This is an automatically-generated clone of issue https://bugzilla.redhat.com/show_bug.cgi?id=2211240
tested with following script: systemctl start openvswitch systemctl start ovn-northd ovn-nbctl set-connection ptcp:6641 ovn-sbctl set-connection ptcp:6642 ovs-vsctl set open . external_ids:system-id=hv1 external_ids:ovn-remote=tcp:127.0.0.1:6642 external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=127.0.0.1 systemctl restart ovn-controller ovn-nbctl ls-add ls1 ovn-nbctl lsp-add ls1 ls1p1 ovn-nbctl lsp-set-addresses ls1p1 "00:00:00:01:01:02 192.168.1.1 2001::1" ovn-nbctl lsp-add ls1 ls1p2 ovn-nbctl lsp-set-addresses ls1p2 "00:00:00:01:02:02 192.168.1.2 2001::2" ovn-nbctl lr-add lr1 ovn-nbctl lrp-add lr1 lr1-ls1 00:00:00:00:00:01 192.168.1.254/24 2001::a/64 ovn-nbctl lsp-add ls1 ls1-lr1 ovn-nbctl lsp-set-addresses ls1-lr1 "00:00:00:00:00:01 192.168.1.254 2001::a" ovn-nbctl lsp-set-type ls1-lr1 router ovn-nbctl lsp-set-options ls1-lr1 router-port=lr1-ls1 ovn-nbctl lrp-add lr1 lr1-ls2 00:00:00:00:00:02 192.168.2.254/24 2002::a/64 ovn-nbctl ls-add ls2 ovn-nbctl lsp-add ls2 ls2-lr1 ovn-nbctl lsp-set-addresses ls2-lr1 "00:00:00:00:00:02 192.168.2.254 2002::a" ovn-nbctl lsp-set-type ls2-lr1 router ovn-nbctl lsp-set-options ls2-lr1 router-port=lr1-ls2 ovn-nbctl lsp-add ls2 ls2p1 ovn-nbctl lsp-set-addresses ls2p1 "00:00:00:02:01:02 192.168.2.1 2002::1" ovn-nbctl lsp-add ls1 ls1p3 ovn-nbctl lsp-set-addresses ls1p3 "00:00:00:01:03:02 192.168.1.3 2001::3" ovn-nbctl set logical_router lr1 options:always_learn_from_arp_request=false ovs-vsctl add-port br-int ls1p1 -- set interface ls1p1 type=internal external_ids:iface-id=ls1p1 ip netns add ls1p1 ip link set ls1p1 netns ls1p1 ip netns exec ls1p1 ip link set lo up ip netns exec ls1p1 ip link set ls1p1 address 00:00:00:01:01:02 ip netns exec ls1p1 ip link set ls1p1 up ip netns exec ls1p1 ip addr add 192.168.1.1/24 dev ls1p1 ip netns exec ls1p1 ip addr add 2001::1/64 dev ls1p1 ip netns exec ls1p1 ip route add default via 192.168.1.254 ip netns exec ls1p1 ip -6 route add default via 2001::a ovs-vsctl add-port br-int ls1p2 -- set interface ls1p2 type=internal external_ids:iface-id=ls1p2 ip netns add ls1p2 ip link set ls1p2 netns ls1p2 ip netns exec ls1p2 ip link set lo up ip netns exec ls1p2 ip link set ls1p2 address 00:00:00:01:02:02 ip netns exec ls1p2 ip link set ls1p2 up ip netns exec ls1p2 ip addr add 192.168.1.2/24 dev ls1p2 ip netns exec ls1p2 ip addr add 2001::2/64 dev ls1p2 ip netns exec ls1p2 ip route add default via 192.168.1.254 ip netns exec ls1p2 ip -6 route add default via 2001::a ovs-vsctl add-port br-int ls2p1 -- set interface ls2p1 type=internal external_ids:iface-id=ls2p1 ip netns add ls2p1 ip link set ls2p1 netns ls2p1 ip netns exec ls2p1 ip link set lo up ip netns exec ls2p1 ip link set ls2p1 address 00:00:00:02:01:02 ip netns exec ls2p1 ip link set ls2p1 up ip netns exec ls2p1 ip addr add 192.168.2.1/24 dev ls2p1 ip netns exec ls2p1 ip addr add 2002::1/64 dev ls2p1 ip netns exec ls2p1 ip route add default via 192.168.2.254 ip netns exec ls2p1 ip -6 route add default via 2002::a ip netns exec ls1p1 python3 test.py ovn-sbctl list mac_binding [root@kvm-01-guest09 bz2211240]# cat test.py from scapy.all import * # Craft the ND broadcast packet na_packet = Ether(dst="ff:ff:ff:ff:ff:ff")/IPv6(dst="fe80::1")/ICMPv6ND_NA(tgt="fe80::f816:3eff:fe55:a747") # Send the packet sendp(na_packet, iface="ls1p1") reproduced on ovn-2021-21.12.0-103.el9: [root@kvm-01-guest09 bz2211240]# rpm -qa | grep -E "openvswitch2.17|ovn-2021" openvswitch2.17-2.17.0-92.el9fdp.x86_64 ovn-2021-21.12.0-103.el9fdp.x86_64 ovn-2021-central-21.12.0-103.el9fdp.x86_64 ovn-2021-host-21.12.0-103.el9fdp.x86_64 + ip netns exec ls1p1 python3 test.py . Sent 1 packets. + ovn-sbctl list mac_binding _uuid : aa677ba7-a4f6-4c4c-9df0-c9c415a73d01 datapath : 04b2b9b1-36e6-45c8-bfbf-5c5e5c61a999 ip : "fe80::f816:3eff:fe55:a747" logical_port : lr1-ls1 mac : "00:00:00:01:01:02" <== mac_binding is created Verified on ovn-2021-21.12.0-134.el9: [root@kvm-01-guest09 bz2211240]# rpm -qa | grep -E "openvswitch2.17|ovn-2021" openvswitch2.17-2.17.0-92.el9fdp.x86_64 ovn-2021-21.12.0-134.el9fdp.x86_64 ovn-2021-central-21.12.0-134.el9fdp.x86_64 ovn-2021-host-21.12.0-134.el9fdp.x86_64 + ip netns exec ls1p1 python3 test.py . Sent 1 packets. + ovn-sbctl list mac_binding <== no mac_binding is created
after re-reun the reproducer and add sleep 5 before send NA, the mac_binding is still created when always_learn_from_arp_request is false: + ip netns exec ls2p1 ip -6 route add default via 2002::a + sleep 5 + ip netns exec ls1p1 python3 test.py . Sent 1 packets. + ovn-sbctl list mac_binding _uuid : 58a892d7-8208-448e-8726-88ca2dd361a8 datapath : 09b77f8a-3c67-4351-8125-eda853a02e93 ip : "fe80::f816:3eff:fe55:a747" logical_port : lr1-ls1 mac : "00:00:00:01:01:02" [root@kvm-01-guest09 bz2211240]# rpm -qa | grep -E "openvswitch2.17|ovn-2021" openvswitch2.17-2.17.0-92.el9fdp.x86_64 ovn-2021-21.12.0-134.el9fdp.x86_64 ovn-2021-central-21.12.0-134.el9fdp.x86_64 ovn-2021-host-21.12.0-134.el9fdp.x86_64 Ales, could you help to check?
Hi Jianlin, sorry I was away for a bit. The original reproducer has wrong destionation IP address, so it is in fact correct that it ends up in the MAC binding table. If you change the packet to the following it shouldn't end up in the table: na_packet = Ether(dst="ff:ff:ff:ff:ff:ff")/IPv6(dst="ff00::1")/ICMPv6ND_NA(tgt="fe80::f816:3eff:fe55:a747") Thanks, Ales
updated the test.py: [root@sweetpig-17 bz2213612]# cat test.py from scapy.all import * # Craft the ND broadcast packet na_packet = Ether(dst="ff:ff:ff:ff:ff:ff")/IPv6(dst="ff01::1", src="fe80::abcd:1")/ICMPv6ND_NA(tgt="fe80::f816:3eff:fe55:a747") # Send the packet sendp(na_packet, iface="ls1p1") and Verified on ovn-2021-21.12.0-134.el9: + ip netns exec ls2p1 ip -6 route add default via 2002::a + sleep 5 + ip netns exec ls1p1 python3 test.py . Sent 1 packets. + ovn-sbctl list mac_binding [root@sweetpig-17 bz2213612]# rpm -qa | grep -E "openvswitch2.17|ovn-2021" openvswitch2.17-2.17.0-93.el9fdp.x86_64 ovn-2021-21.12.0-134.el9fdp.x86_64 ovn-2021-central-21.12.0-134.el9fdp.x86_64 ovn-2021-host-21.12.0-134.el9fdp.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (ovn-2021 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:3990