Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Assisted Replication Multicast Optimization in EVPN Networks

SUMMARY Assisted replication helps to optimize multicast traffic flow in EVPN networks by offloading traffic replication to devices that can more efficiently handle the task.

Assisted Replication in EVPN Networks

Assisted replication (AR) is a Layer 2 multicast traffic optimization feature supported in EVPN networks. With AR enabled, an ingress device replicates a multicast stream to another device in the EVPN network that can more efficiently handle replicating and forwarding the stream to the other devices in the network. For backward compatibility, ingress devices that don’t support AR operate transparently with other devices that have AR enabled, and use ingress replication to distribute the traffic themselves to other devices in the EVPN network.

AR provides an overlay multicast optimization Layer 2 solution, and does not require PIM to be enabled in the underlay.

Note:

This documentation describes AR functions in terms of multicast traffic replication and forwarding, but applies to any broadcast, unknown unicast, and multicast (BUM) traffic in general.

Benefits of Assisted Replication

  • In an EVPN network with a significant volume of broadcast, unknown unicast, and multicast (BUM) traffic, helps to optimize BUM traffic flow by passing replication and forwarding tasks to other devices that have more capacity to better handle the load.

  • In an EVPN-VXLAN environment, reduces the number of hardware next hops to multiple remote virtual tunnel endpoints (VTEPs) over traditional multicast ingress replication.

  • Can operate with other multicast optimizations such as IGMP snooping, MLD snooping, and selective multicast Ethernet tag (SMET) forwarding.

  • Operates transparently with devices that do not support AR for backward compatibility in existing EVPN networks.

AR Device Roles

Starting in Junos OS Releases 18.4R2 and 19.4R1, you can enable AR on QFX Series switches that support EVPN-VXLAN, which includes the QFX10000 line of switches and QFX5110 and QFX5120 switches.

To enable AR, you configure devices in the EVPN network into AR replicator and AR leaf roles. For backward compatibility, your EVPN network can also include devices that don’t support AR, which operate in a regular network virtualization edge (NVE) device role.

Table 1 summarizes these roles:

Table 1: AR Device Roles

Role

Description

AR leaf device

Device in an EVPN network that offloads multicast ingress replication tasks to another device in the EVPN network to handle the replication and forwarding load.

AR replicator device

Device in an EVPN network that helps perform multicast ingress replication and forwarding for traffic received from AR leaf devices on an AR overlay tunnel to other ingress replication overlay tunnels.

Regular NVE device

Device that does not support AR or is not configured into an AR role in an EVPN network, and replicates and forwards multicast traffic using the usual EVPN network ingress replication.

If you enable other supported multicast optimization features in your EVPN network such as IGMP snooping, MLD snooping, and SMET forwarding, AR replicator and AR leaf devices forward traffic in the EVPN core or on the access side only toward interested receivers.

Note:

With QFX Series AR devices in EVPN-VXLAN networks, AR replicator and AR leaf devices must operate in extended AR mode. In this mode, AR leaf devices that have multihomed Ethernet segments share some of the replication load with the AR replicator devices, which enables them to use split horizon and local bias rules to prevent traffic loops and duplicate forwarding. See Extended AR Mode for Multihomed Ethernet Segments. For details on how devices in an EVPN-VXLAN environment forward traffic to multihomed Ethernet segments using local bias and split horizon filtering, see EVPN-over-VXLAN Supported Functionality.

How AR Works

In general, devices in the EVPN network use ingress replication to distribute BUM traffic. The ingress device (the device where the source traffic enters the network) replicates and sends the traffic on overlay tunnels to all other devices in the network. For EVPN topologies with EVPN multihoming (ESI-LAGs), network devices employ local bias or designated forwarder (DF) rules to avoid duplicating forwarded traffic to receivers on multihomed Ethernet segments. With multicast optimizations like IGMP or MLD snooping and SMET forwarding enabled, forwarding devices avoid sending unnecessary traffic by replicating the traffic only to other devices that have active listeners.

AR operates within the existing EVPN network overlay and multicast forwarding mechanisms, but defines special AR overlay tunnels over which AR leaf devices pass traffic from multicast sources to AR replicator devices. AR replicator devices treat incoming source traffic on AR overlay tunnels as requests to replicate the traffic toward other devices in the EVPN network on behalf of the sending AR leaf device.

AR basically works like this:

  • Each AR replicator device advertises its replicator capabilities and AR IP address to the EVPN network using EVPN Type 3 (inclusive multicast Ethernet tag [IMET]) routes. You configure a secondary IP address on the lo0 loopback interface as an AR IP address when you assign the replicator role to the device. AR leaf devices use that IP address for the AR overlay tunnel.

  • An AR leaf device receives these advertisements to learn about available AR replicator devices and their capabilities.

  • AR leaf devices advertise EVPN Type 3 routes for ingress replication that include the AR leaf device ingress replication tunnel IP address.

  • The AR leaf device forwards multicast source traffic to a selected AR replicator on its AR overlay tunnel.

    When the network has multiple AR replicator devices, AR leaf devices automatically load-balance among them. (See AR Leaf Device Load Balancing With Multiple Replicators.)

  • The AR replicator device receives multicast source traffic from an AR leaf device on an AR overlay tunnel and replicates it to the other devices in the network using the established ingress replication overlay tunnels. It also forwards the traffic toward local receivers and external gateways, including those on multihomed Ethernet segments, using the same local bias or DF rules it would use for traffic received from directly connected sources or regular NVE devices.

    Note:

    When AR operates in extended AR mode, an AR leaf device with a multihomed source handles the replication to its EVPN multihoming peers, and the AR replicator device receiving source traffic from that AR leaf device skips forwarding to the multihomed peers. (See Extended AR Mode for Multihomed Ethernet Segments; Figure 5 illustrates this use case.)

Figure 1 shows an example of multicast traffic flow in an EVPN network with two AR replicators, four AR leaf devices, and a regular NVE device.

Figure 1: Assisted Replication Traffic FlowAssisted Replication Traffic Flow

In Figure 1, AR Leaf 4 forwards multicast source traffic on an AR overlay tunnel to Spine 1, one of the available AR replicators. Spine 1 receives the traffic on the AR tunnel and replicates it on the usual ingress replication overlay tunnels to all other devices in the EVPN network, including AR leaf devices, other AR replicators, and regular NVE devices. In this example, Spine 1 also forwards the traffic to its local receivers, and, applying local bias rules, forwards the traffic to its multihomed receiver regardless of whether or not it is the DF for that multihomed Ethernet segment. In addition, according to split horizon rules, AR replicator Spine 1 does not forward the traffic to AR Leaf 4. Instead, AR Leaf 4, the ingress device, does local bias forwarding to its attached receiver.

When you enable IGMP snooping or MLD snooping, SMET forwarding is also enabled by default, and the AR replicator skips sending the traffic on ingress replication overlay tunnels to any devices that don’t have active listeners.

Figure 1 shows a simplified view of the control messages and traffic flow with IGMP snooping enabled:

  • Receivers attached to AR Leaf 1 (multhomed to AR Leaf 2), AR Leaf 4, and Regular NVE send IGMP join messages to express interest in receiving the multicast stream.

  • For IGMP snooping to work with EVPN multihoming and avoid duplicate traffic, multihomed peers AR Leaf 1 and AR Leaf 2 synchronize the IGMP state using EVPN Type 7 and 8 (Join Sync and Leave Sync) routes. (Spine 1 and Spine 2 do the same for their multihomed receiver, athough the figure doesn’t show that specifically.)

  • The EVPN devices hosting receivers (and only the DF for multihomed receivers) advertise EVPN Type 6 routes in the EVPN core (see Overview of Selective Multicast Forwarding), so forwarding devices only send the traffic to the other EVPN devices with interested receivers.

