I am also agree flooding is caused due to
- for egress trffic there is action=NORMAL
- for ingress traffic there is direct action=output:PORT
in the openflow rules.
NORMAL action causes openvswitch to flood traffic if there is no dst mac entry in fdb table
(https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-xlate.c#L3109)
At the same time MAC address is put into fdb table only if NORMAL action is performed (note, no mac learning is performed for direct output:PORT action)
E.g.
- a VM with m_mac sends packets to a node with node_mac -> it forces an ovs to learn vm_mac and remember this mac in br-int fdb table, then packet is flooded to all ovs ports;
- the node responses to vm_mac using output:VM_PORT rule -> the packet is sent directly to the VM port (without node_mac learning)
- the VM again sends packet to the node -> there is no node_mac in the fdb table and it forces ovs another packet flooding to all ports.
I am also agree flooding is caused due to
- for egress trffic there is action=NORMAL
- for ingress traffic there is direct action=output:PORT
in the openflow rules.
NORMAL action causes openvswitch to flood traffic if there is no dst mac entry in fdb table /github. com/openvswitch /ovs/blob/ master/ ofproto/ ofproto- dpif-xlate. c#L3109)
(https:/
At the same time MAC address is put into fdb table only if NORMAL action is performed (note, no mac learning is performed for direct output:PORT action)
E.g.
- a VM with m_mac sends packets to a node with node_mac -> it forces an ovs to learn vm_mac and remember this mac in br-int fdb table, then packet is flooded to all ovs ports;
- the node responses to vm_mac using output:VM_PORT rule -> the packet is sent directly to the VM port (without node_mac learning)
- the VM again sends packet to the node -> there is no node_mac in the fdb table and it forces ovs another packet flooding to all ports.