Multichassis Lacp

Multichassis LACP
First Published: December 11, 2009

Last Updated: February 8, 2011
In Carrier Ethernet networks, various redundancy mechanisms provide resilient interconnection of nodes
and networks. The choice of redundancy mechanisms depends on various factors such as transport
technology, topology, single node versus entire network multihoming, capability of devices, autonomous
system (AS) boundaries or service provider operations model, and service provider preferences.
Carrier Ethernet network high-availability can be achieved by employing both intra- and interchassis
redundancy mechanisms. Cisco’s Multichassis EtherChannel (MCEC) solution addresses the need for
interchassis redundancy mechanisms, where a carrier wants to “dual home” a device to two upstream
points of attachment (PoAs) for redundancy. Some carriers either cannot or will not run loop prevention
control protocols in their access networks, making an alternative redundancy scheme necessary. MCEC
addresses this issue with enhancements to the 802.3ad Link Aggregation Control Protocol (LACP)
implementation. These enhancements are provided in the Multichassis LACP (mLACP) feature
described in this document.
Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature
information and caveats, see the release notes for your platform and software release. To find information
about the features documented in this module, and to see a list of the releases in which each feature is
supported, see the “Feature Information for mLACP” section on page 57.
Use Cisco Feature Navigator to find information about platform support and Cisco software image
support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on
Cisco.com is not required.
Contents
• Prerequisites for mLACP, page 2
• Restrictions for mLACP, page 2
• Information About mLACP, page 3
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Multichassis LACP
Prerequisites for mLACP
• How to Configure mLACP, page 17

• Configuration Examples for mLACP, page 37
• Additional References, page 55
• Feature Information for mLACP, page 57
• Glossary, page 58
Prerequisites for mLACP

• The command lacp max-bundle must be used on all PoAs in order to operate in PoA control and
shared control modes.
– The maximum number of links configured cannot be less than the total number of interfaces in
the link aggregation group (LAG) that is connected to the PoA.
– Each PoA may be connected to a dual-homed device (DHD) with a different number of links
for the LAG (configured with a different number of maximum links).
• Each PoA must be configured using the port-channel min-link command with the desired
minimum number of links to maintain the LAG in the active state.
• Each PoA must be configured with the errdisable recovery cause mlacp command if brute-force
failover is being used.
• For DHD control there must be an equal number of links going to each PoA.
• The max-bundle value must equal the number of links connected locally to the PoA (no local
intra-PoA active or standby protection).
• LACP fast switchover must be configured on all devices to speed convergence.
Restrictions for mLACP

• mLACP does not support Fast Ethernet.
• mLACP does not support half-duplex links.
• mLACP does not support multiple neighbors.
• Converting a port channel to mLACP can cause a service disruption.
• The maximum number of member links per LAG per PoA is restricted by the maximum number of
ports per port channel, as limited by the platform.
• System priority on a DHD must be a lesser priority than on PoAs.
• MAC Tunneling Protocol (MTP) supports only one member link in a port channel.
• A port-channel or its member links may flap while LACP stabilizes.
• DHD-based control does not function when min-links is not configured.
• DHD-controlled revertive behavior with min-links is not supported.
• Brute-force failover always causes min-link failures.
• Any failure with brute-force failover behaves revertively.
2
Multichassis LACP
Information About mLACP

• Overview of Multichassis EtherChannel, page 3
• Interactions with the MPLS Pseudowire Redundancy Mechanism, page 4
• Redundancy Mechanism Processes, page 5
• Dual-Homed Topology Using mLACP, page 6
• Failure Protection Scenarios, page 9
• Operational Variants, page 10
• mLACP Failover, page 11
Overview of Multichassis EtherChannel

In Multichassis EtherChannel (MCEC), the DHD is dual-homed to two upstream PoAs. The DHD is
incapable of running any loop prevention control protocol such as Multiple Spanning Tree (MST).
Therefore, another mechanism is required to prevent forwarding loops over the redundant setup. One
method is to place the DHD’s uplinks in a LAG, commonly referred to as EtherChannel. This method
assumes that the DHD is capable of running only IEEE 802.3ad LACP for establishing and maintaining
the LAG.
LACP, as defined in IEEE 802.3ad, is a link-level control protocol that allows the dynamic negotiation
and establishment of LAGs. An extension of the LACP implementation to PoAs is required to convey to
a DHD that it is connected to a single virtual LACP peer and not to two disjointed devices. This extension
is called Multichassis LACP or mLACP. Figure 1 shows this setup.
Figure 1 MCEC with mLACP

VirtualLACP Peer
Standby
PoA
DHD
Inter-chassis
Communication
EtherChannel
Active
277477
with mLACP
PoA
The PoAs forming a virtual LACP peer, from the perspective of the DHD, are defined as members of a
redundancy group. For the PoAs in a redundancy group to appear as a single device to the DHD, the
states between them must be synchronized through the Interchassis Communication Protocol (ICCP),
which provides a control-only interchassis communication channel (ICC).
3
Multichassis LACP
In Cisco IOS Release 12.2(33)SRE, the system functions in active/standby redundancy mode. In this
mode DHD uplinks that connect to only a single PoA can be active at any time. The DHD recognizes
one PoA as active and the other as standby but does not preclude a given PoA from being active for one
DHD and standby for another. This capability allows two PoAs to perform load sharing for different
services.
Interactions with the MPLS Pseudowire Redundancy Mechanism

The network setup shown in Figure 1 can be used to provide provider edge (PE) node redundancy for
Virtual Private LAN Service (VPLS) and Virtual Private Wire Service (VPWS) deployments over
Multiprotocol Label Switching (MPLS). In these deployments, the uplinks of the PoAs host the MPLS
pseudowires that provide redundant connectivity over the core to remote PE nodes. Proper operation of
the network requires interaction between the redundancy mechanisms employed on the attachment
circuits (for example, mLACP) and those employed on the MPLS pseudowires. This interaction ensures
the state (active or standby) is synchronized between the attachment circuits and pseudowires for a given
PoA.
RFC 4447 introduced a mechanism to signal pseudowire status via the Link Distribution Protocol (LDP)
and defined a set of status codes to report attachment circuit as well as pseudowire fault information.
The Preferential Forwarding Status bit (draft-ietf-pwe3-redundancy-bit) definition proposes to extend
these codes to include two bits for pseudowire redundancy applications:
• Preferential forwarding status: active or standby
• Request pseudowire switchover
The draft also proposes two modes of operation:
• Independent mode—The local PE decides on its pseudowire status independent of the remote PE.
• Primary and secondary modes—One of the PEs determines the state of the remote side through a
handshake mechanism.
For the mLACP feature, operation is based on the independent mode. By running ICC between the PoAs,
only the preferential forwarding status bit is required; the request pseudowire switchover bit is not used.
The local pseudowire status (active or standby) is determined independently by the PoAs in a redundancy
group and then relayed to the remote PEs in the form of a notification. Similarly, the remote PEs perform
their own selection of their pseudowire status and notify the PoAs on the other side of the core.
After this exchange of local states, the pseudowires used for traffic forwarding are those selected to be
active independently on both local and remote ends.
The attachment circuit redundancy mechanism determines and controls the pseudowire redundancy
mechanism. mLACP determines the status of the attachment circuit on a given PoA according to the
configured LACP system and port priorities, and then the status of the pseudowires on a given PoA is
synchronized with that of the local attachment circuits. This synchronization guarantees that the PoA
with the active attachment circuits has its pseudowires active. Similarly, the PoA with the standby
attachment circuits has its pseudowires in standby mode. By ensuring that the forwarding status of the
attachment circuits is synchronized with that of the pseudowires, the need to forward data between PoA
nodes within a redundancy group can be avoided. This synchronization saves platform bandwidth that
would otherwise be wasted on inter-PoA data forwarding in case of failures.
4
Multichassis LACP
Redundancy Mechanism Processes

The Carrier Ethernet redundancy solution should include the following processes (and how they apply
to the mLACP solution):
• Attachment circuit active or standby status selection—This selection can be performed by the access
node or network, the aggregation node, or combination of the two. For mLACP, the attachment
circuit status selection is determined through collaboration between the DHD and the PoAs.
• Pseudowire forwarding status notification—This notification is mandatory for mLACP operation in
VPWS and VPLS deployments; that is, when the PoA uplinks employ pseudowire technology. When
the PoAs decide on either an active or standby role, they need to signal the status of the associated
pseudowires to the PEs on the far end of the network. For MPLS pseudowires, this is done using
LDP.
• MAC flushing indication—This indication is mandatory for any redundancy mechanism in order to
speed convergence time and eliminate potential traffic blackholing. The mLACP redundancy
mechanism should be integrated with relevant 802.1Q/802.1ad/802.1ah MAC flushing mechanisms
as well as MAC flushing mechanisms for VPLS.
Note Blackholing occurs when incoming traffic is dropped without informing the source that the data
did not reach its intended recipient. A black hole can be detected only when lost traffic is
monitored.
• Active VLAN notification—For mLACP, this notification is not required as long as the PoAs follow
the active/standby redundancy model.
Figure 2 shows redundancy mechanisms in Carrier Ethernet networks.
5
Multichassis LACP
Figure 2 Redundancy Mechanisms in Carrier Ethernet Networks

mLACP
DSLAM
Dual-homing
DSLAM Large-scale
Native Ethernet Ethernet
Access (Hub & Spoke) Aggregation MPLS Access/
DSLAM MPLS Core Aggregation
CE
nPE
Access Network uPE
Dual-homing 2-way
2-way VPLS EoMPLS PW
L2GP Redundancy Redundancy
(VPLS PE (uPE & nPE
Node CE
Node Dual-homing
Redundancy) Redundancy)
Ethernet
Access Ring Access Ring
Dual-homing
REP
7478
CE
Dual-Homed Topology Using mLACP

The mLACP feature allows the LACP state machine and protocol to operate in a dual-homed topology.
The mLACP feature decouples the existing LACP implementation from the multichassis specific
requirements, allowing LACP to maintain its adherence to the IEEE 802.3ad standard. The mLACP
feature exposes a single virtual instance of IEEE 802.3ad to the DHD for each redundancy group. The
virtual LACP instance interoperates with the DHD according to the IEEE 802.3ad standard to form
LAGs spanning two or more chassis.
LACP and 802.3ad Parameter Exchange

In IEEE 802.3ad, the concatenation of the LACP system MAC address and system priority form an
LACP system ID (8 bytes). The system ID is formed by taking the two-byte system priority value as the
most significant two octets of the system ID. The system MAC address makes up the remainder of the
system ID (octets 3 to 8). System ID priority comparisons are based on the lower numerically valued ID.
To provide the highest LACP priority, the mLACP module communicates the system MAC address and
priority values for the given redundancy group to its redundancy group peer(s) and vice versa. The
mLACP then chooses the lowest system ID value among the PoAs in the given redundancy group to use
as the system ID of the virtual LACP instance of the redundancy group.
Cisco IOS Release 12.2(33)SRE introduces two LACP configuration commands to specify the system
MAC address and system priority used for a given redundancy group: mlacp system-mac mac-address
and mlacp system-priority priority-value. These commands provide better settings to determine which
side of the attachment circuit will control the selection logic of the LAG. The default value for the system
MAC address is the chassis backplane default MAC address. The default value for the priority is 32768.
6
Multichassis LACP
Port Identifier
IEEE 802.3ad uses a 4-byte port identifier to uniquely identify a port within a system. The port identifier
is the concatenation of the port priority and port number (unique per system) and identifies each port in
the system. Numerical comparisons between port IDs are performed by unsigned integer comparisons
where the 2-byte Port Priority field is placed in the most significant two octets of the port ID. The 2-byte
port number makes up the third and fourth octets. The mLACP feature coordinates the port IDs for a
given redundancy group to ensure uniqueness.
Port Number
A port number serves as a unique identifier for a port within a device. The LACP port number for a port
is equal to the port’s ifIndex value (or is based on the slot and subslot identifiers on the Cisco 7600
router).
LACP relies on port numbers to detect rewiring. For multichassis operation, you must enter the mlacp
node-id node-id command to coordinate port numbers between the two PoAs in order to prevent overlap.
Port Priority
Port priority is used by the LACP selection logic to determine which ports should be activated and which
should be left in standby mode when there are hardware or software limitations on the maximum number
of links allowed in a LAG. For multichassis operation in active/standby redundancy mode, the port
priorities for all links connecting to the active PoA must be higher than the port priorities for links
connecting to the standby PoA. These port priorities can either be guaranteed through explicit
configuration or the system can automatically adjust the port priorities depending on selection criteria.
For example, select the PoA with the highest port priority to be the active PoA and dynamically adjust
the priorities of all other links with the same port key to an equal value.
In Cisco IOS Release 12.2(33)SRE, the mLACP feature supports only the active/standby redundancy
model. The LACP port priorities of the individual member links should be the same for each link
belonging to the LAG of a given PoA. To support this requirement, the mlacp lag-priority command is
implemented in interface configuration mode in the command-line interface (CLI). This command sets
the LACP port priorities for all the local member links in the LAG. Individual member link LACP
priorities (configured by the lacp port-priority command) are ignored on links belonging to mLACP
port channels.
The mlacp lag-priority command may also be used to force a PoA failover during operation in the
following two ways:
• Set the active PoA’s LAG priority to a value greater than the LAG priority on the standby PoA. This
setting results in the quickest failover because it requires the fewest LACP link state transitions on
the standby links before they turn active.
• Set the standby PoA’s LAG priority to a value numerically less than the LAG priority on the active
PoA. This setting results in a slightly longer failover time because standby links have to signal
OUT_OF_SYNC to the DHD before the links can be brought up and go active.
In some cases, the operational priority and the configured priority may differ when using dynamic port
priority management to force failovers. In this case, the configured version will not be changed unless
the port channel is operating in nonrevertive mode. Enter the show lacp multichassis port-channel
command to view the current operational priorities. The configured priority values can be displayed by
using the show running-config command.
7
Multichassis LACP
Multichassis Considerations
Because LACP is a link layer protocol, all messages exchanged over a link contain information that is
specific and local to that link. The exchanged information includes:
• System attributes—priority and MAC address
• Link attributes—port key, priority, port number, and state
When extending LACP to operate over a multichassis setup, synchronization of the protocol attributes
and states between the two chassis is required.
System MAC Address

LACP relies on the system MAC address to determine the identity of the remote device connected over
a particular link. Therefore, to mask the DHD from its connection to two disjointed devices, coordination
of the system MAC address between the two PoAs is essential. In Cisco IOS software, the LACP system
MAC address defaults to the ROM backplane base MAC address and cannot be changed by
configuration. For multichassis operation the following two conditions are required:
• System MAC address for each PoA should be communicated to its peer—For example, the PoAs
elect the MAC address with the lower numeric value to be the system MAC address. The arbitration
scheme must resolve to the same value. Choosing the lower numeric MAC address has the advantage
of providing higher system priority.
• System MAC address is configurable—The system priority depends, in part, on the MAC address,
and a service provider would want to guarantee that the PoAs have higher priority than the DHD (for
example, if both DHD and PoA are configured with the same system priority and the service
provider has no control over DHD). A higher priority guarantees that the PoA port priorities take
precedence over the DHD’s port priority configuration. If you configure the system MAC address,
you must ensure that the addresses are uniform on both PoAs; otherwise, the system will
automatically arbitrate the discrepancy, as when a default MAC address is selected.
System Priority
LACP requires that a system priority be associated with every device to determine which peer’s port
priorities should be used by the selection logic when establishing a LAG. In Cisco IOS software, this
parameter is configurable through the CLI. For multichassis operation, this parameter is coordinated by
the PoAs so that the same value is advertised to the DHD.
Port Key
The port key indicates which links can form a LAG on a given system. The key is locally significant to
an LACP system and need not match the key on an LACP peer. Two links are candidates to join the same
LAG if they have the same key on the DHD and the same key on the PoAs; however, the key on the DHD
is not required to be the same as the key on the PoAs. Given that the key is configured according to the
need to aggregate ports, there are no special considerations for this parameter for multichassis operation.
8
Multichassis LACP
Failure Protection Scenarios

The mLACP feature provides network resiliency by protecting against port, link, and node failures.
These failures can be categorized into five types. Figure 3 shows the failure points in a network, denoted
by the letters A through E.
• A—Failure of the uplink port on the DHD
• B—Failure of the Ethernet link
• C—Failure of the downlink port on the active PoA
• D—Failure of the active PoA node
• E—Failure of the active PoA uplinks
Figure 3 mLACP Protected Failure Points

Standby
PoA
DHD
A
B
C D
E
Active
277479
PoA
When any of these faults occur, the system reacts by triggering a switchover from the active PoA to the
standby PoA. The switchover involves failing over the PoA’s uplinks and downlinks simultaneously.
Failure points A and C are port failures. Failure point B is an Ethernet link failure and failure point D is
a node failure. Failure point E can represent one of four different types of uplink failures when the PoAs
connect to an MPLS network:
• Pseudowire failure—Monitoring individual pseudowires (for example, using VCCV-BFD) and,
upon a pseudowire failure, declare uplink failure for the associated service instances.
• Remote PE IP path failure—Monitoring the IP reachability to the remote PE (for example, using IP
Route-Watch) and, upon route failure, declare uplink failure for all associated service instances.
• LSP failure—Monitoring the LSP to a given remote PE (for example, using automated LSP-Ping)
and, upon LSP failure, declare uplink failure for all associated service instances.
• PE isolation—Monitoring the physical core-facing interfaces of the PE. When all of these interfaces
go down, the PE effectively becomes isolated from the core network, and the uplink failure is
declared for all affected service instances.
As long as the IP/MPLS network employs native redundancy and resiliency mechanisms such as MPLS
fast reroute (FRR), the mLACP solution is sufficient for providing protection against PE isolation.
Pseudowire, LSP, and IP path failures are managed by the native IP/MPLS protection procedures. That
9
Multichassis LACP
is, interchassis failover via mLACP is triggered only when a PE is completely isolated from the core
network, because native IP/MPLS protection mechanisms are rendered useless. Therefore, failure point
E is used to denote PE isolation from the core network.
Note The set of core-facing interfaces that should be monitored are identified by explicit configuration. The
set of core-facing interfaces must be defined independently per redundancy group. Failure point E
(unlike failure point A, B, or C) affects and triggers failover for all the multichassis LAGs configured on
a given PoA.
Operational Variants
LACP provides a mechanism by which a set of one or more links within a LAG are placed in standby
mode to provide link redundancy between the devices. This redundancy is normally achieved by
configuring more ports with the same key than the number of links a device can aggregate in a given
LAG (due to hardware or software restrictions, or due to configuration). For active/standby redundancy,
two ports are configured with the same port key, and the maximum number of allowed links in a LAG is
configured to be 1. If the DHD and PoAs are all capable of restricting the number of links per LAG by
configuration, three operational variants are possible.
DHD-based Control
The DHD is configured to limit the maximum number of links per bundle to one, whereas the PoAs are
configured to limit the maximum number of links per bundle to greater than one. Thus, the selection of
the active/standby link is the responsibility of the DHD. Which link is designated active and which is
marked standby depends on the relative port priority, as configured on the system with the higher system
priority. A PoA configured with a higher system priority can still determine the selection outcome. The
DHD makes the selection and places the link with lower port priority in standby mode.
To accommodate DHD-controlled failover, the DHD must be configured with the max-bundle value
equal to a number of links (L), where L is the fewest number of links connecting the DHD to a PoA. The
max-bundle value restricts the DHD from bundling links to both PoAs at the same time (active/active).
Although the DHD controls the selection of active/standby links, the PoA can still dictate the individual
member link priorities by configuring the PoA’s virtual LACP instance with a lower system priority
value than the DHD’s system priority.
The DHD control variant must be used with a PoA minimum link threshold failure policy where the
threshold is set to L (same value for L as described above). A minimum link threshold must be
configured on each of the PoAs because an A, B, or C link failure that does not trigger a failover
(minimum link threshold is still satisfied) causes the DHD to add one of the standby links going to the
standby PoA to the bundle. This added link results in the unsupported active/active scenario.
Note DHD control does not use the mLACP hot-standby state on the standby PoA, which results in higher
failover times than the other variants.
DHD control eliminates the split brain problem on the attachment circuit side by limiting the DHD’s
attempts to bundle all the links.
10
Multichassis LACP
PoA Control
In PoA control, the PoA is configured to limit the maximum number of links per bundle to be equal to
the number of links (L) going to the PoA. The DHD is configured with that parameter set to some value
greater than L. Thus, the selection of the active/standby links becomes the responsibility of the PoA.
Shared Control (PoA and DHD)