For IPv6 multicast traffic with MLD and MLD snooping enabled, you’ll see the same behavior as illustrated for IGMP snooping.

Regular NVE devices and other AR replicator devices don’t send source traffic on AR overlay tunnels to an AR replicator device, and AR replicators don’t perform AR tasks when receiving multicast source traffic on regular ingress replication overlay tunnels. AR replicators forward traffic they did not receive on AR tunnels the way they normally would using EVPN network ingress replication.

Similarly, if an AR leaf device doesn’t see any available AR replicators, the AR leaf device defaults to using the usual ingress replication forwarding behavior (the same as a regular NVE device). In that case, AR show commands display the AR operational mode as No replicators/Ingress Replication. See the show evpn multicast-snooping assisted-replication replicators command for more details.

AR Route Advertisements

Devices in an EVPN network advertise EVPN Type 3 (IMET) routes for regular ingress replication and assisted replication.

AR replicator devices advertise EVPN Type 3 routes for regular ingress replication that include:

  • The AR replicator device ingress replication tunnel IP address

  • Tunnel type—IR

  • AR device role—AR-REPLICATOR

AR replicators also advertise EVPN Type 3 routes for the special AR overlay tunnels that include:

  • An AR IP address you configure on a loopback interface on the AR replicator device (see the replicator configuration statement)

  • Tunnel type—AR

  • AR device role—AR-REPLICATOR

  • EVPN multicast flags extended community with the Extended-MH-AR flag when operating in extended AR mode (see Extended AR Mode for Multihomed Ethernet Segments)

AR leaf devices advertise EVPN Type 3 routes for regular ingress replication that include:

  • The AR leaf device ingress replication tunnel IP address

  • Tunnel type—IR

  • AR device role—AR-LEAF

Regular NVE devices, which don’t support AR or are not configured as an AR leaf device, ignore AR route advertisements and forward multicast traffic using the usual EVPN network ingress replication rules.

Extended AR Mode for Multihomed Ethernet Segments

EVPN networks employ split horizon and local bias rules to enable multicast optimizations when the architecture includes multihomed Ethernet segments (see EVPN-over-VXLAN Supported Functionality). These methods include information about the ingress AR leaf device in forwarded packets to ensure that the traffic isn’t unnecessarily forwarded or looped back to the source by way of the ingress device’s multihomed peers.

Some devices serving in the AR replicator role can’t retain the source IP address or Ethernet segment identifier (ESI) label on behalf of the ingress AR leaf device when forwarding the traffic to other overlay tunnels. AR replicator devices with this limitation operate in extended AR mode, where the AR replicator forwards traffic toward other devices in the EVPN network with the AR replicator’s ingress replication IP address as the source IP address.

Note:

QFX Series AR devices in an EVPN-VXLAN environment use extended AR mode. We currently only support AR in VXLAN overlay architectures, so the only supported AR mode is extended AR mode.

AR replicators include the EVPN multicast flags extended community in the EVPN Type 3 AR route advertisement. The Extended-MH-AR flag indicates the AR operating mode.

When AR devices operate in extended AR mode:

  • Besides forwarding the traffic to the AR replicator device, an AR leaf device with multihomed sources also handles replicating the traffic to its multihoming peers.

  • An AR replicator device receiving source traffic from an AR leaf device with multihomed sources skips forwarding to the AR leaf device’s multihoming peers.

See Source Behind an AR Leaf Device (Multihomed Ethernet Segment) with Extended AR Mode, which shows the traffic flow in extended AR mode for an EVPN network with a multihomed source.

Extended AR mode behavior applies only when AR leaf devices have multihomed Ethernet segments with other AR leaf devices, not with AR replicators from which the AR leaf requests replication assistance. When AR replicator and AR leaf devices share multihomed Ethernet segments in environments that require extended AR mode, AR can’t work correctly, so ingress AR leaf devices don’t use the AR tunnels and default to using only ingress replication. In this case, AR show commands display the AR operational mode as Misconfiguration/Ingress Replication.

