HP MSR SERIES User manual

HP MSR Router Series
High Availability
Configuration Guide(V5)
Part number: 5998-2031
Software version: CMW520-R2509
Document version: 6PW102-20130925

Legal and notice information
© Copyright 2013 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or
use of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained
herein.

i
Contents
High availability overview··········································································································································· 1
Availability requirements··················································································································································1
Availability evaluation······················································································································································1
High availability technologies ·········································································································································2
Fault detection technologies ····································································································································2
Protection switchover technologies·························································································································2
Configuring BFD··························································································································································· 4
Introduction to BFD····························································································································································4
How BFD works ························································································································································4
BFD packet format····················································································································································7
Supported features ···················································································································································8
Protocols and standards ··········································································································································9
Configuring BFD basic functions ·····································································································································9
Configuration prerequisites ·····································································································································9
Configuration procedure ·········································································································································9
Enabling trap·································································································································································· 10
Displaying and maintaining BFD·································································································································· 11
Configuring interface backup ···································································································································12
Overview········································································································································································· 12
Active and standby interfaces······························································································································ 12
How interface backup works ······························································································································· 13
Interface backup configuration task list ······················································································································· 14
Configuring interface backup······································································································································· 14
Configuring active/standby mode ······················································································································ 14
Associating an interface with a track entry ········································································································ 15
Configuring load balancing·········································································································································· 15
Configuring the delay timer for the backup function to take effect on system startup············································ 16
Displaying and maintaining interface backup············································································································ 17
Interface backup configuration examples ··················································································································· 17
Multi-interface backup configuration example··································································································· 17
Multi-interface load balancing configuration example ····················································································· 18
Configuring Track ······················································································································································22
Track overview ······························································································································································· 22
Collaboration fundamentals································································································································· 22
Collaboration application example····················································································································· 23
Collaboration application example on an AC··································································································· 23
Track configuration task list··········································································································································· 24
Associating the Track module with a detection module····························································································· 24
Associating Track with NQA ······························································································································· 24
Associating Track with BFD·································································································································· 25
Associating Track with interface management··································································································· 26
Associating the Track module with an application module······················································································· 27
Associating Track with VRRP································································································································ 27
Associating Track with static routing··················································································································· 28
Associating Track with PBR ·································································································································· 29
Associating Track with interface backup ············································································································ 31
Displaying and maintaining track entries···················································································································· 32

ii
Track configuration examples······································································································································· 32
VRRP-Track-NQA collaboration configuration example···················································································· 32
Configuring BFD for a VRRP backup to monitor the master·············································································· 36
Configuring BFD for the VRRP master to monitor the uplink ············································································· 39
Static routing-Track-NQA collaboration configuration example ······································································ 42
Static routing-Track-BFD collaboration configuration example········································································· 47
VRRP-Track-interface management collaboration configuration example ······················································· 50
Configuring VRRP·······················································································································································54
VRRP overview································································································································································ 54
VRRP standard mode············································································································································· 55
VRRP load balancing mode·································································································································· 61
Configuring IPv4 VRRP ·················································································································································· 65
IPv4 VRRP configuration task list·························································································································· 65
Specifying an IPv4 VRRP operating mode·········································································································· 66
Specifying the IPv4 VRRP version ························································································································ 66
Specifying the type of MAC addresses mapped to virtual IP addresses························································· 67
Creating a VRRP group and assigning a virtual IP address ············································································· 67
Configuring router priority, preemptive mode, and tracking function····························································· 69
Configuring VF tracking········································································································································ 70
Configuring IPv4 VRRP packet attributes ············································································································ 71
Enabling the trap function for VRRP····················································································································· 72
Displaying and maintaining IPv4 VRRP··············································································································· 72
Configuring IPv6 VRRP ·················································································································································· 73
Specifying the type of MAC addresses mapped to virtual IPv6 addresses ···················································· 73
Creating a VRRP group and assigning a virtual IPv6 address ········································································· 74
Configuring router priority, preemptive mode, and tracking function····························································· 75
Configuring VF tracking········································································································································ 76
Configuring IPv6 VRRP packet attributes ············································································································ 77
Displaying and maintaining IPv6 VRRP··············································································································· 78
IPv4 VRRP configuration examples······························································································································· 78
Single VRRP group configuration example········································································································· 78
VRRP interface tracking configuration example ································································································· 81
Multiple VRRP groups configuration example ···································································································· 84
VRRP load balancing configuration example····································································································· 86
IPv6 VRRP configuration examples······························································································································· 96
Single VRRP group configuration example········································································································· 96
VRRP interface tracking configuration example ································································································· 99
Multiple VRRP groups configuration example ··································································································103
VRRP load balancing configuration example···································································································105
Troubleshooting VRRP··················································································································································114
The screen frequently displays error prompts···································································································114
Multiple masters appear in a VRRP group········································································································114
Frequent VRRP state transition····························································································································115
Support and other resources ·································································································································· 116
Contacting HP ······························································································································································116
Subscription service ············································································································································116
Related information······················································································································································116
Documents····························································································································································116
Websites·······························································································································································116
Conventions ··································································································································································117
Index ········································································································································································ 119

1
High availability overview
Because communication interruptions can seriously affect widely-deployed value-added services such as
IPTV and video conference, basic network infrastructures must be able to provide high availability.
The following are the effective ways to improve availability:
•Increasing fault tolerance.
•Speeding up fault recovery.
•Reducing impact of faults on services.
Availability requirements
Table 1 describes a typical availability model that divides availability requirements into different levels.
Table 1 Availability requirements
Level Re
q
uirement Solution
1 Decrease system software and
hardware faults
•Hardware—Simplified circuit design, enhanced
production techniques, and reliability tests.
•Software—Reliability design and test.
2 Protect system functions from being
affected if faults occur Device and link redundancy and switchover.
3 Enable the system to recover as fast
as possible
Performing fault detection, diagnosis, isolation, and
recovery technologies.
Consider level 1 availability requirements during the design and production processes of network
devices.
Consider level 2 availability requirements during network design.
Consider level 3 availability requirements during network deployment, according to the network
infrastructure and service characteristics.
Availability evaluation
Mean Time Between Failures (MTBF) and Mean Time to Repair (MTTR) are used to evaluate the
availability of a network.
MTBF
MTBF is the predicted elapsed time between inherent failures of a system during operation. It is typically
in the unit of hours. A higher MTBF means a high availability.
MTTR
MTTR is the average time required to repair a failed system. MTTR in a broad sense also involves spare
parts management and customer services.

2
MTTR = fault detection time + hardware replacement time + system initialization time + link recovery time
+ routing time + forwarding recovery time. A smaller value of each item means a smaller MTTR and a
higher availability.
High availability technologies
Increasing MTBF or decreasing MTTR can enhance the availability of a network. The high availability
technologies described in this section meet the level 2 and level 3 high availability requirements in the
aspect of decreasing MTTR.
High availability technologies can be classified as fault detection technologies or protection switchover
technologies.
Fault detection technologies
Fault detection technologies enable detection and diagnosis of network faults:
•BFD is a generic fault detection technology that can be used at any layer.
•NQA is used for diagnosis and evaluation of network quality.
•Track works along with other high availability technologies to detect faults through a collaboration
mechanism.
Table 2 Fault detection technologies
Technolo
gy
Introduction Reference
BFD
BFD provides a single mechanism to quickly detect and monitor the
connectivity of links or IP forwarding in networks. To improve network
performance, devices must quickly detect communication failures to
restore communication through backup paths as soon as possible.
"Configuring BFD"
NQA
NQA analyzes network performance, services and service quality
through sending test packets, and provides you with network
performance and service quality parameters such as jitter, TCP
connection delay, FTP connection delay and file transfer rate.
Network
Management and
Monitoring
Configuration
Guide
Track
The Track module implements collaboration between different
modules. The collaboration involves three sets of modules:
application, Track, and detection. These modules collaborate with
one another through collaboration entries. The detection modules
trigger the application modules to perform certain operations through
the Track module. The detection modules probe such items as link
status and network performance, and inform the application modules
of the detection result through the Track module. Once notified of
network status changes, the application modules use the changes to
avoid communication interruption and network performance
degradation.
"Configuring
Track"
Protection switchover technologies
Protection switchover technologies aim at recovering network faults. They back up hardware, link, routing,
and service information for switchover in case of network faults to ensure continuity of network services.

3
A single availability technology cannot solve all problems. You should use a combination of availability
technologies, chosen on the basis of detailed analysis of network environments and user requirements,
to enhance network availability. For example, access-layer devices should be connected to
distribution-layer devices over redundant links, and core-layer devices should be fully meshed. Network
availability should be considered during the planning stage.
Table 3 Protection switchover technologies
Technolo
gy
Introduction Reference
Interface
backup
Interface backup allows interfaces on one device to back up one
another. The main interface transmits services, and the backup
interfaces are in the backup state. When the main interface fails or
the link fails, a backup interface is brought up to transmit services,
increasing network reliability.
"Configuring
interface backup"
Ethernet link
aggregation
Ethernet link aggregation, or link aggregation, aggregates multiple
physical Ethernet links into one logical link to increase link
bandwidth beyond the limits of any one single link. This logical link
is an aggregate link. It allows for link redundancy because the
member physical links can dynamically back up one another.
Layer 2—LAN
Switching
Configuration Guide
MSTP
As a Layer 2 management protocol, MSTP eliminates Layer 2 loops
by selectively blocking redundant links in a network, and in the
meantime, allows for link redundancy.
Layer 2—LAN
Switching
Configuration Guide
GR
GR ensures the continuity of packet forwarding when a protocol,
such as BGP, IS-IS, OSPF, LDP, or RSVP-TE, restarts, or during an
active/standby switchover process. It needs other devices to
implement routing information backup and recovery.
Related chapters in
Layer 3—IP Routing
Configuration Guide
and MPLS
Configuration Guide
VRRP
VRRP is an error-tolerant protocol, which provides highly reliable
default links on multicast and broadcast LANs such as Ethernet,
avoiding network interruption due to failure of a single link.
"Configuring VRRP"

4
Configuring BFD
Introduction to BFD
Devices must detect communication failures quickly so that measures can be taken in time to ensure
service continuity and enhance network availability.
Fault detection methods include the following:
•Hardware detection—Detects link failures by sending hardware detection signals, such as
synchronous digital hierarchy (SDH) alarms. Hardware detection can quickly detect link failures,
but is not supported by all media types.
•Hello mechanism—Devices can use the hello mechanism of a routing protocol to detect link failures.
The hello mechanism takes seconds to detect a link failure. However, that detection rate is too slow
for voice services and other delay-sensitive services. It is also too slow for high-speed data
transmission, such as Gigabit data transmission, where a detection rate slower than one second will
cause a large quantity of data to be dropped. This detection method is dependent on the routing
protocol.
•Other detection methods—Some protocols provide dedicated detection mechanisms. However,
these are difficult to deploy for inter-system communications.
Bidirectional forwarding detection (BFD) provides a single mechanism to quickly detect and monitor the
connectivity of links or IP forwarding in networks. To improve network performance, devices must quickly
detect communication failures and restore communication through backup paths as soon as possible.
How BFD works
BFD provides a general-purpose, standard, medium- and protocol-independent fast failure detection
mechanism. It can uniformly and quickly detect the failures of the bidirectional forwarding paths between
two routers, for protocols such as routing protocols and Multiprotocol Label Switching (MPLS).
BFD provides no neighbor discovery mechanism. Protocols that BFD services notify BFD of routers to
which it needs to establish sessions. After a session is established, if no BFD control packet is received
from the peer within the negotiated BFD interval, BFD notifies a failure to the protocol, which takes
appropriate measures.