In shared control, both the DHD and the PoA are configured to limit the maximum number of links per
bundle to L—the number of links going to the PoA. In this configuration, each device independently
selects the active/standby link. Shared control is advantageous in that it limits the split-brain problem in
the same manner as DHD control, and shared control is not susceptible to the active/active tendencies
that are prevalent in DHD control. A disadvantage of shared control is that the failover time is
determined by both the DHD and the PoA, each changing the standby links to SELECTED and waiting
for each of the WAIT_WHILE_TIMERs to expire before moving the links to IN_SYNC. The
independent determination of failover time and change of link states means that both the DHD and PoAs
need to support the LACP fast-switchover feature in order to provide a failover time of less than
one second.
mLACP Failover
The mLACP forces a PoA failover to the standby PoA when one of the following failures occurs:
• Failure of the DHD uplink port, Ethernet link, or downlink port on the active PoA—A policy failover
is triggered via a configured failover policy and is considered a forced failover. In Cisco IOS Release
12.2(33)SRE, the only option is the configured minimum bundle threshold. When the number of
active and SELECTED links to the active PoA goes below the configured minimum threshold,
mLACP forces a failover to the standby PoA’s member links. This minimum threshold is configured
using the port-channel min-links command in interface configuration mode. The PoAs determine
the failover independent of the operational control variant in use.
• Failure of the active PoA—This failure is detected by the standby PoA. mLACP automatically fails
over to standby because mLACP on the standby PoA is notified of failure via ICRM and brings up
its local member links. In the DHD-controlled variant, this failure looks the same as a total member
link failure, and the DHD activates the standby links.
• Failure of the active PoA uplinks—mLACP is notified by ICRM of PE isolation and relinquishes its
active member links. This failure is a “forced failover” and is determined by the PoAs independent
of the operational control variant in use.
Dynamic Port Priority

The default failover mechanism uses dynamic port priority changes on the local member links to force
the LACP selection logic to move the required standby link(s) to the SELECTED and
Collecting_Distributing state. This state change occurs when the LACP actor port priority values for all
affected member links on the currently active PoA are changed to a higher numeric value than the
standby PoA’s port priority (which gives the standby PoA ports a higher claim to bundle links). Changing
the actor port priority triggers the transmission of an mLACP Port Config Type-Length-Value (TLV)
message to all peers in the redundancy group. These messages also serve as notification to the standby
PoA(s) that the currently active PoA is attempting to relinquish its role. The LACP then transitions the
standby link(s) to the SELECTED state and moves all the currently active links to STANDBY.
11
Multichassis LACP
Dynamic port priority changes are not automatically written back to the running configuration or to the
NVRAM configuration. If you want the current priorities to be used when the system reloads, the mlacp
lag-priority command must be used and the configuration must be saved.
Revertive and Nonrevertive Modes

Dynamic port priority functionality is used by the mLACP feature to provide both revertive mode and
nonrevertive mode. The default operation is revertive, which is the default behavior in single chassis
LACP. Nonrevertive mode can be enabled on a per port-channel basis by using the lacp failover
non-revertive command in interface configuration mode. In Cisco IOS Release 12.2(33)SRE this
command is supported only for mLACP.
Nonrevertive mode is used to limit failover and, therefore, possible traffic loss. Dynamic port priority
changes are utilized to ensure that the newly activated PoA remains active after the failed PoA recovers.
Revertive mode operation forces the configured primary PoA to return to active state after it recovers
from a failure. Dynamic port priority changes are utilized when necessary to allow the recovering PoA
to resume its active role.
Brute Force Shutdown

A brute-force shutdown is a forced failover mechanism to bring down the active physical member link
interface(s) for the given LAG on the PoA that is surrendering its active status. This mechanism does not
depend on the DHD’s ability to manage dynamic port priority changes and compensates for deficiencies
in the DHD’s LACP implementation.
The brute-force shutdown changes the status of each member link to ADMIN_DOWN to force the
transition of the standby links to the active state. Note that this process eliminates the ability of the local
LACP implementation to monitor the link state.
The brute-force shutdown operates in revertive mode, so dynamic port priorities cannot be used to
control active selection. The brute-force approach is configured by the lacp failover brute-force
command in interface configuration mode. This command is not allowed in conjunction with a
nonrevertive configuration.
Peer Monitoring with Interchassis Redundancy Manager

There are two ways in which a peer can be monitored with Interchassis Redundancy Manager (ICRM):
• Routewatch (RW)—This method is the default.
• Bidirectional Forwarding Detection (BFD)—You must configure the redundancy group with the
monitor peer bfd command.
Note For stateful switchover (SSO) deployments (with redundant support in the chassis), BFD monitoring and
a static route for the ICCP connection are required to prevent “split brain” after an SSO failover.
Routewatch is not compatible with SSO for health monitoring.
For each redundancy group, for each peer (member IP), a monitoring adjacency is created. If there are
two peers with the same IP address, the adjacency is shared regardless of the monitoring mode. For
example, if redundancy groups 1 and 2 are peered with member IP 10.10.10.10, there is only one
adjacency to 10.10.10.10, which is shared in both redundancy groups. Furthermore, redundancy group
1 can use BFD monitoring while redundancy group 2 is using RW.
12
Multichassis LACP
Note BFD is completely dependent on RW—there must be a route to the peer for ICRM to initiate BFD
monitoring. BFD implies RW and sometimes the status of the adjacency may seem misleading but is
accurately representing the state. Also, if the route to the peer PoA is not through the directly connected
(back-to-back) link between the systems, BFD can give misleading results.
An example of output from the show redundancy interface command follows:

Router# show redundancy interface
Redundancy Group 1 (0x1)

Applications connected: mLACP
Monitor mode: Route-watch
member ip: 201.0.0.1 ‘mlacp-201’, CONNECTED
Route-watch for 201.0.0.1 is UP
mLACP state: CONNECTED
ICRM fast-failure detection neighbor table

IP Address Status Type Next-hop IP Interface
========== ====== ==== =========== =========
201.0.0.1 UP RW
To interpret the adjacency status displayed by the show redundancy interchassis command, refer to
Table 1.
Table 1 Status Information from the show redundancy interchassis command
Adjacency Type Adjacency Status Meaning

RW DOWN RW or BFD is configured, but there is no route for the given
IP address.
RW UP RW or BFD is configured. RW is up, meaning there is a
valid route to the peer. If BFD is configured and the
adjacency status is UP, BFD is probably not configured on
the interface of the route’s adjacency.
BFD DOWN BFD is configured. A route exists and the route’s adjacency
is to an interface that has BFD enabled. BFD is started but
the peer is down. The DOWN status can be because the peer
is not present or BFD is not configured on the peer’s
interface.
BFD UP BFD is configured and operational.
Note If the adjacency type is “BFD,” RW is UP regardless of the BFD status.
MAC Flushing Mechanisms

When mLACP is used to provide multichassis redundancy in multipoint bridged services (for example,
VPLS), there must be a MAC flushing notification mechanism in order to prevent potential traffic
blackholing.
13
Multichassis LACP
At the failover from a primary PoA to a secondary PoA, a service experiences traffic blackholing when
the DHD in question remains inactive and while other remote devices in the network are attempting to
send traffic to that DHD. Remote bridges in the network have stale MAC entries pointing to the failed
PoA and direct traffic destined to the DHD to the failed PoA, where the traffic is dropped. This
blackholing continues until the remote devices age out their stale MAC address table entries (which
typically takes five minutes). To prevent this anomaly, the newly active PoA, which has taken control of
the service, transmits a MAC flush notification message to the remote devices in the network to flush
their stale MAC address entries for the service in question.
The exact format of the MAC flushing message depends on the nature of the network transport: native
802.1Q/802.1ad Ethernet, native 802.1ah Ethernet, VPLS, or provider backbone bridge (PBB) over
VPLS. Furthermore, in the context of 802.1ah, it is important to recognize the difference between
mechanisms used for customer-MAC (C-MAC) address flushing versus bridge-MAC (B-MAC) address
flushing.
The details of the various mechanisms are discussed in the following sections.
Multiple I-SID Registration Protocol
Multiple I-SID Registration Protocol (MIRP) is enabled by default on 802.1ah service instances. The use
of MIRP in 802.1ah networks is shown in Figure 4.
Figure 4 Traffic Blackholing in an 802.1ah Network
BEB 1
M1
DHD1 BCB BEB 3 DHD2

CM1 M3 CM2
BEB 2 C-MAC B-MAC

M2
CM1 M1
BEB 1
M1
DHD1 BCB BEB 3 DHD2

CM1 M3 CM2
BEB 2 C-MAC B-MAC

248496
M2
CM1 M1
Device DHD1 is dual-homed to two 802.1ah backbone edge bridges (BEB1 and BEB2). Assume that
initially the primary path is through BEB1. In this configuration BEB3 learns that the host behind DHD1
(with MAC address CM1) is reachable via the destination B-MAC M1. If the link between DHD1 and
BEB1 fails and the host behind DHD1 remains inactive, the MAC cache tables on BEB3 still refer to the
14
Multichassis LACP
BEB1 MAC address even though the new path is now via BEB2 with B-MAC address M2. Any bridged
traffic destined from the host behind DHD2 to the host behind DHD1 is wrongfully encapsulated with
B-MAC M1 and sent over the MAC tunnel to BEB1, where the traffic blackholes.
To circumvent the traffic blackholing problem when the link between DHD1 and BEB1 fails, BEB2
performs two tasks:
• Flushes its own MAC address table for the service or services in question.
• Transmits an MIRP message on its uplink to signal the far end BEB (BEB3) to flush its MAC address
table. Note that the MIRP message is transparent to the backbone core bridges (BCBs). The MIRP
message is processed on a BEB because only BCBs learn and forward based on B-MAC addresses
and they are transparent to C-MAC addresses.
Note MIRP triggers C-MAC address flushing for both native 802.1ah and PBB over VPLS.
15
Multichassis LACP
Figure 5 shows the operation of the MIRP.
Figure 5 Operation of MIRP for C-MAC Flushing in 802.1ah Networks
BEB 1
M1
DHD1 BCB BEB 3 DHD2

CM1 M3 CM2
BEB 2 C-MAC B-MAC

M2
CM1 M1
C-MAC B-MAC
CM1 M1
BEB 1
M1
DHD1 BCB BEB 3 DHD2

CM1 M3 CM2
248497
BEB 2 C-MAC B-MAC
1 M2 2b CM1 M1
C-MAC B-MAC 3
CM1 M1 C-MAC B-MAC
2a
C-MAC B-MAC
The MIRP has not been defined in IEEE but is expected to be based on the IEEE 802.1ak Multiple
Registration Protocol (MRP). MRP maintains a complex finite state machine (FSM) for generic attribute
registration. In the case of MIRP, the attribute is an I-SID. As such, MIRP provides a mechanism for
BEBs to build and prune a per I-SID multicast tree. The C-MAC flushing notification capability of MIRP
is a special case of attribute registration in which the device indicates that an MIRP declaration is “new,”
meaning that this notification is the first time a BEB is declaring interest in a particular I-SID.
LDP MAC Address Withdraw
When the mLACP feature is used for PE redundancy in traditional VPLS (that is, not PBB over VPLS),
the MAC flushing mechanism is based on the LDP MAC Address Withdraw message as defined in
RFC 4762.
16
Multichassis LACP
How to Configure mLACP
The required functional behavior is as follows: Upon a failover from the primary PoA to the standby
PoA, the standby PoA flushes its local MAC address table for the affected services and generates the
LDP MAC Address Withdraw messages to notify the remote PEs to flush their own MAC address tables.
One message is generated for each pseudowire in the affected virtual forwarding instances (VFIs).

• Configuring Interchassis Group and Basic mLACP Commands, page 17 (required)
• Configuring the mLACP Interchassis Group and Other Port-Channel Commands, page 19
• Configuring Redundancy for VPWS, page 21
• Configuring Redundancy for VPLS, page 24
• Configuring Hierarchical VPLS, page 28
• Troubleshooting mLACP, page 32 (optional)
Configuring Interchassis Group and Basic mLACP Commands

Perform this task to set up the communication between multiple PoAs and to configure them in the same
group.
SUMMARY STEPS
1. enable
2. configure terminal
3. redundancy
4. interchassis group group-id
5. monitor peer bfd
6. member ip ip-address
7. mlacp node-id node-id
8. mlacp system-mac mac-address
9. mlacp system-priority priority-value
10. backbone interface type number
11. end
17
Multichassis LACP
DETAILED STEPS
Command or Action Purpose

Step 1 enable Enables privileged EXEC mode.
• Enter your password if prompted.
Example:
Router> enable
Step 2 configure terminal Enters global configuration mode.
Example:
Router# configure terminal
Step 3 redundancy Enters redundancy configuration mode.
Example:
Router(config)# redundancy
Step 4 interchassis group group-id Configures an interchassis group within the redundancy
configuration mode and enters interchassis redundancy
mode.
Example:
Router(config-red)# interchassis group
50
Step 5 monitor peer bfd Configures the BFD option to monitor the state of the
peer. The default option is route-watch.
Example:
Router(config-r-ic)# monitor peer bfd
Step 6 member ip ip-address Configures the IP address of the mLACP peer member
group.
Example:
Router(config-r-ic)# member ip
172.3.3.3
Step 7 mlacp node-id node-id Defines the node ID used in the LACP Port ID field by
this member of the mLACP redundancy group.
Example: • The valid range is 0 to 7, and the value should be
Router(config-r-ic)# mlacp node-id 5 different from the peer values.
Step 8 mlacp system-mac mac-address Defines and advertises the system MAC address value
to the mLACP members of the redundancy group for
arbitration.
Example:
Router(config-r-ic)# mlacp system-mac • The format of the mac-address argument must be in
aa12.be45.d799 standard MAC address format: aabb.ccdd.eeff.
Step 9 mlacp system-priority priority-value Defines the system priority advertised to the other
mLACP members of the redundancy group.
Example: • System priority values are 1 to 65535. Default
Router(config-r-ic)# mlacp value is 32768.
system-priority 100
• The assigned values should be lower than the DHD.
18
Multichassis LACP

Step 10 backbone interface type number Defines the backbone interface for the mLACP
configuration.
Example:
Router(config-r-ic)# backbone
interface GigabitEthernet2/3
Step 11 end Returns the CLI to privileged EXEC mode.
Example:
Router(config-r-ic)# end
Configuring the mLACP Interchassis Group and Other Port-Channel Commands

Perform this task to set up mLACP attributes specific to a port channel. The mlacp interchassis group
command links the port-channel interface to the interchassis group that was created in the previous
“Configuring Interchassis Group and Basic mLACP Commands” section on page 17.
SUMMARY STEPS
1. enable
3. interface port-channel port-channel-number
4. lacp max-bundle max-bundles
5. lacp failover {brute-force | non-revertive}
6. exit
7. redundancy
9. exit
10. exit
11. errdisable recovery cause mlacp-minlink
12. exit
DETAILED STEPS

Example:
Router> enable
Example:
19
Multichassis LACP
Step 3 interface port-channel port-channel- Configures the port channel and enters interface
number configuration mode.
Example:
Router(config)# interface port-channel1
Step 4 lacp max-bundle max-bundles Configures the max-bundle links that are connected to
the PoA. The value of the max-bundles argument
should not be less than the total number of links in the
Example:
Router(config-if)# lacp max-bundle 4
LAG that are connected to the PoA.
• Determines whether the redundancy group is under
DHD control, PoA control, or both.
• Range is 1 to 8. Default value is 8.
Step 5 lacp failover {brute-force | Sets the mLACP switchover to nonrevertive or brute
non-revertive} force. This command is optional.
• Default value is revertive (with 180-second delay).
Example:
Router(config-if)# lacp failover
• If you configure brute force, a minimum link
brute-force failure for every mLACP failure occurs or the
dynamic lag priority value is modified.
Step 6 exit Exits interface configuration mode.
Example:
Router(config-if)# exit
Example:
Step 8 interchassis group group-id Specifies that the port channel is an mLACP port
channel. The group-id should match the configured
redundancy group.
Example:
Router(config-red)# interchassis group
230
Step 9 exit Exits interchassis redundancy mode.
Example:
Router(config-r-ic)# exit
Step 10 exit Exits redundancy configuration mode.
Example:
Router(config-red)# exit
20
Multichassis LACP
Step 11 errdisable recovery cause mlacp-minlink Enables automatic recovery from a failover state of the
port channel.
Example:
Router(config)# errdisable recovery
cause mlacp-minlink
Example:
Router(config)# end
Configuring Redundancy for VPWS