AR replicators that can retain the source IP address or ESI label of the ingress AR leaf device operate in regular AR mode.

See the show evpn multicast-snooping assisted-replication replicators command for more information on AR operational modes.

AR Leaf Device Load Balancing With Multiple Replicators

When the EVPN network has more than one advertised AR replicator device, the AR leaf devices automatically load-balance among the available AR replicator devices.

For QFX Series switches in an EVPN-VXLAN network:

  • AR leaf devices in the QFX5000 line of switches designate a particular AR replicator device for a VLAN or VXLAN network identifier (VNI) to load-balance among the available AR replicators.

  • AR leaf devices in the QFX10000 line of switches actively load-balance among the available AR replicators based on traffic flow levels within a VNI.

AR Limitations With IGMP or MLD Snooping

AR replicator devices with IGMP or MLD snooping enabled will silently drop multicast traffic toward AR Leaf devices that don’t support IGMP or MLD snooping in an EVPN-VXLAN environment.

If you want to include IGMP or MLD snooping multicast traffic optimization with AR, you can work around this limitation by disabling AR on the EVPN devices that don’t support IGMP ot MLD snooping so they don’t function as AR leaf devices. Those devices then behave like regular network virtualization edge (NVE) devices and can receive the multicast traffic by way of the usual EVPN network ingress replication, although without the benefits of AR and IGMP or MLD snooping optimizations. You can configure devices that do support IGMP or MLD snooping in this environment as AR leaf devices with IGMP or MLD snooping.

See Table 1 for more about the behavior differences between AR leaf devices and regular NVE devices.

Best Practice:

For best results in EVPN-VXLAN networks with a combination of leaf devices that don’t support IGMP or MLD snooping (such as QFX5100 switches) and leaf devices that do support IGMP or MLD snooping (such as QFX5110 switches), follow these recommendations based on the VTEP scaling you need:

  • VTEP scaling with 100 or more VTEPs: Enable AR for all supporting devices in the network, and don’t use IGMP or MLD snooping.

  • VTEP scaling with less than 100 VTEPs: Enable AR and IGMP snooping on the AR replicators and other AR leaf devices that support IGMP or MLD snooping, but disable AR on leaf devices that don’t support IGMP or MLD snooping (so those act as regular NVE devices and not as AR leaf devices).

Multicast Forwarding Use Cases in an EVPN Network with AR Devices

This section shows multicast traffic flow in several common use cases where the source is located behind different AR devices or regular NVE devices in an EVPN network.

Source Behind a Regular NVE Device

Figure 2 shows an EVPN network with multicast traffic from a source attached to Regular NVE, a device that doesn’t support AR.

Figure 2: Multicast Source Traffic Ingress at a Regular NVE DeviceMulticast Source Traffic Ingress at a Regular NVE Device

In this case, forwarding behavior is the same whether or not AR is enabled because the ingress device, Regular NVE, is not an AR leaf device sending traffic for replication to an AR replicator. Regular NVE employs the usual ingress replication forwarding rules as follows:

  • Without IGMP or MLD snooping and SMET forwarding enabled, Regular NVE floods the traffic to all the other devices in the EVPN network.

  • With IGMP or MLD snooping and SMET forwarding enabled, Regular NVE only forwards the traffic to other devices in the EVPN network with active listeners. In this case, Regular NVE forwards to all the other devices except AR Leaf 2 and AR Leaf 4.

Spine 1 and Spine 2 replicate and forward the traffic toward their local single-homed or multihomed receivers or external gateways using the usual EVPN network ingress replication local bias or DF behaviors. In this case, Figure 2 shows that Spine 2 is the elected DF and forwards the traffic to a multihomed receiver on an Ethernet segment that the two spine devices share.

