MultiChassis LAG

Multi-Chassis LAG and Pseudowire
Redundancy Interworking
In This Chapter
This section provides information about Multi-Chassis Link Aggregation (MC-LAG) and
pseudowire redundancy interworking.
Topics in this section include:
Applicability on page 142
Overview on page 143
Configuration on page 146
Conclusion on page 167
7750 SR Advanced Configuration Guide
Page 141
Applicability
Applicability
This feature is supported on all 7x50 platforms including the 7710 SR. MC-LAG is supported only
on Ethernet MDAs, and this only for access ports (the given LAG group must be in access mode).
The configuration was tested on release 7.0R5. The 7750 SR-c4 is supported from 8.0R4 and
higher.
Page 142
Multi-Chassis LAG and Pseudowire Redundancy
Overview
MC-LAG
MC-LAG is an extension to the LAG feature to provide not only link redundancy but also nodelevel redundancy. This feature provides an Alcatel-Lucent added value solution which is not
defined in any IEEE standard.
A proprietary messaging between redundant-pair nodes supports coordinating the LAG
switchover.
Multi-chassis LAG supports LAG switchover coordination: one node connected to two redundantpair peer nodes with the LAG. During the LACP negotiation, the redundant-pair peer nodes act
like a single node using active/stand-by signaling to ensure that only links of one peer node is used
at a time.
Pseudowire Redundancy
Pseudowire (PW) redundancy provides the ability to protect a pseudowire with a pre-provisioned
pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or
network failure condition. Normally, pseudowires are redundant by the virtue of the SDP
redundancy mechanism. For instance, if the SDP is an RSVP LSP and is protected by a secondary
standby path and/or by Fast-Reroute paths, the pseudowire is also protected.
However, there are a few of applications in which SDP redundancy does not protect the end-toend pseudowire path when there are two different destination 7x50 PE nodes for the same VLL
service. The main use case is the provision of dual-homing of a CPE or access node to two 7x50
PE nodes located in different POPs. The other use case is the provisioning of a pair of active and
standby BRAS nodes, or active and standby links to the same BRAS node, to provide service
resiliency to broadband service subscribers.
Page 143
Network Topology
Network Topology
192.0.2.3
192.0.2.1
1/1/1
1/1/4
PE-1
LAG
192.168.13.0/30
.1
1/1/3
.2
PE-3
LAG
1/1/1
1/1/1
1/1/2
.1
1/1/3
1/1/2 .1
1/1/1
CE-1
1/1/2
172.16.12.1/30
1/1/3
192.168.12.0/30
192.168.34.0/30
172.16.12.2/30
CE-2
1/1/2
.2
1/1/4
1/1/2 .2
1/1/1
1/1/1
192.0.2.4
192.0.2.2
PE-2
192.168.24.0/30
.2
PE-4
1/1/1
1/1/3
1/1/2
OSSG380
Figure 25: MC-LAG Network Topology
This section describes a setup which contains 2 CE and 4 PE nodes. The CE nodes can be any
routing/switching device that support the OUT_OF_SYNC signaling as described in IEEE
Standard 802.3-2005 section 3 section 43.6.1. Figure 25 shows the physical topology of the setup.
Figure 26 shows the use of both MC-LAG in the access network and pseudowire redundancy in
the core network to provide a resilient end-to-end VLL service between CE1 and CE2.
Page 144
TLDP
PE-1
PE-3
Active
Active
Standby
Active
LAG
LAG
Inter-chassis
PW for VLL
CE-1
Inter-chassis
PW ICE VLL
Standby
Standby
Standby
Standby
CE-2
Active
Active
PE-2
Standby
Active
PE-4
TLDP
PE-1
PE-3
Active
Standby
LAG
CE-1
LAG
Inter-chassis
PW ICE VLL
Standby
Inter-chassis
PW ICE VLL
PE-2
PE-4
CE-2
Active
OSSG381
Figure 26: Network Resiliency
Note in Figure 26 that when an SDP is in standby it sends the pseudowire status bit
pwFwdingStandby to its peer.
Page 145
Configuration
Configuration
It is assumed that the following base configuration has been implemented on the PEs:
Cards, MDAs and ports
Interfaces
IGP configured and converged
MPLS
SDPs configured between all PE routers
Note that either OSPF and IS-IS can be used as the IGP. Both LDP or RSVP can be used for
signaling the transport MPLS labels. Alternatively, GRE can be used for the transport tunnels.
It does not matter if the SDPs are using LDP, RSVP or GRE. RSVP has the added value of
offering FRR to get faster convergence in the core. In this example OSPF and LDP are used.
The following commands can be used to check if OSPF has converged and to make sure the SDPs
are up (for example, on PE-1):
*A:PE-1# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
00h29m42s
0
system
0
192.0.2.2/32
Remote OSPF
00h28m37s
10
192.168.12.2
100
192.0.2.3/32
Remote OSPF
00h27m53s
10
192.168.13.2
100
192.0.2.4/32
Remote OSPF
00h27m02s
10
192.168.12.2
200
192.168.12.0/30
Local
Local
00h29m42s
0
int-PE-1-PE-2
0
192.168.13.0/30
Local
Local
00h29m42s
0
int-PE-1-PE-3
0
192.168.24.0/30
Remote OSPF
00h28m37s
10
192.168.12.2
200
192.168.34.0/30
Remote OSPF
00h27m53s
10
192.168.13.2
200
------------------------------------------------------------------------------No. of Routes: 8
===============================================================================
*A:PE-1#
Page 146
*A:PE-1# show service sdp

