Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN-VXLAN DCI Multicast with Enhanced OISM

Transfer IPv4 or IPv6 multicast traffic efficiently and seamlessly across EVPN-VXLAN to EVPN-VXLAN interconnected data centers using enhanced OISM.

We support efficient transfer of IPv4 or IPv6 multicast traffic with Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) to EVPN-VXLAN seamless data center interconnect (DCI) stitching using enhanced optimized intersubnet multicast (OISM). The EVPN-VXLAN fabrics on both sides of the interconnection can use either IPv4 underlay peering or IPv6 underlay peering.

Without this feature, the DCI gateway (iGW) devices in each data center flood multicast traffic across the WAN. Flooding consumes significant WAN bandwidth if your network has many multicast flows or high multicast traffic rates. This feature seamlessly replaces the multicast flooding behavior in DCI stitched networks to optimize multicast forwarding across the DCI.

Benefits of DCI Multicast with Enhanced OISM

  • Significantly reduces network bandwidth consumption when transferring multicast traffic across the WAN interconnecting data centers, especially if your network has a large number of multicast flows or high multicast traffic rates.

  • Prevents traffic loss when the designated forwarder (DF) and non-DF (NDF) status changes among the multihomed iGW devices that share an interconnect Ethernet segment (I-ESI) in a data center.

EVPN-VXLAN to EVPN-VXLAN DCI Stitching Overview

DCI stitching seamlessly transfers control and data traffic in EVPN-VXLAN data centers across an interconnecting WAN. See Figure 1. DCI gateway (iGW) devices in each data center use different route targets (RTs) for:

  • Traffic inside the data center (DC-1 RT, DC-2 RT).

  • Traffic exchanged across the WAN (WAN RT).

Figure 1: EVPN-VXLAN to EVPN-VXLAN DCI Stitching Design Overview Network architecture diagram showing EVPN-VXLAN connecting two data centers over a WAN. Features spine-leaf topology, interconnect gateways, and IP Fabric cloud for seamless connectivity.

To configure iGW devices, you use the interconnect stanza at the [edit <routing-instances routing-instance-name> protocols evpn] hierarchy level. Also see the following for some DCI configuration examples:

OISM Overview

OISM handles multicast traffic efficiently in an EVPN-VXLAN data center for multicast sources and receivers inside and outside the data center.

OISM has two modes:

  • Regular OISM mode—This mode uses a symmetric bridge domains OISM model that requires you to configure all revenue VLANs (the tenant VLANs) in the network on all OISM leaf devices. This is the original OISM implementation.

  • Enhanced OISM mode—This mode doesn't require you to configure all revenue bridge domains (VLANs) in the network on all OISM devices. On each device, you can configure only the revenue VLANs hosted by that device (so we call this an asymmetric model). However, you must still configure the revenue VLANs symmetrically on OISM devices that are multihoming peers.

Note:

We support this seamless optimized multicast over DCI feature with enhanced OISM only.

OISM operates on the server leaf and border leaf provider edge (PE) devices in EVPN-VXLAN edge-routed bridging (ERB) overlay data center architectures. If the topology includes a layer of transit spine devices, you don't configure OISM on those devices.

  • OISM server leaf devices host the multicast sources and receivers within the data center. The sources and receivers can be either directly connected or connected through intermediary customer edge (CE) devices.

  • OISM border leaf devices connect to external multicast domains to transfer multicast data into a data center from external sources and out of a data center to external receivers. Like server leaf devices, the border leaf devices might also host devices in the data center that are multicast sources or receivers.

See Optimized Intersubnet Multicast in EVPN Networks for details on how OISM works in general. See these sections for more on the differences with enhanced OISM operation in particular:

OISM Configuration

In regular or enhanced mode, OISM requires many configuration elements to operate. You configure some elements in common on server leaf devices and border leaf devices. Some elements are specific to OISM server leaf devices or border leaf devices. See the configuration sections in Optimized Intersubnet Multicast in EVPN Networks for the steps to configure each type of OISM device. Many of the configuration steps are the same for either regular or enhanced OISM modes.

You can configure iGW devices to act as enhanced OISM server leaf or border leaf devices. If the iGW devices also provide the interfaces to external multicast sources or receivers, you configure them as OISM border leaf devices.

OISM Supplemental Bridge Domain (SBD)

One common configured element for OISM operation is the VLAN called the supplemental bridge domain (SBD). You configure a unique SBD VLAN ID and corresponding integrated routing and bridging (IRB) interface for each tenant virtual routing and forwarding (VRF) instance in a data center.

One major difference between regular OISM and enhanced OISM is that regular OISM ingress devices send multicast traffic from the source on the source VLAN to other OISM devices. In contrast, enhanced OISM ingress devices send source traffic on the source VLAN only to their multihoming peers, and use the SBD to send source traffic to all other OISM devices.

When you use enhanced OISM with DCI stitching, you assign the same VLAN as the SBD in both data centers for the VRF instances that span the interconnection. The iGW devices with enhanced OISM enabled transfer multicast control and data traffic across the interconnection only on the SBD.

Note:

Because enhanced OISM uses the SBD toward remote devices that aren't its multihoming peers, the enhanced mode has an inhernet limitation where packets with TTL=1 will not reach receivers on those remote devices.

If you use enhanced OISM with DCI stitching and need to avoid this limitation, we have a solution that enables enhanced OISM to behave like regular OISM to use the source VLAN for particular multicast data flows toward the remote OISM devices. You can enable this solution for particular multicast groups (or groups and sources) using routing policies and the forward-on-source-bridge-domain configuration option. See Enhanced OISM Exception Policy to Forward on Source VLAN Instead of SBD for Packets with TTL=1 for details.

How Enhanced OISM Works over DCI Stitching

In a DCI stitching environment without enhanced OISM, the iGW devices default to flooding all multicast traffic across the interconnecting WAN. Flooding can consume significant WAN bandwidth when you have heavy multicast traffic loads.

This feature seamlessly replaces the multicast flooding behavior across the WAN with selective multicast Ethernet tag (SMET) forwarding between the data centers. SMET forwarding only sends multicast traffic across the interconnection when the other data center has receivers that explicitly subscribed to that multicast flow. EVPN Type 6 routes implement SMET in EVPN data centers.

You enable enhanced OISM on the leaf devices in each data center as either OISM server leaf devices or OISM border leaf devices. The DCI iGW devices can be either type of OISM leaf device. Often, the iGW devices are the devices in the EVPN-VXLAN fabric that also act as the OISM border leaf devices to connect to external sources or receivers.

Note:

In the figures in this section and the following sections showing DCI with enhanced OISM, the spine devices in the DCI architecture in Figure 1 act only as L3 transit devices in each data center. You don't configure OISM on the spine devices. As a result, to more clearly show how the multicast control and data traffic flows among the OISM leaf devices, we don't include the spine devices in these figures.

SMET (EVPN Type 6 Route) Control Flow Across DCI

Figure 2 shows the control flow for EVPN Type 6 routes in each data center and across the interconnection.

Figure 2: SMET EVPN Type 6 Routes Sent Across DCI for Subscribed Receivers Network architecture showing EVPN Type 6 routes interconnecting DC-1 and DC-2 over WAN using VXLAN. Control traffic flows across a Supplemental Bridge Domain.

The SMET control flow operates as follows:

  1. To subscribe to a multicast data flow, a receiver in DC-2, for example, sends an Internet Group Management Protocol (IGMP) report for IPv4 multicast flows, or sends a Multicast Listener Discovery (MLD) report for IPv6 multicast flows.

  2. The OISM leaf device that receives the IGMP or MLD report in DC-2, Leaf 21 in this case, creates a SMET route (EVPN Type 6 route) for that subscription. The SMET route uses the RT for DC-2.

  3. Leaf 21 advertises the route on the OISM SBD to all other OISM leaf devices in DC-2 (Leaf 22, Leaf 23, iGW 21, and iGW 22).

  4. The iGW devices configured as OISM leaf devices in DC-2 (iGW 21, and iGW 22) receive the SMET route on the SBD, seamlessly re-originate the SMET route using the WAN RT, and forward the SMET route on the OISM SBD across the DCI.

  5. The iGW devices on the other side of the DCI in DC-1 (iGW 11 and iGW 12) receive the SMET route with the WAN RT on the SBD. iGW 11 and iGW 12 seamlessly re-originate the SMET route using the RT for DC-1, and forward the SMET route to all other OISM leaf devices in DC-1.

  6. The OISM leaf devices in both data centers store the multicast subscriber information from the SMET routes in their multicast routing and forwarding tables.

Multicast Data Flow with SMET and Enhanced OISM Across DCI

Figure 3 shows that based on received SMET routes, the OISM leaf devices in each data center send multicast traffic from the source only to the remote receivers across the DCI who subscribed to that multicast flow.

Figure 3: Multicast Data Flow with Enhanced OISM and DCI Network architecture diagram showing multicast traffic flow between DC-1 and DC-2 via WAN. Key elements include source VLAN 100 and receiver VLAN 200, interconnect gateway devices, leaf switches, and bridge domains. Traffic paths are highlighted: green for Supplemental Bridge Domain, purple for VLAN 100, and red for VLAN 200.

In this case:

  1. The multicast source is in DC-1 on VLAN 100.

  2. A receiver in DC-2 on VLAN 200 subscribes to the multicast data from the source in DC-1.

  3. As we show in SMET (EVPN Type 6 Route) Control Flow Across DCI, the OISM leaf devices in both data centers, including iGW 11, iGW 12, and Leaf 11 in DC-1, receive SMET routes for that subscription.

  4. In DC-1, Leaf 11 receives multicast traffic from the source on VLAN 100. Leaf 11 knows from receiving the SMET routes that there is a receiver in DC-2, so Leaf 11 routes the multicast traffic to iGW 11 and iGW 12 on the SBD.

    Note:

    Although Figure 3 doesn't show local receivers on the other leaf devices in DC-1, Leaf 11 would also route the multicast traffic on the SBD to those devices if (and only if) those devices also have subscribed receivers.

  5. iGW 11 and iGW 12 also know from receiving the SMET routes that there is a receiver in DC-2. In this case, iGW 11 is the DF for the pair of iGW devices in DC-1. So iGW 11 forwards the traffic over the interconnection to DC-2 on the SBD.

  6. The iGW devices in DC-2 receive the multicast traffic. In this case, iGW 21 is the DF for the pair of iGW devices in DC-2, so iGW 21 forwards the traffic on the SBD to Leaf 21 toward the subscribed receiver.

  7. In DC-2, Leaf 21 routes the multicast traffic toward the receiver on the receiver VLAN, VLAN 200.

