IP multicast routing support with Split MultiLink Trunking (SMLT) builds a virtual switch that represents the two switches of the split multilink trunk core.
When switches use PIM in the core, they need to exchange protocol-related updates as part of the interswitch trunking (IST) protocol. IST hides the fact that the edge switch attaches to two physical switches.
PIM-SMLT can work in triangular, square, and full mesh configurations with Layer 3 IP multicast. However, PIM-SSM in square or full mesh SMLT topologies is not supported.
The following rules apply:
If a VLAN receives traffic from the IST link, it cannot forward on the split multilink trunk link or the edge for the same VLAN.
If one side of the SMLT link toward the receiver is down, such that the traffic cannot be forwarded directly down the SMLT link from the router on which traffic is ingressing, the IST Peer MUST forward that traffic it receives over the IST link down its side of the SMLT toward the receiver. The decision of whether the IST Peer needs to forward traffic received over the IST to SMLT receivers is made in the datapath, which has full knowledge of the remote SMLT link state.
Traffic can use the IST to route between VLANs if the forwarding decision for the multicast protocol requires that the other side of the core forwards the multicast traffic (follow the IP multicast routing and forwarding rules for routed traffic). Other VLANs that are not part of SMLT continue to behave in the same way.
To create a temporary default route pointing to a peer IST, you must enable PIM on the IST VLAN.
In a scaled multicast environment, if you must reconfigure the members of an MLT link, either SMLT or IST, by removing the ports from the MLT membership list, you must first shutdown the port by using the shutdown command at the port configuration level. Let the unicast and multicast traffic subside, and then remove the port from the MLT membership list. If you reconfigure the MLT without first shutting down the port, it can lead to excessive hardware updates to multicast forwarding records and can result in high utilization of the CPU.
Note
In a scaled PIM over Simplified vIST deployment, disabling all the PIM interfaces (no ip routing) causes the VLACP ports to bounce. With no user intervention, the packets start getting processed again in approximately 10 seconds. VLACP enables the ports and full functionality is restored.
SMLT provides for fast failover in all cases, but does not provide a functionality similar to Routed SMLT (RSMLT).
Important
You must enable square SMLT globally before you configure square or full-mesh configurations.
If you restart peer SMLT switches, you can lose, or experience a delay in, PIM traffic. The local and remote SMLT links must be up to forward traffic. If a remote SMLT link is down, you can experience a traffic delay.
PIM uses a DR to forward data to receivers on a VLAN. If you restart the DR in an SMLT VLAN, you can lose data because of the following actions:
If the DR is down, the non-DR switch assumes the role and starts forwarding data.
After the DR comes back up, it takes priority (higher IP address) to forward data so the non-DR switch stops forwarding data.
The DR is not ready to forward traffic due to protocol convergence and because it takes time to learn the RP set and create the forwarding path. This situation can result in a traffic delay of 2 to 3 minutes because the DR learns the RP set after Open Shortest Path First (OSPF) converges.
A workaround to this delay is to a configure the static RP router on the peer SMLT switches. This feature avoids the process of selecting an active RP router from the list of candidate RPs and dynamically learning about RPs through the BSR mechanism. After the DR comes back up, traffic resumes as soon as OSPF converges. This workaround reduces the traffic delay to approximately 15 to 65 seconds.