===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Adm MTU
Opr MTU
IP address
Adm Opr
Deliver Signal
------------------------------------------------------------------------------12
0
1556
192.0.2.2
Up
Up
LDP
TLDP
13
0
1556
192.0.2.3
Up
Up
LDP
TLDP
14
0
1556
192.0.2.4
Up
Up
LDP
TLDP
------------------------------------------------------------------------------Number of SDPs : 3
------------------------------------------------------------------------------===============================================================================
*A:PE-1#
Page 147
Configuration
Step 1.
MC-LAG configuration.
LAG configuration on CEs. Note that this is only included for completeness of the example, any
CE device could be used.
Auto-negotiation must be switched off or set to limited on all ports that will be included into the
LAG.
Configure LACP on the LAG. At least one side of the LAG must be configured in active mode.
*A:CE1#
*A:CE1#
*A:CE1#
*A:CE1#
*A:CE1#
Step 1.1
configure
configure
configure
configure
configure
port 1/1/[1..4] ethernet autonegotiate limited

port 1/1/[1..4] no shut
lag 1 port 1/1/1 1/1/2 1/1/3 1/1/4
lag 1 lacp active
lag 1 no shutdown
LAG configuration on PEs.
The PE ports connected to the CEs must be configured as access ports since they will be used in
the redundant pseudowire service. The LAG must also be configured in mode access.
Note that the LAG encapsulation type (null | dot1q | qinq) must match the port encapsulation type
of the LAG members.
Auto-negotiation must be switched off or configured to limited.
Configure LACP on the LAG. At least 1 side of the LAG (PE or CE) must be configured in active
mode.
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
Page 148
configure
configure
configure
configure
configure
configure
configure
port 1/1/[1..2] ethernet autonegotiate limited

