Professional Documents
Culture Documents
ZTE CORPORATION
NO. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright 2011 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited.
Revision History
Revision No.
Revision Data
Revision Reason
R1.0
20110730
Summary
Chapter 1, Safety
Instructions
Chapter 2, Service
Reliability Management
Configuration
Chapter 3, VRRP
Configuration
Chapter 4, EFM
Configuration
Chapter 5, CFM
Configuration
Chapter 6, BFD
Configuration
Chapter 7, FRR
Configuration
Chapter 8, IP Graceful
Restart Configuration
Configuration
Chapter
Summary
Protection Group
Configuration
Configuration
Chapter 13,
Active/Standby Switchover
Configuration
Configuration
Intended Audience
This manual is intended for the following engineers:
l
l
l
Conventions
ZTE documents employ the following typographical conventions.
Typeface
Meaning
Italics
Variables in commands. It may also refers to other related manuals and documents.
Bold
Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters and commands.
CAPS
Constant
Text that you type, program codes, filenames, directory names, function names.
width
[]
Optional parameters.
{}
Mandatory parameters.
II
Typeface
Meaning
Danger: Indicates an imminently hazardous situation, which if not avoided, will result in
death or serious injury.
Warning: Indicates a hazard that, if not avoided, could result in serious injuries,
equipment damages or interruptions of major services.
Caution: Indicates a potential hazard that, if not avoided, could result in moderate
injuries, equipment damages or partial service interruption.
Note: Provides additional information about a certain topic.
Auxiliary Function
Command help function of ZXCTN9000 devices has the following features:
1. By entering a question mark (?) following DOS prompt in any command mode, a list of
available commands in this command mode are displayed. With the context-sensitive
help function, the keywords and parameter list of any commands can be displayed.
l By entering a question mark "?" following DOS prompt in any command mode,
a list of all commands in this mode and brief description of these commands are
displayed.
l Input the question mark following a character or a character string, a list of
commands or keywords beginning with this character or character string is
displayed. Note that there is no space between the character (string) and the
question mark.
l Press Tab key following the character string. If the command or keyword
beginning with this character string is unique, complement the command or
keyword and attach a space to the end. Note that there is no space between the
character string and the Tab key.
l Input a question mark (?) following the command, keyword or parameter. The
next keyword or parameter to be entered is listed, and also a brief description is
given. A space shall be entered before the question mark.
2. If incorrect command, keyword or parameter is entered, the error isolation is offered
with ^ in the user interface after you press Enter key. Character ^ locates below the
first character of the entered incorrect command, keyword or parameter.
III
Function
key
key
reached, one more operation will roll the commands from the
beginning of the buffer cyclically.
Use show history command in any mode, and the latest several commands in this
mode will be listed.
IV
Chapter 1
Safety Instructions
Table of Contents
Safety Instructions......................................................................................................1-1
Safety Signs ...............................................................................................................1-1
Warning!
Indicates a hazardous situation, which if not avoided, could result in death, serious injury,
or damage to equipment.
1-1
SJ-20100901100356-020|2011-07-30(R1.0)
Caution!
Indicates a hazardous situation, which if not avoided, could result in minor or moderate
injury, or damage to equipment.
1-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 2
Device reliability
Link reliability
Network reliability
In the bearer network, the availability of network devices must be up to 99.999%, which is
equivalent to a cumulative downtime less than five minutes due to various reasons during
the continuous running of network devices in a year. High reliability is a basic requirement
for carrier-class equipment as well as a basis for telecommunication operators to construct
networks. The bearer network is a basic network for bearing services, so its reliability is
increasingly attracting eyes.
The key reliability technologies used on ZXCTN9000 include device hardware redundancy
and network reliability. This section focuses on network reliability technologies.
Network reliability technologies include network fault detection and protection switching.
Network fault detection technologies are classified as follows according to the network
hierarchy:
l
l
l
l
SJ-20100901100356-020|2011-07-30(R1.0)
End-to-end protection: 1:1, 1+1, 1:N, M:N tunnel protection switching, MC-LAG,
MC-APS, MVLAN, and hot standby
Local protection: FRR, including IP-FRR, LDP-FRR, TE-FRR, and PW-FRR
The service availability manager is used to manage the relations between services and
service availability. It provides a variety of functions, including track object management,
track group management, OAM binding, and OAM mapping. It implements interactions
between services and detection technologies, ensuring that traffic can be quickly switched
over when a network link fails.
Network Topology
1. Figure 2-1 shows how the VRRP, service availability manager, EOAM, and BFD
interact with one another.
2-2
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 2-1 Interactions Between VRRP, Service Availability Manager, EOAM, and
BFD
The VRRP protocol runs on the direct connection interfaces of PA, PB, and PC,
so that the three nodes form a VRRP group.
d. EOAM detection results and BFD detection results are monitored in real time in
VRRP services to provide reliability guarantee for the VRRP.
When the EOAM mechanism detects a failure, it first reports the failure to the service
availability manager. The service availability manager checks the relations between
track objects and services, and then sends a notification message to the corresponding
service, instructing the service to perform status switching.
When the peer BFD on ZXCTN9000 fails, the service availability manager sends a
status notification message to the service. The service performs switching based on
its policy according to the EOAM status and the BFD status.
2. As shown in Figure 2-2, each CE is symmetrically dual-homed to two PE devices to
implement status interactions between detection technologies.
2-3
SJ-20100901100356-020|2011-07-30(R1.0)
Principles of failure detection and switching: Assume the AC between CE1 and PE1
fails.
a. The AC EOAM mechanism on PE1 detects the AC failure, and then notifies the
service availability manager of the AC failure.
b. The service availability manager on PE1 maps the detection track object for the
PW corresponding to AC according to the OAM mapping/binding relation.
c.
SJ-20100901100356-020|2011-07-30(R1.0)
Command
Function
ZXCTN9000(config-track)#detect interface
smartgroup< 1-32>
detection type
ZXCTN9000(config-track)#detect lsp-bfd {
< tunnel-id> }
6
ZXCTN9000(config-track)#detect tunnel-bfd
< tunnel-id>
ZXCTN9000(config-track)#detect tmpls-oam
Description
< name>
Description
< 1-32>
Description
< md>
< ma>
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< mep>
Description
< local-ipv4-address>
< remote-ipv4-address>
< vrfname>
Description
< fec-address>
FEC address
< prefixlen>
< tunnel-id>
Description
< peer-id>
< vcid>
Description
< tunnel-id>
Description
< meg-index>
Command
Function
SJ-20100901100356-020|2011-07-30(R1.0)
Description
< group>
< name>
Function
name>
session object
The following example shows the outputs of the show oam-track session all command.
ZXCTN9000(config)#show oam-track session all
session name: link-bfd
detect type: LINK BFD
local address 10.1.1.1, peer address 10.1.1.2
session name: cfm
detect type: CFM
md 1, ma 2, mep id 109
The following example shows the outputs of the show oam-track session command.
ZXCTN9000(config)#show oam-track session cfm
session name: cfm
detect type: CFM
md 1, ma 2, mep id 109
Description
session name
detect type
The following example shows the outputs of the show vrrp command.
ZXCTN9000#show vrrp
2-7
SJ-20100901100356-020|2011-07-30(R1.0)
Description
2-8
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Enable the link BFD heartbeat detection function on the direct connection interfaces
of P2 and P3.
2. Configure a track session object on P3, and specify the detection type as LINK BFD.
3. Configure the same VRRP group number and virtual address on P2 and P3. To enable
P2 to become the master, use the interface address 10.0.0.1 of P2 as the VRRP virtual
address, or ensure the priority of the VRRP group on P2 is higher than the priority of
the VRRP group on P3.
4. Bind VRRP to the track session object of link BFD on P3.
5. Shut down the interface gei_3/2 on P2. The status of the VRRP group on P3 changes
to Master. Restore the interface gei_3/2 on P2. The status of the VRRP group on P3
changes to Backup.
Configuration Procedure
Run the following configuration commands on P2:
P2(config)#interface loopback1
P2(config-loopback1)ip add 1.1.1.1 255.255.255.255
P2(config)#vlan 10
P2(config-vlan10)#switchport pvid gei_2/1
P2(config)#interface vlan 10
P2(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
P2(config-if-vlan10)#exit
P2(config)#vlan 20
P2(config-vlan20)#switchport trunk gei_3/2
P2(config)#interface vlan 20
P2(config-if-vlan20)#ip address 11.0.0.1 255.255.0.0
P2(config-if-vlan20)#exit
P2(config)#ip static-bfd 1.1.1.1 2.2.2.2
P2(config)#bfd session bfd11
P2(config)#bind link-bfd peer-ip 11.0.0.2 interface vlan20
P2(config)#discriminator-local 51
P2(config)#discriminator-remote 31
P2(config)#detect-multiplier 3
P2(config)#min-tx-interval 3
P2(config)#min-rx-interval 3
P2(config)#interface vlan 20
P2(config-if-vlan20)#bfd interval 3 min-rx 3 multiplier 3
P2(config-if-vlan20)#exit
P2(config)#interface vlan 10
P2(config-if-vlan10)#vrrp 1 ip address 10.0.0.1
P2(config-if-vlan10)#vrrp 1 priority 150
P2(config-if-vlan10)#vrrp 1 out-interface vlan 20
P2(config-if-vlan10)#exit
P2(config)#
2-9
SJ-20100901100356-020|2011-07-30(R1.0)
bfd-session
31 51
P3(config)#exit
P3(config)#interface vlan 10
P3(config-if-vlan10)#vrrp 1 ip address 10.0.0.1
P3(config-if-vlan10)#vrrp 1 priority 80
P3(config-if-vlan10)#vrrp 1 out-interface vlan 20
P3(config-if-vlan10)#vrrp 1 track session link-bfd switch
P3(config-if-vlan10)#exit
P3(config)#
Configuration Verification
Check the configurations and validity of VRRP on P2 and P3. P2 is the master device
whereas P3 is the backup device. Run the show oam-track session command on P3. The
track session object of link BFD has been created. Then run the show vrrp command on
P3. The track session object of link BFD has been bound to the VRRP group.
P2#show vrrp b
Interface
vlan10
Grp
Pri
255
VGMP Admin
0
none
Own
Y
Pr State
Y
Master
Master-addr
10.0.0.1
Group-addr
10.0.0.1
2-10
SJ-20100901100356-020|2011-07-30(R1.0)
Grp
Pri
VGMP Admin
80
vlan10
Own
none
Pr State
Y
Backup
Master-addr
10.0.0.1
Group-addr
10.0.0.1
When the interface gei_3/2 on P2 is shut down, P3 becomes the master device.
P3#show vrrp b
Interface Grp Pri VGMP Admin Own Pr State
vlan10
80
none
Y Master
Master-addr Group-addr
10.0.0.2
10.0.0.1
80
none
Backup
Master-addr Group-addr
10.0.0.1
10.0.0.1
2-11
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Enable the CFM heartbeat detection function on the direct connection interfaces of P2
and P3.
2. Configure a track session object on P3, and specify the detection type as CFM.
3. Configure the same VRRP group number and virtual address on P2 and P3. To enable
P2 to become the master, use the interface address 10.0.0.1 of P2 as the VRRP virtual
address, or ensure the priority of the VRRP group on P2 is higher than the priority of
the VRRP group on P3.
4. Bind VRRP to the track session object of CFM on P3.
5. Shut down the interface gei_3/2 on P2. The status of the VRRP group on P3 changes
to Master. Restore the interface gei_3/2 on P2. The status of the VRRP group on P3
changes to Backup.
Configuration Procedure
Run the following configuration commands on P2:
P2(config)#interface loopback1
P2(config-loopback1)#ip add 1.1.1.1 255.255.255.255
P2(config)#vlan 10
P2(config-vlan10)#switchport pvid gei_2/1
P2(config)#interface vlan 10
P2(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
P2(config-if-vlan10)#exit
P2(config)#vlan 20
P2(config-vlan20)#switchport trunk gei_3/2
P2(config)#interface vlan 20
P2(config-if-vlan20)#ip address 11.0.0.1 255.255.0.0
P2(config-if-vlan20)#exit
P2(config)#cfm enable
P2(config)#cfm create md session 1 name MD1 level 5
P2(config-md1)#ma create session 1 name MA1
2-12
SJ-20100901100356-020|2011-07-30(R1.0)
2-13
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Check the configurations and validity of VRRP on P2 and P3. P2 is the master device
whereas P3 is the backup device. Run the show oam-track session command on P3. The
track session object of CFM has been created. Then run the show vrrp command on P3.
The track session object of CFM has been bound to the VRRP group.
P2#show vrrp b
Interface
vlan10
Grp
Pri
VGMP
Admin
Own
Pr
State
Master-addr
Group-addr
255
none
Master
10.0.0.1
10.0.0.1
Grp
Pri
VGMP
Admin
Own
Pr
State
Master-addr Group-addr
255
none
Backup
P3#show vrrp b
Interface
vlan10
10.0.0.1
10.0.0.1
P3(config)#show vrrp 1
vlan100 - Group 1
State is Backup
Connection interface is vlan20
Admin none, VGMP none
Virtual IP address is 10.0.0.1
Virtual MAC address is 0000.5e00.0101
Backup route is disabled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 80 (config 80)
Authentication is disabled
Track object session cfm switch (up)
Master router is 10.0.0.1(local), priority is 255
Master advertisement interval is 0.000 sec
2-14
SJ-20100901100356-020|2011-07-30(R1.0)
When the interface gei_3/2 on P2 is shut down, P3 becomes the master device.
P3#show vrrp b
Interface Grp Pri VGMP Admin Own Pr State
vlan10
80
none
Master
Master-addr Group-addr
10.0.0.2
10.0.0.1
255
none
Backup
Master-addr Group-addr
10.0.0.1
10.0.0.1
2-15
SJ-20100901100356-020|2011-07-30(R1.0)
2-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 3
VRRP Configuration
Table of Contents
Overview of VRRP .....................................................................................................3-1
Configuring the VRRP ................................................................................................3-4
Maintaining VRRP ......................................................................................................3-7
VRRP Configuration Instances ...................................................................................3-8
VRRP Troubleshooting.............................................................................................3-16
3-1
SJ-20100901100356-020|2011-07-30(R1.0)
As shown in Figure 3-2, the VRRP organizes a group of switches (Switch A and Switch B)
in an LAN into a virtual switch.
Figure 3-2 Working Principles of the VRRP
This virtual switch has its own IP address 10.100.10.1, which can be the same as the
interface address of a certain switch. Physical switches A and B also have their own IP
addresses. For example, the IP address of Switch A is 10.100.10.2, and that of Switch B
is 10.100.10.3. All hosts in the LAN, however, only know the IP address 10.100.10.1 of the
virtual switch but not the IP addresses of Switch A and Switch B. The hosts set their default
route to the IP address 10.100.10.1 of the virtual switch. In this way, hosts in the LAN can
communicate with other networks using the virtual switch. The working mechanism of the
virtual switch is described as follows:
1. A master switch is elected according to priority. The switch with the highest priority
becomes the master switch, whose status is Master. If two switches have the same
priority, the master IP address of the interface is compared. The switch with a greater
master IP address becomes the master switch to provide the routing service.
2. The rest switches serve as backup switches, which monitor the working status of
the master switch at any time. When the master switch works normally, it sends a
VRRP multicast packet at a certain interval to all backup switches in the VRRP group,
3-2
SJ-20100901100356-020|2011-07-30(R1.0)
indicating that the master switch is normally working. If a backup switch in the VRRP
group does not receive any packet from the master switch within the specified time,
it sets its own status to Master. Therefore, there may be multiple master switches if
there are multiple backup switches in the VRRP group according to the above principle.
Then each master switch compares the priority in the received VRRP packet with its
own local priority. If the local priority is smaller than the priority in the VRRP packet,
the switch changes its own status to Backup. Otherwise, the switch keeps the Master
status. Therefore, the switch with the highest priority is elected as the new master
switch to implement VRRP backup.
The switches forming a virtual switch may be in one of the following three states: Initialize,
Master, and Backup, as described below:
l
Initialize
A switch enters this status upon start. If the priority of the switch is 255 when the switch
receives a Startup event, the VRRP switch changes to the Master status. Otherwise,
the VRRP switch changes to the Backup status. A switch in Initialize status will not
perform any processing for a VRRP packet.
Master
A switch in Master status will complete the following tasks:
1. Periodically sending the VRRP multicast packet.
2. The switch sends free ARP packets, so that hosts in the network learn the virtual
MAC address corresponding to the virtual IP address.
3. Responding to the ARP requests of the virtual IP address. The switch responds
to the virtual MAC address but not the real MAC address of the interface.
4. Forwarding IP packets whose destination MAC address is the virtual MAC
address.
5. Receiving IP packets whose destination IP address is the virtual IP address if
itself is the owner of the virtual IP address, or simply discarding the IP packets if
otherwise.
A switch in Master status will change to the Backup status only when it receives a
VRRP packet containing a priority value greater than the priority value of the switch
itself. It will change to the Initialize status only when it receives a shutdown event.
Backup
A switch in Backup status will complete the following tasks:
1. Receiving VRRP multicast packets from the master switch so as to learn the status
of the master switch.
2. Not responding to the ARP requests of the virtual IP address.
3. Discarding IP packets whose destination MAC address is the virtual MAC address.
4. Discarding IP packets whose destination IP address is the virtual IP address.
The switch in Backup status will change to the Master status only when it receives the
MASTER_DOWN timer expiry event. When the switch in Backup status receives a
VRRP packet containing a priority value smaller than the priority value of the switch
3-3
SJ-20100901100356-020|2011-07-30(R1.0)
itself, it simply discards the packet and does not reset the timer. Then the switch will
change to the Master status after several times of such timer processing. The switch
in Backup status will change to the Initialize status only when it receives a shutdown
event.
Figure 3-3 shows the transition of the three states.
Figure 3-3 VRRP Status Transition
As can be seen from the above analysis, a host in the network does not perform any extra
tasks and its communications with external networks are not affected by switch faults.
Command
Function
ZXCTN9000(config-if-vlanX)#vrrp <
ZXCTN9000(config-if-vlanX)#vrrp <
ZXCTN9000(config-if-vlanX)#vrrp <
3-4
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-if-vlanX)#vrrp
100-25000> }
ZXCTN9000(config-if-vlanX)#vrrp <
group> learn
ZXCTN9000(config-if-vlanX)#vrrp <
ZXCTN9000(config-if-vlanX)#vrrp <
10
11
12
ZXCTN9000(config-if-vlanX)#vrrp
command)
ZXCTN9000(config-if-vlanX)#vrrp <
group> ttl-check
configuration mode
ZXCTN9000(config-if-vlanX)#vrrp <
3-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< group>
ipv4
< ip-address>
secondary
Description
< seconds>
Description
< interface-name>
Description
< group>
group
object
string
link-type
Link type
peer-type
Peer type
Priority decrement
Description
< group>
check-ttl
SJ-20100901100356-020|2011-07-30(R1.0)
Function
interface-name>
specific interface
The following example shows the outputs of the show vrrp brief command.
ZXCTN9000#show vrrp brief
Interface Grp Pri VGMP Admin Own Pr State Master-addr Group-addr
---------------------------------------------------------------vlan10
100
none
Init
0.0.0.0
10.0.0.3
vlan10
100
none
Init
0.0.0.0
10.0.0.2
The following example shows the outputs of the show vrrp interface < interface-name>
command.
ZXCTN9000(config)#show vrrp interface vlan 10
vlan10 - Group 1
State is Init
Connection interface is vlan10
Admin none, VGMP none
Virtual IP address is 10.0.0.3
Virtual MAC address is 0000.5e00.0101
Backup route is disabled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 100 (config 100)
Authentication is disabled
Track object session 1 switch (up)
Master router is 0.0.0.0, priority is 0
Master advertisement interval is 0.000 sec
Master down interval is 3.609 sec
vlan10 - Group 2
State is Init
Connection interface is vlan10
3-7
SJ-20100901100356-020|2011-07-30(R1.0)
The following example shows the outputs of the show vrrp [ < group number> ] command.
ZXCTN9000(config)#show vrrp 2
vlan2340 - Group 2
State is Init
Connection interface is vlan2340
Admin none, VGMP none
Virtual IP address is 1.1.1.23
Virtual MAC address is 0000.5e00.0102
Backup route is disabled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 100 (config 100)
Authentication is disabled
Master router is 0.0.0.0, priority is 0
Master advertisement interval is 0.000 sec
Master down interval is 3.609 sec
3-8
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Configure the IP addresses of VRRP interfaces. The interface IP addresses configured
on S1 and S2 must belong to the same network segment.
2. Configure the same VRRP group and virtual IP address on S1 and S2. The virtual IP
address must be in the same network segment as the IP addresses of VRRP interfaces.
3. To enable S1 to serve as the master device, first configure S1 according to the above
steps. For devices with the same priority (100 by default), the VRRP-enabled device
that first advertises VRRP packets will become the master device in the VRRP group.
4. If the configured VRRP virtual IP address is the same as an interface IP address, this
VRRP group has the highest priority (255).
Configuration Procedure
Run the following configuration commands on S1:
S1(config)#vlan 10
S1(config-vlan10)#ex
S1(config)#interface vlan 10
S1(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
S1(config-if-vlan10)#vrrp 1 ip 10.0.0.1
S1(config-if-vlan10)#end
3-9
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Check the VRRP configuration results on S1 and verify that the configurations have taken
effect:
S1#show vrrp breif
brief
Interface Grp Pri VGMP Admin Own Pr State
Master-addr Group-addr
-----------------------------------------------------------------vlan10
255
none
Master
10.0.0.1
10.0.0.1
3-10
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Configure the IP addresses of VRRP interfaces. The interface IP addresses configured
on S1 and S2 must belong to the same network segment.
2. Configure VRRP group 1 and a virtual address on S1. Then configure VRRP group 2
and another virtual address on S2. The virtual IP addresses must belong to the same
network segment as interface IP addresses.
3. S1 becomes the master in group 1, whereas S2 becomes the master in group 2.
4. Add S1 as a backup device to group 2, and S2 as a backup device to group 1.
5. If the configured VRRP virtual IP address is the same as the IP address of the downlink
interface, this VRRP group has the highest priority (255).
Configuration Procedure
Run the following configuration commands on S1:
S1(config)#vlan 10
S1(config-vlan10)#ex
S1(config)#interface vlan 10
S1(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
S1(config-if-vlan10)#vrrp 1 ip 10.0.0.1
S1(config-if-vlan10)#vrrp 2 ip 10.0.0.2
S1(config-if-vlan10)#end
3-11
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Check the VRRP configuration results on S1 and verify that the configurations have taken
effect:
S1#show vrrp brief
Interface Grp Pri VGMP Admin Own Pr State
Master-addr Group-addr
-----------------------------------------------------------------vlan10
255
none
Y Mastert
10.0.0.1
10.0.0.1
vlan10
100
none
10.0.0.2
10.0.0.2
Slaver
S1(config-if-vlan10)#show vrrp 1
vlan10 - Group 1
State is Master,, Owner
Connection interface is vlan10
Admin none, VGMP none
Virtual IP address is 10.0.0.1
Virtual MAC address is 0000.5e00.0101
Backup route is disabled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 255 (config 100)
Authentication is disabled
Master router is 0.0.0.0, priority is 0
Master advertisement interval is 0.000 sec
Master down interval is 3.003 sec
3-12
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Configure the IP addresses of VRRP interfaces. The interface IP addresses configured
on S1 and S2 must belong to the same network segment.
2. Configure the same VRRP group and virtual IP address on S1 and S2. The virtual IP
address must be in the same network segment as the IP addresses of VRRP interfaces.
3. To enable S1 to serve as the master device, first configure S1 according to the above
steps. For devices with the same priority (100 by default), the VRRP-enabled device
that first advertises VRRP packets will become the master device in the VRRP group.
4. Configure the same heartbeat egress interface for the VRRP group in VRRP interface
configuration mode on S1 and S2.
5. If the configured VRRP virtual IP address is the same as the IP address of the downlink
interface, this VRRP group has the highest priority (255).
Configuration Procedure
Run the following configuration commands on S1:
S1(config)#vlan 10
S1(config-vlan10)#ex
S1(config)#vlan 20
S1(config-vlan20)#ex
S1(config)#interface vlan 20
S1(config-if-vlan20)#ip address 20.0.0.1 255.255.255.0
S1(config-if-vlan20)#ex
S1(config)#interface vlan 10
S1(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
S1(config-if-vlan10)#vrrp 1 ipv4 10.0.0.1
S1(config-if-vlan10)#vrrp 1 out-interface vlan 20
3-13
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Check the VRRP configuration results on S1 and verify that the configurations have taken
effect:
S1#show vrrp brief
Interface Grp Pri VGMP Admin Own Pr State Master-addr Group-addr
----------------------------------------------------------------vlan10
255
none
Y Mastert
10.0.0.1
10.0.0.1
S1(config-if-vlan10)#show vrrp 1
vlan10 - Group 1
State is Init, Master
Connection interface is vlan20
Admin none, VGMP none
Virtual IP address is 10.0.0.1
Virtual MAC address is 0000.5e00.0101
Backup route is disabled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 255 (config 100)
Authentication is disabled
Master router is 0.0.0.0, priority is 0
Master advertisement interval is 0.000 sec
Master down interval is 3.003 sec
Configuration Method
1. Configure the IP addresses of VRRP interfaces. The interface IP addresses configured
on PA and PB must belong to the same network segment.
2. Configure the same VRRP group and virtual IP address on PA and PB. The virtual
IP address must be in the same network segment as the IP addresses of VRRP
interfaces.
3. To enable PA to serve as the master device, first configure PA according to the above
steps. For devices with the same priority (100 by default), the VRRP-enabled device
that first advertises VRRP packets will become the master device in the VRRP group.
4. Configure track session objects on PA and PB.
5. Configure the VRRP tracking function on the VRRP group interfaces of PA and PB.
Configuration Procedure
Run the following configuration commands on PA:
PA(config)#valn 10
PA(config-vlan10)#ex
PA(config)#interface vlan 10
PA(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
PA(config-if-vlan10)#vrrp 1 ip 10.0.0.3
PA(config-if-vlan10)#vrrp 1 track session 1 switch
/*Here, the track session has been preconfigured in the service
availability manager.*/
PA(config-if-vlan10)#end
3-15
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Check the VRRP track configuration results on PA and verify that the configurations have
taken effect:
PA#show vrrp brief
Interface Grp Pri VGMP Admin Own Pr State Master-addr Group-addr
---------------------------------------------------------------vlan10
100
none
Master 10.0.0.1
10.0.0.3
PA(config-if-vlan10)#show vrrp 1
vlan10 - Group 1
State is Master
Connection interface is vlan10
Admin none, VGMP none
Virtual IP address is 10.0.0.3
Virtual MAC address is 0000.5e00.0101
Backup route is diPAbled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 100 (config 100)
Authentication is disabled
Track object session 1 P(up)
Master router is 0.0.0.0, priority is 0
Master advertisement interval is 0.000 sec
Master down interval is 3.609 sec
3-16
SJ-20100901100356-020|2011-07-30(R1.0)
3-17
SJ-20100901100356-020|2011-07-30(R1.0)
3-18
SJ-20100901100356-020|2011-07-30(R1.0)
5.
6.
7.
8.
9.
switch with a greater IP address becomes the master switch. Configure a reasonable
preemption delay, or simply keep the default delay.
If it is necessary to configure egress interfaces for heartbeat, ensure that the egress
interfaces at the two ends are direct connection interfaces, the interface addresses
belong to the same network segment, and the two interfaces can ping through each
other.
If authentication is configured, ensure that the authentication configurations at both
ends are consistent.
Ensure that the set advertisement interval is not too great. In general, just keep
the default settings. To restore the default settings, use the no form of a relevant
command.
Ensure that both the master device and the slave device are in learning status.
Ensure that the VRRP virtual addresses configured for the master device and the slave
device as well as the number of virtual addresses are consistent.
3-20
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 4
EFM Configuration
Table of Contents
Overview of EFM........................................................................................................4-1
Configuring EFM ........................................................................................................4-2
Maintaining EFM ........................................................................................................4-5
EFM Configuration Instances .....................................................................................4-8
EFM Troubleshooting ...............................................................................................4-13
EFM enables the local device to check the received protocol packets to determine whether
the EFM function is also enabled on the peer device. It checks the relevant configurations
of the local device and the peer device through protocol packet exchange to determine
whether the negotiation procedure can be completed. After the negotiation procedure is
over, EFM detects the link status through the link monitoring function. For example, it
statistically analyzes the erroneous frames or symbols transmitted on a link in a statistical
period. If the number of erroneous frames or symbols is more than the configured threshold
4-1
SJ-20100901100356-020|2011-07-30(R1.0)
value, EFM triggers an event notification to both the local device and the remote device
so that network administrators timely learn the running status of the link. Furthermore,
the remote loopback function can be enabled for EFM to detect the ratio of lost packets
caused by inconsistent receiving rates between the local device and the remote device or
caused by link faults.
EFM packets are slow protocol packets that cannot be forwarded by devices. Therefore,
EFM can be applied only between two devices physically directly connected to each other,
as shown in Figure 4-1.
Figure 4-1 Working Principles of EFM
The EFM application environment is simple. Packets cannot be forwarded via devices. In
general, EFM is applied between the two ports of the link that directly connects two devices.
It is used for precise link detection and poses certain requirements on the precision of
detection. Ensure that protocol negotiation is successful without link interruption while
keepalive packets are sent between the two devices. The other functions of EFM are
available only after protocol negotiation succeeds. When detecting an event, EFM notifies
the event in a specific packet to the peer device.
Command
Function
state>
function
word>
field
ZXCTN9000(config)#set ethernet-oam
loopback
ZXCTN9000(config)#interface <
interface-name>
5
ZXCTN9000(config-[x]gei_x/y[/z])#set
ZXCTN9000(config-[x]gei_x/y[/z])#set
ZXCTN9000(config-[x]gei_x/y[/z])#set
loopback function
4-2
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-[x]gei_x/y[/z])#set
ZXCTN9000(config-[x]gei_x/y[/z])#set
link monitoring
ZXCTN9000(config-[x]gei_x/y[/z])#set
link monitoring
ZXCTN9000(config-[x]gei_x/y[/z])#set
10
11
12
ZXCTN9000(config-[x]gei_x/y[/z])#set
Description
< state>
Description
< word>
Description
< value>
Description
< interface-name>
Interface name
Description
< state>
Parameter
Description
< level-value>
< time>
< mode-value>
Description
< operation>
Description
< state>
Description
< th-value>
< win-value>
Description
< th-value>
< win-value>
Description
< th-value>
< win-value>
SJ-20100901100356-020|2011-07-30(R1.0)
Description
< th-value>
< win-value>
Function
statistics} ]
Description
< interface-name>
Interface name
dual
in
out
all
information
lpbk-ctrl
notify
org-spec
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
reqst-varb
respst-varb
all-time
< num-value>
Description
< interface-name>
Interface name
discovery
link-monitor
statistics
01 80 C2 00 00 02 00 D0 D0 C7 40 00 88 09 03 00
50 00 01 10 01 00 02 02 1D 05 EE 52 31 00 00 00
00 00 02 10 01 00 02 05 1D 05 EE 52 32 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Port
Local DTE
----------Config:
Mode
: active
Period
: 10*100(ms)
Link TimeOut
: 5(s)
Unidirection
: nonsupport
4-6
SJ-20100901100356-020|2011-07-30(R1.0)
: 1518(bytes)
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Discovery
: done
Loopback
: off
PDU Revision
: 1
Remote DTE
----------Config:
Mode
: active
Link Monitor
: support
Unidirection
: nonsupport
: support
: 1518
OUI
: P2
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Mac Address
: 00.d0.d0.c5.6b.80
PDU Revision
: 1
The outputs of the show ethernet-oam gei_1/1 discovery command are described as follows:
Output Item
Description
Mode
Period Time
Link TimeOut
Link timeout
Unidirection
Parse
Parser status
Multiplexer
Multiplexer status
Stable
Discovery
Loopback
PDU Revision
4-7
SJ-20100901100356-020|2011-07-30(R1.0)
Output Item
Description
Link Monitor
Remote Loopback
Mib Retrieval
Mac Address
Configuration Method
1. Configure EFM on the interface of P1 that directly connects P2, enable the EFM
enabling switch and the link-monitor switch on the specified interface, and globally
enable EFM.
2. Configure EFM on the interface of P2 that directly connects P1, enable the EFM
enabling switch and the link-monitor switch on the specified interface, and globally
enable EFM.
3. Run the show ethernet-oam discovery command on P1 and P2 to check the status of
EFM connection establishment on P1 and P2.
4. Run the show ethernet-oam link-monitor command on P1 and P2 to check the number
of link errors between P1 and P2.
Configuration Procedure
Run the following configuration commands on P1:
P1#configure terminal
P1(config)#set ethernet-oam enable
P1(config)#set ethernet-oam oui P1
4-8
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
1. Run the show ethernet-oam discovery command on P1 to check the EFM negotiation
status of the link.
P1#show ethernet-oam gei_1/1 discovery
Port
Local DTE
----------Config:
Mode
: active
Period
: 10*100(ms)
Link TimeOut
: 5(s)
Unidirection
: nonsupport
: 1518(bytes)
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Discovery
: done
Loopback
: off
PDU Revision
: 1
Remote DTE
----------Config:
Mode
: active
Link Monitor
: support
Unidirection
: nonsupport
: support
: 1518
4-9
SJ-20100901100356-020|2011-07-30(R1.0)
: P2
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Mac Address
: 00.d0.d0.c5.6b.80
PDU Revision
: 1
2. Run the show ethernet-oam link-monitor command on P1 to check the number of link
errors.
P1#show ethernet-oam gei_1/1 link-monitor
: 1(million symbols)
: 1
: 0
: 0
: 1(s)
: 1
: 0
: 0
: 1
: 0
: 0
: 60(s)
: 0(s)
: 0
3. Run the show ethernet-oam discovery command on P2 to check the EFM negotiation
status of the link.
P2#show ethernet-oam gei_2/1 discovery
Port
4-10
SJ-20100901100356-020|2011-07-30(R1.0)
: active
Period
: 10*100(ms)
Link TimeOut
: 5(s)
Unidirection
: nonsupport
: 1518(bytes)
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Discovery
: done
Loopback
: off
PDU Revision
: 1
Remote DTE
----------Config:
Mode
: active
Link Monitor
: support
Unidirection
: nonsupport
: support
: 1518
OUI
: P1
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Mac Address
: 00.d0.d0.c7.40.00
PDU Revision
: 1
4. Run the show ethernet-oam link-monitor command on P2 to check the number of link
errors.
P2#show ethernet-oam gei_2/1 link-monitor
: 1(million symbols)
: 1
: 0
: 0
4-11
SJ-20100901100356-020|2011-07-30(R1.0)
: 1(s)
: 1
: 0
: 0
: 1
: 0
: 0
: 60(s)
: 0(s)
: 0
Configuration Method
1. Configure EFM on the interface of P1 that directly connects P2, and globally enable
EFM.
2. Configure EFM on the interface of P2 that directly connects P1, and globally enable
EFM.
3. Enable the remote loopback function on P1 after the EFM connection is established
between P1 and P2.
4. Run the show ethernet-oam discovery command on P1 and P2 to check the status of
EFM connection establishment on P1 and P2.
4-12
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Procedure
Run the following configuration commands on P1:
P1#configure terminal
P1(config)#set ethernet-oam enable
P1(config)#set ethernet-oam oui P1
P1(config)#interface gei_1/1
P1(config-gei_1/1)#set ethernet-oam enable
P1(config-gei_1/1)#set ethernet-oam link-monitor enable
P1(config-gei_1/1)#exit
Enable the remote loopback function on P1 after the EFM connection is established.
P1#configure terminal
P1(config)#interface gei_1/1
P1(config-gei_1/1)#set ethernet-oam remote-loopback start
P1(config-gei_1/1)#exit
Configuration Verification
After receiving a packet except for the OAM PDU from P1 on the EFM connection link, P2
directly loops back the packet to P1.
4-13
SJ-20100901100356-020|2011-07-30(R1.0)
4-14
SJ-20100901100356-020|2011-07-30(R1.0)
4-15
SJ-20100901100356-020|2011-07-30(R1.0)
4-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 5
CFM Configuration
Table of Contents
Overview of CFM .......................................................................................................5-1
Configuring CFM ........................................................................................................5-2
Maintaining CFM ........................................................................................................5-9
CFM Configuration Instances ...................................................................................5-12
CFM Troubleshooting ...............................................................................................5-19
In the domain illustrated in the above figure, a series of ports are defined on both
edge devices and internal devices. The gray points on the edge devices indicate
the service ports that directly connect devices outside the domain, and are called
Maintenance-association End Points (MEPs). There are also some black ports (including
those on the intermediate device of the domain), which connect devices inside the
domain and are called the Maintenance-association Intermediate Point (MIPs). Domain
management is implemented by the defined MEPs and MIPs.
5-1
SJ-20100901100356-020|2011-07-30(R1.0)
A network can be divided into multiple domains, such as the user domain, provider domain,
and operator domain. For each created domain, a level is specified. There are totally 8
levels: 0 to 7. The level of a domain determines the inclusive relation of the domain. A
domain with a larger level can include a domain with a smaller level. A domain with a
smaller level, however, cannot include a domain with a larger level. In addition, a domain
cannot include other domains with the same level. In other words, the domain with the
largest range has the highest level. The inclusive relation of a domain can be tangency
(inner or outer tangency) or inclusion but cannot be intersection.
Connectivity Fault Management (CFM) can effectively check, isolate, and report the
connectivity faults of virtual bridge LANs. It is intended for operators' networks but
also effective for customer networks (C-VLANs). IEEE 802.1ag defines the following
mechanism:
1. Configuring multiple nested maintenance domains through a bridge network. Each
domain can be managed by a different management organization.
2. Configuring a maintenance association (MA) identified by a separate MD in any given
bridge and a group of VLANs.
3. The protocols, procedures, and CFM protocol packet formats for detecting, isolating,
and reporting connectivity faults.
4. Configuring and managing the configurations of maintenance points (MPs) in an MA.
An MP is used to generate and receive relevant CFM packets.
5. Instructing MPs to perform the determined fault isolation operation and inspect the
results.
Command
Function
ZXCTN9000(config)#cfm ccm-format { 0| 1}
session-id>
5
session-id>
6
5-2
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
session-id>
9
ZXCTN9000(config-md-maX)#create mep
Creates an MEP
ZXCTN9000(config-md-maX)#create rmep
Deletes an MEP
ZXCTN9000(config-md-maX)#create mip
Creates an MIP
Deletes an MEP
Deletes an MIP
ZXCTN9000(config-md-maX)#protect <
protect-type>
17
ZXCTN9000(config-md-maX)#primary vlan
< vlan-id>
18
ZXCTN9000(config-md-maX)#speed { fast |
slow}
19
20
ZXCTN9000(config-md-maX)#ccm
of the MA
21
5-3
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
22
23
25
MEP
ZXCTN9000(config-md-maX)#l2vpn <
l2vpn-name>
26
Messages (LBMs)
Messages (LTMs)
Description
{enable|disable}
Description
{0|1}
Description
< session-id>
5-4
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< md-name>
< md-level>
Description
< session-id>
Description
< session-id>
< ma-name>
Description
< session-id>
< index-id>
{down | up}
Description
< session-id>
< index-id>
5-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< xxxx.xxxx.xxxx>
Description
< session-id>
< mip-name>
Description
< index-id>
all
< session-id>
Description
< index-id>
all
Description
< index-id>
< interface>
< cip-index>
Description
< session-id>
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< interface>
< cip-index>
Description
< protect-type>
Description
< vlan-id>
Description
{fast | slow}
Description
< interval>
Description
< index-id>
{enable | disable}
Description
< index-id>
{enable | disable}
SJ-20100901100356-020|2011-07-30(R1.0)
Description
< index-id>
< priority-value>
Description
< index-id>
< level>
Client level
Description
< index-id>
{enable | disable}
Description
< l2vpn-name>
Description
< md-session-id>
< ma-session-id>
< smep-id>
< dmep-id>
< dmep-mac>
< dmip-mac>
< count>
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< size>
< time>
Description
< md-session-id>
< ma-session-id>
< smep-id>
< dmep-id>
< dmep-mac>
< dmip-mac>
< ttl-count>
< time>
Function
< md-session-id> }
maintenance domain
association
Command
Function
Description
< md-session-id>
< ma-session-id>
< mp-session-id>
Session ID of the MP
< mep-session-id>
< rmep-session-id>
< pkt-num-value>
The following example shows the outputs of the show cfm status command. This command
is used to show the global status of CFM.
ZXCTN9000#show cfm status
CFM enabled
CFM CCM format without MD name
The outputs of the show cfm status command are described as follows.
Output Item
Description
CFM enabled
The following example shows the outputs of the show cfm md all command.
ZXCTN9000#show cfm md all
MD session 1
5-10
SJ-20100901100356-020|2011-07-30(R1.0)
md1
5
contain MA numbers: 1
The outputs of the show cfm md all command are described as follows:
Output Item
Description
MD session 1
name
Name of the MD
level
Level of the MD
contain MA numbers
The following example shows the outputs of the show cfm ma all md 1 command.
ZXCTN9000#show cfm ma all md 1
MA session 1
name:
ma1
belong to MD:
primary vlan:
l2vpn:
protect type:
vlan
time interval:
10(s)
speed:
contain MP numbers:
slow
2
The outputs of the show cfm ma all md 1 command are described as follows:
Output Item
Description
MA session 1
name
Name of the MA
belong to MD
primary vlan
l2vpn
protect type
time interval
speed
Speed of the MA
5-11
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Create an ME and MA with the same name and the same ID on P1 and P2, and globally
enable CFM.
2. Create a local MEP of the same level on the direct connection interfaces of P1 and
P2, and create a remote MEP using the peer MAC and MEP ID. Then enable the local
MEP and CCM packet sending as well as the remote MEP.
3. Run the show cfm mp command on P1 and P2 to check the MEP flag bit and the status
of CFM connection establishment between P1 and P2.
4. Perform cfm linktrace and cfm loopback operations on the MEP of P2 from P1 to
check link connectivity.
Configuration Procedure
Run the following configuration commands on P1:
P1#configure terminal
P1(config)#cfm enable
P1(config)#cfm create md session 1 name MD1 level 5
P1(config-md1)#ma create session 1 name MA1
P1(config-md1-ma1)#speed fast
P1(config-md1-ma1)#protect vlan
P1(config-md1-ma1)#primary vlan 2
P1(config-md1-ma1)#ccm time-interval 2
P1(config-md1-ma1)#create mep session 1 1 direction down
P1(config-md1-ma1)#assign mep 1 to interface gei_1/1
P1(config-md1-ma1)#mep 1 state enable
P1(config-md1-ma1)#mep 1 ccm-send enable
P1(config-md1-ma1)#mep 1 alarm-lowest-pri 1
P1(config-md1-ma1)#create rmep session 2 2 remote-mac 0025.1210.9720
5-12
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
1. Run the show cfm mp all md 1 ma 1 command on P1 to check the status of the link.
P1(config)#show cfm mp all md 1 ma 1 brief
MP session 1
type: local mep
direction: down
mep id: 1
admi state: enable
ccm send state: enable
mep priority: 7
mep client-level: 0
mep ais state: disable
lowest alarm priority: 1
assign port: gei_1/1
MP session 2
type: remote mep
mep id: 2
remote mac: 0025.1210.9720
MP session 1
type: local mep
direction: down
mep id: 1
5-13
SJ-20100901100356-020|2011-07-30(R1.0)
MP session 2
type: remote mep
mep id: 2
remote mac: 0025.1210.9720
DefRemoteCCM:0
DefRDICCM:0
2. Run the show cfm mp all md 1 ma 1 command on P2 to check the status of the link.
P2(config)#show cfm mp all md 1 ma 1 brief
MP session 1
type: local mep
direction: down
mep id: 2
admi state: enable
ccm send state: enable
mep priority: 7
mep client-level: 0
mep ais state: disable
lowest alarm priority: 1
assign port: gei_2/1
MP session 2
type: remote mep
mep id: 1
remote mac: 0818.1a94.0470
5-14
SJ-20100901100356-020|2011-07-30(R1.0)
DefXconCCM:0
DefUnexpectedMepId:0
DefUnexpectedPeriod:0
DefRemoteCCM:1
DefRDICCM:0
MP session 2
type: remote mep
mep id: 1
remote mac: 0818.1a94.0470
DefRemoteCCM:0
DefRDICCM:0
3. Run the cfm lbm command on P1 and P2 to check the continuity of the link.
P1#cfm lbm md 1 ma 1 smep-id 1 dmep-id 2
Sending 5 loopback messages to 0025.1210.9720,timeout is 3 seconds.
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max= 2/4/7 ms.
4. Run the cfm ltm command on P1 and P2 to check the continuity of the link.
P1#cfm ltm md 1 ma 1 smep-id 1 dmep-id 2
Linktrace to 0025.1210.9720: timeout 5 seconds, 64 hops, trans-id 1.
Please wait 5 seconds to print the result.
-----------------------------------------------------------------------------Hops
MAC ADDRESS
Ingress Action
Egress Action
Relay Action
-----------------------------------------------------------------------------1
0025.1210.9720
IngOK
RlyHit
5-15
SJ-20100901100356-020|2011-07-30(R1.0)
MAC ADDRESS
Ingress Action
Egress Action
Relay Action
-----------------------------------------------------------------------------1
0818.1a94.0470
IngOK
RlyHit
Configuration Method
1. Configure an MD and an MA with the same name and the same ID on CE1, CE2, PE1,
and PE2.
2. Configure the interfaces of CE1 and CE2 as a pair of CFM CC groups with reference
to the configuration instance of CFM fast continuity check as described previously.
Enable the alarm function on CE1 and CE2.
3. Configure MIPs for the public network interface and AC-side interfaces of PE1 and
PE2, and globally enable the CFM function on PE1 and PE2.
4. Perform cfm linktrace and cfm loopback operations on the MIPs and MEPs of PE1,
PE2, and CE2 from CE1 to check link connectivity.
5-16
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Procedure
Run the following configuration commands on CE1:
CE1#configure terminal
CE1(config)#cfm enable
CE1(config)#cfm create md session 1 name MD1 level 5
CE1(config-md1)#ma create session 1 name MA1
CE1(config-md1-ma1)#speed fast
CE1(config-md1-ma1)#protect vlan
CE1(config-md1-ma1)#primary vlan 2
CE1(config-md1-ma1)#ccm time-interval 2
CE1(config-md1-ma1)#create mep session 1 1 direction down
CE1(config-md1-ma1)#assign mep 1 to interface gei_4/2
CE1(config-md1-ma1)#mep 1 state enable
CE1(config-md1-ma1)#mep 1 ccm-send enable
CE1(config-md1-ma1)#mep 1 alarm-lowest-pri 1
CE1(config-md1-ma1)#create rmep session 2 2 remote-mac 0025.1210.9720
CE1(config-md1-ma1)#end
5-17
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Perform cfm linktrace and cfm loopback operations on the MIPs and MEPs of PE1, PE2,
and CE2 from CE1 to check link connectivity. If the link is normal, the trace and ping packet
reply should be correct. If the link worsens, CFM alarms will be generated on CE1 and
CE2. The following example shows how to perform ping and trace operations from CE2
to CE1.
CE2#cfm loopback
md 1 ma 1 local-mep 1 type unicast 0016.1514.1312
Sending 3 loopback messages to 0016.1514.1312,timeout is 5 seconds.
Reply from 00.16.15.14.13.12: byte=0 success
Reply from 00.16.15.14.13.12: byte=0 success
Reply from 00.16.15.14.13.12: byte=0 success
Packet : Sent= 3, Received= 3, Lost=0
Hops
MAC ADDRESS
Forwarded
Ingress Action
Egress Action
Relay Action
--------------------------------------------------------------------------F 1
1622.30c4.e999
Forwarded
IngOk
EgrOk
RlyFDB
F 2
00d0.d011.3377
Forwarded
IngOk
EgrOk
RlyFDB
! 3
0016.1514.1312
Not Forwarded
IngOk
RlyHit
Trace complet
5-18
SJ-20100901100356-020|2011-07-30(R1.0)
The name or ID of the MD/MA configured on CE1 is not the same as that configured
on CE2.
The local MEP level configured on CE1 is not the same as that configured on CE2.
The MAC address corresponding to the remote MEP configured on CE1/CE2 is not
the peer MAC address.
The MIP level configured on PE1/PE2 is higher than that configured on CE1/CE2.
5-19
SJ-20100901100356-020|2011-07-30(R1.0)
5-20
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 6
BFD Configuration
Table of Contents
Overview of BFD ........................................................................................................6-1
Configuring BFD.........................................................................................................6-1
Maintaining BFD.........................................................................................................6-7
BFD Configuration Instances......................................................................................6-9
BFD Troubleshooting................................................................................................6-28
Command
Function
ZXCTN9000(config)#interface <
interface-name>
ZXCTN9000(config-if-vlan)#bfd interval
multiplier>
Parameter
Description
< src-ip-address>
< dst-ip-address>
< interface-name>
< vrf-name>
Description
< interface-name>
Description
< interval>
< min-rx-interval>
< multiplier>
Detection multiplier
Command
Function
session-name>
2
interface-name>
3
ZXCTN9000(config-bfd)#discriminator-local
< ld>
4
ZXCTN9000(config-bfd)#discriminator-rem
Description
< session-name>
Description
< bfd-type>
< peer-address>
< interface-name>
Egress interface
Description
< ld>
Description
< rd>
Command
Function
ZXCTN9000(config-router)#bfd-all-interf
ace
3
ZXCTN9000(config)#interface <
interface-name>
4
disable]
Parameter
Description
process-id
Description
interface-name
Users can enable the BFD function on all interfaces in OSPF configuration mode, or enter
a certain interface to enable the BFD function on that interface.
Command
Function
vrf-name> ]
ZXCTN9000(config)#interface <
interface-name>
ZXCTN9000(config-if-vlan)#isis bfd-enable
Description
< vrf-name>
Description
< interface-name>
The BFD function can be enabled on an IS-IS-enabled interface. When the interface
establishes an IS-IS adjacency with the peer interface, a BFD session based on the IS-IS
protocol is established on the direct link composed of the two neighboring interfaces.
6-4
SJ-20100901100356-020|2011-07-30(R1.0)
Command
Function
ZXCTN9000(config-router)#neighbor
command)
multiplier< multiplier> ]
Description
< as-number>
Description
< ipv4-address>
< ipv6-address>
< peer-group-name>
< interval>
< min-rx-interval>
< multiplier>
Detection multiplier
The single-hop BFD mechanism (for a direct connection link) or the multi-hop BFD
mechanism (for non-direct connection links) can be configured, depending on whether
BGP neighbors are directly connected or not directly connected.
Command
Function
establishment
6-5
SJ-20100901100356-020|2011-07-30(R1.0)
It is only necessary to unidirectionally configure LDP BFD. Specify the LSP remote
address during the configuration. The LDP BFD session in the reverse direction will be
automatically established, with the destination being the remote LDP discovery source.
The command parameters in step 1 are described as follows:
Parameter
Description
< masklength>
< interval>
< min_rx>
< multiplier>
Command
Function
ZXCTN9000(config)#interface <
interface-name>
Description
< interface-name>
Command
Function
ZXCTN9000(config-tunnel)#tunnel mpls
Description
< tunnel-id>
Tunnel ID
Description
< interval>
< min-rx-interval>
< multiplier>
Function
Description
< vcid>
< interval>
< min_rx>
< multiplier>
6-7
SJ-20100901100356-020|2011-07-30(R1.0)
Command
Function
of the PW type
Shows summary information about BFD sessions
NeighAddr
12.12.12.1 12.12.12.2
LD
RD
Hold
364 150
State
UP
Int
vlan10
------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Received MinRxInt: 50
Received Multiplier: 3
Holdown : 150
Rx Count: 85
/50
/50
Tx Count: 169
/50
/50
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 7
Min tx interval: 50
Min rx interval: 50
IP length 257~512:
N/A
6-8
SJ-20100901100356-020|2011-07-30(R1.0)
N/A
IP length 257~512:
N/A
====================================================================
6-9
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Configure interface BFD on P1.
2. Configure interface BFD on P2.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip address 172.20.130.213 255.255.255.252
P1(config-if-vlan11)#exit
P1(config)#interface
loopback1
loopback1
Configuration Verification
A BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether static BFD has taken effect.
Check whether static BFD has taken effect on P1:
P1(config)#show bfd
OurAddr
172.20.130.213
neighbors detail
NeighAddr
172.20.130.214
LD
RD
Hold
150
State
UP
Int
vlan99
------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Received MinRxInt: 50
Received Multiplier: 3
Holdown : 150
6-10
SJ-20100901100356-020|2011-07-30(R1.0)
/50
/50
Tx Count: 68
/50
/50
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 1
Your Discr: 1
Min tx interval: 50
Min rx interval: 50
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
===========================================================================
Configuration Method
1. Configure static BFD on P1.
2. Configure static BFD on P2.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip address 172.20.130.213 255.255.255.252
P1(config-if-vlan11)#exit
P1(config)#bfd session 1
P1(config-bfd)#bind link-bfd peer-ip default-ip interface gei_2/1
P1(config-bfd)#discriminator-local 250
6-11
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
A BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether static BFD has taken effect.
Check whether static BFD has taken effect on P1:
P1(config)#show bfd neighbors detail
OurAddr
NeighAddr
1.1.1.1
172.20.130.214
LD
RD
500
250
Hold
0
State Int
up
gei_4/4
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 1890
MinRxInt: 1890
Multiplier: 3
Received MinRxInt: 50
Received Multiplier: 3
Holdown : 0
Rx Count: 254441
/50
/50
Tx Count: 339315
/50
/50
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 500
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
===========================================================================
6-12
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Run the OSPF protocol between P1 and P2.
2. Enable the BFD function on the protocol interfaces of P1 and P2.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip address 172.20.130.213 255.255.255.252
P1(config-if-vlan11)#exit
P1(config)#router ospf 1
P1(config-router)#network 172.20.130.0 0.0.0.255 area 0.0.0.0
P1(config-router)#bfd-all-interface
P1(config-router)#exit
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip ospf bfd
P1(config-if-vlan11)#exit
6-13
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
An OSPF BFD session can be successfully established after the configuration.
Run the show bfd neighbors brief command to check whether OSPF BFD has taken effect.
Check whether OSPF BFD has taken effect on P1:
P1(config)#show bfd neighbors brief
OurAddr
NeighAddr
LD
172.20.130.213 172.20.130.214 9
RD
Hold
150
State
UP
Int
vlan11
NeighAddr
172.20.130.213
LD
RD
Hold
150
State
Int
UP
vlan11
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Holdown : 150
Received MinRxInt: 50
Received Multiplier: 3
Rx Count: 0
/0
/0
Tx Count: 0
/0
/0
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 14
Your Discr: 14
Min tx interval: 50
Min rx interval: 50
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
6-14
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Run the IS-IS protocol between P1 and P2.
2. Enable the BFD function on the protocol interfaces of P1 and P2.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip address 172.20.130.213 255.255.255.252
P1(config-if-vlan11)#exit
P1(config)#router isis
P1(config-router)#area 49.0172
P1(config-router)#system-id 0020.0096.0001
P1(config-router)#exit
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip router isis
P1(config-if-vlan11)#isis bfd-enable
P1(config-if-vlan11)#end
Configuration Verification
An IS-IS BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether IS-IS BFD has taken effect.
Check whether IS-IS BFD has taken effect on P1:
6-15
SJ-20100901100356-020|2011-07-30(R1.0)
NeighAddr
172.20.130.213
172.20.130.214
LD
RD
Hold
State
Int
150
UP
vlan11
-----------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Holdown : 150
Received MinRxInt: 50
Received Multiplier: 3
Rx Count: 124
/50
/50
Tx Count: 98
/50
/50
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
My Discr: 2
Your Discr: 2
Min tx interval: 50
Min rx interval: 50
Final bit: 0
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
============================================================================
Configuration Method
1. Run the BGP protocol between P1 and P2.
2. Enable the BFD function on the protocol interfaces of P1 and P2.
6-16
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface vlan 10
P1(config-if-vlan10)#ip address 10.1.1.1 255.255.255.252
P1(config-if-vlan10)#exit
P1(config)#interface
loopback1
fall-over bfd
P1(config-bgp)#exit
loopback1
fall-over bfd
P2(config-bgp)#exit
Configuration Verification
A BGP BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether BGP BFD has taken effect.
Check whether BGP BFD has taken effect on P1:
P1(config-router)#show bfd neighbors detail
OurAddr
NeighAddr
LD
RD
10.1.1.2
10.1.1.1
Hold
State
30
UP
Int
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 3
Multiplier: 3
Received MinRxInt: 3
Received Multiplier: 3
Holdown : 30
Rx Count: 1317
/3
/3
Tx Count: 1411
/10
/10
6-17
SJ-20100901100356-020|2011-07-30(R1.0)
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 1
Your Discr: 3
Min tx interval: 10
Min rx interval: 3
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
============================================================================
Configuration Method
1.
2.
3.
4.
Enable the MPLS hop-by-hop forwarding function on the link between P1 and P2.
Configure LDP label distribution between P1 and P2.
Specify the IP address of the loopback interface as the LSR ID.
LDP BFD configuration is required on only one node. Therefore, specify P1 as the
initiator and configure an LDP BFD session on P1.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface vlan 11
P1(config-if-vlan11)#ip address 172.20.130.213 255.255.255.252
P1(config-if-vlan11)#exit
P1(config)#interface loopback1
P1(config-loopback1)#ip address 172.20.96.1 255.255.255.255
6-18
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
An LDP BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether LDP BFD has taken effect.
Check whether LDP BFD has taken effect on P1:
P1#show bfd n d
Dest
18.18.18.18
Prefixlen
32
LD
RD
Hold
35
41
150
State
Int
UP
vlan11
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 10
Multiplier: 3
Holdown : 150
Received MinRxInt: 50
Received Multiplier: 3
Rx Count: 422
/10
/10
Tx Count: 673
/50
/50
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Final bit: 0
6-19
SJ-20100901100356-020|2011-07-30(R1.0)
Length: 24
My Discr: 35
Your Discr: 41
Min tx interval: 10
Min rx interval: 10
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
Configuration Method
1. Establish an IS-IS TE tunnel between P1 and P2.
2. Enable the BFD function on the TE interfaces of P1 and P2.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface loopback1
P1(config-loopback1)#ip address 1.1.1.1 255.255.255.255
P1(config-loopback1)#exit
P1(config)#router ospf 1
P1(config-router)#mpls traffic-eng router-id loopback1
P1(config-router)#network 0.0.0.0 255.255.255.255 area 0.0.0.0
P1(config-router)#mpls traffic-eng area 0.0.0.0
P1(config-router)#exit
P1(config)#vlan 10
P1(config-vlan10)#exit
P1(config)#interface vlan 10
P1(config-if-vlan10)#ip address 10.1.1.1 255.255.255.0
6-20
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
An RSVP interface BFD session can be successfully established on P1 after the
configuration.
6-21
SJ-20100901100356-020|2011-07-30(R1.0)
Run the show bfd neighbors detail command to check whether RSVP interface BFD has
taken effect.
Check whether RSVP interface BFD has taken effect on P1:
P1(config)#show bfd neighbors detail
OurAddr
NeighAddr
LD
RD
Hold
10.1.1.1
10.1.1.2
30
State
UP
Int
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 10
Multiplier: 3
Received MinRxInt: 10
Received Multiplier: 3
Holdown : 30
Rx Count: 50130
/10
/10
Tx Count: 50179
/10
/10
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 1
Your Discr: 1
Min tx interval: 10
Min rx interval: 10
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
===========================================================================
6-22
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Enable OSPF TE between P1 and P2.
2. Configure a tunnel on P1, and enable the BFD function on this tunnel.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface loopback1
P1(config-loopback1)#ip address 1.1.1.1 255.255.255.255
P1(config-loopback1)#exit
P1(config)#router ospf 1
P1(config-router)#mpls traffic-eng router-id loopback1
P1(config-router)#network 0.0.0.0 255.255.255.255 area 0.0.0.0
P1(config-router)#mpls traffic-eng area 0.0.0.0
P1(config-router)#exit
P1(config)#vlan 10
P1(config-vlan10)#exit
P1(config)#interface vlan 10
P1(config-if-vlan10)#ip address 10.1.1.1 255.255.255.0
P1(config-if-vlan10)#mpls traffic-eng tunnels
P1(config-if-vlan10)#exit
P1(config)#mpls ip
P1(config)#mpls traffic-eng tunnels
P1(config)#ip explicit-path identifier 1 next-address 10.1.1.2 strict
P1(config)#tunnel 4000
P1(config-tunnel4000)#tunnel mode mpls traffic-eng
P1(config-tunnel4000)#tunnel mpls traffic-eng bfd interval 10 min_rx 3 multiplier 3
6-23
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Tunnel 1 on P1 is up, and an RSVP LSP BFD session can be successfully established on
P1 after the configuration is completed.
Run the show bfd neighbors detail command to check whether RSVP LSP BFD has taken
effect.
Check whether RSVP LSP BFD has taken effect on P1:
P1(config)#show bfd neighbors detail
Tunnel
LD
RD
Hold
State Int
tunnel2
150
UP
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 3
Multiplier: 3
Received MinRxInt: 50
Received Multiplier: 3
Holdown : 150
Rx Count: 70
/3
/3
Tx Count: 46
/50
/50
Diagnostic: 0
6-24
SJ-20100901100356-020|2011-07-30(R1.0)
Poll bit: 0
Final bit: 0
Multiplier: 3
Length: 24
My Discr: 2
Your Discr: 2
Min tx interval: 10
Min rx interval: 3
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
============================================================================
OurAddr
NeighAddr
LD
RD
Hold
State Int
10.1.1.1
10.1.1.2
150
UP
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Received MinRxInt: 50
Received Multiplier: 3
Holdown : 150
Rx Count: 77403
/50
/50
Tx Count: 77329
/50
/50
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
My Discr: 1
Your Discr: 1
Min tx interval: 50
Min rx interval: 50
Final bit: 0
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
============================================================================
6-25
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Configure PW BFD on P1.
2. Configure PW BFD on P2.
Configuration Procedure
Run the following configuration commands on P1:
P1(config)#interface loopback1
P1(config-loopback1)#ip address 1.1.1.1 255.255.255.255
P1(config-loopback1)#exit
P1(config)#router ospf 1
P1(config-router)#mpls traffic-eng router-id loopback1
P1(config-router)#network 0.0.0.0 255.255.255.255 area 0.0.0.0
P1(config-router)#mpls traffic-eng area 0.0.0.0
P1(config-router)#exit
P1(config)#vlan 10
P1(config-vlan10)#exit
P1(config)#vlan 20
P1(config-vlan20)#exit
P1(config)#interface vlan 10
P1(config-if-vlan10)#ip address 10.1.1.1 255.255.255.0
P1(config-if-vlan10)#mpls traffic-eng tunnels
P1(config-if-vlan10)#exit
P1(config)#interface vlan 20
P1(config-if-vlan20)#ip address 20.1.1.1 255.255.255.0
P1(config-if-vlan20)#mpls traffic-eng tunnels
P1(config-if-vlan20)#exit
P1(config)#mpls ip
P1(config)#mpls traffic-eng tunnels
P1(config)#ip explicit-path identifier 1 next-address 10.1.1.2 strict
P1(config)#ip explicit-path identifier 2 next-address 20.1.1.2 strict
P1(config)#interface tunnel4000
P1(config-tunnel4000)#tunnel mode mpls traffic-eng
P1(config-tunnel4000)#ex
P1(config)#tunnel 4000
P1(config-tunnel4000)#tunnel mode traffic-engineer dynamic
P1(config-tunnel4000)#tunnel enable
P1(config-tunnel4000)#tunnel destination 2.2.2.2
6-26
SJ-20100901100356-020|2011-07-30(R1.0)
P1(config-pw)#tunnel 4000
P1(config-pw)#exit
6-27
SJ-20100901100356-020|2011-07-30(R1.0)
P2(config-pw)#tunnel 4000
P2(config-pw)##exit
Configuration Verification
A BFD session can be successfully established after the configuration.
Run the show bfd neighbors brief command to check whether PW BFD has taken effect.
Check whether PW BFD has taken effect on P1:
P1(config)#show bfd neighbors detail
VcId
PeerAddr
LD
RD
Hold
State
2.2.2.2
30
UP
Int
--
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 3
Multiplier: 3
Received MinRxInt: 3
Received Multiplier: 3
Holdown : 30
Rx Count: 2
/3
/3
Tx Count: 2557
/10
/10
Registered protocols: PW
Session name: N/A
Uptime: 0 DAYS,0 HOURS,0 MINUTES
Last packet: Version: 1
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
My Discr: 1
Your Discr: 1
Min tx interval: 10
Min rx interval: 3
Final bit: 0
IP length 257~512:
N/A
N/A
IP length 257~512:
N/A
============================================================================
6-29
SJ-20100901100356-020|2011-07-30(R1.0)
6-30
SJ-20100901100356-020|2011-07-30(R1.0)
3. For a routing protocol BFD session, check whether the BFD session is bidirectionally
configured. For an LSP BFD session, check whether the destination address of the
session can be pinged through.
Contact ZTE technical support personnel if the fault still exists.
6-31
SJ-20100901100356-020|2011-07-30(R1.0)
6-32
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 7
FRR Configuration
Table of Contents
Configuring IP FRR ....................................................................................................7-1
Configuring L2VPN FRR ............................................................................................7-3
Configuring L3VPN FRR ............................................................................................7-5
Configuring TE-FRR...................................................................................................7-6
Configuring LDP FRR...............................................................................................7-14
Configuring TE-Hotstandby ......................................................................................7-15
Configuring Interface FRR........................................................................................7-16
2. The time taken to notify a link failure event to the control layer of the routing device. It
is usually several milliseconds to a dozen milliseconds.
3. The time taken for the local routing device to respond to a link or node failure. For
example, the local routing device may trigger and flood a new link status update packet
as a response. The time is usually several milliseconds to a dozen milliseconds.
4. The time taken for the local routing device to notify a link failure message to the other
nodes in the network. It is usually a dozen milliseconds to a hundred milliseconds per
node.
5. The time taken to trigger route recomputation. For the IGP protocol using the Dijkstra
algorithm, this time is usually a dozen milliseconds.
6. The time taken for the new route information computed through interactions with line
cards to form a forwarding table. It is usually hundreds of milliseconds depending on
the specific number of route entries.
7. The time taken to write the computed new route entries into hardware. It is usually a
dozen milliseconds.
Traffic loss will occur during the recovery of a link failure as described above. The traffic
loss process can be further divided into two stages:
1. Stage 1: The routing device fails to immediately discover the failure of a link connected
to itself, and still forwards traffic to the failed link.
2. Stage 2: The routing device discovers the link failure but the network is still ongoing
with route convergence. As a result, the forwarding tables on the other routing devices
in the network are inconsistent with the forwarding table on the local routing device,
causing a micro loop in the forwarding layer.
For this purpose, a mechanism with the following functions must be provided to shorten
the duration of traffic interruption in the network:
l
l
l
Distance_opt(Ni, D)<Distance_opt(Ni, S)+Distance(S, D), that is, the distance from the
next hop of the backup link to the destination node must be smaller than the sum of the
distance from the next hop of the backup link to the source node and the distance from the
source node of the working link to the destination node.
To form an FRR relation in the downstream mode, the algorithm must meet this condition:
Distance_opt(Ni, D)<Distance(S, D), that is, the distance from the next hop of the backup
link to the destination node must be smaller than the distance from the source node of the
working link to the destination node.
The formation of a BGP FRR relation is quite simpler. The BGP FRR relation can be
formed as long as there are two different next hops to the same destination.
Implementation method: CE1 and CE2 access PE devices via Ethernet links. A PW
is established between PE1 and PE4 as well as between PE2 and PE3. MPLS LSPs
are used as tunnels.
Configure Ethernet OAM on PE devices and CE devices, configure AC OAM detection
and notification on PE devices, and enable the OAM mapping function. Establish a
BFD for PW session between PE1 and PE3 as well as between PE2 and PE4.
Switching is implemented by CE devices. PE devices are responsible for forwarding
only. Therefore, the forwarding process of PE devices is the same as that in common
PWE3.
2. Asymmetrical access of CE devices: The CE at one end accesses a PE via a single
AC, and the CE at the other end accesses PE devices via two ACs. Figure 7-2 shows
the implementation.CE1 and CE2 access PE devices via Ethernet links. A PW is
established between PE1 and PE3, called the master PW. A PW is also established
between PE1 and PE2, called the backup PW.
Figure 7-2 Asymmetrical Access of CE Devices
technology such as BFD to switch over traffic to the backup PW. The master PW and
the backup PW may belong to the same tunnel or different tunnels. When the master
PW is restored, PW-FRR switchback is triggered to fast switch traffic back to the master
PW.
VPN FRR is a technology most commonly used for fast traffic switching in the event of
faults. It establishes an end-to-end channel between two PE devices and pre-establishes
a backup channel for the working channel to be protected. When the device detects that
the working channel is unavailable due to a node or link failure, it switches over traffic to
7-5
SJ-20100901100356-020|2011-07-30(R1.0)
the backup channel, thus rapidly implementing traffic switchover and avoiding VPN traffic
loss.
In an IP/MPLS VPN multi-service bearer network, VPN FRR can be deployed to implement
the fast convergence of public network routes and LSPs in the event of a PE-P link failure,
P-P link failure, or P device failure.
7-6
SJ-20100901100356-020|2011-07-30(R1.0)
Detour mode: One-to-one backup. Protection is provided for each protected LSP.
A protection path is created for each protected LSP. The protection path is called a
detour LSP.
2.
Bypass mode: Facility backup. A protection path protects multiple LSPs. The
protection path is called a bypass LSP.
The detour mode protects each LSP, and thus involves larger overheads. In practice, the
bypass mode is more widely applied. Therefore, the subsequent descriptions focus on the
bypass mode.
Figure 7-4 shows the bypass mode of FRR. The blue LSP is the working LSP, whereas
the red LSP is the bypass LSP. When the RTB-RTC link fails or the node RTC fails, data
on the working LSP is switched to the bypass LSP. The label allocated by RTF to RTB is
added in the top layer of the packet header sent out of RTB, and the egress label of RTC
is pressed into the label stack to serve as the next layer.
7-7
SJ-20100901100356-020|2011-07-30(R1.0)
The LSP uses two layers of labels on the RTB-RTF-RTD path. For a packet received by
RTD, the label allocated by RTD to RTF pops out, and the packet is forwarded using the
label allocated by RTD to RTC.
Several concepts are involved:
l
l
l
l
Working LSP: For the detour LSP or bypass LSP, the working LSP is the protected
LSP.
Point of Local Repair (PLR): It is the source node of the detour LSP or bypass LSP. It
must be on the path of the working LSP and cannot be the sink node.
Merge Point (MP): It is the sink node of the detour LSP or bypass LSP. It must be on
the path of the working LSP and cannot be the source node.
Link protection: There is a direct link to connect the PLR and the MP. The working
LSP passes this direct link. When the link fails, traffic can be switched to the detour
or bypass LSP. This mechanism is called link protection.
Node protection: There is a routing device to connect the PLR and the MP. The
working LSP passes this routing device. When the routing device fails, traffic can
be switched to the detour or bypass LSP. This mechanism is called node protection.
Key Technologies
Figure 7-5 shows the bypass mode of FRR.
7-8
SJ-20100901100356-020|2011-07-30(R1.0)
The bypass mode of FRR as described in this section is implemented using objects
SESSION_ATTRIBUTE and RECORD_ROUTE in compliance with RFC 4090 (hereinafter
referred to as the protocol).
checks the local protection flag to determine whether the LSP is an LSP requiring FRR
protection.
If the LSP requires FRR protection according to the local protection flag in the received
PATH message, the downstream node records the egress interface, LSR ID, and label
of the RESV message in RRO, and then sends the RESV message to the upstream
node. The information is cumulatively calculated hop by hop and further transmitted to
the upstream node.
When a node receives the RESV message for the first time, it selects a proper bypass
LSP for the LSP according to the information recorded in RRO. The process of selecting
a proper bypass LSP for the working LSP is called binding. For details about the binding
algorithm, refer to subsequent descriptions.
After a node performs FRR binding computation for the working LSP, it sends an RESV
message to the upstream node. In the RESV message, there is a RECORD_ROUTE
object, indicating whether the LSP is already protected. If the LSP is already protected,
the node records the protected egress interface address (the eth1 interface of RT2) and
the egress interface of the RESV message (the eth3 interface of RT2). If the LSP is
not protected, the relevant flag in RRO is cleared and the node records only the egress
interface of the RESV message (the eth3 interface of RT2). The egress does not perform
binding computation, but clears all flags recorded in RRO for the RESV message.
The establishment of the working LSP with FRR protection is almost the same as that of a
common LSP, except that binding computation is performed as mentioned previously and
several flags and sub-objects are added in the PATH message and RESV message.
In general, node protection can protect the protected node and the link between the PLR
and the protected node, so it seems to be better than link protection.
The bandwidth of the bypass tunnel is usually used to protect the working LSP. All the
resources on the bypass tunnel are for use only after protection switching. Users should
ensure that the configured bandwidth is greater than or equal to the sum of bandwidth
requested by each protected LSP during configuration. Otherwise, the bypass LSP cannot
provide satisfactory protection after FRR takes effect.
In general, the bypass LSP is in idle status and does not bear any data service. If
users hope that the bypass LSP also undertakes an ordinary data forwarding task while
protecting the working LSP, they must configure a sufficient bandwidth for the bypass LSP.
Binding Computation
Binding can be considered as specifying a bypass tunnel to protect a physical interface.
This is called the binding between a bypass tunnel and a physical interface. One bypass
tunnel can be bound to multiple physical interfaces, and one physical interface can also
be bound to multiple bypass tunnels.
Binding can also be considered as selecting a proper bypass LSP to protect a working LSP.
This is called the binding between a working LSP and a bypass LSP. Binding computation
is a process through which a working LSP is bound to a bypass LSP. The result of binding
computation is to obtain data necessary for forwarding during protection switching, such
as the bypass tunnel interface, the egress interface and NHLFE of the bypass LSP, and
the label allocated by the MP. If the binding computation is successful, an RESV message
is sent to the upstream node, indicating that the working LSP is already protected.
The result of binding computation covers the following items, which are used for sending
data and signaling messages on the bypass tunnel after protection switching:
l
l
l
The result of binding computation will be saved for instant use when a local failure occurs.
This is also the reason why MPLS TE FRR can quickly respond to failures.
Failure Detection
The objective of failure detection is to discover link (RT2-RT3) failures and node (RT3)
failures at the earliest possible time and trigger switching to reduce data packet loss.
The failure detection mechanism does not determine whether a failure is a link or node
failure but ultimately summarizes the failure as an interface failure (a failure of the eth1
interface on RT2).
The interface failure triggers all the LSPs using the failed interface as the egress interface
to implement FRR switching. If the protection type of an LSP is link protection according
to binding computation, it switches to link protection. If the failure is actually a node failure,
7-11
SJ-20100901100356-020|2011-07-30(R1.0)
however, protection will fail and the LSP will be ultimately deleted. If the protection type of
an LSP is node protection according to binding computation, it switches to node protection.
If the failure is actually a link failure, however, the next-hop node will be neglected by the
bypass tunnel, even though the next-hop node is available.
Some link or node failures can be detected by the link layer protocol. The speed of failure
detection of the link layer directly relates to the type of the interface. The other failures are
detected by the hello mechanism of RESV. The hello detection is quite slow.
The hello detection function can be enabled on each physical interface to be protected.
If the hello detection function is also enabled on the peer interface, hello messages and
replies will be periodically sent between the two routing devices. When a link or node fails,
the hello message or reply message will be lost. If the message is lost for three consecutive
times, a failure is considered as having taken place.
Switching Procedure
In the switching procedure, the bypass LSP is enabled so that the data and RSVP
messages of the working LSP are no longer sent on the original path but on the protection
path.
The switching procedure can be triggered by shutting down the interface (eth1 on RT2)
or when an interface failure (eth1 on RT2) is detected through failure detection. Then the
forwarding service and signaling of the protected LSP on the failed interface is switched to
the bypass LSP, and a notification message is sent to the upstream node, indicating that
a switching event has taken place.
7-12
SJ-20100901100356-020|2011-07-30(R1.0)
The MP receives the PATH message sent via the bypass tunnel. Because the session
does not change but the Ingress lsr id (It should be the LSR ID of RT1 instead) in
SENDERTEMPLATE has been changed to the egress interface (eth2 on RT2) address of
the bypass LSP on the PLR, the MP considers that this a PATH after FRR switching and
itself is the MP node.
The PATH message sent by the MP to the downstream will not change with switching.
The RESV message sent by the MP to the upstream will be modified as follows:
1. The Filter Spec source address in the message is changed to the PHOP address (the
address of eth2 on RT2) of the PATH message.
2. NHOP in the message is changed to the ingress interface (eth2 on RT4) address of
the bypass tunnel on the MP.
3. The RRO object in the RESV message records the ingress interface (eth2 on RT4)
address of the bypass tunnel on the MP.
4. The destination address in the IP header of the message is the egress interface (eth2
on RT2) address of the bypass tunnel on the PLR.
5. The TTL value in the message is set to 255, and the TTL value of the protocol message
header is set to 1.
The RESV message sent by the PLR to the upstream after switching will also change. The
egress interface (eth2 on RT2) address of the bypass LSP will be added to RRO.
The paths on which the PTEAR, RERR, RTEAR, and PERR messages of the working LSP
are sent will change accordingly after switching.
After the node protection switching, the protected node (RT3) may send a PATHTEAR
message to the downstream node upon PATH message timeout. The MP (RT4) will ignore
this message. In addition, an ResvTear message will be sent on the ingress interface (eth3
on RT4) of the original LSP during MP switching, so that the protected node (RT3) can
release relevant resources at the earliest possible time.
MBB
For FRR, another function of MBB is to restore the tunnel (Tunnel 1 on RT1) protected
by the bypass LSP to the normal status. When switching occurs on the working LSP,
the source node starts the MBB procedure to recompute an available path. After the
new path is successfully established, a proper backup LSP is re-selected to form a new
working-protection binding relation.
Forwarding
The data forwarding process before the switching of the working LSP is the same as that
of a common LSP. When the working LSP is switched over to the bypass tunnel, data on
the working LSP is forwarded via the bypass tunnel to the MP.
7-13
SJ-20100901100356-020|2011-07-30(R1.0)
to the FEC for the FEC. After port backup is implemented, if the next hop in a label
forwarding table is the protected port, an additional next hop and a label will be added
for this forwarding entry. The added label is the label allocated by the LDP peer
connected to the next hop of the backup route for the FEC.
4. The device maintains the working status (Normal or Invalid) of each port. When detecting that a certain port cannot work properly (for example, the physical link fails or
the port is manually shut down), the device immediately updates the working status of
the port. The device can check the label forwarding table during packet forwarding to
obtain the next-hop port of the packet. If the port status is invalid, the device switches
to the backup port and sets a label before delivering the packet.
The packet reaches the next hop. because the label is allocated by the device itself, there
is surely a label forwarding table for this next hop. Therefore, the packet can continue to
be forwarded to the specified destination address.
Command
Function
ZXCTN9000(config-if-vlan)#interface frr
enable
3
ZXCTN9000(config-if-vlan)#exit
group
Description
VLAN ID
Description
< vrfname>
< ip-address>
< mask>
< next-hop>
Command
Function
ZXCTN9000(config-if-vlan)#interface frr
disable
3
ZXCTN9000(config-if-vlan)#exit
Parameter
Description
VLAN ID
Description
< vrfname>
< ip address>
< mask>
7-17
SJ-20100901100356-020|2011-07-30(R1.0)
7-18
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 8
IP Graceful Restart
Configuration
Table of Contents
Overview of IP Graceful Restart .................................................................................8-1
Configuring IP Graceful Restart ..................................................................................8-1
Maintaining IP Graceful Restart ..................................................................................8-5
IP Graceful Restart Instances...................................................................................8-11
IP Graceful Restart Troubleshooting.........................................................................8-14
Command
Function
ZXCTN9000(config-router)#nsf
8-1
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-router)#grace-period <
time>
Description
< id>
Description
< time>
Command
Function
ZXCTN9000(config)#router isis
ZXCTN9000(config-router)#area <
area-address>
3
ZXCTN9000(config-router)#system-id <
ZXCTN9000(config-router)#restart enable
Enables IS-IS GR
ZXCTN9000(config-router)#restart t2-timer
ZXCTN9000(config-router)#restart t3-timer
ZXCTN9000(config)#interface <
interface-name>
mode
Parameter
Description
< area-address>
Description
< system-id>
< range-number>
Description
t2-timer
< t2-interval>
[level-1 | level-2]
Description
t3timer
adjacency
manual
< t3-interval>
Description
< multiplier>
level-1
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
level-2
Description
< retry-timers>
level-1
level-2
Description
< interval>
level-1
level-2
Command
Function
ZXCTN9000(config-router)#bgp
graceful-restart
3
ZXCTN9000(config-router)#bgp
GR router
ZXCTN9000(config-router)#bgp
8-4
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< as>
Description
< time>
Description
< time>
Function
The following example shows the outputs of the show ip ospf command.
ZXCTN9000(config)#show ip ospf 1
OSPF 1 enable
Router ID 47.47.47.47
Domain ID type 0x5,value 0.0.0.1
Enabled for 00:03:18,Debug on
Number of areas 1, Normal 1, Stub 0, NSSA 0
Number of interfaces 3
Number of neighbors 1
Number of adjacent neighbors 1
Number of virtual links 0
Total number of entries in LSDB 4
Number of ASEs in LSDB 0, Checksum Sum 0x00000000
Number of grace LSAs 0
Number of new LSAs received 4
8-5
SJ-20100901100356-020|2011-07-30(R1.0)
Description
Non-stop Forwarding
(took time)
The following example shows the outputs of the show ip ospf nsf command.
ZXCTN9000(config)#show ip ospf nsf
OSPF Router with ID (47.47.47.47) (Process ID 1)
OSPF instance is graceful restarting
Restart reason is switch to redundant control processor
Grace period 120
Start time 00:00:06
Time to leave 86 s
Helper 46.46.46.46
In the area 0.0.0.0
via interface vlan23 23.1.1.2
Neighbor is DR
State FULL
Description
Restart reason
Restart reason
Grace period
Start time
Time to leave
Helper
Helper ID
In the area
State
Helper status
The following example shows the outputs of the show ip ospf nsf command.
ZXCTN9000(config-router)#show ip ospf nsf
OSPF Router with ID (46.46.46.46) (Process ID 1)
8-6
SJ-20100901100356-020|2011-07-30(R1.0)
Description
Restarting router ID
In the area
Neighbor is BDR
State
Start time
Time to leave
Function
Description
< process-id>
System id
State
Lev Holds
SNPA(802.2)
Pri
MT
8-7
SJ-20100901100356-020|2011-07-30(R1.0)
ZXCTN9000
The following example shows the outputs of the show isis nsf command.
ZXCTN9000(config)#show isis nsf
Process ID 0:
NSF is ENABLE
NSF mode is Normal
NSF L1 active interface: 0
NSF L2 active interface: 0
NSF L1 T2 remaining: 0 seconds
NSF L2 T2 remaining: 0 seconds
NSF T3 using Adjacency
NSF T3 remaining: 0 seconds
Interface:xgei_1/1
NSF L1 restart state: Finished
NSF L1 helper in restart state: Other
NSF L1 T1 remaining: 0 seconds
NSF L1 T1 retransmissions: 0
NSF L2 restart state: Finished
NSF L2 helper in restart state: Other
NSF L2 T1 remaining: 0 seconds
NSF L2 T1 retransmissions: 0
Description
NSF L1 T2 remaining
NSF L2 T2 remaining
8-8
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
Function
The following example shows the outputs of the show ip bgp neighbor command.
sho ip bgp neighbor
BGP neighbor is 1.9.9.9, remote AS 1, internal link
BGP version 4, remote router ID 1.9.9.9
BGP state = Established, up for 15:49:38
Last read update 15:49:36, hold time is 90 seconds, keepalive
interval is 30 seconds
Neighbor capabilities:
Route refresh: advertised and received
New ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
8-9
SJ-20100901100356-020|2011-07-30(R1.0)
8-10
SJ-20100901100356-020|2011-07-30(R1.0)
Connections established 1
Local host: 5.9.9.9, Local port: 1025
Foreign host: 1.9.9.9, Foreign port: 179
Description
received
received
seconds.
Configuration Method
1. Configure ZXCTN9000 devices P1 and P2 as OSPF neighbors to each other.
8-11
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Procedure
Run the following configuration commands on P1:
ZXCTN9000(config)#router ospf 1
ZXCTN9000(config-router)#network 25.60.61.60 0.0.0.255 area 0
ZXCTN9000(config-router)#nsf
0.0.0.255 area 0
ZXCTN9000(config-router)#nsf
Configuration Verification
Traffic can still be normally forwarded after an active/standby switchover of P1.
Configuration Method
1. Configure ZXCTN9000 devices P1 and P2 as IS-IS neighbors to each other.
2. Enable the graceful start function on P1 and P2.
Configuration Procedure
Run the following configuration commands on P1:
ZXCTN9000(config)#router isis
ZXCTN9000(config-router)#system-id 0000.0000.0001
8-12
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
Traffic can still be normally forwarded after an active/standby switchover of P1.
Configuration Method
1. Configure ZXCTN9000 devices P1 and P2 as BGP neighbors to each other.
8-13
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Procedure
Run the following configuration commands on P1:
ZXCTN9000(config)#router bgp 18004
ZXCTN9000(config-router)#neighbor 25.60.61.61 remote-as 18004
ZXCTN9000(config-router)#neighbor 25.60.61.61 update-source loopback1
ZXCTN9000(config-router)#bgp graceful-restart
Configuration Verification
Traffic can still be normally forwarded after an active/standby switchover of P1.
8-14
SJ-20100901100356-020|2011-07-30(R1.0)
8-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 9
9-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 10
10-1
SJ-20100901100356-020|2011-07-30(R1.0)
In 1:1 protection mode, if the working LSP is normal, the protection source sends traffic on
only the working LSP, whereas the protection sink receives only the traffic on the working
LSP. If the working LSP fails, the protection source sends traffic on the protection LSP only,
whereas the protection sink receives only the traffic on the protection LSP. For bidirectional
tunnels, a protection end node is both the source node in one direction and the sink node
in the other direction.
As shown in Figure 10-2, there are two tunnels from PE1 to PE2. One is the working
tunnel, and the other is the protection tunnel. PE1 is the source node of the tunnels and
the protection source as well. PE2 is the sink node of the tunnels and the protection sink as
well. The OAM function is enabled on both the working tunnel and the protection tunnel.
When a failure as shown in the following figure occurs, PE2 detects the failure through
OAM, locally switches from the working tunnel to the protection tunnel to receive traffic, and
at the same time sends a switching notification message (an APS protocol packet) to PE1
via the protection tunnel. Upon receipt of the switching notification message, PE1 locally
switches from the working tunnel to the protection tunnel to send traffic, thus performing
protection switching. If the protection mode is revertive, PE1/PE2 detects the restoration
of the failure through OAM after the failure is restored, and sends a switching notification
message to PE2/PE1. Then PE1/PE2 waits for a certain time, and locally switches from
the protection tunnel to the working tunnel to send/receive traffic, thus performing switching
restoration.
Figure 10-2 1:1 Protection Model
10-2
SJ-20100901100356-020|2011-07-30(R1.0)
10-3
SJ-20100901100356-020|2011-07-30(R1.0)
10-4
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 11
MSP Configuration
Table of Contents
Overview of MSP .....................................................................................................11-1
Configuring MSP ......................................................................................................11-2
Maintaining MSP ......................................................................................................11-3
MSP Configuration Example.....................................................................................11-5
MSP Troubleshooting ...............................................................................................11-6
11-1
SJ-20100901100356-020|2011-07-30(R1.0)
Command
Function
ZXCTN9000(config-msp1)#group-type { msp|
mc-aps}
"msp" by default
ZXCTN9000(config-msp1)#work-unit<
interfacename >
4
ZXCTN9000(config-msp1)#protect-unit<
interfacename >
5
ZXCTN9000(config-msp1)#protect-type {
is "1+1bi" by default
ZXCTN9000(config-msp1)#protect-mode {
ZXCTN9000(config-msp1)#protect-switch{ lp|
Description
msp
mc-aps
Description
1+1uni
1+1bi
1:1bi
11-2
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
revertive
no-revertive
Non-revertive mode
Description
lp
fs work
fs protec
ms work
ms protect
exer protect
clear
Function
msp-id>
11-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< msp-id>
The following example shows the outputs of the show msp-status msp< msp-id> command.
ZXCTN9000#show msp-status msp1
MSP Group ID
: 1
Group Type
: MSP
Protect Type
: 1+1 bi
: work unit
Work Unit
: cstm1_cpos3_7/2/1
Protect Unit
: cstm1_cpos3_6/1/9
RG Group ID
: N/R
: revertive
WTR Time
: 5(min)
Description
MSP Group ID : 1
RG Group ID : N/R
11-4
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Create a protection group on both P1 and P2.
2. Specify the working port and protection port on P1 and P2.
3. Configure MSP parameters, such as the protection mode and the restoration mode.
By default, the protection type is "1+1bi", the restoration mode is "revertive", and the
WRT time is 5 minutes for a protection group.
4. Run the show msp-status msp< msp-id> command on P1 and P2 to check the current
configuration and status of the protection group.
Configuration Procedure
Run the following configuration command on P1:
P2(config)#interface msp1
P2(config-msp1)#work-unit cstm1-cpos3_7/2/1
P2(config-msp1)#protect-unit cstm1-cpos3_7/2/2
P2(config-msp1)#protect-type 1+1bi
P2(config-msp1)#protect-mode revertive 5
Configuration Verification
P2(config-msp1)#show msp msp1
MSP Group ID
: 1
Group Type
: MSP
Protect Type
: 1+1 bi
11-5
SJ-20100901100356-020|2011-07-30(R1.0)
: work unit
Work Unit
: cstm1-cpos3_7/2/1
Protect Unit
: cstm1-cpos3_7/2/2
RG Group ID
: N/R
: revertive
WTR Time
: 5(min)
: 1
Group Type
: MSP
Protect Type
: 1+1 bi
: work unit
Work Unit
: cstm1-cpos3_6/1/9
Protect Unit
: cstm1-cpos3_6/1/10
RG Group ID
: N/R
: revertive
WTR Time
: 5(min)
11-6
SJ-20100901100356-020|2011-07-30(R1.0)
normal, check the software, including the MSP protection type, protection mode (revertive
or non-revertive), and priority.
11-7
SJ-20100901100356-020|2011-07-30(R1.0)
1. Run the show msp-status msp msp-id command on P1 and P2 to check whether the
current status of the protection group is consistent. If the status is consistent, check
whether the link under Running Mode is up.
2. Run the show msp-status msp msp-id command on P1 and P2 to check whether the
configured protection type is consistent. If the protection type is inconsistent, modify
the MSP protection type till consistent.
3. Run the show msp-status msp msp-id command on P1 and P2 to check whether the
configured protection mode is consistent. If the protection mode is inconsistent, modify
the MSP protection mode till consistent.
4. Check whether the protection group failure or traffic interruption is caused by priority.
If yes, perform the protection switching operation using the correct priority.
Contact ZTE technical support personnel if the fault still exists.
11-8
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 12
12-1
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
disable}
2
meg-index>
6
< meg-index>
7
meg-index>
8
ZXCTN9000(config-instance-meg)#tmpls
configuration mode
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
oam cv
14
ZXCTN9000(config-instance-meg)#tmpls
oam cv cc
15
16
ZXCTN9000(config-instance-meg)#tmpls
packets
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
12-2
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
19
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
ZXCTN9000(config-instance-meg)#tmpls
Description
{enable|disable}
Description
< tms-id>
12-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< tunnel-id>
Description
< pw-name>
Description
< meg-index>
Description
{enable|disable}
Description
< meg-id>
Description
{fast|slow}
Description
< meg-id>
Description
< interval>
SJ-20100901100356-020|2011-07-30(R1.0)
Description
< phb-value>
Description
{enable|disable}
Description
< mip-id>
< port-name>
Description
< mep-id>
< mip-id>
< phb-value>
{connect | diagnose}
< mip-id>
< hop-count>
< report-interval>
< send-interval>
< send-time>
12-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< hop-value>
< phb-value>
< send-count>
< send-interval>
< thresh-value>
Description
< phb-value>
Description
{proactive| on-demand}
< mep-id>
< phb-value>
< report-interval>
< send-interval>
Description
{one-way| two-way}
< mep-id>
< phb-value>
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< report-interval>
< send-interval>
< send-value>
Function
meg-index> ]
ZXCTN9000(config)#show tmpls oam lm [ <
meg-index> ]
configured MEG
< meg-index>
configured MEG
Description
[ < meg-index> ]
[ < bytes-type> ]
[ < packet-type> ]
The following example shows the outputs of the show tmpls meg-info command.
ZXCTN9000#show tmpls meg-info
Meg_1 Information:
-----------------------------------------MegId
abc
MegSpeed
FAST
MegEnableFlag
ENABLE
12-7
SJ-20100901100356-020|2011-07-30(R1.0)
TUNNEL_1
------------------------------------------
The outputs of the show tmpls meg-info command are described as follows:
Output Item
Description
MegId
MEG ID
MegSpeed
MegEnableFlag
MegInstanceInfo
The following example shows the outputs of the debug tmpls bytes lb command.
ZXCTN9000#debug tmpls bytes lb
Nov 30 01:05:59: TMPLS-OAM:IN:
E0 03 00 04 00 00 00 0B 21 00 0F 00 12 61 62 63
00 00 00 00 00 00 00 00 00 00 21 00 0F 00 11 61
62 63 00 00 00 00 00 00 00 00 00 00 00
The following example shows the outputs of the debug tmpls packet lb command.
ZXCTN9000#debug tmpls packet lb
Nov 30 01:06:45:
TMPLS-OAM:IN:
E0 03 00 04 00 00 00 15 21 00 0F 00 12 61 62 63
00 00 00 00 00 00 00 00 00 00 21 00 0F 00 11 61
62 63 00 00 00 00 00 00 00 00 00 00 00
Nov 30 01:06:45:
TMPLS-OAM:PANNEL:[5]Received
12-8
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Configure static MAC and ARP entries on P1 and P2, and globally enable MPLS-TP
OAM.
2. Create TMS, TMP, and TMC instances on P1 and P2, create an MEG with the same
MEG ID on TMS, TMP, and TMC, configure the attributes and members of the MEG,
and then check the connection establishment status of the MEGs on P1 and P2 to
determine whether there is any Loss of Connectivity (LoC) alarm.
3. Perform loopback operations on the MEP of P2 from P1 to check the continuity of the
link between P1 and P2.
Configuration Procedure
Run the following configuration commands on P1:
P1#configure terminal
P1(config)#interface loopback1
P1(config-loopback1)#ip address 1.1.1.1 255.255.255.255
P1(config-loopback1)#exit
P1(config)#interface gei_1/1
P1(config-gei_1/1)#switchport mode trunk
P1(config-gei_1/1)#switchport trunk vlan 20
P1(config-gei_1/1)#exit
P1(config)#interface vlan20
P1(config-if-vlan20)#ip address 20.1.1.1 255.255.255.0
P1(config-if-vlan20)#set arp permanent 20.1.1.2 00d0.d0c7.ffe1
P1(config-if-vlan20)#exit
P1(config)#mac add permanent 00d0.d0c7.ffe1 interface gei_1/1 vlan 20
P1(config)#tmpls oam enable
P1(config)#pw-class ControlWordEnable
P1(config-pw-class)#control-word preferred
P1(config-pw-class)#exit
P1(config)#tms 1
P1(config-tms)#local-port gei_1/1 peer-port 20.1.1.2
P1(config-tms)#tmpls oam meg 1
P1(config-instance-meg)#tmpls oam enable
P1(config-instance-meg)#tmpls oam meg-id 1
P1(config-instance-meg)#tmpls oam meg speed fast
P1(config-instance-meg)#tmpls oam local-mep 1 type bidirectional
12-9
SJ-20100901100356-020|2011-07-30(R1.0)
12-10
SJ-20100901100356-020|2011-07-30(R1.0)
12-11
SJ-20100901100356-020|2011-07-30(R1.0)
12-12
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
1. Run the show logging current-alarm command on P1 to check whether there is any
LoC alarm for the MEG.
P1(config)#show logging current-alarm typeid tms-mep
P1(config)#show logging current-alarm typeid tmp-mep
P1(config)#show logging current-alarm typeid tmc-mep
/*It indicates that currently there is no LoC alarm and the MEG is normal.*/
2. Run the show logging current-alarm command on P2 to check whether there is any
LoC alarm for the MEG.
P2(config)#show logging current-alarm typeid tms-mep
P2(config)#show logging current -alarm typeid tmp-mep
P2(config)#show logging current -alarm typeid tmc-mep
/*It indicates that currently there is no LoC alarm and the MEG is normal.*/
LOC alarms are generated at one end, and RDI alarms are generated at the other
end.
LOC alarms are generated at one end only.
12-13
SJ-20100901100356-020|2011-07-30(R1.0)
All the above symptoms indicate that a link failure occurs. This section describes the cause
of such faults and relevant solutions by taking the topology shown in Figure 12-2 as an
example.
Figure 12-2 Network Topology for MPLS-TP OAM Troubleshooting
12-14
SJ-20100901100356-020|2011-07-30(R1.0)
12-15
SJ-20100901100356-020|2011-07-30(R1.0)
12-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 13
Active/Standby Switchover
Table of Contents
Overview of Active/Standby Switchover....................................................................13-1
Phases in Active/Standby Switchover.......................................................................13-1
Active/Standby Switchover Status Determination .....................................................13-2
Triggering Active/Standby Switchover ......................................................................13-2
Active/Standby Switchover Command ......................................................................13-3
Instructions on Active/Standby Switchover ...............................................................13-3
Real-Time Backup
After the batch backup process is over, the system enters a real-time backup process.
When the backup data on the master MP changes in the real-time backup process, the
backup data is synchronized in real time to the slave MP. This usually lasts for a very short
time.
13-1
SJ-20100901100356-020|2011-07-30(R1.0)
Data Smoothing
The slave MP is escalated and becomes the new master MP after active/standby
switchover. Then it sends a notification message to all modules, instructing them to collect
data from and synchronize to service boards. This process is called data smoothing. In
the data smoothing process, all modules actively communicate with service boards to
confirm the hardware status, link layer status, and configuration data with the service
boards and to synchronize to the service boards if inconsistency exists, so as to ensure
that the data and status information maintained by the entire system are consistent to
guarantee normal system running after active/standby switchover. The new master MP
is really active only after the data smoothing phase is over.
SJ-20100901100356-020|2011-07-30(R1.0)
It takes the same time for the slave MP to detect the switchover notification, no matter
what factor triggers the switchover. The detection notification is triggered by a hardware
interrupt, and status switching is completed within a matter of milliseconds.
Both the master MP and the slave MP periodically send handshake messages to each
other. If the master or slave MP does not receive a handshake message from the peer
within the specified time, it considers that the master-slave communications fail. Then the
slave MP is reset.
3. Type the letter "y". If the slave MP board is not online, the system gives the following
prompt:
%Error 27604: Slave board is not online
4. If the slave MP is online but data is not yet completely synchronized, the system gives
the following prompt:
%Error 6552: Database sync is not Ready!
5. If the system gives the prompt as described in step 4, manually synchronize the
database using the following command in privileged mode:
ZXCTN9000#syncdb
After confirming that the configuration information is successfully saved, export it for
backup as much as possible and then run the active/standby switchover command.
After the active/standby switchover is completed, compare the configuration
information with the backup configuration information. If the configuration information
is consistent and services are normal, the active/standby switchover is successful.
Otherwise, contact technical personnel for help.
13-3
SJ-20100901100356-020|2011-07-30(R1.0)
2. Line cards will not restart during active/standby switchover. If the line cards restart and
services are abnormal after the restart, contact technical personnel for help.
3. Do not forcibly perform switchover. Otherwise, services can be abnormal due to system configuration data loss or data exceptions after the switchover. If the active/standby switchover is unsuccessful, contact technical personnel for help.
13-4
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 14
MCLAG Configuration
Table of Contents
Overview of mcLag...................................................................................................14-1
Configuring mcLag ...................................................................................................14-2
Maintaining mcLag ...................................................................................................14-4
mcLag Configuration Instances ................................................................................14-4
mcLag Troubleshooting ............................................................................................14-7
Link faults on the CE side can be detected by means such as CFM, EFM, or ZFID. The
system supports both a static mode and a dynamic mode for selecting the active link and
14-1
SJ-20100901100356-020|2011-07-30(R1.0)
the standby link. In static mode, the standby link is specified through manual configuration.
In dynamic mode, the active link and the standby link are selected through LACP packet
exchange between the CE and the two PE devices. The selection is based on the chassis
addresses and priority of the two peer PE devices.
Command
Function
ZXCTN9000(config)#interface smartgroup<
lacp-id>
2
ZXCTN9000(config-smartgroup1)#smartgr
oup mode on
3
ZXCTN9000(config)#interface <
interface-name>
4
ZXCTN9000(config-[x]gei_x/y[/z])#smart
ZXCTN9000(config-[x]gei_x/y[/z])#lacp
protection
Description
< lacp-id>
LACP group ID
Description
< interface-name>
Description
< lacp-id>
LACP group ID
14-2
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< interface-name>
Description
< lacp-id>
LACP group ID
Command
Function
ZXCTN9000(config)#interface smartgroup<
lacp-id>
2
ZXCTN9000(config-smartgroup1)#smartgr
ZXCTN9000(config-smartgroup1)#smartgr
ZXCTN9000(config-smartgroup1)#smartgr
ZXCTN9000(config)#interface <
interface-name>
6
ZXCTN9000(config-[x]gei_x/y[/z])#smart
Description
< lacp-id>
LACP group ID
Description
< sys-mae>
Description
< sys-priority>
SJ-20100901100356-020|2011-07-30(R1.0)
Description
< interface-name>
Description
< lacp-id>
LACP group ID
Function
Description
< lacp-id>
LACP group ID
14-4
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
Configure mcLag on P1.
Configuration Procedure
Run the following configuration commands on P1:
ZXCTN9000(config)#interface smartgroup1
ZXCTN9000(config-smartgroup1)#smartgroup mode on
ZXCTN9000(config-smartgroup1)#ex
ZXCTN9000(config)#interface gei_4/4
ZXCTN9000(config-gei_4/4)#smartgroup 1 mode on
ZXCTN9000(config-gei_4/4)#ex
ZXCTN9000(config)#interface gei_4/2
ZXCTN9000(config-gei_4/2)#smartgroup 1 mode on
ZXCTN9000(config-gei_4/2)#lacp protection
ZXCTN9000(config-gei_4/2)#exit
Configuration Verification
A smart group can be successfully established after the configuration. Run the following
command to check the configuration results.
ZXCTN9000(config)#show lacp 1 internal
Smartgroup:1
Switch attribute:TRUE
Mode:on
Agg
LACPDUs
Port
Oper
Port
State
Port
RX
Mux
State Machine
Machine
---------------------------------------------------------------------gei_4/4
active
30
32768
0x111
0x3d
N/A
N/A
14-5
SJ-20100901100356-020|2011-07-30(R1.0)
inactive
30
32768
0x111
0x45
N/A
N/A
Configuration Method
Configure mcLag on P1, P2, and P3.
Configuration Procedure
Run the following configuration commands on P1:
ZXCTN9000(config)#interface smartgroup1
ZXCTN9000(config-smartgroup1)#smartgroup mode 802.3ad
ZXCTN9000(config-smartgroup1)#ex
ZXCTN9000(config)#interface gei_1/1
ZXCTN9000(config-gei_1/1)#smartgroup 1 mode active
ZXCTN9000(config-gei_1/1)#ex
ZXCTN9000(config)#interface gei_1/2
ZXCTN9000(config-gei_1/2)#smartgroup 1 mode active
ZXCTN9000(config-gei_1/2)#exit
14-6
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Verification
A smart group can be successfully established after the configuration. Run the following
command to check the configuration results.
ZXCTN9000(config)#show lacp 1 internal
Smartgroup:3
Switch attribute:TRUE
Mode:802.3ad
active
30
32768
0x311
0x3d
current
distributing
gei_4/2
inactive
30
32768
0x321
0x5
current
defaulte
14-7
SJ-20100901100356-020|2011-07-30(R1.0)
14-8
SJ-20100901100356-020|2011-07-30(R1.0)
14-9
SJ-20100901100356-020|2011-07-30(R1.0)
14-10
SJ-20100901100356-020|2011-07-30(R1.0)
Figures
Figure 2-1 Interactions Between VRRP, Service Availability Manager, EOAM, and
BFD ........................................................................................................ 2-3
Figure 2-2 Status Interactions of CE Devices Dual-Homed to PE Devices ................ 2-4
Figure 2-3 LINK BFD Interacting with VRRP ............................................................. 2-8
Figure 2-4 CFM Interacting with VRRP ................................................................... 2-12
Figure 2-5 Network Topology for Service Availability Manager
Troubleshooting .................................................................................... 2-15
Figure 2-6 Service Availability Manager Fault Handling Flow .................................. 2-16
Figure 3-1 Default Gateway for the LAN.................................................................... 3-1
Figure 3-2 Working Principles of the VRRP............................................................... 3-2
Figure 3-3 VRRP Status Transition ........................................................................... 3-4
Figure 3-4 Configuring the Basic VRRP .................................................................... 3-9
Figure 3-5 Configuring Symmetrical VRRP ............................................................. 3-11
Figure 3-6 Configuring the VRRP Heartbeat Line (IPv4) ......................................... 3-13
Figure 3-7 Configuring VRRP Track ........................................................................ 3-15
Figure 3-8 Network Topology for VRRP Troubleshooting......................................... 3-17
Figure 3-9 VRRP Fault Handling Flow 1.................................................................. 3-18
Figure 3-10 VRRP Fault Handling Flow 2................................................................ 3-19
Figure 4-1 Working Principles of EFM ....................................................................... 4-2
Figure 4-2 EFM Connection Establishment ............................................................... 4-8
Figure 4-3 EFM Remote Loopback ......................................................................... 4-12
Figure 4-4 Network Topology for EFM Troubleshooting ........................................... 4-13
Figure 4-5 EFM Fault Handling Flow....................................................................... 4-14
Figure 5-1 MD........................................................................................................... 5-1
Figure 5-2 CFM Connection Establishment............................................................. 5-12
Figure 5-3 Inter-L2VPN Connectivity Check ............................................................ 5-16
Figure 5-4 Network Topology for CFM Troubleshooting........................................... 5-19
Figure 5-5 CFM Fault Handling Flow....................................................................... 5-20
Figure 6-1 Interface BFD ........................................................................................ 6-10
Figure 6-2 A Configuration Example of Static BFD.................................................. 6-11
Figure 6-3 A Configuration Example of OSPF BFD ................................................. 6-13
Figure 6-4 A Configuration Example of IS-IS BFD................................................... 6-15
II
Glossary
BFD
- Bidirectional Forwarding Detection
BGP
- Border Gateway Protocol
CFM
- Connectivity Fault Management
EFM
- Ethernet in the First Mile
FRR
- Fast Reroute
IBGP
- Interior Border Gateway Protocol
IGP
- Interior Gateway Protocol
IS-IS
- Intermediate System-to-Intermediate System
LACP
- Link Aggregation Control Protocol
LDP
- Label Distribution Protocol
LSP
- Label Switched Path
MC-LAG
- Multi-Chassis Link Aggregation Group
MPLS
- Multi Protocol Label Switching
MVLAN
- Multicast Virtual Local Area Network
OAM
- Operation, Administration and Maintenance
OSPF
- Open Shortest Path First
PW
- Pseudo Wire
III
QoS
- Quality of Service
VPN
- Virtual Private Network
VRRP
- Virtual Router Redundancy Protocol
IV