• P2 due to its *,G state originates a join towards RP. This join is ooded 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 trac from P2 unnecessarily on the ICL link because of P1 sending joins ooded on the VLAN and
in turn P2 adds ICL as an OIF.
• R1 sends the join toward RP and pulls the trac. Because the OIF at R1 is LAG, trac pulled by R1 will be load-shared among
the member links.
• Thus trac for S,G will reach only one of the MCT peers. Assuming the trac reaches P2, (S,G) state will be created on P2 and
P2 will be forwarding the trac.
• Assuming the trac reaches P1 the trac 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 trac by MCT-cluster on CCEP links
MCT peers load-share multicast
trac 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 trac; if result is 0, remote CCEP forwards the trac
Fast convergence of multicast trac
The multicast routing on MCT feature provides sub-second convergence of trac in the event of CCEP or MCT peer failures and
recoveries.
When a CCEP or MCT peer fails, multicast trac 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, trac for all multicast ows 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 tradeo 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.
Layer 3 behavior with MCT
FastIron Ethernet Switch Layer 3 Routing
584 53-1003627-04
To Next Page
Loading...
Need help?
General
