Uploaded image for project: 'Fast Datapath Product'
  1. Fast Datapath Product
  2. FDP-2609

Test Coverage: Ethernet multicast communication is getting dropped in L2 OVS bridges due to name differences

    • False
    • Hide

      None

      Show
      None
    • False
    • Hide

      ( ) The test coverage is aligned with the epic's acceptance criteria

      Show
      ( ) The test coverage is aligned with the epic's acceptance criteria
    • rhel-9
    • None
    • rhel-net-ovs-dpdk

      This task is tracking the test case writing activities to cover the bug described below.

       Problem Description: 

      The multicast ethernet packets are getting dropped in L2 ovs-bridges and it is not getting sent against the configured ovs-interface once bridge and interface have different names. All other type of traffic seems to be working except multicast ethernet and it affected NDP IPv6 mechanism in the networking.

      Impact Assessment: It is not causing any blocking however it has affected a critical customer

      Software Versions: openvswitch3.4-3.4.0-48.el9fdp.x86_64 / openvswitch3.5-3.5.0-19.el9fdp.x86_64

      Issue Type: It seems a new issue

       Reproducibility: It is easy to reproduce.

       Reproduction Steps: 

      1. Configure one ovs-bridge using nmstate operator. Note that the ovs-bridge has a different name from ovs-interface on top of this bridge.

      apiVersion: nmstate.io/v1
      kind: NodeNetworkConfigurationPolicy
      metadata:
        name: nmstate-name-ovs-bridge
      spec:
        desiredState:
          interfaces:
          - bridge:
              options:
                mcast-snooping-enable: true
                stp: false
              port:
              - name: br-sec
              - name: bond0.<vlan-id>>
            name: ovs-sec-br-vlan-282 <------
            state: up
            type: ovs-bridge
          - ipv4:
              address:
              - ip: <ipv4-address>
                prefix-length: <net-mask>
              enabled: true
            ipv6:
              address:
              - ip: <ipv6-address>
                prefix-length: 112
              enabled: true
            name: br-sec <----------
            state: up
            type: ovs-interface <--------------- INTERFACE WITH IP!
          - name: bond0.<vlan-id>
            state: up
            type: vlan
            vlan:
              base-iface: bond0
              id: <vlan-id> 

      2. Run a ovs-ofctl trace using the following parameters:

      $ ovs-appctl ofproto/trace <bridge-name> 'in_port=bond0.<vlan-id>,eth_type=0x86dd,ipv6_src=2a00:8a00:4000:20c::18:ee4,ipv6_dst=ff02::1:ff18:f3d,ip_proto=58,icmpv6_type=135,dl_src=00:21:5a:9b:18:54,dl_dst=33:33:ff:18:0f:3d' 

      3. Note that the packet is going to be dropped by ovs-bridge as below.

      bridge("ovs-sec-br-vlan-282")
      -----------------------------
      0. icmp6, priority 90
          NORMAL
           -> unregistered multicast, flooding
       
      Final flow: unchanged
      Megaflow: recirc_id=0,eth,icmp6,in_port=2,dl_src=00:21:5a:9b:18:54,dl_dst=33:33:ff:18:0f:3d,ipv6_dst=ff02::1:ff18:f3d,nw_frag=no,icmp_type=0x87/0xff
      Datapath actions: drop <--------------- 

      4. Once the ovs-bridge and ovs-interface is changed to have the exact same name, the traffic is not dropped anymore and it is allowed.

      Expected Behavior: It is expected that the ovs-bridge allows the packet

      Observed Behavior: Packet is being dropped.

       

              ovsdpdk-triage ovsdpdk triage
              nstbot NST Bot
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: