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