Re: Filtering arp on vlan trunk interface

Note:  I have not thoroughly read your follow up message from today.

On 08/30/07 16:29, xerofun wrote:
> Well, there actually is a loop (at least concerning mac conflicts), 
> but I wanted to keep my question as simple as possible, as there's no 
> way to prevent the loop in this setup, which is a bit more complex 
> than what I was showing above. By being able to filter out the mac 
> address I was talking about, I could fix this mac loop.

*nod*

> Yes, right, I'm running ebtables + iptables. Sorry for not mentioning 
> this.

No problem.  I just wanted to make sure that we were all on the same page.

> The arp requests I want to filter enters vlan111 and that's where I 
> also tried to filtered the requests.

Ok.

> So thinking about your explanation, I tried the following:
> 
> Bridge chain: INPUT, entries: 20, policy: ACCEPT
> -s 0:0e:15:33:9f:1b --logical-in br0 -j DROP , pcnt = 229 -- bcnt = 
> 10534
> -s 0:0e:15:33:9f:1b -i vlan111 -j DROP , pcnt = 0 -- bcnt = 0
> Bridge chain: FORWARD, entries: 60, policy: ACCEPT
> -s 0:0e:15:33:9f:1b --logical-in br0 -j DROP , pcnt = 36 -- bcnt = 
> 1656
> -s 0:0e:15:33:9f:1b -i vlan111 -j DROP , pcnt = 0 -- bcnt = 0
> 
> So this only matches the first rule, the counters of the second rules 
> in every chain are never matched/incremented. I'm definetly not 
> trying to proof you wrong, or maybe I just get something wrong here, 
> but shouldn't the ARP request be filtered by the second rule before 
> it "reaches" br0? Following your explanation - which sounds 
> absolutely reasonable - this should be the way, right?

If I have tings straight in my head, now knowing that you are doing the 
filtering with EBTables, I think both rules apply sequentially on the 
packets.

So, with that in mind as the packets come in vlan111 on their way out 
the br0 interface your first rule is matching because the packets will 
be coming in the logical br0 interface.

You packets also would match the second rule as they are coming in the 
vlan111 interface, however the first rule is DROPing them.  I would 
recommend that you use your second rule and remove the first one.

I need to ask.  Do you have the "Bridged IP/ARP packets filtering" 
(CONFIG_BRIDGE_NETFILTER) turned on in your kernel?  I ask because this 
determines if IPTables will see bridged packets or not.  If this option 
is turned on then you will need to be aware that IPTables will see and 
effect bridged traffic.  If this option is not turned on then IPTables 
will have no bearing on bridged traffic.  I would almost be willing to 
bet that it is on and should probably be turned off in your situation.

> I never used ARPtables, where does it hook into the packet flow? 
> Before ebtables or after ebtables? I will definetly have a look at 
> it.

I don't know for sure.

> This question was more about at what point tcpdump gets fed with the 
> packet headers. From my point of view it should happen after all 
> filtering is done, as it is a userspace tool and ebtables/iptables 
> filtering happens in kernelspace, right?

Don't know this one either.

> Thanks a lot for your detailed answer.

You are welcome.



Grant. . . .

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/