port 1/1/[1..2] ethernet mode access
port 1/1/[1..2] no shut
lag 1 mode access
lag 1 port 1/1/1 1/1/2
lag 1 lacp active
lag 1 no shutdown
Step 1.2
MC-LAG configuration on PE1 and PE2
The redundant PEs must act as 1 virtual node toward the CE. They have to be able to communicate
the same LACP parameters to the CE side.
The following parameters uniquely identify a LAG instance:
lacp-key
system-id
system-priority
These three parameters must be configured with the same value on both redundant PEs.
Configure multi-chassis redundancy with a peering session (which operates by an IP connection
using UDP destination port 1025) toward the redundant PE system address and enable MC-LAG
redundancy. The peering session can be configured with MD5 authentication.
*A:PE-1>config>redundancy>multi-chassis# info
---------------------------------------------peer 192.0.2.2 create
authentication-key "441dO/0RgDhHgzYwpOCTK9zbKjv4GZ/z" hash2
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100
no shutdown
exit
no shutdown
exit
---------------------------------------------*A:PE-1>config>redundancy>multi-chassis#
*A:PE-2>config>redundancy>multi-chassis# info
---------------------------------------------peer 192.0.2.1 create
authentication-key "441dO/0RgDg2CA0JlyzVNQBoRc327b1j" hash2
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100
no shutdown
exit
no shutdown
exit
---------------------------------------------*A:PE-2>config>redundancy>multi-chassis#
Page 149
Configuration
Step 1.3
MC-LAG verification.
Verify MC peers showing that the authentication and admin state are enabled.
*A:PE-1# show redundancy multi-chassis sync
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.2
Description
: (Not Specified)
Authentication
: Enabled
Source IP Address
: 192.0.2.1
Admin State
: Enabled
------------------------------------------------------------------------------Sync: Not-configured
------------------------------------------------------------------------------===============================================================================
*A:PE-1#
Step 1.4
Verify MC-LAG peer status and LAG parameters.
*A:PE-1# show redundancy multi-chassis mc-lag peer 192.0.2.2

===============================================================================
Multi-Chassis MC-Lag Peer 192.0.2.2
===============================================================================
Last State chg : 11/01/2009 11:07:48
Admin State
: Up
Oper State
: Up
KeepAlive
: 10 deci-seconds
Hold On Ngbr Failure : 3
------------------------------------------------------------------------------Lag Id Lacp Key Remote Lag Id System Id
Sys Prio Last State Changed
------------------------------------------------------------------------------1
1
1
00:00:00:00:00:01 100
11/01/2009 11:06:08
------------------------------------------------------------------------------Number of LAGs : 1
===============================================================================
*A:PE-1#
Note that there is a fixed keepalive timer of 1 second. The hold-on-neighbor-failure multiplier
command indicates the interval that the standby node will wait for packets from the active node
before assuming a redundant-neighbor failure. The hold-on-neighbor-failure multiplier
command is configurable (2-25) in the config>redundancy>multi-chassis>peer>mc-lag
context. The standby node will also assume a redundant-neighbor failure when there is no route
available to the redundant-neighbor.
In this example the lag-id is 1 on both redundant PEs. This is not mandatory. If the lag-id on PE-2
is, for example 2, the following should be configured on PE-1:
*A:PE-1# configure redundancy multi-chassis
*A:PE-1>config>redundancy>multi-chassis# peer 192.0.2.2 mc-lag lag 1 remote-lag 2 lacp-key
1 system-id 00:00:00:00:00:01 system-priority 100
Page 150
Step 1.5
Verify MC-LAG status
*A:PE-1# show lag 1

===============================================================================
Lag Data
===============================================================================
Lag-id
Adm
Opr
Port-Threshold
Up-Link-Count
MC Act/Stdby
------------------------------------------------------------------------------1
up
up
0
2
active
===============================================================================
*A:PE-1#
*A:PE-2# show lag 1

===============================================================================
Lag Data
===============================================================================
Lag-id
Adm
Opr
Port-Threshold
Up-Link-Count
MC Act/Stdby
------------------------------------------------------------------------------1
up
down
0
0
standby
===============================================================================
*A:PE-2#
In this case the LAG on PE-1 is active (operationally up) whereas the LAG on PE-2 is standby
(operationally down).
The selection criteria by default is highest number of links and priority. In this example the
number of links and the priority of the links is the same on both redundant PEs. Whichever PEs
LAG gets the operational status up first will be the active.
LAG ports of one PE could be preferred over the other PE by configuring port priority (for
example, the following command lowers the priority of the LAG ports on PE-1, thus giving this
LAG higher preference).
*A:PE1# configure lag 1 port 1/1/1 1/1/2 priority 10
Note that the selection criteria can be configured as highest-count or highest-weight (the default is
highest count). If highest-weight is configured (or in case the number of active MC-LAG links are
the same on both MC-LAG PEs), the sum of the weights of the LAG members is considered. The
weight of an individual LAG member is calculated as 65535 priority (the default is 32768).
Page 151
Configuration
Step 1.6
Verify detailed MC-LAG status on PE-1
*A:PE-1# show lag 1 detail