Source Behind an AR Replicator Device

Figure 3 shows an EVPN network with multicast traffic from a source attached to an AR replicator device called Spine 1.

Figure 3: Multicast Source Traffic Ingress at an AR Replicator DeviceMulticast Source Traffic Ingress at an AR Replicator Device

In this case, forwarding behavior is the same whether or not AR is enabled because the ingress device, Spine 1, is not an AR leaf device sending traffic for replication to an AR replicator. Spine 1, although it’s configured as an AR replicator device, does not act as an AR replicator. Instead, it employs the usual ingress replication forwarding rules as follows:

  • Without IGMP or MLD snooping and SMET forwarding enabled, Spine 1, the ingress device, floods the traffic to all the other devices in the EVPN network.

  • With IGMP or MLD snooping and SMET forwarding enabled, Spine 1 only forwards the traffic to other devices in the EVPN network with active listeners. In this case, Spine 1 forwards to the other devices except AR Leaf 2 and AR Leaf 4, and to Spine 2, which has a local interested receiver.

  • Spine 1 also replicates the traffic toward local single-homed or multihomed receivers or external gateways using the usual EVPN network ingress replication local bias or DF behaviors. In this case, Spine 1 uses local bias and forwards the traffic to a multihomed receiver due to local bias rules (whether or not it is the DF on that Ethernet segment).

Spine 2 forwards the traffic received from Spine 1 to its local receiver, does a local bias check for its multihomed receiver, and skips forwarding to the multihomed receiver even though it is the DF for that Ethernet segment.

Source Behind an AR Leaf Device (Single-Homed Ethernet Segment)

Figure 4 shows an EVPN network with multicast traffic from a source attached to the AR leaf device called AR Leaf 4. Traffic flow is the same whether the ingress AR leaf device and AR replicator are operating in extended AR mode or not, because the source isn’t multihomed to any other leaf devices.

Figure 4: Source Traffic Ingress at an AR Leaf Device (Single-Homed Source)Source Traffic Ingress at an AR Leaf Device (Single-Homed Source)

Without IGMP or MLD snooping and SMET forwarding enabled:

  • AR Leaf 4 forwards one copy of the multicast traffic to an advertised AR replicator device, in this case Spine 1, using the AR overlay tunnel secondary IP address that you configured on the loopback interface lo0 for Spine 1.

  • AR Leaf 4 also applies local bias forwarding rules and replicates the multicast traffic to its locally attached receiver.

  • Spine 1 receives the multicast traffic on the AR overlay tunnel and replicates and forwards it on behalf of Leaf 4 using the usual ingress replication overlay tunnels to all the other devices in the EVPN network, including Spine 2. Spine 1 skips forwarding the traffic back to the ingress device AR Leaf 4 (according to split horizon rules).

With IGMP or MLD snooping and SMET forwarding enabled:

  • AR replicator Spine 1 further optimizes replication by only forwarding the traffic towards other devices in the EVPN network with active listeners. In this case, Spine 1 skips forwarding to AR Leaf 2.

Spine 1 also replicates and forwards the traffic to its local receivers and toward multihomed receivers or external gateways using the usual EVPN network ingress replication local bias or DF behaviors. In this case, Spine 1 forwards the traffic to a local receiver and uses local bias to forward to a multihomed receiver (although it is not the DF for that Ethernet segment).

Spine 2 forwards the traffic received from Spine 1 to its local receiver, does a local bias check for its multihomed receiver, and skips forwarding to the multihomed receiver even though it is the DF for that Ethernet segment.

Source Behind an AR Leaf Device (Multihomed Ethernet Segment) with Extended AR Mode

Figure 5 shows an EVPN network with multicast traffic from a source on a multihomed Ethernet segment operating in extended AR mode. The source is multihomed to three AR leaf devices and might send the traffic to any one of them. In this case, AR Leaf 1 is the ingress device.