Perform this task to provide Layer 2 VPN service redundancy for VPWS.
SUMMARY STEPS
1. enable
3. pseudowire-class pw-class-name
4. encapsulation mpls
5. status peer topology dual-homed
6. exit
8. no ip address
9. lacp fast-switchover
11. exit
12. redundancy
14. exit
15. exit
17. service instance id ethernet [evc-name]
18. encapsulation dot1q vlan-id [,vlan-id [-vlan-id]] [native]
19. exit
20. xconnect peer-ip-address vc-id {encapsulation mpls | pw-class pw-class-name} [pw-class
pw-class-name] [sequencing {transmit | receive | both}]
21. backup peer peer-router-ip-addr vcid [pw-class pw-class-name] [priority value]
22. end
21
Multichassis LACP
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class pw-class-name Specifies the name of a Layer 2 pseudowire class and
enters pseudowire class configuration mode.
Example:
Router(config)# pseudowire-class
ether-pw
Step 4 encapsulation mpls Specifies that MPLS is used as the data encapsulation
method for tunneling Layer 2 traffic over the
pseudowire.
Example:
Router(config-pw-class)# encapsulation
mpls
Step 5 status peer topology dual-homed Enables the reflection of the attachment circuit status
onto both the primary and secondary pseudowires. This
condition is necessary if the peer PEs are connected to
Example:
Router(config-pw-class)# status peer
a dual-homed device.
topology dual-homed
Step 6 exit Exits pseudowire class configuration mode.
Example:
Router(config-pw-class)# exit
Step 7 interface port-channel Configures the port channel and enters interface
port-channel-number configuration mode.
Example:
Step 8 no ip address Specifies that the VLAN interface does not have an IP
address assigned to it.
Example:
Router(config-if)# no ip address
Step 9 lacp fast-switchover Enables LACP 1-to-1 link redundancy.
Example:
Router(config-if)# lacp fast-switchover
22
Multichassis LACP
Example:
Example:
Example:
channel.
Example: • The group-id should match the configured
Router(config-red)# interchassis group redundancy group.
230
Example:
Example:
Step 16 interface port-channel Configures the port channel and enters interface
port-channel-number configuration mode.
Example:
Step 17 service instance id ethernet [evc-name] Configures an Ethernet service instance.
Example:
Router(config-if)# service instance 1
ethernet
Step 18 encapsulation dot1q vlan-id [,vlan-id Enables IEEE 802.1Q encapsulation of traffic on a
[-vlan-id]] [native] specified subinterface in a VLAN.
Example:
Router(config-if-srv)# encapsulation
dot1q 100
23
Multichassis LACP
Step 19 exit Exits service instance configuration mode.
Example:
Router(config-if-srv)# exit
Step 20 xconnect peer-ip-address vc-id Binds an attachment circuit to a pseudowire.
{encapsulation mpls | pw-class
pw-class-name} [pw-class pw-class-name]
[sequencing {transmit | receive |
both}]
Example:
Router(config-if)# xconnect 10.0.3.201
123 pw-class ether-pw
Step 21 backup peer peer-router-ip-addr vcid Specifies a redundant peer for a pseudowire virtual
[pw-class pw-class-name] [priority circuit.
value]
Example:
Router(config-if)# backup peer 10.1.1.1
Example:
Router(config-if)# end
Configuring Redundancy for VPLS

This section contains a brief description of VPLS coupled and decoupled modes and steps to configure
redundancy for VPLS.
Coupled and Decoupled Modes for VPLS

VPLS can be configured in either coupled mode or decoupled mode. Coupled mode is when at least one
attachment circuit in VFI changes state to active, all pseudowires in VFI advertise active. When all
attachment circuits in VFI change state to standby, all pseudowires in VFI advertise standby mode. See
Figure 6.
Figure 6 VPLS Coupled Mode States

Standby Active Standby Standby
Standby Active Standby Standby
277507
Active Active Standby Standby
24
Multichassis LACP
VPLS decoupled mode is when all pseudowires in the VFI are always active and the attachment circuit
state is independent of the pseudowire state. This mode provides faster switchover time when a platform
does not support pseudowire status functionality, but extra flooding and multicast traffic will be dropped
on the PE with standby attachment circuits. See Figure 7.
Figure 7 VPLS Decoupled Mode States
Standby Active Standby Active

Standby Active Standby Active
277508
Active Active Standby Active
Steps for Configuring Redundancy for VPLS

Perform the following task to configure redundancy for VPLS.
SUMMARY STEPS
1. enable
3. l2 vfi name manual
4. vpn id vpn-id
5. status decoupled (optional)
6. neighbor neighbor ip-address vc-id {encapsulation mpls | pw-class pw-class-name}
7. exit
9. no ip address
12. exit
13. redundancy
15. exit
16. exit
20. bridge-domain bridge-id [split-horizon [group group-id]]
21. exit
22. interface vlan vlanid
23. no ip address
25
Multichassis LACP
24. xconnect vfi vfi-name

25. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 l2 vfi name manual Establishes a Layer 2 VFI between two separate
networks and enters VFI configuration mode.
Example:
Router(config)# l2 vfi vfi1 manual
Step 4 vpn id vpn-id Sets or updates a Virtual Private Network (VPN) ID on
a VPN routing and forwarding (VRF) instance.
Example:
Router(config-vfi)# vpn id 100
Step 5 status decoupled (Optional) Enables decoupled mode. The state of the
attachment circuits on the user-facing Provider Edge
(uPE) is decoupled from the state of the pseudowires.
Example:
Router(config-vfi)# status decoupled
The mLACP controls the state of the attachment
circuits.
Step 6 neighbor neighbor ip-address vc-id Specifies the routers that should form a VFI
{encapsulation mpls | pw-class connection.
pw-class-name}
• Repeat this command for each neighbor.
Example:
Router(config-vfi)# neighbor 10.1.1.1
50 encapsulation mpls
Step 7 exit Exits VFI configuration mode and returns to global
configuration mode.
Example:
Router(config-vfi)# exit
Example:
Example:
26
Multichassis LACP
Example:
Example:
Example:
Step 13 redundancy • Enters redundancy configuration mode.
Example:
Step 14 interchassis group group-id Specifies that the port channel is an mLACP
port-channel.
230
Example:
Example:
Example:
Step 18 service instance id ethernet [evc-name] Configures an Ethernet service instance and enters
Ethernet service configuration mode.
Example:
ethernet
27
Multichassis LACP
Example:
dot1q 100
Step 20 bridge-domain bridge-id [split-horizon Configures the bridge domain. Binds the service
[group group-id]] instance to a bridge domain instance where
domain-number is the identifier for the bridge domain
Example: instance.
Router(config-if-srv)# bridge-domain
200
Example:
Step 22 interface vlan vlanid Creates a dynamic switch virtual interface (SVI).
Example:
Router(config-if)# interface vlan 200
Example:
Step 24 xconnect vfi vfi-name Specifies the Layer 2 VFI that you are binding to the
VLAN port.
Example:
Router(config-if)# xconnect vfi vfi-16
Example:
Configuring Hierarchical VPLS

Perform this task to configure Hierarchical VPLS (H-VPLS).
SUMMARY STEPS
1. enable
3. pseudowire-class pw-class-name
4. encapsulation mpls
5. status peer topology dual-homed
6. status decoupled (optional)
28
Multichassis LACP
7. exit
9. no ip address
12. exit
13. redundancy
15. exit
16. exit
20. exit
21. xconnect peer-ip-address vc-id {encapsulation mpls | pw-class pw-class-name} [pw-class
pw-class-name] [sequencing {transmit | receive | both}]
22. backup peer peer-router-ip-addr vcid [pw-class pw-class-name] [priority value]
23. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class pw-class-name Specifies the name of a Layer 2 pseudowire class and
enters pseudowire class configuration mode.
Example:
Router(config)# pseudowire-class
ether-pw
Step 4 encapsulation mpls Specifies that MPLS is used as the data encapsulation
method for tunneling Layer 2 traffic over the
pseudowire.
Example:
Router(config-pw-class)# encapsulation
mpls
29
Multichassis LACP
Step 5 status peer topology dual-homed Enables the reflection of the attachment circuit status
onto both the primary and secondary pseudowires. This
configuration is necessary if the peer PEs are connected
Example:
Router(config-pw-class)# status peer
to a dual-homed device.
topology dual-homed
Step 6 status decoupled (Optional) Enables decoupled mode. The state of the
attachment circuits on the uPE is decoupled from the
state of the pseudowires. The mLACP controls the state
Example:
Router(config-pw-class)# status
of the attachment circuits.
decoupled
Step 7 exit Exits pseudowire class configuration mode and returns
to global configuration mode.
Example:
Router(config-pw-class)# exit
Example:
Example:
Example:
Example:
Example:
Example:
30
Multichassis LACP
channel.
230
Example:
Example:
Example:
Step 18 service instance id ethernet [evc-name] Configures an Ethernet service instance and enters
Ethernet service configuration mode.
Example:
ethernet
Example:
dot1q 100
Example:
Step 21 xconnect peer-ip-address vc-id Binds an attachment circuit to a pseudowire, and
{encapsulation mpls | pw-class configures an Any Transport over MPLS (AToM) static
pw-class-name} [pw-class pw-class-name]
[sequencing {transmit | receive |
pseudowire.
both}]
Example:
Router(config-if)# xconnect 10.0.3.201
123 pw-class vlan-xconnect
31
Multichassis LACP
Step 22 backup peer peer-router-ip-addr vcid Specifies a redundant peer for a pseudowire virtual
[pw-class pw-class-name] [priority circuit.
value]
Example:
Router(config-if)# backup peer 10.1.1.1
Example:
Troubleshooting mLACP
• Debugging mLACP, page 32
• Debugging mLACP on an Attachment Circuit or EVC, page 33
• Debugging mLACP on AToM Pseudowires, page 34
• Debugging Cross-Connect, Redundancy Manager, and Session Setup, page 34
• Debugging VFI, page 35
• Debugging the Segment Switching Manager (Switching Setup), page 35
• Debugging High Availability Features in mLACP, page 36
Debugging mLACP
Use these debug commands for general mLACP troubleshooting.
SUMMARY STEPS
1. enable
2. debug redundancy interchassis {all | application | error | event | monitor}
3. debug mpls ldp iccp
4. debug lacp [all | event | fsm | misc | multi-chassis [all | database | lacp-mgr | redundancy-group
| user-interface] | packet]
DETAILED STEPS