===============================================================================
LAG Details
===============================================================================
Description
: N/A
------------------------------------------------------------------------------Details
------------------------------------------------------------------------------Lag-id
: 1
Mode
: access
Adm
: up
Opr
: up
Thres. Exceeded Cnt : 1
Port Threshold
: 0
Thres. Last Cleared : 11/01/2009 11:06:10
Threshold Action
: down
Dynamic Cost
: false
Encap Type
: null
Configured Address : 1e:51:ff:00:01:41
Lag-IfIndex
: 1342177281
Hardware Address
: 1e:51:ff:00:01:41
Adapt Qos
: distribute
Hold-time Down
: 0.0 sec
Port Type
: standard
Per FP Ing Queuing : disabled
LACP
: enabled
Mode
: active
LACP Transmit Intvl : fast
LACP xmit stdby
: enabled
Selection Criteria : highest-count
Slave-to-partner
: disabled
Number of sub-groups: 1
Forced
: System Id
: 1e:51:ff:00:00:00
System Priority
: 32768
Admin Key
: 32768
Oper Key
: 1
Prtr System Id
: 1e:50:ff:00:00:00
Prtr System Priority : 32768
Prtr Oper Key
: 32768
MC Peer Address
: 192.0.2.2
MC Peer Lag-id
: 1
MC System Id
: 00:00:00:00:00:01
MC System Priority
: 100
MC Admin Key
: 1
MC Active/Standby
: active
MC Lacp ID in use
: true
MC extended timeout : false
MC Selection Logic : peer decided
MC Config Mismatch : no mismatch
------------------------------------------------------------------------------Port-id
Adm
Act/Stdby Opr
Primary
Sub-group
Forced Prio
------------------------------------------------------------------------------1/1/1
up
active
up
yes
1
10
1/1/2
up
active
up
1
10
------------------------------------------------------------------------------Port-id
Role
Exp
Def
Dist Col
Syn
Aggr Timeout Activity
------------------------------------------------------------------------------1/1/1
actor
No
No
Yes
Yes
Yes
Yes
Yes
Yes
1/1/1
partner
No
No
Yes
Yes
Yes
Yes
Yes
Yes
1/1/2
actor
No
No
Yes
Yes
Yes
Yes
Yes
Yes
1/1/2
partner
No
No
Yes
Yes
Yes
Yes
Yes
Yes
===============================================================================
*A:PE-1#
After changing the LAG port priorities the LAG on PE-1 is in up/up state and the ports are in up/
active/up status. This show command also displays actor and partner bits set in the LACP
messages.
Page 152
Step 1.7
MC-LAG configuration on PE-3 and PE-4.
The MC-LAG configuration on PE-3 and PE-4 is similar to the configuration on PE-1 and PE-2.
In this case the priority of the LAG port on PE-4 is lowered to obtain the behavior in Figure 26
where LAG on PE-1 and PE-4 is active.
Step 1.8
Pseudowire configuration.
Configure an Epipe service on every PE and create endpoints x and y (the endpoint names can be
any text string). Traffic can only be forwarded between two endpoints, for example, it is not
possible for objects associated with the same endpoint to forward traffic to each other.
Associate the SAPs and spoke SDPs with the endpoints like shown in Figure 27.
PE-1
epipe
X Y SDP
LAG
PE-3
epipe
Y
SDP X
SAP
SAP
SDP
SDP
LAG
MC-LAG
MC-LAG
CE-1
CE-2
PE-4
PE-2
SDP
LAG
SDP
LAG
SAP
SAP
X Y
epipe
SDP
SDP
X Y
epipe
OSSG382
Figure 27: Association of SAPs/SDPs and Endpoints
Page 153
Configuration
*A:PE-1>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap lag-1 endpoint "x" create
exit
spoke-sdp 13:1 endpoint "y" create
exit
exit
no shutdown
---------------------------------------------*A:PE-1>config>service>epipe#
Likewise, an Epipe service, endpoints, SAPs and spoke SDPs must be configured on the other PE
routers.
Page 154
Step 1.9
Pseudowire verification.
*A:PE-1# show service service-using