Figure 5: Source Traffic Ingress at an AR Leaf Device (Multihomed Source)Source Traffic Ingress at an AR Leaf Device (Multihomed Source)

Without IGMP or MLD snooping and SMET forwarding enabled:

  • AR Leaf 1 forwards one copy of the multicast traffic to one of the advertised AR replicator devices, in this case, Spine 1, using the AR overlay tunnel secondary IP address that you configured on the loopback interface lo0 for Spine 1.

  • Operating in extended AR mode:

    • AR Leaf 1 also replicates and forwards the multicast traffic to all of its multihoming peers (AR Leaf 2 and AR Leaf 3) for the source Ethernet segment.

    • Spine 1 receives the multicast traffic on the AR overlay tunnel and replicates and forwards it using the usual ingress replication overlay tunnels to the other devices in the EVPN network except AR Leaf 1 and its multihoming peers AR Leaf 2 and AR Leaf 3.

With IGMP or MLD snooping and SMET forwarding enabled, the AR leaf and AR replicator devices further optimize multicast replication in extended AR mode as follows:

  • Besides sending to AR replicator Spine 1, AR Leaf 1 also replicates and forwards the multicast traffic only to its multihoming peers that have active listeners (AR Leaf 3).

  • Spine 1 replicates traffic for AR Leaf 1 only to other devices in the EVPN network with active listeners. In this case, that includes only the regular NVE device and Spine 2.

Spine 1 also replicates and forwards the traffic to its local receivers and toward multihomed receivers or external gateways using the usual EVPN network ingress replication local bias or DF behaviors. In this case, Spine 1 uses local bias to forward to a multihomed receiver although it is not the DF for that Ethernet segment. Spine 2 receives the traffic from Spine 1, forwards the traffic to its local receiver, does a local bias check for its multihomed receiver, and skips forwarding to the multihomed receiver even though it is the DF for that Ethernet segment.

Configure Assisted Replication

Assisted replication (AR) helps optimize multicast traffic flow in EVPN networks. To enable AR, you configure devices in the EVPN network to operate as AR replicator and AR leaf devices. Available AR replicator devices that are better able to handle the processing load help perform multicast traffic replication and forwarding tasks for AR leaf devices.

You don’t need to configure any options on AR replicator or AR leaf devices to accommodate devices that don't support AR, which we refer to as regular network virtualization edge (NVE) devices. Regular NVE devices use the usual EVPN network and overlay tunnel ingress replication independently of AR operation within the same EVPN network. AR replicator devices also don’t need to distinguish between AR leaf and regular NVE devices when forwarding multicast traffic, because AR replicator devices also use the existing ingress replication overlay tunnels for all destinations.

Configure an AR Replicator Device

Devices you configure as AR replicator devices advertise their AR capabilities and AR IP address to the EVPN network. The AR IP address is a loopback interface address you configure on the AR replicator device. AR leaf devices receive these advertisements to learn about available AR replicators to which they can offload multicast replication and forwarding tasks. AR leaf devices automatically load-balance among multiple available AR replicator devices.

To configure an AR replicator device:

  1. Configure the loopback interface lo0 with a secondary IP address specifically for AR functions. The AR replicator advertises this IP address to the network in the EVPN Type 3 AR tunnel routes. (See AR Route Advertisements for details.)
  2. Configure the AR replicator device using the loopback interface you configured in Step 1.
  3. Set the type of IP address the AR replicator uses as the ingress source address in the overlay tunnel encapsulation for the replicated traffic.
    Note:

    The default value for vxlan-encapsulation-source-ip is retain-incoming-source-ip. (See replicator.) With AR replicators that are not capable of retaining the source IP address, such as QFX Series devices in an EVPN-VXLAN network, the vxlan-encapsulation-source-ip statement is mandatory and must be set to the ingress-replication-ip option instead of the default value.

    When you set the ingress-replication-ip VXLAN encapsulation option, the AR replicator advertises that it is not capable of retaining the source IP address of the originating AR leaf device when replicating and forwarding the traffic to the regular ingress replication overlay tunnels. This means it supports only extended AR mode. (See Extended AR Mode for Multihomed Ethernet Segments.) Other AR devices in the EVPN network receive these advertisements and also use extended AR mode to operate compatibly.

    The retain-incoming-source-ip setting is reserved for future compatibility with EVPN network devices and overlays that are capable of retaining the incoming source IP address in replicated traffic.

