Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-59559

Linux bonding-slb should steer IGMP/MLD queries to be sent using the active bond port member

XMLWordPrintable

    • rhel-sst-network-management
    • ssg_networking
    • 13
    • 5
    • False
    • Hide

      None

      Show
      None
    • None
    • NMT - RHEL-9.6/RHEL 10 DTM 10
    • Hide

      Given a bonded interface (bond0) in SLB mode with multiple ports and multicast traffic flowing to a VM,

      When a failover occurs (port1 goes down and port2 becomes active),

      Then, NetworkManager should automatically ensure that IGMP join and MLD report packets are re-sent from the new active port to maintain the multicast flow.

      Definition of Done:

      • The implementation meets the acceptance criteria
      • Integration tests are written and pass
      • The code is part of a downstream build attached to an errata
      Show
      Given a bonded interface (bond0) in SLB mode with multiple ports and multicast traffic flowing to a VM, When a failover occurs (port1 goes down and port2 becomes active), Then, NetworkManager should automatically ensure that IGMP join and MLD report packets are re-sent from the new active port to maintain the multicast flow. Definition of Done : The implementation meets the acceptance criteria Integration tests are written and pass The code is part of a downstream build attached to an errata
    • Pass
    • None
    • None

      In a scenario where a VM1 join a multicast group and send multicast stream from a remote VM2 to the VM1, then bring down/up bonding port, then send multicast stream from a remote VM2 to this VM1 again, and check if multicast stream can still reach VM1. Sometimes, the multicast stream can't reach VM1 after failover.

      When the bridge's igmp_snooping is on, it needs to re-send igmp join packet to update the route path for multicast packets after failover, but mode 2 bonding doesn't support this (resend_igmp). So multicast packets could be lost after failover.

              rhn-engineering-vbenes Vladimir Benes
              ferferna Fernando Fernandez Mancera
              Network Management Team Network Management Team
              Vladimir Benes Vladimir Benes
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: