CloudEngine 12800 V100R001C00 Configuration Guide - Reliability 03

CloudEngine 12800 Series Switches
V100R001C00
Configuration Guide - Reliability
Issue 03
Date 2013-07-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://enterprise.huawei.com
Issue 03 (2013-07-10) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples of the reliability supported by the device.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER
Indicates a hazard with a high level or medium level of risk
which, if not avoided, could result in death or serious injury.
WARNING
Indicates a hazard with a low level of risk which, if not
avoided, could result in minor or moderate injury.
CAUTION
Indicates a potentially hazardous situation that, if not
avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP
Provides a tip that may help you solve a problem or save time.
NOTE
Provides additional information to emphasize or supplement
important points in the main text.

Command Conventions
The command conventions that may be found in this document are defined as follows.
Configuration Guide - Reliability About This Document
ii
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }
*
Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]
*
Optional items are grouped in brackets and separated by
vertical bars. You can select one or several items, or select
no item.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.

Interface Numbering Conventions
Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 03 (2013-07-10)
The third commercial release has the following updates:
The following information is modified:
l 3.2 VRRP Features Supported by the Device
l 3.4.3 (Optional) Configuring VRRP Time Parameters
The third commercial release has the following updates:
The following information is modified:
l 3.8.1 Example for Configuring a VRRP Group in Active/Standby Mode
iii
l 3.8.2 Example for Configuring a VRRP Group in Multi-gateway Load Balancing
Mode
l 3.8.3 Example for Configuring a VRRP Group in Single-gateway Load Balancing
Mode
Initial commercial release.
iv
Contents
About This Document.....................................................................................................................ii
1 BFD Configuration........................................................................................................................1
1.1 BFD Overview................................................................................................................................................................3
1.2 BFD Features Supported by the Device.........................................................................................................................3
1.3 Default Configuration.....................................................................................................................................................5
1.4 Configuring Single-Hop BFD........................................................................................................................................5
1.5 Configuring Multi-Hop BFD..........................................................................................................................................7
1.6 Configuring Static BFD with Automatically Negotiated Discriminators......................................................................8
1.7 Configuring BFD to Detect VPN Routes.....................................................................................................................10
1.8 Configuring BFD Association......................................................................................................................................11
1.9 Adjusting BFD Parameters...........................................................................................................................................12
1.9.1 Adjusting the BFD Detection Time...........................................................................................................................12
1.9.2 Setting the WTR Time of a BFD Session..................................................................................................................13
1.9.3 Configuring the Description for a BFD Session........................................................................................................13
1.9.4 Setting the Delay Before a BFD Session Becomes Up.............................................................................................14
1.9.5 Setting the Priority of BFD Packets..........................................................................................................................15
1.10 Checking the Configuration........................................................................................................................................15
1.11 Maintaining BFD........................................................................................................................................................16
1.12 Configuration Examples.............................................................................................................................................16
1.12.1 Example for Configuring Single-Hop BFD on a VLANIF Interface......................................................................16
1.12.2 Example for Configuring Multi-Hop BFD..............................................................................................................19
1.13 Common Configuration Errors...................................................................................................................................22
1.13.1 BFD Session Cannot Become Up............................................................................................................................22
2 DLDP Configuration...................................................................................................................24
2.1 DLDP Overview...........................................................................................................................................................25
2.2 Default Configuration...................................................................................................................................................25
2.3 Configure DLDP Functions..........................................................................................................................................26
2.3.1 Enabling DLDP.........................................................................................................................................................26
2.3.2 (Optional) Configuring the Working Mode of DLDP...............................................................................................27
2.3.3 (Optional) Configuring the DLDP-Compatible Mode..............................................................................................27
2.3.4 (Optional) Setting the Interval for Sending Advertisement Packets.........................................................................28
2.3.5 (Optional) Setting the Timeout Period of the DelayDown Timer.............................................................................29
Configuration Guide - Reliability Contents
v
2.3.6 (Optional) Setting the Mode of Shutting Down an Interface When a Unidirectional Link Is Detected...................30
2.3.7 (Optional) Configuring the Authentication Mode for DLDP Packets.......................................................................30
2.3.8 Checking the Configuration.......................................................................................................................................31
2.4 Resetting the DLDP Status...........................................................................................................................................32
2.5 Maintaining DLDP.......................................................................................................................................................33
2.6 Configuration Examples...............................................................................................................................................33
2.6.1 Example for Configuring DLDP to Detect a Disconnected Optical Fiber Link........................................................33
2.6.2 Example for Configuring DLDP to Detect Cross-Connected Optical Fibers............................................................35
2.7 Common Configuration Errors.....................................................................................................................................38
2.7.1 DLDP Cannot Discover a Directly Connected Neighbor..........................................................................................38
3 VRRP Configuration...................................................................................................................40
3.1 Introduction to VRRP...................................................................................................................................................42
3.2 VRRP Features Supported by the Device.....................................................................................................................43
3.3 Default Configuration...................................................................................................................................................46
3.4 Configuring Basic Functions of an IPv4 VRRP Group................................................................................................46
3.4.1 Creating a VRRP Group............................................................................................................................................46
3.4.2 Setting the Device Priority in a VRRP Group...........................................................................................................48
3.4.3 (Optional) Configuring VRRP Time Parameters......................................................................................................49
3.4.4 (Optional) Setting the Mode in Which VRRP Packets Are Sent in a Super-VLAN.................................................51
3.4.5 (Optional) Disabling VRRP TTL Check...................................................................................................................52
3.4.6 (Optional) Setting the Authentication Mode of VRRP Packets................................................................................52
3.4.7 (Optional) Enabling the Ping to a Virtual IP Address...............................................................................................53
3.5 Configuring an IPv4 mVRRP Group............................................................................................................................54
3.5.1 Configuring an mVRRP Group.................................................................................................................................54
3.5.2 (Optional) Configuring a VRRP Group and Binding the VRRP Group to an mVRRP Group.................................55
3.6 Configuring VRRP Association...................................................................................................................................56
3.6.1 Configuring Association Between VRRP and BFD to Implement a Rapid Active/Standby Switchover.................56
3.6.2 Configuring Association Between VRRP and Link/Peer BFD to Implement a Rapid Active/Standby Switchover
............................................................................................................................................................................................57
3.6.3 Configuring Association Between VRRP and the Interface Status...........................................................................59
3.6.4 Configuring Association Between VRRP and BFD to Monitor the Uplink Status...................................................60
3.6.5 Configuring Association Between VRRP and Routing to Monitor the Uplink Status..............................................61
3.6.6 Configuring Association Between a VRRP Group and a Direct Route....................................................................62
3.7 Maintaining VRRP.......................................................................................................................................................65
3.7.1 Monitoring the VRRP Running Status......................................................................................................................65
3.7.2 Clearing VRRP Packet Statistics...............................................................................................................................65
3.8 Configuration Examples...............................................................................................................................................66
3.8.1 Example for Configuring a VRRP Group in Active/Standby Mode.........................................................................66
3.8.2 Example for Configuring a VRRP Group in Multi-gateway Load Balancing Mode................................................71
vi
3.8.3 Example for Configuring a VRRP Group in Single-gateway Load Balancing Mode...............................................76
3.8.4 Example for Connecting VRRP Groups to L3VPNs.................................................................................................82
3.8.5 Example for Configuring Association Between VRRP and BFD to Implement a Rapid Active/Standby Switchover
............................................................................................................................................................................................87
3.8.6 Example for Configuring Association Between VRRP and the logical Interface Status..........................................92
3.8.7 Example for Configuring Association Between VRRP and BFD to Monitor the Uplink Status..............................98
3.8.8 Example for Configuring Association Between VRRP and Routing to Monitor the Uplink Status.......................105
3.8.9 Example for Configuring Association Between a VRRP Group and a Direct Route.............................................113
3.9 Common Configuration Errors...................................................................................................................................117
3.9.1 Multiple Masters Coexist in a VRRP Group...........................................................................................................117
3.9.2 VRRP Group Status Changes Frequently................................................................................................................118
vii
1 BFD Configuration
About This Chapter
Bidirectional forwarding detection (BFD) allows network devices to quickly detect faults.
1.1 BFD Overview
Bidirectional forwarding detection (BFD) can quickly detect a communications fault between
systems and notify upper layer applications of the fault.
1.2 BFD Features Supported by the Device
The device supports the following BFD features: BFD session setup, BFD detection mode,
single-hop and multi-hop BFD, BFD session with automatically negotiated parameters, VPN
route detection, and dynamic change of BFD parameters.
1.3 Default Configuration
This section provides the default configuration of a BFD session.
1.4 Configuring Single-Hop BFD
Single-hop BFD fast detects faults on the directly connected link.
1.5 Configuring Multi-Hop BFD
Multi-hop BFD fast detects faults on the indirectly connected link.
1.6 Configuring Static BFD with Automatically Negotiated Discriminators
When the peer device uses dynamic BFD and the local device wants to communicate with the
peer device and detect static routes, create a BFD session with automatically negotiated
discriminators.This function applies to networks that use static routes to implement Layer 3
connectivity.
1.7 Configuring BFD to Detect VPN Routes
This section describes how to configure BFD to detect VPN routes.
1.8 Configuring BFD Association
Association between BFD and other protocols improves upper-layer application performance
and fast detects faults on links.
1.9 Adjusting BFD Parameters
You can adjust BFD parameters so that the BFD session can fast detect faults on links.
1.10 Checking the Configuration
After the BFD configuration is complete, you can view the BFD session configuration.
Configuration Guide - Reliability 1 BFD Configuration
1
1.11 Maintaining BFD
This section describes how to maintain BFD.
1.12 Configuration Examples
This section provides examples for the BFD configuration, including networking requirements,
configuration notes, and configuration roadmap.
1.13 Common Configuration Errors
This section describes common configuration errors of BFD.
2
1.1 BFD Overview
Bidirectional forwarding detection (BFD) can quickly detect a communications fault between
systems and notify upper layer applications of the fault.
To minimize the impact of a fault on services and improve network reliability, a network device
is required to rapidly detect a communications fault between adjacent devices and the upper
layer protocol can rectify the fault to ensure service transmission.
Currently, the existing detection mechanisms are as follows:
l Hardware detection: For example, the Synchronous Digital Hierarchy (SDH) alarms are
used to report link faults. Hardware detection can quickly detect a fault; however, not all
media can provide the hardware detection mechanism.
l Slow Hello mechanism: It usually refers to the Hello mechanism offered by a routing
protocol. The slow Hello mechanism can detect a fault in seconds. When traffic is
transmitted at a high rate, fault detection with more than 1s will cause packet loss. The slow
Hello mechanism depends on routing protocols. If no routing protocol is deployed on a
small-scale Layer 3 network, this mechanism cannot be used.
l Other detection mechanisms: Different protocols or manufacturers may provide proprietary
detection mechanisms; however, it is difficult to deploy the proprietary detection
mechanisms when different systems are interconnected.
BFD provides fast fault detection independent of media and routing protocols. It has the
following advantages:
l Provides low-load and short-duration detection for faults on the bidirectional forwarding
path of any type.
l Provides uniform detection for all media and protocol layers in real time and supports
different detection intervals and overheads.
1.2 BFD Features Supported by the Device
The device supports the following BFD features: BFD session setup, BFD detection mode,
single-hop and multi-hop BFD, BFD session with automatically negotiated parameters, VPN
route detection, and dynamic change of BFD parameters.
1. You can create BFD sessions based on the mode in which local and remote discriminators
are created.
2. You can configure single-hop BFD, multiple-hop BFD, and VPN route detection based on
detection modes.
3. You can configure association between BFD and other protocols.
BFD Session Setup
BFD uses local and remote discriminators in control packets to differentiate BFD sessions. Based
on the mode in which local and remote discriminators are created, the device supports the
following BFD session types:
l Static BFD sessions with manually specified discriminators
You must manually specify the local and remote discriminators of a BFD session. If a static
BFD session is established on the local end using the manually specified discriminators,
3
the static BFD session must also be established on the remote end using the manually
specified discriminators.
l Static BFD sessions with automatically negotiated discriminators
When the peer device uses dynamic BFD and the local device wants to communicate with
the peer device and detect static routes, create a BFD session with automatically negotiated
discriminators. If a static BFD session is established on the local end using the automatically
negotiated discriminators, the static BFD session can be established on the remote end using
the automatically negotiated discriminators or a dynamic BFD session can be established
on the remote end.
l Dynamic BFD sessions triggered by a protocol
The local discriminator is dynamically allocated and the remote discriminator is learned
by the system.
BFD Detection Mode
The Switch supports BFD in asynchronous mode.
Devices send BFD control packets at the negotiated period. If a device does not receive a packet
from the peer device within the period, the BFD session becomes Down.
Single-hop BFD and Multi-hop BFD
Single-hop BFD detects IP connectivity of the forwarding link between two directly connected
devices.
Multi-hop BFD detects IP connectivity of paths between two indirectly connected devices. These
paths may span multiple hops or overlap.
VPN Route Detection
To fast detect and monitor VPN routes, create a BFD session in a VPN instance.
Association
In practice, BFD is often used with other protocols to serve upper-layer applications, such as
BFD for OSPF. By default, the interval for OSPF to send Hello packets is 10 seconds. That is,
the Switch detects neighbor faults in seconds. The second-level detection leads to the loss of a
large number of packets on a high-speed network. BFD works with OSPF to fast detect the
adjacency fault. In addition, BFD instructs OSPF to recalculate corresponding routes for correct
packet forwarding.
The Switch allows BFD to associate with the following protocols:
l OSPF
l IS-IS
l BGP
l Static route
l PIM
l VRRP
4
This section provides the default configuration of a BFD session.
Table 1-1 Default BFD parameter settings
Parameter Default Setting
Global BFD Disabled
Minimum interval for sending BFD control
packets
1000 ms
Minimum interval for receiving BFD control
packets
1000 ms
Local detection multiplier 3
WTR time 0 min
Delay before a BFD session becomes Up 0 min
Priority of BFD packets 7

