Brocade Communications Systems FastIron SX 800 Configuration Manual page 582

Layer 3 behavior with MCT
• If it is not, the packet ingress port will be an ICL port.
In the following figures, P1 and P2 are MCT peers and R1 is the MCT client. P1, P2 and R1 are configured with PIM on the MCT VE
interface. MCT peers act as PIM intermediate routers with respect to R1.
MCT peer as intermediate Upstream router
P1 and P2 are the MCT peers and are acting as upstream routers for R1. R1 is the last-hop router (LHR).
P1, P2, and R1 are configured with PIM on the MCT virtual Ethernet (VE) interface. RP and source is in the core and the connectivity to
the core is via an uplink.
FIGURE 45 MCT peer as immediate Upstream router
Hello exchange and neighbor state:
• In MCT topology, the CCEP links going out of P1 and P2 to R1 are treated as a single LAG at R1. That means when R1 sends
multicast packets (either control or data packets), they reach only one of the peers. These control packets (hellos, joins, prunes,
and others) received by one peer are flooded on the MCT VLAN including the ICL port to the other peer.
• Hellos sent by R1 could reach either P1 or P2 due to the above nature of MCT LAG.
• Hellos that reach P2 are sent to P1 natively over ICL. That means P1 learns about R1 (by searching the source-MAC of the
hello packet in its MAC table) and it treats the hello as if it was received on its CCEP interface. Thus both P1 and P2 learn about
the PIM neighbors across the CCEP links and create neighbor state for R1.
• Hellos originated from P1 and P2 are flooded on the MCT VLAN i.e. on ICL, CEP, local CCEP ports. This enables R1 to learn
that both the MCT peers are PIM neighbors and also enables P1 and P2 to learn about each other as PIM neighbors on an ICL
link and create neighbor state, for each other.
582
FastIron Ethernet Switch Layer 3 Routing
53-1003627-04