HP FlexFabric 12900 Switch Series

HP FlexFabric 12900 Switch Series
High Availability
Configuration Guide
Part number: 5998-5209
Software version: R1106 and later
Document version: 6W100-20140124
Legal and notice information
© Copyright 2014 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.
Contents
Configuring DLDP ························································································································································· 1 Overview············································································································································································ 1 Basic concepts ·························································································································································· 2 How DLDP works ······················································································································································ 3 Configuration restrictions and guidelines ······················································································································· 5 DLDP configuration task list ·············································································································································· 5 Enabling DLDP ··································································································································································· 5 Setting the interval to send advertisement packets ········································································································ 6 Setting the DelayDown timer ··········································································································································· 6 Setting the port shutdown mode ······································································································································ 6 Configuring DLDP authentication····································································································································· 7 Displaying and maintaining DLDP··································································································································· 7 DLDP configuration examples ·········································································································································· 8 Automatically shutting down unidirectional links ·································································································· 8 Manually shutting down unidirectional links ······································································································ 11 Configuring VRRP ······················································································································································· 15 Overview········································································································································································· 15 VRRP standard mode ····················································································································································· 16 Router priority in a VRRP group ··························································································································· 16 Preemption ····························································································································································· 16 Authentication method ·········································································································································· 17 VRRP timers ···························································································································································· 17 Master election ······················································································································································ 18 VRRP tracking ························································································································································· 18 VRRP application ··················································································································································· 18 Protocols and standards ················································································································································ 20 Configuring IPv4 VRRP ·················································································································································· 20 IPv4 VRRP configuration task list ·························································································································· 20 Specifying the IPv4 VRRP version ························································································································ 20 Creating a VRRP group and assigning a virtual IP address ············································································· 20 Configuring the router priority, preemptive mode, and tracking function ······················································ 21 Configuring IPv4 VRRP packet attributes ············································································································ 22 Enabling SNMP notifications for VRRP················································································································ 23 Disabling an IPv4 VRRP group ····························································································································· 23 Displaying and maintaining IPv4 VRRP··············································································································· 24 IPv4 VRRP configuration examples ······························································································································· 24 Single VRRP group configuration example ········································································································· 24 Multiple VRRP groups configuration example ···································································································· 27 Troubleshooting VRRP ···················································································································································· 29 An error prompt is displayed ······························································································································· 29 Multiple masters appear in a VRRP group ·········································································································· 30 Fast VRRP state flapping ······································································································································· 30 Configuring BFD ························································································································································· 31 Overview········································································································································································· 31 BFD session establishment ···································································································································· 31 BFD session modes and operating modes ·········································································································· 31 Supported features ················································································································································ 32 Protocols and standards ······································································································································· 32 i
Configuring BFD basic functions ·································································································································· 33 Configuring echo packet mode ··························································································································· 33 Configuring control packet mode ························································································································ 33 Displaying and maintaining BFD·································································································································· 35 Configuring Track ······················································································································································ 36 Overview········································································································································································· 36 Collaboration fundamentals ································································································································· 36 Collaboration application example····················································································································· 37 Track configuration task list··········································································································································· 37 Associating the Track module with a detection module ····························································································· 38 Associating Track with NQA ······························································································································· 38 Associating Track with BFD ·································································································································· 38 Associating Track with interface management··································································································· 39 Associating the Track module with an application module ······················································································· 40 Associating Track with VRRP ································································································································ 40 Associating Track with static routing ··················································································································· 41 Associating Track with PBR ·································································································································· 42 Displaying and maintaining track entries ···················································································································· 43 Track configuration examples ······································································································································· 43 VRRP-Track-NQA collaboration configuration example ···················································································· 43 Configuring BFD for a VRRP backup to monitor the master·············································································· 47 Configuring BFD for the VRRP master to monitor the uplinks············································································ 50 Static routing-Track-BFD collaboration configuration example ········································································· 53 VRRP-Track-interface management collaboration configuration example ······················································· 57 Support and other resources ····································································································································· 60 Contacting HP ································································································································································ 60 Subscription service ·············································································································································· 60 Related information ························································································································································ 60 Documents ······························································································································································ 60 Websites································································································································································· 60 Conventions ···································································································································································· 61 Index ··········································································································································································· 63 ii
Configuring DLDP
Overview
Unidirectional links occur when one end of a link can receive packets from the other end, but the other
end cannot receive packets sent by the first end.
Unidirectional fiber links include the following types:
•
Occur when fibers are cross-connected.
•
Occur when a fiber is not connected at one end or when one fiber of a fiber pair gets broken.
Figure 1 shows a correct fiber connection and the two types of unidirectional fiber connections.
Figure 1 Correct and incorrect fiber connections
Physical layer detection mechanisms, such as auto-negotiation, can detect physical signals and faults.
They cannot detect communication failures for unidirectional links where the physical layer state is
connected.
As a data link layer protocol, the Device Link Detection Protocol (DLDP) detects whether the fiber link or
twisted-pair link is correctly connected at the link layer, and whether the two ends can exchange packets
correctly. When DLDP detects unidirectional links, it can automatically shut down the faulty port to avoid
network problems. Alternatively, a user can manually shut down the faulty port. DLDP cooperates with
physical layer protocols to monitor link status and avoid physical and logical unidirectional links.
1
Basic concepts
DLDP neighbor states
If port A and B are on the same link and port A can receive link-layer packets from port B, port B is a
DLDP neighbor of port A. Two ports that can exchange packets are neighbors.
Table 1 DLDP neighbor states
DLDP timer
Description
Confirmed
The link to a DLDP neighbor is bidirectional.
Unconfirmed
The state of the link to a newly discovered neighbor is not determined.
DLDP port states
A DLDP-enabled port is called a "DLDP port." A DLDP port can have multiple neighbors, and its state
depends on the DLDP neighbor state.
Table 2 DLDP port states
State
Description
Initial
DLDP is enabled on the port, but is disabled globally.
Inactive
DLDP is enabled on the port and globally, and the link is physically down.
Bidirectional
DLDP is enabled on the port and globally, and at least one neighbor in Confirmed
state exists.
Unidirectional
DLDP is enabled on the port and globally, and no neighbor in Confirmed state
exists. In this state, a port does not send or receive packets other than DLDP
packets any more.
DLDP timers
Table 3 DLDP timers
DLDP timer
Description
Advertisement timer
Advertisement packet sending interval (the default is 5 seconds and is
configurable).
Probe timer
Probe packet sending interval. This timer is set to 1 second.
Echo timer
The Echo timer is triggered when a probe is launched for a new neighbor. This
timer is set to 10 seconds.
Entry timer
When a new neighbor joins, a neighbor entry is created and the corresponding
entry timer is triggered if the neighbor is in Confirmed state. When an
Advertisement is received, the device updates the corresponding neighbor entry
and the Entry timer.
The setting of an Entry timer is three times that of the Advertisement timer.
Enhanced timer
The Enhanced timer is triggered, together with the Echo timer, when the Entry timer
expires. Enhanced timer is set to 1 second.
2
DLDP timer
DelayDown timer
RecoverProbe timer
Description
If a port is physically down, the device triggers the DelayDown timer (the default
is 1 second and is configurable), rather than removing the corresponding
neighbor entry.
When the DelayDown timer expires, the device removes the corresponding DLDP
neighbor information if the port is down, and does not perform any operation if
the port is up.
This timer is set to 2 seconds. A port in the Unidirectional state regularly sends
RecoverProbe packets to detect whether a unidirectional link has been restored to
bidirectional.
DLDP authentication mode
You can use DLDP authentication to prevent network attacks and illegal detecting.
Table 4 DLDP authentication mode
Authentication
mode
Processing at the DLDP packet sending side
Non-authentication
The sending side sets the Authentication field of DLDP
packets to 0.
Plaintext
authentication
The sending side sets the Authentication field to the
password configured in plain text.
MD5
authentication
The sending side encrypts the user configured password
using MD5 algorithm, assigns the digest to the
Authentication field.
Processing at the DLDP
packet receiving side
The receiving side checks
the authentication
information of received
DLDP packets and drops
packets where the
authentication
information conflicts with
the local configuration.
How DLDP works
Detecting one neighbor
When two devices are connected through an optical fiber or network cable, enable DLDP to detect
unidirectional links to the neighbor. The following illustrates the unidirectional link detection process in
two cases:
•
Unidirectional links occur before you enable DLDP.
Figure 2 Cross-connected fibers
As shown in Figure 2, before you enable DLDP, the optical fibers between Device A and Device B
are cross-connected. After you enable DLDP, the four ports are all up and in Unidirectional state,
and they send RecoverProbe packets. Take Port 1 as an example to illustrate the unidirectional link
detection process:
3
a. Port 1 receives the RecoverProbe packet from Port 4, and returns a RecoverEcho packet.
b. Port 4 cannot receive any RecoverEcho packet from Port 1, so Port 4 cannot become the
neighbor of Port 1.
c. Port 3 can receive the RecoverEcho packet from Port 1, but Port 3 is not the intended
destination, so Port 3 cannot become the neighbor of Port 1.
The same process occurs on the other three ports. The four ports are all in Unidirectional state.
•
Unidirectional links occur after you enable DLDP.
Figure 3 Broken fiber
Device A
Device B
Port 1
Port 2
Port 1
Port 2
Correct fiber
connection
Device A
Device B
One fiber is
broken
Ethernet
fiber port
Tx end
Rx end
Fiber link
Broken fiber
As shown in Figure 3, Device and Device B are connected through an optical fiber. After you
enable DLDP, Port 1 and Port 2 establish the bidirectional neighborship in the following way:
a. Port 1 that is physically up enters the Unidirectional state and sends a RecoverProbe packet.
b. After receiving the RecoverProbe packet, Port 2 returns a RecoverEcho packet.
c. After Port 1 receives the RecoverEcho packet and detects that the neighbor information in the
packet matches the local information, Port 1 establishes the neighborship with Port 2 and
transits to the Bidirectional state. Port 1 then starts the Entry timer and periodically sends
Advertisement packets.
d. After Port 2 receives the Advertisement packet, it establishes the Unconfirmed neighborship
with Port 1. Port 2 then starts the Echo timer and Probe timer, and periodically sends Probe
packets.
e. After receiving the Probe packet, Port 1 returns an Echo packet.
f. After Port 2 receives the Echo packet and detects that the neighbor information in the packet
matches the local information, the neighbor state of Port 1 becomes Confirmed. Port 2 then
transits to the Bidirectional state, starts the Entry timer, and periodically sends Advertisement
packets.
The bidirectional neighborship between Port 1 and Port 2 is now established.
After that, when Port 2's Rx end fails to receive signals, Port 2 is physically down and enters the
Inactive state. Because Port 2's Tx end can still send signals to Port 1, Port 1 stays up. After the
Entry timer for Port 2 expires, Port 1 starts the Enhanced timer and Echo timer, and sends a probe
packet to Port 2. Because Port 1's Tx line is broken, Port 1 cannot receive the Echo packet from Port
2 after the Echo timer expires. Port 1 then enters the Unidirectional state, and sends a Disable
4
packet to Port 2. At the same time, Port 1 deletes the neighborship with Port 2, and starts the
RecoverProbe timer. Port 2 stays in Inactive state during this process.
Detecting multiple neighbors
When multiple devices are connected through a hub, enable DLDP on all interfaces connected to the hub
to detect unidirectional links among the neighbors. When no Confirmed neighbor exists, an interface
enters the Unidirectional state.
Figure 4 Network diagram
As shown in Figure 4, Device A through Device D are connected through a hub, and enabled with DLDP.
When Port 1, Port 2, and Port 3 detect that the link to Port 4 fails, they deletes the neighborship with Port
4, but stay in Bidirectional state.
Configuration restrictions and guidelines
For DLDP to operate correctly, enable DLDP on both sides and make sure these settings are consistent: the
interval to send Advertisement packets, DLDP authentication mode, and password.
DLDP configuration task list
Tasks at a glance
(Required.) Enabling DLDP
(Optional.) Setting the interval to send advertisement packets
(Optional.) Setting the DelayDown timer
(Optional.) Setting the port shutdown mode
(Optional.) Configuring DLDP authentication
Enabling DLDP
To correctly configure DLDP on the device, you must enable DLDP globally and on each port.
5
To enable DLDP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable DLDP globally.
dldp global enable
By default, DLDP is globally
disabled.
3.
Enter Layer 2 or Layer 3
Ethernet interface view.
interface interface-type
interface-number
N/A
4.
Enable DLDP.
dldp enable
By default, DLDP is disabled on an
interface.
Setting the interval to send advertisement packets
To make sure DLDP can detect unidirectional links before network performance deteriorates, set the
advertisement interval appropriate for your network environment. (HP recommends using the default
interval.)
To set the Advertisement packet sending interval:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the interval to send
Advertisement packets.
dldp interval time
The default is 5 seconds.
Setting the DelayDown timer
On some ports, when the Tx line fails, the port goes down and then comes up again, causing optical
signal jitters on the Rx line. To avoid this problem, when a port goes down due to a Tx failure, the device
triggers the DelayDown timer to prevent the corresponding neighbor entries from being removed. If the
port remains down when the timer expires, the device removes the DLDP neighbor information. If the port
goes up, the device takes no action.
To set the DelayDown timer:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Set the DelayDown timer.
dldp delaydown-timer time
The default is 1 second.
The DelayDown timer setting
applies to all DLDP-enabled ports.
Setting the port shutdown mode
On detecting a unidirectional link, the ports can be shut down in one of the following modes:
6
•
Auto mode—When a unidirectional link is detected, DLDP changes the DLDP port state to
Unidirectional. The unidirectional port periodically sends RecoverProbe packets. When a correct
RecoverEcho packet is received, the link is restored to a bidirectional link, and the port state
changes from Unidirectional to Bidirectional. This process is called "link auto-recovery
mechanism."
•
Manual mode—When a unidirectional link is detected, DLDP does not shut down the port, and you
need to manually shut it down. When the link state is restored to Bidirectional, you must manually
bring up the port. If the network performance is low, the device is busy, or the CPU usage is high,
use this mode to prevent normal links from being shut down because of false unidirectional link
reports.
To set port shutdown mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set port shutdown mode.
dldp unidirectional-shutdown
{ auto | manual }
The default mode is auto.
Configuring DLDP authentication
You can guard your network against attacks and malicious probes by configuring an appropriate DLDP
authentication mode, which can be plain text authentication or MD5 authentication. If your network is
safe, you can choose not to authenticate.
To configure DLDP authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure a DLDP
authentication mode.
dldp authentication-mode { md5 |
none | simple }
The default authentication mode is
none.
By default, no password is
configured for DLDP
authentication.
3.
Configure the password for
DLDP authentication.
dldp authentication-password
{ cipher cipher | simple simple }
If you do not configure the
authentication password after you
configure the authentication mode,
the authentication mode is none no
matter which authentication mode
you configure.
Displaying and maintaining DLDP
Execute display commands in any view and the reset command in user view.
Task
Command
Display the DLDP configuration globally and of a port.
display dldp [ interface interface-type
interface-number ]
7
Task
Command
Display the statistics on DLDP packets passing through
a port.
display dldp statistics [ interface interface-type
interface-number ]
Clear the statistics on DLDP packets passing through a
port.
reset dldp statistics [ interface interface-type
interface-number ]
DLDP configuration examples
Automatically shutting down unidirectional links
Network requirements
As shown in Figure 5, Device A and Device B are connected with two fiber pairs.
Configure DLDP to automatically shut down the faulty port upon detecting a unidirectional link, and
automatically bring up the port after you clear the fault.
Figure 5 Network diagram
Configuration procedure
1.
Configure Device A:
# Enable DLDP globally.
<DeviceA> system-view
[DeviceA] dldp global enable
# Enable DLDP on FortyGigE 1/0/1.
[DeviceA] interface fortygige 1/0/1
[DeviceA-FortyGigE1/0/1] dldp enable
[DeviceA-FortyGigE1/0/1] quit
# Enable DLDP on FortyGigE 1/0/2.
[DeviceA] interface fortygige 1/0/2
[DeviceA-FortyGigE1/0/2] dldp enable
[DeviceA-FortyGigE1/0/2] quit
# Set the port shutdown mode to auto.
[DeviceA] dldp unidirectional-shutdown auto
2.
Configure Device B:
# Enable DLDP globally.
<DeviceB> system-view
[DeviceB] dldp global enable
8
# Enable DLDP on FortyGigE 1/0/1.
[DeviceB] interface fortygige 1/0/1
[DeviceB-FortyGigE1/0/1] dldp enable
[DeviceB-FortyGigE1/0/1] quit
# Enable DLDP on FortyGigE 1/0/2.
[DeviceB] interface fortygige 1/0/2
[DeviceB-FortyGigE1/0/2] dldp enable
[DeviceB-FortyGigE1/0/2] quit
# Set the port shutdown mode to auto.
[DeviceB] dldp unidirectional-shutdown auto
3.
Verify the configuration:
After the configurations are complete, you can use the display dldp command to display the DLDP
configuration globally and on ports.
# Display the DLDP configuration globally and on all the DLDP-enabled ports of Device A.
[DeviceA] display dldp
DLDP global status: Enabled
DLDP advertisement interval: 5s
DLDP authentication-mode: None
DLDP unidirectional-shutdown mode: Auto
DLDP delaydown-timer value: 1s
Number of enabled ports: 2
Interface FortyGigE1/0/1
DLDP port state: Bidirectional
Number of the port’s neighbors: 1
Neighbor MAC address: 0023-8956-3600
Neighbor port index: 1
Neighbor state: Confirmed
Neighbor aged time: 11s
Interface FortyGigE1/0/2
DLDP port state: Bidirectional
Number of the port’s neighbors: 1
Neighbor MAC address: 0023-8956-3600
Neighbor port index: 2
Neighbor state: Confirmed
Neighbor aged time: 12s
The output shows that both FortyGigE 1/0/1 and FortyGigE 1/0/2 are in Bidirectional state,
which means both links are bidirectional.
# Enable the monitoring of logs on the current terminal on Device A, and set the lowest level of the
logs that can be output to the current terminal to 6.
[DeviceA] quit
<DeviceA> terminal monitor
<DeviceA> terminal logging level 6
The following log information is displayed on Device A:
<DeviceA>%Jul 11 17:40:31:089 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/1 link
status is DOWN.
9
%Jul 11 17:40:31:091 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/1 is DOWN.
%Jul 11 17:40:31:677 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
DOWN.
%Jul 11 17:40:31:678 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/2 is DOWN.
%Jul 11 17:40:38:544 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/1 link status is
UP.
%Jul 11 17:40:38:836 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
UP.
The output shows that the port status of both FortyGigE 1/0/1 and FortyGigE 1/0/2 is down and
then up, but the link status of them is always down.
# Display the DLDP configuration globally and of all the DLDP-enabled ports.
<DeviceA> display dldp
DLDP global status: Enabled
DLDP advertisement interval: 5s
DLDP authentication-mode: None
DLDP unidirectional-shutdown mode: Auto
DLDP delaydown-timer value: 1s
Number of enabled ports: 2
Interface FortyGigE1/0/1
DLDP port state: Unidirectional
Number of the port’s neighbors: 0 (Maximum number ever detected: 1)
Interface FortyGigE1/0/2
DLDP port state: Unidirectional
Number of the port’s neighbors: 0 (Maximum number ever detected: 1)
The output shows that the DLDP port status of both FortyGigE 1/0/1 and FortyGigE 1/0/2 is
unidirectional, which indicates that DLDP detects unidirectional links on them and automatically
shuts down the two ports.
The unidirectional links are caused by cross-connected fibers. Correct the fiber connections. As a
result, the ports shut down by DLDP automatically recover, and Device A displays the following log
information:
<DeviceA>%Jul 11 17:42:57:709 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/1 link
status is DOWN.
%Jul 11 17:42:58:603 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
DOWN.
%Jul 11 17:43:02:342 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/1 link status is
UP.
%Jul 11 17:43:02:343 2013 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was
confirmed on interface FortyGigE1/0/1. The neighbor's system MAC is 0023-8956-3600,
and the port index is 1.
%Jul 11 17:43:02:344 2013 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a
bidirectional link on interface FortyGigE1/0/1.
%Jul 11 17:43:02:353 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/1 is UP.
%Jul 11 17:43:02:357 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
UP.
10
%Jul 11 17:43:02:362 2013 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was
confirmed on interface FortyGigE1/0/2. The neighbor's system MAC is 0023-8956-3600,
and the port index is 2.
%Jul 11 17:43:02:362 2013 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a
bidirectional link on interface FortyGigE1/0/2.
%Jul 11 17:43:02:368 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/2 is UP.
The output shows that the port status and link status of both FortyGigE 1/0/1 and FortyGigE
1/0/2 are now up and their DLDP neighbors are determined.
Manually shutting down unidirectional links
Network requirements
As shown in Figure 6, Device A and Device B are connected with two fiber pairs.
Configure DLDP to detect unidirectional links. When a unidirectional link is detected, the administrator
must manually shut down the port.
Figure 6 Network diagram
Configuration procedure
1.
Configure Device A:
# Enable DLDP globally.
<DeviceA> system-view
[DeviceA] dldp enable
# Enable DLDP on FortyGigE 1/0/1.
[DeviceA] interface fortygige 1/0/1
[DeviceA-FortyGigE1/0/1] dldp enable
[DeviceA-FortyGigE1/0/1] quit
# Enable DLDP on FortyGigE 1/0/2.
[DeviceA] interface fortygige 1/0/2
[DeviceA-FortyGigE1/0/2] dldp enable
[DeviceA-FortyGigE1/0/2] quit
# Set the port shutdown mode to manual.
[DeviceA] dldp unidirectional-shutdown manual
2.
Configure Device B:
# Enable DLDP globally.
<DeviceB> system-view
[DeviceB] dldp global enable
# Enable DLDP on FortyGigE 1/0/1.
11
[DeviceB] interface fortygige 1/0/1
[DeviceB-FortyGigE1/0/1] dldp enable
[DeviceB-FortyGigE1/0/1] quit
# Enable DLDP on FortyGigE 1/0/2.
[DeviceB] interface fortygige 1/0/2
[DeviceB-FortyGigE1/0/2] dldp enable
[DeviceB-FortyGigE1/0/2] quit
# Set the port shutdown mode to manual.
[DeviceB] dldp unidirectional-shutdown manual
3.
Verify the configuration:
After the configurations are complete, you can use the display dldp command to display the DLDP
configuration globally and on ports.
# Display the DLDP configuration globally and on all the DLDP-enabled ports of Device A.
[DeviceA] display dldp
DLDP global status: Enabled
DLDP advertisement interval: 5s
DLDP authentication-mode: None
DLDP unidirectional-shutdown mode: Manual
DLDP delaydown-timer value: 1s
Number of enabled ports: 2
Interface FortyGigE1/0/1
DLDP port state: Bidirectional
Number of the port’s neighbors: 1
Neighbor MAC address: 0023-8956-3600
Neighbor port index: 1
Neighbor state: Confirmed
Neighbor aged time: 11s
Interface FortyGigE1/0/2
DLDP port state: Bidirectional
Number of the port’s neighbors: 1
Neighbor MAC address: 0023-8956-3600
Neighbor port index: 2
Neighbor state: Confirmed
Neighbor aged time: 12s
The output shows that both FortyGigE 1/0/1 and FortyGigE 1/0/2 are in Bidirectional state,
which means both links are bidirectional.
# Enable the monitoring of logs on the current terminal on Device A, and set the lowest level of the
logs that can be output to the current terminal to 6.
[DeviceA] quit
<DeviceA> terminal monitor
<DeviceA> terminal logging level 6
The following log information is displayed on Device A:
<DeviceA>%Jul 12 08:29:17:786 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/1 link
status is DOWN.
12
%Jul 12 08:29:17:787 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/1 is DOWN.
%Jul 12 08:29:17:800 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
DOWN.
%Jul 12 08:29:17:800 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/2 is DOWN.
%Jul 12 08:29:25:004 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/1 link status is
UP.
%Jul 12 08:29:25:005 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/1 is UP.
%Jul 12 08:29:25:893 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
UP.
%Jul 12 08:29:25:894 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/2 is UP.
The output shows that the port status and link status of both FortyGigE 1/0/1 and FortyGigE
1/0/2 are down and then up.
# Display the DLDP configuration globally and of all the DLDP-enabled ports.
<DeviceA> display dldp
DLDP global status: Enabled
DLDP advertisement interval: 5s
DLDP authentication-mode: None
DLDP unidirectional-shutdown mode: Manual
DLDP delaydown-timer value: 1s
Number of enabled ports: 2
Interface FortyGigE1/0/1
DLDP port state: Unidirectional
Number of the port’s neighbors: 0 (Maximum number ever detected: 1)
Interface FortyGigE1/0/2
DLDP port state: Unidirectional
Number of the port’s neighbors: 0 (Maximum number ever detected: 1)
The output shows that the DLDP port status of both FortyGigE 1/0/1 and FortyGigE 1/0/2 is
unidirectional, which indicates that DLDP detects unidirectional links on them but does not shut
down the two ports.
The unidirectional links are caused by cross-connected fibers. Manually shut down the two ports:
# Shut down FortyGigE 1/0/1.
<DeviceA> system-view
[DeviceA] interface fortygige 1/0/1
[DeviceA-FortyGigE1/0/1] shutdown
The following log information is displayed on Device A:
[DeviceA-FortyGigE1/0/1]%Jul 12 08:34:23:717 2013 DeviceA IFNET/3/PHY_UPDOWN:
FortyGigE1/0/1 link status is DOWN.
%Jul 12 08:34:23:718 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/1 is DOWN.
%Jul 12 08:34:23:778 2013 DeviceA IFNET/3/PHY_UPDOWN: FortyGigE1/0/2 link status is
DOWN.
%Jul 12 08:34:23:779 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/2 is DOWN.
13
The output shows that the port status and link status of both FortyGigE 1/0/1 and FortyGigE
1/0/2 are now down.
# Shut down FortyGigE 1/0/2.
[DeviceA-FortyGigE1/0/1] quit
[DeviceA] interface fortygige 1/0/2
[DeviceA-FortyGigE1/0/2] shutdown
Correct the fiber connections and bring up the two ports:
# Bring up FortyGigE 1/0/2.
[DeviceA-FortyGigE1/0/2] undo shutdown
The following log information is displayed on Device A:
[DeviceA-FortyGigE1/0/2]%Jul 12 08:46:17:677 2013 DeviceA IFNET/3/PHY_UPDOWN:
FortyGigE1/0/2 link status is UP.
%Jul 12 08:46:17:678 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/2 is UP.
%Jul 12 08:46:17:959 2013 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was
confirmed on interface FortyGigE1/0/2. The neighbor's system MAC is 0023-8956-3600,
and the port index is 2.
%Jul 12 08:46:17:959 2013 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a
bidirectional link on interface FortyGigE1/0/2.
The output shows that the port status and link status of FortyGigE 1/0/2 are now up and its DLDP
neighbors are determined.
# Bring up FortyGigE 1/0/1.
[DeviceA-FortyGigE1/0/2] quit
[DeviceA] interface fortygige 1/0/1
[DeviceA-FortyGigE1/0/1] undo shutdown
The following log information is displayed on Device A:
[DeviceA-FortyGigE1/0/1]%Jul 12 08:48:25:952 2013 DeviceA IFNET/3/PHY_UPDOWN:
FortyGigE1/0/1 link status is UP.
%Jul 12 08:48:25:952 2013 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was
confirmed on interface FortyGigE1/0/1. The neighbor's system MAC is 0023-8956-3600,
and the port index is 1.
%Jul 12 08:48:25:953 2013 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface
FortyGigE1/0/1 is UP.
%Jul 12 08:48:25:953 2013 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a
bidirectional link on interface FortyGigE1/0/1.
The output shows that the port status and link status of FortyGigE 1/0/1 are now up and its DLDP
neighbors are determined.
14
Configuring VRRP
The term "interface" in this chapter refers to Layer 3 Ethernet interfaces, and VLAN interfaces. You can
configure an Ethernet port as a Layer 3 interface by using the port link-mode route command (see Layer
2—LAN Switching Configuration Guide).
Overview
Typically, you can configure a default gateway for every host on a LAN. All packets destined for other
networks are sent through the default gateway. As shown in Figure 7, when the default gateway fails, no
hosts can communicate with external networks.
Figure 7 LAN networking
Using a default gateway facilitates your configuration but requires high availability. Using more egress
gateways improves link availability but introduces the problem of routing among the egresses.
Virtual Router Redundancy Protocol (VRRP) is designed to address this issue. VRRP adds a group of
network gateways to a VRRP group called a "virtual router." A VRRP group comprises one master and
multiple backups, but has only one virtual IP address. The hosts on the subnet only need to configure this
virtual IP address as their default network gateway for communicating with external networks.
The virtual IP address of the virtual router can be either an unused IP address on the subnet where the
VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the
router is called the IP address owner. A VRRP group can have only one IP address owner.
VRRP avoids single points of failure and simplifies the configuration on hosts. When the master in the
VRRP group on a multicast or broadcast LAN (for example, an Ethernet network) fails, another router in
the VRRP group takes over. The switchover is complete without causing dynamic route recalculation, route
re-discovery, gateway reconfiguration on the hosts, or traffic interruption.
VRRP operates in standard mode implemented based on RFCs. For more information, see "VRRP
standard mode."
VRRP has two versions: VRRPv2 and VRRPv3. VRRPv2 and VRRPv3 support only IPv4 VRRP.
15
VRRP standard mode
In VRRP standard mode, only the master in the VRRP group can provide gateway service. When the
master fails, the backup routers elect a new master to take over for nonstop gateway service.
Figure 8 VRRP networking
As shown in Figure 8, Router A, Router B, and Router C form a virtual router, which has its own IP address.
Hosts on the subnet use the virtual router as the default gateway.
The router with the highest priority among the three routers is elected as the master, and the other two are
backups.
Router priority in a VRRP group
VRRP determines the role (master or backup) of each router in a VRRP group by priority. A router with
higher priority is more likely to become the master.
VRRP priorities range from 0 to 255, and a greater number represents a higher priority. Priorities 1 to
254 are configurable. Priority 0 is reserved for special uses, and priority 255 is for the IP address owner.
The router acting as the IP address owner in a VRRP group always has a running priority of 255 and acts
as the master as long as it operates correctly.
Preemption
A router in a VRRP group operates in either non-preemptive mode or preemptive mode:
•
Non-preemptive mode—When a router in the VRRP group becomes the master, it acts as the master
as long as it operates correctly, even if a backup router is later assigned a higher priority.
Non-preemptive mode helps avoid frequent switchover between the master and backup routers.
•
Preemptive mode—A backup starts a new master election and takes over as master when it detects
that it has a higher priority than the current master. Preemptive mode makes sure the router with the
highest priority in a VRRP group always acts as the master.
16
Authentication method
To avoid attacks from unauthorized users, VRRP member routers add authentication keys in VRRP packets
to authenticate one another. VRRP provides the following authentication methods:
•
Simple authentication
The sender fills an authentication key into the VRRP packet, and the receiver compares the received
authentication key with its local authentication key. If the two authentication keys match, the
received VRRP packet is legitimate. Otherwise, the received packet is illegitimate and gets
discarded.
•
MD5 authentication
The sender computes a digest for the packet to be sent by using the authentication key and MD5
algorithm, and saves the result in the VRRP packet. The receiver performs the same operation with
the authentication key and MD5 algorithm, and compares the result with the content in the
authentication header. If the results match, the received VRRP packet is legitimate. Otherwise, the
received packet is illegitimate and gets discarded.
On a secure network, you can choose to not authenticate VRRP packets.
NOTE:
IPv4 VRRPv3 does not support VRRP packet authentication.
VRRP timers
Skew_Time
Skew_Time helps avoid the situation that multiple backups in a VRRP group become the master at the
same time when the master in the VRRP group fails.
Skew_Time is not configurable and its value depends on the version of VRRP:
•
In VRRPv2 (described in RFC 3768), Skew_Time is (256 – Router priority)/256.
•
In VRRPv3 (described in RFC 5798), Skew_Time is ((256 – Router priority) × VRRP advertisement
interval)/256.
VRRP advertisement interval
The master in a VRRP group periodically sends VRRP advertisements to declare its presence.
You can configure the interval at which the master sends VRRP advertisements. If a backup does not
receive a new VRRP advertisement from the master when the timer (3 × VRRP advertisement interval +
Skew_Time) expires, it regards that the master has failed and takes over as the master.
VRRP preemption delay timer
You can configure the VRRP preemption delay timer to avoid frequent state changes among members in
a VRRP group and provide the backups enough time to collect information (such as routing information).
In preempt mode, a backup does not immediately become the master after it receives an advertisement
with lower priority than the local priority. Instead, it waits for a period of time (preemption delay time +
Skew_Time) before taking over as the master.
17
Master election
Routers in a VRRP group determine their roles by priority. When a router joins a VRRP group, it has a
backup role. The router role changes according to the following situations:
•
If the backup does not receive any VRRP advertisement when the timer (3 × advertisement interval
+ Skew_Time) expires, it becomes the master.
•
If the backup receives a VRRP advertisement with a greater or the same priority within the timer (3
× advertisement interval + Skew_Time), it remains a backup.
•
If the backup receives a VRRP advertisement with a smaller priority within the timer (3 ×
advertisement interval + Skew_Time), it remains a backup when operating in non-preemptive mode,
or becomes the master when operating in preemptive mode.
The elected master starts a VRRP advertisement interval to periodically send VRRP advertisements to
notify the backups that it is operating correctly. Each of the backups starts a timer to wait for
advertisements from the master.
After a backup receives a VRRP advertisement, it compares only the priority in the packet with its own
priority.
When multiple routers in a VRRP group declare that they are the master because of network problems,
the one with the highest priority becomes the master. If two routers have the same priority, the one with
the highest IP address becomes the master.
VRRP tracking
To enable VRRP tracking, configure the routers in the VRRP group to operate in preemptive mode first, so
that only the router with the highest priority operates as the master for packet forwarding. For more
information about track entries, see High Availability Configuration Guide.
The VRRP tracking function uses network quality analyzer (NQA) or bidirectional forwarding detection
(BFD) to monitor the state of the master, and establishes the collaboration between the VRRP device state
and NQA or BFD through the track function. It implements the following:
•
Monitors the upstream link and changes the priority of the router according to the state of the link.
If the upstream link fails, the hosts on the subnet cannot access external networks through the router
and the state of the track entry becomes Negative. The priority of the master decreases by a
specified value. Then, a router with a higher priority in the VRRP group becomes the master to
maintain the proper communication between the hosts on the subnet and external networks.
•
Monitors the state of the master on the backups. When the master fails, a backup immediately takes
over as the master to ensure uninterrupted communication.
When the track entry changes from Negative to Positive or Notready, the router automatically restores its
priority. For more information about track entries, see "Configuring Track."
VRRP application
Master/backup
In master/backup mode, only the master forwards packets, as shown in Figure 9. When the master fails,
a new master is elected from among the backups. This mode requires only one VRRP group, and each
router in the group has a different priority. The one with the highest priority becomes the master.
18
Figure 9 VRRP in master/backup mode
Assume that Router A is acting as the master to forward packets to external networks, and Router B and
Router C are backups in listening state. When Router A fails, Router B and Router C elect a new master
to forward packets for hosts on the subnet.
Load sharing
A router can join multiple VRRP groups and has different priorities in different VRRP groups, and it can act
as the master in one VRRP group and a backup in another.
In load sharing mode, multiple VRRP groups provide gateway services. This mode requires at least two
VRRP groups, and each group has one master and multiple backups. The master roles in the VRRP groups
are assumed by different routers, as shown in Figure 10.
Figure 10 Load sharing of VRRP
A router can be in multiple VRRP groups and have a different priority in each group.
As shown in Figure 10, the following VRRP groups are present:
19
•
VRRP group 1—Router A is the master. Router B and Router C are the backups.
•
VRRP group 2—Router B is the master. Router A and Router C are the backups.
•
VRRP group 3—Router C is the master. Router A and Router B are the backups.
To implement load sharing among Router A, Router B, and Router C, hosts on the subnet must be
configured with the virtual IP addresses of VRRP group 1, 2, and 3 as default gateways, respectively.
When you configure them, make sure that each router is assigned an appropriate priority in each VRRP
group so that each router can take the expected role in each group.
Protocols and standards
•
RFC 3768, Virtual Router Redundancy Protocol (VRRP)
•
RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
Configuring IPv4 VRRP
IPv4 VRRP configuration task list
Tasks at a glance
Remarks
(Optional.) Specifying the IPv4 VRRP version
N/A
(Required.) Creating a VRRP group and assigning a virtual IP address
N/A
(Optional.) Configuring the router priority, preemptive mode, and tracking
function
N/A
(Optional.) Configuring IPv4 VRRP packet attributes
N/A
(Optional.) Enabling SNMP notifications for VRRP
N/A
(Optional.) Disabling an IPv4 VRRP group
N/A
Specifying the IPv4 VRRP version
The VRRP version on all routers in an IPv4 VRRP group must be the same.
To specify the version of IPv4 VRRP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type interface-number
N/A
3.
Specify the version of
VRRP.
vrrp version version-number
By default, VRRPv3 is used.
Creating a VRRP group and assigning a virtual IP address
A VRRP group can operate correctly after you create it and assign at least one virtual IP address to it. You
can configure multiple virtual IP addresses for the VRRP group on an interface that connects to multiple
subnets for router backup on different subnets.
20
Configuration guidelines
•
When VRRP is operating in standard mode, the virtual IP address of a VRRP group can be either an
unused IP address on the subnet where the VRRP group resides or the IP address of an interface on
a router in the VRRP group.
•
When a router is the IP address owner in a VRRP group, do not configure the network command on
the interface to use the IP address of the interface, or the virtual IP address of the VRRP group, to
establish a neighbor relationship with the adjacent router. For more information about the network
command, see Layer 3—IP Routing Command Reference.
•
If you create an IPv4 VRRP group but do not assign any virtual IP address for it, the VRRP group stays
in inactive state and does not function.
•
Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the
collision, change the IP address of the interface on the IP address owner before you remove the
VRRP group from the interface.
•
The virtual IP addresses of an IPv4 VRRP group and the IP address of the downlink interface of the
VRRP group must be in the same subnet. Otherwise, the hosts in the subnet cannot access external
networks.
Configuration procedure
To create a VRRP group and assign a virtual IP address:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type interface-number
N/A
3.
Create a VRRP group
and assign a virtual IP
address.
vrrp vrid virtual-router-id virtual-ip
virtual-address
By default, no VRRP group exists.
Configuring the router priority, preemptive mode, and tracking
function
The router priority determines which router in the VRRP group serves as the master. The preemptive mode
enables a backup to take over as the master when it detects that it has a higher priority than the current
master. The tracking function decreases the router priority or enables the backup to take over as the
master when the state of the monitored track entry transits to Negative.
Configuration guidelines
•
The running priority of an IP address owner is always 255, and you do not need to configure it. An
IP address owner always operates in preemptive mode.
•
If you associate a track entry with a VRRP group on an IP address owner, the association does not
take effect until the router is not an IP address owner.
Configuration procedure
To configure the router priority, preemptive mode, and tracking function:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
21
Step
Command
Remarks
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Configure the priority of the
router in the VRRP group.
vrrp vrid virtual-router-id priority
priority-value
The default setting is 100.
4.
Enable the preemptive mode
for the router in a VRRP group
and configure the preemption
delay time.
vrrp vrid virtual-router-id
preempt-mode [ delay
delay-value ]
By default, the router in a VRRP
group operates in preemptive
mode and the preemption delay
time is 0 seconds, which means an
immediate preemption.
5.
Associate a VRRP group with
a track entry.
vrrp vrid virtual-router-id track
track-entry-number [ reduced
priority-reduced | switchover ]
By default, a VRRP group is not
associated with any track entry.
Configuring IPv4 VRRP packet attributes
Configuration guidelines
•
You can configure different authentication modes and authentication keys for VRRP groups on an
interface. However, members of the same VRRP group must use the same authentication mode and
authentication key.
•
In VRRPv2, all routers in a VRRP group must have the same VRRP advertisement interval.
•
In VRRPv3, authentication mode and authentication key settings do not take effect.
•
In VRRPv3, routers in an IPv4 VRRP group can have different intervals for sending VRRP
advertisements. The master in the VRRP group sends VRRP advertisements at specified intervals, and
carries the interval in the advertisements. After a backup receives the advertisement, it records the
interval in the advertisement. If the backup does not receive a new VRRP advertisement from the
master when the timer (3 x recorded interval + Skew_Time) expires, it regards the master as failed
and takes over as the new master.
Configuration procedure
To configure VRRP packet attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Configure the authentication
mode and authentication key
for an IPv4 VRRP group to
send and receive VRRP
packets.
vrrp vrid virtual-router-id
authentication-mode { md5 |
simple } { cipher | plain } key
By default, authentication is
disabled.
4.
Configure the interval at
which the master in an IPv4
VRRP group sends VRRP
advertisements.
The default setting is 100
centiseconds.
vrrp vrid virtual-router-id timer
advertise adver-interval
22
To maintain system stability, HP
recommends setting the VRRP
advertisement interval to be
greater than 100 centiseconds.
Step
Command
Remarks
5.
Specify the source interface
for receiving and sending
VRRP packets.
vrrp vrid virtual-router-id
source-interface interface-type
interface-number
By default, the source interface for
receiving and sending VRRP
packets is not specified. The
interface where the VRRP group
resides sends and receives VRRP
packets.
6.
Enable TTL check for IPv4
VRRP packets.
vrrp check-ttl enable
By default, TTL check for IPv4 VRRP
packets is enabled.
7.
Return to system view.
quit
N/A
vrrp dscp dscp-value
The DSCP value identifies the
packet priority during
transmission.
8.
Configure a DCSP value for
VRRP packets.
By default, the DCSP value for
VRRP packets is 48.
Enabling SNMP notifications for VRRP
Perform this task to enable VRRP to report important events through notifications to the SNMP module.
The SNMP module determines how to output the notifications according to the configured output rules.
For more information about notifications, see Network Management and Monitoring Configuration
Guide.
To enable SNMP notifications for VRRP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable SNMP notifications for
VRRP.
snmp-agent trap enable vrrp
[ auth-failure | new-master ]
By default, SNMP notifications for
VRRP are enabled.
Disabling an IPv4 VRRP group
You can temporarily disable an IPv4 VRRP group. After being disabled, the VRRP group stays in
initialized state, and its configurations remain unchanged. You can change the configuration of a VRRP
group when the VRRP group is disabled. Your changes take effect when you enable the VRRP group
again.
To disable an IPv4 VRRP group:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Disable a VRRP group.
vrrp vrid virtual-router-id shutdown
By default, a VRRP group is
enabled.
23
Displaying and maintaining IPv4 VRRP
Execute display commands in any view and the reset command in user view.
Task
Command
Display states of IPv4 VRRP groups.
display vrrp [ interface interface-type interface-number [ vrid
virtual-router-id ] ] [ verbose ]
Display statistics for IPv4 VRRP
groups.
display vrrp statistics [ interface interface-type interface-number [ vrid
virtual-router-id ] ]
Clear statistics for IPv4 VRRP
groups.
reset vrrp statistics [ interface interface-type interface-number [ vrid
virtual-router-id ] ]
IPv4 VRRP configuration examples
This section provides examples of configuring IPv4 VRRP applications on switches.
Single VRRP group configuration example
This section provides an example of configuring a single VRRP group on switches.
Network requirements
Switch A and Switch B form a VRRP group and use the virtual IP address 10.1.1.111/24 to provide gateway
service for the subnet where Host A resides, as shown in Figure 11.
Switch A operates as the master to forward packets from Host A to Host B. When Switch A fails, Switch
B takes over to forward packets for Host A.
Figure 11 Network diagram
Configuration procedure
1.
Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] vlan 2
24
[SwitchA-vlan2] port fortygige 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.1 255.255.255.0
# Create VRRP group 1 on VLAN-interface 2, and set its virtual IP address to 10.1.1.111.
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.111
# Assign Switch A a higher priority than Switch B in VRRP group 1, so Switch A can become the
master.
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# Configure Switch A to operate in preemptive mode, so it can become the master whenever it
operates correctly, and set the preemption delay to 5 seconds to avoid frequent status switchover.
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5
2.
Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] vlan 2
[SwitchB-Vlan2] port fortygige 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 10.1.1.2 255.255.255.0
# Create VRRP group 1 on VLAN-interface 2, and set its virtual IP address to 10.1.1.111.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.111
# Configure the priority of Router B in VRRP group 1 as 100.
[SwitchB-Vlan-interface2] vrrp vrid 1 priority 100
# Configure Switch B to operate in preemptive mode, and set the preemption delay to 5 seconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5
3.
Verify the configuration:
# Ping Host B from Host A. (Details not shown.)
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 5
Auth Type
: None
Virtual IP
: 10.1.1.111
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.1
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
25
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 5
Become Master
: 401ms left
Auth Type
: None
Virtual IP
: 10.1.1.111
Master IP
: 10.1.1.1
The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from
Host A to Host B.
# Disconnect the link between Host A and Switch A, and verify that Host A can still ping Host B.
(Details not shown.)
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 5
Auth Type
: None
Virtual IP
: 10.1.1.111
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.2
The output shows that when Switch A fails, Switch B takes over to forward packets from Host A to
Host B.
# Recover the link between Host A and Switch A, and display detailed information about VRRP
group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 5
Auth Type
: None
Virtual IP
: 10.1.1.111
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.1
The output shows that after Switch A resumes normal operation, it becomes the master to forward
packets from Host A to Host B.
26
Multiple VRRP groups configuration example
This section provides an example of configuring multiple VRRP groups on switches.
Network requirements
Switch A and Switch B form two VRRP groups. VRRP group 1 uses the virtual IP address 10.1.1.100/25 to
provide gateway service for hosts in VLAN 2, and VRRP group 2 uses the virtual IP address
10.1.1.200/25 to provide gateway service for hosts in VLAN 3, as shown in Figure 12.
Assign a higher priority to Switch A than Switch B in VRRP group 1, but a lower priority in VRRP group
2, to distribute the traffic from VLAN 2 and VLAN 3 between the two switches. When one of the switches
fails, the healthy switch provides gateway service for both VLANs.
Figure 12 Network diagram
Virtual IP address 1:
10.1.1.100/25
XGE1/0/5
Vlan-int2
10.1.1.1/25
XGE1/0/6
Vlan-int3
10.1.1.130/25
VLAN 2
Gateway:
10.1.1.100/25
Switch A
Internet
VLAN 3
XGE1/0/5
Vlan-int2
10.1.1.2/25
XGE1/0/6
Vlan-int3
10.1.1.131/25
Gateway:
10.1.1.200/25
Switch B
Virtual IP address 2:
10.1.1.200/25
Configuration procedure
1.
Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] vlan 2
[SwitchA-vlan2] port fortygige 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.1 255.255.255.128
# Create VRRP group 1, and set its virtual IP address to 10.1.1.100.
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.100
# Assign Switch A a higher priority than Switch B in VRRP group 1, so Switch A can become the
master in the group.
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
[SwitchA-Vlan-interface2] quit
# Configure VLAN 3.
[SwitchA] vlan 3
[SwitchA-vlan3] port fortygige 1/0/6
[SwitchA-vlan3] quit
27
[SwitchA] interface vlan-interface 3
[SwitchA-Vlan-interface3] ip address 10.1.1.130 255.255.255.128
# Create VRRP group 2, and set its virtual IP address to 10.1.1.200.
[SwitchA-Vlan-interface3] vrrp vrid 2 virtual-ip 10.1.1.200
2.
Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] vlan 2
[SwitchB-vlan2] port fortygige 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 10.1.1.2 255.255.255.128
# Create VRRP group 1, and set its virtual IP address to 10.1.1.100.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.100
[SwitchB-Vlan-interface2] quit
# Configure VLAN 3.
[SwitchB] vlan 3
[SwitchB-vlan3] port fortygige 1/0/6
[SwitchB-vlan3] quit
[SwitchB] interface vlan-interface 3
[SwitchB-Vlan-interface3] ip address 10.1.1.131 255.255.255.128
# Create VRRP group 2, and set its virtual IP address to 10.1.1.200.
[SwitchB-Vlan-interface3] vrrp vrid 2 virtual-ip 10.1.1.200
# Assign Switch B a higher priority than Switch A in VRRP group 2, so Switch B can become the
master in the group.
[SwitchB-Vlan-interface3] vrrp vrid 2 priority 110
3.
Verify the configuration:
# Display detailed information about the VRRP groups on Switch A.
[SwitchA-Vlan-interface3] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 2
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 10.1.1.100
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.1
Interface Vlan-interface3
VRID
: 2
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 100
Running Pri
: 100
28
Preempt Mode
: Yes
Become Master
: 203ms left
Auth Type
: None
Virtual IP
: 10.1.1.200
Master IP
: 10.1.1.131
Delay Time
: 0
# Display detailed information about the VRRP groups on Switch B.
[SwitchB-Vlan-interface3] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 2
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Become Master
: 211ms left
Auth Type
: None
Virtual IP
: 10.1.1.100
Master IP
: 10.1.1.1
Interface Vlan-interface3
VRID
: 2
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 10.1.1.200
Virtual MAC
: 0000-5e00-0102
Master IP
: 10.1.1.131
The output shows that Switch A is operating as the master in VRRP group 1 to forward Internet
traffic for hosts that use the default gateway 10.1.1.100/25, and Switch B is operating as the
master in VRRP group 2 to forward Internet traffic for hosts that use the default gateway
10.1.1.200/25.
Troubleshooting VRRP
An error prompt is displayed
Symptom
An error prompt "The virtual router detected a VRRP configuration error." is displayed during
configuration.
Analysis
This symptom is probably caused by the following reasons:
•
The VRRP advertisement interval in the packet is not the same as that for the current VRRP group.
•
The number of virtual IP addresses in the packet is not the same as that for the current VRRP group.
29
•
The virtual IP address list is not the same as that for the current VRRP group.
•
A device in the VRRP group receives illegitimate VRRP packets. For example, the IP address owner
receives a VRRP packet with the priority 255.
•
Modify the configuration on routers in VRRP groups to ensure consistent configuration.
•
Take fault location and anti-attack measures to eliminate potential threats.
Solution
Multiple masters appear in a VRRP group
Symptom
Multiple masters appear in a VRRP group.
Analysis
It is normal for a VRRP group to have multiple masters for a short time, and this situation requires no
manual intervention.
If multiple masters coexist for a longer period, it might be because the masters cannot receive
advertisements from each other, or because the received advertisements are illegitimate.
Solution
Ping between these masters, and do the following checks:
•
If the ping fails, examine network connectivity.
•
If the ping succeeds, check for configuration inconsistencies in the number of virtual IP addresses,
virtual IP addresses, and authentication. For IPv4 VRRP, also make sure a consistent version of VRRP
is configured on all routers in the VRRP group. For VRRPv2, make sure consistent VRRP
advertisement interval is configured on the routers in the VRRP group.
Fast VRRP state flapping
Symptom
Fast VRRP state flapping occurs.
Analysis
The VRRP advertisement interval is set too short.
Solution
Increase the interval for sending VRRP advertisements or introduce a preemption delay.
30
Configuring BFD
The term "interface" in this chapter collectively refers to Layer 3 interfaces, including VLAN interfaces
and Layer 3 Ethernet interfaces. You can set an Ethernet port as a Layer 3 interface by using the port
link-mode route command (see Layer 2—LAN Switching Configuration Guide).
Overview
Bidirectional forwarding detection (BFD) provides a general-purpose, standard, medium- and
protocol-independent fast failure detection mechanism. It can detect and monitor the connectivity of links
in IP to detect communication failures quickly so that measures can be taken to ensure service continuity
and enhance network availability.
BFD can uniformly and quickly detect the failures of the bidirectional forwarding paths between two
devices for upper-layer protocols such as routing protocols. The hello mechanism used by upper layer
protocols needs seconds to detect a link failure, while BFD can provide detection measured in
milliseconds.
BFD can be used for single-hop and multi-hop detections:
•
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 overlap.
BFD session establishment
BFD provides no neighbor discovery mechanism. Protocols that BFD services notify BFD of routers to
which it needs to establish sessions.
Establishing BFD sessions
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.
Terminating a BFD session
When BFD detects a link failure:
1.
BFD clears the neighbor session.
2.
BFD notifies the protocol of the failure.
3.
The protocol terminates the neighborship on the link.
4.
If a backup link is available, the protocol will use it for communication.
BFD session modes and operating modes
BFD sessions use the following types of packets:
31
•
Echo packets—Encapsulated into UDP packets with port number 3785.
•
Control packets—Encapsulated into UDP packets with port number 3784 for single-hop detection
or port number 4784 for multi-hop detection.
Echo packet mode
The local end of the link sends echo packets to establish BFD sessions and monitor link status. The peer
end does not establish BFD sessions and only forwards the packets back to the originating end.
In echo packet mode, BFD supports only single-hop detection and the BFD session is independent of the
operating mode.
Control packet mode
Both ends of the link exchange BFD control packets to monitor link status.
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. 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 the connectivity is found to be up, no
more BFD control packets are sent until the next command is issued.
In addition, both ends of the link can exchange BFD control packets to establish and maintain BFD
sessions, and one end of the link sends echo packets to monitor link status.
Supported features
•
Static routing. For more information, see Layer 3—IP Routing Configuration Guide.
•
RIP. For more information, see Layer 3—IP Routing Configuration Guide.
•
OSPF. For more information, see Layer 3—IP Routing Configuration Guide.
•
IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.
•
BGP. For more information, see Layer 3—IP Routing Configuration Guide.
•
PIM. For more information, see IP Multicast Configuration Guide.
•
Track. For more information, see "Configuring Track."
•
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)
32
•
RFC 5882, Generic Application of Bidirectional Forwarding Detection (BFD)
•
RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths
•
RFC 5885, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV)
Configuring BFD basic functions
Before configuring BFD basic functions, configure the network layer addresses of the interfaces so that
adjacent nodes are reachable to each other at the network layer.
After a BFD session is established, the two ends negotiate BFD parameters, including minimum sending
interval, minimum receiving interval, initialization mode, and packet authentication, by exchanging
negotiation packets. They use the negotiated parameters without affecting the session status.
Configuring echo packet mode
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, no source IP address is
configured for echo packets.
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.
2.
Configure the source IP
address of echo packets.
bfd echo-source-ip ip-address
3.
Enter interface view.
interface interface-type
interface-number
N/A
4.
(Optional.) Configure the
minimum interval for receiving
BFD echo packets.
bfd min-echo-receive-interval
value
The default setting is 400
milliseconds.
5.
(Optional.) Configure the
single-hop detection time
multiplier.
bfd detect-multiplier value
The default setting is 5.
Configuring control packet mode
To configure control packet mode for single-hop detection:
Step
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 }
By default, active is specified.
3.
Enter interface view.
interface interface-type
interface-number
N/A
33
Step
Command
Remarks
4.
Configure the authentication
mode for single-hop control
packets.
bfd authentication-mode simple
key-id { cipher cipher-string | plain
plain-string }
By default, single-hop BFD packets
are not authenticated.
5.
Enable the Demand BFD
session mode.
bfd demand enable
By default, the BFD session is in
Asynchronous mode.
By default, the echo packet mode
is disabled.
If you enable the echo packet
mode for a BFD session in which
control packets are sent and the
session goes up, BFD periodically
sends echo packets to detect link
connectivity and decrease control
packet receive rate.
6.
Enable the echo packet mode.
bfd echo enable
7.
Configure the minimum
interval for transmitting
single-hop BFD control
packets.
bfd min-transmit-interval value
The default setting is 400
milliseconds.
Configure the minimum
interval for receiving
single-hop BFD control
packets.
bfd min-receive-interval value
The default setting is 400
milliseconds.
Configure the single-hop
detection time multiplier.
bfd detect-multiplier value
The default setting is 5.
8.
9.
To configure control packet mode for multi-hop detection:
Step
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 }
By default, active is specified.
3.
Configure the authentication
mode for multi-hop BFD
control packets.
bfd multi-hop authentication-mode
simple key-id { cipher cipher-string
| plain plain-string }
By default, no authentication is
performed.
4.
Configure the destination port
number for multi-hop BFD
control packets.
bfd multi-hop destination-port
port-number
The default setting is 4784.
5.
Configure the multi-hop
detection time multiplier.
bfd multi-hop detect-multiplier
value
The default setting is 5.
6.
Configure the minimum
interval for receiving multi-hop
BFD control packets.
bfd multi-hop min-receive-interval
value
The default setting is 400
milliseconds.
7.
Configure the minimum
interval for transmitting
multi-hop BFD control packets.
bfd multi-hop
min-transmit-interval value
The default setting is 400
milliseconds.
34
Displaying and maintaining BFD
Execute the display command in any view and the reset command in user view.
Task
Command
Display BFD session information.
display bfd session [ discriminator value | verbose ]
Clear BFD session statistics.
reset bfd session statistics
35
Configuring Track
Overview
The Track module works between application modules and detection modules, as shown in Figure 13. It
shields the differences between various detection modules from application modules.
Collaboration is enabled after you associate the Track module with a detection module and an
application module. The detection module probes specific objects such as interface status, link status,
network reachability, and network performance, and informs the Track module of detection results. The
Track module sends the detection results to the associated application module. When notified of changes
for the tracked object, the application modules can react to avoid communication interruption and
network performance degradation.
Figure 13 Collaboration through the Track module
Collaboration fundamentals
The Track module collaborates with detection modules and application modules:
•
Collaboration between the Track module and a detection module
•
Collaboration between the Track module and an application module
Collaboration between the Track module and a detection module
The detection module sends the detection result of the associated tracked object to the Track module.
Depending on the result, the Track module changes the status of the track entry:
•
If the tracked object functions correctly (for example, the target interface is up or the target network
is reachable), the state of the track entry is Positive.
•
If the tracked object does not function correctly (for example, the target interface is down or the
target network is unreachable), the state of the track entry is Negative.
•
If the detection result is not valid (for example, the NQA test group that is associated with the track
entry does not exist), the state of the track entry is NotReady.
The following detection modules can be associated with the Track module:
•
NQA.
36
•
BFD.
•
Interface management.
Collaboration between the Track module and an application module
The following application modules can be associated with the Track module:
•
VRRP.
•
Static routing.
•
Policy-based routing.
When configuring a track entry for an application module, you can set a notification delay to avoid
immediate notification of status changes, which can cause communication failure. This issue occurs when
route convergence is slower than the link state change notification. For example, when the master in a
VRRP group detects that the uplink interface fails through the Track module, the Track module notifies the
master to decrease its priority so that a backup with higher priority preempts as the new master. When
the failed uplink interface recovers, the Track module immediately notifies the original master to restore
its priority and forward traffic. If the uplink route has not recovered, forwarding failure will occur.
Collaboration application example
The following is an example of collaboration between NQA, Track, and static routing.
Configure a static route with next hop 192.168.0.88 on the device. If the next hop is reachable, the static
route is valid. If the next hop becomes unreachable, the static route should become invalid. For this
purpose, configure collaboration between the NQA, track, and static routing modules:
1.
Create an NQA test group to monitor the accessibility of IP address 192.168.0.88.
2.
Create a track entry and associate it with the NQA test group. When the next hop 192.168.0.88
is reachable, the track entry is in Positive state. When the next hop becomes unreachable, the track
entry is in Negative state.
3.
Associate the track entry with the static route. When the track entry turns to the Positive state, the
static route is valid. When the associated track entry turns to Negative state, the static route is
invalid.
Track configuration task list
To implement the collaboration function, establish associations between the Track module and the
detection modules, and between the Track module and the application modules.
To configure the Track module, perform the following tasks:
Tasks at a glance
Remarks
(Required.) Associating the Track module with a detection module:
• Associating Track with NQA
• Associating Track with BFD
• Associating Track with interface management
37
Use one of the
methods.
Tasks at a glance
Remarks
(Required.) Associating the Track module with an application module:
• Associating Track with VRRP
• Associating Track with static routing
• Associating Track with PBR
Use one of the
methods.
Associating the Track module with a detection
module
Associating Track with NQA
NQA supports multiple test types to analyze network performance, services, and service quality. For
example, an NQA test group can periodically detect whether a destination is reachable, or whether the
TCP connection to a TCP server can be set up.
An NQA test group functions as follows when it is associated with a track entry:
•
If the consecutive failures reach the specified threshold, the NQA module notifies the Track module
that the tracked object has malfunctioned. Then the Track module sets the track entry to Negative
state.
•
If the specified threshold is not reached, the NQA module notifies the Track module that the tracked
object is functioning correctly. The Track module then sets the track entry to Positive state.
For more information about NQA, see Network Management and Monitoring Configuration Guide.
To associate Track with NQA:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create a track entry,
associate it with an NQA
reaction entry, and specify the
delay time for the Track
module to notify the
associated application
module when the track entry
status changes.
track track-entry-number nqa entry
admin-name operation-tag reaction
item-number [ delay { negative
negative-time | positive
positive-time } * ]
No track entry is created by
default.
If the specified NQA test group or
the reaction entry in the track entry
does not exist, the status of the
track entry is NotReady.
Associating Track with BFD
BFD supports the control packet mode and echo packet mode. A track entry can only be associated with
the echo-mode BFD session, and cannot be associated with the control-mode BFD session. For more
information about BFD, see "Configuring BFD."
BFD functions as follows when it is associated with a track entry:
•
If the BFD detects that the link fails, it informs the track entry of the link failure. The Track module sets
the track entry to Negative state.
38
If the BFD detects that the link is operating correctly, the Track module sets the track entry to Positive
state.
•
Configuration prerequisites
Before you associate Track with BFD, configure the source IP address of BFD echo packets. For more
information, see "Configuring BFD."
Configuration procedure
To associate Track with BFD:
Step
1.
Enter system view.
2.
Create a track entry,
associate it with the BFD
session, and specify the delay
time for the Track module to
notify the associated
application module when the
track entry status changes.
Command
Remarks
system-view
N/A
track track-entry-number bfd echo interface
interface-type interface-number remote ip
remote-ip local ip local-ip [ delay { negative
negative-time | positive positive-time } * ]
No track entry is created
by default.
Do not configure the
virtual IP address of a
VRRP group as the local or
remote address of a BFD
session.
Associating Track with interface management
The interface management module monitors the link status or network-layer protocol status of the
interface. The interface management module functions as follows when it is associated with a track entry:
•
When the link or network-layer protocol status of the interface changes to up, the interface
management module informs the Track module of the change and the Track module sets the track
entry to Positive.
•
When the link or network-layer protocol status of the interface changes to down, the interface
management module informs the Track module of the change and the Track module sets the track
entry to Negative.
To associate Track with interface management:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
39
Step
Command
Remarks
• Create a track entry, associate it with
2.
Associating Track with
interface management.
the interface management module to
monitor the link status of an interface,
and specify the delay time for the Track
module to notify the associated
application module when the track
entry status changes:
track track-entry-number interface
interface-type interface-number [ delay
{ negative negative-time | positive
positive-time } * ]
• Create a track entry, associate it with
the interface management module to
monitor the Layer 3 protocol status of
an interface, and specify the delay time
for the Track module to notify the
associated application module when
the track entry status changes:
track track-entry-number interface
interface-type interface-number
protocol ipv4 [ delay { negative
negative-time | positive positive-time }
*]
Use either method.
No track entry is created by
default.
Associating the Track module with an application
module
Associating Track with VRRP
Associate the Track module with the VRRP group to implement the following actions:
•
Change the priority of a router according to the status of the uplink. If a fault occurs on the uplink
of the router, the VRRP group is not aware of the uplink failure. If the router is the master, hosts in the
LAN cannot access the external network. This problem can be solved by establishing a Track-VRRP
group association. Use the detection modules to monitor the status of the uplink of the router and
establish collaborations between the detection modules, Track module, and VRRP. When the uplink
fails, the detection modules notify the Track module to change the status of the monitored track entry
to Negative, and the priority of the master decreases by a user-specified value. This allows a higher
priority router in the VRRP group to become the master, and maintains proper communication
between the hosts in the LAN and the external network.
•
Monitor the master on a backup. If a fault occurs on the master, the backup operating in switchover
mode will switch to the master immediately to maintain normal communication.
Follow these guidelines when you associate Track with VRRP:
•
VRRP tracking is not valid on an IP address owner. An IP address owner refers to a router when the
IP address of the virtual router is the IP address of an interface on the router in the VRRP group.
•
When the status of the track entry changes from Negative to Positive or NotReady, the associated
router restores its priority automatically.
40
You can associate a nonexistent track entry with a VRRP group. The association takes effect only
after you use the track command to create the track entry.
•
To associate Track with VRRP group:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Associate a track entry with a
VRRP group.
vrrp vrid virtual-router-id track
track-entry-number [ reduced
priority-reduced | switchover ]
By default, no track entry is
specified for a VRRP group.
Associating Track with static routing
A static route is a manually configured route. With a static route configured, packets to the specified
destination are forwarded through the path specified by the administrator. For more information about
static route configuration, see Layer 3—IP Routing Configuration Guide.
The disadvantage of using static routes is that they cannot adapt to network topology changes. Faults or
topological changes in the network can make the routes unreachable, causing network breaks.
To prevent this problem, configure another route to back up the static route. When the static route is
reachable, packets are forwarded through the static route. When the static route is unreachable, packets
are forwarded through the backup route, avoiding network breaks and enhancing network reliability.
To check the accessibility of a static route in real time, establish an association between Track and the
static route.
If you specify the next hop but not the egress interface when configuring a static route, you can establish
collaborations among the static route, the Track module, and detection modules. This enables you to
check the accessibility of the static route by the status of the track entry.
•
The Positive state of the track entry shows that the next hop of the static route is reachable, and that
the configured static route is valid.
•
The Negative state of the track entry shows that the next hop of the static route is not reachable, and
that the configured static route is invalid.
•
The NotReady state of the track entry shows that the accessibility of the next hop of the static route
is unknown, and that the static route is valid.
Follow these guidelines when you associate Track with static routing:
•
You can associate a nonexistent track entry with a static route. The association takes effect only after
you use the track command to create the track entry.
•
If a static route needs route recursion, the associated track entry must monitor the next hop of the
recursive route instead of that of the static route. Otherwise, a valid route might be considered
invalid.
To associate Track with static routing:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
41
Step
Associate the static
route with a track
entry to check the
accessibility of the
next hop.
2.
Command
Remarks
ip route-static dest-address { mask |
mask-length } { next-hop-address [ track
track-entry-number ] | interface-type
interface-number [ next-hop-address ] }
[ permanent ] [ preference preference-value ]
[ tag tag-value ] [ description description-text ]
Not configured by default.
Associating Track with PBR
PBR is a routing mechanism based on user-defined policies. Different from the traditional
destination-based routing mechanism, PBR allows you to use a policy to route packets. You can specify
the next hop to guide the forwarding of packets that match specific ACLs. For more information about
PBR, see Layer 3—IP Routing Configuration Guide.
PBR cannot detect the availability of any action taken on packets. When the specified next hop fails, PBR
cannot sense the failure, and continues to forward matching packets to the next hop.
This problem can be solved by associating Track with PBR, which improves the flexibility of the PBR
application and enables PBR to sense topology changes.
After you associate a track entry with an apply clause, the detection module associated with the track
entry sends the detection result of the availability of the object (an interface or an IP address) specified
in the apply clause.
•
The Positive state of the track entry shows that the object is available, and the apply clause is valid.
•
The Negative state of the track entry shows that the object is not available, and the apply clause is
invalid.
•
The NotReady state of the track entry shows that the apply clause is valid.
The following objects can be associated with a track entry:
•
Outgoing interface.
•
Next hop.
•
Default outgoing interface.
•
Default next hop.
Configuration prerequisites
Before you associate Track with PBR, create a policy or a policy node and configure the match criteria as
well.
Configuration procedure
You can associate a nonexistent track entry with PBR. The association takes effect only after you use the
track command to create the track entry.
To associate Track with IPv4 PBR:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
42
Step
Command
Remarks
Create a policy or policy
node and enter PBR policy
node view.
policy-based-route policy-name [ deny |
permit ] node node-number
N/A
3.
Define a match criterion.
if-match acl { acl-number | name acl-name }
By default, no packets
are filtered.
4.
Associate Track with PBR.
apply next-hop { ip-address [ direct ] [ track
track-entry-number ] }&<1-n>
N/A
2.
Displaying and maintaining track entries
Execute the display command in any view.
Task
Command
Display information about a specific or all track entries.
display track { track-entry-number | all }
Track configuration examples
VRRP-Track-NQA collaboration configuration example
In this example, the master monitors the uplink.
Network requirements
As shown in Figure 14, configure Host A to access Host B on the Internet. The default gateway of Host A
is 10.1.1.10/24.
Switch A and Switch B belong to VRRP group 1, whose virtual IP address is 10.1.1.10.
When Switch A works correctly, packets from Host A to Host B are forwarded through Switch A. When
VRRP finds that a fault is on the uplink of Switch A through NQA, packets from Host A to Host B are
forwarded through Switch B.
43
Figure 14 Network diagram
Configuration procedure
1.
Create VLANs and assign corresponding ports to them. Configure the IP address of each VLAN
interface as shown in Figure 14. (Details not shown.)
2.
Configure an NQA test group on Switch A:
# Create an NQA test group with the administrator name admin and the operation tag test.
<SwitchA> system-view
[SwitchA] nqa entry admin test
# Configure the test type as ICMP-echo.
[SwitchA-nqa-admin-test] type icmp-echo
# Configure the destination address as 10.1.2.2.
[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.1.2.2
# Set the test frequency to 100 milliseconds.
[SwitchA-nqa-admin-test-icmp-echo] frequency 100
# Configure reaction entry 1, specifying that five consecutive probe failures trigger the Track
module.
[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail
threshold-type consecutive 5 action-type trigger-only
[SwitchA-nqa-admin-test-icmp-echo] quit
# Start the NQA test.
[SwitchA] nqa schedule admin test start-time now lifetime forever
3.
On Switch A, configure track entry 1, and associate it with reaction entry 1 of the NQA test group
(with the administrator admin, and the operation tag test).
[SwitchA] track 1 nqa entry admin test reaction 1
4.
Configure VRRP on Switch A:
# Create VRRP group 1, and configure the virtual IP address 10.1.1.10 for the group.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
# Set the priority of Switch A in VRRP group 1 to 110.
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# Set the authentication mode of VRRP group 1 to simple, and the authentication key to hello.
44
[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# Configure the master to send VRRP packets at an interval of 500 centiseconds.
[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 500
# Configure Switch A to operate in preemptive mode, and set the preemption delay to 5 seconds.
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
# Configure to monitor track entry 1, and specify the priority decrement to 30.
[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 30
5.
Configure VRRP on Switch B:
<SwitchB> system-view
[SwitchB] interface vlan-interface 2
# Create VRRP group 1, and configure the virtual IP address 10.1.1.10 for the group.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
# Set the authentication mode of VRRP group 1 to simple, and the authentication key to hello.
[SwitchB-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# Configure the master to send VRRP packets at an interval of 500 centiseconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 timer advertise 500
# Configure Switch B to operate in preemptive mode, and set the preemption delay to 5 seconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
Verifying the configuration
After configuration, ping Host B on Host A, and you can see that Host B is reachable. Use the display
vrrp command to view the configuration result.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 500
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 5
Auth Type
: Simple
Key
: ******
Virtual IP
: 10.1.1.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.1
VRRP Track Information:
Track Object
: 1
State : Positive
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 500
Admin Status
: Up
State
: Backup
45
Pri Reduced : 30
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 5
Become Master
: 2200ms left
Auth Type
: Simple
Key
: ******
Virtual IP
: 10.1.1.10
Master IP
: 10.1.1.1
The output shows that in VRRP group 1, Switch A is the master, and Switch B is a backup. Packets from
Host A to Host B are forwarded through Switch A.
When a fault is on the link between Switch A and Switch C, you can still successfully ping Host B on Host
A. Use the display vrrp command to view information about VRRP group 1.
# Display detailed information about VRRP group 1 on Switch A when a fault is on the link between
Switch A and Switch C.
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 500
Admin Status
: Up
State
: Backup
Config Pri
: 110
Running Pri
: 80
Preempt Mode
: Yes
Delay Time
: 5
Become Master
: 2200ms left
Auth Type
: Simple
Key
: ******
Virtual IP
: 10.1.1.10
Master IP
: 10.1.1.2
VRRP Track Information:
Track Object
: 1
State : Negative
Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B when a fault is on the link between
Switch A and Switch C.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 500
Admin Status
: Up
State
: Master
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 5
Auth Type
: Simple
Key
: ******
Virtual IP
: 10.1.1.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.2
The output shows that when a fault is on the link between Switch A and Switch C, the priority of Switch
A decreases to 80. Switch A becomes the backup, and Switch B becomes the master. Packets from Host
A to Host B are forwarded through Switch B.
46
Configuring BFD for a VRRP backup to monitor the master
Network requirements
As shown in Figure 15, Switch A and Switch B belong to VRRP group 1, whose virtual IP address is
192.168.0.10.
The default gateway of the hosts in the LAN is 192.168.0.10. When Switch A works correctly, the hosts
in the LAN access the external network through Switch A. When Switch A fails, the hosts in the LAN
access the external network through Switch B.
If the master in a VRRP group fails and BFD is not configured, the backup cannot become the master until
the configured timeout timer expires. The timeout is usually 3 to 4 seconds, which is a long delay for most
applications. To solve this problem, VRRP uses BFD to probe the state of the master. Once the master fails,
the backup can become the new master in milliseconds.
Figure 15 Network diagram
Internet
Switch A
Master
Virtual router
Virtual IP address:
192.168.0.10
Switch B
Backup
Vlan-int2
192.168.0.101/24
Vlan-int2
192.168.0.102/24
L2 switch
BFD probe packets
VRRP packets
Configuration procedure
1.
Create VLANs and assign corresponding ports to them. Configure the IP address of each VLAN
interface as shown in Figure 15. (Details not shown.)
2.
Configure VRRP on Switch A:
<SwitchA> system-view
[SwitchA] interface vlan-interface 2
# Create VRRP group 1, and configure the virtual IP address 192.168.0.10 for the group. Set the
priority of Switch A in VRRP group 1 to 110.
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
[SwitchA-Vlan-interface2] return
47
3.
On Switch B, configure the source address of BFD echo packets as 10.10.10.10.
<SwitchB> system-view
[SwitchB] bfd echo-source-ip 10.10.10.10
4.
On Switch B, create track entry 1 to be associated with the BFD session to check whether Switch
A is reachable.
[SwitchB] track 1 bfd echo interface vlan-interface 2 remote ip 192.168.0.101 local
ip 192.168.0.102
5.
On Switch B, create VRRP group 1, and configure the virtual IP address 192.168.0.10 for the
group. VRRP group 1 monitors the status of track entry 1. When the status of the track entry
becomes Negative, Switch B quickly becomes the master.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10
[SwitchB-Vlan-interface2] vrrp vrid 1 track 1 switchover
[SwitchB-Vlan-interface2] return
Verifying the configuration
# Display detailed information about VRRP group 1 on Switch A.
<SwitchA> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 192.168.0.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 192.168.0.101
# Display detailed information about VRRP group 1 on Switch B.
<SwitchB> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Become Master
: 2200ms left
Auth Type
: None
Virtual IP
: 192.168.0.10
Master IP
: 192.168.0.101
VRRP Track Information:
Track Object
: 1
State : Positive
# Display information about track entry 1 on Switch B.
<SwitchB> display track 1
48
Switchover
Track ID: 1
State: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
VPN instance name: Remote IP: 192.168.0.101
Local IP: 192.168.0.102
The output shows that when the status of the track entry becomes Positive, Switch A is the master and
Switch B the backup.
# Enable VRRP state debugging and BFD event debugging on Switch B.
<SwitchB> terminal debugging
<SwitchB> terminal monitor
<SwitchB> debugging vrrp state
<SwitchB> debugging bfd event
# When Switch A fails, the following output is displayed on Switch B.
*Dec 17 14:44:34:142 2012 SwitchB BFD/7/EVENT: Send sess-down Msg,
[Src:192.168.0.102,Dst:192.168.0.101,Vlan-interface2,Echo], instance:0, protocol:Track
*Dec 17 14:44:34:144 2012 SwitchB VRRP/7/DebugState: IPv4 Vlan-interface2 | Virtual Router
1 : Backup --> Master
reason: The status of the tracked object changed
# Display detailed information about the VRRP group on Switch B.
<SwitchB> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 192.168.0.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 192.168.0.102
VRRP Track Information:
Track Object
: 1
State : Negative
Switchover
The output shows that when BFD detects that Switch A fails, it notifies VRRP through the Track module to
change the status of Switch B to master without waiting for a period three times the advertisement interval.
This ensures that a backup can quickly preempt as the master.
49
Configuring BFD for the VRRP master to monitor the uplinks
Network requirements
As shown in Figure 16, Switch A and Switch B belong to VRRP group 1, whose virtual IP address is
192.168.0.10.
The default gateway of the hosts in the LAN is 192.168.0.10.
When Switch A works correctly, the hosts in the LAN access the external network through Switch A.
When Switch A detects that the uplink is down through BFD, it decreases its priority so that Switch B can
preempt as the master, ensuring that the hosts in the LAN can access the external network through Switch
B.
Figure 16 Network diagram
Internet
Master
uplink device
Backup
uplink device
Vlan-int3
1.1.1.2/24
Uplink
Uplink
Vlan-int3
1.1.1.1/24
Switch A
Master
Vlan-int2
192.168.0.101/24
Switch B
Backup
Virtual router
Virtual IP address:
192.168.0.10
Vlan-int2
192.168.0.102/24
L2 switch
BFD probe packets
VRRP packets
Configuration procedure
1.
Create VLANs and assign corresponding ports to them. Configure the IP address of each VLAN
interface as shown in Figure 16. (Details not shown.)
2.
On Switch A, configure the source address of BFD echo packets as 10.10.10.10.
<SwitchA> system-view
[SwitchA] bfd echo-source-ip 10.10.10.10
3.
On Switch A, create track entry 1 to be associated with the BFD session to check whether the uplink
device with the IP address 1.1.1.2 is reachable.
[SwitchA] track 1 bfd echo interface vlan-interface 3 remote ip 1.1.1.2 local ip
1.1.1.1
4.
On Switch A, create VRRP group 1, and configure the virtual IP address of the group as
192.168.0.10. Configure the priority of Switch A in VRRP group 1 as 110. Configure VRRP group
50
1 to monitor the status of track entry 1. When the status of the track entry becomes Negative, the
priority of Switch A decreases by 20.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 20
[SwitchA-Vlan-interface2] return
5.
On Switch B, create VRRP group 1, and configure the virtual IP address of the group as
192.168.0.10.
<SwitchB> system-view
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10
[SwitchB-Vlan-interface2] return
Verifying the configuration
# Display detailed information about the VRRP group on Switch A.
<SwitchA> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 192.168.0.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 192.168.0.101
VRRP Track Information:
Track Object
: 1
State : Positive
Pri Reduced : 20
# Display information about track entry 1 on Switch A.
<SwitchA> display track 1
Track ID: 1
State: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
VPN instance name: Remote IP: 1.1.1.2
Local IP: 1.1.1.1
# Display detailed information about the VRRP group on Switch B.
<SwitchB> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
51
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Become Master
: 2200ms left
Auth Type
: None
Virtual IP
: 192.168.0.10
Master IP
: 192.168.0.101
The output shows that when the status of track entry 1 becomes Positive, Switch A is the master, and
Switch B the backup.
# When the uplink of Switch A goes down, the status of track entry 1 becomes Negative.
<SwitchA> display track 1
Track ID: 1
State: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
VPN instance name: Remote IP: 1.1.1.2
Local IP: 1.1.1.1
# Display detailed information about VRRP group 1 on Switch A.
<SwitchA> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 110
Running Pri
: 90
Preempt Mode
: Yes
Delay Time
: 0
Become Master
: 2200ms left
Auth Type
: None
Virtual IP
: 192.168.0.10
Master IP
: 192.168.0.102
VRRP Track Information:
Track Object
: 1
State : Negative
Pri Reduced : 20
# Display detailed information about VRRP group 1 on Switch B.
<SwitchB> display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
52
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 192.168.0.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 192.168.0.102
The output shows that when Switch A detects that the uplink fails through BFD, it decreases its priority by
20 to make sure that Switch B can preempt as the master.
Static routing-Track-BFD collaboration configuration example
Network requirements
As shown in Figure 17, Switch A, Switch B, and Switch C are connected to two segments 20.1.1.0/24 and
30.1.1.0/24. Configure static routes on these routers so that the two segments can communicate with
each other. Configure route backup to improve network reliability.
Switch A is the default gateway of the hosts in segment 20.1.1.0/24. Two static routes to 30.1.1.0/24 exist
on Switch A, with the next hop being Switch B and Switch C, respectively. These two static routes back
up each other as follows:
•
The static route with Switch B as the next hop has a higher priority and is the master route. If this
route is available, Switch A forwards packets to 30.1.1.0/24 through Switch B.
•
The static route with Switch C as the next hop acts as the backup route.
•
Configure static routing-Track-BFD collaboration to determine whether the master route is available
in real time. If the master route is unavailable, BFD can quickly detect the route failure to make the
backup route take effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C and
Switch B.
Similarly, Switch B is the default gateway of the hosts in segment 30.1.1.0/24. Two static routes to
20.1.1.0/24 exist on Switch B, with the next hop being Switch A and Switch C, respectively. These two
static routes back up each other as follows:
•
The static route with Switch A as the next hop has a higher priority and is the master route. If this
route is available, Switch B forwards packets to 20.1.1.0/24 through Switch A.
•
The static route with Switch C as the next hop acts as the backup route.
•
Configure static routing-Track-BFD collaboration to determine whether the master route is available
in real time. If the master route is unavailable, BFD can quickly detect the route failure to make the
backup route take effect, and Switch B forwards packets to 20.1.1.0/24 through Switch C and
Switch A.
53
Figure 17 Network diagram
Configuration procedure
1.
Create VLANs and assign corresponding ports to them. Configure the IP address of each VLAN
interface as shown in Figure 17. (Details not shown.)
2.
Configure Switch A:
# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.2.1.2 and the
default priority 60. This static route is associated with track entry 1.
<SwitchA> system-view
[SwitchA] ip route-static 30.1.1.0 24 10.2.1.2 track 1
# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.3.1.3 and the
priority 80.
[SwitchA] ip route-static 30.1.1.0 24 10.3.1.3 preference 80
# Configure the source address of BFD echo packets as 10.10.10.10.
[SwitchA] bfd echo-source-ip 10.10.10.10
# Configure track entry 1, and associate it with the BFD session. Check whether Switch A can be
interoperated with the next hop of static route (Switch B).
[SwitchA] track 1 bfd echo interface vlan-interface 2 remote ip 10.2.1.2 local ip
10.2.1.1
3.
Configure Switch B:
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.2.1.1 and the
default priority 60. This static route is associated with track entry 1.
<SwitchB> system-view
[SwitchB] ip route-static 20.1.1.0 24 10.2.1.1 track 1
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.4.1.3 and the
priority 80.
[SwitchB] ip route-static 20.1.1.0 24 10.4.1.3 preference 80
# Configure the source address of BFD echo packets as 1.1.1.1.
[SwitchB] bfd echo-source-ip 1.1.1.1
# Configure track entry 1 that is associated with the BFD session to check whether Switch B can
communicate with the next hop (Switch A) of the static route.
[SwitchB] track 1 bfd echo interface vlan-interface 2 remote ip 10.2.1.1 local ip
10.2.1.2
4.
Configure Switch C:
# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.4.1.2.
<SwitchC> system-view
54
[SwitchC] ip route-static 30.1.1.0 24 10.4.1.2
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.3.1.1.
[SwitchB] ip route-static 20.1.1.0 24 10.3.1.1
Verifying the configuration
# Display information about the track entry on Switch A.
[SwitchA] display track all
Track ID: 1
State: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
Remote IP: 10.2.1.2
Local IP: 10.2.1.1
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 9
Destination/Mask
Proto
10.2.1.0/24
10.2.1.1/32
Routes : 9
Pre
Cost
NextHop
Interface
Direct 0
0
10.2.1.1
Vlan2
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
Direct 0
0
10.3.1.1
Vlan3
10.3.1.1/32
Direct 0
0
127.0.0.1
InLoop0
20.1.1.0/24
Direct 0
0
20.1.1.1
Vlan5
20.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
30.1.1.0/24
Static 60
0
10.2.1.2
Vlan2
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoop0
127.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
The output shows the BFD detection result: the next hop 10.2.1.2 is reachable (the status of the track entry
is Positive). The master static route takes effect. Switch A forwards packets to 30.1.1.0/24 through Switch
B.
# Remove the IP address of interface VLAN-interface 2 on Switch B.
<SwitchB> system-view
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] undo ip address
# Display information about the track entry on Switch A.
[SwitchA] display track all
Track ID: 1
State: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
VPN instance name: -
55
Remote IP: 10.2.1.2
Local IP: 10.2.1.1
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 9
Routes : 9
Destination/Mask
Proto
Cost
NextHop
Interface
10.2.1.0/24
Direct 0
Pre
0
10.2.1.1
Vlan2
10.2.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
Direct 0
0
10.3.1.1
Vlan3
10.3.1.1/32
Direct 0
0
127.0.0.1
InLoop0
20.1.1.0/24
Direct 0
0
20.1.1.1
Vlan5
20.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
30.1.1.0/24
Static 80
0
10.3.1.3
Vlan3
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoop0
127.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
The output shows the BFD detection result: the next hop 10.2.1.2 is unreachable (the status of the track
entry is Negative), and the backup static route takes effect, and Switch A forwards packets to
30.1.1.0/24 through Switch C and Switch B.
# When the master route fails, the hosts in 20.1.1.0/24 can still communicate with the hosts in
30.1.1.0/24.
[SwitchA] ping -a 20.1.1.1 30.1.1.1
Ping 30.1.1.1: 56
data bytes, press CTRL_C to break
Reply from 30.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 30.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 30.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 30.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 30.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms
--- Ping statistics for 30.1.1.1 --5 packet(s) transmitted, 5 packet(s) received, 0.00% packet loss
round-trip min/avg/max/std-dev = 1/1/2/1 ms
# The output on Switch B is similar to that on Switch A. When the master route fails, the hosts in
30.1.1.0/24 can still communicate with the hosts in 20.1.1.0/24.
[SwitchB] ping -a 30.1.1.1 20.1.1.1
Ping 20.1.1.1: 56
data bytes, press CTRL_C to break
Reply from 20.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 20.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=4 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms
--- Ping statistics for 20.1.1.1 --5 packet(s) transmitted, 5 packet(s) received, 0.00% packet loss
round-trip min/avg/max/std-dev = 1/1/2/1 ms
56
VRRP-Track-interface management collaboration configuration
example
In this example, the master monitors the uplink interface.
Network requirements
As shown in Figure 18, Host A needs to access Host B on the Internet. The default gateway of Host A is
10.1.1.10/24.
Switch A and Switch B belong to VRRP group 1, whose virtual IP address is 10.1.1.10.
When Switch A works correctly, packets from Host A to Host B are forwarded through Switch A. When
VRRP detects that a fault is on the uplink interface of Switch A through the interface management module,
packets from Host A to Host B are forwarded through Switch B.
Figure 18 Network diagram
Configuration procedure
1.
Create VLANs and assign corresponding ports to them. Configure the IP address of each VLAN
interface as shown in Figure 18. (Details not shown.)
2.
Configure a track entry on Switch A:
# Configure track entry 1 and associate it with the link status of the uplink interface VLAN-interface
3.
[SwitchA] track 1 interface vlan-interface 3
3.
Configure VRRP on Switch A:
# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
# Set the priority of Switch A in VRRP group 1 to 110.
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# Configure to monitor track entry 1, and specify the priority decrement as 30.
[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 30
4.
Configure VRRP on Switch B:
<SwitchB> system-view
57
[SwitchB] interface vlan-interface 2
# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
Verifying the configuration
After configuration, ping Host B on Host A, and you can see that Host B is reachable. Use the display
vrrp command to view the configuration result.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 110
Running Pri
: 110
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 10.1.1.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.1
VRRP Track Information:
Track Object
: 1
State : Positive
Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Become Master
: 2200ms left
Auth Type
: None
Virtual IP
: 10.1.1.10
Master IP
: 10.1.1.1
The output shows that in VRRP group 1, Switch A is the master, and Switch B is a backup. Packets from
Host A to Host B are forwarded through Switch A.
# Shut down the uplink interface VLAN-interface 3 on Switch A.
[SwitchA-Vlan-interface2] interface vlan-interface 3
[SwitchA-Vlan-interface3] shutdown
After shutting down the uplink interface on Switch A, you can still successfully ping Host B on Host A. Use
the display vrrp command to view information about VRRP group 1.
# After shutting down the uplink interface on Switch A, display detailed information about VRRP group
1 on Switch A.
58
[SwitchA-Vlan-interface3] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Backup
Config Pri
: 110
Running Pri
: 80
Preempt Mode
: Yes
Delay Time
: 0
Become Master
: 2200ms left
Auth Type
: None
Virtual IP
: 10.1.1.10
Master IP
: 10.1.1.2
VRRP Track Information:
Track Object
: 1
State : Negative
Pri Reduced : 30
# After shutting down the uplink interface on Switch A, display detailed information about VRRP group
1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode
: Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID
: 1
Adver Timer
: 100
Admin Status
: Up
State
: Master
Config Pri
: 100
Running Pri
: 100
Preempt Mode
: Yes
Delay Time
: 0
Auth Type
: None
Virtual IP
: 10.1.1.10
Virtual MAC
: 0000-5e00-0101
Master IP
: 10.1.1.2
The output shows that when the uplink interface on Switch A is shut down, the priority of Switch A
decreases to 80. Switch A becomes the backup, and Switch B becomes the master. Packets from Host A
to Host B are forwarded through Switch B.
59
Support and other resources
Contacting HP
For worldwide technical support information, see the HP support website:
http://www.hp.com/support
Before contacting HP, collect the following information:
•
Product model names and numbers
•
Technical support registration number (if applicable)
•
Product serial numbers
•
Error messages
•
Operating system type and revision level
•
Detailed questions
Subscription service
HP recommends that you register your product at the Subscriber's Choice for Business website:
http://www.hp.com/go/wwalerts
After registering, you will receive email notification of product enhancements, new driver versions,
firmware updates, and other product resources.
Related information
Documents
To find related documents, browse to the Manuals page of the HP Business Support Center website:
http://www.hp.com/support/manuals
•
For related documentation, navigate to the Networking section, and select a networking category.
•
For a complete list of acronyms and their definitions, see HP FlexNetwork Technology Acronyms.
Websites
•
HP.com http://www.hp.com
•
HP Networking http://www.hp.com/go/networking
•
HP manuals http://www.hp.com/support/manuals
•
HP download drivers and software http://www.hp.com/support/downloads
•
HP software depot http://www.software.hp.com
•
HP Education http://www.hp.com/learn
60
Conventions
This section describes the conventions used in this documentation set.
Command conventions
Convention
Description
Boldface
Bold text represents commands and keywords that you enter literally as shown.
Italic
Italic text represents arguments that you replace with actual values.
[]
Square brackets enclose syntax choices (keywords or arguments) that are optional.
{ x | y | ... }
Braces enclose a set of required syntax choices separated by vertical bars, from which
you select one.
[ x | y | ... ]
Square brackets enclose a set of optional syntax choices separated by vertical bars, from
which you select one or none.
{ x | y | ... } *
Asterisk-marked braces enclose a set of required syntax choices separated by vertical
bars, from which you select at least one.
[ x | y | ... ] *
Asterisk-marked square brackets enclose optional syntax choices separated by vertical
bars, from which you select one choice, multiple choices, or none.
&<1-n>
The argument or keyword and argument combination before the ampersand (&) sign can
be entered 1 to n times.
#
A line that starts with a pound (#) sign is comments.
GUI conventions
Convention
Description
Boldface
Window names, button names, field names, and menu items are in bold text. For
example, the New User window appears; click OK.
>
Multi-level menus are separated by angle brackets. For example, File > Create > Folder.
Convention
Description
Symbols
WARNING
An alert that calls attention to important information that if not understood or followed can
result in personal injury.
CAUTION
An alert that calls attention to important information that if not understood or followed can
result in data loss, data corruption, or damage to hardware or software.
IMPORTANT
An alert that calls attention to essential information.
NOTE
TIP
An alert that contains additional or supplementary information.
An alert that provides helpful information.
61
Network topology icons
Represents a generic network device, such as a router, switch, or firewall.
Represents a routing-capable device, such as a router or Layer 3 switch.
Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports
Layer 2 forwarding and other Layer 2 features.
Represents an access controller, a unified wired-WLAN module, or the switching engine
on a unified wired-WLAN switch.
Represents an access point.
Represents a security product, such as a firewall, a UTM, or a load-balancing or security
card that is installed in a device.
Represents a security card, such as a firewall card, a load-balancing card, or a
NetStream card.
Port numbering in examples
The port numbers in this document are for illustration only and might be unavailable on your device.
62
Index
A
high availability DLDP simple authentication, 7
advertising
high availability VRRP MD5 authentication, 17
high availability DLDP advertisement packet
send interval, 6
high availability VRRP simple authentication, 17
automatic
high availability DLDP automatic unidirectional link
shutdown, 8
high availability DLDP advertisement timer, 2
high availability VRRP advertisement
interval, 17
application
high availability VRRP, 18
B
BFD
basic configuration, 33
high availability VRRP load-sharing, 19
configuration, 31
high availability VRRP master/backup, 18
control packet mode configuration, 33
Track application collaboration, 37
displaying, 35
Track/application module association, 40
echo packet mode configuration, 33
Track/application module collaboration, 37
high availability VRRP tracking, 18
Track/policy-based routing association, 42
maintaining, 35
Track/static routing association, 41
multi-hop detection, 31
Track/VRRP association, 40
protocols and standards, 32
assigning
session establishment, 31
high availability IPv4 VRRP virtual IP
address, 20
session modes, 31
single-hop detection, 31
associating
static routing-Track-BFD collaboration, 53
Track/application module, 40
supported features, 32
Track/BFD, 38
Track BFD/VRRP backup master monitor, 47
Track/detection modules, 38
Track BFD/VRRP master uplink monitor, 50
Track/interface management, 39
Track/NQA, 38
Track/policy-based routing, 42
Track/static routing, 41
Track/VRRP, 40
Track/BFD association, 38
BGP
high availability BFD supported, 32
bidirectional
forwarding detection. Use BFD
attribute
high availability IPv4 VRRP packet attribute, 22
authenticating
high availability DLDP MD5 authentication, 7
high availability DLDP port state, 2
C
collaborating
high availability DLDP MD5 mode, 3
static routing-Track-BFD collaboration, 53
high availability DLDP non-authentication
mode, 3
Track application collaboration, 37
Track BFD/VRRP backup master monitor, 47
high availability DLDP password
authentication, 7
Track BFD/VRRP master uplink monitor, 50
Track configuration, 36, 37, 43
high availability DLDP plaintext
authentication, 7
Track/application modules, 37
Track/detection modules, 36
high availability DLDP plaintext mode, 3
63
high availability DLDP single neighbor detection, 3
VRRP-Track-interface management
collaboration, 57
Track application collaboration, 37
VRRP-Track-NQA collaboration, 43
Track configuration, 36
configuring
Track/application module collaboration, 37
high availability BFD, 31
Track/BFD association, 38
high availability BFD basic functions, 33
Track/detection module association, 38
high availability BFD control packet mode, 33
Track/detection module collaboration, 36
high availability BFD echo packet mode, 33
Track/interface management association, 39
high availability DLDP, 1, 5, 8
high availability DLDP authentication, 7
Track/NQA association, 38
device
high availability DLDP automatic unidirectional
link shutdown, 8
high availability DLDP automatic unidirectional link
shutdown, 8
high availability IPv4 VRRP, 20, 24
high availability DLDP configuration, 1, 5, 8
high availability IPv4 VRRP multiple groups, 27
high availability DLDP manual unidirectional link
shutdown, 11
high availability IPv4 VRRP packet attributes, 22
high availability IPv4 VRRP configuration, 24
high availability IPv4 VRRP router preemptive
mode, 21
high availability IPv4 VRRP router priority, 21
high availability IPv4 VRRP multiple groups
configuration, 27
high availability IPv4 VRRP router tracking
function, 21
high availability IPv4 VRRP router preemptive
mode, 21
high availability IPv4 VRRP single group, 24
high availability IPv4 VRRP router priority, 21
high availability VRRP, 15
high availability IPv4 VRRP router tracking, 21
static routing-Track-BFD collaboration, 53
high availability IPv4 VRRP single group
configuration, 24
Track, 36, 37, 43
high availability VRRP group router priority, 16
Track BFD/VRRP backup master monitor, 47
high availability VRRP router preemption modes, 16
Track BFD/VRRP master uplink monitor, 50
VRRP-Track-interface management
collaboration, 57
high availability VRRP tracking, 18
VRRP-Track-NQA collaboration, 43
static routing-Track-BFD collaboration, 53
link detection protocol. Use DLDP
confirmed DLDP neighbor state, 2
Track BFD/VRRP backup master monitor, 47
controlling
Track BFD/VRRP master uplink monitor, 50
Track configuration, 43
high availability BFD control packet mode, 33
VRRP-Track-interface management collaboration, 57
creating
VRRP-Track-NQA collaboration, 43
high availability IPv4 VRRP group, 20
disabling
D
DelayDown timer (DLDP), 2, 6
detecting
high availability IPv4 VRRP group, 23
displaying
high availability BFD, 35
high availability BFD configuration, 31
high availability DLDP, 7
high availability DLDP automatic unidirectional
link shutdown, 8
high availability DLDP configuration, 1, 5, 8
high availability DLDP manual unidirectional
link shutdown, 11
high availability IPv4 VRRP, 24
track entries, 43
DLDP
advertisement packet send interval, 6
authentication configuration, 7
high availability DLDP multiple neighbors
detection, 5
authentication modes, 3
64
automatic unidirectional link shutdown, 8
displaying BFD, 35
basic concepts, 2
displaying IPv4 VRRP, 24
configuration, 1, 5, 8
displaying track entries, 43
configuration restrictions, 5
DLDP automatic unidirectional link shutdown, 8
DelayDown timer, 6
DLDP configuration, 1, 5, 8
displaying, 7
DLDP manual unidirectional link shutdown, 11
enabling, 5
IPv4 VRRP configuration, 20, 24
how it works, 3
IPv4 VRRP group creation, 20
maintaining, 7
IPv4 VRRP group disable, 23
manual unidirectional link shutdown, 11
IPv4 VRRP multiple groups configuration, 27
multiple neighbors detection, 5
IPv4 VRRP packet attribute, 22
neighbor states, 2
IPv4 VRRP router preemptive mode, 21
port shutdown mode, 6
IPv4 VRRP router priority, 21
port states, 2
IPv4 VRRP router tracking, 21
single neighbor detection, 3
IPv4 VRRP single group configuration, 24
timers, 2
IPv4 VRRP version specification, 20
IPv4 VRRP virtual IP address assignment, 20
E
maintaining BFD, 35
echo
maintaining IPv4 VRRP, 24
high availability BFD echo packet mode, 33
static routing-Track-BFD collaboration, 53
high availability DLDP echo timer, 2
Track application collaboration, 37
electing
Track BFD/VRRP backup master monitor, 47
high availability VRRP master election, 18
Track BFD/VRRP master uplink monitor, 50
enabling
Track configuration, 36, 37, 43
high availability DLDP, 5
troubleshooting VRRP, 29
high availability VRRP SNMP notification, 23
troubleshooting VRRP error prompt displayed, 29
enhanced timer (DLDP), 2
troubleshooting VRRP fast state flapping, 30
entry timer (DLDP), 2
troubleshooting VRRP multiple masters appear in
group, 30
establishing
high availability BFD session establishment, 31
VRRP application, 18
F
VRRP authentication methods, 17
fast failure detection (BFD), 31
VRRP configuration, 15
VRRP group router priority, 16
fault detection
VRRP operating mode, 15
high availability BFD basic configuration, 33
VRRP protocols and standards, 20
high availability BFD configuration, 31
VRRP router preemption, 16
forwarding
bidirectional detection. Use BFD
VRRP SNMP notification, 23
high availability BFD support for IP FRR, 32
VRRP timers, 17
VRRP standard operating mode, 16
FRR
VRRP tracking, 18
H
VRRP-Track-interface management collaboration, 57
hardware
high availability BFD configuration, 31
high availability
BFD configuration, 31
VRRP-Track-NQA collaboration, 43
I
inactive
65
high availability BFD basic configuration, 33
high availability DLDP port state, 2
initial DLDP port state, 2
high availability BFD configuration, 31
interface management
high availability BFD supported features, 32
VRRP-Track-interface management
collaboration, 57
line
high availability DLDP DelayDown line failure
timer, 6
interval
high availability DLDP advertisement packet
send interval, 6
link
high availability DLDP automatic unidirectional link
shutdown, 8
IP addressing
high availability DLDP configuration, 1, 5, 8
high availability IPv4 VRRP virtual IP address
assignment, 20
high availability DLDP manual unidirectional link
shutdown, 11
high availability VRRP configuration, 15
load balancing
IPv4
high availability VRRP. See IPv4 VRRP
high availability IPv4 VRRP group creation, 20
IPv4 VRRP
high availability IPv4 VRRP group disable, 23
configuration, 20, 24
high availability IPv4 VRRP packet attribute, 22
displaying, 24
high availability IPv4 VRRP router preemptive
mode, 21
group creation, 20
high availability IPv4 VRRP router priority, 21
group disable, 23
high availability IPv4 VRRP router tracking, 21
maintaining, 24
high availability IPv4 VRRP version specification, 20
multiple groups configuration, 27
high availability IPv4 VRRP virtual IP address
assignment, 20
packet attribute configuration, 22
router preemptive mode configuration, 21
high availability VRRP load-balancing operating
mode, 15
router priority configuration, 21
router tracking function configuration, 21
single group configuration, 24
SNMP notification enable, 23
load-sharing
high availability VRRP application, 19
version specification, 20
M
virtual IP address assignment, 20
maintaining
IPv6
high availability BFD, 35
high availability BFD protocols and
standards, 32
high availability BFD-supported static
routing, 32
high availability DLDP, 7
high availability IPv4 VRRP, 24
master
high availability VRRP master election, 18
high availability VRRP. See IPv6 VRRP
high availability VRRP master/backup
application, 18
IPv6 BGP
high availability BFD supported, 32
high availability VRRP multiple masters appear in
group, 30
IPv6 IS-IS
high availability BFD supported, 32
MD5
IPv6 PIM
high availability DLDP authentication, 7
high availability BFD supported, 32
IS-IS
high availability DLDP authentication mode, 3
MD5 authentication
high availability BFD supported, 32
L
high availability VRRP, 17
mode
Layer 3
66
high availability BFD control packet active
operating mode, 31
high availability BFD control packet
asynchronous operating mode, 31
high availability BFD control packet demand
operating mode, 31
high availability BFD control packet
mode, 31, 33
high availability BFD control packet passive
operating mode, 31
high availability BFD echo packet mode, 31, 33
VRRP-Track-interface management collaboration, 57
VRRP-Track-NQA collaboration, 43
multi-hop
high availability BFD control packet mode, 33
high availability BFD mode, 31
multi-hop detection (BFD), 33
multiple neighbors detection (DLDP), 5
N
neighbor
high availability BFD multi-hop detection, 31
high availability DLDP multiple neighbors
detection, 5
high availability BFD single-hop detection, 31
high availability DLDP neighbor state, 2
high availability DLDP MD5 authentication, 3
high availability DLDP non-authentication, 3
high availability DLDP single neighbor detection, 3
network
high availability DLDP plaintext
authentication, 3
high availability BFD control packet mode
configuration, 33
high availability DLDP port shutdown auto
mode, 6
high availability BFD echo packet mode
configuration, 33
high availability DLDP port shutdown manual
mode, 6
high availability DLDP authentication, 7
high availability IPv4 VRRP router preemptive
mode, 21
high availability DLDP multiple neighbors
detection, 5
high availability DLDP authentication modes, 3
high availability VRRP load-balancing
operation, 15
high availability DLDP single neighbor detection, 3
high availability IPv4 VRRP group creation, 20
high availability VRRP router non-preemptive
mode, 16
high availability IPv4 VRRP group disable, 23
high availability IPv4 VRRP packet attribute, 22
high availability VRRP router preemptive
mode, 16
high availability IPv4 VRRP router preemptive
mode, 21
high availability VRRP standard operating
mode, 16
high availability IPv4 VRRP router priority, 21
high availability IPv4 VRRP router tracking, 21
high availability VRRP standard operation, 15
high availability IPv4 VRRP version specification, 20
module
high availability IPv4 VRRP virtual IP address
assignment, 20
static routing-Track-BFD collaboration, 53
Track application collaboration, 37
high availability VRRP application, 18
Track BFD/VRRP backup master monitor, 47
high availability VRRP master election, 18
Track BFD/VRRP master uplink monitor, 50
high availability VRRP timers, 17
Track configuration, 36, 37, 43
high availability VRRP tracking, 18
Track/application module association, 40
Track application collaboration, 37
Track/application module collaboration, 37
Track/application module association, 40
Track/detection module association, 38
Track/BFD association, 38
Track/detection module collaboration, 36
Track/detection module association, 38
Track/interface management association, 39
Track/interface management association, 39
Track/policy-based routing association, 42
Track/NQA association, 38
Track/static routing association, 41
Track/policy-based routing association, 42
Track/VRRP association, 40
Track/static routing association, 41
67
high availability DLDP authentication, 7
Track/VRRP association, 40
high availability DLDP authentication mode, 3
network management
high availability BFD basic configuration, 33
policy-based routing
high availability BFD configuration, 31
Track/application module collaboration, 37
high availability DLDP automatic unidirectional
link shutdown, 8
policy-based routing (PBR)
high availability DLDP configuration, 1, 5, 8
port
high availability DLDP manual unidirectional
link shutdown, 11
Track/policy-based routing association, 42
high availability DLDP automatic unidirectional link
shutdown, 8
high availability IPv4 VRRP
configuration, 20, 24
high availability DLDP configuration, 1, 5, 8
high availability IPv4 VRRP multiple groups
configuration, 27
high availability DLDP manual unidirectional link
shutdown, 11
high availability DLDP DelayDown timer, 6
high availability IPv4 VRRP single group
configuration, 24
high availability VRRP configuration, 15
static routing-Track-BFD collaboration, 53
high availability DLDP port shutdown mode, 6
high availability DLDP port state, 2
preempting
high availability IPv4 VRRP router preemptive
mode, 21
Track BFD/VRRP backup master monitor, 47
Track BFD/VRRP master uplink monitor, 50
high availability VRRP non-preemptive mode, 16
Track configuration, 36, 37, 43
VRRP-Track-interface management
collaboration, 57
VRRP-Track-NQA collaboration, 43
high availability VRRP preemption delay timer, 17
high availability VRRP preemptive mode, 16
priority
high availability IPv4 VRRP router priority, 21
non-authentication mode (DLDP), 3
NQA
high availability VRRP tracking, 18
Track/NQA association, 38
high availability VRRP group router priority, 16
probe timer (DLDP), 2
procedure
assigning high availability IPv4 VRRP virtual IP
address, 20
VRRP-Track-NQA collaboration, 43
O
associating Track/application module, 40
OSPF
associating Track/BFD, 38
associating Track/detection modules, 38
high availability BFD-supported, 32
associating Track/interface management, 39
OSPFv3
associating Track/NQA, 38
high availability BFD-supported, 32
associating Track/policy-based routing, 42
P
associating Track/static routing, 41
packet
associating Track/VRRP, 40
high availability BFD control packet mode, 33
high availability BFD echo packet mode, 33
configuring high availability BFD basic
functions, 33
high availability DLDP advertisement packet
send interval, 6
configuring high availability BFD control packet
mode (multi-hop detection), 33
high availability IPv4 VRRP packet attribute, 22
configuring high availability BFD control packet
mode (single-hop detection), 33
password
high availability DLDP authentication, 7
configuring high availability BFD echo packet
mode, 33
high availability BFD supported, 32
configuring high availability DLDP, 5, 8
PIM
configuring high availability DLDP authentication, 7
plaintext
68
configuring high availability DLDP automatic
unidirectional link shutdown, 8
troubleshooting high availability VRRP error prompt
displayed, 29
configuring high availability IPv4 VRRP, 20, 24
troubleshooting high availability VRRP multiple
masters appear in group, 30
configuring high availability IPv4 VRRP multiple
groups, 27
configuring high availability IPv4 VRRP packet
attributes, 22
configuring high availability IPv4 VRRP router
preemptive mode, 21
configuring high availability IPv4 VRRP router
priority, 21
troubleshooting VRRP fast state flapping, 30
protocols and standards
high availability BFD, 32
high availability VRRP, 20
R
recoverprobe timer (DLDP), 2
configuring high availability IPv4 VRRP router
tracking function, 21
restrictions
configuring high availability IPv4 VRRP single
group, 24
RIP
configuring static routing-Track-BFD
collaboration, 53
router
high availability DLDP configuration, 5
high availability BFD-supported, 32
high availability IPv4 VRRP router preemptive
mode, 21
configuring Track, 37, 43
configuring Track BFD/VRRP backup master
monitor, 47
high availability IPv4 VRRP router priority, 21
high availability IPv4 VRRP router tracking, 21
configuring Track BFD/VRRP master uplink
monitor, 50
high availability VRRP group priority, 16
configuring VRRP-Track-interface management
collaboration, 57
high availability VRRP preemption modes, 16
configuring VRRP-Track-NQA collaboration, 43
creating high availability IPv4 VRRP group, 20
high availability VRRP master election, 18
virtual router redundancy protocol. Use VRRP
routing
high availability DLDP automatic unidirectional link
shutdown, 8
disabling high availability IPv4 VRRP group, 23
displaying high availability BFD, 35
high availability DLDP configuration, 1, 5, 8
displaying high availability DLDP, 7
high availability DLDP manual unidirectional link
shutdown, 11
displaying high availability IPv4 VRRP, 24
displaying track entries, 43
high availability VRRP configuration, 15
enabling high availability DLDP, 5
static routing-Track-BFD collaboration, 53
enabling high availability VRRP SNMP
notification, 23
Track/policy-based routing association, 42
Track/policy-based routing collaboration, 37
maintaining high availability BFD, 35
Track/static routing association, 41
maintaining high availability DLDP, 7
maintaining high availability IPv4 VRRP, 24
setting high availability DLDP advertisement
packet send interval, 6
Track/static routing collaboration, 37
S
security
setting high availability DLDP DelayDown
timer, 6
high availability DLDP authentication, 7
setting high availability DLDP port shutdown
mode, 6
high availability VRRP MD5 authentication, 17
shutting down high availability DLDP
unidirectional link manually, 11
high availability DLDP authentication modes, 3
high availability VRRP simple authentication, 17
session
high availability BFD control packet active
operating mode, 31
specifying high availability IPv4 VRRP
version, 20
69
high availability BFD control packet
asynchronous operating mode, 31
high availability IPv4 VRRP single group
configuration, 24
high availability BFD control packet demand
operating mode, 31
high availability VRRP configuration, 15
high availability BFD control packet mode, 31
switch
high availability IPv4 VRRP configuration, 24
high availability BFD control packet passive
operating mode, 31
high availability IPv4 VRRP multiple groups
configuration, 27
high availability BFD echo packet mode, 31
high availability IPv4 VRRP single group
configuration, 24
high availability BFD session establishment, 31
setting
high availability DLDP advertisement packet
send interval, 6
T
timer
high availability DLDP advertisement, 2
high availability DLDP DelayDown timer, 6
high availability DLDP DelayDown, 2, 6
high availability DLDP port shutdown mode, 6
high availability DLDP echo, 2
shutting down
high availability DLDP enhanced, 2
high availability DLDP automatic unidirectional
link shutdown, 8
high availability DLDP entry, 2
high availability DLDP port shutdown mode, 6
high availability DLDP probe, 2
high availability DLDP unidirectional link
manually, 11
high availability VRRP advertisement interval, 17
high availability DLDP recoverprobe, 2
high availability VRRP preemption delay timer, 17
simple authentication
high availability VRRP Skew-Time, 17
high availability VRRP, 17
single neighbor detection (DLDP), 3
Track
application collaboration, 37
single-hop
high availability BFD control packet mode, 33
application module association, 40
high availability BFD mode, 31
BFD association, 38
BFD/VRRP backup master monitor
configuration, 47
single-hop detection (BFD), 33
Skew-Time (VRRP), 17
BFD/VRRP master uplink monitor configuration, 50
specifying
collaboration between Track and application
modules, 37
high availability IPv4 VRRP version, 20
standard operating mode (VRRP), 15, 16
collaboration between Track and detection
modules, 36
state
high availability DLDP neighbor state, 2
configuration, 36, 37, 43
high availability DLDP port state, 2
detection module association, 38
static
displaying entries, 43
high availability BFD supported static
routing, 32
high availability BFD supported, 32
high availability IPv4 VRRP router tracking, 21
static routing
interface management association, 39
static routing-Track-BFD collaboration, 53
NQA association, 38
Track/application module collaboration, 37
policy-based routing association, 42
Track/static routing association, 41
static routing association, 41
subnetting
static routing-Track-BFD collaboration
configuration, 53
high availability IPv4 VRRP
configuration, 20, 24
VRRP association, 40
high availability IPv4 VRRP multiple groups
configuration, 27
70
VRRP-Track-interface management collaboration
configuration, 57
router preemption, 16
VRRP-Track-NQA collaboration
configuration, 43
Track BFD/VRRP backup master monitor, 47
timers, 17
Track BFD/VRRP master uplink monitor, 50
tracking
Track/application module collaboration, 37
high availability VRRP, 18
Track/VRRP association, 40
traffic management
tracking, 18
Track/application module collaboration, 37
troubleshooting, 29
troubleshooting
troubleshooting error prompt displayed, 29
high availability VRRP, 29
troubleshooting fast state flapping, 30
high availability VRRP error prompt
displayed, 29
troubleshooting multiple masters appear in
group, 30
high availability VRRP fast state flapping, 30
VRRP-Track-interface management collaboration, 57
high availability VRRP multiple masters appear
in group, 30
VRRP-Track-NQA collaboration, 43
U
unconfirmed DLDP neighbor state, 2
unidirectional
high availability DLDP automatic unidirectional
link shutdown, 8
high availability DLDP manual unidirectional
link shutdown, 11
high availability DLDP port state, 2
uplink
Track BFD/VRRP master uplink monitor, 50
V
version
high availability IPv4 VRRP specification, 20
virtual
high availability IPv4 VRRP virtual IP address
assignment, 20
router redundancy protocol. Use VRRP
VRRP
application, 18
authentication methods, 17
configuration, 15
group router priority, 16
IPv4. See IPv4 VRRP
IPv6. See IPv6 VRRP
load-sharing application, 19
master election, 18
master/backup application, 18
operating mode (load-balancing), 15
operating mode (standard), 15, 16
protocols and standards, 20
71
Download PDF
Similar pages