===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Up
1
11/01/2009 11:55:13
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-1#

===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Down
1
11/01/2009 11:55:38
------------------------------------------------------------------------------==============================================================================
*A:PE-2#

===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Down
1
11/01/2009 10:56:10
------------------------------------------------------------------------------===============================================================================
*A:PE-3#

===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Up
1
11/01/2009 11:01:07
------------------------------------------------------------------------------===============================================================================
*A:PE-4#
Page 155
Configuration
The Epipe service on PE-2 and PE-3 is down and up on PE-1 and PE-4. This reflects the standby
behavior shown in Figure 26. Note that after configuring ICB spoke SDPs (described later in this
document) the Epipe will be in up/up status on all PE routers.
Page 156
Step 1.10 Verify SDP status
Peer pseudowire bits indicate the status of the pseudowire on the peer. Here is an example taken
on PE-2:
*A:PE-2# show service id 1 sdp 23:1 detail
===============================================================================
Service Destination Point (Sdp Id : 23:1) Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 23:1 -(192.0.2.3)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 23:1
Type
: Spoke
Split Horiz Grp
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 1556
Far End
: 192.0.2.3
Delivery
: LDP
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Ing ipv6 Fltr
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
Class Fwding State
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
Oper State
: Up
None
Collect Stats
: Disabled
131070
Egress Label
: 131070
n/a
Egr mac Fltr
: n/a
n/a
Egr ip Fltr
: n/a
n/a
Egr ipv6 Fltr
: n/a
Not Preferred
Oper ControlWord : False
0
Oper BW(Kbps)
: 0
11/01/2009 11:01:50
Signaling
: TLDP
10/29/2009 17:14:13
Force Vlan-Vc
: Disabled
y
Precedence
: 4
Down
None
lacIngressFault lacEgressFault pwFwdingStandby
None
lspPing
mplsRouterAlertLabel
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-2#
Page 157
Configuration
In this example, the remote side of the SDP is sending lacIngressFault lacEgressFault
pwFwdingStandby flags. This is because the Epipe service on PE-3 is down because the MC-LAG
is in standby/down status.
Link and node protection can be tested. The access links are protected by the MC-LAG, the PE
routers are protected by the combination of MC-LAG/pseudowire redundancy. The SDPs can be
protected by FRR in the case of RSVP-TE.
Revertive behavior is expected when different MC-LAG port priorities are configured or if the
number of MC-LAG ports is different on the MC-LAG peers: convergence takes place when the
active PE fails and convergence takes place again when that PE is online again.
In case of revertive behavior MC-LAG convergence might take less time than the setup of the
spoke SDPs, thus creating a temporary blackhole. To avoid this situation its best to configure
hold-time up on the LAG ports. In that case the ports are kept in a down state for a configured
period of time after the node has rebooted. This is done to ensure that the SDPs are operationally
up when the MC-LAG convergence takes place. hold-time up is expressed in seconds.
*A:PE-1# configure port 1/1/1 ethernet hold-time up 50
*A:PE-1# configure port 1/1/2 ethernet hold-time up 50
Step 1.11 Inter-Chassis Backup (ICB) pseudowire configuration.
Note that in this setup the configuration of ICBs is optional. It can be used to speed up
convergence by forwarding in-flight packets during MC-LAG transition. Figure 29 shows some
setup examples where ICBs are required. ICBs cannot be configured at endpoints where the other
object is a standard SAP, only MC-LAG SAPs and pseudowires are allowed with ICBs.
Configure ICB SDPs and associate them to endpoints like shown in Figure 28.
Page 158
LAG
SDP
MC-LAG
CE-1
PE-1
epipe
Y SDP
SAP X
SDP SDP
PE-3
epipe
Y SAP
SDP X
ICB Spoke-SDP
SDP SDP SDP
X Y
epipe
MC-LAG
ICB Spoke-SDP
SDP
CE-2
SDP SDP SDP
LAG
SAP
LAG
SDP SDP SDP
SDP
X Y SAP
epipe
PE-2
LAG
PE-4
OSSG383
Figure 28: ICB Spoke SDPs and Their Association with the Endpoints
Two ICB spoke SDPs must be configured in the Epipe service on each PE router, one in each
endpoint. Different SDP IDs can be used for the ICBs (as opposed to the regular pseudowires) but
this is not necessary since the far-end will be the same. The vc-id must be different however.
The ICB spoke SDPs must cross, one end should be associated with endpoint x and the other end
(on the other PE) should be associated with endpoint y. Note that after configuring the ICB spoke
SDPs the Epipe service will be up/up on all four PE routers.
Only one spoke SDPs will be forwarding. If there is an ICB and a MC-LAG SAP in an endpoint
the ICB will only forward if the SAP goes down. If an ICB resides in an endpoint together with
other spoke SDPs the ICB will only forward if there is no other active spoke SDP.
The following output shows the complete Epipe service configuration on each PE:
exit
endpoint "y" create
exit
exit
exit
exit
spoke-sdp 12:1 endpoint "x" icb create
Page 159
Configuration
exit
spoke-sdp 12:2 endpoint "y" icb create
exit
no shutdown
---------------------------------------------*A:PE-1>config>service>epipe
exit
endpoint "y" create
exit
exit
exit
exit
exit
exit
no shutdown
exit
endpoint "y" create
exit
sap lag-1 endpoint "y" create
exit
spoke-sdp 31:1 endpoint "x" create
exit
exit
exit
exit
no shutdown
exit
endpoint "y" create
exit
sap lag-1 endpoint "y" create
exit
Page 160
exit
exit
exit
exit
no shutdown
Page 161
Configuration
Step 1.12 Verification of active objects for each endpoint.
The following command shows which objects are configured for each endpoint and which is the
active object at this moment:
*A:PE-1# show service id 1 endpoint
===============================================================================
Service 1 endpoints
===============================================================================
Endpoint name
: x
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: true
Block On Mesh Fail
: false
Tx Active
: lag-1
Tx Active Up Time
: 0d 01:30:25
Revert Time Count Down
: N/A
Tx Active Change Count
: 2
Last Tx Active Change
: 11/01/2009 11:06:10
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------SAP
: lag-1
Oper Status: Up
Spoke-sdp: 12:1 Prec:4 (icb)
Oper Status: Up
===============================================================================
Endpoint name
: y
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: true
Block On Mesh Fail
: false
Tx Active
: 14:1
Tx Active Up Time
: 0d 01:30:48
Revert Time Count Down
: N/A
Tx Active Change Count
: 3
Last Tx Active Change
: 11/01/2009 11:05:48
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 12:2 Prec:4 (icb)
Oper Status: Up
Spoke-sdp: 13:1 Prec:4
Oper Status: Up
Spoke-sdp: 14:1 Prec:4
Oper Status: Up
===============================================================================
*A:PE-1#
Note that on PE-1 the SAP and the spoke SDP 14:1 are active. The other objects do not forward
traffic.
Page 162
Step 1.13 Other types of setups.
Figure 29 and Figure 30 shows other setups that combine MC-LAG and pseudowire redundancy.
PE-1
epipe
LAG
LAG
MC-LAG
MC-LAG
ICB Spoke-SDP
CE-1
LAG
= SDP
ICB Spoke-SDP
X Y
epipe
PE-2
LAG
= SAP
LAG
MC-LAG
LAG
LAG
MC-LAG
CE-1
LAG
PE-1
epipe
X Y
ICB Spoke-SDP
CE-1
CE-2
LAG
CE-2
Spoke-SDP
X Y
epipe
PE-2
PE-1
epipe
X Y
Note: ICB parameter not required

