From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 13 09:03:07 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A756E16A41F for ; Sat, 13 Aug 2005 09:03:07 +0000 (GMT) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (prime.gushi.org [65.125.228.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F4CB43D45 for ; Sat, 13 Aug 2005 09:03:07 +0000 (GMT) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (danm@localhost.gushi.org [127.0.0.1]) by prime.gushi.org (8.13.4/8.13.4) with ESMTP id j7D98BoZ074098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2005 05:08:11 -0400 (EDT) Received: (from danm@localhost) by prime.gushi.org (8.13.4/8.13.4/Submit) id j7D98Amm074092; Sat, 13 Aug 2005 05:08:10 -0400 (EDT) Date: Sat, 13 Aug 2005 05:08:10 -0400 (EDT) From: "Dan Mahoney, System Admin" To: Luigi Rizzo In-Reply-To: <20050812170348.A20828@xorpc.icir.org> Message-ID: <20050813044147.B61674@prime.gushi.org> References: <20050812042749.H87994@prime.gushi.org> <20050812063359.A14229@xorpc.icir.org> <20050812224956.GG45385@obiwan.tataz.chchile.org> <20050812170348.A20828@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 13 Aug 2005 15:11:16 +0000 Cc: hackers@freebsd.org, Jeremie Le Hen Subject: Re: 5.4 -- bridging, ipfw, dot1q X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2005 09:03:07 -0000 On Fri, 12 Aug 2005, Luigi Rizzo wrote: > On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: >> Hi, >> >>> I am afraid the existing code cannot help you. >>> The packets you see are encapsulated in 802.1q aka VLAN frames, >>> and since ipfw2 does not try to decapsulate the packets, you >>> don't get to see the IP headers. >>> >>> Your most reasonable option would be to write a new ipufw2 opcode, >>> say something like 'vlan-decap x-y', which succeeds if the packet has >>> a vlan header in the range x to y, and in this case skips the VLAN header, >>> tries to re-parse the header fields as in the beginning of >>> ip_fw_chk() after the section >>> >>> /* >>> * Collect parameters into local variables for faster matching. >>> */ >>> >>> and then continues. >>> It's not a lot of code, in the worst case you can just cut&paste >>> the relevant 50-60 lines from the beginning of the code >>> (though of course it would be nice to rearrange the code to >>> reduce duplication). >>> >>> By doing this you can do something like >>> >>> ipfw add skipto 1000 vlan-decap 1-50 >>> >>> and then process vlans 1 to 50 at line 1000. >>> Maybe it is a good idea to split the vlan-id matching and the decapsulation. >> >> Isn't it posible to cheat using vlan(4) interface ? I think it's >> possible to create them in order to use its code to zap the VLAN header >> and then use ipfw to filter on these vlan(4) interfaces. This isn't >> more than a workaround, but it might help. After all, the demuxing is nothing more than ignoring a few extra bits at the beginning of the packet. Which all my BPF stuff is doing nicely. Snort, trafshow, etc all work fine and don't seem to choke on the extra frames. I'd personally just be happy if ipfw was smart enough to know that if I was using ip-type rules on something that's not ip...that it would handle the demuxing automagically. i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan via em1 or maybe i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan-as-inet via em1 assuming mac-type vlan is, of course, dot1q trunk traffic. or better still... ipfw add 200 deny ip from any to 10.2.2.2 mac-type vlan vlan-id 400 via em1 I'd also really like it if non-bridged interfaces kept their arp table separate from normal interfaces -- but that's a separate issue I'm experiencing when the management subnet (on a dedicated non-bridged nic) also happens to be one of the vlans within the dot1q trunk. A spanning tree daemon (user or kernelspace) wouldn't be bad either. > > well it would be painful to configure, because the number of vlans is > (according to what Dan says) is large, and he would have to define > N vlan interfaces on each of the physical ones, then define > N bridges between the corresponding vlans (and i think there is > a limit on how large N can be). It's worse than that. The device has four bridged interfaces. One up, three down to three switches. Each switch holds 24 vlans. That QUICKLY becomes a nightmare when bridging actually works without doing this. It's just ipfw saying "nope, there's no possible way for me to look > Additionally demuxing incoming packets would take O(N) time. > > cheers > luigi > -- "I hate Windows" -Tigerwolf, Anthrocon 2004 --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------