OISM selective multicast Ingress Replication with IGMP proxy

1

(% class="row" %)

2

(((

3

(% class="col-xs-12 col-sm-8 test-report-content" %)

(((

----

When EVPN operates over a unicast underlay, Network Virtualization Overlay (NVO) networks using EVPNs as their control plane may use trees based on Ingress Replication (IR) or Protocol Independent Multicast (PIM) to convey the overlay Broadcast, Unknown Unicast, or Multicast (BUM) traffic. However, there are certain circumstances in which PIM cannot be deployed. In such a situation, IR is the only option left.

8

9

IGMP and MLD are essential protocols for tenants to indicate their interest in receiving multicast traffic. Tenants join multicast groups on specific subnets or VLANs by sending IGMP or MLD membership reports. Routers, in turn, periodically send membership queries to verify whether hosts on the subnet still wish to receive multicast traffic for a given group. However, these core mechanisms require periodic flooding of messages throughout the network, which is suboptimal for NVO environments. To address this, RFC 9251 introduces the IGMP/MLD proxy, which aims to: reduce IGMP/MLD message flooding, provide a distributed anycast multicast proxy, and enable selective multicast (only when supported).

10

11

In our test, we evaluated an OISM selective multicast IR solution. We began by generating IGMPv3 (S, G) join messages from the receiver and confirmed proper advertisement of EVPN RT-6 and RT-7. Next, multicast traffic was sent from the source using Keysight IxNetwork, and no packet loss was observed, verifying IR functionality. Since the multicast traffic included both intra- and inter-subnet flows, we confirmed that OISM IRB was functioning correctly. Finally, during a failover in the multi-homed group, a small amount of packet loss occurred, but recovery was achieved within 3 seconds, with no additional packet loss afterward, as expected.

12

13

In this test, we also verified the Proxy MAC-IP advertisement feature. We verified that the P flag in the EVPN ARP/ND extended community was properly set in both advertised and received EVPN RT-2.

14

15

[[~[~[Figure 14: EVPN VXLAN OISM selective multicast Ingress Replication combi 1~>~>image:486469475691855873_VXLAN-1.09_1.png~|~|alt="Figure 14" width="450"~]~]>>attach:486469475691855873_VXLAN-1.09_1.png||target="_blank"]]

16

17

The remaining combinations were additional iterations of combination 1, but without failover for the multi-homed group.

18

19

[[~[~[Figure 15: EVPN VXLAN OISM selective multicast Ingress Replication combi 2~>~>image:486469475691921409_VXLAN-1.09_2.png~|~|alt="Figure 15" width="450"~]~]>>attach:486469475691921409_VXLAN-1.09_2.png||target="_blank"]]

20

21

[[~[~[Figure 16: EVPN VXLAN OISM selective multicast Ingress Replication combi 3~>~>image:486469475691986945_VXLAN-1.09_3.png~|~|alt="Figure 16" width="450"~]~]>>attach:486469475691986945_VXLAN-1.09_3.png||target="_blank"]]

22

23

(% id="prev-next-links" %)

24

|[[< Previous>>doc:Optimized Inter-Subnet Multicast with PIM EVPN Gateway (PEG)]]|[[Next ~>>>doc:EVPN VXLAN with BGP IPv6 Unnumbered Underlay]]

25

)))

26

27

(% class="col-xs-12 col-sm-4 test-report-sidebar" %)

28

(((