5
BFD session establishment
Figure 1 BFD session establishment (on OSPF routers)
As shown in Figure 1, BFD sessions are established as follows:
1. A protocol sends Hello messages to discover neighbors and establish neighborships.
2. After establishing neighborships, the protocol notifies BFD of the neighbor information, including
destination and source addresses.
3. BFD uses the information to establish BFD sessions.
Figure 2 BFD fault detection (on OSPF routers)
BFD fault detection
The BFD fault detection process is as follows:
1. BFD detects a link failure.
2. BFD clears the neighbor session.
3. BFD notifies the protocol of the failure.
4. The protocol terminates the neighborship on the link.
5. If a backup link is available, the protocol will use it to forward packets.
No detection time resolution is defined in the BFD draft. Most devices supporting BFD provide detection
measured in milliseconds.
BFD detection methods
BFD detection methods include the following:
5
OSPF neighbors
BFD neighbors
Router A Router B
1
2
Fault
BFD notifies the OSPF link failure
33
4
Backup link

6
•Single-hop detection—Detects the IP connectivity between two directly connected systems.
•Multi-hop detection—Detects any of the paths between two systems. These paths have multiple
hops and might be overlapped.
•Bidirectional detection—Sends detection packets at two sides of a bidirectional link to detect the
bidirectional link status, finding link failures in milliseconds. (BFD LSP detection is a special case, in
which BFD control packets are sent in one direction, and the peer device reports the link status
through other links.)
BFD session modes
Session modes for BFD include:
•Control packet mode—Both ends of the link exchange BFD control packets to monitor link status.
•Echo packet mode—One end of the link sends Echo packets to the other end, which then forwards
the packets back to the originating end, monitoring link status in both directions.
BFD operating modes
Before a BFD session is established, BFD has two operating modes—active and passive.
•Active mode—BFD actively sends BFD control packets regardless of whether any BFD control
packet is received from the peer.
•Passive mode—BFD does not send control packets until a BFD control packet is received from the
peer.
At least one end must operate in active mode for a BFD session to be established.
After a BFD session is established, both ends must operate in one of the following BFD operating modes:
•Asynchronous mode—Both endpoints periodically send BFD control packets to each other. BFD
considers that the session is down if it receives no BFD control packets within a specific interval.
•Demand mode—No BFD control packets are exchanged after the session is established. It is
assumed that the endpoints have another way to verify connectivity to each other. However, either
host might still send BFD control packets if needed.
When the connectivity to another system needs to be verified explicitly, a system sends several BFD
control packets that have the Poll (P) bit set at the negotiated transmit interval. If no response is received
within the detection interval, the session is considered down. If connectivity is found to be up, no more
BFD control packets are sent until the next command is issued.
NOTE:
•Only the asynchronous mode is supported.
•When a BFD session is maintained by sending Echo packets, the session is independent of the operatin
g
mode.
Dynamic BFD parameter changes
After a BFD session is established, both ends can negotiate the related BFD parameters, such as the
minimum transmit interval, minimum receive interval, initialization mode, and packet authentication
mode. After that, both ends use the negotiated parameters, without affecting the current session state.
Authentication modes
BFD provides the following authentication methods:
•Simple—Simple authentication.
•MD5—MD5 (Message Digest 5) authentication.

7
•SHA1—SHA1 (Secure Hash Algorithm 1) authentication.
BFD packet format
BFD control packets are encapsulated into UDP packets with port number 3784 for single-hop detection
or port number 4784 for multi-hop detection (also can be 3784 based on the configuration task). BFD
echo packets have a similar format as BFD control packets with UDP port number 3785 except that the
Desired Min TX Interval and Required Min RX Interval fields are null. Figure 3 illustrates the packet format.
Figure 3 BFD packet format
•Vers—Protocol version. The protocol version is 1.
•Diag—This bit indicates the reason for the last transition of the local session from up to some other
state. Table 4 lists the states.
Table 4 Diag bit values
Dia
g
Descri
p
tion
0 No Diagnostic.
1 Control Detection Time Expired.
2 Echo Function Failed.
3 Neighbor Signaled Session Down.
4 Forwarding Plane Reset.
5 Path Down.
6 Concatenated Path Down.
7 Administratively Down.
8 Reverse Concatenated Path Down.
9–31 Reserved for future use.
•State (Sta)—Current BFD session state. Its value can be 0 for AdminDown, 1 for Down, 2 for Init,
and 3 for Up.
•Poll (P)—If set, the transmitting system is requesting verification of connectivity, or of a parameter
change. If clear, the transmitting system is not requesting verification.
•Final (F)—If set, the transmitting system is responding to a received BFD control packet that had the
Poll (P) bit set. If clear, the transmitting system is not responding to a Poll.

