Multicast Optimization Design and Implementation
Juniper Networks supports the multicast optimization features discussed in this section in both centrally-routed bridging (CRB) and edge-routed bridging (ERB) overlays.
This design assumes that an EVPN-VXLAN ERB overlay is already running for IPv4 unicast traffic. (See Edge-Routed Bridging Overlay Design and Implementation for information about configuring edge-routed bridging.) However, the multicast optimization features uses a centrally routed approach.
Starting in Junos OS and Junos OS Evolved Release 22.2R2, we recommend deploying the optimized intersubnet multicast (OISM) solution for ERB overlay unicast EVPN-VXLAN networks that include multicast traffic. OISM combines the best aspects of ERB and CRB overlay designs together to provide the most efficient multicast traffic flow in ERB overlay fabrics.
We describe the OISM configuration that we validated in our ERB overlay reference architecture here:
This section shows how to add centrally-routed multicast optimizations to the edge-routed bridging topology shown in Figure 1.
Multicast is configured as follows:
Server leaf devices are set up in AR leaf role and for IGMP snooping.
Spine devices are set up in AR replicator role.
Border leaf devices are set up for multicast routing.
If your multicast environment requires assisted replication to handle large multicast flows and multicast routing, we recommend any of the QFX10000 line of switches for the border leaf and border spine roles. However, note that the QFX10002-60C switch supports multicast at a lower scale than the QFX10002-36Q/72Q switches. Also, we do not recommend any of the MX Series routers included in this reference design as a border leaf in a multicast environment with large multicast flows.
For an overview of multicast optimizations, see the Multicast Optimization section in Data Center Fabric Blueprint Architecture Components.
The following sections show how to configure and verify multicast assisted replication:
Configuring the Server Leaf
We are configuring AR and IGMP snooping on the server leaf. When IGMP snooping is enabled on a device, SMET is also enabled on the device by default.
Configuring the Spine
We are configuring the spine as AR replicator device.
Configuring the Border Leaf
This section describes how to set up multicast routing on the border leafs.
We do not configure AR on the border leafs. In this network design, the two border leafs share a multihomed ESI, and one of the border leaf devices supports AR but the other does not. In this situation, we do not recommend configuring AR on the border leaf that supports this feature. However, if your network includes two border leafs that share a multihomed ESI, and both border leaf devices support AR, we support the configuration of AR on both border leafs.
Verifying Assisted Replication on the Server Leaf
The server leaf is in the role of AR leaf device. This means that it does not perform ingress replication. Instead, it forwards one copy of multicast traffic to the spine, which is configured as the AR replicator device.
Verifying Assisted Replication on the Spine
user@spine> show route table bgp.evpn.0 match-prefix 3:*100001*192.168.0.* extensive | match "3:192.168.0.|LEAF"| except "PMSI|Path"
3:192.168.0.1:10000::100001::192.168.0.1/248 IM (1 entry, 1 announced)
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.1 AR-LEAF ## Leaf 1
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.1 AR-LEAF
3:192.168.0.2:10::100001::192.168.0.2/248 IM (1 entry, 1 announced)
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.2 AR-LEAF ## Leaf 2
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.2 AR-LEAF
3:192.168.0.3:10000::100001::192.168.0.3/248 IM (1 entry, 1 announced)
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.3 AR-LEAF ## Leaf 3
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.3 AR-LEAF
3:192.168.0.4:10000::100001::192.168.0.4/248 IM (2 entries, 1 announced)
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.4 AR-LEAF ## Leaf 4
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.4 AR-LEAF
3:192.168.0.10:10000::100001::192.168.0.10/248 IM (1 entry, 1 announced) ## Border Leaf 1
3:192.168.0.11:10000::100001::192.168.0.11/248 IM (1 entry, 1 announced) ## Border Leaf 2
user@spine> show route table bgp.evpn.0 match-prefix 3:*100001*192.168.0.1 extensive
bgp.evpn.0: 362179 destinations, 504791 routes (347873 active, 14306 holddown, 0 hidden)
3:192.168.0.1:10000::100001::192.168.0.1/248 IM (1 entry, 1 announced)
TSI:
Page 0 idx 0, (group overlay-bgp-rr type Internal) Type 1 val 0x1af46804 (adv_entry)
Advertised metrics:
Nexthop: 192.168.0.1
Localpref: 100
AS path: [4210000001] I
Communities: target:32897:268535457 encapsulation:vxlan(0x8) evpn-mcast-flags:0x1:snooping-enabled
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.1 AR-LEAF
Cluster ID: 192.168.2.10
Originator ID: 192.168.0.1
Page 0 idx 1, (group overlay-bgp type Internal) Type 1 val 0x1af46510 (adv_entry)
Advertised metrics:
Nexthop: 192.168.0.1
Localpref: 100
AS path: [4210000001] I
Communities: target:32897:268535457 encapsulation:vxlan(0x8) evpn-mcast-flags:0x1:snooping-enabled
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.1 AR-LEAF
Cluster ID: 192.168.2.10
Originator ID: 192.168.0.1
Advertise: 0000001e
Path 3:192.168.0.1:10000::100001::192.168.0.1
from 192.168.0.1
Vector len 4. Val: 0 1
*BGP Preference: 170/-101
Route Distinguisher: 192.168.0.1:10000
PMSI: Flags 0x10: Label 6250: Type INGRESS-REPLICATION 192.168.0.1 AR-LEAF
Next hop type: Indirect, Next hop index: 0
Address: 0x11bd0d90
Next-hop reference count: 35023
Source: 192.168.0.1
Protocol next hop: 192.168.0.1
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 4210000001 Peer AS: 4210000001
Age: 18:34:04 Metric2: 0
Validation State: unverified
Task: BGP_4210000001.192.168.0.1
Announcement bits (1): 1-BGP_RT_Background
AS path: I
Communities: target:32897:268535457 encapsulation:vxlan(0x8) evpn-mcast-flags:0x1:snooping-enabled
Import Accepted
Localpref: 100
Router ID: 192.168.0.1
Secondary Tables: default-switch.evpn.0
Indirect next hops: 1
Protocol next hop: 192.168.0.1
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 172.16.101.1 via ae1.0
Session Id: 0x0
192.168.0.1/32 Originating RIB: inet.0
Node path count: 1
Forwarding nexthops: 1
Nexthop: 172.16.101.1 via ae1.0
Session Id: 0
Multicast Optimization with a Centrally Routed Multicast Design— Feature Summary
Table 1 provides a history of the features described in this section and their support within this reference design.
Hardware |
IGMPv2 Snooping |
EVPN Type 6 SMET Routes |
Inter-VNI Multicast with PIM Gateway |
Assisted Replication |
PIM to External Rendezvous Point (From Border) |
|---|---|---|---|---|---|
QFX51001 |
Not supported |
Not supported |
Not supported |
Not supported |
Not supported |
QFX5110-32Q, QFX5110-48S |
18.1R3-S3 |
18.4R2 |
Not supported |
Not supported |
Not supported |
QFX5120-48Y |
18.4R2 |
18.4R2 |
Not supported |
Not supported |
Not supported |
QFX5120-32C |
19.1R2 |
19.1R2 |
Not supported |
Not supported |
Not supported |
QFX5200-32C1, QFX5200-48Y1 |
Not supported |
Not supported |
Not supported |
Not supported |
Not supported |
QFX10002-36Q/72Q, QFX10008, QFX10016 |
18.1R3-S3 |
18.4R2 |
18.1R3-S3 |
18.4R2 |
17.3R3-S1 |
QFX10002-60C2 |
20.2R2 |
20.2R2 |
20.2R2 |
20.2R2 |
20.2R2 |
MX204; MX240, MX480, MX960 with MPC7E; MX10003; |
Not supported |
Not supported |
Not supported |
Not supported |
Not supported |
1Make sure that IGMP snooping is not enabled on these QFX switches. If IGMP snooping is inadvertently enabled, these switches might process EVPN Type 6 routes that are reflected to them.
2The QFX10002-60C switch supports multicast at a lower scale than the QFX10002-36Q/72Q switches.