See Multicast Next Hops Convergence Optimization for more on how we improve EVPN multicast next hop convergence over the DCI when iGW device DF and NDF status changes.

More Enhanced OISM over DCI Use Cases

We support a variety of configurations for DCI multicast with enhanced OISM.

For example, the multicast source can be:

  • Behind an OISM server leaf device in one of the data centers.

    Multicast Data Flow with SMET and Enhanced OISM Across DCI describes a use case with an internal source behind an OISM server leaf device in one data center to subscribed receivers behind OISM server leaf devices in another data center.

    Multicast Traffic Flow across DCI from Multihomed Source on DCI Gateway Devices describes a use case with an internal source that is multihomed to the iGW devices acting as OISM server leaf devices in one data center. The receivers are behind OISM leaf devices in both data centers.

  • In an external PIM domain connected to the iGW devices in one of the data centers.

    Multicast Traffic Flow from External Source to Internal Receivers describes a use case where the iGW devices also act as the OISM PIM EVPN gateway (PEG) devices. The receivers are inside both of the interconnected data centers.

  • In an external PIM domain connected to an OISM leaf device or multihomed to more than one OISM leaf device in one of the data centers.

    In this use case, you configure those leaf devices as the OISM border leaf PEG devices. We don't include a figure or describe this use case in detail here.

With a multicast source in one of the data centers, the multicast receivers can be:

We show some of these additional use cases in the next sections.

Multicast Traffic Flow across DCI from Multihomed Source on DCI Gateway Devices

Figure 4 shows a use case where the multicast source on VLAN 100 is multihomed to iGW 11 and iGW 12 in DC-1. You configure all of the leaf devices in this use case as OISM server leaf devices because all sources and receivers are inside the interconnected data centers.

Both of the interconnected data centers have internal subscribed receivers behind the following OISM server leaf devices:

  • In DC-1: Leaf 11, Leaf 13, and iGW 12

  • In DC-2: Leaf 21

The multihoming peer iGW devices in each data center elect a DF; the other iGW devices become NDFs (also called backup DFs [BDFs]). The DF forwards or routes multicast source traffic to the other OISM leaf devices. The NDF devices forward traffic only to the receivers that are local to their own device.

With enhanced OISM operation, if the multicast source is multihomed to a set of OISM leaf devices, the ingress PE device that receives the traffic from the source will:

  • Forward the traffic to its multihoming peers using the source VLAN.

  • Route the traffic on the SBD to all the other OISM leaf devices that are not its multihoming peers.

  • Use SMET to forward or route the traffic only to other OISM leaf devices with subscribed receivers.

Figure 4: Multihomed Multicast Source on DCI Gateways with Receiver across DCI Network architecture for multicast traffic flow between two data centers using Enhanced Optimized Inter-Site Multicast. Data centers DC-1 and DC-2 connected via WAN. Key components include iGW, CE, and Leaf switches. Multicast traffic originates from Source VLAN 100 in DC-1, sent to iGW devices. Enhanced OISM forwards traffic across WAN to DC-2 if subscribed. Traffic routed from SBD to Leaf switches and Receiver VLANs. Color-coded arrows indicate multicast traffic flow on SBD and VLANs.

In this use case:

  1. The multicast source is in DC-1 on VLAN 100, behind CE 12. CE 12 is multihomed to the two iGW devices in DC-1, iGW 11 and iGW 12.

  2. Receivers in both DC-1 and DC-2 on VLAN 200 subscribe to the multicast data from the source in DC-1. Receivers in DC-1 on VLAN 100 behind iGW 12 and behind Leaf 11 also subscribe to the multicast data.

  3. In DC-1, both iGW devices receive the multicast traffic from the source on VLAN 100. Both of the iGW devices in DC-1 know from receiving the SMET routes that there are receivers in DC-1 and remote receivers in DC-2. In this case, iGW 11 is the DF for the iGW devices in DC-1, so iGW 11:

    1. Routes the traffic on the SBD across the DCI toward DC-2.

    2. Forwards the traffic locally on the source VLAN to its multihoming peer, iGW 12.

    3. Routes the traffic locally on the SBD to the other (non-multihoming peer) OISM leaf devices in DC-1.

  4. In DC-1, the multihoming peer iGW device, iGW 12, forwards the traffic on the source VLAN to its local receiver. The other OISM leaf devices in DC-1 route the traffic from the SBD toward the receivers on the receiver VLANs (VLAN 100 and VLAN 200).

  5. In DC-2, the iGW devices receive the multicast traffic on the SBD. In this case, iGW 21 is the DF for the iGW devices in DC-2, so iGW 21 forwards the traffic on the SBD to Leaf 21 toward the subscribed receiver.

  6. In DC-2, Leaf 21 routes the multicast traffic toward the receiver on the receiver VLAN, VLAN 200.

