Brocade Multi-Service IronWare Switching Configuration Guide (Supporting R05.6.00) - Manual (Page 704)

674 Multi-Service IronWare Switching Configuration Guide
53-1003036-02
MCT for VPLS
18
On Standby MCT PE Node
• Traffic received from CE’s is forwarded to all locally connected CE’s and to MCT Spoke PW
which is the only PE session which is active.
• Traffic received from the MCT Spoke PW is forwarded to all locally connected CE’s which are
single homed to this standby MCT PE node.
MAC Learning & Synching
CCEP endpoints can send traffic to either of the MCT switches. This causes MAC addresses to
move from CCEP port and the MCT Spoke PW continuously. To avoid MAC movement between the
CCEP port and MCT spoke, MAC learning is disabled on MCT spoke PW and MAC addresses are
synced between the two MCT peer switches using MAC database update protocol (MDUP).
MAC addresses learned are added to the MDUP database (MDB). MAC addresses learned locally
on the cluster node are added to the local MDB with a cost of zero. MAC addresses learned from
the peer cluster node are added to the remote MDB with a cost of one.
If a MAC address exists in both local and remote MDB, the MAC with the lowest cost is selected and
added to the forwarding database (FDB). Cluster local MACs are always given preference over
cluster remote MACs.
• On Active MCT PE Node MAC’s are learned from the packets received from both CE and PE’s
(except the MCT Spoke PW).
• On standby MCT PE node MAC’s are learned from packets received from CE’s. (No packets are
received from the remote PE’s).
• There is no learning of MAC’s for packets received on MCT Spoke PW. This is true on both
Active and standby PE Node.
• For all VPLS instance which have MCT based endpoints, the complete MAC tables are synched
between Master and Slave MCT peers.
MAC Aging
Cluster remote MDB entries are not aged locally. They are deleted only when an MDUP messages is
received from the cluster peer switch.
MAC entries are deleted from FDB only if the MAC entry is not present in both local and remote
MDBs.
Active-standby role change (revertible timer)
When a MCT node cannot establish a CCP connection with other MCT node, it will declare itself as
Active and start the Remote Peering.
When the CCP session is established the node which is already Active will have higher preference
over other MCT node if it is in Transit state.
MCT node which is configured to be Active will start the l2vpn reversion-timer to take over the
Active role (if it is in standby role).