Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 1805652

Summary: [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
Product: Red Hat Enterprise Linux Fast Datapath Reporter: ying xu <yinxu>
Component: ovn2.13Assignee: Dumitru Ceara <dceara>
Status: CLOSED ERRATA QA Contact: ying xu <yinxu>
Severity: high Docs Contact:
Priority: high    
Version: FDP 20.ACC: ctrautma, dceara, jishi, ralongi
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovn2.13-2.13.0-2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-10 15:23:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description ying xu 2020-02-21 10:00:15 UTC 
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.
Comment 1 Dumitru Ceara 2020-02-21 13:00:50 UTC 
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
Comment 2 ying xu 2020-02-23 02:34:05 UTC 
(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.
Comment 3 Dumitru Ceara 2020-02-27 14:59:30 UTC 
Fix sent for review upstream: https://patchwork.ozlabs.org/patch/1245901/
Comment 5 ying xu 2020-04-15 09:57:41 UTC 
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
Comment 6 Dan Williams 2020-11-10 15:23:33 UTC 
All these bugs have been verified and have shipped in FDP 20.G or earlier.