1.4 Configuring Single-Hop BFD
Single-hop BFD fast detects faults on the directly connected link.
Pre-configuration Tasks
Before configuring single-hop BFD, complete the following tasks:
l Configuring link layer protocol parameters for interfaces to ensure that the link layer
protocol status on the interfaces is Up
l Configuring an IP address for the Layer 3 interface
5
Configuration Process
Figure 1-1 Single-hop BFD configuration process
Enable global BFD
Establish a BFD session
Mandatory
Optional
Set local and remote
discriminators
Procedure
Step 1 Run:
system-view
The system view is displayed.
Step 2 Run:
bfd
BFD is enabled globally and the BFD view is displayed.
By default, BFD is disabled globally.
Step 3 Run:
quit
Return to the system view.
Step 4 Run:
bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ] interface
interface-type interface-number [ source-ip ip-address ]
A BFD session is created.
NOTE
l When creating a single-hop BFD session, bind the single-hop BFD session to the peer IP address and
the local address.
l When the BFD configuration items are created, the system checks only the format of the IP address.
The BFD session cannot be established if an incorrect peer IP address or source IP address is bound.
l When BFD and URPF are used together, UPRF checks the source IP address of the received BFD
packets. You must bind the correct source IP address to the BFD session to prevent BFD packets from
being discarded incorrectly.
l BFD cannot detect route switching. If the bound peer IP address change causes route switching, BFD
does not perform negotiation again unless forwarding fails on the original link.
Step 5 Run:
discriminator local discr-value
6
The local discriminator is set.
Step 6 Run:
discriminator remote discr-value
The remote discriminator is set.
NOTE
The local discriminator of the local system must be the same as the remote discriminator of the remote
system; the remote discriminator of the local system must be the same as the local discriminator of the
remote system. Otherwise, BFD sessions cannot be established.
Step 7 Run:
commit
The configuration is committed.
----End
1.5 Configuring Multi-Hop BFD
Multi-hop BFD fast detects faults on the indirectly connected link.
Before configuring multi-hop BFD, complete the following task:
l Configuring a routing protocol to ensure reachability at the network layer
Figure 1-2 Multi-hop BFD configuration process
Enable global BFD
Mandatory
Optional
discriminators
Procedure
Step 1 Run:
system-view
Step 2 Run:
7
bfd
Step 3 Run:
quit
Step 4 Run:
bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ] [ source-ip ip-
address ]
A BFD session is created and the peer IP address is specified.
NOTE
l When creating a multi-hop BFD session, you must bind the BFD session to the peer IP address.
l When the BFD configuration items are created, the system checks only the format of the IP address.
The BFD session cannot be established if an incorrect peer IP address or source IP address is bound.
Step 5 Run:
Step 6 Run:
NOTE
remote system. Otherwise, BFD sessions cannot be established. After the local discriminator and the remote
discriminator are configured, you cannot modify them.
Step 7 Run:
commit
----End
1.6 Configuring Static BFD with Automatically Negotiated
Discriminators
When the peer device uses dynamic BFD and the local device wants to communicate with the
peer device and detect static routes, create a BFD session with automatically negotiated
discriminators.This function applies to networks that use static routes to implement Layer 3
connectivity.
8
Before configuring a BFD session with automatically negotiated discriminators, complete the
following task:
l Configuring an IP address for the Layer 3 interface
Figure 1-3 Configuring static BFD with automatically negotiated discriminators
Enable global BFD
Mandatory
Optional
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
quit
Step 4 Run:
bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ] [ interface
interface-type interface-number ] source-ip ip-address auto
A BFD session with automatically negotiated discriminators is created.
NOTE
l You must specify a source IP address.
l You must specify the peer IP address, which cannot be a multicast IP address.
Step 5 Run:
commit
----End
9
1.7 Configuring BFD to Detect VPN Routes
This section describes how to configure BFD to detect VPN routes.
Before configuring BFD to detect VPN routes, complete the following tasks:
l Configuring network layer attributes of interfaces to ensure network connectivity
l Configuring VPN instances on PEs
Figure 1-4 Configuring BFD to detect VPN routes
Enable global BFD
Mandatory
Optional
discriminators
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
bfd session-name bind peer-ip ip-address vpn-instance vpn-name [ interface
interface-type interface-number ] [ source-ip ip-address ]
A BFD session is created and the peer IP address is specified.
10
NOTE
l When creating a BFD session for the first time, bind the BFD session to the peer IP address and the
local VPN instance. To modify a configured BFD session, delete it and recreate a new one.
l When the BFD configuration items are created, the system checks only the IP address format. The BFD
session cannot be established if an incorrect peer IP address or source IP address is bound.
Step 4 Run:
Step 5 Run:
NOTE
remote system. Otherwise, BFD sessions cannot be established.
Step 6 Run:
commit
----End
1.8 Configuring BFD Association
Association between BFD and other protocols improves upper-layer application performance
and fast detects faults on links.
Applications Associated with BFD
l BFD for OSPF: See Configuring BFD for OSPF in the CloudEngine 12800 Series Switches
Configuration - Configuration Guide - IP Routing OSPF Configuration.
l BFD for IS-IS: See Configuring Static BFD for IS-IS and Configuring Dynamic BFD for
IS-IS in the CloudEngine 12800 Series Switches Configuration - Configuration Guide - IP
Routing IS-IS Configuration.
l BFD for BGP: See Configuring Association Between BGP and BFD in the CloudEngine
12800 Series Switches Configuration - Configuration Guide - IP Routing BGP
Configuration.
l BFD for static routes: See Configuring Dynamic BFD for IPv4 Static Routes and
Configuring Static BFD for IPv4 Static Routes in the CloudEngine 12800 Series Switches
Configuration - Configuration Guide - IP Routing Static Route Configuration.
l BFD for VRRP: See 3.6.3 Configuring Association Between VRRP and the Interface
Status in the CloudEngine 12800 Series Switches Configuration - Configuration Guide -
Reliability VRRP Configuration.
11
l BFD for PIM: See Configuring PIM BFD in the CloudEngine 12800 Series Switches
Configuration - Configuration Guide - IP Multicast PIM-SM (IPv4) Configuration.
1.9 Adjusting BFD Parameters
You can adjust BFD parameters so that the BFD session can fast detect faults on links.
Before adjusting BFD parameters, complete the following task:
l Creating a BFD session
1.9.1 Adjusting the BFD Detection Time
Context
When you set up a BFD session, you can adjust the minimum interval for sending BFD packets,
minimum interval for receiving BFD packets, and local detection multiplier based on the network
situation and performance requirements.
To reduce usage of system resources, when a BFD session is detected in Down state, the system
adjusts the minimum interval for receiving BFD packets and the minimum interval for sending
BFD packets to random values greater than 1000 ms. When the BFD session becomes Up, the
configured intervals are restored.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd session-name
The BFD session view is displayed.
Step 3 Run:
min-tx-interval interval
The minimum interval for sending BFD packets is set.
By default, the minimum interval for sending BFD packets is 1000 ms.
Step 4 Run:
min-rx-interval interval
The minimum interval for receiving BFD packets is set.
By default, the minimum interval for receiving BFD packets is 1000 ms.
Step 5 Run:
detect-multiplier multiplier
The local detection multiplier is set.
12
By default, the local detection multiplier is 3.
NOTE
It is recommended that the detection interval be set not smaller than 50 ms x 5 or 100 ms x 3.
Step 6 Run:
commit
----End
1.9.2 Setting the WTR Time of a BFD Session
Context
If a BFD session flaps, an active/standby switchover is frequently performed on the application
associated with the BFD session. To prevent the problem, set the WTR time of the BFD session.
When the BFD session changes from Down to Up, BFD reports the change to the upper layer
application only after the WTR timer times out.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd session-name
Step 3 Run:
wtr wtr-value
The WTR time is set.
By default, the WTR time is 0, indicating that the status change of a BFD session is reported
immediately.
NOTE
If the WTR time is set, set the same WTR time at both ends. Otherwise, when the BFD session status
changes at one end, applications at both ends detect different BFD session statuses.
Step 4 Run:
commit
----End
1.9.3 Configuring the Description for a BFD Session
13
Context
To differentiate BFD sessions, configure the description for BFD sessions.
NOTE
The description (BFD session view) command is valid for only static BFD sessions, and is invalid for
dynamic BFD sessions and BFD sessions with automatically negotiated parameters.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd session-name
Step 3 Run:
description description
The description of the BFD session is configured.
By default, the description of a BFD session is empty.
Step 4 Run:
commit
----End
1.9.4 Setting the Delay Before a BFD Session Becomes Up
Context
In practice, some devices determine whether to switch traffic based on the BFD session status.
Because the routing protocol becomes Up after the interface becomes Up, routes may be not
found when services are switched back, causing traffic loss. Therefore, the interval between the
time when the routing protocol becomes Up and the time when the interface becomes Up must
be eliminated.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Global BFD is enabled and the BFD view is displayed.
14
Step 3 Run:
delay-up time
The delay before a BFD session becomes Up is set.
By default, the delay before a BFD session becomes Up is 0.
Step 4 Run:
commit
----End
1.9.5 Setting the Priority of BFD Packets
You can change the priority of BFD packets to:
l Detect whether packets with different priorities on a link can be forwarded.
l Ensure that BFD packets with a higher priority are forwarded first.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd session-name
Step 3 Run:
tos-exp tos-value
The priority of BFD packets is set.
By default, the priority of BFD packets is 7, representing the highest priority. The value 0 is the
lowest priority.
The tos-exp dynamiccommand can be used to set a priority value for a dynamic BFD session.
----End
1.10 Checking the Configuration
After the BFD configuration is complete, you can view the BFD session configuration.
Procedure
l Run the display bfd session { all | static | discriminator discr-value | dynamic | peer-ip
peer-ip [ vpn-instance vpn-instance-name ] | static-auto } [ verbose ] command to view
information about the BFD session.
l Run the display bfd statistics command to check global BFD statistics.
15
l Run the display bfd statistics session { all | static | dynamic | discriminator discr-
value | peer-ip peer-ip [ vpn-instance vpn-name ] | static-auto } command to check BFD
session statistics.
----End
1.11 Maintaining BFD
This section describes how to maintain BFD.
To view BFD statistics within a specified period, clear existing statistics and then use a display
command.
CAUTION
The deleted BFD statistics cannot be restored. Exercise caution when you use this command.
Procedure
l Run the reset bfd statistics { all | discriminator discr-value } command in the user view
to clear BFD session statistics.
----End
This section provides examples for the BFD configuration, including networking requirements,
1.12.1 Example for Configuring Single-Hop BFD on a VLANIF
Interface
Networking Requirements
As shown in Figure 1-5, SwitchA connects to SwitchB through the VLANIF interface. Faults
on the link between SwitchA and SwitchB need to be fast detected.
Figure 1-5 Networking diagram for configuring single-hop BFD on a VLANIF interface
VLANIF100
10.1.1.5/24
VLANIF100
10.1.1.6/24
10GE1/0/1 10GE1/0/1
SwitchA SwitchB
Configuration Roadmap
The configuration roadmap is as follows:
16
Configure BFD sessions on SwitchA and SwitchB.
Procedure
Step 1 On SwitchA and SwitchB, create VLANs, configure 10GE1/0/1 interfaces as trunk interfaces,
and add 10GE1/0/1 interfaces to VLANs. The configuration details are not mentioned here.
Step 2 Configure IP addresses for VLANIF interfaces so that SwitchA and SwitchB can communicate
at Layer 3. The configuration details are not mentioned here.
Step 3 Configure single-hop BFD.
# Enable BFD and create a BFD session on SwitchA.
<HUAWEI> system-view
[~HUAWEI] sysname SwitchA
[~HUAWEI] commit
[~SwitchA] bfd
[~SwitchA-bfd] quit
[~SwitchA] bfd atob bind peer-ip 10.1.1.6 interface vlanif 100
[~SwitchA-bfd-session-atob] discriminator local 1
[~SwitchA-bfd-session-atob] discriminator remote 2
[~SwitchA-bfd-session-atob] commit
[~SwitchA-bfd-session-atob] quit
# Enable BFD and create a BFD session on SwitchB.
[~HUAWEI] sysname SwitchB
[~HUAWEI] commit
[~SwitchB] bfd
[~SwitchB-bfd] quit
[~SwitchB] bfd btoa bind peer-ip 10.1.1.5 interface vlanif 100
[~SwitchB-bfd-session-btoa] discriminator local 2
[~SwitchB-bfd-session-btoa] discriminator remote 1
[~SwitchB-bfd-session-btoa] commit
[~SwitchB-bfd-session-btoa] quit
Step 4 Verify the configuration.
After the configuration is complete, run the display bfd session all verbose command on
SwitchA and SwitchB. You can see that a single-hop BFD session is set up and its status is Up.
The display on SwitchA is used as an example.
<SwitchA> display bfd session all verbose
--------------------------------------------------------------------------------
Name : atob (One Hop) State : Up
--------------------------------------------------------------------------------
Local Discriminator : 1 Remote Discriminator : 2
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : Interface(Vlanif100)
Bind Session Type : Static
Bind Peer IP Address : 10.1.1.6
Bind Interface : Vlanif100
FSM Board Id : 1 TOS-EXP : 7
Min Tx Interval (ms) : 1000 Min Rx Interval (ms) : 1000
Actual Tx Interval (ms): 1000 Actual Rx Interval (ms): 1000
WTR Interval (ms) : - Detect Interval (ms) : 3000
Local Detect Multi : 3 Active Multi : 3
Destination Port : 3784 TTL : 255
Last Local Diagnostic : No Diagnostic
Bind Application : No Application Bind
Session Description : -
--------------------------------------------------------------------------------

Total UP/DOWN Session Number : 1/0
17
# Run the shutdown command on the 10GE1/0/1 interface of SwitchA to simulate a link fault.
[~SwitchA] interface 10GE 1/0/1
[~SwitchA-10GE1/0/1] shutdown
[~SwitchA-10GE1/0/1] quit
After the configuration is complete, run the display bfd session all verbose command on
SwitchA and SwitchB. You can see that a single-hop BFD session is set up and its status is
Down. Take the display on SwitchA as an example.
--------------------------------------------------------------------------------
Name : atob (One Hop) State : Down
--------------------------------------------------------------------------------
BFD Bind Type : Interface(Vlanif100)
Bind Interface : Vlanif100
WTR Interval (ms) : - Detect Interval (ms) : -
Last Local Diagnostic : Control Detection Time Expired
Session Not Up Reason : In negotiation
--------------------------------------------------------------------------------

----End
Configuration Files
l Configuration file of SwitchA
#
sysname SwitchA
#
vlan batch 100
#
bfd
#
interface Vlanif100
ip address 10.1.1.5 255.255.255.0
#
interface 10GE1/0/1
port link-type trunk
port trunk allow-pass vlan 100
#
bfd atob bind peer-ip 10.1.1.6 interface Vlanif100
discriminator local 1
discriminator remote 2
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
vlan batch 100
#
bfd
#
18
interface Vlanif100
ip address 10.1.1.6 255.255.255.0
#
interface 10GE1/0/1
#
bfd btoa bind peer-ip 10.1.1.5 interface Vlanif100
#
return
1.12.2 Example for Configuring Multi-Hop BFD
As shown in Figure 1-6, SwitchA is indirectly connected to SwitchC. Static routes are
configured so that SwitchA can communicate with SwitchC. Faults on the link between
SwitchA and SwitchC need to be fast detected.
Figure 1-6 Networking diagram for configuring multi-hop BFD
SwitchA SwitchC SwitchB
10GE1/0/1
10.1.1.1/24
10GE1/0/1
10.1.1.2/24
10GE1/0/2
10.2.1.1/24
10GE1/0/1
10.2.1.2/24
VLAN 10 VLAN 20
Configure BFD sessions on SwitchA and SwitchC to detect the multi-hop route.
Procedure
Step 1 Add interfaces to VLANs, create VLANIF interfaces, and assign IP addresses to VLANIF
interfaces. The configuration details are not mentioned here.
Step 2 Configure a reachable static route between SwitchA and SwitchC.
[~HUAWEI] commit
[~SwitchA] ip route-static 10.2.0.0 16 10.1.1.2
[~SwitchA] commit
The configuration of SwitchC is similar to the configuration of SwitchA, and is not mentioned
here.
Step 3 Configure multi-hop BFD.
# Create a BFD session between SwitchA and SwitchC.
[~SwitchA] bfd
[~SwitchA-bfd] quit
19
[~SwitchA] bfd atoc bind peer-ip 10.2.1.2
[~SwitchA-bfd-session-atoc] discriminator local 10
[~SwitchA-bfd-session-atoc] discriminator remote 20
[~SwitchA-bfd-session-atoc] commit
[~SwitchA-bfd-session-atoc] quit
# Create a BFD session between SwitchC and SwitchA.
[~SwitchC] bfd
[~SwitchC-bfd] quit
[~SwitchC] bfd ctoa bind peer-ip 10.1.1.1
[~SwitchC-bfd-session-ctoa] discriminator local 20
[~SwitchC-bfd-session-ctoa] discriminator remote 10
[~SwitchC-bfd-session-ctoa] commit
[~SwitchC-bfd-session-ctoa] quit
After the configuration, run the display bfd session verbose command on SwitchA and
SwitchC. You can see that a BFD session is set up and is in Up state. Take the display on
SwitchA as an example.
--------------------------------------------------------------------------------
Name : atoc (Multi Hop) State : Up
--------------------------------------------------------------------------------
BFD Bind Type : Peer IP Address
Bind Interface : -
WTR Interval (ms) : - Detect Interval (ms) : 3000
Last Local Diagnostic : No Diagnostic
---------------------------------------------------------------
# Run the shutdown command on the 10GE1/0/1 interface of SwitchA to simulate a link fault.
[~SwitchA] interface 10ge 1/0/1
[~SwitchA-10GE1/0/1] commit
After the configuration, run the display bfd session all verbose command on SwitchA and
SwitchB. You can see that a multi-hop BFD session is set up and the status is Down. Take the
display on SwitchA as an example.
--------------------------------------------------------------------------------
Name : atoc (Multi Hop) State : Down
--------------------------------------------------------------------------------
BFD Bind Type : Peer IP Address
Bind Interface : -
FSM Board Id : - TOS-EXP : 7
20
WTR Interval (ms) : - Detect Interval (ms) : -
Last Local Diagnostic : Control Detection Time Expired
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface 10GE1/0/1
#
bfd atoc bind peer-ip 10.2.1.2
#
ip route-static 10.2.0.0 255.255.0.0 10.1.1.2
#
return
#
sysname SwitchB
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif20
ip address 10.2.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
bfd
#
vlan batch 20
#
interface Vlanif20
21
ip address 10.2.1.2 255.255.255.0
#
interface 10GE1/0/1
#
bfd ctoa bind peer-ip 10.1.1.1
#
ip route-static 10.1.0.0 255.255.0.0 10.2.1.1
#
return
This section describes common configuration errors of BFD.
1.13.1 BFD Session Cannot Become Up
Common Causes
This fault is commonly caused by one of the following:
l The link carrying the BFD session is faulty. As a result, BFD packets cannot be exchanged.
l The BFD session flaps frequently.
Procedure
Step 1 Run the display current-configuration configuration bfd-session command to check whether
the local and remote discriminators at both ends match.
l If the local and remote discriminators at both ends match, go to step 2.
l If the local and remote discriminators at both ends do not match, run the discriminator
command to correctly configure local and remote discriminators, and then run the display
bfd session all command to check whether the BFD session is Up.
If the value of the State field is Up, the BFD session has been established.
If the value of the State field is not Up, go to step 2.
Step 2 Run the display current-configuration configuration bfd-session command to check whether
the BFD detection time is longer than the delay before the BFD session becomes Up.
Detection time = Received Detect Multi of the remote system x Max (Local RMRI/Received
DMTI) Detect Multi is the local detection multiplier, which is set by using the detect-
multiplier command. The Required Min Rx Interval (RMRI) is the minimum interval for
receiving BFD packets, which is set by using the min-rx-interval command. The Desired Min
Tx Interval (DMTI) is the minimum interval for sending BFD packets, which is set by using the
min-tx-interval command.
The link delay can be obtained using the ping or tracert mechanism.
22
If the BFD detection time is shorter than the delay before the BFD session becomes Up, run the
detect-multiplier, min-rx-interval, and min-tx-interval commands to increase the BFD
detection time to be longer than the delay.
----End
23
2 DLDP Configuration
About This Chapter
DLDP can detect unidirectional links of optical fibers or copper twisted pairs.
2.1 DLDP Overview
DLDP is used to detect unidirectional links and shut down interfaces or notify the network
administrator if a unidirectional link fault occurs.
This section describes the default configuration of the DLDP.
2.3 Configure DLDP Functions
This section describes how to configure DLDP for detecting unidirectional links.
2.4 Resetting the DLDP Status
After the DLDP status of a disabled interface is reset, the interface re-detects unidirectional links.
2.5 Maintaining DLDP
You can monitor the DLDP running status and debug DLDP faults by maintaining DLDP.
This section provides examples for the DLDP configuration, including networking requirements,
This section describes common configuration errors of DLDP.
Configuration Guide - Reliability 2 DLDP Configuration
24
2.1 DLDP Overview
DLDP is used to detect unidirectional links and shut down interfaces or notify the network
administrator if a unidirectional link fault occurs.
The Device Link Detection Protocol (DLDP) can detect unidirectional links and take
corresponding measures. DLDP monitors the link status on devices connected through optical
fibers or copper twisted pairs. If a unidirectional link exists on an interface, DLDP automatically
shuts down or prompts users to manually shut down the interface to prevent network faults.
On running networks, optical fibers may be cross-connected, an optical fiber may be
disconnected, and a line in the copper twisted pair or optical fiber may be disconnected. In these
scenarios, the interface on one end of the link can receive the link layer packets from the peer
end, but the peer end cannot receive packets from the local end. This link is a unidirectional link.
The physical layer of a unidirectional link is in connected state and can work properly. The
detection mechanisms on the physical layer such as auto-negotiation cannot detect faults on
communication among devices. This may lead to incorrect forwarding of traffic.
As shown in Figure 2-1 and Figure 2-2, a unidirectional link fault may be caused by cross
connections of optical fibers or disconnection of an optical fiber.
Figure 2-1 Correct optical fiber connections
SwitchA
SwitchB
Interface 2
Interface 1 Interface 3
Interface 4
Figure 2-2 Cross-connected optical fibers
SwitchA
SwitchB
Interface 2
Interface 1 Interface 3
Interface 4
This section describes the default configuration of the DLDP.
Table 2-1 Default configuration of DLDP
Parameter Default Value
DLDP function Disabled
DLDP working mode Enhanced mode
Interval for sending Advertisement packets 5 seconds
Authentication mode of DLDP packets Non-authentication
Timeout value of the DelayDown timer 1 second
25
Parameter Default Value
Shutdown mode of an interface after a
unidirectional link is found
Automatic mode