See Multicast Next Hops Convergence Optimization for more on how we improve EVPN multicast next hop convergence over the DCI when DF and NDF status changes for the peer iGW devices in a data center.

Multicast Traffic Flow from External Source to Internal Receivers

Figure 5 shows a use case where the iGW devices in DC-1 also act as the OISM PEG devices to connect to a source in an external PIM domain.

The receivers in this use case are behind customer edge (CE) devices connected to the leaf devices inside each of the interconnected data centers.

Note:

For simplicity, we omit showing the receivers behind the CE devices here. The CE devices don't serve in an EVPN OISM leaf device role and you don't configure OISM on these devices.

For details on how OISM works with an external source and internal receivers, see Multicast Traffic from an External Source to Receivers Inside the EVPN Data Center—L3 Interface Method or Non-EVPN IRB Method.

You configure:

  • The iGW devices in DC-1 as OISM border leaf PEG devices.

  • The iGW devices in DC-2 as OISM server leaf devices.

  • The remaining leaf devices in both data centers as OISM server leaf devices.

We include a topology variation here with a receiver behind CE 12 in DC-1, where CE 12 is multihomed to OISM server leaf devices Leaf 12 and Leaf 13 for redundancy. These two leaf devices share an Ethernet segment identifier (ESI) for the multihomed receiver, and elect a DF for the ESI. In this case, Leaf 12 is the DF that forwards the multicast traffic destined for the receiver behind CE 12.

Figure 5: Multicast Traffic from External Source to Internal Receivers through OISM Border Leaf PEG Devices Network architecture diagram showing multicast traffic flow between two data centers via WAN. Key components include external source, PIM router, iGW devices in DC-1 and DC-2, leaf devices, and CE devices. Protocol roles like PIM DR, DF, and NDF manage traffic in the SBD. Traffic flows via green, purple, and red arrows on SBD, VLAN 100, and VLAN 200 respectively, demonstrating multicast distribution using PIM, SBD, and VLANs.

In this use case:

  1. Receivers in DC-1 and DC-2 on VLAN 100 and VLAN 200 subscribe to the multicast data from the external source.

  2. In DC-1, iGW 11 and iGW 12 receive the multicast traffic from the external source. Both of the iGWs in DC-1 know from receiving the SMET routes that there are receivers in DC-1 and remote receivers in DC-2. In this case, iGW 11 is the DF for the iGW devices in DC-1, so iGW 11:

    1. Routes the traffic on the SBD across the DCI to the iGW devices in DC-2.

    2. Routes the traffic locally on the SBD to the OISM leaf devices in DC-1 that are not its multihoming peers and have subscribed receivers—in this case, Leaf 11, Leaf 12 and Leaf 13.

  3. In DC-1, the OISM leaf devices route the traffic from the SBD toward the receivers on the receiver VLANs—VLAN 100 and VLAN 200. In this case, a receiver is behind CE 12, which is multihomed to Leaf 12 and Leaf 13. Leaf 12 is the DF and forwards the multicast traffic toward that receiver.

  4. In DC-2, the iGW devices receive the multicast traffic on the SBD. In this case, iGW 22 is the DF for the iGW devices in DC-2, so iGW 22 forwards the traffic on the SBD to Leaf 21 toward the subscribed receiver.

  5. In DC-2, Leaf 21 routes the multicast traffic from the SBD toward the receiver on the receiver VLAN, VLAN 200.

Multicast Control and Data Flow for Internal Source to External Receiver

Figure 6 shows a use case where the source is in DC-1. We have a receiver across the DCI in DC-2 and an external receiver. The iGW devices in DC-1 are the OISM PEG devices connecting to the receiver in an external PIM domain.

For details on how OISM works with an internal source and external receiver, see Multicast Traffic from an Internal Source to Receivers Outside the EVPN Data Center—L3 Interface Method or Non-EVPN IRB Method.

For details on how enhanced OISM ensures that the OISM PEG devices correctly perform PIM source registration for multicast sources inside an EVPN data center to an external PIM domain, see PIM Registration with Enhanced OISM for Internal Sources Based on EVPN Type 10 S-PMSI A-D Routes.

The multicast source and iGW devices in the OISM border leaf PEG role are in the same data center in this use case. However, with an external receiver, the multicast source might not be in the same data center as the OISM PEG devices that connect to the external receivers. The seamless enhanced OISM multicast over DCI implementation ensures that multicast source traffic from any of the interconnected data centers can reach external receivers wherever the OISM border leaf PEG devices are. As a result, Figure 6 also shows the following control flow:

  • The OISM PEG devices advertise their PEG role in the local data center and across the DCI to the other iGW devices.

  • The OISM PEG devices send these advertisements on the OISM SBD in the SMET EVPN Type 6 routes, and in Inclusive Multicast Ethernet Tag (IMET) routes, which are EVPN Type 3 routes.

In this use case, you configure:

  • The iGW devices in DC-1 as OISM border leaf PEG devices.

  • The iGW devices in DC-2 as OISM server leaf devices.

  • The remaining EVPN PE leaf devices in both data centers as OISM server leaf devices.

Figure 6: Multicast Traffic from Internal Source to External Receiver through OISM Border Leaf PEG Devices Network diagram of multicast traffic flow between two data centers via WAN, using PIM EVPN with iGW devices, leaf switches, and external receivers.

In this use case:

  1. The iGW devices in DC-1 connected to the external PIM domain advertise that they are OISM PEG devices using EVPN Type 3 and Type 6 routes. The PEG devices send these advertisements to all local OISM PE devices in DC-1 and across the DCI to the iGW devices in DC-2.

  2. A receiver in DC-2 on VLAN 200 and an external receiver subscribe to the multicast data from the source on VLAN 100 in DC-1.

  3. In DC-1, Leaf 11 receives multicast traffic from the source on VLAN 100. Leaf 11 knows from receiving EVPN Type 6 SMET routes that DC-2 has a receiver and there is an external receiver connected by way of the iGW devices in OISM PEG role. As a result, Leaf 11 routes the multicast traffic to iGW 11 and iGW 12 on the SBD.

  4. In DC-1, iGW 11 and iGW 12 receive the multicast traffic from Leaf 11 on the SBD. The iGW devices know from receiving EVPN Type 6 SMET routes that there are remote receivers in DC-2. The iGW devices also act as OISM border leaf PEG devices to the external receiver. In this case, Figure 6 shows that:

    1. iGW 11 is the DF for the iGW devices in DC-1, so iGW 11 forwards the multicast traffic on the SBD across the DCI to the iGW devices in DC-2.

    2. iGW 11 routes the multicast traffic toward the external receiver.

  5. In DC-2, the iGW devices receive the multicast traffic on the SBD. In this case, iGW 22 is the DF for the iGW devices in DC-2, so iGW 22 forwards the traffic on the SBD to Leaf 21 toward the subscribed receiver.

  6. In DC-2, Leaf 21 routes the multicast traffic from the SBD toward the receiver on the receiver VLAN, VLAN 200.

If DC-2 included a multicast data source, an external receiver connected to DC-1 might subscribe to that source data. In that case, the iGW devices in DC-2 receive the PEG role advertisements from the DC-1 iGW devices. The iGW devices in DC-2 would send multicast source traffic to an external receiver seamlessly using their interconnection to the DC-1 iGW devices acting as the OISM border leaf PEG devices.

Multicast Next Hops Convergence Optimization

When you interconnect EVPN data centers, we identify the peer multihomed iGW devices in each data center with a unique interconnect Ethernet segment ID (I-ESI). The peer iGW devices in each data center have a designated forwarder (DF) that forwards traffic across the interconnection and to the local receivers in the data center. The other iGW devices that are the NDF devices (sometimes called backup DF [BDF] devices) forward traffic only to receivers that are local to their own device.

The control plane on the iGW devices determines the multicast next hops for the DF and NDF iGW devices, and installs the next hops on the Packet Forwarding Engine (PFE) to efficiently forward traffic toward the destinations.

To improve multicast next hop information convergence in the PFE for EVPN multicast traffic over DCI, the iGW devices use a session model to track I-ESI DF and NDF status and multicast next hop information.

The control plane on the iGW devices:

  • Assigns a session ID to identify the DF and NDF device sessions.

  • Sends session status update messages to the PFE when the DF and NDF status for the I-ESI changes.

Upon receiving DF and NDF session status updates, the PFE on the iGW devices can quickly update the forwarding paths accordingly.

You can use the show multicast next-hops session command to see the DF and NDF session information for the I-ESI on iGW devices that you configure to support enhanced OISM traffic across the DCI.

Configure EVPN-VXLAN DCI with Enhanced OISM

To enable seamless multicast optimization with DCI and enhanced OISM, you configure many statements to set up EVPN-VXLAN, DCI, and enhanced OISM in each data center.

Keep in mind the following when planning an optimized DCI multicast environment:

  • We support enhanced OISM only in EVPN-VXLAN ERB overlay architectures.

  • If your environment includes external multicast sources or receivers, you configure EVPN devices in one of the data centers to act as the OISM border leaf PEG devices to connect to the external PIM domain. You can configure the iGW devices to also be the OISM PEG devices, or other OISM leaf devices in one of the data centers can be the OISM PEG devices.

This section provides a high-level overview of the different components you configure for multicast with enhanced OISM over DCI. We also include a simple sample configuration in Sample Configuration for DCI with Enhanced OISM, and corresponding verification show command outputs in Show Commands to Verify DCI with Enhanced OISM.

Configure EVPN-VXLAN in Each Data Center

Configure the EVPN-VXLAN networks in the data centers on both sides of the interconnection. See Configure DCI Gateway Devices across Data Centers for more on how to set up the data centers for DCI.

