Description of problem: [ovn 2.13][20.B]when create a logical-sw and set the mcast_flood=true of a ls port for the first time,mcast_flood takes a long time to work Version-Release number of selected component (if applicable): ovn2.13 20.B How reproducible: always Steps to Reproduce: 1.create a logical-sw and two port(p1,p2) on the ls 2.set the mcast_snooping=true 3.set p2 option mcast_flood=true 4.ping 224.1.1.1 from p1,p2 can't recieve the icmp packets in 5 minutes at least Actual results: p2 can't recieve the icmp packets in 5 minutes at least Expected results: p2 should recieve the icmp packets immediately Additional info: but after that ,set the option mcast_flood from true to false and then to true,it will work immediately.only when the first time it needs a long time to work.
Hi Ying Xu, What OVN version are you using? I see the bug reported against component ovn2.13 but there's no FDP ovn 2.13 release yet. Also, can you please describe the whole configuration of your topology? Please include the OVN NB/SB Db and linux interfaces, IPs and routes for your VMs? FYI, on a plain setup running ovn2.13-2.13.0-0.20200217git7886ac9.el8fdp I don't see the issue. Thanks, Dumitru
(In reply to Dumitru Ceara from comment #1) > Hi Ying Xu, > > What OVN version are you using? I see the bug reported against component > ovn2.13 but there's no FDP ovn 2.13 release yet. > Also, can you please describe the whole configuration of your topology? > Please include the OVN NB/SB Db and linux interfaces, IPs and routes for > your VMs? > my configuration as below: [root@dell-per730-03 basic]# ovn-nbctl show switch 1edf5679-25e2-45a3-82f0-644cc4d8aa82 (ls2) port ls2p1 addresses: ["00:00:00:01:01:02"] port ls2p2 addresses: ["00:00:00:01:01:04"] [root@dell-per730-03 basic]# ovn-sbctl show Chassis hv1 hostname: dell-per730-03.rhts.eng.pek2.redhat.com Encap geneve ip: "20.0.3.25" options: {csum="true"} Port_Binding ls2p2 Port_Binding ls2p1 Chassis hv0 hostname: ibm-x3650m4-04.rhts.eng.pek2.redhat.com Encap geneve ip: "20.0.3.26" options: {csum="true"} netns connected to the ls2p1: # ip netns exec server0 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 173: veth0_s0@if172: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:00:00:01:01:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.16.2.1/24 scope global veth0_s0 valid_lft forever preferred_lft forever inet6 fe80::200:ff:fe01:102/64 scope link valid_lft forever preferred_lft forever #ip netns exec server0 ip route default via 172.16.2.254 dev veth0_s0 172.16.2.0/24 dev veth0_s0 proto kernel scope link src 172.16.2.1 netns connected to the ls2p2: # ip netns exec server1 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 175: veth0_s1@if174: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:00:00:01:01:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.16.2.2/24 scope global veth0_s1 valid_lft forever preferred_lft forever inet6 fe80::200:ff:fe01:104/64 scope link valid_lft forever preferred_lft forever #ip netns exec server1 ip route default via 172.16.2.254 dev veth0_s1 172.16.2.0/24 dev veth0_s1 proto kernel scope link src 172.16.2.2 > FYI, on a plain setup running ovn2.13-2.13.0-0.20200217git7886ac9.el8fdp I > don't see the issue. I found the issue on version as below: it is the same version as yours [root@dell-per730-03 basic]# rpm -qa|grep ovn kernel-kernel-networking-openvswitch-ovn-common-1.0-7.noarch kernel-kernel-networking-openvswitch-ovn-qos-1.0-1.noarch kernel-kernel-networking-openvswitch-ovn-basic-1.0-19.noarch ovn2.13-2.13.0-0.20200217git7886ac9.el8fdp.x86_64 ovn2.13-central-2.13.0-0.20200217git7886ac9.el8fdp.x86_64 ovn2.13-host-2.13.0-0.20200217git7886ac9.el8fdp.x86_64 kernel-kernel-networking-openvswitch-ovn-multicast-1.0-3.noarch kernel-kernel-networking-openvswitch-ovn-scenario-1.0-3.noarch > > Thanks, > Dumitru I think you can try to clear all the ovn configurations and then create again. that means you can start with an empty environment.
Fix sent for review upstream: https://patchwork.ozlabs.org/patch/1245901/
verified on version: # rpm -qa|grep ovn ovn2.13-central-2.13.0-11.el8fdp.x86_64 ovn2.13-host-2.13.0-11.el8fdp.x86_64 ovn2.13-2.13.0-11.el8fdp.x86_64 create the topo: switch e52362a8-6c7a-4c8a-adfc-c08e4eb84a42 (ls2) port ls2p1 addresses: ["00:00:00:01:01:02"] port ls2p2 addresses: ["00:00:00:01:01:04"] port ls2-lr1 type: router addresses: ["00:de:ad:ff:01:02"] router-port: lr1-ls2 switch ac59492e-42a3-4e65-ac33-50e3195b9164 (ls1) port ls1-lr1 type: router addresses: ["00:de:ad:ff:01:01"] router-port: lr1-ls1 port ls1p1 addresses: ["00:00:00:01:00:02"] router 91121b15-d742-4b9b-8123-31a96beb728c (lr1) port lr1-ls1 mac: "00:de:ad:ff:01:01" networks: ["172.16.1.254/24"] port lr1-ls2 mac: "00:de:ad:ff:01:02" networks: ["172.16.2.254/24"] set the mcast_flood=true,ls2p1 can ping to ls2p2 immediatly 15:34:56.936045 M 00:de:ad:ff:01:02 ethertype IPv4 (0x0800), length 100: 172.16.1.1 > 224.1.1.3: ICMP echo request, id 33359, seq 1, length 64 15:34:57.934372 M 00:de:ad:ff:01:02 ethertype IPv4 (0x0800), length 100: 172.16.1.1 > 224.1.1.3: ICMP echo request, id 33359, seq 2, length 64 15:34:58.934389 M 00:de:ad:ff:01:02 ethertype IPv4 (0x0800), length 100: 172.16.1.1 > 224.1.1.3: ICMP echo request, id 33359, seq 3, length 64 15:34:59.934366 M 00:de:ad:ff:01:02 ethertype IPv4 (0x0800), length 100: 172.16.1.1 > 224.1.1.3: ICMP echo request, id 33359, seq 4, length 64 15:35:00.934362 M 00:de:ad:ff:01:02 ethertype IPv4 (0x0800), length 100: 172.16.1.1 > 224.1.1.3: ICMP echo request, id 33359, seq 5, length 64 set verified
All these bugs have been verified and have shipped in FDP 20.G or earlier.