2.3 Configure DLDP Functions
This section describes how to configure DLDP for detecting unidirectional links.
Before configuring DLDP, complete the following task:
l Ensure that the interfaces on both ends work in non-auto-negotiation mode.
2.3.1 Enabling DLDP
Context
Unidirectional links can be detected only when the devices on both ends of optical fibers or
copper twisted pairs support DLDP functions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
dldp enable
DLDP is enabled globally.
By default, DLDP is disabled globally and on each interface.
Step 3 Run:
interface interface-type interface-number
The interface view is displayed.
NOTE
l DLDP cannot be configured on Layer 3 interfaces or logical interfaces.
Step 4 Run:
dldp enable
DLDP is enabled on the interfaces.
Step 5 Run:
commit
26
----End
2.3.2 (Optional) Configuring the Working Mode of DLDP
Context
If DLDP works in normal mode, the system can identify only unidirectional links caused by
cross connections of optical fibers.
If DLDP works in enhanced mode, the system can identify unidirectional links caused by cross
connections of optical fibers and disconnection of one optical fiber. To detect unidirectional
links caused by disconnection of one optical fiber, manually set the rate and full duplex mode
of the connected interfaces. If you do not set the rate and full duplex mode of the connected
interfaces, DLDP does not take effect even if it is enabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
dldp work-mode { enhance | normal }
The working mode of DLDP is configured.
By default, the working mode of DLDP is enhance.
Step 3 Run:
commit
----End
2.3.3 (Optional) Configuring the DLDP-Compatible Mode
Context
If the device needs to work with some old Huawei switches to provide the DLDP function, this
configuration is required.
NOTE
In compatible mode, the BPDU MAC address carried in a DLDP packet is 010F-E200-0001.
Procedure
Step 1 Run:
system-view
27
Step 2 Run:
Step 3 Run:
dldp compatible-mode enable
The DLDP compatible mode is enabled.
If two devices are connected by two cross links, the DLDP compatible mode must be enabled
or disabled on both the two interfaces.
If two devices are Huawei devices (not preceding models), the DLDP compatible mode must
be enabled or disabled on both the two interfaces.
Step 4 Run:
dldp compatible-mode local-mac mac-address
The DLDP packets sent in the DLDP compatible mode contain MAC addresses.
After the DLDP compatible mode is enabled on the device, the peer device may discover multiple
neighbors, which leads to DLDP flapping. The dldp compatible-mode local-mac command
can prevent this problem.
NOTE
At least one bit in the MAC address must be 0, and the MAC address cannot be a multicast MAC address.
Step 5 Run:
commit
----End
2.3.4 (Optional) Setting the Interval for Sending Advertisement
Packets
Context
An interface in Advertisement state sends Advertisement packets. DLDP creates a neighbor
entry, starts the entry timer, and transits to the Probe state if the neighbor entry does not exist
on the peer interface. DLDP updates the entry timer if the neighbor entry exists.
The interval for sending Advertisement packets must be smaller than one third of the STP
convergence time. If the interval is too long, STP loops occur when a unidirectional link is still
enabled on a DLDP interface. If the interval is too short, the traffic volume on the network
increases.
Procedure
Step 1 Run:
system-view
28
Step 2 Run:
dldp interval interval
The interval for sending Advertisement packets is set.
By default, the interval for sending the Advertisement packets is 5 seconds.
NOTE
The same interval for sending Advertisement packets must be set on the local and remote devices that are
connected through optical fibers or copper twisted pairs; otherwise, DLDP cannot work properly.
Step 3 Run:
commit
----End
2.3.5 (Optional) Setting the Timeout Period of the DelayDown
Timer
Context
If a DLDP interface in Active, Advertisement, or Probe state receives a Port-Down event, the
interface enters Inactive state and clears the neighbor information. In some cases, the interface
is Down for a short time. For example, failure of the Tx fiber on an interface may cause jitter of
optical signals on the Rx fiber, which makes the interface Down and then Up again. To prevent
the neighbor information from being deleted immediately in this case, the DLDP interface first
enters the DelayDown state and starts the DelayDown timer. Before the DelayDown timer times
out, the interface retains the neighbor information and responds to only Port-Up events.
l If the DLDP interface does not receive any Port-Up event when the DelayDown timer times
out, the interface deletes the neighbor entry and enters the Inactive state.
l If the DLDP interface receives the Port-Up event before the DelayDown timer times out,
the interface returns to the previous state.
Procedure
Step 1 Run:
system-view
Step 2 Run:
dldp delaydown-timer time
The timeout period of the DelayDown timer is set.
The default timeout value of the DelayDown timer is 1 second.
Step 3 Run:
commit
----End
29
2.3.6 (Optional) Setting the Mode of Shutting Down an Interface
When a Unidirectional Link Is Detected
Context
When a unidirectional link is detected, DLDP shuts down the corresponding interface in either
of the following ways:
l Manual mode: When the network performance is poor, this mode can prevent DLDP from
affecting packet forwarding by shutting down the interface immediately when a
unidirectional link is detected. It is a compromise mode used to prevent interface shutdown
due to incorrect judgment of the system. In this mode, DLDP detects unidirectional links,
and the network administrator manually shuts down the interface. Upon detecting a
unidirectional link, DLDP records only log and trap messages and prompts the network
administrator to shut down the interface.
l Automatic mode: It is the default mode. When a unidirectional link is detected, DLDP
changes to the Disable state, records the log and trap messages, and sets the interface status
to Shutdown.
Procedure
Step 1 Run:
system-view
Step 2 Run:
dldp unidirectional-shutdown { auto | manual }
The interface shutdown mode when a unidirectional link is detected is set.
By default, DLDP automatically shuts down the interface when a unidirectional link is detected.
An interface in DLDP Down state still sends RecoverProbe packets periodically. If the interface
receives correct RecoverEcho packets, the unidirectional link changes to the bidirectional link
and the DLDP status of the interface becomes Up.
NOTE
When the network performance is good, the automatic mode is recommended. When the network performance
is low, the manual mode is recommended because the automatic mode may lead to a delay in receiving DLDP
packets and a unidirectional link may be detected mistakenly. The network administrator manually shuts down
the interface, preventing packet forwarding from being affected by automatic interface shutdown.
Step 3 Run:
commit
----End
2.3.7 (Optional) Configuring the Authentication Mode for DLDP
Packets
30
Context
To ensure packet validity on an insecure network, users can configure one of the following
authentication modes for DLDP packets.
Table 2-2 Authentication modes of DLDP packets
Authentication Mode Description
Non-authentication mode The receiver compares the authentication key
and authentication type of the packet with
those configured on the local end. If they are
different, the receiver discards the packet.
Simple authentication mode The receiver compares the authentication key
and authentication type of the packet with
those configured on the local end. If they are
different, the receiver discards the packet.
MD5 authentication mode The receiver compares the authentication key
and authentication type of the packet with the
MD5-encrypted password and authentication
type that are configured on the local end. If
they are different, the receiver discards the
packet.

Procedure
Step 1 Run:
system-view
Step 2 Run:
dldp authentication-mode { md5 md5password | simple simple-password }
The authentication mode is configured for DLDP packets.
By default, the DLDP packets between the interfaces on the local device and the remote device
are not authenticated.
NOTE
The local and remote devices must use the same authentication mode and the authentication password; otherwise,
the authentication fails. DLDP works properly only after the authentication succeeds.
Step 3 Run:
commit
----End
2.3.8 Checking the Configuration
31
Procedure
l Run the display dldp [ interface interface-type interface-number | brief ] command to
check the DLDP configuration and neighbor information entries.
----End
2.4 Resetting the DLDP Status
After the DLDP status of a disabled interface is reset, the interface re-detects unidirectional links.
Context
When a unidirectional link is detected, the interface enters the Disable state. The system prompts
you to shut down the interface or automatically sets the interface state to DLDP Down according
to the configuration. To enable the interface to detect unidirectional links again, you can reset
the DLDP status of the interface as follows:
l If the interface is shut down using the shutdown command, run the undo shutdown
command to enable the interface to detect unidirectional links again.
l If the system automatically sets the interface state to DLDP Down, wait the interface to
recover using the auto recovery mechanism after the link state becomes bidirectional. You
can also run the dldp reset command to reset the DLDP status of the interface.
When you reset the DLDP status globally on a device, the DLDP status is reset for all the disabled
ports on the device. When you reset the DLDP status on a disabled interface, the DLDP status
is reset only for this interface.
Procedure
l Reset the DLDP status globally.
1. Run:
system-view
2. Run:
dldp reset
The DLDP status is reset globally.
3. Run:
commit
l Reset the DLDP status on an interface.
1. Run:
system-view
2. Run:
3. Run:
dldp reset
32
The DLDP status is reset for the interface.
4. Run:
commit
----End
2.5 Maintaining DLDP
You can monitor the DLDP running status and debug DLDP faults by maintaining DLDP.
Context
To view DLDP statistics within a specified period, clear existing statistics and then use a display
command.
NOTE
The DLDP statistics cannot be restored after being cleared; therefore, confirm the action before you perform
the operation.
Procedure
l Run the reset dldp statistics [ interface interface-type interface-number ] command in the
user interface to clear DLDP packet statistics.
----End
This section provides examples for the DLDP configuration, including networking requirements,
2.6.1 Example for Configuring DLDP to Detect a Disconnected
Optical Fiber Link
As shown in Figure 2-3, SwitchA and SwitchB are connected through a pair of optical fibers.
On an optical fiber, Rx indicates the receive end, and Tx indicates the transmit end. The
requirement is to detect unidirectional links.
Tx
Tx Rx
Rx
Switch A Switch B
10GE1/0/1 10GE1/0/1
33
1. Configure the interfaces on both ends to work in non-auto-negotiation mode.
2. Enable DLDP to detect unidirectional links between SwitchA and SwitchB.
3. Adjust DLDP parameters to detect unidirectional links more efficiently.
Procedure
Step 1 Enable DLDP globally.
[~SwitchA] commit
[~SwitchA] dldp enable
[~SwitchA] commit
Step 2 Enable DLDP on an interface of SwitchA.
[~SwitchA-10GE1/0/1] dldp enable
Step 3 Set the interval for sending Advertisement packets to 10 seconds on SwitchA.
[~SwitchA] dldp interval 10
[~SwitchA] commit
Step 4 Set the timeout value of the DelayDown timer to 4 seconds on SwitchA.
[~SwitchA] dldp delaydown-timer 4
[~SwitchA] commit
Step 5 Set the authentication mode of DLDP packets to simple password authentication and set the
password to 12345 on SwitchA.
[~SwitchA] dldp authentication-mode simple 12345
[~SwitchA] commit
Perform steps 1 to 6 on SwitchB.
After the configuration is complete, run the display dldp command in the interface view. The
command output shows that the DLDP status of the interface is advertisement.
[~SwitchA] display dldp
DLDP global status : enable
DLDP interval(s) : 10
DLDP work mode : enhance
DLDP authentication mode : simple
DLDP authentication password : Ls#e*h445SZypQCee$t3w=%#
DLDP unidirectional shutdown : auto
DLDP delaydown timer(s) : 4
The number of enabled ports : 1
The number of global neighbors : 1
Interface 10GE1/0/1
DLDP port state : advertisement
DLDP link state : up
The neighbor number of the port : 1
Neighbor mac address : 0025-9e95-7c21
Neighbor port index : 80
Neighbor state : two way
Neighbor aged time(s) : 11
Neighbor created time : 2013-06-09 15:09:25
34
Simulate an optical fiber disconnection by removing the receive optical fiber from SwitchA.
DLDP automatically shuts down 10GE1/0/1 on SwitchB when a unidirectional link occurs
between SwitchA and 10GE1/0/1 on SwitchB.
# Run the display dldp command on SwitchA and SwitchB. The command output shows that
the DLDP status of 10GE1/0/1 on SwitchA is inactive, and the DLDP status of 10GE1/0/1 on
SwitchB is disable.
[~SwitchA] display dldp interface 10ge 1/0/1
Interface 10GE1/0/1
DLDP port state : inactive
DLDP link state : down
[~SwitchB] display dldp interface 10ge 1/0/1
Interface 10GE1/0/1
DLDP port state : disable
DLDP link state : down
----End
Configuration Files
#
sysname SwitchA
#
dldp enable
dldp interval 10
dldp delaydown-timer 4
dldp authentication-mode simple %$%$%;a:%$%$%;a:
#
interface 10GE1/0/1
dldp enable
#
return
#
sysname SwitchB
#
dldp enable
dldp interval 10
#
interface 10GE1/0/1
dldp enable
#
return
2.6.2 Example for Configuring DLDP to Detect Cross-Connected
Optical Fibers
As shown in Figure 2-4, SwitchA and SwitchB are connected through a pair of optical fibers.
On an optical fiber, Rx indicates the receive end, and Tx indicates the transmit end. Optical
fibers may be cross connected, as shown in Figure 2-5. The requirement is to detect
unidirectional links caused by cross connections of optical fibers.
35
SwitchA SwitchB
10GE1/0/2
10GE1/0/1 10GE1/0/1
10GE1/0/2
Rx Tx
Rx
Rx
Tx
Tx
Figure 2-5 Cross-connected optical fibers
SwitchA SwitchB
10GE1/0/2
10GE1/0/1 10GE1/0/1
10GE1/0/2
Rx Tx
Rx
Rx
Tx
Tx
1. Configure the interfaces on both ends to work in non-auto-negotiation mode.
2. Enable DLDP to detect unidirectional links between SwitchA and SwitchB.
3. Adjust DLDP parameters to detect unidirectional links more efficiently.
Procedure
Step 1 Enable DLDP globally on SwitchA.
[~SwitchA] commit
[~SwitchA] dldp enable
[~SwitchA] commit
Step 2 Enable DLDP on an interface of SwitchA.
Step 3 Set the interval for sending Advertisement packets to 10 seconds on SwitchA.
[~SwitchA] dldp interval 10
[~SwitchA] commit
Step 4 Set the timeout value of the DelayDown timer to 4 seconds on SwitchA.
[~SwitchA] dldp delaydown-timer 4
[~SwitchA] commit
Step 5 Set the authentication mode of DLDP packets to simple password authentication and set the
password to 12345 on SwitchA.
[~SwitchA] dldp authentication-mode simple 12345
[~SwitchA] commit
Perform steps 1 to 6 on SwitchB.
36
After the configuration is complete, run the display dldp command in the interface view. The
command output shows that the DLDP status of the interface is advertisement.
Interface 10GE1/0/1
Neighbor mac address : 0001-0001-0001
Neighbor created time : 2009/2/13 11:40:49
Interface 10GE 1/0/2
Neighbor mac address : 0001-0001-0001
Interface 10GE1/0/1
Neighbor mac address : 781d-ba57-c24a
Interface 10GE 1/0/2
Neighbor mac address : 781d-ba57-c24a
As shown in Figure 2-5, if a unidirectional link occurs between the interfaces on SwitchA and
SwitchB due to cross connections of optical fibers, DLDP will shut down the interfaces.
Run the display dldp command on SwitchA and SwitchB. The command output shows that the
DLDP status of interfaces on SwitchA and SwitchB is disable.
Interface 10GE1/0/1
The neighbor number of the port is: 0
Interface 10GE1/0/2
Interface 10GE1/0/1
Interface 10GE1/0/2
37
----End
Configuration Files
#
sysname SwitchA
#
dldp enable
dldp interval 10
#
interface 10GE1/0/1
dldp enable
#
interface 10GE1/0/2
dldp enable
#
return
#
sysname SwitchB
#
dldp enable
dldp interval 10
#
interface 10GE1/0/1
dldp enable
#
interface 10GE1/0/2
dldp enable
#
return
This section describes common configuration errors of DLDP.
2.7.1 DLDP Cannot Discover a Directly Connected Neighbor
Common Cause
This fault is commonly caused by one of the following:
l The link between the local device and directly connected neighbor failed.
l DLDP is disabled on the peer device.
l DLDP parameters on the local and the peer devices are different.
38
Procedure
Step 1 Run the display interface interface-type interface-number command to check the status of the
interface that cannot discover the peer device.
l If the interface status is Down, rectify the failure.
l If the interface status is Up, go to step 2.
Step 2 Run the display dldp command to see whether DLDP is enabled globally, that is, run the display
this command in the interface view to check whether the output information contains the dldp
enable field. If so, DLDP has been enabled on the interface; if not, DLDP is disabled on the
interface.
l If DLDP is not enabled globally or on an interface, run the dldp enable command in the
corresponding view to enable DLDP.
l If DLDP is enabled, go to step 3.
Step 3 Run the display dldp command to check whether the DLDP parameters on the local and peer
devices are the same.
Field Method
DLDP interval Check whether the intervals on both ends are
the same. If the intervals for sending DLDP
packets on both ends are different, run the
dldp interval interval command in the
system view on both devices to set the same
interval on both devices.
DLDP authentication-mode Check whether authentication modes and
passwords on both ends are the same. If the
two devices use different authentication
modes or passwords, run the dldp
authentication-mode { md5 md5-password
| simple simple-password | none } command
in the system view to set the same
authentication mode and password on both
devices.
----End
39
3 VRRP Configuration
About This Chapter
The Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol. VRRP switches
services from the master device to the backup router when the next hop device of the master
device fails. This ensures nonstop service transmission and reliability.
3.1 Introduction to VRRP
VRRP is a fault-tolerant protocol and provides a single default gateway address for hosts. If a
VRRP-enabled device fails, another VRRP-enabled device takes over traffic, ensuring
continuity and reliability for network communication.
3.2 VRRP Features Supported by the Device
The device supports basic VRRP functions and VRRP association.
This section provides the default VRRP configuration.
3.4 Configuring Basic Functions of an IPv4 VRRP Group
An IPv4 VRRP group implements gateway backup and ensures stable and efficient data
forwarding.
3.5 Configuring an IPv4 mVRRP Group
An mVRRP group can be bound to VRRP groups and determine the status of its bound VRRP
groups. mVRRP is often used to solve dual-homing problems.
3.6 Configuring VRRP Association
VRRP association enables VRRP to detect faults in a timely manner and triggers an active/
standby switchover when the master or the uplink of the master becomes faulty. VRRP
association optimizes VRRP switchover and enhances network reliability.
3.7 Maintaining VRRP
This section describes how to maintain VRRP, including monitoring the VRRP running status
and clearing VRRP packet statistics.
This section provides several configuration examples of VRRP.
Configuration Guide - Reliability 3 VRRP Configuration
40
This section describes common faults caused by incorrect VRRP configurations and provides
the troubleshooting procedure.
41
3.1 Introduction to VRRP
VRRP is a fault-tolerant protocol and provides a single default gateway address for hosts. If a
VRRP-enabled device fails, another VRRP-enabled device takes over traffic, ensuring
continuity and reliability for network communication.
As networks rapidly develop and applications become diversified, various value-added services
such as IPTV and video conferencing are widely used. Demands for network infrastructure
reliability are increasing, especially in nonstop network transmission for users.
Generally, hosts communicate with external networks through the gateway, as shown in Figure
3-1. When the gateway is faulty, hosts fail to communicate with external networks. One method
to prevent communication interruption is usually to configure multiple egress gateways.
However, terminal devices cannot select routes to these gateways because terminal devices often
do not support routing protocols.
Figure 3-1 Default gateway on a LAN
SwitchA
HostA
10.1.1.100/24
Gateway
HostB
10.1.1.101/24
10.1.1.1/24
Internet
Data flow1
Data flow2
VRRP virtualizes multiple routing devices into a virtual gateway device and uses the virtual
gateway device IP address as the default gateway address. When the gateway device becomes
faulty, VRRP uses a new gateway device to transmit service traffic. This ensures reliable
communication.
As shown in Figure 3-2, a VRRP group is configured on SwitchA and SwitchB. The VRRP
group virtualizes two devices into one gateway device. The virtual gateway device has a virtual
IP address and a virtual MAC address. Hosts only detect the virtual gateway device and use the
virtual IP address as the gateway address to communicate with external networks.
Normally, user-side traffic is forwarded by the master. When the master becomes faulty, a new
master SwitchB is selected among backups through negotiation. The new master then forwards
traffic.
42
Figure 3-2 VRRP group
Virtual IP Address
10.1.1.1/24
SwitchA
Master
Internet
HostA
10.1.1.100/24
HostB
10.1.1.101/24
SwitchB
Backup
Virtual IP Address
10.1.1.1/24
SwitchA
Initialize
Internet
HostA
10.1.1.100/24
HostB
10.1.1.101/24
SwitchB
Master
Data flow1
Data flow2
3.2 VRRP Features Supported by the Device
The device supports basic VRRP functions and VRRP association.
NOTE
Only VLANIF interfaces support VRRP.
VRRP Configuration Logic
The configuration logic is as follows:
l Configure basic VRRP functions: The active/standby mode and load balancing mode are
configured. The active/standby mode is often used. In load balancing mode, multiple VRRP
groups are configured, which implements gateway backup and load balances traffic.
l VRRP association: VRRP association enables VRRP to detect faults in a timely manner
and triggers an active/standby switchover when the master or the uplink of the master
43
becomes faulty. After basic VRRP functions are configured, you can configure VRRP
association to optimize VRRP switchover and enhance network reliability.
Basic VRRP Functions
l VRRP active/standby mode
In practice, hosts use the default gateway to communicate with external networks. If the
default gateway is faulty, hosts may fail to communicate with external networks. You can
configure the VRRP active/standby mode. Multiple devices are virtualized into a gateway
device. The virtual gateway device consists of a master device and multiple backup devices.
Normally, user-side traffic is forwarded by the master. When the master becomes faulty, a
new master is selected among backups through negotiation. The new master then forwards
traffic.
l VRRP load balancing mode
When all hosts on a LAN communicate with external networks through a gateway, traffic
may be congested or lost on the gateway. You can configure the load balancing mode. That
is, multiple VRRP groups are configured. Each VRRP group consists of one master and
multiple backups and VRRP groups have different masters. The virtual IP address of each
VRRP group is configured as the default gateway address of some hosts so that traffic is
load balanced and gateways back up each other.
mVRRP
Figure 3-3 mVRRP networking
NPE1
NPE2
UPE
mVRRP
As shown in Figure 3-3, to improve network reliability, a UPE is usually dual-homed to two
NPEs. NPEs run mVRRP to determine the master and backup statuses.
The only difference between an mVRRP group and a VRRP group is that the mVRRP group
can be bound to VRRP groups and determine the status of its bound VRRP groups.
Although an mVRRP group can be bound to multiple VRRP groups, the mVRRP group cannot
be bound to any other mVRRP groups as a VRRP group.
The objects that can be bound to mVRRP in different scenarios are described as follows:
l Binding a VRRP group to an mVRRP group: An UPE is connected to two NPEs. VRRP
runs between NPEs. The VRRP priority determines whether an NPE is the master or
backup. Multiple VRRP groups can be configured on the two NPEs to transmit various
types of services.
44
Each VRRP group needs to maintain its own state machine; therefore, a large number of
VRRP packets are transmitted between NPEs. To help simplify VRRP operation and
decrease bandwidth consumption, a VRRP group is configured as an mVRRP group and
bound to other VRRP groups. mVRRP determines the status of its bound VRRP groups.
VRRP Association
VRRP association optimizes VRRP switchovers and enhances network reliability. You can
configure VRRP to monitor the status of other objects. When the status of the monitored object
changes, an active/standby switchover is performed. Table 3-1 shows objects with which VRRP
is associated and association scenarios.
Table 3-1 Objects with which VRRP is associated and association scenarios
Object Association Scenario
Association
between VRRP
and BFD to
implement a
rapid active/
standby
switchover
When a VRRP group is faulty, the backup detects the fault and switches
to the master after the Master_Down_Interval timer expires. The
switchover period is at least 3s. During the switchover period, service
traffic is still sent to the original master, causing user traffic loss. You can
associate a VRRP group with a BFD session so that the BFD session can
rapidly detect communication faults of the VRRP group. When the BFD
session detects a fault, it notifies the VRRP group that the priority of the
backup needs to be increased. Then an active/standby switchover is
triggered immediately. This millisecond-level switchover reduces traffic
loss.
Association
between a
VRRP group
and the interface
status
When the uplink logical interface of the master becomes faulty, VRRP
cannot detect the status change of interfaces not in a VRRP group. This
may interrupt services. You can associate a VRRP group with the interface
status. When the monitored logical interface is faulty, the priority of the
master is adjusted. This triggers an active/standby switchover and reduces
the impact of services on the uplink interface.
Association
between a
VRRP group
and BFD to
monitor the
uplink status
Because VRRP cannot detect faults on the uplink of a VRRP group,
services may be interrupted. You can associate a VRRP group with a BFD
session on the master so that the BFD session monitors the uplink status
of the master. When the BFD session detects faults on the uplink, it notifies
the VRRP group that the priority of the master needs to be decreased. Then
an active/standby switchover is triggered immediately. This reduces the
impact of uplink faults on service forwarding.
BFD implements millisecond-level detection. Association between VRRP
and BFD provides fast active/standby switchover.
Association
between a
VRRP group
and routing to
monitor the
uplink status
Because VRRP cannot detect faults on the uplink of a VRRP group,
services may be interrupted. The VRRP group monitors the number of
routes on the uplink forwarding path. When the route is withdrawn or
becomes inactive, the master' priority is adjusted and an active/standby
switchover is performed. This reduces link faults on service forwarding.
During route association, link switchover depends on convergence of a
routing protocol associated with the VRRP group.
45
Object Association Scenario
Association
between a
VRRP group
and a direct
route
When a VRRP group is configured, uplink traffic passes the master. The
downlink traffic is often transmitted through a route of a dynamic routing
protocol, so the downlink traffic may pass the master or backup, or be load
balanced. Uplink and downlink traffic may be transmitted along different
paths. If the firewall is configured for the VRRP group, the firewall blocks
traffic that is sent and received along different paths. In addition, it is
difficult to monitor such traffic and collect traffic statistics.
You can associate a VRRP group with a direct route so that VRRP affects
route selection of a dynamic routing protocol.

