Re: Filtering arp on vlan trunk interface

On 08/30/07 07:51, xerofun wrote:
> I'm trying to filter arp broadcast packets from a specific mac 
> address (0:0e:15:33:9f:1b) on interface vlan111.

That should be simple enough to do.

> But I'm not sure if this issue is related to the item "ip/arp/etc 
> over vlan filtering" in the todo list?

I don't know and as such can not say.

> The bridge looks likes this:
> 
> br0   0001.00e081111112   yes   eth2
>                                 vlan111  (@eth3)

This looks simple enough.  Well at least so long as there is not a loop 
between VLAN 111 and eth2.

> When adding these rules to the INPUT and FORWARD chain, the counter 
> values raise, so it looks like packets are dropped.
> 
> -A INPUT -p ARP --logical-in br0 --arp-mac-src 0:0e:15:33:9f:1b -j 
> DROP , pcnt = 2211 -- bcnt = 101706
> 
> -A FORWARD -p ARP --logical-in br0 --arp-mac-src 0:0e:15:33:9f:1b -j 
> DROP , pcnt = 6876 -- bcnt = 316296

Ok...

> I also added these rules with "-i vlan111" instead of "--logical-in
> br0".

Ok...

> Using 'brctl showmacs br0' I grep for the mac address. It's not 
> dissappearing, but instead, everytime a packet is dropped in the 
> chain (I'm running 'watch -n1 -d ebtables -L --Lc') the ageing timer 
> for that mac gets refreshed.

Well back up a moment and think about what you are doing.  I'm presuming 
that you are running EBTables (verses IPTables and / or ARPTables) on 
the bridge interface br0.  Thus you are filtering packets that are 
coming in to the system's higher layer network / protocol stack through 
br0.  Thus the packets are already being bridged from either eth2 or 
vlan111 in to br0.  Thus the MAC addresses would show up as a MAC 
address that the bridging code has bridged for you.

If you are wanting to prevent the MAC address from showing up at all, 
try your filtering as the packets enter either the eth2 or vlan111 
interface before they are bridged to br0.

> So is this related to the todo "ip/arp/etc over vlan filtering"?

I'm not exactly sure what the "ip/arp/etc over vlan filtering" issue is 
so I can not say "No" for sure.  However given the above point of view I 
going to guess "no".

> How would I be able to filter such an arp request, so that it's not
> added to the bridge mac table?

Try using EBTables to filter the traffic before it enters the bridge by 
filtering at the lower level eth2 and / or vlan111 interfaces.

You may also want to investigate ARPTables for this.

> Tcpdump also sees the arp packets coming in, this wouldn't be
> happening if the ARP packets would have been filtered, right?

Ugh, I think this depends on what type of interface you are sniffing and 
what sniffer you are running as in where said sniffer connects to the 
interface and what capabilities the sniffer has.

> I'm running Kernel 2.6.22.5 + Bridge + ebtables

Ok.  I don't know of any problems there.

> Thanks in advance,

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/