Example:
Router> enable
32
Multichassis LACP
Step 2 debug redundancy interchassis {all | • Enables debugging of the interchassis redundancy
application | error | event | monitor} manager.
Example:
Router# debug redundancy interchassis
all
Step 3 debug mpls ldp iccp • Enables debugging of the InterChassis Control
Protocol (ICCP).
Example:
Router# debug mpls ldp iccp
Step 4 debug lacp [all | event | fsm | misc | Enables debugging of LACP activity.
multi-chassis [all | database |
lacp-mgr | redundancy-group | • This command is run on the switch processor.
user-interface] | packet]
Example:
Router# debug lacp multi-chassis all
Debugging mLACP on an Attachment Circuit or EVC

Use these debug commands for troubleshooting mLACP on an attachment circuit or on an EVC.
SUMMARY STEPS
1. enable
2. debug acircuit {checkpoint | error | event}
3. debug ethernet service {all | api | error | evc [evc-id] | ha | instance [id id | interface type number
| qos] | interface type number | microblock | oam-mgr}
DETAILED STEPS

Example:
Router> enable
Step 2 debug acircuit {checkpoint | error | Displays checkpoints, errors, and events that occur on
event} the attachment circuits between the PE and CE routers.
Example:
Router# debug acircuit event
Step 3 debug ethernet service {all | api | Enables debugging of Ethernet customer service
error | evc [evc-id] | ha | instance instances.
[id id | interface type number | qos] |
interface type number | microblock |
oam-mgr}
Example:
Router# debug ethernet service all
33
Multichassis LACP
Debugging mLACP on AToM Pseudowires

Use the debug mpls l2transport vc command for troubleshooting mLACP on AToM pseudowires.
SUMMARY STEPS
1. enable
2. debug mpls l2transport vc {event | fsm | ldp | sss | status {event | fsm}}
DETAILED STEPS

Example:
Router> enable
Step 2 debug mpls l2transport vc {event | fsm Displays information about the status of AToM virtual
| ldp | sss | status {event | fsm}} circuits (VCs).
Example:
Router# debug mpls l2transport status
event
Debugging Cross-Connect, Redundancy Manager, and Session Setup

Use the following debug commands to troubleshoot cross-connect, redundancy manager, and session
setup.
SUMMARY STEPS
1. enable
2. debug sss error
3. debug sss event
4. debug xconnect {error | event}
DETAILED STEPS

Example:
Router> enable
Step 2 debug sss error Displays diagnostic information about errors that may
occur during a subscriber service switch (SSS) call
setup.
Example:
Router# debug sss error
34
Multichassis LACP
Step 3 debug sss events Displays diagnostic information about SSS call setup
events.
Example:
Router# debug sss event
Step 4 debug xconnect {error | event} Displays errors or events related to a cross-connect
configuration.
Example:
Router# debug xconnect event
Debugging VFI
Use the debug vfi command for troubleshooting a VFI.
SUMMARY STEPS
1. enable
2. debug vfi {checkpoint | error | event | fsm {error | event}}
DETAILED STEPS

Example:
Router> enable
Step 2 debug vfi {checkpoint | error | event | Displays checkpoint information about a VFI.
fsm {error | event}}
Example:
Router# debug vfi checkpoint
Debugging the Segment Switching Manager (Switching Setup)

Use the debug ssm command for troubleshooting a segment switching manager (SSM).
SUMMARY STEPS
1. enable
2. debug ssm {cm errors | cm events | fhm errors | fhm events | sm errors | sm events | sm counters
| xdr}
35
Multichassis LACP
DETAILED STEPS

Example:
Router> enable
Step 2 debug ssm {cm errors | cm events | fhm Displays diagnostic information about the SSM for
errors | fhm events | sm errors | sm switched Layer 2 segments.
events | sm counters | xdr}
Example:
Router# debug ssm cm events
Debugging High Availability Features in mLACP

Use the following debug commands for troubleshooting High Availability features in mLACP.
SUMMARY STEPS
1. enable
2. debug mpls l2transport checkpoint
3. debug acircuit checkpoint
4. debug vfi checkpoint
DETAILED STEPS

Example:
Router> enable
Step 2 debug mpls l2transport checkpoint Enables the display of AToM events when AToM is
configured for nonstop forwarding/stateful switchover
(NSF/SSO) and Graceful Restart.
Example:
Router# debug mpls l2transport
checkpoint
Step 3 debug acircuit checkpoint Enables the display of attachment circuit events when
AToM is configured for NSF/SSO and Graceful Restart.
Example:
Router# debug acircuit checkpoint
Step 4 debug vfi checkpoint Enables the display of VFI events when AToM is
configured for NSF/SSO and Graceful Restart.
Example:
Router# debug vfi checkpoint
36
Multichassis LACP
Configuration Examples for mLACP

• Example: Configuring VPWS, page 37
• Example: Configuring VPLS, page 39
• Example: Configuring H-VPLS, page 41
• Example: Verifying VPWS on an Active PoA, page 43
• Example: Verifying VPWS on a Standby PoA, page 46
• Example: Verifying VPLS on an Active PoA, page 49
• Example: Verifying VPLS on a Standby PoA, page 52
Example: Configuring VPWS

Two sample configurations for VPWS follow: one example for an active PoA and the other for a standby
PoA.
Figure 8 shows a sample topology for a VPWS configuration.
Figure 8 mLACP with Two-way Pseudowire Redundancy

MPLS
Priority L4 is
Higher than
Priority L3
PW2
PE1 PE2
DHD1 DHD2
L2 PW1 L4
L1 PW3 L3
PE3 PE4
PW4
277542
Priority L1 is Higher than Priority L2
Active PoA for VPWS

The following VPWS sample configuration is for an active PoA:
mpls ldp graceful-restart
mpls label protocol ldp
!
redundancy
mode sso
interchassis group 1
member ip 201.0.0.1
backbone interface Ethernet0/2
monitor peer bfd
mlacp node-id 0
!
37
Multichassis LACP
pseudowire-class mpls-dhd
encapsulation mpls
status peer topology dual-homed
!
interface Loopback0
ip address 200.0.0.1 255.255.255.255
!
interface Port-channel1
no ip address
lacp fast-switchover
lacp max-bundle 1
mlacp interchassis group 1
hold-queue 300 in
service instance 1 ethernet
encapsulation dot1q 100
xconnect 210.0.0.1 10 pw-class mpls-dhd
backup peer 211.0.0.1 10 pw-class mpls-dhd
!
interface Ethernet0/0
no ip address
channel-group 1 mode active
!
ip address 10.0.0.200 255.255.255.0
mpls ip
bfd interval 50 min_rx 150 multiplier 3
Standby PoA for VPWS

The following VPWS sample configuration is for a standby PoA:
!
Redundancy
mode sso
member ip 200.0.0.1
monitor peer bfd
mlacp node-id 1
!
encapsulation mpls
!
interface Loopback0
ip address 201.0.0.1 255.255.255.255
!
no ip address
lacp max-bundle 1
mlacp lag-priority 40000
hold-queue 300 in
38
Multichassis LACP

!
no ip address
!
ip address 10.0.0.201 255.255.255.0
mpls ip
Example: Configuring VPLS

Two sample configurations for VPLS follow: one example for an active PoA and the other for a standby
PoA.
Figure 9 shows a sample topology for a VPLS configuration.
Figure 9 mLACP with VPLS PE Redundancy

VPLS
DHD1 DHD4
L4 L8
PW2
L3 PE1 PW1 PE2 L7
DHD2 PW5 PW6 DHD3

L2 PW3 L6
L1 PE3 PW4 PE4 L5
277543
Active PoA for VPLS

The following VPLS sample configuration is for an active PoA:
!
redundancy
mode sso
member ip 201.0.0.1
monitor peer bfd
mlacp node-id 0
!
l2 vfi VPLS_200 manual
vpn id 10
39
Multichassis LACP
neighbor 210.0.0.1 encapsulation mpls

!
interface Loopback0
ip address 200.0.0.1 255.255.255.255
!
no ip address
lacp max-bundle 1
bridge-domain 200
!
no ip address
!
ip address 10.0.0.200 255.255.255.0
mpls ip
!
interface Vlan200
no ip address
xconnect vfi VPLS_200
Standby PoA for VPLS

The following VPLS sample configuration is for a standby PoA:
!
redundancy
member ip 200.0.0.1
monitor peer bfd
mlacp node-id 1
!
l2 vfi VPLS1 manual
vpn id 10
!
interface Loopback0
ip address 201.0.0.1 255.255.255.255
!
no ip address
lacp max-bundle 1
bridge-domain 200
!
40
Multichassis LACP
no ip address
!
ip address 10.0.0.201 255.255.255.0
mpls ip
!
interface Vlan200
no ip address
xconnect vfi VPLS_200
Example: Configuring H-VPLS

Two sample configurations for H-VPLS follow: one example for an active PoA and the other for a
standby PoA.
Figure 10 shows a sample topology for a H-VPLS configuration.
Figure 10 mLACP with H-VPLS uPE and nPE Redundancy

EoMPLS VPLS
DHD1
L2
PW2 PW5
uPE1 nPE1 nPE3
L1 PW1 PW6
PW9 PW10
PW3 PW7
uPE2 PW4 nPE2 PW8 nPE4
277544
PW3, PW2 Primary
PW4, PW1 Backup
Active PoA for H-VPLS

The following H-VPLS sample configuration is for an active PoA:
!
redundancy
mode sso
member ip 201.0.0.1
monitor peer bfd
mlacp node-id 0
!
41
Multichassis LACP
encapsulation mpls
!
interface Loopback0
ip address 200.0.0.1 255.255.255.255
!
no ip address
lacp max-bundle 1
hold-queue 300 in
!
no ip address
!
ip address 10.0.0.200 255.255.255.0
mpls ip
Standby PoA for H-VPLS