This section provides the default VRRP configuration.
Table 3-2 Default VRRP configuration
Parameter Default Setting
Priority of the device in a VRRP group 100
Preemption Immediate preemption mode
Interval at which VRRP Advertisement
packets are sent
1s
Interval at which gratuitous ARP packets are
sent
120s

3.4 Configuring Basic Functions of an IPv4 VRRP Group
An IPv4 VRRP group implements gateway backup and ensures stable and efficient data
forwarding.
Before configuring basic functions of an IPv4 VRRP group, complete the following task:
l Configuring network layer attributes of interfaces to ensure network connectivity
3.4.1 Creating a VRRP Group
Applicable Scenario
VRRP virtualizes multiple routing devices into a virtual gateway device and uses the virtual
gateway device IP address as the default gateway address. After a VRRP group is configured,
traffic is forwarded through the master. When the master fails, a new master is selected among
backup devices to forward traffic. This implements gateway backup.
46
If load balancing is required in addition to gateway backup, configure two or more VRRP groups
on an interface in single-gateway load balancing mode or multi-gateway load balancing mode.
CAUTION
If both VRRP and static ARP are configured on a VLANIF interface on a device, an IP address
mapped to a static ARP entry cannot be used as a virtual IP address. If a VRRP virtual IP address
is an IP address mapped to a static ARP entry on the device, the device generates incorrect host
routes, affecting traffic forwarding.
In mVRRP, if a device has a virtual IP address, the device does not support load balancing.
In load balancing scenarios, you must run the arp fast-reply disable command to disable the
ARP fast reply funcion.
Procedure
l Create a VRRP group working in master/backup mode.
1. Run:
system-view
2. Run:
3. Run:
vrrp vrid virtual-router-id [ virtual-ip virtual-address ]
A VRRP group is created, and a virtual IP address is assigned to the VRRP group.
NOTE
l VRRP groups must use different virtual IP addresses. The virtual IP address of a VRRP
group must be on the same network segment as the IP address of the interface where the
VRRP group is configured.
l Two devices in a VRRP group must be configured with the same VRID.
l Different interfaces can be bound to the same VRRP group.
l Create VRRP groups working in multi-gateway load balancing mode.
If VRRP groups need to work in multi-gateway load balancing mode, repeat the steps to
configure two or more VRRP groups on the interface and assign different VRIDs to them.
l Create VRRP groups working in single-gateway load balancing mode.
1. Run:
system-view
2. Run:
3. Run:
vrrp vrid virtual-router-id virtual-ip virtual-address
47
A VRRP group is created.
If you use the VRRP group as a load-balance redundancy group (LBRG), you must
assign a virtual IP address to the VRRP group.
If you use the VRRP group as an LBRG member group, you do not need to assign
a virtual IP address to the VRRP group.
4. Run:
vrrp vrid virtual-router-id priority priority-value
A VRRP priority is set for the device.
5. Run:
vrrp vrid virtual-router-id load-balance
An LBRG is created.
6. Run:
vrrp vrid virtual-router-id join load-balance-vrrp vrid lb-vrid-value
A VRRP group is added to the LBRG.
----End
3.4.2 Setting the Device Priority in a VRRP Group
Context
The device with a higher priority in a VRRP group is more likely to become the master. You
can specify the master by setting the device priority.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The device priority in a VRRP group is set.
By default, the device priority is 100.
NOTE
l Priority 0 is reserved in the system. Priority 255 is reserved for the IP address owner, and the priority
of the IP address owner cannot be changed. The priority that can be set ranges from 1 to 254.
l When devices in a VRRP group have the same priority, if devices preempt to be the master
simultaneously, the device on an interface with the largest IP address is the master. The device that
first switches to Master state becomes the master.
----End
48
3.4.3 (Optional) Configuring VRRP Time Parameters
Context
You can set VRRP time parameters as needed. Table 3-3 lists applicable scenarios.
Table 3-3 Applicable scenarios of VRRP time parameters
Function Applicable Scenario
Interval at which
VRRP
Advertisement
packets are sent
The master in a VRRP group sends VRRP Advertisement packets to
the backup at intervals to notify that it works properly. After the
Master_Down_Interval timer expires, the backup switches to the master
if it does not receive VRRP Advertisement packets.
Heavy network traffic or time differences on different devices may
result in the status change of the backup due to timeout of VRRP
packets. When packets from the original master reach the new master,
the status of the new master changes. You can increase the interval to
solve this problem.
Preemption delay On an unstable network, if the BFD session status monitored by a VRRP
group flaps frequently or the backup cannot receive VRRP
Advertisement packets within a specified period, an active/standby
switchover is frequently performed, which causes network flapping.
You can adjust the preemption delay of the master in the VRRP group
so that the backup preempts to be the master after the delay. This
prevents frequent change of the VRRP group status.
Timeout interval at
which gratuitous
ARP packets are
sent by the master
To ensure that MAC address entries on the downstream switch are
correct, the master in the VRRP group periodically sends gratuitous
ARP packets to update MAC address entries on the downstream switch.
Delay in
recovering a VRRP
group
On an unstable network, frequent flapping of the BFD session status or
interface status monitored by a VRRP group may result in frequent
switching of the VRRP group status. After the delay in recovering a
VRRP group is set, the VRRP group does not immediately respond to
an interface or BFD session Up event. Instead, the VRRP group
processes this event after the delay in recovering a VRRP group. This
prevents frequent switching of the VRRP group status.

