finding optimal ipfw strategy

Victor Gamov vit at otcnet.ru
Wed Aug 28 16:58:31 UTC 2019


On 28/08/2019 18:48, Eugene Grosbein wrote:
> 28.08.2019 17:18, Victor Gamov wrote:
> 
>>> Why do you need to filter ARP on bridge? That's unusial. VLANs are
>>> isolated by default and by definition, unless you explicitly enable
>>> inter-vlan routing and setup your routing table.
>>
>> May be I have some misunderstood here but...
>> If I have many VLANs bridged via bridge interface then ARP received
>> from one VLAN will be send to all bridge members.  So it will be send
>> to all unwanted VLANs. Is it correct?
> 
> Yes. So, you really do not want any kind of unicast bridging at all
> and use bridge as "poor man's" replacement for inter-vlan multicast routing, right?

:-)  Looks like this

But I start this project as experiment (now in production) to get 
"router" which allowed implicitly send multicast whithout needs to 
igmp-join from attached VLANs and with my own multicast policy.


> In such case you could benefit from small patch that allows you to block ARP packets unconditionally
> as if they were filtered by ipfw without really passing them through the ruleset.
> Use sysctl net.link.bridge.ipfw_arp=-1 with the patch (untested):

I'll try it when make test server. Thanks!


>>> Anyway, you can skip entire ipfw pass over a bridge because you
>>> filter its members anyway, so just drop ARP coming from any vlan with
>>> exception of controlling one:
>>>
>>> allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan deny ip from any to any layer2 mac-type 0x0806 in allow ip from any
>>> to any layer2
>>>
>>> And then disable filtering for bridge itself altogether. Decreasing
>>> number of passes over ipfw should be your top priority because that's
>>> what can provide you with most benefit. You should even rewrite your
>>> ruleset if that is needed to achieve this goal.
>>
>> If I set net.link.bridge.ipfw=0 but net.link.ether.ipfw and net.link.bridge.ipfw still set to 1
>> is it still possible block unwanted ARP received from one VLAN and bridged to other on outgoing VLAN like
>>
>> deny ip from any to any layer2 mac-type 0x0806 out xmit MAC not $mymac any
>>
>> Is it correct and more effective than net.link.bridge.ipfw=1 if I have "deny mac-type 0x0806 via bridge" at rules top?
> 
> Yes. And anything decreasing number of traffic passes over entire ipfw ruleset is efficient.

ok, will try it some later.  Hope no problem to switch on/off this 
sysctl on production server :-)

Many thanks, Eugene!


P.S. Two questions about rules syntax optimization.  What is more effective:
  skipto tablearg udp from any to table(AllMcast_out)
or
  skipto tablearg udp from any to table(AllMcast_out) out xmit vlan*

I hope I can place such rule at top of ruleset and only allowed 
multicast packets outgoing via VLANs interfaces will hit this rule.


and second:
  allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 }
or
  allow udp from src1 to 239.1.2.0/24{55,56}


Thanks again!

-- 
CU,
Victor Gamov


More information about the freebsd-net mailing list