Configure an AR Leaf Device

Devices you configure as AR leaf devices receive traffic from multicast sources and offload the replication and forwarding to an AR replicator device. AR replicator devices advertise their AR capabilities and AR IP address, and AR leaf devices automatically load-balance among the available AR replicators.

To configure an AR leaf device:

  1. Configure the device into the AR leaf role.
  2. (Optional) By default, AR leaf devices delay for 10 seconds after receiving an AR replicator advertisement before starting to send traffic to that AR replicator device. If needed, you can adjust the delay (in seconds) to make sure AR replicator devices have fully learned the current EVPN state from the network (such as after an AR replicator goes down and comes up again).

    For example, to change the delay to 30 seconds:

Verify Assisted Replication Setup and Operation

Several commands help verify that AR replicator devices have advertised their AR IP address and capabilities, and AR leaf devices have learned how to reach available AR replicator devices and EVPN multihoming peers to operate in extended AR mode.

  1. View AR information received from AR replicator EVPN Type 3 (IMET) route advertisements.

    This command displays the Type 3 routes for an EVPN instance to the available AR replicator devices (AR overlay tunnel next hops), including Type ASSISTED-REPLICATION and Role AR-REPLICATOR in the PMSI section of the output.

    The following (truncated) example shows the EVPN Type 3 route for an available AR replicator device with AR IP address 192.168.102.1 seen on an AR leaf device. The output also includes the advertised EVPN multicast extended community flags that show the AR operating mode is extended AR mode:

  2. Check the available AR replicators and AR mode in which they are operating.

    You can run this command on an AR leaf or AR replicator device. The output shows the available AR replicator devices, their AR operating mode, and the next hops and overlay tunnel interfaces used to reach each AR replicator device from the device where you run the command.

    For example:

  3. (Available when IGMP or MLD snooping is enabled) View AR leaf device overlay tunnel next hops to load-balance among the advertised AR replicator devices.

    The following sample command shows the load-balancing next hops toward the advertised AR replicators that the AR leaf device detected in Step 2.

    Also, when an AR leaf device load-balances by assigning an AR replicator device to each VLAN or VNI, this command tags that AR replicator as the (Designated Node) in the output (which the example below also shows). AR leaf devices that load-balance based on active traffic flow don’t display this tag. (See AR Leaf Device Load Balancing With Multiple Replicators.)

  4. (Available when IGMP or MLD snooping is enabled) View AR leaf device multhihomed peers. Include the extensive option to also see the multihomed ESs shared with peers.

    For example:

  5. (Available when IGMP or MLD snooping is enabled) View IGMP or MLD snooping core next hops on the AR replicator for each multicast group and VLAN or VNI, and follow those to corresponding AR load-balancing and multihoming peer device next hops. Use the following commands:

    For example, in the output from the following commands, you can see the Downstream interface Addr field for next-hop ID 131092 shows the following:

    • The load-balancing next-hop index 131091, which you also see with the show evpn multicast-snooping assisted-replication next-hops command in Step 3.

    • The multihoming peer device interface and next hop index vtep.32768-(1746), which you also see with the show evpn multicast-snooping assisted-replication next-hops command in Step 4.

Release History Table
Release
Description
18.4R2
Starting in Junos OS Releases 18.4R2 and 19.4R1, you can enable AR on QFX Series switches that support EVPN-VXLAN, which includes the QFX10000 line of switches and QFX5110 and QFX5120 switches.