on PE-1 and PE-3 but used
for consitency.
ICB Spoke-SDP
Spoke-SDP
PE-2
epipe
LAG
MC-LAG
LAG
Spoke-SDP
ICB Spoke-SDP
CE-2
PE-3
epipe
X Y
LAG
OSSG384
Figure 29: Additional Setup Example 1
Page 163
Configuration
PE-1
epipe
MC-LAG
LAG
ICB Spoke-SDP
CE-1
PE-3
epipe
SpokeSDP
LAG
Y
CE-2
ICB Spoke-SDP
Spoke-SDP
X Y
epipe
PE-2
LAG
= SDP
= SAP
PE-1
epipe
MC-LAG
CE-1
LAG
ICB Spoke-SDP
SpokeSDP
PE-3
epipe
X
LAG
Y
CE-2
ICB Spoke-SDP
X Y
epipe
PE-2
LAG
PE-3
epipe
PE-1
epipe
X
DP
LAG
e-S
Spok
MC-LAG
Spok
ICB
Spoke-SDP
e-SD
ICB Spoke-SDP
CE-2
Sp
ok
e-
SD
X Y
epipe
PE-4
SD
e-
ok
Sp
MCD-LAG
PE-2
epipe
X
Sp
ok
eS
DP
CE-1
PE-5
epipe
P
SD
e-
ok
LAG
LAG
Sp
MC-LAG
e-SD
Spok
Spok
ICB
Spoke-SDP
ICB Spoke-SDP
CE-3
e-SD
P
X Y
epipe
PE-6
LAG
OSSG386
Figure 30: Additional Setup Example 2
Page 164
MC-LAG in VPLS Services

