Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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.

  • 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:

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.

One common configured element for OISM operation is the bridge domain (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.

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.

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. iGW11 and iGW12 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, iGW12, 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 iGW12 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.

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 references for some DCI stitching configuration examples:

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] 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:

Show Commands to Verify DCI with Enhanced OISM

We provide the following show commands in the CLI to verify DCI with enhanced OISM is enabled, and the iGW devices are transferring multicast traffic across the interconnection:

  1. show multicast next-hops session <identifier session-id>—Display EVPN multicast next hop session information for DF status on 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:

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

    For example:

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

    For example:

  4. show evpn oism dci <l3-context l3-vrf-name> <extensive>—Display DCI information when DCI is enabled with enhanced OISM.

    For example:

  5. show evpn oism <l3-context l3-vrf-name> <extensive>—Display device OISM status, including whether the device has DCI status Enabled, which 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:

  6. show evpn l3-context l3-vrf-name extensive—Display information about an L3 VRF for an EVPN instance that includes the configured multicast mode (if any). EVPN Multicast Routing mode output field value is Enhanced OISM for enhanced OISM mode.

    For example:

  7. show multicast route <extensive>—Display includes details about DCI DF and NDF multicast next-hop unilist entries.

    For example: