On 27/10/2018 18:44, Eugene Grosbein wrote:
27.10.2018 22:16, Victor Gamov wrote:

Hi All

I have some misunderstanding how ipfw work with VLAN and bridge

I have following config


         bridge2
       ------------
      /      |     \
     /       |      \
    /        |       \
vlan200  vlan300  vlan400
(igb0)    (igb0)   (igb1)


=====
net.link.bridge.ipfw: 1
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 1
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

net.link.ether.ipfw=1
=====


I need to allow some multicast from some vlans, block other multicast and 
forward allowed multicast into other vlans

Your ruleset needs to differentiate packets based on name of incoming bridge 
member
but you forgot to enable net.link.bridge.pfil_member=1. Enable it.

Also note that change of net.link.bridge.ipfw from 0 to 1 disables
net.link.bridge.{pfil_member|pfil_onlyip|pfil_bridge} but you are allowed
to enable them after.

net.link.bridge.pfil_member=1 makes frames enter ruleset as incoming from 
bridge member, zero disables this pass.

net.link.bridge.ipfw=1 makes frames enter ruleset again as incoming from bridge 
interface itself
without distinction of bridge member, and for forwarded frames enter ruleset 
one more time as outgoing from the bridge itself.

And frame enters ruleset one MORE time as outgoing from bridge member if 
net.link.bridge.pfil_member=1.

Hi Eugene,

Thanks for your quick response!


With current configs I have unexpected behavior when multicast received via unneeded vlan300 not blocked by rule 9000 and bad traffic bridged into all bridge members.

So if when net.link.bridge.pfil_member=1 then I can check incoming and outgoing bridge members as expected? I'll try it later, thanks


Is it possible the following config with net.link.bridge.pfil_member=1 ?

table allow239 create type iface
table allow239 add vlan400
3000 allow ip from any to 239.0.0.10 recv vlan100 xmit table(allow239)


It's still very interesting to know full packet path via all interfaces (phy, vlan, bridge) and understand where/why ipfw triggered.

For example why i need "allow via igb0"? It's because net.link.ether.ipfw=1?

Can you explain it in details?


Thanks again!


--
CU
Victor Gamov
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to