The following H-VPLS sample configuration is for a standby PoA:
!
Redundancy
mode sso
member ip 200.0.0.1
monitor peer bfd
mlacp node-id 1
!
encapsulation mpls
!
interface Loopback0
ip address 201.0.0.1 255.255.255.255
!
no ip address
lacp max-bundle 1
hold-queue 300 in
!
42
Multichassis LACP
no ip address
!
ip address 10.0.0.201 255.255.255.0
mpls ip
Example: Verifying VPWS on an Active PoA

The following show commands can be used to display statistics and configuration parameters to verify
the operation of the mLACP feature on an active PoA:
• show lacp multichassis group, page 43
• show lacp multichassis port-channel, page 44
• show mpls ldp iccp, page 44
• show mpls l2transport, page 45
• show etherchannel summary, page 45
• show etherchannel number port-channel, page 45
• show lacp internal, page 46
show lacp multichassis group

Use the show lacp multichassis group command to display the interchassis redundancy group value and
the operational LACP parameters.
Router# show lacp multichassis group 100
Interchassis Redundancy Group 100
Operational LACP Parameters:
RG State: Synchronized
System-Id: 200.000a.f331.2680
ICCP Version: 0
Backbone Uplink Status: Connected
Local Configuration:
Node-id: 0
System-Id: 200.000a.f331.2680
Peer Information:
State: Up
Node-id: 7
System-Id: 2000.0014.6a8b.c680
ICCP Version: 0
State Flags: Active - A

Standby - S
Down - D
AdminDown - AD
Standby Reverting - SR
Unknown - U
mLACP Channel-groups
Channel State Priority Active Links Inactive Links
Group Local/Peer Local/Peer Local/Peer Local/Peer
1 A/S 28000/32768 4/4 0/0
43
Multichassis LACP
show lacp multichassis port-channel

Use the show lacp multichassis port-channel command to display the interface port-channel value
channel group, LAG state, priority, inactive links peer configuration, and standby links.
Router# show lacp multichassis port-channel1
Interface Port-channel1
Address: 000a.f331.2680
Channel Group: 1
State: Active
LAG State: Up
Priority: 28000
Inactive Links: 0
Total Active Links: 4
Bundled: 4
Selected: 4
Standby: 0
Unselected: 0
Peer Configuration:
Interface: Port-channel1
Address: 0014.6a8b.c680
Channel Group: 1
State: Standby
LAG State: Up
Priority: 32768
Inactive Links: 0
Bundled: 0
Selected: 0
Standby: 4
Unselected: 0
show mpls ldp iccp

Use the show mpls ldp iccp command to display the LDP session and ICCP state information.
Router# show mpls ldp iccp
ICPM RGID Table

iccp:
rg_id: 100, peer addr: 172.3.3.3
ldp_session 0x3, client_id 0
iccp state: ICPM_ICCP_CONNECTED
app type: MLACP
app state: ICPM_APP_CONNECTED, ptcl ver: 0
ICPM RGID Table total ICCP sessions: 1
ICPM LDP Session Table
iccp:
rg_id: 100, peer addr: 172.3.3.3
app type: MLACP
ICPM LDP Session Table total ICCP sessions: 1
44
Multichassis LACP
show mpls l2transport

Use the show mpls l2transport command to display the local interface and session details, destination
address, and status.
Router# show mpls l2transport vc 2
Local intf Local circuit Dest address VC ID Status

------------- -------------------------- --------------- ---------- ----------
Po1 Eth VLAN 2 172.2.2.2 2 UP
Po1 Eth VLAN 2 172.4.4.4 2 STANDBY
show etherchannel summary

Use the show etherchannel summary command to display the status and identity of the mLACP
member links.
Router# show etherchannel summary
Flags: D - down P - bundled in port-channel

I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met

u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 2

Number of aggregators: 2
Group Port-channel Protocol Ports

------+-------------+-----------+-----------------------------------------------
1 Po1(RU) LACP Gi2/9(P) Gi2/20(P) Gi2/31(P)
show etherchannel number port-channel

Use the show etherchannel number port-channel command to display the status and identity of the
EtherChannel and and port channel.
Router# show etherchannel 51 port-c
Port-channels in the group:

----------------------
Port-channel: Po51 (Primary Aggregator)
------------
Age of the Port-channel = 0d:02h:25m:23s

Logical slot/port = 14/11 Number of ports = 2
HotStandBy port = null
Passive port list = Gi9/15 Gi9/16
Port state = Port-channel L3-Ag Ag-Inuse
Protocol = LACP
Fast-switchover = enabled
45
Multichassis LACP
Direct Load Swap = disabled
Ports in the Port-channel:
Index Load Port EC state No of bits

------+------+--------+------------------+-----------
0 55 Gi9/15 mLACP-stdby 4
1 AA Gi9/16 mLACP-stdby 4
Time since last port bundled: 0d:01h:03m:39s Gi9/16

Time since last port Un-bundled: 0d:01h:03m:40s Gi9/16
Last applied Hash Distribution Algorithm: Fixed Channel-group Iedge Counts:

--------------------------:
Access ref count : 0
Iedge session count : 0
show lacp internal

Use the show lacp internal command to display the device, port, and member- link information.
Router# show lacp internal
Flags: S - Device is requesting Slow LACPDUs

F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 1
LACP port Admin Oper Port Port
Port Flags State Priority Key Key Number State
Gi2/9 SA bndl-act 28000 0x1 0x1 0x820A 0x3D
Gi2/20 SA bndl-act 28000 0x1 0x1 0x8215 0x3D
Peer (MLACP-PE3) mLACP member links
Gi3/11 FA hot-sby 32768 0x1 0x1 0xF30C 0x5

Gi3/21 FA hot-sby 32768 0x1 0x1 0xF316 0x5
Example: Verifying VPWS on a Standby PoA

the operation of the mLACP feature on a standby PoA:
• show lacp multichassis portchannel, page 47
46
Multichassis LACP

Use the show lacp multichassis group command to display the LACP parameters, local configuration,
status of the backbone uplink, peer information, node ID, channel, state, priority active, and inactive
links.

System-Id: 200.000a.f331.2680
ICCP Version: 0
Node-id: 7
System-Id: 2000.0014.6a8b.c680
Peer Information:
State: Up
Node-id: 0
System-Id: 200.000a.f331.2680
ICCP Version: 0

Standby - S
Down - D
AdminDown - AD
Unknown - U
1 S/A 32768/28000 4/4 0/0
show lacp multichassis portchannel

Use the show lacp multichassis portchannel command to display the interface port-channel value
Channel Group: 1
State: Standby
LAG State: Up
Priority: 32768
Inactive Links: 0
Bundled: 0
Selected: 0
Standby: 4
Unselected: 0
Peer Configuration:
Address: 000a.f331.2680
Channel Group: 1
State: Active
47
Multichassis LACP
LAG State: Up
Priority: 28000
Inactive Links: 0
Bundled: 4
Selected: 4
Standby: 0
Unselected: 0
show mpls ldp iccp

ICPM RGID Table

iccp:
rg_id: 100, peer addr: 172.1.1.1
app type: MLACP
iccp:
rg_id: 100, peer addr: 172.1.1.1
app type: MLACP


------------- -------------------------- --------------- ---------- ----------

member links.


48
Multichassis LACP
d - default port


------+-------------+-----------+-----------------------------------------------
Gi3/32(P)
show lacp internal

Use the show lacp internal command to display the device, port, and member-link information.
Router# show lacp 1 internal

Channel group 1
Gi3/2 FA bndl-sby 32768 0x1 0x1 0xF303 0x7
Gi3/11 FA bndl-sby 32768 0x1 0x1 0xF30C 0x5
Gi2/20 SA bndl 28000 0x1 0x1 0x8215 0x3D

Gi2/31 SA bndl 28000 0x1 0x1 0x8220 0x3D
Gi2/40 SA bndl 28000 0x1 0x1 0x8229 0x3D
Gi2/9 SA bndl 28000 0x1 0x1 0x820A 0x3D
Example: Verifying VPLS on an Active PoA

the operation of the mLACP feature on an active PoA:
• show lacp multichassis port-channel, page 50

Use the show lacp multichassis group command to display the LACP parameters, local configuration,
status of the backbone uplink, peer information, node ID, channel, state, priority active, and inactive
links.
49
Multichassis LACP

System-Id: 200.000a.f331.2680
ICCP Version: 0
Node-id: 0
System-Id: 200.000a.f331.2680
Peer Information:
State: Up
Node-id: 7
System-Id: 2000.0014.6a8b.c680
ICCP Version: 0

Standby - S
Down - D
AdminDown - AD
Unknown - U
1 A/S 28000/32768 4/4 0/0
show lacp multichassis port-channel

Use the show lacp multichassis port-channel command to display the interface port-channel value
Address: 000a.f331.2680
Channel Group: 1
State: Active
LAG State: Up
Priority: 28000
Inactive Links: 0
Bundled: 4
Selected: 4
Standby: 0
Unselected: 0
Peer Configuration:
Channel Group: 1
State: Standby
LAG State: Up
Priority: 32768
Inactive Links: 0
Bundled: 0
50
Multichassis LACP
Selected: 0
Standby: 4
Unselected: 0
show mpls ldp iccp

ICPM RGID Table

iccp:
rg_id: 100, peer addr: 172.3.3.3
app type: MLACP
iccp:
rg_id: 100, peer addr: 172.3.3.3
app type: MLACP

