Date: Wed, 28 Aug 2019 19:58:25 +0300 From: Victor Gamov <vit@otcnet.ru> To: Eugene Grosbein <eugen@grosbein.net>, freebsd-net@freebsd.org Subject: Re: finding optimal ipfw strategy Message-ID: <dc7df89c-f9f8-bb4f-3600-4e6bc78c6630@otcnet.ru> In-Reply-To: <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net> References: <f38b21a5-8f9f-4f60-4b27-c810f78cdc88@otcnet.ru> <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <a559d2bd-5218-f344-2e88-c00893272222@otcnet.ru> <ddaa55bc-1fa5-151b-258e-e3e9844802ef@yandex.ru> <c275f853-62a7-6bb7-d309-bf8a27d3dbae@grosbein.net> <f2aa4e0e-2339-d3e6-5a41-567b0c55b9e3@otcnet.ru> <eb249ea4-1f14-4826-d235-ed81e1c5e4d0@grosbein.net> <d78ccbbf-115e-d550-077c-383de805556b@otcnet.ru> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dc7df89c-f9f8-bb4f-3600-4e6bc78c6630>