8
•Control Plane Independent(C)—If set, the transmitting system's BFD implementation does not share
fate with its control plane. That is, BFD is implemented in the forwarding plane and can continue to
function through disruptions in the control plane. If clear, the transmitting system's BFD
implementation shares fate with its control plane.
•Authentication Present (A)—If set, the Authentication Section is present and the session is to be
authenticated.
•Demand (D)—If set, Demand mode is active in the transmitting system. The system would like to
operate in Demand mode, knows that the session is up in both directions, and is directing the
remote system to stop the periodic transmission of BFD control packets. If clear, Demand mode is not
active in the transmitting system.
•Reserved (R)—This byte must be set to zero on transmit, and ignored on receipt.
•Detect Mult—Detection time multiplier.
•Length—Length of the BFD control packet, in bytes.
•My Discriminator—A unique, nonzero discriminator value generated by the transmitting system,
used to demultiplex multiple BFD sessions between the same pair of systems.
•Your Discriminator—It is the discriminator received from the remote system. This field reflects back
the received value of My Discriminator, or is 0 if that value is unknown.
•Desired Min TX Interval—This is the minimum interval (in milliseconds) that the local system would
like to use when transmitting BFD control packets. The value zero is reserved.
•Required Min RX Interval—This is the minimum interval (in milliseconds) between received BFD
control packets that this system is capable of supporting. If this value is zero, the transmitting system
does not want the remote system to send any periodic BFD control packets.
•Required Min Echo RX Interval—This is the minimum interval (in milliseconds) between received
BFD echo packets that this system is capable of supporting. If this value is zero, the transmitting
system does not support the receipt of BFD echo packets.
•Auth Type—The authentication type in use, if the Authentication Present (A) bit is set.
•Auth Len—The length, in bytes, of the authentication section, including the Auth Type and Auth Len
fields.
Supported features
•OSPF. For more information, see Layer 3—IP Routing Configuration Guide.
•OSPFv3. For more information, see Layer 3—IP Routing Configuration Guide.
•IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.
•IPv6 IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.
•RIP. For more information, see Layer 3—IP Routing Configuration Guide.
•Static routing. For more information, see Layer 3—IP Routing Configuration Guide.
•BGP. For more information, see Layer 3—IP Routing Configuration Guide.
•IPv6 BGP. For more information, see Layer 3—IP Routing Configuration Guide.
•PIM. For more information, see IP Multicast Configuration Guide.
•IPv6 PIM. For more information, see IP Multicast Configuration Guide.
•MPLS. For more information, see MPLS Configuration Guide.
•Track. For more information, see "Configuring Track."

9
•IP fast reroute (FRR). IP FRR is supported by OSPF, RIP, IS-IS and static routing. For more information,
see Layer 3—IP Routing Configuration Guide.
Protocols and standards
•RFC 5880, Bidirectional Forwarding Detection (BFD)
•RFC 5881, Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
•RFC 5882, Generic Application of Bidirectional Forwarding Detection (BFD)
•RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths
•RFC 5884, Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
•RFC 5885, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV)
Configuring BFD basic functions
The BFD basic function configuration is the basis for configuring BFD for other protocols.
Configuration prerequisites
Before configuring BFD basic functions, complete the following tasks:
•Configure the network layer addresses of the interfaces so that adjacent nodes are reachable to
each other at the network layer.
•Configure the routing protocols that support BFD.
Configuration procedure
To configure BFD basic functions:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Specify the mode for
establishing a BFD session.
bfd session init-mode { active |
passive }
Optional.
active by default.
3. Configure the destination port
number for multi-hop BFD
control packets.
bfd multi-hop destination-port
port-number
Optional.
4784 by default.
4. Configure the source IP
address of echo packets. bfd echo-source-ip ip-address
This command applies to only BFD
echo packet mode.
The source IP address cannot be on
the same network segment as any
local interface's IP address.
Otherwise, a large number of
ICMP redirect packets might be
sent from the peer, resulting in link
congestion.

10
Ste
p
Command Remarks
5. Enter interface view. interface interface-type
interface-number N/A
6. Configure the minimum
interval for receiving BFD
echo packets.
bfd min-echo-receive-interval
value
Optional.
For more information, see the
description of the Required Min
Echo RX Interval field in "BFD
packet format."
7. Configure the minimum
interval for transmitting BFD
control packets.
bfd min-transmit-interval value
Optional.
For more information, see the
description of the Desired Min TX
Interval field in "BFD packet
format."
8. Configure the minimum
interval for receiving BFD
control packets.
bfd min-receive-interval value
Optional.
For more information, see the
description of the Required Min RX
Interval field in "BFD packet
format."
9. Configure the detection time
multiplier. bfd detect-multiplier value
Optional.
For more information, see the
description of the Detect Mult field
in "BFD packet format."
5by default.
10. Configure the authentication
mode on the interface.
bfd authentication-mode { md5
key-id [ cipher ] key |sha1 key-id
[ cipher ] key | simple key-id
[ cipher ] password }
Optional.
By default, the interface does not
authenticate BFD packets.
In Figure 1, if you configure the Desired Min TX Interval as 100 milliseconds, Required Min RX Interval as
300 milliseconds, and Detect Mult as 5 on Router A, and then configure the Desired Min TX Interval as
200 milliseconds, Required Min RX Interval as 400 milliseconds, and Detect Mult as 10 on Router B:
•The actual transmitting interval on Router A is 400 milliseconds, which is the greater value between
the minimum interval for transmitting BFD control packets on Router A (100 milliseconds) and the
minimum interval for receiving BFD control packets on Router B (400 milliseconds).
•The actual transmitting interval on Router B is 300 milliseconds, which is the greater value between
the minimum interval for transmitting BFD control packets on Router B (200 milliseconds) and the
minimum interval for receiving BFD control packets on Router A (300 milliseconds).
•The actual detection time on Router A is 3000 milliseconds, which is 10 × 300 milliseconds (Detect
Mult on Router B × actual transmitting interval on Router B).
•The actual detection time on Router B is 2000 milliseconds, which is 5 × 400 milliseconds (Detect
Mult on Router A × actual transmitting interval on Router A).
Enabling trap
When the trap function is enabled on the BFD module, the module will generate trap messages at the
notifications level to report the important events of the module. The generated trap messages are sent to
the device's information center, which determines the output rules for the trap messages (whether to