We support DCI and enhanced OISM with interconnected EVPN-VXLAN data centers that use IPv4 underlay peering or IPv6 underlay peering. You can transfer IPv4 multicast data or IPv6 multicast data across DCI with either type of underlay.

See the following references for how to configure an IPv6 underlay with EVPN-VXLAN:

Configure DCI Gateway Devices across Data Centers

You configure the iGW devices to interconnect the data centers the same way you would without configuring enhanced OISM.

See the interconnect configuration hierarchy, and the following reference for a DCI stitching configuration example:

Configure Enhanced OISM in Each Data Center

Configure enhanced OISM in the EVPN-VXLAN data center on each side of the DCI in one of the many different use cases on this page with multicast source and multicast receiver locations. Optimized Intersubnet Multicast in EVPN Networks has details on other supported OISM use cases in a data center.

Note the following about configuring enhanced OISM:

  • You enable enhanced OISM mode on all OISM devices using the enhanced-oism option at the [edit forwarding-options multicast-replication evpn irb (EVPN Multicast Replication)] hierarchy level. You use the enhanced-oism option instead of the regular OISM mode oism option at the same hierarchy level. The enhanced-oism and oism options are mutually exclusive. All EVPN PE devices in each data center must use enhanced OISM mode.

  • With enhanced OISM, you can configure each OISM device with only the VLANs that device hosts. You don't need to configure all VLANs in the EVPN network on all OISM devices like you do with regular OISM. The exception is multihoming peer OISM devices—on those devices, you must configure the OISM revenue VLANs symmetrically on all peers. This requirement applies to the peer DCI gateways in each data center when you configure them as OISM server leaf devices or OISM border leaf devices.

  • You must configure the OISM SBD with the same VLAN ID in the matching tenant virtual routing and forwarding (VRF) instances in the interconnected data centers.

OISM requires some common configuration statements on both OISM server leaf devices and OISM border leaf devices. You configure some statements only on the server leaf devices, and configure some statements only on the border leaf devices. See Optimized Intersubnet Multicast in EVPN Networks for details on understanding and configuring server leaf and border leaf OISM device roles and all elements for OISM to work (some options are platform-specific).

See the following sections in Optimized Intersubnet Multicast in EVPN Networks for configuration considerations, steps to configure each OISM device role, and CLI commands to verify OISM operation:

Sample Configuration for DCI with Enhanced OISM

The following sections show a simple sample configuration for DCI with enhanced OISM with two stitched data centers, DC-1 and DC-2, similar to the topologies in the use cases in Figure 3 through Figure 6.

The setup uses the following parameters:

  • Interconnect WAN

    • OSPF underlay peering

    • IBGP overlay peering for EVPN

  • DCI EVPN instance: evpn-vxlan-A

    • EBGP underlay and overlay peering

    • DC-1 EVPN instance RT—target:9:9

    • DC-2 EVPN instance RT—target:21:21

    • WAN (interconnect) RT—target:11:11

  • L3 VRF instance: VRF-1 (RT target:1:2)

  • OISM SBD VLAN: VLAN_4

  • OISM tenant VLANs: VLAN_2, VLAN_3, VLAN_5

    Note: Remember that with enhanced OISM, you must configure the same tenant VLANs on OISM multihoming peer PE devices. On all of the other OISM devices,you only need to configure the VLANs hosted by that device.
  • Multicast groups (IPv4): 233.252.0.1, 233.252.0.2

  • Multicast source IP address: 172.20.1.15

  • External multicast PIM RP static address: (IPv4) 172.30.7.7, (IPv6) 2001:0db8::172:30:7:7

Table 1: Sample Configuration Parameters

Device

Device Address

VRF-1 Router ID

AS #

EVPN Instance RD

VRF-1 RD

Interconnect RD

Tenant VLANs

WAN Router

192.168.50.50

n/a

65000

n/a

n/a

n/a

n/a

DC-1—AS 65111

ERB overlay with transit lean spine devices connecting the multihoming peer interconnect gateway devices iGW-11 and iGW-12 devices to eash other and to the other leaf devices:

  • Spine-1: 192.168.7.1, AS# 65107

  • Spine-2: 192.168.8.1, AS# 65108

Interconnect ESI for peer iGW devices iGW-11 and iGW-12—00:0a:0b:0c:0d:0a:0b:0c:0d:0a

iGW-11

192.168.1.1

192.168.1.2

65101

192.168.1.1:9

192.168.1.1:8

111:100

VLAN_2, VLAN_5

iGW-12

192.168.2.1

192.168.2.2

65102

192.168.1.1:9

192.168.2.1:8

112:100

VLAN_2, VLAN_5

Leaf-11

192.168.3.1

192.168.3.2

65103

192.168.3.1:9

192.168.3.1:8

n/a

VLAN_2, VLAN_5

Leaf-12

192.168.4.1

192.168.4.2

65104

192.168.4.1:9

192.168.4.1:8

n/a

VLAN_2, VLAN_5

Leaf-13

192.168.5.1

192.168.5.2

65105