Procedure
l Setting the interval at which VRRP Advertisement packets are sent
1. Run:
system-view
2. Run:
49
3. Run:
vrrp vrid virtual-router-id timer advertise advertise-interval
The interval at which VRRP Advertisement packets are sent is set.
By default, the interval is 1 second.
l Setting the preemption delay of the master
1. Run:
system-view
2. Run:
3. Run:
vrrp vrid virtual-router-id preempt timer delay delay-value
The preemption delay is set.
By default, the preemption delay is 0. In immediate preemption mode, a backup can
immediately preempt to be the master when its priority is higher than the master.
You can use the vrrp vrid virtual-router-id preempt disable command to set the non-
preemption mode. In non-preemption mode, the master that works properly can retain
the Master state. The backup cannot preempt to be the master even if the priority of
the master decreases.
You can use the undo vrrp vrid virtual-router-id preempt command to restore the
default preemption mode.
NOTE
It is recommended that you set the preemption delay of the backup in a VRRP group to 0,
configure the master in preemption mode, and set the preemption delay. On an unstable
network, these settings allow a period of time for status synchronization between the uplink
and downlink. If the preceding settings are not used, two masters coexist and users devices
may learn incorrect address of the master.
l Setting the timeout interval at which gratuitous ARP packets are sent by the master
1. Run:
system-view
2. Run:
vrrp gratuitous-arp interval interval-value
The timeout interval at which gratuitous ARP packets are sent by the master is set.
By default, the master sends gratuitous ARP packets every 120s.
NOTE
The timeout interval at which the master sends gratuitous ARP packets must be shorter than
the aging time of ARP entries on user devices.
To restore the default interval at which a gratuitous ARP packet is sent, run the
undo vrrp gratuitous-arp interval command in the system view.
50
If the master does not need to send gratuitous ARP packets, run the vrrp
gratuitous-arp interval disable command in the system view.
l Setting the delay in recovering a VRRP group
1. Run:
system-view
2. Run:
vrrp recover-delay delay-value
The delay in recovering a VRRP group is set.
By default, the delay in recovering a VRRP group is 0.
NOTE
l After this command is used, all VRRP groups on the device are configured with the same
delay.
l When the device in a VRRP group restarts, VRRP status flapping may occur. It is
recommended that the delay be set based on actual networking.
----End
3.4.4 (Optional) Setting the Mode in Which VRRP Packets Are Sent
in a Super-VLAN
Context
When a VRRP group is configured in a super VLAN, VRRP Advertisement packets can be sent
to a specified sub-VLAN or all sub-VLANs of the super-VLAN. Sending VRRP Advertisement
packets to a specified sub-VLAN efficiently saves network bandwidth.
Prerequisites
A super-VLAN has been configured.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
vrrp advertise vlan { sub-vlan-id | all }
The mode in which VRRP Advertisement packets are sent in a super-VLAN is set.
By default, the master sends VRRP Advertisement packets to a sub-VLAN that is Up and has
the smallest VLAN ID in the super-VLAN.
51
l If sub-vlan-id is specified, the master sends VRRP Advertisement packets to a specified sub-
VLAN.
l If all is specified, the master broadcasts VRRP Advertisement packets to all sub-VLANs of
a super-VLAN.
CAUTION
If all is specified, the master broadcasts VRRP Advertisement packets to all sub-VLANs of a
super-VLAN. This causes bandwidth usage to increase. Therefore, do not specify all.
----End
3.4.5 (Optional) Disabling VRRP TTL Check
Context
The system checks the TTL value in received VRRP packets, and discards VRRP packets in
which the TTL value is not 255. On a network where devices of different vendors are deployed,
if TTL check is enabled on the device, the device may incorrectly discard valid packets. In this
case, disable TTL check so that devices of different vendors can communicate.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
vrrp check ttl disable
The device is configured not to check the TTL value in VRRP packets.
By default, the system checks the TTL value in VRRP packets.
----End
3.4.6 (Optional) Setting the Authentication Mode of VRRP Packets
Context
On a secure network, the device considers received VRRP packets valid.
On a vulnerable network, VRRP provides simple authentication and Message Digest 5 (MD5)
authentication:
l Simple authentication: The device encapsulates the authentication mode and authentication
key into an outgoing VRRP Advertisement packet. The device that receives the VRRP
52
Advertisement packet compares the authentication mode and authentication key in the
received packet with those configured on the device. If the values are the same, the device
considers the received VRRP Advertisement packet valid. If the values are different, the
device considers the received VRRP Advertisement packet invalid and discards it.
l MD5 authentication: The device uses the MD5 algorithm to encrypt the authentication key
and encapsulates the key in the Authentication Data field of an outgoing VRRP
Advertisement packet. The device matches the authentication mode with the decrypted
authentication key in the received VRRP Advertisement packet.
NOTE
l MD5 authentication provides higher security than simple authentication.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
vrrp vrid virtual-router-id authentication-mode { simple { key | plain key |
cipher cipher-key } | md5 md5-key }
The authentication mode in VRRP Advertisement packets is configured.
NOTE
l Devices in a VRRP group must be configured with the same authentication mode and authentication
key; otherwise, the VRRP group cannot negotiate the Master and Backup status.
l An MD5 key can be entered in cipher text or plain text. The MD5 key in plain text is a string of 1 to 8
characters, and the MD5 key in cipher text is a string of 32 characters.
----End
3.4.7 (Optional) Enabling the Ping to a Virtual IP Address
Context
The device allows user devices to ping a virtual IP address to serve the following purposes:
l Monitors the operating status of the master in a VRRP group.
l Monitors communication between a user device and a network connected through a default
gateway that uses the virtual IP address.
Procedure
Step 1 Run:
system-view
53
Step 2 Run:
undo vrrp virtual-ip ping disable
The ping to a virtual IP address is enabled.
By default, the ping function is enabled. The master in a VRRP group responds to ping packets
sent to the virtual IP address.
CAUTION
If the ping to a virtual IP address is enabled, a device on an external network can ping a virtual
address. This exposes the device to ICMP-based attacks. The undo vrrp virtual-ip ping
disable command can be used to disable the ping function.
----End
Procedure
l Run the display vrrp [ admin-vrrp | [ interface interface-type interface-number [ virtual-
router-id ] | virtual-router-id ] [ verbose ] ] command to check the VRRP group status and
parameters.
l Run the display vrrp [ interface interface-type interface-number ] [ virtual-router-id ]
statistics command to check statistics about sent and received packets of a VRRP group.
----End
3.5 Configuring an IPv4 mVRRP Group
An mVRRP group can be bound to VRRP groups and determine the status of its bound VRRP
groups. mVRRP is often used to solve dual-homing problems.
3.5.1 Configuring an mVRRP Group
Context
Each VRRP group needs to maintain its own state machine. Configuring an mVRRP group
reduces bandwidth occupied by VRRP packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
54
Step 3 Run:
Step 4 Run:
The priority of the VRRP group is configured.
Step 5 Run:
vrrp vrid virtual-router-id admin [ ignore-if-down ]
The VRRP group is configured as an mVRRP group.
----End
3.5.2 (Optional) Configuring a VRRP Group and Binding the VRRP
Group to an mVRRP Group
Context
You can bind VRRP groups to an mVRRP group so that mVRRP determines the status of the
bound VRRP groups.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the interface where a VRRP group is configured is displayed.
Step 3 Run:
Because the mVRRP group determines the status of its service VRRP groups, you do not need
to set priorities for the bound VRRP groups.
Step 4 Run:
vrrp vrid virtual-router-id1 track admin-vrrp interface interface-type interface-
number vrid virtual-router-id2 trigger-down
The VRRP group is bound to an mVRRP group.
After the binding is complete, the state machine of the bound VRRP group depends on the status
of the mVRRP group. The bound VRRP group inherits the status of the mVRRP group, and
55
deletes its VRRP packet timeout timer and stops sending or receiving VRRP packets. A VRRP
group can be bound to only one mVRRP group.
----End
Procedure
l Run the display vrrp binding [ interface admin-interface-type admin-interface-number ]
[ vrid admin-virtual-router-id ] [ member-vrrp interface member-interface-type member-
interface-number [ vrid member-virtual-router-id ] ]command to check information about
mVRRP group binding.
----End
3.6 Configuring VRRP Association
VRRP association enables VRRP to detect faults in a timely manner and triggers an active/
standby switchover when the master or the uplink of the master becomes faulty. VRRP
association optimizes VRRP switchover and enhances network reliability.
Before configuring basic functions of an IPv4 VRRP group, complete the following task:
l 3.4 Configuring Basic Functions of an IPv4 VRRP Group
You can configure VRRP association only after basic VRRP functions are configured.
3.6.1 Configuring Association Between VRRP and BFD to
Implement a Rapid Active/Standby Switchover
Context
When a VRRP group is faulty, the backup detects the fault and switches to the master after the
Master_Down_Interval timer expires. The switchover period is at least 3s. During the switchover
period, service traffic is still sent to the original master, causing user traffic loss. As shown in
Figure 3-4, the VRRP group is associated with a BFD session on the backup so that the BFD
session can rapidly detect communication faults of the VRRP group. When the BFD session
detects a fault, it notifies the VRRP group that the priority of the backup needs to be increased.
Then an active/standby switchover is triggered immediately. This millisecond-level switchover
reduces traffic loss.
When the fault is rectified, the priority of the backup is restored and the original master preempts
to be the master to forward traffic.
NOTE
l A VRRP group can be associated with only a static BFD session or a static BFD session with
automatically negotiated discriminators.
l The master and backup in the VRRP group must work in preemption mode. It is recommended that
the preemption delay be 0 on the backup and non-0 on the master.
56
Figure 3-4 Association between VRRP and BFD to implement a rapid active/standby switchover
Internet
VRRP
Master
SwitchA
SwitchB
Backup
BFD packets
HostB
Switch
HostA
Procedure
Step 1 Configure a static session or a static BFD session with automatically negotiated discriminators.
For details, see 1.4 Configuring Single-Hop BFD, 1.5 Configuring Multi-Hop BFD, or 1.6
Configuring Static BFD with Automatically Negotiated Discriminators.
Step 2 Run:
system-view
Step 3 Run:
The view of the interface on the backup where a VRRP group is configured is displayed.
Step 4 Run:
vrrp vrid virtual-router-id track bfd { bfd-session-id | session-name bfd-configure-
name } [ increase value-increased | reduce value-reduced ]
Association between VRRP and BFD is configured.
NOTE
When associating a VRRP group with a BFD session, note the following points:
l If session-name bfd-configure-name is specified, the VRRP group can bind to only a static BFD session
with automatically negotiated discriminators.
l If bfd-session-id is specified, the VRRP group can bind to only a static BFD session.
l After the VRRP group is associated with a BFD session, the BFD session type cannot be modified.
Before deleting the BFD session type, you must delete all original configurations.
l After the value by which the priority increases is set, ensure that the priority of the backup is higher
than the priority of the master.
----End
3.6.2 Configuring Association Between VRRP and Link/Peer BFD
to Implement a Rapid Active/Standby Switchover
57
Context
When a VRRP group is faulty, the backup detects the fault and switches to the master after the
Master_Down_Interval timer expires. The switchover period is at least 3s. During the switchover
period, service traffic is still sent to the original master, causing user traffic loss. As shown in
Figure 3-5, the VRRP group is associated with a link/peer BFD session on the backup so that
the BFD session can rapidly detect communication faults of the VRRP group. When the BFD
session detects a fault, it notifies the VRRP group that the priority of the backup needs to be
increased. Then an active/standby switchover is triggered immediately. This millisecond-level
switchover reduces traffic loss.
After a fault is rectified, the BFD sessions go Up, and the devices in the VRRP group restore
their VRRP status.
NOTE
Figure 3-5 Association between VRRP and link/peer BFD to implement a rapid active/standby
switchover
Internet
VRRP
Master
SwitchA
SwitchB
Backup
BFD packets
HostB
Switch
HostA
Peer BFD
Link1 BFD
Link2 BFD
Procedure
Step 1 Configure a static session or a static BFD session with automatically negotiated discriminators.
For details, see 1.4 Configuring Single-Hop BFD, 1.5 Configuring Multi-Hop BFD, or 1.6
Configuring Static BFD with Automatically Negotiated Discriminators.
Step 2 Run:
system-view
Step 3 Run:
The view of the interface on the backup where a VRRP group is configured is displayed.
Step 4 Run:
58
name } [ peer | link ]
The VRRP group is configured to monitor a link or peer BFD session.
NOTE
l If the VRRP group is bound to an mVRRP group, the mVRRP group maintains the VRRP group status,
and the VRRP group is unable to monitor any BFD sessions.
l In the scenario where the VRRP group is associated with a link BFD session and a peer BFD session,
the backup becomes the master if the backup detects the peer BFD session status change before
detecting the link BFD session status change. The backup transitions from Master to Initialize after it
detects the peer BFD session status change. To prevent the preceding problem, run the min-tx-
interval command in the BFD session view to set the interval at which link BFD control packets to be
smaller than the interval at which peer BFD control packets are sent.
Step 5 (Optional) Run:
vrrp vrid virtual-router-id track link-bfd down-number
The threshold of monitored link BFD sessions that are in the Down state is set.
If the number of monitored link BFD sessions reaches the threshold, an active/standby
switchover is performed.
Step 6 Run:
commit
----End
3.6.3 Configuring Association Between VRRP and the Interface
Status
Context
When the uplink logical interface of the master becomes faulty, VRRP cannot detect the status
change of interfaces not in the VRRP group, causing service interruption. You can associate a
VRRP group with the logical interface status. When the monitored interface is faulty, the priority
of the master is reduced. This triggers an active/standby switchover and reduces the impact of
services on the uplink interface.
When the fault is rectified, the priority of the original master is restored and preempts to be the
master to forward traffic.
NOTE
The master and backup in the VRRP group must work in preemption mode. It is recommended that the
preemption delay be 0 on the backup and non-0 on the master.
Procedure
Step 1 Run:
59
system-view
Step 2 Run:
The view of the interface on the master where a VRRP group is configured is displayed.
Step 3 Run:
vrrp vrid virtual-router-id track interface interface-type interface-number
[ increase value-increased | reduce value-reduced ]
Association between VRRP and the logical interface status is configured.
By default, when the monitored logical interface goes Down, the VRRP priority of the device
decreases by 10.
NOTE
l After the value by which the priority decreases is set, ensure that the priority of the backup is higher
l Only VLANIF interfaces can be monitored.
----End
3.6.4 Configuring Association Between VRRP and BFD to Monitor
the Uplink Status
Context
Because VRRP cannot detect faults on the uplink of a VRRP group, services may be interrupted.
As shown in Figure 3-6, a VRRP group is associated with a BFD session on the master so that
the BFD session monitors the uplink status of the master. When the BFD session detects faults
on the uplink, it notifies the VRRP group that the priority of the master needs to be decreased.
Then an active/standby switchover is triggered immediately. This reduces the impact of uplink
faults on service forwarding.
BFD implements millisecond-level detection. Association between VRRP and BFD provides
fast active/standby switchover.
NOTE
60
Figure 3-6 Association between VRRP and BFD
SwitchA
SwitchB
SwitchC
SwitchD
Internet
VRRP
Master
Backup
BFD packets
HostB
Switch
HostA
SwitchE
Procedure
Step 1 Configure a static BFD session or a static BFD session with automatically negotiated
discriminators. For details, see 1.4 Configuring Single-Hop BFD, 1.5 Configuring Multi-Hop
BFD, and 1.6 Configuring Static BFD with Automatically Negotiated Discriminators.
Step 2 Run:
system-view
Step 3 Run:
Step 4 Run:
name } [ increase value-increased | reduce value-reduced ]
Association between VRRP and BFD is configured.
By default, when the monitored BFD session becomes Down, the VRRP priority decreases by
10.
NOTE
l After the VRRP group is associated with a BFD session, the BFD session type cannot be modified.
Before deleting the BFD session type, you must delete all original configurations.
l After the value by which the priority decreases is set, ensure that the priority of the backup is higher
----End
3.6.5 Configuring Association Between VRRP and Routing to
Monitor the Uplink Status
61
Context
Because VRRP cannot detect faults on the uplink of a VRRP group, services may be interrupted.
The VRRP group monitors the number of routes on the uplink forwarding path. When the route
is withdrawn or becomes inactive, the master' priority is adjusted and an active/standby
switchover is performed. This reduces link faults on service forwarding.
During route association, link switchover depends on convergence of a routing protocol
associated with the VRRP group.
NOTE
l When a VRRP group is associated with a static route, the device can detect only faults on the direct
uplink. To detect faults on an indirect uplink, associate a VRRP group with a dynamic route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
vrrp vrid virtual-router-id track ip route ip-address { mask-address | mask-
length } [ vpn-instance vpn-instance-name ] [ reduce value-reduced ]
Association between a route and a VRRP group is configured.
By default, the master' priority decreases by 10 if the associated route is withdrawn or becomes
inactive.
NOTE
After the value by which the priority decreases is set, ensure that the priority of the backup is higher than
the priority of the master.
----End
3.6.6 Configuring Association Between a VRRP Group and a Direct
Route
Context
To improve network reliability, a VRRP group is often used as the gateway for users to access
external networks. Uplink traffic passes the master, but downlink traffic is often transmitted
through a route of a dynamic routing protocol. In this case, uplink and downlink traffic may be
transmitted along different paths. If the firewall is configured for the VRRP group to improve
62
security, the firewall blocks traffic that is sent and received along different paths. In addition, it
is difficult to monitor such traffic and collect traffic statistics.
You can associate a VRRP group with a direct route so that VRRP affects route selection of a
dynamic routing protocol. Association ensures that uplink traffic and downlink traffic are
transmitted along the same path.
Before configuring association between a VRRP group and a direct route, complete the following
tasks:
l Configuring basic VRRP functions and creating a VRRP group
l Configuring a dynamic routing protocol to make IP routes of nodes reachable.
NOTE
After association between a VRRP group and a direct route is configured, an IGP protocol cannot run on the
interface running VRRP. If an IGP protocol runs on the interface, the IGP protocol cannot retain the original
cost of the imported direct route. As a result, the VRRP group cannot be associated with the direct route.
Procedure
l Configuring association between a direct route and a VRRP group
1. Run:
system-view
2. Run:
interface interface-type interface-name
The view of the VRRP-enabled interface is displayed.
3. Run:
direct-route track vrrp vrid virtual-router-id degrade-cost cost-value
Association between a direct route and a VRRP group is configured.
Association between the VRRP group and the direct route allows the cost of the direct
route to be adjusted based on the VRRP group status.
When the VRRP group is in Master state, the cost is set to the default value 0
(highest priority).
When the VRRP group is in Backup state, the cost is specified by cost-value (larger
than the default value 0).
NOTE
A direct route on the network segment that an interface belongs to can be associated with only
one VRRP group. To associate a direct route that has been associated with one VRRP group
to another VRRP group, you must delete the original association configuration.
4. Run:
commit
5. Run:
quit
l Configuring a dynamic routing protocol to import the direct route
63
IGP protocols and BGP are mainly used. RIP does not retain the original cost of the imported
route, so OSPF, IS-IS, and BGP are used here.
Configuring OSPF to import the direct route
1. Run:
system-view
2. Run:
ospf [ process-id ]
The OSPF process view is displayed.
3. Run:
import-route direct
OSPF is configured to import the direct route.
4. Run:
default cost inherit-metric
OSPF is configured to retain the original cost of the imported route.
NOTE
l The default command has the lowest priority. When running the default command, ensure
that the apply cost command for the direct route is not executed. Otherwise, the default
command does not take effect.
l After the default cost inherit-metric command is used, the default cost cost-value
command that is executed later will overwrite the default cost inherit-metric command.
5. Run:
commit
Configuring IS-IS to import the direct route
1. Run:
system-view
2. Run:
isis [ process-id ]
The IS-IS process view is displayed.
3. Run:
import-route direct inherit-cost
IS-IS is configured to retain the original cost of the imported route.
4. Run:
commit
Configuring BGP to import the direct route
1. Run:
system-view
2. Run:
bgp as-number
64
The BGP process view is displayed.
3. Run:
import-route direct
BGP is configured to import the direct route.
BGP retains the original cost of the imported route in the MED.
4. Run:
commit
----End
Procedure
l Run the display vrrp [ admin-vrrp | [ interface interface-type interface-number [ virtual-
router-id ] | virtual-router-id ] [ verbose ] ] command to check the VRRP group status and
parameters.
statistics command to check statistics about sent and received packets of a VRRP group.
----End
3.7 Maintaining VRRP
This section describes how to maintain VRRP, including monitoring the VRRP running status
and clearing VRRP packet statistics.
3.7.1 Monitoring the VRRP Running Status
Context
During routine maintenance, you can run the following command to view VRRP packet statistics
and monitor the VRRP running status.
Procedure
statistics command in any view to view statistics about sent and received packets of a
VRRP group.
3.7.2 Clearing VRRP Packet Statistics
Context
Before recollecting statistics about VRRP packets in a period of time, clear existing statistics.
65
CAUTION
The cleared statistics cannot be restored. Exercise caution when you run the reset command.
Procedure
l Run the reset vrrp [ interface interface-type interface-number ] [ vrid virtual-router-id ]
statistics command in the user view to clear statistics about a VRRP group.
This section provides several configuration examples of VRRP.
3.8.1 Example for Configuring a VRRP Group in Active/Standby
Mode
As shown in Figure 3-7, HostA is dual-homed to SwitchA and SwitchB through the switch. The
requirements are as follows:
l The host uses SwitchA as the default gateway to connect to the Internet. When SwitchA
becomes faulty, SwitchB functions as the gateway. This implements gateway backup.
l After SwitchA recovers, it becomes the gateway.
Figure 3-7 Networking diagram for configuring a VRRP group
SwitchB
Backup
10GE1/0/2
10.1.1.2/24
10GE1/0/1
192.168.2.1/24
10GE1/0/2
192.168.2.2/24
10GE1/0/3
20.1.1.100/24
SwitchC
10GE1/0/1
192.168.1.2/24
10GE1/0/1
192.168.1.1/24
SwitchA
Master
10GE1/0/2
10.1.1.1/24
VRRP VRID 1
Virtual IP Address:
10.1.1.111
HostA
10.1.1.100/24
Internet
Switch
GE1/0/0
GE2/0/0
Device Interface VLANIF Interface IP Address
SwitchA 10GE1/0/1 VLANIF 300 192.168.1.1/24
66
10GE1/0/2 VLANIF 100 10.1.1.1/24
SwitchB 10GE1/0/1 VLANIF 200 192.168.2.1/24
10GE1/0/2 VLANIF 100 10.1.1.2/24
SwitchC 10GE1/0/1 VLANIF 300 192.168.1.2/24
10GE1/0/2 VLANIF 200 192.168.2.2/24
10GE1/0/3 VLANIF 400 20.1.1.100/24

