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

Upstream: [Investigation spike] Ethernet multicast communication is getting dropped in L2 OVS bridges due to name differences

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • openvswitch3.4, openvswitch3.5
    • None
    • 5
    • False
    • False
    • Hide

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:
      ( ) Unit test or Integration test case are written and pass successfully

      ( ) The upstream pull request is merged upstream and pass CI

      Show
      Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) Unit test or Integration test case are written and pass successfully ( ) The upstream pull request is merged upstream and pass CI
    • rhel-9
    • None
    • rhel-net-ovs-dpdk

      This is tracking the upstream effort needed to deliver the solution to 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: