Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Multicast Router Port Status Synchronization in EVPN-VXLAN Bridged Overlays

Learn how multihoming peer border leaf devices in EVPN-VXLAN bridged overlay (BO) networks synchronize their multicast router (mrouter) interface status by default.

EVPN-VXLAN BO networks extend Layer 2 (L2) traffic between EVPN leaf devices across a Layer 3 (L3) fabric using VXLAN encapsulation. Lean spine devices in the topology use BGP peering for EVPN device reachability and perform IP forwarding.

To handle multicast traffic, the BO network can include EVPN border leaf (BL) devices that connect to an external PIM domain over L2 links. The BL devices use these L2 links to exchange multicast control and data traffic with external receivers. The topology usually includes two (or more) BL devices, and an external multicast router with redundant links to the peer BL devices. The multihomed links comprise an Ethernet segment (ES) that the peer devices share, represented by an ES identifier (ESI). To avoid sending duplicate traffic on multiple links, the ES peer devices elect one of the peers to be the designated forwarder (DF) that handles forwarding traffic toward the subscribed external users. The other peers have non-designated forwarder (NDF) status.

For external receivers that are interested in the multicast traffic, the external multicast router load-balances IGMP or MLD queries to one of its multihomed links connected to the peer BL devices. The EVPN devices in the network then follow standard IGMP and MLD protocol behavior as follows:

  • The BL device that receives the IGMP or MLD query tags the incoming interface as the multicast router (mrouter) port, and advertises that role to the other EVPN devices in the network.

  • The devices in the EVPN network route multicast traffic to the mrouter port to reach any external receivers.

A problem arises if the external multicast router load-balances the IGMP or MLD query to a BL device that is elected as a non-designated forwarder (NDF) among its multihoming peers. In that case, that NDF BL device doesn't forward the multicast traffic, so sometimes the external subscribers don't receive the traffic.

Previously, the only solution to prevent traffic loss in the above scenario is to explicitly configure the mrouter port setting for the interface on each peer BL device connected to the external multicast router. To explicitly configure an mrouter port, set the multicast-router-interface statement at the [edit protocols igmp-snooping interface name] hierarchy level for IGMP traffic, or set the same statement at the [edit protocols mld-snooping interface name] hierarchy level for MLD traffic.

However, by default on supported platforms, the peer BL devices use EVPN routes to automatically synchronize the mrouter port status for the ESIs the peer devices share. This feature ensures that multicast traffic can still reach external receivers when an NDF BL device receives the IGMP or MLD queries from the external multicast domain, without explicitly configuring the mrouter ports.

Note:

This mrouter port synchronization method is not based on an industry standard, so this feature works only in EVPN networks where the peer BLs are Junos devices that support this behavior. BL devices with this feature can't interoperate with peer BL devices from other vendors.

See Feature Explorer for the platforms that support this default behavior.

Benefits of Synchronizing Multicast Router Port Status by Default

  • External multicast receivers won't lose traffic when a non-designated forwarder (NDF) BL peer device receives IGMP or MLD queries from the external PIM router.

  • You don't need to manually configure a multicast router interface on the peer BL devices. The peer BL devices exchange that information automatically.

How the Multicast Router Port Synchronization Process Works

The multihoming peer BL devices use the EVPN Type 7 Join Sync route type for the mrouter port synchronization process. This feature re-purposes the EVPN Type 7 routes to communicate the mrouter port status among the ESI peers. Then all of the peers also tag their interfaces to the external multicast router as mrouter ports for the relevant multicast source and group.

The BL devices advertise their mrouter ports using EVPN Type 3 Inclusive Multicast Ethernet Tag (IMET) routes according to the usual EVPN multicast protocol control flow. Upon receiving the EVPN Type 3 routes, the EVPN devices with internal multicast sources learn how to reach the mrouter interfaces on the peer BL devices to successfully forward the multicast traffic.

How the Peer BL Devices use EVPN Type 7 Routes

When a multihoming peer BL device receives an IGMP or MLD query from the external multicast router, the BL device tags that link as an mrouter port. That BL device uses the EVPN Type 7 route network layer reachability information (NLRI) to advertise to its peer BL devices that they should also tag their interfaces for the same ESI as mrouter ports. The advertisement for a particular ESI for this purpose includes the following information:

  • The EVPN Type 7 route multicast source address and group address fields set to 0.0.0.0 (wildcard match [*,*]), which signals the advertisement is for synchronizing the multicast router port information for the ESI.

  • An EVPN instance (EVI) route target (RT) extended community (EVI-RT Extended Community) with the ESI to ensure the advertisement only reaches the relevant peer BL devices with the same ESI.

The peer BL devices also adjust their mrouter port statuses if needed if the BL device that received the IGMP (or MLD) query is the NDF but needs to withdraw the EVPN Type 7 route, such as when:

  • The BL device has a query timeout because the external multicast router stops serving in that role and stops sending IGMP or MLD queries. In this case:

    • The BL untags its mrouter port.

    • The peer BL devices also untag their corresponding mrouter ports.

  • The ESI link on the BL device goes down. In this case:

    • The BL device withdraws the EVPN Type 7 route, untags its mrouter port for the ESI, and also withdraws its EVPN Type 1 Ethernet A-D Route.

    • The peer BL devices don't untag their corresponding mrouter ports, so multicast traffic can still reach the external receivers.

How Multicast Traffic Successfully Reaches External Receivers

The process to tag an mrouter port, synchronize the mrouter port status for an ESI, and forward corresponding multicast traffic works as follows:

  1. The BL device that receives the IGMP or MLD query from the external multicast router marks its interface on the external multicast link as the mrouter port for the ESI.

  2. The BL device with the mrouter port clears the IGMP proxy (or MLD proxy) bit in the multicast flags extended community in its EVPN Type 3 routes, as usual for EVPN multicast protocol handling. Then that BL device advertises the EVPN Type 3 routes to the other EVPN leaf devices in the network.

    Note:

    A device with an mrouter port does not act as an IGMP (or MLD) proxy. Instead, the device acts as the upstream router that receives IGMP reports from an IGMP proxy and normally would forward the multicast traffic accordingly. That's why the device clears the proxy bits in the EVPN Type 3 route NLRI.

  3. The other EVPN leaf devices learn how to reach a BL device with an mrouter port upon receiving the EVPN Type 3 routes.

  4. When a multicast source behind one of the leaf devices sends traffic to that leaf device, the leaf device forwards the traffic to the BL device with the mrouter port.

  5. Normally, the other multihoming peer BL devices that didn't receive the IGMP or MLD query would not tag an mrouter port on the device. Instead, the other peer BL devices would set the IGMP proxy (or MLD proxy) bit in the multicast flags extended community in the EVPN Type 3 routes they advertise, and act as an IGMP proxy or MLD proxy.

  6. If the multihoming peer BL device with the mrouter port was not elected as the DF for the ESI and receives multicast traffic to forward to the external multicast router, that device normally wouldn't forward the traffic.

  7. However, with mrouter port synchronization, upon receiving an EVPN Type 7 advertisement for the shared ESI (see How the Peer BL Devices use EVPN Type 7 Routes), the other peer BL devices synchronize the mrouter status from the BL device that sent the EVPN Type 7 route. The peer BL devices:

    • Tag their mrouter port for the ESI.

    • Clear the IGMP proxy (or MLD proxy) bit in the EVPN Type 3 routes they advertise to all of the EVPN leaf devices in the network.

  8. One of the other peer BL devices is the DF for the ESI; that DF forwards the traffic on its mrouter port link toward the external receivers that subscribed to the traffic.

Supported Multicast Protocols and EVPN-VXLAN Environments

We support default mrouter port synchronization with:

  • IGMPv2, IGMPv3, and IGMP snooping for IPv4 multicast data traffic

  • MLDv1, MLDv2, and MLD snooping for IPv6 multicast data traffic

  • Selective Multicast Ethernet Tag (SMET) forwarding

  • EVPN-VXLAN networks with an IPv4 underlay or an IPv6 underlay

Related Documentation