Re: Filtering arp on vlan trunk interface

This mail didn't make it to the list on friday, probably the spam filter
filtered out the image url I included. Trying it with an attachment this time.

----------------------

Ok, let me be a litte more specific. See the setup in the attached screenshot.

Connections to the router are only made (or should only be made) through br111.
br0 is an old bridge that will be phased out soon, but still needs to be
available on the same vlan as br111 in the MZ (there are more vlans in the
original setup). The coloured line is showing the way of the arp broadcasts
originated by the router. The mac of the router is learned on vlan111 of br0.
That's why I'm trying to prevent the routers mac address from reaching the arp
table of br0.

In this case, unfortunately the setup can't be different in order to share the
upstream on top.

I played a bit with several ebtables and arptables rules and I'm really not sure
about the results.

1. I inserted rules into ebtables + arptables. Ebtables rules match first, the
counter values increment, but packets are still seen in tcpdump (read on,
because they are not seen anymore later on). Arptables rules don't match.
Removing the ebtables rules starts incrementing the arptable rules. This means
to me, arptables is hooked in after ebtables, right?

2. When completely blocking arp broadcast traffic for the router with these
rules on the bridge...
ebtables -A INPUT -p ARP -s 0:0e:15:33:9f:1b -d Broadcast -j DROP
ebtables -A FORWARD -p ARP -s 0:0e:15:33:9f:1b -d Broadcast -j DROP
... the routers mac address is not learned on br0's vlan111 anymore, of course.
Tcpdump is not displaying a single arp packet from the router, except on
eth0.111, so it's still appearing on br111's eth0.111 bridge arp table:

  1     0:0e:15:33:9f:1b       no                 0.33

This entry is even relearned after the ageing time has been reached and the
address is removed from the list. But why is this happending.

So to me it seems as if blocking arp requests in ebtables using "-i" or
"--logical-in" doesn't affect the bridge arp-table.

When completely clearing the arp cache of the router, it's mac address is
learned on eth2 of br0 as well.

Shouldn't this all be blocked by the ebtables rules?

Let me know if I'm totally wrong with my assumptions.

Thanks for your time.

Best,

Lars


Bart De Schuymer wrote:
> Op do, 30-08-2007 te 23:29 +0200, schreef xerofun:
> 
>> 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?
> 
> Use ebtables --log --log-arp to see how ebtables sees the packets. If
> something looks wrong please mail it here. Shouldnt you also have a -i
> eth2 rule? Isn't your arp table populated through that input port?
> 
>>> With {arp,ip,ip6}tables you can filter vlan encapsulated packets.
>> @Bart: So did you just forget "eb" in the curly brackets or did you mean that
>> these are the right tools to do so?
> 
> I didn't forget "eb", that's basically why that entry was in the todo
> list. If the bridge port is a vlan device (like your vlan111) then you
> can filter on the arp though.
> 
>> What I really want to do is to prevent mac addresses to reach the bridge mac table.
> 
> "arptables -A INPUT -j DROP" should do this. Using the ebtables
> PREROUTING and/or INPUT chain should do this too.
> 
> cheers,
> Bart
> 
> 
> 
>

-------------------------------------------------------------------------
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/

_______________________________________________
Ebtables-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ebtables-user