192.168.5.1:9

192.168.5.1:8

n/a

VLAN_3, VLAN_5

DC-2—AS 65222

In this ERB overlay data center, Leaf-21, Leaf-22, Leaf-23 are directly connected to the multihoming peer interconnect gateway devices iGW-21 and iGW-22, without a transit lean spine layer.

Interconnect ESI for peer iGW devices iGW-21 and iGW-22—00:aa:bb:cc:dd:aa:bb:cc:dd:aa

iGW-21

192.168.21.1

192.168.21.2

65201

192.168.21.1:9

192.168.21.1:8

221:100

VLAN_3, VLAN_5

iGW-22

192.168.22.1

192.168.22.2

65202

192.168.22.1:9

192.168.22.1:8

222:100

VLAN_3, VLAN_5

Leaf-21

192.168.23.1

192.168.23.2

65203

192.168.23.1:9

192.168.23.1:8

n/a

VLAN_2, VLAN_5

Leaf-22

192.168.24.1

192.168.24.2

65204

192.168.24.1:9

192.168.24.1:8

n/a

VLAN_2, VLAN_5

Leaf-23

192.168.25.1

192.168.25.2

65205

192.168.25.1:9

192.168.25.1:8

n/a

VLAN_3, VLAN_5

We provide sample configurations for DCI seamless stitching and enhanced OISM on the following devices in the topology:

  • WAN router: Simple EVPN overlay for seamless stitching across DC-1 and DC-2

  • DC-1: Multihoming interconnect peers iGW-11 and iGW-12, and Leaf-11

  • DC-2: iGW-21 and Leaf-21

The configuration on the multihoming interconnect peer iGW-22 in DC-2 would be similar to the configuration on iGW-21. The same applies to the configurations for Leaf-12, Leaf-13, Leaf-22, and Leaf-23.

Related Platform-Specific Configuration Elements for EVPN-VXLAN Configurations

We require you to include the following statements in EVPN-VXLAN configurations with OISM or DCI on some platforms. Remember to add these statements to the indicated type of OISM device or DCI gateway device configuration on the stated platforms:

WAN Router EVPN Overlay Sample Configuration

DC-1: iGW-11 Sample Configuration

DC-1: iGW-12 Sample Configuration

DC-1: Leaf-11 Sample Configuration

DC-2: iGW-21 Sample Configuration

DC-2: Leaf-21 Sample Configuration

Show Commands to Verify DCI with Enhanced OISM