11
output the trap messages and the output destinations). For the information center configuration, see
Network Management and Monitoring Configuration Guide.
To enable BFD trap:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enable BFD trap. snmp-agent trap enable bfd
Optional.
Enabled by default.
For more information about the
command, see the snmp-agent
trap enable command in Network
Management and Monitoring
Command Reference.
Displaying and maintaining BFD
Task Command Remarks
Display information about
BFD-enabled interfaces.
display bfd interface [ verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about enabled
BFD debugging.
display bfd debugging-switches [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display BFD session information.
display bfd session [ verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Clear BFD session statistics. reset bfd session statistics Available in user view.

12
Configuring interface backup
Overview
Interface backup increases network reliability. The active interface transmits services, and the standby
interfaces are in the backup state. When the active interface fails or the link fails, or when the traffic on
the active interface exceeds the configured threshold, a standby interface is activated to transmit
services.
As shown in Figure 4, interfaces Serial 2/0, Serial 2/1, and Serial 2/2 on Router A back up each other.
Serial 2/0 transmits data, and Serial 2/1 and Serial 2/2 are standby interfaces that have different
priorities.
Figure 4 Diagram for interface backup
When interface Serial 2/0 or its link to Router B fails, or when the traffic on Serial 2/0 exceeds the
configured threshold, the standby interface with the highest priority is activated, ensuring uninterrupted
data transmission.
Active and standby interfaces
In interface backup, an interface can be an active interface or standby interface. Interfaces that can
serve as active or standby interfaces are: Layer 3 Ethernet interfaces, Layer 3 Ethernet subinterfaces,
synchronous serial interfaces, asynchronous serial interfaces, AM interfaces, AUX ports,
WLAN-ETHERNET interfaces, dialer interfaces, ISDN BRI interfaces, Layer 3 VE interfaces, ATM
interfaces, POS interfaces, Tunnel interfaces, USB 3G Modem interfaces, and MP-group interfaces.
Active interface—An active interface transmits data, and can be configured with up to three standby
interfaces (for example, Serial 2/0 in Figure 4). Up to 10 active interfaces can be configured on a
device.
•When a Dialer interface acts as the PPPoE client and the PPPoE session operates in permanent
on-line mode, it can be configured as the active interface.
•When a BRI interface is used for the ISDN leased line, it can be configured as the active interface.
Standby interface—Standby interfaces function as backups for active interfaces (for example, interfaces
Serial 2/1 and Serial 2/2 in Figure 4), which are generally idle. One standby interface can only back
up one active interface.

13
How interface backup works
Interface backup operates in active/standby mode or in load balancing mode.
Active/standby mode
As shown in Figure 5, interface Serial 2/0 on Router A acts as the active interface and interfaces Serial
2/1 and Serial 2/2 act as the standby interfaces.
Figure 5 Diagram for active/standby mode
In active/standby mode, only one interface transmits data at any given time.
•When the active interface is operating correctly, even if the traffic is overloaded, the standby
interface is in a backup state. All traffic is transmitted by the active interface.
•If the active interface fails, the standby interface with highest priority takes over to transmit data.
•When the active interface is restored, it resumes data transmission.
Load balancing mode
As shown in Figure 6, interface Serial 2/0 on Router A acts as the active interface, and interfaces Serial
2/1 and Serial 2/2 act as the standby interfaces.
Figure 6 Diagram for load balancing mode
In load balancing mode, you can set an upper threshold (enable-threshold) and a lower threshold
(disable-threshold). Traffic can be shared among multiple interfaces:
•When the traffic on the active interface exceeds the predefined enable-threshold, the highest
priority standby interface is activated. Other standby interfaces are activated in descending priority
order if exceeding traffic still exists.
•When the traffic on the active interface decreases below the predefined disable-threshold, the
system shuts down the lowest priority standby interface first and then shuts down the other standby
interfaces in ascending priority order depending on traffic size.
S2/2

14
NOTE:
A
dopt active/standby or load balancin
g
mode dependin
g
on whether you have confi
g
ured an upper or
lower threshold for the active interface traffic. If this threshold is configured, load balancing mode is
adopted. Otherwise, active/standby mode is adopted.
Interface backup configuration task list
Task Remarks
Configuring interface backup Configuring active/standby mode Optional
Associating an interface with a track entry
Configuring load balancing Optional
Configuring the delay timer for the backup function to take effect on system startup Optional
Configuring interface backup
You can configure interface backup through active/standby mode or association between an interface
and a track entry, but you cannot configure them at the same time.
Configuring active/standby mode
You can configure multiple standby interfaces for one active interface. The standby interfaces are
activated depending on their priority, with the highest priority being activated first.
To prevent frequent interface switchover as a result of interface instability, you can configure a switchover
delay. A standby interface then takes over only if the active interface remains down upon expiration of
the delay.
Follow these guidelines when you configure active/standby mode:
•To configure multiple standby interfaces for an active interface, execute the standby interface
command repeatedly.
•You can use the ip route-static command in system view to configure the routes for reaching a
destination network through the active interface and its standby interfaces. For more information
about the command, see Layer 3—IP Routing Command Reference.
•If multiple standby interfaces have the same priority, when the active interface is down, the standby
interface configured first is selected.
To configure active/standby mode:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter interface view. interface interface-type
interface-number N/A

15
Ste
p
Command Remarks
3. Specify a standby
interface for the active
interface.
standby interface
interface-type
interface-number [ priority ]
By default, no standby interface is specified
for the active interface.
4. Set switchover delays. standby timer delay
enable-delay disable-delay
Optional.
Both thresholds are 0 by default, indicating
immediate switchover without delay.
Associating an interface with a track entry
You can associate a standby interface with a track entry to enable the interface to monitor the state of the
active interface through the track entry and change the backup state of the interface accordingly.
•If the state of the track entry is positive, the link connecting the active interface is normal and the
standby interface stays in the backup state.
•If the state of the track entry is negative, the link connecting the active interface is not functioning
correctly. The standby interface becomes the active interface to transmit data.
•When you associate an interface with a track entry, if the track entry is invalid, the interface keeps
its forwarding state. After your configuration, if the state of the track entry changes to invalid, the
standby interface will become the active interface.
Follow these guidelines when you associate an interface with a track entry:
•One interface can be associated with one track entry only. If you repeatedly execute the standby
track command, the latter configuration overwrites the previous one.
•The track entry associated with an interface can be one you have not created yet. After you create
a track entry with the track command, the association takes effect.
•For more information about the Track module, see "Configuring Track."
To associate an interface with a track entry:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter interface view. interface interface-type
interface-number N/A
3. Associate an interface with a
track entry. standby track track-entry-number By default, an interface is not
associated with a track entry.
Configuring load balancing
Interface backup detects the data traffic on the active interface to determine whether to bring up or shut
down the standby interface.
When multiple standby interfaces are assigned the same priority, they are brought up or shut down
depending on the order they are configured:
•The standby interface configured first is used first to participate in load balancing with the active
interface.

16
•The standby interface configured later is shut down first and exits load balancing with the active
interface.
IMPORTANT:
W
hen you use the load balancing function, use the undo ip fast-forwarding command to disable fast
forwarding on both the active interface and the standby interfaces. For more information about the undo
ip fast-forwarding command, see
Layer 3—IP Services Command Reference .
To configure load balancing:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter active interface view. interface interface-type
interface-number N/A
3. Configure the available
bandwidth used for setting the
thresholds.
standby bandwidth size Optional.
0 kbps by default.
4. Configure load balancing
thresholds.
standby threshold
enable-threshold disable-threshold
No load balancing thresholds are
configured by default.
5. Configure the interval for
detecting traffic size on the
active interface.
standby timer flow-check interval Optional.
30 seconds by default.
Configuring the delay timer for the backup function
to take effect on system startup
Generally, HP recommends that you use the default settings for the devices supporting this feature. If you
set a too short timer, the standby interfaces will be activated and deactivated in a short time on system
startup; if you set a too long timer, when the active interface fails, the standby interfaces take too long
time to take effect on system startup.
This feature takes effect on all the standby interfaces working in active/standby mode, but does not take
effect on the standby interfaces working in load balancing mode.
The device restores its configuration when starting up. If the device is configured with the backup function,
during the configuration restoration process, the system enables the delay timer for the backup function
to take effect on system startup, because the status of all the interfaces is down. If the delay timer times
out, but the active interface is not up (because the cables are not well connected, or parameter
negotiation is being performed), the system will activate a standby interface to start interface backup.
When the active interface is up, the system will disable the standby interface, and set its status to down.
To avoid activation and deactivation (up and down) of the standby interfaces in a short time on system
startup, you can modify the delay timer for the backup function to take effect on system startup, so that the
standby interfaces will be activated only when the delay timer times out and the active interface is not up.
To set the delay timer for the backup function to take effect on system startup:
Ste
p
Command Remarks
1. Enter system view. system-view N/A