MC-LAG can also be configured in VPLS services. When the MC-LAG converges the PE that
moves to standby state for the MC-LAG will send out an LDP address withdrawal message to all
peers configured in the VPLS service. Both types of SDPs (spoke and mesh) support this feature.
The PE peers will then flush all the MAC addresses learned through the PE that sent the LDP
MAC address withdrawal message.
Since a VPLS service is a multipoint service, pseudowire redundancy is not required. The MCLAG redundancy configuration is identical.
Page 165
Forced Switchover
Forced Switchover
MC-LAG convergence can be forced with tools perform lag command:
*A:PE-1# tools perform lag force
- force all-mc {active|standby}
- force lag-id <lag-id> [sub-group <sub-group-id>] {active|standby}
- force peer-mc <peer-ip-address> {active|standby}
<lag-id>
<sub-group-id>
<all-mc>
<peer-ip-address>
<active|standby>
:
:
:
:
:
[1..200]
[1..16]
keyword
a.b.c.d
keywords
After the forced switchover it is important to clear the forced switchover:

*A:PE1# tools perform lag clear-force
- clear-force all-mc
- clear-force lag-id <lag-id> [sub-group <sub-group-id>]
- clear-force peer-mc <ip-address>
<lag-id>
<sub-group-id>
<all-mc>
<ip-address>
Page 166
:
:
:
:
[1..200]
[1..16]
keyword
a.b.c.d
Conclusion
MC-LAG is an Alcatel added value redundancy feature that offers fast access link convergence in
Epipe and VPLS services for CE devices that support standard LACP. PE node convergence for
VPLS services is enhanced by using LDP address withdrawal messages to flush the FDB on the
PE peers. PE node convergence for Epipes is guaranteed by using pseudowire redundancy.
Page 167
Conclusion
Page 168

MultiChassis LAG

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MultiChassis LAG

Загружено:

Авторское право:

Доступные форматы

Multi-Chassis LAG and Pseudowire

Applicability on page 142

Overview on page 143

Configuration on page 146

Conclusion on page 167

7750 SR Advanced Configuration Guide

7750 SR Advanced Configuration Guide