Brocade Communications Systems FastIron SX 800 Configuration Manual page 584

Layer 3 behavior with MCT
• P2 due to its *,G state originates a join towards RP. This join is flooded on the MCT VLAN and R1 creates *,G state.
• P1 on receiving this join natively via ICL creates *,G state and adds ICL as OIF. Note that as a special case P1 will not include
the *,G in the join it generates towards RP as in this case the IIF is CCEP and ICL is the only OIF and the remote CCEP is up.
This is to avoid P1 pulling traffic from P2 unnecessarily on the ICL link because of P1 sending joins flooded on the VLAN and
in turn P2 adds ICL as an OIF.
• R1 sends the join toward RP and pulls the traffic. Because the OIF at R1 is LAG, traffic pulled by R1 will be load-shared among
the member links.
• Thus traffic for S,G will reach only one of the MCT peers. Assuming the traffic reaches P2, (S,G) state will be created on P2 and
P2 will be forwarding the traffic.
• Assuming the traffic reaches P1 the traffic will be forwarded via ICL to P2 and P2 will forward it to its OIFs which is the link
connecting to the core.
Load sharing of multicast traffic by MCT-cluster on CCEP links
MCT peers load-share multicast traffic on both the local and the remote CCEP links when both are available.
Loads are only shared, and may or may not be balanced, across the CCEP links. An MCT peer selects a stream for forwarding based on
a software hash function that uses the source and group addresses. That means you can have one MCT peer forwarding more multicast
streams than another.
The load is assigned without regard to the capacity of the CCEP links, so the feature works best when both CCEP links have the same
capacity and the source and group addresses are evenly distributed. That situation avoids the timing synchronization between the MCT
peer routers, which would be very hard to achieve.
The sharing is done at a stream, not packet, level ,using the following software hash algorithm:
((source address + group address) & 0x00000001) ^ ((local_bridge_id > remote_bridge_id))
If result is 1, local CCEP forwards the traffic; if result is 0, remote CCEP forwards the traffic
Fast convergence of multicast traffic
The multicast routing on MCT feature provides sub-second convergence of traffic in the event of CCEP or MCT peer failures and
recoveries.
When a CCEP or MCT peer fails, multicast traffic that used to go through the failed CCEP link or node switches to the surviving CCEP
link in approximately one second or less.
Sub-second convergence requires both MCT peers to maintain state for, and pull down, traffic for all multicast flows from the core,
regardless of whether the chassis is forwarding this stream out of the local CCEP. This means that streams forwarded by the remote
CCEP are pulled down to the local MCT peer but dropped in the absence of other receivers on the local router, thus potentially wasting
the bandwidth inside the core on uplink. This is deemed a fair tradeoff because otherwise the MCT peer that takes over the job of
forwarding a stream when the remote CCEP or peer fails, must establish a new multicast path through the core, which can potentially
black out the stream for many seconds
Requirements for multicast MCT
OSPF must be supported on MCT member VLAN virtual Ethernet (VE) interfaces, that is, on CCEP, CEP, and ICL links.
584
FastIron Ethernet Switch Layer 3 Routing
53-1003627-04