address, and the status.

------------- -------------------------- --------------- ---------- ----------
VFI VPLS VFI 172.2.2.2 4000 UP

member links.


d - default port

51
Multichassis LACP

------+-------------+-----------+-----------------------------------------------
Gi2/40(P)
show lacp internal

Use the show lacp internal command to display the device, port, and member-link information.
Router# show lacp internal
Channel group 1
Gi2/9 SA bndl-act 28000 0x1 0x1 0x820A 0x3D
Gi3/11 FA hot-sby 32768 0x1 0x1 0xF30C 0x5

Example: Verifying VPLS on a Standby PoA

The show commands in this section can be used to display statistics and configuration parameters to
verify the operation of the mLACP feature:
• show lacp multichassis portchannel, page 53
• show mpls l2transport vc 2, page 54

Use the show lacp multichassis group interchassis group number command to display the LACP
parameters, local configuration, status of the backbone uplink, peer information, node ID, channel, state,
priority, active, and inactive links.

System-Id: 200.000a.f331.2680
ICCP Version: 0
52
Multichassis LACP

Node-id: 7
System-Id: 2000.0014.6a8b.c680
Peer Information:
State: Up
Node-id: 0
System-Id: 200.000a.f331.2680
ICCP Version: 0

Standby - S
Down - D
AdminDown - AD
Unknown - U
1 S/A 32768/28000 4/4 0/0
show lacp multichassis portchannel

Use the show lacp multichassis portchannel command to display the interface port-channel value
Channel Group: 1
State: Standby
LAG State: Up
Priority: 32768
Inactive Links: 0
Bundled: 0
Selected: 0
Standby: 4
Unselected: 0
Peer Configuration:
Address: 000a.f331.2680
Channel Group: 1
State: Active
LAG State: Up
Priority: 28000
Inactive Links: 0
Bundled: 4
Selected: 4
Standby: 0
Unselected: 0
53
Multichassis LACP
show mpls ldp iccp

ICPM RGID Table

iccp:
rg_id: 100, peer addr: 172.1.1.1
app type: MLACP
iccp:
rg_id: 100, peer addr: 172.1.1.1
app type: MLACP
show mpls l2transport vc 2


------------- -------------------------- --------------- ---------- ----------

member links.


d - default port


------+-------------+-----------+-----------------------------------------------
Gi3/32(P)
54
Multichassis LACP
Additional References
show lacp internal

Use the show lacp internal command to display the device, port, and member- link information.
Router# show lacp 1 internal
Channel group 1
Gi3/11 FA bndl-sby 32768 0x1 0x1 0xF30C 0x5
Gi2/20 SA bndl 28000 0x1 0x1 0x8215 0x3D

Gi2/31 SA bndl 28000 0x1 0x1 0x8220 0x3D
Gi2/40 SA bndl 28000 0x1 0x1 0x8229 0x3D
Gi2/9 SA bndl 28000 0x1 0x1 0x820A 0x3D
Related Documents
Related Topic Document Title
Carrier Ethernet configurations Cisco IOS Carrier Ethernet Configuration Guide, Release 12.2SR
Carrier Ethernet commands: complete command Cisco IOS Carrier Ethernet Command Reference
syntax, command mode, command history, defaults,
usage guidelines, and examples
Cisco IOS commands: master list of commands with Cisco IOS Master Command List, All Releases
complete command syntax, command mode, command
history, defaults, usage guidelines, and examples
Standards
Standard Title
IEEE 802.3ad Link Aggregation Control Protocol
IEEE 802.1ak Multiple Registration Protocol
55
Multichassis LACP
MIBs
MIB MIBs Link
• Cisco-LAG-MIB To locate and download MIBs for selected platforms, Cisco software
• IEEE 802.3ad-MIB releases, and feature sets, use Cisco MIB Locator found at the
following URL:
• IEEE8023-LAG-MIB
http://www.cisco.com/go/mibs
RFCs
RFC Title
RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution
Protocol (LDP) Signaling
RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
Technical Assistance
Description Link
The Cisco Support and Documentation website http://www.cisco.com/cisco/web/support/index.html
provides online resources to download documentation,
software, and tools. Use these resources to install and
configure the software and to troubleshoot and resolve
technical issues with Cisco products and technologies.
Access to most tools on the Cisco Support and
Documentation website requires a Cisco.com user ID
and password.
56
Multichassis LACP
Feature Information for mLACP
Feature Information for mLACP

Table 2 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support.
Cisco Feature Navigator enables you to determine which software images support a specific software
release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.
An account on Cisco.com is not required.
Note Table 2 lists only the software release that introduced support for a given feature in a given software
release train. Unless noted otherwise, subsequent releases of that software release train also support that
feature.
Table 2 Feature Information for mLACP
Feature Name Releases Feature Information

Multichassis LACP (mLACP) 12.2(33)SRE Cisco’s mLACP feature addresses the need for interchassis
15.0(1)S redundancy mechanisms when a carrier wants to dual home
a device to two upstream PoAs for redundancy. The mLACP
feature enhances the 802.3ad LACP implementation to meet
this requirement.
The following commands were introduced or modified:
backbone interface, debug acircuit checkpoint, debug
lacp, ethernet mac-flush mirp notification, interchassis
group, lacp failover, lacp max-bundle, lacp min-bundle,
member ip, mlacp interchassis group, mlacp
lag-priority, mlacp node-id, mlacp system-mac, mlacp
system-priority, monitor peer bfd, redundancy, show
ethernet service instance interface port-channel, show
ethernet service instance id mac-tunnel, show lacp,
status decoupled, status peer topology dual-homed.
57
Multichassis LACP
Glossary
Glossary
Active attachment circuit—The link that is actively forwarding traffic between the DHD and the active
PoA.
Active PW—The pseudowire that is forwarding traffic on the active PoA.
BD—bridge domain.
BFD—bidirectional forwarding detection.
DHD—dual-homed device. A node that is connected to two switches over a multichassis link
aggregation group for purpose of redundancy.
DHN—dual-homed network. A network that is connected to two switches to provide redundancy.
H-VPLS—Hierarchical Virtual Private LAN Service.
ICC—Interchassis Communication Channel.
ICCP—Interchassis Communication Protocol.
ICPM—Interchassis Protocol Manager.
ICRM—Interchassis Redundancy Manager.
LACP—Link Aggregation Control Protocol.
LAG—link aggregation group.
LDP—Link Distribution Protocol.
MCEC—Multichassis EtherChannel.
mLACP—Multichassis LACP.
PoA—point of attachment. One of a pair of switches running multichassis link aggregation group with
a DHD.
PW-RED—pseudowire redundancy.
Standby attachment circuit—The link that is in standby mode between the DHD and the standby PoA.
Standby PW—The pseudowire that is in standby mode on either an active or a standby PoA.
uPE—user-facing Provider Edge.
VPLS—Virtual Private LAN Service.
VPWS—Virtual Private Wire Service.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks
can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word
partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any
examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only.
Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2009–2011 Cisco Systems, Inc. All rights reserved.
58

Multichassis Lacp

Uploaded by

Copyright:

Available Formats

Multichassis Lacp

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multichassis Lacp

Uploaded by

Copyright:

Available Formats

Multichassis LACP

First Published: December 11, 2009

Finding Feature Information

• How to Configure mLACP, page 17

Prerequisites for mLACP

Restrictions for mLACP

Information About mLACP

Overview of Multichassis EtherChannel

Figure 1 MCEC with mLACP

Interactions with the MPLS Pseudowire Redundancy Mechanism

Redundancy Mechanism Processes

Figure 2 Redundancy Mechanisms in Carrier Ethernet Networks

Dual-Homed Topology Using mLACP

LACP and 802.3ad Parameter Exchange

System MAC Address

Failure Protection Scenarios

Figure 3 mLACP Protected Failure Points

Shared Control (PoA and DHD)

Dynamic Port Priority

Revertive and Nonrevertive Modes

Brute Force Shutdown

Peer Monitoring with Interchassis Redundancy Manager

An example of output from the show redundancy interface command follows:

Redundancy Group 1 (0x1)

ICRM fast-failure detection neighbor table

Table 1 Status Information from the show redundancy interchassis command

Adjacency Type Adjacency Status Meaning

Note If the adjacency type is “BFD,” RW is UP regardless of the BFD status.

MAC Flushing Mechanisms

Multiple I-SID Registration Protocol

Figure 4 Traffic Blackholing in an 802.1ah Network

DHD1 BCB BEB 3 DHD2

BEB 2 C-MAC B-MAC

DHD1 BCB BEB 3 DHD2

BEB 2 C-MAC B-MAC

Figure 5 shows the operation of the MIRP.

Figure 5 Operation of MIRP for C-MAC Flushing in 802.1ah Networks

DHD1 BCB BEB 3 DHD2

BEB 2 C-MAC B-MAC

DHD1 BCB BEB 3 DHD2

LDP MAC Address Withdraw

How to Configure mLACP

Configuring Interchassis Group and Basic mLACP Commands

Command or Action Purpose

Command or Action Purpose

Configuring the mLACP Interchassis Group and Other Port-Channel Commands

Command or Action Purpose

Configuring Redundancy for VPWS

Command or Action Purpose

Step 19 exit Exits service instance configuration mode.

Configuring Redundancy for VPLS

Coupled and Decoupled Modes for VPLS

Figure 6 VPLS Coupled Mode States

Active Active Standby Standby

Figure 7 VPLS Decoupled Mode States

Standby Active Standby Active

Steps for Configuring Redundancy for VPLS

24. xconnect vfi vfi-name

Command or Action Purpose