1. Assign an IP address to each interface and configure a routing protocol to ensure network
connectivity.
2. Configure a VRRP group on SwitchA and SwitchB, set a higher priority for SwitchA so
that SwitchA functions as the master to forward traffic and set the preemption delay to 20s
on SwitchA, and set a lower priority for SwitchB so that SwitchB functions as the backup.
Procedure
Step 1 Configure devices to ensure network connectivity.
# Assign an IP address to each interface. SwitchA is used as an example. The configurations of
SwitchB and SwitchC are similar to the configuration of SwitchA, and are not mentioned here.
[~HUAWEI] commit
[~SwitchA] vlan batch 100 300
[~SwitchA-10GE1/0/1] port link-type trunk
[~SwitchA-10GE1/0/1] port trunk allow-pass vlan 300
[~SwitchA-10GE1/0/2] port trunk pvid vlan 100
[~SwitchA-10GE1/0/2] undo port trunk allow-pass vlan 1
[~SwitchA] interface vlanif 100
[~SwitchA-Vlanif100] ip address 10.1.1.1 24
[~SwitchA-Vlanif100] quit
[~SwitchA] commit
# Configure OSPF between SwitchA, SwitchB, and SwitchC. SwitchA is used as an example.
The configurations of SwitchB and SwitchC are similar to the configuration of SwitchA, and
are not mentioned here.
[~SwitchA] ospf 1
[~SwitchA-ospf-1] area 0
[~SwitchA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
67
[~SwitchA-ospf-1-area-0.0.0.0] commit
[~SwitchA-ospf-1-area-0.0.0.0] quit
[~SwitchA-ospf-1] quit
Step 2 Configure VRRP groups.
# Configure VRRP group 1 on SwitchA, and set the priority of SwitchA to 120 and the
preemption delay to 20s.
[~SwitchA-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
[~SwitchA-Vlanif100] vrrp vrid 1 priority 120
[~SwitchA-Vlanif100] vrrp vrid 1 preempt timer delay 20
[~SwitchA-Vlanif100] commit
# Configure VRRP group 1 on SwitchB. SwitchB uses default value 100.
[~SwitchB] interface vlanif 100
[~SwitchB-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
[~SwitchB-Vlanif100] commit
[~SwitchB-Vlanif100] quit
# After the configuration is complete, run the display vrrp command on SwitchA and
SwitchB. You can see that SwitchA is in Master state and SwitchB is in Backup state.
<SwitchA> display vrrp verbose
Vlanif100 | Virtual Router 1
State : Master
Virtual IP : 10.1.1.111
Master IP : 10.1.1.1
PriorityRun : 120
PriorityConfig : 120
MasterPriority : 120
Preempt : YES Delay Time : 20 s Remain : --
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Config type : normal-vrrp
Create time : 2012-05-11 11:39:18
Last change time : 2012-05-26 11:38:58
<SwitchB> display vrrp verbose
State : Backup
Virtual IP : 10.1.1.111
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-11 11:39:18
Last change time : 2012-05-26 11:38:58
# Run the display ip routing-table command on SwitchA and SwitchB. The command output
shows that a direct route to the virtual IP address exists in the routing table of SwitchA and an
OSPF route to the virtual IP address exists in the routing table of SwitchB. The command output
on SwitchA and SwitchB is as follows:
68
<SwitchA> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 10 Routes : 10

Destination/Mask Proto Pre Cost Flags NextHop Interface

10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif100
10.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
20.1.1.0/24 OSPF 10 2 D 192.168.1.2 Vlanif300
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif300
192.168.1.2/32 Direct 0 0 D 192.168.1.2 Vlanif300
192.168.2.0/24 OSPF 10 2 D 10.1.1.2 Vlanif100
<SwitchB> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public

10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif100
10.1.1.111/32 OSPF 10 2 D 10.1.1.1 Vlanif100
20.1.1.0/24 OSPF 10 2 D 192.168.2.2 Vlanif200
192.168.1.0/24 OSPF 10 2 D 10.1.1.1 Vlanif100
192.168.2.0/24 Direct 0 0 D 192.168.2.1 Vlanif200
192.168.2.2/32 Direct 0 0 D 192.168.2.2 Vlanif200
# Run the shutdown command on 10GE1/0/2 of SwitchA to simulate a link fault.
Run the display vrrp command on SwitchB to view the VRRP status. The command output
shows that SwitchB is in Master state.
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-11 11:39:18
Last change time : 2012-05-26 11:38:58
# Run the undo shutdown command on 10GE1/0/2 of SwitchA. After 20s, run the display
vrrp command on SwitchA to view the VRRP status. SwitchA restores to be in Master state.
[~SwitchA-10GE1/0/2] undo shutdown
69
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-11 11:39:18
Last change time : 2012-05-26 11:38:58
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 300
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.1.111
vrrp vrid 1 priority 120
vrrp vrid 1 preempt timer delay 20
#
interface Vlanif200
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
port trunk pvid vlan 100
undo port trunk allow-pass vlan 1
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
#
interface 10GE1/0/1
70
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 200 300 400
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif300
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif400
ip address 20.1.1.100 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
3.8.2 Example for Configuring a VRRP Group in Multi-gateway
Load Balancing Mode
As shown in Figure 3-8, HostA and HostC are dual-homed to SwitchA and SwitchB through
the switch. Load balancing is required in this scenario. HostA uses SwitchA as the default
gateway to connect to the Internet, and SwitchB functions as the backup gateway. HostC uses
SwitchB as the default gateway to connect to the Internet, and SwitchA functions as the backup
gateway.
71
Figure 3-8 Networking diagram for configuring VRRP in multi-gateway load balancing mode
SwitchB
VRID 1:Backup
VRID 2:Master
VRRP VRID 2
Virtual IP Address:
10.1.1.112
SwitchA
VRID 1:Master
VRID 2:Backup
10GE1/0/2
10.1.1.2/24
10GE1/0/1
192.168.2.1/24
10GE1/0/2
192.168.2.2/24
10GE1/0/3
20.1.1.100/24
SwitchC
10GE1/0/1
192.168.1.2/24
10GE1/0/2
10.1.1.1/24
VRRP VRID 1
Virtual IP Address:
10.1.1.111
Internet
HostC
10.1.1.101/24
HostA
10.1.1.100/24
GE1/0/0
GE2/0/0
Switch
10GE1/0/1
192.168.1.1/24
10GE1/0/2 VLANIF 100 10.1.1.1/24
10GE1/0/2 VLANIF 100 10.1.1.2/24
10GE1/0/2 VLANIF 200 192.168.2.2/24
10GE1/0/3 VLANIF 400 20.1.1.100/24

connectivity.
2. Create VRRP groups 1 and 2 on SwitchA and SwitchB. In VRRP group 1, configure
SwitchA as the master and SwitchB as the backup. In VRRP group 2, configure SwitchB
as the master and SwitchA as the backup.
Procedure
72
[~HUAWEI] commit
[~SwitchA] commit
[~SwitchA] ospf 1
# Configure VRRP group 1 on SwitchA and SwitchB, set the priority of SwitchA to 120 and the
preemption delay to 20s, and set the default priority for SwitchB.
# Configure VRRP group 2 on SwitchA and SwitchB, set the priority of SwitchB to 120 and the
preemption delay to 20s, and set the default priority for SwitchA.
[~SwitchB-Vlanif100] vrrp vrid 2 priority 120
[~SwitchB-Vlanif100] vrrp vrid 2 preempt timer delay 20
73
# After the configuration is complete, run the display vrrp command on SwitchA. You can see
that SwitchA is the master in VRRP group 1 and the backup in VRRP group 2.
<SwitchA> dislpay vrrp verbose
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-11 11:39:18
Last change time : 2012-05-26 11:38:58
State : Backup
Virtual IP : 10.1.1.112
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0102
Check TTL : YES
Create time : 2012-05-11 11:40:18
Last change time : 2012-05-26 11:48:58
# After the configuration is complete, run the display vrrp command on SwitchB. You can see
that SwitchB is the backup in VRRP group 1 and the master in VRRP group 2.
State : Backup
Virtual IP : 10.1.1.111
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-11 11:39:18
Last change time : 2012-05-26 11:38:58
State : Master
Virtual IP : 10.1.1.112
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0102
74
Check TTL : YES
Create time : 2012-05-11 11:40:18
Last change time : 2012-05-26 11:48:58
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 300
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif200
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
75
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif300
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif400
ip address 20.1.1.100 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
3.8.3 Example for Configuring a VRRP Group in Single-gateway
Load Balancing Mode
As shown in Figure 3-9, HostA and HostC are dual-homed to SwitchA and SwitchB. Some
users want to use SwitchA to forward data traffic and use fSwitchB as the backup. Other users
want to use SwitchB to forward data traffic and use SwitchA as the backup. SwitchA and
SwitchB used as masters in different VRRP groups can back up each other and load balance
data traffic.
76
Figure 3-9 Network diagram for VRRP groups working in single-gateway load balancing mode
SwitchB
Load-Balance VRRP VRID 1:Backup
Member VRRP VRID 2:Master
VRRP VRID 2
Load-Balance VRRP VRID 1:Master
Member VRRP VRID 2:Backup
SwitchA
10GE1/0/2
10.1.1.2/24
10GE1/0/1
192.168.2.1/24
10GE1/0/2
192.168.2.2/24
10GE1/0/3
20.1.1.100/24
SwitchC
10GE1/0/1
192.168.1.2/24
10GE1/0/2
10.1.1.1/24
VRRP VRID 1
Virtual IP Address:
10.1.1.111
Internet
HostC
10.1.1.101/24
HostA
10.1.1.100/24
GE1/0/0
GE2/0/0
Switch
10GE1/0/1
192.168.1.1/24
10GE1/0/2 VLANIF 100 10.1.1.1/24
10GE1/0/2 VLANIF 100 10.1.1.2/24
10GE1/0/2 VLANIF 200 192.168.2.2/24
10GE1/0/3 VLANIF 400 20.1.1.100/24

connectivity.
2. Configure two VRRP groups on SwitchA and SwitchB. SwitchA is configured as the master
in VRRP group 1. SwitchB is configured as the master in VRRP group 2. They can load
balance traffic.
Procedure
77
[~HUAWEI] commit
[~SwitchA] commit
[~SwitchA] ospf 1
# Create VRRP groups 1 and 2 on VLANIF100 of SwitchA, set the priority to 120 for
SwitchA in VRRP group 1 so that SwitchA serves as the master in VRRP group 1, and set the
priority to 100 for SwitchA in VRRP group 2 so that SwitchA serves as the backup in VRRP
group 2.
<SwitchA> system-view
[~SwitchA-Vlanif100] vrrp vrid 2
# On VLANIF100 of SwitchA, configure VRRP group 1 as a load-balance redundancy group
(LBRG) and add VRRP group 2 to the LBRG.
[~SwitchA-Vlanif100] vrrp vrid 1 load-balance
[~SwitchA-Vlanif100] vrrp vrid 2 join load-balance-vrrp vrid 1
# Create VRRP groups 1 and 2 on VLANIF100 of SwitchB in VRRP group 2 so that SwitchB
serves as the master in VRRP group 2 and as the backup in VRRP group 1.
<SwitchB> system-view
[~SwitchB-Vlanif100] vrrp vrid 2
[~SwitchB-Vlanif100] vrrp vrid 2 priority 120
# On VLANIF100 of SwitchB, configure VRRP group 1 as an LBRG and add VRRP group 2
to the LBRG.
[~SwitchB-Vlanif100] vrrp vrid 1 load-balance
[~SwitchB-Vlanif100] vrrp vrid 2 join load-balance-vrrp vrid 1
78
Run the display vrrp command on SwitchA. The command output shows that SwitchA serves
as the master device in the LBRG and as a backup device in the LBRG member group.
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
Preempt : YES Delay Time : 0s
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Config Type : lb-vrrp
Create Time : 2012-10-19 03:29:46
Last Change Time : 2012-10-19 03:29:51
State : Backup
Virtual IP : 0.0.0.0
PriorityRun : 100
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual MAC : 0000-5e00-0102
Check TTL : YES
Config Type : lb-member-vrrp
Create Time : 2012-10-19 03:30:17
Last Change Time : 2012-10-19 03:33:05

Run the display vrrp command on SwitchB. The command output shows that SwitchB serves
as a backup device in the LBRG and as the master device in the LBRG member group.
State : Backup
Virtual IP : 10.1.1.111
PriorityRun : 100
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Config Type : lb-vrrp
Create Time : 2012-10-19 03:32:29
Last Change Time : 2012-10-19 03:32:31
State : Master
79
PriorityRun : 120
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual MAC : 0000-5e00-0102
Check TTL : YES
Config Type : lb-member-vrrp
Create Time : 2012-10-19 03:32:51
Last Change Time : 2012-10-19 03:33:04

Run the display vrrp load-balance command on Switch A. The command output shows
information about the LBRG and its member group on Switch A.
<SwitchA> display vrrp load-balance member-vrrp
Interface: Vlanif100, load-balance-vrrp vrid: 1, state: Master
Member-vrrp number: 1
Member-vrrp vrid: 2, state: Backup
Run the display vrrp load-balance command on Switch B. The command output shows
information about the LBRG and its member group on Switch B.
<SwitchB> display vrrp load-balance member-vrrp
Interface: Vlanif100, load-balance-vrrp vrid: 1, state: Backup
Member-vrrp number: 1
Member-vrrp vrid: 2, state: Master
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 300
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 load-balance
vrrp vrid 2
vrrp vrid 2 join load-balance-vrrp vrid 1
#
interface VLANIF300
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
80
#
sysname SwitchB
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
vrrp vrid 1 load-balance
vrrp vrid 2
vrrp vrid 2 join load-balance-vrrp vrid 1
#
interface VLANIF200
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
#
interface VLANIF200
ip address 192.168.2.2 255.255.255.0
#
interface VLANIF300
ip address 192.168.1.2 255.255.255.0
#
interface VLANIF400
ip address 20.1.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
81
3.8.4 Example for Connecting VRRP Groups to L3VPNs
IT technologies such as enterprise resource planning, voice over IP (VoIP), video conferencing,
and online training provide a framework for office automation and information access in
enterprises. As network economy develops, enterprises have growing networks and partners,
and employees are often on business trips. A carrier network is required to help an enterprise
connect its headquarters and branches and provide convenient access services for the staff on
business trips.VPN technology was developed and used over an IP network to meet this
requirement.
To improve VPN reliability, VPN interfaces can be added to different VRRP groups.
In Figure 3-10, there are two VPNs: VPN RED and VPN BLUE. It is required that users in
different VPNs communicate with each other and reliability on the L3VPN be ensured.
Figure 3-10 Networking diagram for connecting VRRP groups to L3VPNs
Loopback1
Backup group1
Loopback1
Loopback1
Loopback1
VPN BLUE
VPN RED
GE1/0/0
CE-A
10GE1/0/1
1
0
G
E
1
/
0
/
2
10GE1/0/3
10GE1/0/3
10GE1/0/2
GE1/0/0
CE-D
PE-C
10GE1/0/3
10GE1/0/1
1
0
G
E
1
/
0
/
2
10GE1/0/3
10GE1/0/2
1
0
G
E
1
/
0
/
1
GE1/0/0
CE-B
VPN BLUE
Public
Network
for VPN BLUE
PE-B
PE-A
Backup group2
for VPN RED
Branch of
company B
Branch of
company A
10GE1/0/1
GE1/0/0 CE-C
VPN RED
Headquarters
of company A
P
Headquarters
of company B
Table 3-4 Configuration data
Device Interface VLANIF
Interface
IP Address VPN Instance
P 10GE1/0/1 VLANIF 300 192.168.1.2/24 -
82
Device Interface VLANIF
Interface
IP Address VPN Instance
10GE1/0/2 VLANIF 400 192.168.2.2/24 -
10GE1/0/3 VLANIF 500 192.168.3.2/24 -
Loopback1 - 4.4.4.4/32 -
PE-A 10GE1/0/1 VLANIF 100 10.1.1.1/24 VPN-BLUE
10GE1/0/2 VLANIF 200 20.1.1.1/24 VPN-RED
10GE1/0/3 VLANIF 300 192.168.1.1/24 -
Loopback1 - 1.1.1.1/32 -
PE-B 10GE1/0/1 VLANIF 100 10.1.1.2/24 VPN-BLUE
10GE1/0/2 VLANIF 200 20.1.1.2/24 VPN-RED
10GE1/0/3 VLANIF 400 192.168.2.1/24 -
Loopback1 - 2.2.2.2/32 -
PE-C 10GE1/0/1 VLANIF 500 20.2.1.1/24 VPN-RED
10GE1/0/2 VLANIF 600 10.2.1.1/24 VPN-BLUE
10GE1/0/3 VLANIF 700 192.168.3.1/24 -
Loopback1 - 3.3.3.3/32 -
CE-A GE1/0/0 - 10.1.1.100/24 -
CE-B GE1/0/0 - 20.1.1.100/24 -
CE-C GE1/0/0 - 20.2.1.100/24 -
CE-D GE1/0/0 - 10.2.1.100/24 -

VRRP groups 1 and 2 are configured on PE-A and PE-B to improve L3VPN reliability.
Procedure
Step 1 Configure OSPF between PEs and between PEs and P to implement interworking of the
backbone network. The configuration details are not mentioned here.
Step 2 On the MPLS backbone network, configure basic MPLS functions and MPLS LDP and establish
LDP LSPs. The configuration details are not mentioned here.
Step 3 Configure VPN instances on each PE and connect CEs to the PEs. The configuration details are
not mentioned here.
83
Step 4 Establish MP-IBGP peer relationships between PEs. The configuration details are not mentioned
here.
Step 5 Configure default routes on CE-A and CE-B. The configuration details are not mentioned here.
For configurations of steps 1 to 5, see "BGP MPLS IP VPN Configuration" in Configuration
Guide - VPN. You can also see configuration files in this example.
Step 6 Configure two VRRP groups on PE-A and PE-B.
# Create VRRP group 1 and set the VRRP priority to 120 on PE-A so that PE-A is the master.
<PE-A> system-view
[~PE-A] interface vlanif 100
[~PE-A-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
[~PE-A-Vlanif100] vrrp vrid 1 priority 120
[~PE-A-Vlanif100] commit
[~PE-A-Vlanif100] quit
# Create VRRP group 2 on PE-A and configure PE-A to use the default priority.
[~PE-A] interface vlanif 200
[~PE-A-Vlanif200] vrrp vrid 2 virtual-ip 20.1.1.111
[~PE-A-Vlanif200] commit
[~PE-A-Vlanif200] quit
# Create VRRP group 1 on PE-B and configure PE-B to use the default priority.
<PE-B> system-view
[~PE-B] interface vlanif 100
[~PE-B-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
[~PE-B-Vlanif100] commit
[~PE-B-Vlanif100] quit
# Create VRRP group 2 and set the VRRP priority to 120 on PE-B so that PE-B is the master in
VRRP group 2.
[~PE-B] interface vlanif 200
[~PE-B-Vlanif200] vrrp vrid 2 virtual-ip 20.1.1.111
[~PE-B-Vlanif200] vrrp vrid 2 priority 120
[~PE-B-Vlanif200] commit
[~PE-B-Vlanif200] quit
# Run the display ip routing-table vpn-instance vpn-instance-name command on PE-A and
PE-B. The command output shows that a route to the virtual IP address exists in the routing table
on PE-A but not on PE-B. The routing table on PE-A is displayed.
<PE-A> display ip routing-table vpn-instance VPN-BLUE
Route Flags: R - relay, D - download for forwarding
------------------------------------------------------------------------------
Routing Table : VPN-BLUE
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif100
10.1.1.1/32 Direct 0 0 D 10.1.1.1 Vlanif100
10.1.1.111/32 Direct 0 0 D 127.0.0.1 Vlanif100
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif100
# Run the ping command on PE-A and PE-B to ping a specified VPN instance. The ping is
successful on each PE.
84
<PE-A> ping -vpn-instance VPN-BLUE 10.1.1.111
The virtual IP address 10.1.1.111 can be pinged.
----End
Configuration Files
l Configuration file of PE-A
#
sysname PE-A
#
#
ip vpn-instance VPN-BLUE
route-distinguisher 100:1
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
#
ip vpn-instance VPN-RED
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
interface Vlanif100
undo shutdown ip binding vpn-instance VPN-BLUE
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif200
undo shutdown ip binding vpn-instance VPN-RED
ip address 20.1.1.1 255.255.255.0
#
interface Vlanif300
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
bgp 100
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.3 enable
85
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
#
ipv4-family vpn-instance VPN-BLUE
import-route direct
import-route static
#
ipv4-family vpn-instance VPN-RED
import-route direct
import-route static
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
ip route-static vpn-instance VPN-BLUE 0.0.0.0 0.0.0.0 10.1.1.100
ip route-static vpn-instance VPN-RED 0.0.0.0 0.0.0.0 20.1.1.100
return
l Configuration file of PE-B
#
sysname PE-B
#
#
ip vpn-instance VPN-BLUE
#
ip vpn-instance VPN-RED
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
interface Vlanif100
undo shutdown ip binding vpn-instance VPN-BLUE
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
undo shutdown ip binding vpn-instance VPN-RED
ip address 20.1.1.2 255.255.255.0
#
interface Vlanif400
undo shutdown
ip address 192.168.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface 10GE1/0/1
#
interface 10GE1/0/2
86
#
interface 10GE1/0/3
#
bgp 100
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
#
ipv4-family vpn-instance VPN-BLUE
import-route direct import-route static
#
ipv4-family vpn-instance VPN-RED
import-route direct import-route static
#
ospf 1 area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
ip route-static vpn-instance VPN-BLUE
0.0.0.0 0.0.0.0 10.1.1.100
ip route-static vpn-instance VPN-RED
0.0.0.0 0.0.0.0 20.1.1.100
return
3.8.5 Example for Configuring Association Between VRRP and BFD
to Implement a Rapid Active/Standby Switchover
As shown in Figure 3-11, hosts on a LAN are dual-homed to SwitchA and SwitchB through the
switch. A VRRP group is established on SwitchA and SwitchB, and SwitchA is the master.
When SwitchA or the link between SwitchA and the switch is faulty, the switchover period is
within 1s. This reduces the impact of the fault on service transmission.
Figure 3-11 Networking diagram for configuring association between VRRP and BFD to
implement a rapid active/standby switchover
87
SwitchB
Backup
Internet
VRRP VRID 1
Virtual IP Address:
10.1.1.3/24
Master
SwitchA
HostB
Switch
HostA
GE1/0/0
GE2/0/0
10GE1/0/1
VLANIF100
10.1.1.2/24
10GE1/0/1
VLANIF100
10.1.1.1/24
BFD packets
connectivity.
2. Configure a VRRP group on SwitchA and SwitchB. SwitchA functions as the master, its
priority is 120, and the preemption delay is 20s. SwitchB functions as the backup and uses
the default priority.
3. Configure a static BFD session on SwitchA and SwitchB to monitor the link of the VRRP
group.
4. Association between VRRP and BFD is configured on SwitchB. When the link is faulty,
an active/standby switchover can be performed rapidly.
Procedure
[~HUAWEI] commit
[~SwitchA] vlan 100
[~SwitchA] commit
88
Step 3 Configure a static BFD session.
# Create a BFD session on SwitchA.
[~SwitchA] bfd
[~SwitchA-bfd] quit
[~SwitchA] bfd atob bind peer-ip 10.1.1.2 interface vlanif 100
[~SwitchA-bfd-session-atob] min-rx-interval 50
[~SwitchA-bfd-session-atob] min-tx-interval 50
# Create a BFD session on SwitchB.
[~SwitchB] bfd
[~SwitchB-bfd] quit
[~SwitchB] bfd btoa bind peer-ip 10.1.1.1 interface vlanif 100
[~SwitchB-bfd-session-btoa] discriminator local 2
[~SwitchB-bfd-session-btoa] discriminator remote 1
[~SwitchB-bfd-session-btoa] min-rx-interval 50
[~SwitchB-bfd-session-btoa] min-tx-interval 50
[~SwitchB-bfd-session-btoa] commit
[~SwitchB-bfd-session-btoa] quit
Run the display bfd session command on SwitchA and SwitchB. You can see that the BFD
session is Up. The display on Switch A is used as an example.
<SwitchA> display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
1 2 10.1.1.2 Up S_IP_IF Vlanif100
--------------------------------------------------------------------------------
Step 4 Associate BFD with VRPP.
# Configure association between VRRP and BFD on SwitchB. When the BFD session becomes
Down, the priority of SwitchB increases by 40.
[~SwitchB-Vlanif100] vrrp vrid 1 track bfd 2 increase 40
# After the configuration is complete, run the display vrrp command on SwitchA and SwitchB.
SwitchA is the master, SwitchB is the backup, and the associated BFD session is in Up state.
State : Master
89
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:32:56
Last change time : 2012-05-22 17:33:00
<SwitchB>display vrrp verbose
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Track BFD : 2 Priority increased : 40
BFD-Session State: UP
Create time : 2012-05-22 17:33:00
Last change time : 2012-05-22 17:33:04
# Run the shutdown command on 10GE1/0/1 of SwitchA to simulate a link fault. Then run the
display vrrp command on SwitchA and SwitchB. You can see that SwitchA is in Initialize state,
SwitchB becomes the master, and the associated BFD session becomes Down.
State : Initialize
Master IP : 0.0.0.0
PriorityRun : 120
MasterPriority : 0
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:32:56
Last change time : 2012-05-22 17:33:06
State : Master
PriorityRun : 140
90
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
BFD-Session State: DOWN
Create time : 2012-05-22 17:33:00
Last change time : 2012-05-22 17:33:06
# Run the undo shutdown command on 10GE1/0/1 of SwitchA. After 20s, run the display
vrrp command on SwitchA and SwitchB. You can see that SwitchA restores to be the master,
SwitchB restores to be the backup, and the associated BFD session is in Up state.
[~SwitchA-10GE1/0/1] undo shutdown
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:32:56
Last change time : 2012-05-22 17:33:50
<SwitchB>display vrrp verbose
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
BFD-Session State: UP
Create time : 2012-05-22 17:33:00
Last change time : 2012-05-22 17:33:50
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
#
bfd
91
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
#
interface 10GE1/0/1
#
bfd atob bind peer-ip 10.1.1.2 interface Vlanif100
min-tx-interval 50
min-rx-interval 50
commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100
#
bfd
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
vrrp vrid 1 track bfd 2 increase 40
#
interface 10GE1/0/1
#
bfd btoa bind peer-ip 10.1.1.1 interface Vlanif100
min-tx-interval 50
min-rx-interval 50
commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
3.8.6 Example for Configuring Association Between VRRP and the
logical Interface Status
92
When VLANIF 300 on SwitchA becomes faulty, the VRRP group can immediately detect the
fault and an active/standby switchover is performed. SwitchB then continues to forward services.
This reduces the impact of the fault on service transmission.
Figure 3-12 Network diagram for configuring association between VRRP and the interface
status
SwitchB
Backup
Internet
VRRP VRID 1
Virtual IP Address:
10.1.1.3/24
Master
SwitchA
HostB
Switch
HostA
GE1/0/0
GE2/0/0
10GE1/0/2
10.1.1.2/24
10GE1/0/2
10.1.1.1/24
10GE1/0/1
192.168.1.1/24
10GE1/0/2
192.168.2.2/24
10GE1/0/1
192.168.2.1/24
10GE1/0/1
192.168.1.2/24
SwitchC
10GE1/0/2 VLANIF 100 10.1.1.1/24
10GE1/0/2 VLANIF 100 10.1.1.2/24
10GE1/0/2 VLANIF 200 192.168.2.2/24

connectivity.
that SwitchA functions as the master to forward traffic, and set a lower priority for
switchB so that switchB functions as the backup.
3. Configure association between VRRP and the interface status on SwitchA to monitor
VLANIF 300. When the link between SwitchA and SwitchC becomes faulty, the VRRP
group can immediately detect the fault and an active/standby switchover is performed.
93
Procedure
[~HUAWEI] commit
[~SwitchA] commit
[~SwitchA] ospf 1
Step 3 Configure association between VRRP and the interface status.
# Configure association between VRRP and the interface status on SwitchA. When VLANIF
100 becomes Down, the priority of SwitchA decreases by 40.
[~SwitchA-Vlanif100] vrrp vrid 1 track interface vlanif 300 reduce 40
94
SwitchA is the master, SwitchB is the backup, and the associated interface is in Up state.
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Track IF : VLANIF300 Priority reduced : 40
IF state : UP
Create time : 2012-05-22 17:32:56
Last change time : 2012-05-22 17:33:00
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:33:00
Last change time : 2012-05-22 17:33:04
# Run the shutdown command on 10GE1/0/1 of SwitchA to simulate a link fault. Run the
display vrrp command on SwitchA and SwitchB. You can see that SwitchA switches to the
Backup state, SwitchB switches to the Master state, and the associated interface is in Down state.
[~SwitchA-Vlanif300] shutdown
State : Backup
PriorityRun : 80
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
95
IF state : DOWN
Create time : 2012-05-22 17:33:56
Last change time : 2012-05-22 17:34:00
State : Master
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:34:00
Last change time : 2012-05-22 17:34:04
# Run the undo shutdown command on 10GE1/0/1 of SwitchA. Run the display vrrp command
on SwitchA and SwitchB. After 20s, you can see that SwitchA restores to be the master,
SwitchB restores to be the backup, and the associated interface is in Up state.
[~SwitchA-Vlanif300] undo shutdown
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
IF state : UP
Create time : 2012-05-22 17:34:56
Last change time : 2012-05-22 17:35:00
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:35:00
Last change time : 2012-05-22 17:35:04
----End
96
Configuration Files
#
sysname SwitchA
#
vlan batch 100 300
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 track interface Vlanif300 reduce 40
#
interface Vlanif200
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
97
vlan batch 200 300
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif300
ip address 192.168.1.2 255.255.255.0
#
interface 10GE1/0/1
port hybrid pvid vlan 300
port hybrid untagged vlan 300
#
interface 10GE1/0/2
port hybrid pvid vlan 200
port hybrid untagged vlan 200
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
3.8.7 Example for Configuring Association Between VRRP and BFD
to Monitor the Uplink Status
Generally, SwitchA functions as the gateway and user traffic is along the path Switch ->
SwitchA -> SwitchC -> SwitchE.
When the link between SwitchC and SwitchE is faulty, the VRRP group can detect the fault
within 1s and an active/standby switchover is performed rapidly. Then SwitchB forwards
services, so the impact of the link fault on service transmission is reduced.
Figure 3-13 Association between VRRP and BFD to monitor the uplink status
HostA
SwitchA
SwitchB
SwitchC
SwitchD
Internet
10GE1/0/2
192.168.1.1/24
VRRP VRID 1
Virtual IP Address:
10.1.1.10
10GE1/0/1
10.1.1.1/24
10GE1/0/1
10.1.1.2/24
10GE1/0/1
192.168.1.2/24
10GE1/0/2
20.1.1.1/24
Switch
10GE1/0/2
192.168.2.1/24
10GE1/0/1
192.168.2.2/24
Master
Backup
10GE1/0/2
30.1.1.1/24
10GE1/0/2
30.1.1.2/24
10GE1/0/1
20.1.1.2/24
GE1/0/0
GE2/0/0
SwitchE
BFD packets
98
10GE1/0/2 VLANIF 300 192.168.1.1/24
10GE1/0/2 VLANIF 200 192.168.2.1/24
10GE1/0/2 VLANIF 500 20.1.1.1/24
SwitchD 10GE1/0/1 VLANIF 200 192.168.2.2/24
10GE1/0/2 VLANIF 400 30.1.1.1/24
SwitchE 10GE1/0/1 VLANIF 500 20.1.1.2/24
10GE1/0/2 VLANIF 400 30.1.1.2/24

connectivity.
2. Configure a VRRP group on SwitchA and SwitchB. Set the priority of SwitchA to 120 and
the preemption delay to 20s so that SwitchA functions as the master. Configure SwitchB
to use the default priority so that SwitchB functions as the backup.
3. Configure a static BFD session on SwitchA and SwitchE to monitor the link between
SwitchA and SwitchE.
4. Configure association between VRRP and BFD on SwitchA. When the link is faulty, an
active/standby switchover can be performed rapidly.
Procedure
other devices are similar to the configuration of switchA, and are not mentioned here.
[~HUAWEI] commit
99
[~SwitchA] commit
# Configure OSPF between Switchs. SwitchA is used as an example. The configurations of other
Switchs are similar to the configuration of SwitchA, and are not mentioned here.
[~SwitchA] ospf 1
# Configure VRRP group 1 on SwitchB. SwitchB uses default priority 100.
Step 3 Configure a static BFD session.
# Create a BFD session on SwitchA.
[~SwitchA] bfd
[~SwitchA-bfd] quit
[~SwitchA] bfd atob bind peer-ip 20.1.1.2
[~SwitchA-bfd-session-atob] min-rx-interval 50
[~SwitchA-bfd-session-atob] min-tx-interval 50
# Create a BFD session on SwitchE.
[~SwitchE] bfd
[~SwitchE-bfd] quit
[~SwitchE] bfd btoa bind peer-ip 192.168.1.1
[~SwitchE-bfd-session-btoa] discriminator local 2
[~SwitchE-bfd-session-btoa] discriminator remote 1
[~SwitchE-bfd-session-btoa] min-rx-interval 50
[~SwitchE-bfd-session-btoa] min-tx-interval 50
[~SwitchE-bfd-session-btoa] commit
[~SwitchE-bfd-session-btoa] quit
Step 4 Configure association between VRRP and BFD.
# Configure association between VRRP and BFD on SwitchA. When the BFD session becomes
Down, the priority of SwitchA decreases by 40.
[~SwitchA-Vlanif100] vrrp vrid 1 track bfd 1 reduce 40
100
SwitchA is the master, SwitchB is the backup, and the associated BFD session is in Up state.
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Track BFD : 1 Priority reduced : 40
BFD-Session State : UP
Create time : 2012-05-22 17:32:56
Last change time : 2012-05-22 17:33:00
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:33:00
Last change time : 2012-05-22 17:33:04
# Run the shutdown command on 10GE1/0/1 of SwitchE to simulate a link fault.
[~SwitchE] interface 10ge 1/0/1
[~SwitchE-10GE1/0/1] shutdown
[~SwitchE-10GE1/0/1] commit
[~SwitchE-10GE1/0/1] quit
# Run the display vrrp command on SwitchA and SwitchB. You can see that SwitchA is in
Backup state, SwitchB becomes the master, and the associated BFD session becomes Down.
State : Backup
PriorityRun : 80
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
101
BFD-Session State : DOWN
Create time : 2012-05-22 17:34:56
Last change time : 2012-05-22 17:35:00
State : Master
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-22 17:35:00
Last change time : 2012-05-22 17:35:04
# Run the undo shutdown command on 10GE1/0/1 of SwitchE.
[~SwitchE-10GE1/0/1] undo shutdown
[~SwitchE-10GE1/0/1] commit
# After 20s, run the display vrrp command on SwitchA and SwitchB. You can see that
SwitchA restores to be the master, SwitchB restores to be the backup, and the associated BFD
session is in Up state.
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
BFD-Session State : UP
Create time : 2012-05-22 17:36:56
Last change time : 2012-05-22 17:37:00
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
102
Create time : 2012-05-22 17:37:00
Last change time : 2012-05-22 17:37:04
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 300
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 track bfd 1 reduce 40
#
interface Vlanif300
ip address 192.168.1.1 255.255.255.0
#
bfd atob bind peer-ip 20.1.1.2
min-tx-interval 50
min-rx-interval 50
commit
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
103
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 300 500
#
interface Vlanif300
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif500
ip address 20.1.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
l Configuration file of SwitchD
#
sysname SwitchD
#
vlan batch 200 400
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif400
ip address 30.1.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
bfd
#
vlan batch 400 500
104
#
interface Vlanif400
ip address 30.1.1.2 255.255.255.0
#
interface Vlanif500
ip address 20.1.1.2 255.255.255.0
#
bfd btoa bind peer-ip 192.168.1.1
min-tx-interval 50
min-rx-interval 50
commit
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
3.8.8 Example for Configuring Association Between VRRP and
Routing to Monitor the Uplink Status
SwitchA functions as the gateway and user traffic is along the path Switch -> SwitchA ->
SwitchC -> SwitchE.
When the route between SwitchC and SwitchE is withdrawn or becomes inactive, the VRRP
group can detect the fault and an active/standby switchover is performed. SwitchB is enabled to
forward services, so the impact of the link fault on service forwarding is reduced.
105
Figure 3-14 Association between VRRP and routing to monitor the uplink status
HostA
SwitchA
SwitchB
SwitchC
SwitchD
Internet
10GE1/0/2
192.168.1.1/24
VRRP VRID 1
Virtual IP Address:
10.1.1.10
10GE1/0/1
10.1.1.1/24
10GE1/0/1
10.1.1.2/24
10GE1/0/1
192.168.1.2/24
10GE1/0/2
20.1.1.1/24
Switch
10GE1/0/2
192.168.2.1/24
10GE1/0/1
192.168.2.2/24
Master
Backup
10GE1/0/2
30.1.1.1/24
10GE1/0/2
30.1.1.2/24
10GE1/0/1
20.1.1.2/24
GE1/0/0
GE2/0/0
SwitchE
10GE1/0/2 VLANIF 300 192.168.1.1/24
10GE1/0/2 VLANIF 200 192.168.2.1/24
10GE1/0/2 VLANIF 500 20.1.1.1/24
SwitchD 10GE1/0/1 VLANIF 200 192.168.2.2/24
10GE1/0/2 VLANIF 400 30.1.1.1/24
SwitchE 10GE1/0/1 VLANIF 500 20.1.1.2/24
10GE1/0/2 VLANIF 400 30.1.1.2/24

connectivity.
that SwitchA functions as the master to forward traffic and set the preemption delay to 20s,
and set a lower priority for SwitchB so that SwitchB functions as the backup.
106
3. Configure association between VRRP and routing on SwitchA so that an active/standby
switchover is performed immediately when the monitored route is withdrawn or becomes
inactive.
Procedure
Step 1 Assign an IP address to each interface. SwitchA is used as an example. The configurations of
other devices are similar to the configuration of SwitchA, and are not mentioned here.
[~HUAWEI] commit
[~SwitchA] commit
# Configure VRRP group 1 on SwitchB. SwitchB uses default priority 100.
Step 3 Configure IS-IS. SwitchA, SwitchC, and SwitchE are used as an example. The configurations
of other Switchs are similar to the configuration of SwitchA, and are not mentioned here.
# Set the IS-IS NET of SwitchA to 10.0000.0000.0001.00, and set the IS-IS level to 1.
[~SwitchA] isis 1
[~SwitchA-isis-1] is-level level-1
[~SwitchA-isis-1] network-entity 10.0000.0000.0001.00
[~SwitchA-isis-1] quit
[~SwitchA-Vlanif100] isis enable 1
[~SwitchA-Vlanif 200] isis enable 1
# Set the IS-IS NET of SwitchC to 10.0000.0000.0002.00.
107
[~SwitchC] isis 1
[~SwitchC-isis-1] network-entity 10.0000.0000.0002.00
[~SwitchC-isis-1] quit
[~SwitchC] interface vlanif 300
[~SwitchC-Vlanif300] isis enable 1
[~SwitchC-Vlanif300] quit
[~SwitchC] interface vlanif 500
[~SwitchC-Vlanif500] isis enable 1
[~SwitchC-Vlanif500] quit
# Set the IS-IS NET of SwitchE to 10.0000.0000.0003.00 and 20.0000.0000.0003.00.
[~SwitchE] isis 1
[~SwitchE-isis-1] network-entity 10.0000.0000.0003.00
[~SwitchE-isis-1] quit
[~SwitchE] interface vlanif 500
[~SwitchE-Vlanif 500] isis enable 1
[~SwitchE-Vlanif500] quit
[~SwitchE] isis 2
[~SwitchE-isis-2] network-entity 20.0000.0000.0003.00
[~SwitchE-isis-2] quit
[~SwitchE] interface vlanif 400
[~SwitchE-Vlanif400] isis enable 2
[~SwitchE-Vlanif400] quit
Step 4 Configure association between VRRP and routing on SwitchA. When the associated route is
withdrawn, the priority of SwitchA decreases by 40.
[~SwitchA-Vlanif100] vrrp vrid 1 track ip route 20.1.1.0 24 reduce 40
# After the configuration is complete, run the display isis route command on SwitchA. You can
see a route to network segment 20.1.1.0/24.
<SwitchA> display isis route

Route information for ISIS(1)
-----------------------------

ISIS(1) Level-1 Forwarding Table
--------------------------------

IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags
-------------------------------------------------------------------------------
192.168.1.0/24 10 NULL GE0/0/2 Direct D/-/L/-
20.1.1.0/24 20 NULL 10GE1/0/2 192.168.1.2 A/-/-/-
10.1.1.0/24 10 NULL Vlanif18 Direct D/-/L/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set
# Run the display vrrp command on SwitchA and SwitchB. You can see that SwitchA is the
master, SwitchB is the backup, and the associated route is reachable.
10GE1/0/1 | Virtual Router 1
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
108
Check TTL : YES
Track IP route : 20.1.1.0/24 Priority reduced : 40
IP route state : Reachable
Create time : 2012-05-29 21:25:47
Last change time : 2012-05-29 21:25:51
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-29 21:25:47
Last change time : 2012-05-29 21:25:51
# Run the shutdown command on 10GE1/0/1 of SwitchE to simulate a link fault.
[~SwitchE-10GE1/0/1] shutdown
# Run the display isis route command on SwitchA. You can see that the route to network
segment 20.1.1.0/24 is withdrawn.
<SwitchA> display isis route

Route information for ISIS(1)
-----------------------------

ISIS(1) Level-1 Forwarding Table
--------------------------------

IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags
-------------------------------------------------------------------------------
192.168.1.0/24 10 NULL 10GE1/0/2 Direct D/-/L/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set
# Run the display vrrp command on SwitchA and SwitchB. You can see that SwitchA is in
Backup state, SwitchB is in Master state, and the associated route is reachable.
State : Backup
PriorityRun : 80
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
IP route state : Unreachable
109
Create time : 2012-05-29 21:25:47
Last change time : 2012-05-29 21:25:51
State : Master
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-29 21:25:47
Last change time : 2012-05-29 21:25:51
# Run the undo shutdown command on GE1/0/0 of SwitchE.
[~SwitchE-10GE1/0/1] undo shutdown
# After 20s, run the display vrrp command on SwitchA and SwitchB. You can see that
SwitchA restores to be the master, SwitchB restores to be the backup, and the associated route
is reachable.
State : Master
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
IP route state : Reachable
Create time : 2012-05-29 21:27:47
Last change time : 2012-05-29 21:27:51
State : Backup
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-29 21:27:47
Last change time : 2012-05-29 21:27:51
----End
110
Configuration Files
#
sysname SwitchA
#
vlan batch 100 300
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 track ip route 20.1.1.0 255.255.255.0 reduce 40
isis enable 1
#
interface Vlanif200
ip address 192.168.1.1 255.255.255.0
isis enable 1
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
isis 1
is-level level-1
network-entity 20.0000.0000.0001.00
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
#
sysname SwitchC
#
111
vlan batch 300 500
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Vlanif300
ip address 192.168.1.2 255.255.255.0
isis enable 1
#
interface Vlanif500
ip address 20.1.1.1 255.255.255.0
isis enable 1
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
l Configuration file of SwitchD
#
sysname SwitchD
#
vlan batch 200 400
#
isis 1
network-entity 20.0000.0000.0002.00
#
interface Vlanif200
ip address 192.168.1.2 255.255.255.0
isis enable 1
#
interface Vlanif400
ip address 30.1.1.1 255.255.255.0
isis enable 1
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
vlan batch 400 500
#
isis 1
network-entity 10.0000.0000.0003.00
#
isis 2
network-entity 20.0000.0000.0003.00
#
interface Vlanif400
ip address 30.1.1.2 255.255.255.0
isis enable 2
#
interface Vlanif500
ip address 20.1.1.2 255.255.255.0
isis enable 1
#
112
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
3.8.9 Example for Configuring Association Between a VRRP Group
and a Direct Route
As shown in Figure 3-15, the VRRP group consisting of NPE1 and NPE2 functions as the
gateway and uplink traffic is sent to the master device NPE1. OSPF runs between NPE1, NPE2,
and NPE3 to ensure connectivity. The path that downlink traffic passes is determined by OSPF
route selection. On NPE3, there are two equal-cost OSPF routes to network segment 10.1.1.0/24,
so downlink traffic may be load balanced. In this case, uplink and downlink traffic are transmitted
along different paths, so data is blocked by the firewall. It is required that uplink and downlink
traffic be transmitted along the same path so that data can pass the firewall.
Figure 3-15 Association between a VRRP group and a direct route
NPE1
(Master)
NPE2
(Backup)
NPE3
User Network
IP/MPLS
Network
UPE
10GE1/0/2
10.1.1.1/24
Vlanif100
10GE1/0/1
10.1.3.1/24
Vlanif300
10GE1/0/2
10.1.1.2/24
Vlanif100
10GE1/0/1
10.1.2.1/24
Vlanif200
10GE1/0/2
10.1.3.2/24
Vlanif300
10GE1/0/1
10.1.2.2/24
Vlanif200
VRRP
10GE1/0/2
10GE1/0/1
FirewallA
FirewallB
l Configure a VRRP group on NPE1 and NPE2 to improve link reliability.
l Configure OSPF on NPE1, NPE2, and NPE3 to ensure connectivity at the network layer.
113
l Configure association between a direct route and a VRRP group on NPE1 and NPE2.
l Configure OSPF to import direct routes and retain the cost of the imported route on NPE1
and NPE2 so that VRRP can be associated with direct routes.
Procedure
Step 1 Assign an IP address to each interface. For details, see configuration files.
# Create VLAN 100 on the UPE, and add 10GE1/0/1 and 10GE1/0/2 to VLAN 10 so that VRRP
packets from NPE1 and NPE2 can be transparently transmitted.
<UPE> system-view
[~UPE] vlan 100
[~UPE-vlan100] port 10ge 1/0/1
[~UPE-vlan100] port 10ge 1/0/2
[~UPE-vlan100] commit
[~UPE-vlan100] quit
# Create VRRP group 1 on NPE1 and set the priority of NPE1 in the group to 120 so that NPE1
functions as the master.
<NPE1> system-view
[~NPE1] interface vlanif 100
[~NPE1-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
[~NPE1-Vlanif100] vrrp vrid 1 priority 120
[~NPE1-Vlanif100] commit
[~NPE1-Vlanif100] quit
# Create VRRP group 1 on NPE2 and set the priority of NPE2 to 100 so that NPE2 functions as
the backup.
<NPE2> system-view
[~NPE2-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
Step 3 Configure OSPF.
# Configure OSPF on NPE1.
[~NPE1] ospf 1
[~NPE1-ospf-1] area 0
[~NPE1-ospf-1-area-0.0.0.0] network 10.1.3.0 0.0.0.255
[~NPE1-ospf-1-area-0.0.0.0] commit
[~NPE1-ospf-1-area-0.0.0.0] quit
[~NPE1-ospf-1] quit
[~NPE2] ospf 1
[~NPE2-ospf-1] quit
<NPE3> system-view
[~NPE3] ospf 1
114
[~NPE3-ospf-1] quit
Step 4 Configure association between a direct route and a VRRP group.
# Configure NPE1.
[~NPE1-Vlanif100] direct-route track vrrp vrid 1 degrade-cost 300
# Configure NPE2.
[~NPE2-Vlanif100] direct-route track vrrp vrid 1 degrade-cost 300
Step 5 Configure OSPF to import direct routes.
# Configure NPE1.
[~NPE1] ospf 1
[~NPE1-ospf-1] import-route direct
[~NPE1-ospf-1] default cost inherit-metric
[~NPE1-ospf-1] commit
[~NPE1-ospf-1] quit
# Configure NPE2.
[~NPE2] ospf 1
[~NPE2-ospf-1] import-route direct
[~NPE2-ospf-1] default cost inherit-metric
[~NPE2-ospf-1] commit
[~NPE2-ospf-1] quit
# Run the display ip routing-table command on NPE2 to view the IP routing table. You can
see that the cost of the direct route on the network segment where the VRRP-enabled interface
is located is 300.
<NPE2> display ip routing-table
------------------------------------------------------------------------------
Routing Table : _public_
10.1.1.0/24 Direct 0 300 D 10.1.1.2 Vlanif100
10.1.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif100
10.1.1.111/32 O_ASE 150 0 D 10.1.2.2 Vlanif200
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif100
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Vlanif200
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif200
10.1.2.255/32 Direct 0 0 D 127.0.0.1 Vlanif200
10.1.3.0/24 OSPF 10 2 D 10.1.2.2 Vlanif200
# Run the display ip routing-table 10.1.1.0 command on NPE3 to view the route to the user
network segment. You can see that NPE3 sends downlink traffic through the route with the next
hop 10.1.3.1.
115
<NPE3> display ip routing-table 10.1.1.0
------------------------------------------------------------------------------
Routing Table : _public_
Summary Count : 1
10.1.1.0/24 O_ASE 150 0 D 10.1.3.1 Vlanif300
----End
Configuration Files
l Configuration file of the UPE
#
sysname UPE
#
vlan batch 100
#
interface 10GE1/0/1
port default vlan 100
#
interface 10GE1/0/2
#
return
l Configuration file of NPE1
#
sysname NPE1
#
vlan batch 100 300
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
direct-route track vrrp vrid 1 degrade-cost 300
#
interface Vlanif300
ip address 10.1.3.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
import-route direct
area 0.0.0.0
network 10.1.3.0 0.0.0.255
#
return
#
sysname NPE2
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
direct-route track vrrp vrid 1 degrade-cost 300
#
116
interface Vlanif200
ip address 10.1.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
import-route direct
area 0.0.0.0
network 10.1.2.0 0.0.0.255
#
return
#
sysname NPE3
#
vlan batch 200 300
#
interface Vlanif200
ip address 10.1.2.2 255.255.255.0
#
interface Vlanif300
ip address 10.1.3.2 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
return
This section describes common faults caused by incorrect VRRP configurations and provides
the troubleshooting procedure.
3.9.1 Multiple Masters Coexist in a VRRP Group
Fault Description
Multiple masters exist in a VRRP group.
Procedure
Step 1 Ping masters to check network connectivity between masters.
l If the ping operation fails, check whether the network connection is correct.
l If the ping operation is successful and the TTL value of the ping packet is 255, go to step 2.
117
Step 2 Run the display vrrp virtual-router-id command in any view to check whether the master uses
the same virtual IP address, interval at which VRRP Advertisement packets are sent,
authentication mode, and authentication key.
l If the configured virtual IP addresses are different, run the vrrp vrid virtual-router-id
virtual-ip virtual-address command to set the same virtual IP address.
l If the intervals are different, run the vrrp vrid virtual-router-id timer advertise advertise-
interval command to set the same interval.
l If the authentication modes and authentication keys are different, run the vrrp vrid virtual-
router-id authentication-mode { simple { key | plain key | cipher cipher-key } | md5 md5-
key } command to set the same authentication mode and authentication key.
----End
3.9.2 VRRP Group Status Changes Frequently
Fault Description
The VRRP group status changes frequently.
Procedure
Step 1 Run the display vrrp virtual-router-id command in any view to check whether the VRRP group
is associated with an interface, a BFD session, or an NQA test instance.
l If the VRRP group is associated with the interface, BFD session, or NQA test instance,
flapping of the interface, BFD session, or NQA test instancecauses VRRP group status
flapping. Rectify the fault on the associated module.
l If association is not configured, go to step 2.
Step 2 Run the display vrrp virtual-router-id command in any view to check the preemption delay of
the VRRP group.
l If the preemption delay is 0, run the vrrp vrid virtual-router-id preempt timer delay delay-
value command in the view of the interface where the VRRP group is configured to set the
non-0 preemption delay.
l If the preemption is not 0, go to step 3.
Step 3 Run the vrrp vrid virtual-router-id timer advertise advertise-interval command in the view of
the interface where the VRRP group is configured to set a larger interval at which VRRP
Advertisement packets are sent, or run the vrrp vrid virtual-router-id preempt timer delay
delay-value command to set a larger preemption delay.
----End
118

CloudEngine 12800 V100R001C00 Configuration Guide - Reliability 03

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CloudEngine 12800 V100R001C00 Configuration Guide - Reliability 03

Hochgeladen von

Copyright:

Verfügbare Formate

CloudEngine 12800 Series Switches

Das könnte Ihnen auch gefallen