We provide show commands in the CLI to verify DCI with enhanced OISM is enabled, and the iGW devices are transferring multicast traffic across the interconnection. The following sample show command outputs display results from the configuration described in Sample Configuration for DCI with Enhanced OISM.

  1. show multicast next-hops session <identifier session-id>—Check the EVPN multicast next hop session information for DF status on the multihomed EVPN iGW devices that share an I-ESI. See Multicast Next Hops Convergence Optimization for more on how DCI with enhanced OISM uses a session model to optimize next hop convergence in the Packet Forwarding Engine when peer iGW device DF and NDF statuses change.

    For example, in our configuration, currently among the peer iGW devices in DC-1, iGW-11 is the DF and iGW-12 is the NDF. In DC-2, iGW-21 is the DF (so you can assume its peer iGW-22 is the NDF).

    iGW-11:

    iGW-12:

    iGW-21:

  2. show multicast next-hops list <identifier next-hop-id>—Check the multicast next hops unilist entries.

    For example, in our configuration:

    iGW-11:

    iGW-12:

    iGW-21

  3. show multicast snooping next-hops list <identifier next-hop-id>—Check the multicast snooping (L2 multicast forwarding) next hops unilist entries.

    For example, in our configuration:

    iGW-11:

    iGW-12:

    iGW-21

  4. show evpn oism dci <l3-context l3-vrf-name> <extensive>—Verify DCI is enabled with enhanced OISM, and check the multihoming peer I-ESI value and I-ESI DF or NDF status for DCI iGW peer devices.

    For example, in our configuration:

    iGW-11:

    iGW-12:

    Leaf-11:

    iGW-21:

    Leaf-21:

  5. show evpn oism <l3-context l3-vrf-name> <extensive>—Verify device OISM status, including that DC-1 and DC-2 have the same OISM SBD configured and both are in enhanced OISM mode. When the device has DCI status Enabled, that means the device is also an iGW device with enhanced OISM. Add the l3-context option to display information only for a specific L3 VRF. Otherwise, the command displays information for all OISM-enabled VRFs instances.

    For example, in our configuration:

    iGW-11:

    iGW-12:

    Leaf-11:

    iGW-21:

    Leaf-21:

  6. show evpn l3-context l3-vrf-name extensive—Verify information about an L3 VRF corresponding to an EVPN instance, including the configured multicast mode and RD associated with the L3 VRF. EVPN Multicast Routing mode output field value is Enhanced OISM for enhanced OISM mode. All PE devices in the EVPN instance in each data center must use enhanced OISM for this mode to work.

    For example, in our configuration:

    iGW-11:

    iGW-12:

    Leaf-11:

    iGW-21:

    Leaf-21:

  7. show multicast route <instance l3-vrf-name> <extensive>—Verify the multicast routes for the applicable multicast groups and sources, including the DCI DF upstream and downstream interfaces. The traffic flows from the source toward the network on the upstream interfaces, and from the network toward the receivers on the downstream interfaces. On iGW devices, the output also shows the DCI NDF upstream and downstream interfaces.

    Note:

    You can configure enhanced OISM to forward multicast traffic for particular flows on the source VLAN instead of the SBD to avoid time-to-live (TTL) expiration issues for TTL=1 packets. When you enable that behavior, this command displays the following in the Next-hop ID output field for a multicast route:

    • A multicast unilist next hop when the interface is a revenue VLAN IRB interface on an iGW device.

    • A normal multicast next hop otherwise.

    You configure that behavior using the forward-on-source-bridge-domain option. In the configuration we show here, we don't have forward-on-source-bridge-domain enabled.

    For example, in our configuration:

    iGW-11 (peer iGW-12 output is similar):

    Leaf-11:

    iGW-21:

    Leaf-21:

  8. show route table evpn-instance-table-name match-prefix 6:*...—Verify EVPN type 6 route control flow across the interconnect when a remote OISM leaf device receives an IGMP subscription to a multicast group (as Figure 2 illustrates). We show propagation of the EVPN Type 6 route from Leaf-21 through iGW-21 (and iGW-22) in DC-2, across the WAN to iGW-11 (and iGW-12) and reaching Leaf-11 in DC-1.

    1. Verify Leaf-21 in DC-2 (192.168.23.1) advertises an EVPN Type 6 route upon receiving an IGMP report from its host for multicast group 233.252.0.1 to the OISM PE devices in DC-2 (iGW-21, iGW-22, Leaf-22, and Leaf-23):

    2. Verify iGW-21 in DC-2 (192.168.21.1) receives the EVPN Type 6 routes from Leaf-21, and re-originates the advertisement with its interconnect RD (221:100) across the WAN (WAN router 192.168.50.50) toward DC-1:

    3. Verify iGW-11 in DC-1 (192.168.1.1) receives the EVPN type 6 route advertisement from the WAN (WAN router 192.168.50.50), and re-originates the advertisement with the DC-1 RD (192.168.1.1:9) toward the OISM PE devices in DC-1:

    4. Verify Leaf-11 in DC-1 (192.168.3.1) receives the EVPN Type 6 route(s) from the iGW devices in DC-1 (192.168.1.1, 192.168.2.1):

  9. show route table evpn-instance-table-name match-prefix 6:*0.0.0.0*...—Verify an OISM PEG device advertises its PEG role in EVPN type 6 route advertisements across the interconnection (as Figure 6 illustrates). The PEG device advertises the EVPN Type 6 route as a multicast route applicable for all multicast groups and multicast sources (*,*), so with this command we match on output for multicast group address 0.0.0.0 in addition to the device's route distinguisher.

    1. Verify iGW-11 in DC-1 (192.168.1.1) advertises its PEG role in DC-1 and across the WAN by originating EVPN Type 6 routes using its DC-1 RD (192.168.1.1:9) and its interconnect RD (111:100):

    2. Verify Leaf-11 in DC-1 (192.168.3.1) receives the EVPN Type 6 route with the PEG role advertisement from iGW-11 (192.168.1.1):

    3. Verify iGW-21 in DC-2 (192.168.21.1) receives the EVPN Type 6 route with the PEG role advertisement from the WAN, and re-originates the route with the DC-2 RD toward the OISM PE devices in DC-2:

    4. Verify Leaf-21 in DC-1 (192.168.23.1) receives EVPN Type 6 route with the PEG advertisement from iGW-21 (192.168.21.1):

  10. show evpn igmp-snooping proxy <extensive>—Verify IGMP snooping forwarding paths for the expected multicast groups, multicast sources, and VLANs (including the tenant VLANs 2, 3, and 5, and the SBD VLAN 4) are established across the DCI. For example, in our configuration:

    iGW-11:

    iGW-12:

    Leaf-11:

    iGW-21:

    Leaf-21:

  11. show evpn igmp-snooping proxy internal—Get internal details on multicast queues and operating modes for troubleshooting. For example, in our configuration:

    iGW-11 (output for peer iGW-12 and iGW-21 is similar):

    Leaf-11 (output for Leaf-21 is similar):

  12. show igmp snooping evpn status <detail>—Verify the configured EVPN OISM mode and role of each VLAN associated with the configured EVPN instance(s). For example, in our configuration, you can see that enhanced OISM over DCI is enabled on the iGW devices, and all devices in the EVPN network have VLAN_4 (VNI 4) configured as the OISM SBD. Also, iGW-11, iGW-12, Leaf-11, and Leaf-21 serve tenant VLANs VLAN_2 and VLAN_5, while iGW-21 and iGW-22 serve tenant VLANs VLAN_3 and VLAN_5.

    iGW-11 (output for peer iGW-12 is the same):

    Leaf-11:

    iGW-21:

    Leaf-21: