HP 10500 Switch Series network switches Configuration Guide
Below you will find brief information for network switches 10500 Switch Series. This document will guide you through the process of configuring high availability features on your HP 10500 Switch Series, enabling you to increase network reliability and minimize downtime. The guide covers various technologies like active and standby switchover, Ethernet OAM, CFD, DLDP, RRPP, Smart Link, Monitor Link, and VRRP, providing step-by-step instructions and configuration examples for implementing these features in your network.
advertisement
Assistant Bot
Need help? Our chatbot has already read the manual and is ready to assist you. Feel free to ask any questions about the device, but providing details will make the conversation more productive.
HP 10500 Switch Series
High Availability
Configuration Guide
Part number: 5998-2215
Software version: Release 1201 and later
Document version: 6W102-20130530
Legal and notice information
© Copyright 2013 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.
The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
Contents
i
ii
iii
iv
v
High availability overview
Because communication interruptions can seriously affect widely deployed value-added services, such as
IPTV and video conference, basic network infrastructures must be able to provide high availability.
The following are the effective ways to improve availability:
•
Increasing fault tolerance
•
Speeding up fault recovery
• Reducing impact of faults on services
Availability requirements
describes a typical availability model that divides availability requirements into different levels.
Table 1 Availability requirements
Level Requirements Solution
1
Decrease system software and hardware faults.
•
Hardware—Simplified circuit design, enhanced production techniques, and reliability tests.
•
Software—Reliability design and test.
2
Protect system functions from being affected by failures.
Device and link redundancy and switchover.
3
Enable the system to recover as fast as possible.
Fault detection, diagnosis, isolation, and recovery technologies.
Consider level 1 availability requirements during the design and production processes of network devices.
Consider level 2 availability requirements during network design.
Consider level 3 availability requirements during network deployment, according to the network infrastructure and service characteristics.
Availability evaluation
MTBF and MTTR are used to evaluate the availability of a network.
MTBF
MTBF is the predicted elapsed time between inherent failures of a system during operation. It is typically expressed in hours. A higher MTBF means a higher availability.
MTTR
MTTR is the average time required to repair a failed system. MTTR in a broad sense also involves spare parts management and customer services.
MTTR = fault detection time + hardware replacement time + system initialization time + link recovery time + routing time + forwarding recovery time. A smaller value of each item means a smaller MTTR and higher availability.
1
High availability technologies
Increasing MTBF or decreasing MTTR can enhance the availability of a network. The high availability technologies described in this section meet the level 2 and level 3 high-availability requirements in the aspect of decreasing MTTR.
High availability technologies can be classified as fault detection technologies or protection switchover technologies.
Fault detection technologies
Fault detection technologies enable detection and diagnosis of network faults.
•
CFD, DLDP, and Ethernet OAM are data link layer fault detection technologies.
• BFD is a generic fault detection technology that can be used at any layer
•
NQA is used for diagnosis and evaluation of network quality.
•
Monitor Link and Track work along with other high availability technologies to detect faults through a collaboration mechanism.
Table 2 Fault detection technologies
Technology Introduction
CFD
CFD, which conforms to IEEE 802.1ag Connectivity Fault
Management, is an end-to-end per-VLAN link layer Operations,
Administration and Maintenance mechanism used for link connectivity detection, fault verification, and fault location.
DLDP
Ethernet OAM
BFD
The DLDP deals with unidirectional links that may occur in a network.
When detecting a unidirectional link, DLDP, as configured, can shut down the related port automatically or prompt users to take actions to avoid network problems.
As a tool monitoring Layer 2 link status, Ethernet OAM is mainly used to address common link-related issues on the last mile. You can monitor the status of the point-to-point link between two directly-connected devices by enabling Ethernet OAM on the two devices.
BFD provides a single mechanism to quickly detect and monitor the connectivity of links or IP forwarding in networks. Devices must quickly detect communication failures to restore communication through backup paths as soon as possible to improve network performance.
NQA
Monitor Link
Reference
"
"
"
"
"
"
"
NQA analyzes network performance, services, and service quality through sending test packets, and provides network performance and service quality parameters, such as jitter, TCP connection delay, FTP connection delay, and file transfer rate.
Network
Management and
Monitoring
Configuration
Guide
Monitor Link works together with Layer 2 topology protocols to adapt the up/down state of a downlink port to the state of an uplink port. This feature enables fast link switchover on a downstream device in response to the uplink state change on its upstream device.
"
"
2
Technology Introduction
Track
The track module implements collaboration between different modules. The collaboration involves three sets of modules: application, track, and detection. These modules collaborate with one another through collaboration entries. The detection modules trigger the application modules to perform certain operations through the track module. The detection modules probe such items as link status and network performance, and inform the application modules of the detection result through the track module. Once notified of network status changes, the application modules use the changes to avoid communication interruption and network performance degradation.
Reference
"
Protection switchover technologies
Protection switchover technologies aim at recovering network faults. They back up hardware, link, routing, and service information for switchover in case of network faults to ensure continuity of network services.
A single availability technology cannot solve all problems. You should use a combination of availability technologies, chosen on the basis of detailed analysis of network environments and user requirements, to enhance network availability. For example, access-layer devices should be connected to distribution-layer devices over redundant links, and core-layer devices should be fully meshed. Network availability should be considered during the planning stage.
Table 3 Protection switchover technologies
Technology Introduction
Active and standby switchover
Devices supporting active and standby switchover are normally equipped with two MPUs, with one being the active MPU, and the other being the standby MPU. The configurations on the standby
MPU are the same as those on the active MPU. When the active
MPU fails or is removed, the standby MPU automatically becomes the active MPU to ensure non-stop operating of the devices.
Ethernet link aggregation
Smart Link
Ethernet link aggregation, or link aggregation, aggregates multiple physical Ethernet links into one logical link to increase link bandwidth beyond the limits of any one single link. This logical link is an aggregate link. It allows for link redundancy because the member physical links can dynamically back up one another.
Smart Link addresses the slow convergence issue with the spanning tree protocol. It provides link redundancy as well as fast convergence in a dual uplink network, allowing the backup link to quickly take over when the primary link fails.
MSTP
RRPP
As a Layer 2 management protocol, the MSTP eliminates Layer 2 loops by selectively blocking redundant links in a network, and in the meantime, allows for link redundancy.
The RRPP is a link layer protocol designed for Ethernet rings. RRPP can prevent broadcast storms caused by data loops when an
Ethernet ring is healthy, and rapidly restore the communication paths between the nodes in the event that a link is disconnected on the ring.
Reference
" Configuring active and standby switchover
"
Layer 2—LAN
Switching
Configuration Guide
"
Layer 2—LAN
Switching
Configuration Guide
3
Technology Introduction
FRR
GR
NSR
VRRP
FRR provides a quick per-link or per-node protection on an LSP.
Once a link or node fails on a path, FRR reroutes the path to a new link or node to bypass the failed link or node. This can happen as fast as 50 milliseconds minimizing data loss. Protocols such as RIP,
OSPF, IS-IS, static routing, and RSVP-TE support this technology.
GR ensures the continuity of packet forwarding when a protocol, such as BGP, IS-IS, OSPF, IPv6 BGP, IPv6 IS-IS, OSPFv3, LDP, or
RSVP-TE, restarts, or during an active/standby switchover process.
It needs other devices to implement routing information backup and recovery.
NSR ensures non-stop data transmission during an active/standby switchover by backing up IP forwarding information from the active
MPU to the standby MPU. Upon an active/standby switchover,
NSR can complete link state recovery and route re-generation without requiring the cooperation of other devices. OSPF supports this feature.
VRRP is an error-tolerant protocol, which provides highly reliable default links on multicast and broadcast LANs such as Ethernet, avoiding network interruption due to failure of a single link.
Reference
Layer 3—IP Routing
Configuration Guide,
MPLS Configuration
Guide, and configuration guide of the corresponding protocols
Related chapters in
Layer 3—IP Routing
Configuration Guide and MPLS
Configuration Guide
Layer 3—IP Routing
Configuration Guide
4
Configuring active and standby switchover
The switch supports configuring two MPUs. The system uses the MPU with a smaller slot number as the active
MPU, and the other MPU as the standby MPU. The standby MPU keeps its configuration the same as the active MPU through the synchronization function. When the active MPU fails, the standby MPU becomes the active MPU to process services to ensure normal operation of the device. This switchover process is called an active and standby switchover.
Active and standby switchover functions in the following ways:
•
Automatic active and standby switchover—If the active MPU fails or is removed, the system automatically performs an active and standby switchover to enable the standby MPU to function as the active MPU.
•
Manual active and standby switchover—An active and standby switchover performed at the CLI.
Configuration restrictions and guidelines
•
All commands except the display switchover state command take effect only when the switch is operating in standalone mode. For more information about IRF, see IRF Configuration Guide.
• Active/standby switchover configuration tasks must be performed at the CLI of the active MPU. The system can automatically propagate the configuration to the standby MPU.
•
When you upgrade the switch, make sure the software versions of the active and standby MPUs are the same, and reboot the switch after upgrade.
Active and standby switchover configuration task list
Task Remarks
Ignoring version check for the standby MPU
Optional.
Manually performing an active and standby switchover
Optional.
Optional.
Ignoring version check for the standby MPU
To ensure normal device operation, HP recommends running the same software version on the active MPU and the standby MPU.
When the standby MPU attempts to start up, by default the system examines its software version against the active MPU's software version for inconsistency. If the versions of the active MPU and standby MPU are not consistent, the standby MPU cannot be started.
To disable the system from examining the standby MPU's software version:
Step Command
1. Enter system view.
Remarks system-view N/A
5
Step Command
2. Ignore version check for the standby MPU. ha slave-ignore-version-check
Remarks
By default, version check is enabled for the standby MPU.
NOTE:
If the software differences between the active and standby MPUs could possibly affect the normal operation of the device, the system will prevent the standby MPU from starting up, even if software version check has been disabled.
Restarting the standby MPU
You can manually restart the standby MPU. Before restarting, check the consistency of the versions of the active MPU and standby MPU. If they are not consistent, configure the system to ignore version check of the standby MPU.
After the standby MPU is restarted, the active MPU will perform initial synchronization on the standby MPU.
During this process, the system will not respond to your input. After the initial synchronization is completed, you can execute all configuration commands on the active MPU. The active MPU and standby MPU will keep a real-time synchronization process. Your configuration on the active MPU will be copied to the standby MPU to ensure the consistency of the current configuration of the active MPU and standby MPU.
To restart the standby MPU:
Step Command
1. Enter system view. system-view
2. Manually restart the standby MPU. slave restart
Manually performing an active and standby switchover
To avoid service interruption when you upgrade the active MPU, perform a manual active and standby switchover.
Before the switchover, verify that the standby MPU is running the same software version as the active MPU or software version check is disabled for the standby MPU.
To manually perform an active and standby switchover:
Step Command
1. Enter system view. system-view
2. Enable manual active and standby switchover. slave switchover { disable | enable }
Remarks
N/A
Optional.
By default, manual active and standby switchover is enabled.
3. Manually perform an active and standby switchover. slave switchover N/A
6
Displaying and maintaining active and standby switchover
Remarks Task Command
Display the switchover state of
MPUs (in standalone mode). display switchover state [ slot
slot-number ] [ | { begin | exclude
| include } regular-expression ]
Display the switchover state of
MPUs (in IRF mode). display switchover state [ chassis
chassis-number slot
slot-number ] [ | { begin | exclude
| include } regular-expression ]
Available in any view.
Available in any view.
7
Configuring Ethernet OAM
This chapter describes how to configure Ethernet OAM.
Overview
As a tool that monitors Layer 2 link status, Ethernet OAM addresses common link-related issues on the last mile. Ethernet OAM improves Ethernet management and maintainability. You can use it to monitor the status of the point-to-point link between two directly connected devices.
Major functions of Ethernet OAM
Ethernet OAM provides the following functions:
• Link performance monitoring—Monitors the performance indices of a link, including packet loss, delay, and jitter, and collects traffic statistics of various types.
•
Fault detection and alarm—Examines the connectivity of a link by sending OAMPDUs and reports to the network administrators when a link error occurs.
•
Remote loopback—Examines link quality and locates link errors by looping back OAMPDUs.
Ethernet OAMPDUs
Ethernet OAM operates on the data link layer. Ethernet OAM reports the link status by periodically exchanging OAMPDUs between devices so the administrator can effectively manage the network.
Throughout this document, an Ethernet OAM-enabled port is referred to as an Ethernet OAM entity or an
OAM entity.
Ethernet OAMPDUs include the following types: Information, Event Notification, and Loopback Control,
Figure 1 Formats of different types of Ethernet OAMPDUs
Table 4 OAMPDU fields
Field Description
Dest addr
Destination MAC address of the Ethernet OAMPDU.
It is a slow protocol multicast address 0180c2000002. Bridges cannot forward slow protocol packets, so Ethernet OAMPDUs cannot be forwarded.
8
Field Description
Source addr
Source MAC address of the Ethernet OAMPDU.
It is the bridge MAC address of the sending side and is a unicast MAC address.
Type
Subtype
Type of the encapsulated protocol in the Ethernet OAMPDU.
The value is 0x8809.
Protocol being encapsulated in the Ethernet OAMPDU.
The value is 0x03.
Status information of an Ethernet OAM entity. Flags
Code Type of the Ethernet OAMPDU.
Table 5 Functions of different types of OAMPDUs
OAMPDU type Function
Information OAMPDU
Transmits state information of an Ethernet OAM entity (including the information about the local device and remote devices, and customized information) to the remote Ethernet OAM entity. Also, maintains OAM connections.
Event Notification
OAMPDU
Loopback Control
OAMPDU
Used by link monitoring, notifies the remote OAM entity when it detects problems on the link in between.
Used for remote loopback control. By inserting the information used to enable/disable loopback to a loopback control OAMPDU, you can enable/disable loopback on a remote OAM entity.
How Ethernet OAM works
This section describes the working procedures of Ethernet OAM.
Establishing an Ethernet OAM connection
Ethernet OAM connection is the base of all of the other Ethernet OAM functions. Establishing the OAM connection is also known as the "Discovery phase," where an Ethernet OAM entity discovers the remote
OAM entity to establish a session.
In this phase, two connected OAM entities exchange Information OAMPDUs to advertise their OAM configuration and capabilities to each other for a comparison. If their Loopback, link detection, and link event settings match, the OAM entities establish an OAM connection.
An OAM entity operates in active mode or passive mode. OAM entities in active mode initiate OAM connections, and OAM entities in passive mode wait and respond to the OAM connection requests.
IMPORTANT:
To set up an OAM connection between two OAM entities, set at least one entity to operate in active mode.
shows the actions that a device can perform in different modes.
Table 6 Active Ethernet OAM mode and passive Ethernet OAM mode actions
Item
Initiating OAM Discovery
Active Ethernet OAM mode
Available
Passive Ethernet OAM mode
Unavailable
9
Item
Responding to OAM Discovery
Transmitting Information
OAMPDUs
Transmitting Event Notification
OAMPDUs
Transmitting Information
OAMPDUs without any TLV
Transmitting Loopback Control
OAMPDUs
Active Ethernet OAM mode
Available
Passive Ethernet OAM mode
Available
Available Available
Available Available
Available Available
Available Unavailable
Responding to Loopback Control
OAMPDUs
Available when both sides are operating in active OAM mode
Available
After an Ethernet OAM connection is established, the Ethernet OAM entities exchange Information
OAMPDUs at the handshake packet transmission interval to detect the availability of the Ethernet OAM connection. If an Ethernet OAM entity does not receive any Information OAMPDU within the Ethernet
OAM connection timeout time, the Ethernet OAM connection is considered disconnected.
Link monitoring
Error detection in an Ethernet is difficult, especially when the physical connection in the network is not disconnected, but network performance is degrading gradually.
Link monitoring detects link faults in various environments. Ethernet OAM entities monitor link status by exchanging Event Notification OAMPDUs. When detecting a link error event listed in
entity sends an Event Notification OAMPDU to its peer OAM entity. The network administrator can keep track of network status changes by retrieving the log.
The system transforms the period of detecting errored frame period events into the maximum number of
64-byte frames (excluding interframe spacing and preamble) that a port can send in the specified period.
The system takes the maximum number of frames sent as the period. The maximum number of frames sent is calculated using this formula:
Maximum number of frames = Interface bandwidth (bps) × errored frame period event detection period
(in ms)/(64 × 8 × 1000)
If errored frames appear in a certain second, that second is an errored frame second.
Table 7 Ethernet OAM link error events
Ethernet OAM link events
Errored symbol event
Errored frame event
Errored frame period event
Errored frame seconds event
Description
Number of detected symbol errors over a specific detection interval has exceeded the configured threshold.
Number of detected error frames over a specific interval has exceeded the configured threshold.
Number of frame errors in a specified number of received frames has exceeded the configured threshold.
Number of error frame seconds detected on a port over a specific detection interval has reached the error threshold.
10
Remote fault detection
Information OAMPDUs are exchanged periodically among Ethernet OAM entities across established
OAM connections. On a network where traffic is interrupted due to device failures or unavailability, the flag field defined in Information OAMPDUs allows an Ethernet OAM entity to send error information to its peer. (This can include any critical link event type shown in
.) In this way, you can keep track of link status through the log information and troubleshoot in a timely fashion.
•
The switch is able to receive Information OAMPDUs carrying the critical link events listed in Table
•
The switch does not support the sending of Information OAMPDUs carrying Link Fault events.
•
The switch is able to send Information OAMPDUs carrying Dying Gasp events when the device is rebooted or relevant ports are manually shut down. Physical IRF ports, however, are unable to send this type of OAMPDUs. For more information about physical IRF ports, see IRF Configuration Guide.
•
This Switch Series is unable to send Information OAMPDUs carrying Critical Events.
Table 8 Critical link events
Type Description
Link Fault Peer link signal is lost.
Dying Gasp
Critical Event
An unexpected fault, such as power failure, occurred.
An undetermined critical event happened.
OAMPDU transmission frequencies
Once per second.
Non-stop.
Non-stop.
Protocols and standards
Ethernet OAM is defined in IEEE 802.3ah (CSMA/CD) Access Method and Physical Layer
Specifications.
Ethernet OAM configuration task list
Task
Configuring basic Ethernet OAM functions
Configuring the Ethernet OAM connection detection timers
Configuring errored symbol event detection
Configuring errored frame event detection
Configuring errored frame period event detection
Configuring errored frame seconds event detection
Remarks
Required.
Optional.
Optional.
Optional.
Optional.
Optional.
Configuring basic Ethernet OAM functions
To set up an Ethernet OAM connection between two Ethernet OAM entities, you must set at least one entity to operate in active mode. Only in active mode can an Ethernet OAM entity initiate OAM connection. To change the Ethernet OAM mode on an Ethernet OAM-enabled port, first disable Ethernet
OAM on the port.
11
To configure basic Ethernet OAM functions:
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view. interface interface-type
interface-number
Remarks
N/A
N/A
3. Set the Ethernet OAM mode. oam mode { active | passive }
4. Enable Ethernet OAM on the current port. oam enable
Optional.
The default is active Ethernet OAM mode.
By default, Ethernet OAM is disabled.
Configuring the Ethernet OAM connection detection timers
CAUTION:
After the timeout timer of an Ethernet OAM connection expires, the local OAM entity ages out its connection with the peer OAM entity, causing the OAM connection to disconnect. HP recommends setting the connection timeout timer at least five times the handshake packet transmission interval to ensure the stability of Ethernet OAM connections.
After an Ethernet OAM connection is established, the Ethernet OAM entities exchange Information
OAMPDUs at the handshake packet transmission interval to detect the availability of the Ethernet OAM connection. If an Ethernet OAM entity receives no Information OAMPDU within the Ethernet OAM connection timeout time, the Ethernet OAM connection is considered disconnected.
By adjusting the handshake packet transmission interval and the connection timeout timer, you can change the detection time resolution for Ethernet OAM connections.
To configure the Ethernet OAM connection detection timers:
Step Command
1. Enter system view. system-view
2. Configure the Ethernet OAM handshake packet transmission interval. oam timer hello interval
3. Configure the Ethernet OAM connection timeout timer. oam timer keepalive interval
Remarks
N/A
Optional.
The default is 1000 milliseconds.
Optional.
The default is 5000 milliseconds.
Configuring link monitoring
After Ethernet OAM connections are established, the link monitoring periods and thresholds configured in this section automatically take effect on all Ethernet ports.
12
Configuring errored symbol event detection
An errored symbol event occurs when the number of detected symbol errors over a specific detection interval exceeds the configured threshold.
To configure errored symbol event detection:
Step Command
1. Enter system view. system-view
2. Configure the errored symbol event detection interval. oam errored-symbol period
period-value
3. Configure the errored symbol event triggering threshold. oam errored-symbol threshold
threshold-value
Remarks
N/A
Optional.
The default is 1 second.
Optional.
The default is 1.
Configuring errored frame event detection
An errored frame event occurs when the number of detected error frames over a specific interval exceeds the configured threshold.
To configure errored frame event detection:
Remarks
N/A
Step Command
1. Enter system view. system-view
2. Configure the errored frame event detection interval. oam errored-frame period period-value
3. Configure the errored frame event triggering threshold. oam errored-frame threshold
threshold-value
Optional.
The default is 1 second.
Optional.
The default is 1.
Configuring errored frame period event detection
An errored frame period event occurs if the number of frame errors in a specific number of received frames exceeds the configured threshold.
To configure errored frame period event detection:
Step Command
1. Enter system view. system-view
2. Configure the errored frame period event detection period. oam errored-frame-period period
period-value
3. Configure the errored frame period event triggering threshold.
oam errored-frame-period threshold threshold-value
Remarks
N/A
Optional.
The default is 1000.
Optional.
The default is 1.
13
Configuring errored frame seconds event detection
An errored frame seconds event occurs when the number of error frame seconds detected on a port over a detection interval exceeds the error threshold. Make sure the errored frame seconds triggering threshold is less than the errored frame seconds detection interval. Otherwise, no errored frame seconds event can be generated.
To configure errored frame seconds event detection:
Remarks
N/A
Step Command
1. Enter system view. system-view
2. Configure the errored frame seconds event detection interval. oam errored-frame-seconds period
period-value
3. Configure the errored frame seconds event triggering threshold. oam errored-frame-seconds threshold threshold-value
Optional.
The default is 60 seconds.
Optional.
The default is 1.
Displaying and maintaining Ethernet OAM configuration
Task Command
Display global Ethernet OAM configuration. display oam configuration [ |
{ begin | exclude | include }
regular-expression ]
Display the statistics on critical events after an Ethernet OAM connection is established. display oam critical-event
[ interface interface-type
interface-number ] [ | { begin | exclude | include }
regular-expression ]
Display the statistics on Ethernet
OAM link error events after an
Ethernet OAM connection is established.
Display information about an
Ethernet OAM connection. display oam link-event { local | remote } [ interface interface-type
interface-number ] [ | { begin | exclude | include }
regular-expression ] display oam { local | remote }
[ interface interface-type
interface-number ] [ | { begin | exclude | include }
regular-expression ]
Clear statistics on Ethernet OAM packets and Ethernet OAM link error events. reset oam [ interface interface-type
interface-number ]
Remarks
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in user view.
14
Ethernet OAM configuration example
Network requirements
On the network shown in Figure 2 , perform the following operations:
•
Enable Ethernet OAM on Device A and Device B to auto-detect link errors between the two devices.
•
Monitor the performance of the link between Device A and Device B by collecting statistics about the error frames received by Device A.
Figure 2 Network diagram
Configuration procedure
1. Configure Device A:
# Configure GigabitEthernet 1/0/1 to operate in passive Ethernet OAM mode and enable
Ethernet OAM for it.
<DeviceA> system-view
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] oam mode passive
[DeviceA-GigabitEthernet1/0/1] oam enable
[DeviceA-GigabitEthernet1/0/1] quit
# Set the errored frame detection interval to 20 seconds and set the errored frame event triggering threshold to 10.
[DeviceA] oam errored-frame period 20
[DeviceA] oam errored-frame threshold 10
2. On Device B, configure GigabitEthernet 1/0/1 to operate in active Ethernet OAM mode (the default) and enable Ethernet OAM for it.
<DeviceB> system-view
[DeviceB] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] oam mode active
[DeviceB-GigabitEthernet1/0/1] oam enable
[DeviceB-GigabitEthernet1/0/1] quit
Verifying the configuration
Use the display oam configuration command to display the Ethernet OAM configuration. For example:
# Display the Ethernet OAM configuration on Device A.
[DeviceA] display oam configuration
Configuration of the link event window/threshold :
--------------------------------------------------------------------------
Errored-symbol Event period(in seconds) : 1
Errored-symbol Event threshold : 1
Errored-frame Event period(in seconds) : 20
15
Errored-frame Event threshold : 10
Errored-frame-period Event period(in ms) : 1000
Errored-frame-period Event threshold : 1
Errored-frame-seconds Event period(in seconds) : 60
Errored-frame-seconds Event threshold : 1
Configuration of the timer :
--------------------------------------------------------------------------
Hello timer(in ms) : 1000
Keepalive timer(in ms) : 5000
The output shows that the detection period of errored frame events is 20 seconds, the detection threshold is 10 seconds, and all other parameters use the default values.
You can use the display oam critical-event command to display the statistics of Ethernet OAM critical link events. For example:
# Display the statistics of Ethernet OAM critical link events on all ports of Device A.
[DeviceA] display oam critical-event
Port : GigabitEthernet1/0/1
Link Status : Up
Event statistic :
-------------------------------------------------------------------------
Link Fault :0 Dying Gasp : 0 Critical Event : 0
The output shows that no critical link event occurred on the link between Device A and Device B.
You can use the display oam link-event command to display the statistics of Ethernet OAM link error events. For example:
# Display Ethernet OAM link event statistics of the remote end of Device B.
[DeviceB] display oam link-event remote
Port :GigabitEthernet1/0/1
Link Status :Up
OAMRemoteErrFrameEvent : (ms = milliseconds)
---------------------------------------------------------------------
Event Time Stamp : 5789 Errored FrameWindow : 200(100ms)
Errored Frame Threshold : 10 Errored Frame : 13
Error Running Total : 350 Event Running Total : 17
The output shows that 350 errors occurred after Ethernet OAM was enabled on Device A, 17 of which were caused by error frames. The link is unstable.
16
Configuring CFD
This chapter describes how to configure CFD.
Overview
CFD is an end-to-end per-VLAN link layer OAM mechanism used for link connectivity detection, fault verification, and fault location. It conforms to IEEE 802.1ag CFM.
Basic CFD concepts
This section explains the concepts of CFD.
MD
A MD defines the network or part of the network where CFD plays its role. An MD is identified by its MD name.
To accurately locate faults, CFD assigns eight levels ranging from 0 to 7 to MDs. The bigger the number, the higher the level, and the larger the area covered. If the outer domain has a higher level than the nested one, domains can touch or nest, but they cannot intersect or overlap.
MD levels facilitate fault location and its accuracy. As shown in
, MD_A in light blue nests MD_B in dark blue. If a connectivity fault is detected at the boundary of MD_A, any of the devices in MD_A, including Device A through Device E, may fail. If a connectivity fault is also detected at the boundary of
MD_B, the failure points may be any of Device B through Device D. If the devices in MD_B can operate properly, at least Device C is operational.
Figure 3 Two nested MDs
CFD exchanges messages and performs operations on a per-domain basis. By planning MDs properly in a network, you can use CFD to rapidly locate failure points.
17
MA
A MA is a part of an MD. You can configure multiple MAs in an MD as needed. An MA is identified by the "MD name + MA name".
An MA serves a VLAN. Packets sent by the MPs in an MA carry the relevant VLAN tag. An MP can receive packets sent by other MPs in the same MA. The level of an MA equals the level of the MD that the
MA belongs to.
MP
An MP is configured on a port and belongs to an MA. MPs include MEPs and MIPs.
•
MEPs
MEPs define the boundary of the MA. Each MEP is identified by a MEP ID.
The MA to which a MEP belongs defines the VLAN of packets sent by the MEP. The level of a MEP is equal to the level of the MD to which the MEP belongs, and the level of packets sent by a MEP equals the level of the MEP. The level of a MEP determines the levels of packets that the MEP can process. A MEP forwards packets at a higher level and processes packets of its own level or lower.
The processing procedure is specific to packets in the same VLAN. Packets of different VLANs are independent.
MEPs are either inward-facing or outward-facing. An outward-facing MEP sends packets to its host port. An inward-facing MEP does not send packets to its host port. Rather, it sends packets to other ports on the device.
•
MIP
A MIP is internal to an MA. It cannot send CFD packets actively. However, a MIP can handle and respond to CFD packets. By cooperating with MEPs, a MIP can perform a function similar to ping and traceroute. A MIP forwards packets of a different level without any processing and only processes packet of its own level.
The MA to which a MIP belongs defines the VLAN of packets that the MEP can receive. The level of a MIP is defined by its generation rule and the MD that the MIP belongs to. MIPs are generated on each port automatically according to related MIP generation rules. If a port has no MIP, the system will examine the MAs in each MD (from low to high levels), and follow the procedure as
to determine whether to create MIPs at the relevant level.
18
Figure 4 Procedure of creating MIPs
demonstrates a grading example of the CFD module. Four levels of MDs (0, 2, 3, and 5) are designed. The bigger the number, the higher the level, and the larger the area covered. MPs are configured on the ports of device A through device F. Port 1 of device B is configured with the following
MPs—a level 5 MIP, a level 3 inward-facing MEP, a level 2 inward-facing MEP, and a level 0 outward-facing MEP.
Figure 5 CFD grading example
MEP list
A MEP list is a collection of configurable local MEPs and the remote MEPs to be monitored in the same
MA. It lists all MEPs configured on different devices in the same MA. The MEPs all have unique MEP IDs.
19
When a MEP receives from a remote device a CCM with a MEP ID not included in the MEP list of the MA, it drops the message.
CFD functions
CFD works effectively only in properly configured networks. Its functions, which are implemented through the MPs, include:
•
Continuity check (CC)
• Loopback (LB)
• Linktrace (LT)
CC
Connectivity faults are usually caused by device faults or configuration errors. CC examines the connectivity between MEPs. This function is implemented through periodic sending of CCMs by the MEPs.
A CCM sent by one MEP is intended to be received by all of the other MEPs in the same MA. If a MEP fails to receive the CCMs within 3.5 times the sending interval, the link is considered faulty and a log is generated. When multiple MEPs send CCMs at the same time, the multipoint-to-multipoint link check is achieved. CCM frames are multicast frames.
LB
Similar to ping at the IP layer, LB verifies the connectivity between a source device and a target device.
To implement this function, the source MEP sends LBMs to the target MEP. Depending on whether the source MEP can receive a LBR from the target MEP, the link state between the two can be verified. LBM frames and LBR frames are unicast frames.
LT
LT is similar to traceroute. It identifies the path between the source MEP and the target MP. This function is implemented in the following way—the source MEP sends the LTMs to the target MP. After receiving the messages, the target MP and the MIPs that the LTM frames pass send back LTRs to the source MEP. Based on the reply messages, the source MEP can identify the path to the target MP. LTM frames are multicast frames and LTRs are unicast frames.
Protocols and standards
• IEEE 802.1ag, Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault
Management
CFD configuration task list
For CFD to operate properly, design the network by performing the following tasks:
•
Grade the MDs in the entire network and define the boundary of each MD.
•
Assign a name for each MD. Make sure the same MD has the same name on different devices.
• Define the MA in each MD according to the VLAN you want to monitor.
• Assign a name for each MA. Make sure the same MA in the same MD has the same name on different devices.
•
Determine the MEP list of each MA in each MD. Make sure devices in the same MA maintain the same MEP list.
20
• At the edges of MD and MA, MEPs should be designed at the device port. MIPs can be designed on devices or ports that are not at the edges.
Tasks Remarks
Required.
Optional.
Configuring basic CFD settings
Configuring the CFD protocol version
Creating a service instance with the MD name
Creating a service instance without the MD name
Configuring MIP generation rules
Required.
Perform either task.
Required.
Required.
Required.
Optional.
Optional.
Typically, a port blocked by the spanning tree feature cannot receive or send CFD messages except in the following cases:
• The port is configured as an outward-facing MEP.
•
The port is configured as a MIP or an inward-facing MEP that can still receive and send CFD messages except CCM messages.
For more information about the spanning tree feature, see Layer 2—LAN Switching Configuration Guide.
Configuring basic CFD settings
This section provides procedures for configuring basic CFD settings.
Enabling CFD
Enable CFD before you perform other configuration tasks.
To enable CFD on a device:
Step Command
1. Enter system view. system-view
2. Enable CFD. cfd enable
Remarks
N/A
By default, CFD is disabled.
Configuring the CFD protocol version
Three CFD protocol versions are available: IEEE 802.1ag draft5.2 version, IEEE 802.1ag draft5.2 interim version, and IEEE 802.1ag standard version. This Switch Series supports only the standard version of
IEEE 802.1ag.
Devices in the same MD must use the same CFD protocol version. Otherwise, they cannot exchange CFD protocol packets.
21
If an MD is created by using the cfd md command or automatically generated by using the cfd service-instance maid format command on a device, you cannot switch between the standard version and draft5.2 version (or draft5.2 interim version). However, you can switch between the draft5.2 version and draft5.2 interim version. This restriction does not apply to the device without an MD configured.
To configure the CFD protocol version:
Step Command
1. Enter system view. system-view
2. Configure the CFD protocol version. cfd version { draft5 | draft5-plus | standard }
Remarks
N/A
Optional.
By default, CFD uses the standard version of IEEE 802.1ag.
Configuring service instances
Before configuring the MEPs and MIPs, first configure service instances. A service instance is a set of SAPs, and belongs to an MA in an MD.
A service instance is indicated by an integer to represent an MA in an MD. The MD and MA define the level and VLAN attribute of the messages handled by the MPs in a service instance.
Service instances fall into two types:
• Service instance with the MD name, which takes effect in any version of CFD.
•
Service instance without the MD name, which takes effect in only CFD IEEE 802.1ag.
You can create either type of service instance as needed.
Creating a service instance with the MD name
To create a service instance with the MD name, create the MD and MA for the service instance first.
To configure a service instance with the MD name:
Step Command
1. Enter system view. system-view
2. Create an MD.
Remarks
N/A cfd md md-name level level-value By default, no MD is created.
3. Create an MA.
4. Create a service instance with the MD name cfd ma ma-name md md-name vlan
vlan-id cfd service-instance instance-id md
md-name ma ma-name
By default, no MA is created.
By default, no service instance with the MD name is created.
Creating a service instance without the MD name
When you create a service instance without the MD name, the system automatically creates the MA and
MD for the service instance.
To create a service instance without the MD name:
Step Command
1. Enter system view. system-view
Remarks
N/A
22
Step Command
2. Create a service instance without the MD name. cfd service-instance instance-id maid format { icc-based ma-name | string
ma-name } level level-value vlan vlan-id
Remarks
By default, no service instance without the MD name is created.
Configuring MEPs
CFD is implemented through various operations on MEPs. A MEP is configured on a service instance, so the MD level and VLAN attribute of the service instance become the attribute of the MEP.
Before creating MEPs, configure the MEP list. A MEP list is a collection of local configurable MEPs in an
MA and the remote MEPs to be monitored.
To configure a MEP:
Step Command
1. Enter system view. system-view
2. Configure a MEP list.
3. Enter Layer 2 Ethernet interface view.
4. Create a MEP.
5. Enable the MEP.
Remarks
N/A cfd meplist mep-list service-instance instance-id
By default, no MEP list is configured.
To create a MEP, the MEP ID must be included in the MEP list of the service instance. interface interface-type
interface-number
N/A cfd mep mep-id service-instance
instance-id { inbound | outbound } By default, no MEP is created. cfd mep service-instance
instance-id mep mep-id enable
By default, the MEP is disabled.
Configuring MIP generation rules
As functional entities in a service instance, MIPs respond to various CFD frames, such as LTM frames, LBM frames, 1DM frames, DMM frames, and TST frames. You can choose appropriate MIP generation rules based on your network design.
Any of the following actions or cases can cause MIPs to be created or deleted after you configure the cfd mip-rule command:
• Enabling or disabling CFD.
• Creating or deleting the MEPs on a port.
•
Changes occur to the VLAN attribute of a port.
•
The rule specified in the cfd mip-rule command changes.
To configure the rules for generating MIPs:
Step Command
1. Enter system view. system-view
Remarks
N/A
23
Step Command
2. Configure the rules for generating MIPs. cfd mip-rule { default | explicit } service-instance instance-id
Configuring CFD functions
This section provides information about configuring CFD functions.
Remarks
By default, neither MIPs nor the rules for generating MIPs are configured.
Configuration prerequisites
Complete basic CFD settings.
Configuring CC on MEPs
This section describes how to configure CC on MEPs.
Configuration guidelines
•
Configure CC before you configure other CFD functions. After the CC function is configured, MEPs can send CCM frames to each other to examine the connectivity between them.
• Configure the same interval field value in CCM messages sent by the MEPs belonging to the same
MA.
Table 9 Relationship between the interval field value in the CCM message, the interval between CCM messages, and the timeout time of the remote MEP
4
5
The interval field value in the CCM message
3
The interval between CCM messages
100 milliseconds
1 second
10 second
6
7
Configuration procedure
To configure CC on a MEP:
60 seconds
600 seconds
Step Command
1. Enter system view. system-view
2. Configure the interval field value in the CCM messages sent by MEPs. cfd cc interval interval-value service-instance instance-id
3. Enter Layer 2 Ethernet interface view. interface interface-type
interface-number
The timeout time of the remote MEP
350 milliseconds
3.5 seconds
35 seconds
210 seconds
2100 seconds
Remarks
N/A
Optional.
By default, the interval field value is 4.
N/A
24
Step Command
4. Enable CCM sending on a
MEP. cfd cc service-instance
instance-id mep mep-id enable
Remarks
By default, CCM sending on a MEP is disabled.
Configuring LB on MEPs
The LB function can verify the link state between the local MEP and the remote MEP or MIP.
To configure LB on a MEP:
Remarks Task Command
Enable LB. cfd loopback service-instance
instance-id mep mep-id
{ target-mep target-mep-id | target-mac mac-address } [ number
number ]
By default, LB is disabled.
Available in any view.
Configuring LT on MEPs
LT can trace the path between the source and target MEPs, and can also locate link faults by sending LT messages automatically. The two functions are implemented in the following way:
•
To implement the first function, the source MEP first sends LTM messages to the target MEP. Based on the LTR messages in response to the LTM messages, the path between the two MEPs can be identified.
•
In the latter case, after LT messages automatic sending is enabled, if the source MEP fails to receive the CCM frames from the target MEP within 3.5 times the transmission interval, the link between the two is considered faulty. LTM frames will be sent out with the target MEP as the destination and the
TTL field in the LTM frames set to the maximum value 255. Based on the LTRs that the MIPs return, the fault source can be located.
To configure LT on MEPs:
Remarks Step Command
1. Find the path between a source
MEP and a target MEP. cfd linktrace service-instance
instance-id mep mep-id { target-mep
target-mep-id | target-mac
mac-address } [ ttl ttl-value ] [ hw-only ]
2. Enter system view. system-view
3. Enable LT messages automatic sending. cfd linktrace auto-detection [ size
size-value ]
Available in any view.
N/A
By default, LT messages automatic sending is disabled.
25
Displaying and maintaining CFD
Task Command
Display CFD status. display cfd status [ | { begin | exclude | include } regular-expression ]
Display the CFD protocol version. display cfd version [ | { begin | exclude | include } regular-expression ]
Display MD configuration information.
Display MA configuration information.
Display service instance configuration information.
Display MEP list in a service instance.
Display MP information.
Display the attribute and running information of the
MEPs.
Display LTR information received by a MEP.
Display the information of a remote MEP. display cfd md [ | { begin | exclude | include } regular-expression ] display cfd ma [ [ ma-name ] md { md-name
| level level-value } ] [ | { begin | exclude | include } regular-expression ] display cfd service-instance [ instance-id ]
[ | { begin | exclude | include }
regular-expression ] display cfd meplist [ service-instance
instance-id ] [ | { begin | exclude | include } regular-expression ] display cfd mp [ interface interface-type
interface-number ] [ | { begin | exclude | include } regular-expression ] display cfd mep mep-id service-instance
instance-id [ | { begin | exclude | include }
regular-expression ] display cfd linktrace-reply
[ service-instance instance-id [ mep
mep-id ] ] [ | { begin | exclude | include }
regular-expression ] display cfd remote-mep service-instance
instance-id mep mep-id [ | { begin | exclude | include } regular-expression ]
Display the content of the LTR messages received as responses to the automatically sent LTMs. display cfd linktrace-reply auto-detection
[ size size-value ] [ | { begin | exclude | include } regular-expression ]
Remarks
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in any view.
CFD configuration example
Network requirements
As shown in
:
•
The network comprises five devices and is divided into two MDs: MD_A (level 5) and MD_B (level
3). All ports belong to VLAN 100, and the MAs in the two MDs all serve VLAN 100. Assume that the MAC addresses of Device A through Device E are 0010-FC00-6511, 0010-FC00-6512,
0010-FC00-6513, 0010-FC00-6514, and 0010-FC00-6515, respectively.
•
MD_A has three edge ports: GigabitEthernet 1/0/1 on Device A, GigabitEthernet 1/0/3 on
Device D, and GigabitEthernet 1/0/4 on Device E. They are all inward-facing MEPs. MD_B has
26
two edge ports: GigabitEthernet 1/0/3 on Device B and GigabitEthernet 1/0/1 on Device D.
They are both outward-facing MEPs.
•
In MD_A, Device B is designed to have MIPs when its port is configured with low-level MEPs. Port
GigabitEthernet 1/0/3 is configured with MEPs of MD_B, and the MIPs of MD_A can be configured on this port. Configure the MIP generation rule of MD_A as explicit.
•
The MIPs of MD_B are designed on Device C, and are configured on all ports. You should configure the MIP generation rule as default.
• Configure CC to monitor the connectivity among all the MEPs in MD_A and MD_B. Configure LB to locate link faults.
•
Use LT to identify the path between a source MEP and a target MEP or identify any link failure on the path.
Figure 6 Network diagram
Configuration procedure
1. Configure a VLAN and assign ports to it.
On each device shown in
, create VLAN 100 and assign ports GigabitEthernet 1/0/1 through GigabitEthernet 1/0/4 to VLAN 100.
2. Enable CFD on Device A.
<DeviceA> system-view
[DeviceA] cfd enable
Enable CFD on Device B through Device E using the same method.
3. Configure service instances:
# Create MD_A (level 5) on Device A, create MA_A, which serves VLAN 100, in MD_A, and create service instance 1 for MD_A and MA_A.
[DeviceA] cfd md MD_A level 5
[DeviceA] cfd ma MA_A md MD_A vlan 100
[DeviceA] cfd service-instance 1 md MD_A ma MA_A
Configure Device E as you configure Device A.
27
# Create MD_A (level 5) on Device B, create MA_A that serves VLAN 100, in MD_A, and then create service instance 1 for MD_A and MA_A. In addition, create MD_B (level 3) and MA_B that serves VLAN 100, in MD_B, and then create service instance 2 for MD_B and MA_B.
[DeviceB] cfd md MD_A level 5
[DeviceB] cfd ma MA_A md MD_A vlan 100
[DeviceB] cfd service-instance 1 md MD_A ma MA_A
[DeviceB] cfd md MD_B level 3
[DeviceB] cfd ma MA_B md MD_B vlan 100
[DeviceB] cfd service-instance 2 md MD_B ma MA_B
Configure Device D in the same way as Device B.
# Create MD_B (level 3) on Device C, create MA_B that serves VLAN 100, in MD_B, and then create service instance 2 for MD_B and MA_B.
[DeviceC] cfd md MD_B level 3
[DeviceC] cfd ma MA_B md MD_B vlan 100
[DeviceC] cfd service-instance 2 md MD_B ma MA_B
4. Configure MEPs:
# On Device A, configure a MEP list in service instance 1. Create and enable inward-facing MEP
1001 in service instance 1 on GigabitEthernet 1/0/1.
[DeviceA] cfd meplist 1001 4002 5001 service-instance 1
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] cfd mep 1001 service-instance 1 inbound
[DeviceA-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1001 enable
[DeviceA-GigabitEthernet1/0/1] quit
# On Device B, configure a MEP list in service instances 1 and 2 respectively. Create and enable outward-facing MEP 2001 in service instance 2 on GigabitEthernet 1/0/3.
[DeviceB] cfd meplist 1001 4002 5001 service-instance 1
[DeviceB] cfd meplist 2001 4001 service-instance 2
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] cfd mep 2001 service-instance 2 outbound
[DeviceB-GigabitEthernet1/0/3] cfd mep service-instance 2 mep 2001 enable
[DeviceB-GigabitEthernet1/0/3] quit
# On Device D, configure a MEP list in service instances 1 and 2 respectively, create and enable outward-facing MEP 4001 in service instance 2 on GigabitEthernet 1/0/1, and then create and enable inward-facing MEP 4002 in service instance 1 on GigabitEthernet 1/0/3.
[DeviceD] cfd meplist 1001 4002 5001 service-instance 1
[DeviceD] cfd meplist 2001 4001 service-instance 2
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] cfd mep 4001 service-instance 2 outbound
[DeviceD-GigabitEthernet1/0/1] cfd mep service-instance 2 mep 4001 enable
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/3
[DeviceD-GigabitEthernet1/0/3] cfd mep 4002 service-instance 1 inbound
[DeviceD-GigabitEthernet1/0/3] cfd mep service-instance 1 mep 4002 enable
[DeviceD-GigabitEthernet1/0/3] quit
# On Device E, configure a MEP list in service instance 1. Create and enable inward-facing MEP
5001 in service instance 1 on GigabitEthernet 1/0/4.
[DeviceE] cfd meplist 1001 4002 5001 service-instance 1
28
[DeviceE] interface gigabitethernet 1/0/4
[DeviceE-GigabitEthernet1/0/4] cfd mep 5001 service-instance 1 inbound
[DeviceE-GigabitEthernet1/0/4] cfd mep service-instance 1 mep 5001 enable
[DeviceE-GigabitEthernet1/0/4] quit
5. Configure MIP generation rules:
# Configure the MIP generation rule in service instance 1 on Device B as explicit.
[DeviceB] cfd mip-rule explicit service-instance 1
# Configure the MIP generation rule in service instance 2 on Device C as default.
[DeviceC] cfd mip-rule default service-instance 2
6. Configure CC:
# On Device A, enable the sending of CCM frames for MEP 1001 in service instance 1 on
GigabitEthernet 1/0/1.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1001 enable
[DeviceA-GigabitEthernet1/0/1] quit
# On Device B, enable the sending of CCM frames for MEP 2001 in service instance 2 on
GigabitEthernet 1/0/3.
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] cfd cc service-instance 2 mep 2001 enable
[DeviceB-GigabitEthernet1/0/3] quit
# On Device D, enable the sending of CCM frames for MEP 4001 in service instance 2 on
GigabitEthernet 1/0/1. Enable the sending of CCM frames for MEP 4002 in service instance 1 on GigabitEthernet 1/0/3.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] cfd cc service-instance 2 mep 4001 enable
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/3
[DeviceD-GigabitEthernet1/0/3] cfd cc service-instance 1 mep 4002 enable
[DeviceD-GigabitEthernet1/0/3] quit
# On Device E, enable the sending of CCM frames for MEP 5001 in service instance 1 on
GigabitEthernet 1/0/4.
[DeviceE] interface gigabitethernet 1/0/4
[DeviceE-GigabitEthernet1/0/4] cfd cc service-instance 1 mep 5001 enable
[DeviceE-GigabitEthernet1/0/4] quit
Verifying the configuration
1. When the CC function detects a link fault, use LB on Device A to examine the status of the link between MEP 1001 and MEP 5001 in service instance 1.
[DeviceA] cfd loopback service-instance 1 mep 1001 target-mep 5001
Loopback to 0010-FC00-6515 with the sequence number start from 1001-43404:
Reply from 0010-FC00-6515: sequence number=1001-43404 time=5ms
Reply from 0010-FC00-6515: sequence number=1001-43405 time=5ms
Reply from 0010-FC00-6515: sequence number=1001-43406 time=5ms
Reply from 0010-FC00-6515: sequence number=1001-43407 time=5ms
Reply from 0010-FC00-6515: sequence number=1001-43408 time=5ms
Send:5 Received:5 Lost:0
29
After the whole network status is obtained with the CC function, use the LT function to identify the paths between source and target MEPs and to locate faults.
2. Use LT to identify the path between MEP 1001 and MEP 5001 in service instance 1 on Device A.
[DeviceA] cfd linktrace service-instance 1 mep 1001 target-mep 5001
Linktrace to MEP 5001 with the sequence number 1001-43462
MAC Address TTL Last MAC Relay Action
0010-FC00-6515 63 0010-FC00-6512 Hit
30
Configuring DLDP
Unidirectional links occur when one end of a bidirectional link can receive packets. Unidirectional links cause problems such as loops in an STP-enabled network.
For example, the link between two switches, Switch A and Switch B, is a bidirectional link when they are connected through a fiber pair, with one fiber used for sending packets from A to B and the other for sending packets from B to A. When one of the fibers stops operating, the link becomes a unidirectional link (one-way link).
Unidirectional fiber links are either:
•
Cross-connected.
• Disconnected at one end or one fiber in the fiber pair is broken.
shows a correct fiber connection and the two types of unidirectional fiber connections.
Figure 7 Correct and incorrect fiber connections
Correct fiber conecton
Device A
Unidirectional connection type 1
Cross-connected fibers
Device A
Unidirectional connection type 2
One fiber of a fiber pair Is not connected or Is broken
Device A
Port 1 Port 2 Port 1 Port 2 Port 1 Port 2
Port 1 Port 2 Port 1 Port 2 Port 1 Port 2
Device B Device B Device B
Ethernet optical port
Tx end Rx end Fiber link Unconnected or broken fiber
The DLDP detects unidirectional links (fiber links or twisted-pair links). DLDP can be configured to shut down the faulty port automatically or prompt users to take actions to avoid network problems.
As a data link layer protocol, DLDP cooperates with physical layer protocols to monitor link status. When the auto-negotiation mechanism provided by the physical layer detects physical signals and faults, DLDP performs operations such as identifying peer devices, detecting unidirectional links, and shutting down unreachable ports. The auto-negotiation mechanism and DLDP operate together to make sure physical/logical unidirectional links are detected and shut down, and to prevent failure of other protocols such as STP. If both ends of a link are operating normally at the physical layer, DLDP detects
31
whether the link is correctly connected at the link layer and whether the two ends can exchange packets properly. This is beyond the capability of the auto-negotiation mechanism at the physical layer.
How DLDP works
This section describes the function of DLDP.
DLDP link states
describes DLDP link states.
Table 10 DLDP link states
State Description
Initial DLDP is disabled.
Inactive
Active
Advertisement
DLDP is enabled and the link is down.
DLDP is enabled and the link is up or the neighbor entries have been cleared.
All neighbors are bi-directionally reachable or DLDP has been in active state for more than five seconds. This is a relatively stable state where no unidirectional link has been detected.
Probe
Disable
DelayDown
DLDP enters this state if it receives a packet from an unknown neighbor. In this state, DLDP sends packets to examine whether the link is unidirectional. When
DLDP enters this state, a probe timer starts and an echo timeout timer starts for each neighbor to be probed.
A port enters this state when:
•
A unidirectional link is detected.
•
The contact with the neighbor in enhanced mode gets lost.
•
In this state, the port does not receive or send packets other than DLDPDUs.
A port in the Active, Advertisement, or Probe DLDP link state enters this state rather than removing the corresponding neighbor entry, and enters the Inactive state when it detects a port-down event. When a port enters this state, the DelayDown timer is triggered.
DLDP timers
Table 11 DLDP timers
DLDP timer
Active timer
Advertisement timer
Probe timer
Description
Determines the interval for sending Advertisement packets with RSY tags (default is to 1 second). By default, a device in the active DLDP link state sends one
Advertisement packet with RSY tags every second. The maximum number of advertisement packets with RSY tags that can be sent successively is 5.
Determines the interval for sending common advertisement packets (default is 5 seconds).
Determines the interval for sending Probe packets (default is 1 second). By default, a device in the probe state sends one Probe packet every second. The maximum number of Probe packets that can be sent successively is 10.
32
DLDP timer
Echo timer
Entry timer
Enhanced timer
DelayDown timer
Description
This timer is set to 10 seconds. It is triggered when a device transits to the Probe state or when an enhanced detect is launched. When the Echo timer expires and no Echo packet has been received from a neighbor device, the state of the link is set to unidirectional. The device transits to the Disable state and does the following:
•
Sends Disable packets.
•
Either prompts the user to shut down the port or shuts down the port automatically (depending on the DLDP down mode configured).
•
Removes the corresponding neighbor entries.
When a new neighbor joins, a neighbor entry is created and the corresponding entry timer is triggered. When a DLDP packet is received, the device updates the corresponding neighbor entry and the entry timer.
In normal mode, if no packet is received from a neighbor when the corresponding entry timer expires, DLDP sends advertisement packets with RSY tags and removes the neighbor entry.
In enhanced mode, if no packet is received from a neighbor when the Entry timer expires, DLDP triggers the enhanced timer.
The setting of an Entry timer is three times that of the Advertisement timer.
In enhanced mode, this timer is triggered if no packet is received from a neighbor when the entry timer expires. Enhanced timer is set to 1 second.
After the Enhanced timer is triggered, the device sends up to eight probe packets to the neighbor at a frequency of one packet per second.
A device in Active, Advertisement, or Probe DLDP link state transits to DelayDown state and transits to the Inactive state when it detects a port-down event.
When a device transits to this state, the DelayDown timer is triggered. A device in
DelayDown state only responds to port-up events.
If a device in the DelayDown state detects a port-up event before the DelayDown timer expires, it resumes its original DLDP state. If not, when the DelayDown timer expires, the device removes the corresponding DLDP neighbor information and transits to the Inactive state.
RecoverProbe timer
This timer is set to 2 seconds. A port in the Disable state sends one RecoverProbe packet every two seconds to detect whether a unidirectional link has been restored to bidirectional.
DLDP mode
DLDP can operate in normal or enhanced mode.
•
In normal DLDP mode, when an entry timer expires, the device removes the corresponding neighbor entry and sends an Advertisement packet with the RSY tag.
•
In enhanced DLDP mode, when an entry timer expires, the Enhanced timer is triggered and the device tests the neighbor by sending up to eight Probe packets at the frequency of one packet per second. If no Echo packet has been received from the neighbor when the Echo timer expires, the device transits to the Disable state.
shows the relationship between the DLDP modes and neighbor entry aging.
33
Table 12 DLDP mode and neighbor entry aging
DLDP mode
Detecting a neighbor after the corresponding neighbor entry ages out
Removing the neighbor entry immediately after the
Entry timer expires
Triggering the Enhanced timer after an Entry timer expires
Normal DLDP mode
No Yes No
Enhanced
DLDP mode
Yes No Yes
shows the relationship between DLDP modes and unidirectional link types.
Table 13 DLDP mode and unidirectional link types
Unidirectional link type
Occurs on fibers
Occurs on copper twisted pairs
DLDP mode in which unidirectional links can be detected
Cross-connected link
Yes No Both normal and enhanced modes
Connectionless or broken link
Yes Yes
Only enhanced mode. The port that can receive signals is in Disable state, and the port that does not receive signals is in Inactive state.
Enhanced DLDP mode is designed for addressing black holes. It prevents situations where one end of a link is up and the other is down.
When forced speed and full duplex mode are configured on a port, the situation shown in
can occur (such as the fiber link). Without DLDP enabled, the port on Device B is actually down, but its state cannot be detected by common data link protocols, so the port on Device A is still up. However, in enhanced DLDP mode, the following occurs:
•
The port on Device B is in Inactive DLDP state because it is physically down.
•
The port on Device A tests the peer port on Device B after the Entry timer for the port on Device B expires.
• The port on Device A transits to the Disable state if it receives no Echo packet from the port on
Device B when the Echo timer expires.
Figure 8 A scenario for the enhanced DLDP mode
DLDP authentication mode
You can use DLDP authentication to prevent network attacks and illegal detecting. The following DLDP authentication modes are available:
• Non-authentication:
34
{
{
{
{
The sending side sets the Authentication field and the Authentication type field of DLDP packets to 0.
The receiving side examines the values of the two fields in received DLDP packets and drops any packets when there is a conflict with the corresponding local configuration.
• Simple authentication:
{
Before sending a DLDP packet, the sending side sets the Authentication field to the user configured password and sets the Authentication type field to 1.
{
The receiving side examines the values of the two fields in received DLDP packets and drops any packets when there is a conflict with the corresponding local configuration.
•
MD5 authentication:
Before sending a packet, the sending side encrypts the user configured password by using MD5 algorithm, assigns the digest to the Authentication field, and sets the Authentication type field to
2.
The receiving side examines the values of the two fields in received DLDP packets and drops any packets conflicting with the corresponding local configuration.
DLDP processes
1. On a DLDP-enabled link that is in up state, DLDP sends DLDP packets to the peer device and processes the DLDP packets received from the peer device. DLDP packets sent vary with DLDP states.
Table 14 DLDP packet types and DLDP states
DLDP state
Active
Advertisement
Type of DLDP packets sent
Advertisement packet with RSY tag.
Normal Advertisement packet.
Disable Disable packet and then RecoverProbe packet.
NOTE:
A device sends Flush packets when it transits to Initial state from Active, Advertisement, Probe, or
DelayDown state, but does not send them when it transits to Initial state from Inactive or Disable state.
2. DLDP processes the packet received from a neighbor in the following ways:
{
In any of the three authentication modes, drops the packet if it fails to pass authentication.
{
{
Drops the packet if it carries an advertisement interval different than the local setting.
Processes the packet and handles DLDP port state as shown in Table 15
depending on its type.
Table 15 Processing incoming DLDP packets by packet type
Packet type Processing procedure
Advertisement with
RSY tag
Retrieves the neighbor information
If no matching neighbor entry exists, creates the neighbor entry, triggers the Entry timer, and changes the DLDP port state to
Probe.
If a matching neighbor entry already exists, resets the Entry timer and changes the DLDP port state to Probe.
35
Packet type Processing procedure
Normal
Advertisement
Retrieves the neighbor information
If no matching neighbor entry exists, creates the neighbor entry, triggers the Entry timer, and changes the DLDP port state to
Probe.
If a matching neighbor entry already exists, resets the Entry timer.
Flush packet
Examines whether the local DLDP port state is Disable
If yes, no process is performed.
If no, removes the matching neighbor entry (if any).
Probe
Echo
Disable
Retrieves the neighbor information
Retrieves the neighbor information
Examines whether the local DLDP port state is Disable
If no matching neighbor entry exists, creates the neighbor entry, transits to the Probe state, and returns Echo packets.
If a matching neighbor entry already exists, resets the Entry timer and returns Echo packets.
If no matching neighbor entry exists, creates the neighbor entry, triggers the Entry timer, and changes the DLDP port state to
Probe.
If a matching neighbor entry already exists:
•
Drops the packet if it carries information that conflicts with the neighbor entry.
•
Otherwise, sets the state of the neighbor to two way
(bidirectional). If all the neighbors are in two way state, changes from the Probe state to the Advertisement state and disable the Echo timer.
If yes, no process is performed.
If no, sets the state of the neighbor to one way (unidirectional), and then examines the state of other neighbors to determine the subsequent action to take:
•
If all the neighbors are in one way state, changes the local
DLDP port state to Disable.
•
If the state of some neighbors is still unknown, takes no action until the state of these neighbors is determined.
•
If any two-way neighbor is present, removes all one-way neighbors, but does not change the DLDP port state.
If yes, returns RecoverEcho packets.
RecoverProbe
Examines whether the local port is in
Disable or
Advertisement state
If no, no process is performed.
RecoverEcho
Examines whether the local DLDP port state is Disable
If yes, changes the local DLDP port state to Active if the neighbor information the packet carries is consistent with the local port information.
If no, no process is performed.
36
Packet type Processing procedure
LinkDown packet
Examines whether the local port operates in
Enhanced mode
If yes and the local port is not in Disable state, sets the state of the neighbor to one way, and then examines the state of other neighbors to determine the subsequent action to take:
•
If all the neighbors are in one way state, changes the local
DLDP port state to Disable.
•
If the state of some neighbors is still unknown, takes no action until the state of these neighbors is determined.
•
If any two-way neighbor is present, removes all one-way neighbors, but does not change the DLDP port state.
If no, no process is performed.
3.
If no echo packet is received from a neighbor, DLDP takes action as described in Table 16 .
Table 16 Action to take when no echo packet is received from a neighbor
No echo packet received from the neighbor Action
In normal mode, no echo packet is received when the Echo timer expires.
In enhanced mode, no echo packet is received when the Echo timer expires.
DLDP sets the state of the neighbor to one way, and determines the subsequent action to take depending on the state of the other neighbors:
•
If all the neighbors are in one way state, removes all the neighbor entries, changes the DLDP port state to Disable, outputs log and tracking information, and sends Disable packets to the neighbors. In addition, depending on the user-defined DLDP down mode, shuts down the local port or prompts users to shut down the port.
•
If the state of some neighbors is unknown, takes no action until the state of these neighbors is determined.
•
If a two-way neighbor is present, removes all the one-way neighbors, but does not change the DLDP port state.
Link auto-recovery mechanism
If the port shutdown mode upon detection of a unidirectional link is set to auto, DLDP automatically sets the state of the port where a unidirectional link is detected to DLDP down. A DLDP down port cannot forward data traffic or send/receive any PDUs except DLDPDUs.
On a DLDP down port, DLDP monitors the unidirectional link. Once DLDP finds out that the state of the link has been restored to bidirectional, it brings up the port. The specific process is as follows:
1. The DLDP down port sends out a RecoverProbe packet every two seconds, which only carries information about the local port.
2. Upon receiving the RecoverProbe packet, the remote end returns a RecoverEcho packet.
3. Upon receiving the RecoverEcho packet, the local port examines whether neighbor information in the RecoverEcho packet is the same as the local port information. If they are the same, the link between the local port and the neighbor is considered to have been restored to a bidirectional link, and the port will transit from Disable state to Active state and re-establish relationship with the neighbor.
Only DLDP down ports can send and process Recover packets, including RecoverProbe packets and
RecoverEcho packets. If related ports are manually shut down with the shutdown command, the auto-recovery mechanism does not take effect.
37
DLDP neighbor state
A DLDP neighbor can be in one of the states described in
Table 17 DLDP neighbor state description
DLDP neighbor state Description
Unknown
The neighbor is just detected and is being probed. It transits to Two way state or
Unidirectional state after the probe operation finishes.
Two way
Unidirectional
The neighbor has received response from its peer.
The link connecting the neighbor is detected to be a unidirectional link. After a device transits to this state, the corresponding neighbor entries maintained on other devices are removed.
DLDP configuration task list
•
For DLDP to operate properly, enable DLDP on both sides and make sure these settings are consistent: the interval to send Advertisement packets, DLDP authentication mode, and password.
• DLDP does not process any LACP events. The links in an aggregation are treated as individual links in DLDP.
•
Make sure the DLDP version running on devices on the two ends are the same.
Task Remarks
Configuring the duplex mode and speed of an Ethernet interface
Required.
Setting the interval to send advertisement packets
Setting the port shutdown mode
Configuring DLDP authentication
Required.
Optional.
Optional.
Optional.
Optional.
Optional.
Optional.
Configuring the duplex mode and speed of an
Ethernet interface
To make sure DLDP operates properly on a link, configure the full duplex mode for the ports at two ends of the link, and configure a speed for the two ports, rather than letting them negotiate a speed. For more information about the duplex and speed commands, see Layer 2—LAN Switching Command Reference.
Enabling DLDP
To properly configure DLDP on the device, first enable DLDP globally, and then enable it on each port.
To enable DLDP:
38
Step Command
1. Enter system view. system-view
Remarks
N/A
2. Enable DLDP globally. dldp enable
By default, DLDP is disabled globally.
3. Enter Layer 2 Ethernet interface view or port group view.
•
Enter Layer 2 Ethernet interface view: interface interface-type
interface-number
•
Enter port group view: port-group manual
port-group-name
Use either command.
Configurations made in Ethernet interface view apply to the current port only. Configurations made in port group view apply to all ports in the port group.
4. Enable DLDP. dldp enable
By default, DLDP is disabled on a port.
NOTE:
• DLDP takes effect only on Ethernet interfaces (fiber or copper).
• DLDP can detect unidirectional links only after all physical links are connected. Therefore, before enabling DLDP, make sure optical fibers or copper twisted pairs are connected.
Setting DLDP mode
DLDP operates in normal or enhanced mode.
•
Normal mode—DLDP does not actively detect neighbors when the corresponding neighbor entries age out.
•
Enhanced mode—DLDP actively detects neighbors when the corresponding neighbor entries age out.
To set DLDP mode:
Step Command
1. Enter system view. system-view
2. Set DLDP mode. dldp work-mode { enhance | normal }
Remarks
N/A
Optional.
By default DLDP operates in normal mode.
Setting the interval to send advertisement packets
DLDP detects unidirectional links by sending Advertisement packets. To make sure DLDP can detect unidirectional links promptly before network performance deteriorates, set the advertisement interval appropriate for your network environment. Set the interval shorter than one third of the STP convergence time. If the interval is too long, STP loops may occur before unidirectional links are detected and shut down. If the interval is too short, the number of advertisement packets increases. HP recommends that you use the default interval in most cases.
To set the Advertisement packet sending interval:
39
Step Command
1. Enter system view. system-view
2. Set the interval to send
Advertisement packets. dldp interval time
Remarks
N/A
The default is 5 seconds.
This setting applies to all
DLDP-enabled ports.
To enable DLDP to operate properly, make sure the two sides of the link use the same Advertisement packet sending interval.
Setting the DelayDown timer
The DelayDown timer setting applies to all DLDP-enabled ports.
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 transits to the DelayDown state instead of the Inactive state. This prevents the corresponding neighbor entries from being removed. At the same time, the device triggers the DelayDown timer. If the port goes up before the timer expires, the device restores the original state. If the port remains down when the timer expires, the device transits to the Inactive state.
To set the DelayDown timer
Step Command
1. Enter system view. system-view
2. Set the DelayDown timer. dldp delaydown-timer time
Remarks
N/A
Optional.
The default is 1 second.
Setting the port shutdown mode
On detecting a unidirectional link, the ports can be shut down by using one of the following two modes.
•
Manual mode—This mode applies to low performance networks, where normal links may be treated as unidirectional links. It protects data traffic transmission against false unidirectional links.
In this mode, DLDP only detects unidirectional links, but does not automatically shut down unidirectional link ports. Instead, the DLDP state machine generates logs and traps to prompt you to manually shut down unidirectional link ports with the shutdown command. HP recommends that you follow these instructions. Then the DLDP state machine transits to the Disable state.
• Auto mode—In this mode, when a unidirectional link is detected, DLDP transits to Disable state, generates log and traps, and sets the port state to DLDP Down.
If the device is busy, or the CPU usage is high, normal links may be treated as unidirectional links. In this case, you can set the port shutdown mode to manual mode to override false unidirectional link report.
To set port shutdown mode:
Step Command
1. Enter system view. system-view
Remarks
N/A
40
Step Command
2. Set port shutdown mode. dldp unidirectional-shutdown { auto |
Remarks
Optional.
The default 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 simple authentication or MD5 authentication. If your network is safe, you can choose not to authenticate.
To enable DLDP to operate properly, make sure DLDP authentication modes and passwords on both sides of a link are the same.
To configure DLDP authentication:
Step Command
1. Enter system view. system-view
2. Configure DLDP authentication. dldp authentication-mode { none |
{ md5 | simple } password }
Remarks
N/A
The default is none.
Resetting DLDP state
After DLDP detects a unidirectional link on a port, the port enters Disable state. In this case, DLDP prompts you to manually shut down the port or automatically shuts down the port depending on the user-defined port shutdown mode. To enable the port to perform DLDP detect again, reset the DLDP state of the port by using one of the following methods:
• If the port is shut down manually with the shutdown command, run the undo shutdown command on the port.
•
If DLDP automatically shuts down the port, run the dldp reset command on the port to enable the port to perform DLDP detection again. Alternatively, you can wait for DLDP to automatically enable the port when it detects that the link has been restored to bidirectional. For how to reset the DLDP state by using the dldp reset command, see "
Resetting DLDP state in system view " and "
DLDP state in port view/port group view ."
The DLDP state that the port transits to upon the DLDP state reset operation depends on its physical state.
If the port is physically down, it transits to Inactive state. If the port is physically up, it transits to Active state.
Resetting DLDP state in system view
Resetting DLDP state in system view applies to all ports of the device.
41
To reset DLDP in system view:
Step Command
1. Enter system view. system-view
2.
Reset DLDP state. dldp reset
Resetting DLDP state in port view/port group view
Resetting DLDP state in port view or port group view applies to the current port or all ports in the port group.
To reset DLDP state in port view/port group view:
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view or port group view.
•
Enter Layer 2 Ethernet interface view: interface interface-type
interface-number
•
Enter port group view: port-group manual
port-group-name
3. Reset DLDP state. dldp reset
Remarks
N/A
Use either approach.
Configurations made in Ethernet interface view only apply to the current port. Configurations made in port group view apply to all ports in the port group.
N/A
Displaying and maintaining DLDP
Task Command
Display the DLDP configuration of a port. display dldp [ interface-type
interface-number ] [ | { begin | exclude | include } regular-expression ]
Display the statistics on DLDP packets passing through a port.
Clear the statistics on DLDP packets passing through a port. display dldp statistics [ interface-type
interface-number ] [ | { begin | exclude | include } regular-expression ] reset dldp statistics [ interface-type
interface-number ]
DLDP configuration examples
This section provides examples of DLDP configuration.
Remarks
Available in any view.
Available in any view.
Available in user view.
Automatically shutting down unidirectional links
Network requirements
As shown in
Figure 9 , 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.
42
Figure 9 Network diagram
Configuration procedure
1. Configure Device A:
# Enable DLDP globally.
<DeviceA> system-view
[DeviceA] dldp enable
# Configure GigabitEthernet 1/0/49 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on the port.
[DeviceA] interface gigabitethernet 1/0/49
[DeviceA-GigabitEthernet1/0/49] duplex full
[DeviceA-GigabitEthernet1/0/49] speed 1000
[DeviceA-GigabitEthernet1/0/49] dldp enable
[DeviceA-GigabitEthernet1/0/49] quit
# Configure GigabitEthernet 1/0/50 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on the port.
[DeviceA] interface gigabitethernet 1/0/50
[DeviceA-GigabitEthernet1/0/50] duplex full
[DeviceA-GigabitEthernet1/0/50] speed 1000
[DeviceA-GigabitEthernet1/0/50] dldp enable
[DeviceA-GigabitEthernet1/0/50] quit
# Set the DLDP mode to enhanced.
[DeviceA] dldp work-mode enhance
# Set the port shutdown mode to auto.
[DeviceA] dldp unidirectional-shutdown auto
2. Configure Device B:
43
# Enable DLDP globally.
<DeviceB> system-view
[DeviceB] dldp enable
# Configure GigabitEthernet 1/0/49 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on it.
[DeviceB] interface gigabitethernet 1/0/49
[DeviceB-GigabitEthernet1/0/49] duplex full
[DeviceB-GigabitEthernet1/0/49] speed 1000
[DeviceB-GigabitEthernet1/0/49] dldp enable
[DeviceB-GigabitEthernet1/0/49] quit
# Configure GigabitEthernet 1/0/50 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on it.
[DeviceB] interface gigabitethernet 1/0/50
[DeviceB-GigabitEthernet1/0/50] duplex full
[DeviceB-GigabitEthernet1/0/50] speed 1000
[DeviceB-GigabitEthernet1/0/50] dldp enable
[DeviceB-GigabitEthernet1/0/50] quit
# Set the DLDP mode to enhanced.
[DeviceB] dldp work-mode enhance
# Set the port shutdown mode to auto.
[DeviceB] dldp unidirectional-shutdown auto
Verifying the configuration
After the configurations are complete, you can use the display dldp command to display the DLDP configuration information on ports.
# Display the DLDP configuration information on all DLDP-enabled ports of Device A.
[DeviceA] display dldp
DLDP global status : enable
DLDP interval : 5s
DLDP work-mode : enhance
DLDP authentication-mode : none
DLDP unidirectional-shutdown : auto
DLDP delaydown-timer : 1s
The number of enabled ports is 2.
Interface GigabitEthernet1/0/49
DLDP port state : advertisement
DLDP link state : up
The neighbor number of the port is 1.
Neighbor mac address : 0023-8956-3600
Neighbor port index : 59
Neighbor state : two way
Neighbor aged time : 11
Interface GigabitEthernet1/0/50
DLDP port state : advertisement
DLDP link state : up
44
The neighbor number of the port is 1.
Neighbor mac address : 0023-8956-3600
Neighbor port index : 60
Neighbor state : two way
Neighbor aged time : 12
The output shows that both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 are in Advertisement state, which means both links are bidirectional.
# Enable system information monitoring on Device A and enable the display of log and trap information.
[DeviceA] quit
<DeviceA> terminal monitor
<DeviceA> terminal logging
<DeviceA> terminal trapping
The following log and trap information is displayed on Device A:
<DeviceA>
#Jan 18 17:36:18:798 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap
1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825792.
%Jan 18 17:36:18:799 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is DOWN.
%Jan 18 17:36:18:799 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_AUTO: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/49. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.
The shutdown mode is AUTO. DLDP shuts down the port.
#Jan 18 17:36:20:189 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap
1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825793.
%Jan 18 17:36:20:189 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is DOWN.
%Jan 18 17:36:20:190 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_AUTO: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/50. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.
The shutdown mode is AUTO. DLDP shuts down the port.
%Jan 15 16:54:56:040 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_AUTO_ENHANCE: -Slot=1; In enhanced DLDP mode, port GigabitEthernet1/0/49 cannot detect its aged-out neighbor. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor. The shutdown mode is AUTO. DLDP shuts down the port.
The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is down, and DLDP has detected a unidirectional link on both ports and has automatically shut them down.
Assume that in this example, the unidirectional links are caused by cross-connected fibers. Correct the fiber connections on detecting the unidirectional link problem. As a result, the ports shut down by DLDP automatically recover and Device A displays the following log information:
<DeviceA>
%Jan 18 17:47:33:869 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is UP.
%Jan 18 17:47:35:894 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is UP.
The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is now up.
45
Manually shutting down unidirectional links
Network requirements
As shown in
, Device A and Device B are connected with two fiber pairs.
Configure DLDP to send information when a unidirectional link is detected, which reminds the network administrator to manually shut down the faulty port.
Figure 10 Network diagram
Configuration procedure
1. Configure Device A:
# Enable DLDP globally.
<DeviceA> system-view
[DeviceA] dldp enable
# Configure GigabitEthernet 1/0/49 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on the port.
[DeviceA] interface gigabitethernet 1/0/49
[DeviceA-GigabitEthernet1/0/49] duplex full
[DeviceA-GigabitEthernet1/0/49] speed 1000
[DeviceA-GigabitEthernet1/0/49] dldp enable
[DeviceA-GigabitEthernet1/0/49] quit
# Configure GigabitEthernet 1/0/50 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on the port.
[DeviceA] interface gigabitethernet 1/0/50
[DeviceA-GigabitEthernet1/0/50] duplex full
[DeviceA-GigabitEthernet1/0/50] speed 1000
46
[DeviceA-GigabitEthernet1/0/50] dldp enable
[DeviceA-GigabitEthernet1/0/50] quit
# Set the DLDP mode to enhanced.
[DeviceA] dldp work-mode enhance
# Set the port shutdown mode to manual.
[DeviceA] dldp unidirectional-shutdown manual
2. Configure Device B:
# Enable DLDP globally.
<DeviceB> system-view
[DeviceB] dldp enable
# Configure GigabitEthernet 1/0/49 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on it.
[DeviceB] interface gigabitethernet 1/0/49
[DeviceB-GigabitEthernet1/0/49] duplex full
[DeviceB-GigabitEthernet1/0/49] speed 1000
[DeviceB-GigabitEthernet1/0/49] dldp enable
[DeviceB-GigabitEthernet1/0/49] quit
# Configure GigabitEthernet 1/0/50 to operate in full duplex mode and at 1000 Mbps, and enable DLDP on it.
[DeviceB] interface gigabitethernet 1/0/50
[DeviceB-GigabitEthernet1/0/50] duplex full
[DeviceB-GigabitEthernet1/0/50] speed 1000
[DeviceB-GigabitEthernet1/0/50] dldp enable
[DeviceB-GigabitEthernet1/0/50] quit
# Set the DLDP mode to enhanced.
[DeviceB] dldp work-mode enhance
# Set the port shutdown mode to manual.
[DeviceB] dldp unidirectional-shutdown manual
Verifying the configuration
After the configurations are complete, you can use the display dldp command to display the DLDP configuration information on ports.
# Display the DLDP configuration information on all DLDP-enabled ports of Device A.
[DeviceA] display dldp
DLDP global status : enable
DLDP interval : 5s
DLDP work-mode : enhance
DLDP authentication-mode : none
DLDP unidirectional-shutdown : manual
DLDP delaydown-timer : 1s
The number of enabled ports is 2.
Interface GigabitEthernet1/0/49
DLDP port state : advertisement
DLDP link state : up
The neighbor number of the port is 1.
Neighbor mac address : 0023-8956-3600
47
Neighbor port index : 59
Neighbor state : two way
Neighbor aged time : 11
Interface GigabitEthernet1/0/50
DLDP port state : advertisement
DLDP link state : up
The neighbor number of the port is 1.
Neighbor mac address : 0023-8956-3600
Neighbor port index : 60
Neighbor state : two way
Neighbor aged time : 12
The output shows that both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 are in Advertisement state, which means both links are bidirectional.
# Enable system information monitoring on Device A and enable the display of log and trap information.
[DeviceA] quit
<DeviceA> terminal monitor
<DeviceA> terminal logging
<DeviceA> terminal trapping
The following log and trap information is displayed on Device A:
<DeviceA>
#Jan 18 18:10:38:481 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap
1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825792.
%Jan 18 18:10:38:481 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_MANUAL: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/49. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.
The shutdown mode is MANUAL. The port needs to be shut down by the user.
#Jan 18 18:10:38:618 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap
1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825793.
%Jan 18 18:10:38:618 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_MANUAL: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/50. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.
The shutdown mode is MANUAL. The port needs to be shut down by the user.
The output shows that DLDP has detected a unidirectional link on both GigabitEthernet 1/0/49 and
GigabitEthernet 1/0/50, and is asking you to shut down the faulty ports manually.
After you shut down GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50, the following log information is displayed:
<DeviceA> system-view
[DeviceA] interface gigabitethernet 1/0/49
[DeviceA-GigabitEthernet1/0/49] shutdown
%Jan 18 18:16:12:044 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is DOWN.
[DeviceA-GigabitEthernet1/0/49] quit
[DeviceA] interface gigabitethernet 1/0/50
[DeviceA-GigabitEthernet1/0/50] shutdown
48
%Jan 18 18:18:03:583 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is DOWN.
The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is down.
Assume that in this example, the unidirectional links are caused by cross-connected fibers. Correct the fiber connections and then bring up the ports shut down earlier.
# On Device A, bring up GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50:
[DeviceA-GigabitEthernet1/0/50] undo shutdown
[DeviceA-GigabitEthernet1/0/50]
%Jan 18 18:22:11:698 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is UP.
[DeviceA-GigabitEthernet1/0/50] quit
[DeviceA] interface gigabitethernet 1/0/49
[DeviceA-GigabitEthernet1/0/49] undo shutdown
[DeviceA-GigabitEthernet1/0/49]
%Jan 18 18:22:46:065 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is UP.
The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is now up.
Troubleshooting DLDP
Symptom
This section provides troubleshooting advice.
Two DLDP-enabled devices, Device A and Device B, are connected through two fiber pairs, in which two fibers are cross-connected. The unidirectional links cannot be detected. All the four ports involved are in
Advertisement state.
Analysis
The problem can be caused by the following:
•
The intervals to send Advertisement packets on Device A and Device B are not the same.
•
DLDP authentication modes/passwords on Device A and Device B are not the same.
Solution
Make sure the interval to send Advertisement packets, the authentication mode, and the password configured on Device A and Device B are the same.
49
Configuring RRPP
This chapter describes how to configure RRPP.
Overview
The RRPP is a link layer protocol designed for Ethernet rings. RRPP can prevent broadcast storms caused by data loops when an Ethernet ring is healthy and rapidly restore the communication paths between the nodes in the event that a link is disconnected on the ring.
Metropolitan area networks and enterprise networks typically use the ring topology to improve reliability.
However, services are interrupted if any node in the ring network fails. A ring network usually uses RPR or Ethernet rings. RPR is high in cost as it needs dedicated hardware. In contrast, the Ethernet ring technology is more mature and economical, so it is more and more widely used in MANs and enterprise networks.
RSTP, PVST, MSTP, and RRPP can eliminate Layer-2 loops. RSTP, PVST, and MSTP are mature, but they take several seconds to converge. RRPP is an Ethernet ring-specific data link layer protocol, and converges faster than RSTP, PVST, and MSTP. Additionally, the convergence time of RRPP is independent of the number of nodes in the Ethernet ring, so it can be applied to large-diameter networks.
Basic RRPP concepts
The basic parts of an RRPP network are shown
Figure 11 RRPP networking diagram
RRPP domain
Interconnected devices with the same domain ID and control VLANs constitute an RRPP domain. An RRPP domain contains the following elements: primary ring, subring, control VLAN, master node, transit node, primary port, secondary port, common port, and edge port.
As shown in
Figure 11 , Domain 1 is an RRPP domain, including two RRPP rings: Ring 1 and Ring 2. All
nodes on the two RRPP rings belong to the RRPP domain.
50
RRPP ring
A ring-shaped Ethernet topology is called an "RRPP ring". RRPP rings include primary rings and subrings.
You can configure a ring as either the primary ring or a subring by specifying its ring level. The primary ring is level 0, and a subring is level 1. An RRPP domain contains one or multiple RRPP rings, one serving as the primary ring and the others serving as subrings. A ring can be in one of the following states:
•
Health state—All physical links on the Ethernet ring are connected.
•
Disconnect state—Some physical links on the Ethernet ring are broken.
to 0, and that of Ring 2 is set to 1. Ring 1 is configured as the primary ring and Ring 2 is configured as a subring.
Control VLAN and data VLAN
1. Control VLAN
In an RRPP domain, a control VLAN is a VLAN dedicated to transferring RRPPDUs. On a device, the ports accessing an RRPP ring belong to the control VLANs of the ring, and only such ports can join the control VLANs.
An RRPP domain is configured with two control VLANs: one primary control VLAN, which is the control VLAN for the primary ring, and one secondary control VLAN, which is the control VLAN for subrings. All subrings in the same RRPP domain share the same secondary control VLAN. After you specify a VLAN as the primary control VLAN, the system automatically configures the VLAN whose
ID is the primary control VLAN ID plus one as the secondary control VLAN.
IP address configuration is prohibited on the control VLAN interfaces.
2. Data VLAN
A data VLAN is a VLAN dedicated to transferring data packets. Both RRPP ports and non-RRPP ports can be assigned to a data VLAN.
Node
Each device on an RRPP ring is a node. The role of a node is configurable. RRPP has the following node roles:
•
Master node—Each ring has only one master node. The master node initiates the polling mechanism and determines the operations to be performed after a change in topology.
• Transit node—Transit nodes include all nodes except the master node on the primary ring and all nodes on subrings except the master nodes and the nodes where the primary ring intersects with the subrings. A transit node monitors the state of its directly-connected RRPP links and notifies the master node of any link state changes. Based on the link state changes, the master node chooses the operations to be performed.
•
Edge node—A special node residing on both the primary ring and a subring at the same time. An edge node serves as a master node or transit node on the primary ring and an edge node on the subring.
• Assistant-edge node—A special node residing on both the primary ring and a subring at the same time. An assistant-edge node serves as a master node or transit node on the primary ring and an assistant-edge node on the subring. This node works in conjunction with the edge node to detect the integrity of the primary ring and perform loop guard.
As shown in
Figure 11 , Ring 1 is the primary ring and Ring 2 is a subring. Device A is the master node
of Ring 1. Device B, Device C, and Device D are the transit nodes of Ring 1. Device E is the master node of Ring 2, Device B is the edge node of Ring 2, and Device C is the assistant-edge node of Ring 2.
51
Primary port and secondary port
Each master node or transit node has two ports connected to an RRPP ring, one serving as the primary port and the other serving as the secondary port. You can determine the role of a port. The functional differences are:
1. Master node—The primary port and the secondary port of a master node function differently:
{
The primary port sends loop-detect packets and the secondary port receives loop-detect packets.
{
{
When an RRPP ring is in Health state, the secondary port of the master node logically denies data VLANs and permits only the packets from the control VLANs.
When an RRPP ring is in Disconnect state, the secondary port of the master node forwards packets from data VLANs.
2. Transit node—The primary port and the secondary port of a transit node function the same. Both transfer protocol packets and data packets over an RRPP ring.
is the secondary port of the master node on Ring 1. Device B, Device C, and Device D are the transit nodes of Ring 1. Their Port 1 is the primary port and their Port 2 is the secondary port on Ring 1.
Common port and edge port
Edge node ports and assistant-edge node ports that connect to the primary ring are common ports. Edge node ports and assistant-edge node edge ports only connect to the subrings are edge ports.
Device C's Port 1 and Port 2 access the primary ring, so they are common ports. Device B's Port 3 and
Device C's Port 3 access only the subring, so they are edge ports.
RRPP ring group
To reduce Edge-Hello traffic, configure a group of subrings on the edge node or assistant-edge node. For more information about Edge-Hello packets, see "
RRPPDUs ." You must configure a device as the edge
node of these subrings, and another device as the assistant-edge node of these subrings. Additionally, the subrings of the edge node and assistant-edge node must connect to the same subring packet tunnels in major ring (SRPTs), so that Edge-Hello packets of the edge node of these subrings travel to the assistant-edge node of these subrings over the same link.
An RRPP ring group configured on the edge node is an edge node RRPP ring group. An RRPP ring group configured on an assistant-edge node is an assistant-edge node RRPP ring group. Up to one subring in an edge node RRPP ring group is allowed to send Edge-Hello packets.
RRPPDUs
RRPPDUs of subrings are transmitted as data packets in the primary ring, and RRPPDUs of the primary ring can only be transmitted within the primary ring.
Table 18 RRPPDU types and their functions
Type
Hello
Fast-Hello
Description
The master node initiates Hello packets to detect the integrity of a ring in a network.
The master node initiates Fast-Hello packets to fast detect the integrity of a ring in a network.
52
Type
Link-Down
Common-Flush-FDB
Complete-Flush-FDB
Edge-Hello
Fast-Edge-Hello
Major-Fault
Description
The transit node, the edge node or the assistant-edge node initiates Link-Down packets to notify the master node of the disappearance of a ring in case of a link failure.
The master node initiates Common-Flush-FDB packets to instruct the transit nodes to update their own MAC entries and ARP/ND entries when an RRPP ring transits to
Disconnect state.
The master node initiates Complete-Flush-FDB packets to instruct the transit nodes to update their own MAC entries and ARP/ND entries, and release blocked ports from being blocked temporarily when an RRPP ring transits to Health state.
The edge node initiates Edge-Hello packets to examine the SRPTs between the edge node and the assistant-edge node.
The edge node initiates Fast-Edge-Hello packets to fast examine the SRPTs between it and the assistant-edge node.
The assistant-edge node initiates Major-Fault packets to notify the edge node of SRPT failure when an SRPT between edge node and assistant-edge node is torn down.
RRPP timers
When RRPP examines the link state of an Ethernet ring, the master node sends Hello packets out the primary port according to the Hello timer, and determines whether its secondary port receives the Hello packets based on the Fail timer.
•
Hello timer—Specifies the interval at which the master node sends Hello packets out the primary port.
•
Fail timer—Specifies the maximum delay between the master node sending Hello packets out the primary port and the secondary port receiving the Hello packets from the primary port. If the secondary port receives the Hello packets sent by the local master node before the Fail timer expires, the overall ring is in Health state. Otherwise, the ring transits into Disconnect state.
• Fast-Hello timer—Specifies the interval at which the master node sends Fast-Hello packets out from the primary port.
•
Fast-Fail timer—Specifies the maximum delay between the master node sending Fast-Hello packets out from the primary port and the secondary port receiving the Fast-Hello packets from the primary port. If the secondary port receives the Fast-Hello packets sent by the local master node before the
Fast-Fail timer expires, the entire ring is in Health state. Otherwise, the ring transits into the
Disconnect state.
In an RRPP domain, a transit node learns the Hello timer value and the Fail timer value on the master node through the received Hello packets, ensuring that all nodes in the ring network are consistent in the two timer settings. A transit node, however, cannot learn the Fast-Hello timer value and the Fast-Fail timer value set on the master node through received Fast-Hello packets.
How RRPP works
This section explains the way that RRPP works.
Polling mechanism
The polling mechanism is used by the master node of an RRPP ring to examine the Health state of the ring network.
53
The master node periodically sends Hello packets out from its primary port. These Hello packets travel through each transit node on the ring in turn:
•
If the ring is complete, the secondary port of the master node receives Hello packets before the Fail timer expires and the master node keeps the secondary port blocked.
• If the ring is torn down, the secondary port of the master node fails to receive Hello packets before the Fail timer expires. The master node releases the secondary port from blocking data VLANs and sending Common-Flush-FDB packets to instruct all transit nodes to update their own MAC entries and ARP/ND entries.
Link down alarm mechanism
When a transit node, edge node, or assistant-edge node finds any of its own ports belonging to an RRPP domain is down, it immediately sends Link-Down packets to the master node. Upon the receipt of a
Link-Down packet, the master node releases the secondary port from blocking data VLANs, and sends
Common-Flush-FDB packet to instruct all transit nodes, edge nodes, and assistant-edge nodes to update their own MAC and ARP/ND entries. After each node updates its own entries, traffic is switched to the normal link.
Ring recovery
After the ports belonging to the RRPP domain on the transit nodes, edge nodes, or assistant-edge nodes are brought up again, the master node may find the ring is restored after a period of time. A temporary loop may arise in the data VLAN during this period, resulting in a broadcast storm.
To prevent temporary loops, when non-master nodes find that their ports accessing the ring are brought up again, they immediately block them and permit only the packets from the control VLAN to pass through. The blocked ports are activated only when the nodes confirm that the ports do not cause a loop.
Broadcast storm suppression mechanism in case of SRPT failure in a multi-homed subring
As shown in
, Ring 1 is the primary ring, and Ring 2 and Ring 3 are subrings. When the two
SRPTs between the edge node and the assistant-edge node are down, the master nodes of Ring 2 and
Ring 3 open their respective secondary ports, and a loop among Device B, Device C, Device E, and
Device F is generated. As a result, broadcast storm occurs.
To avoid generating a loop, the edge node temporarily blocks the edge port. The blocked edge port is activated only when the edge node is sure that activating it does not cause a loop.
Load balancing
In a ring network, traffic from multiple VLANs may be transmitted at the same time. RRPP can implement load balancing for the traffic by transmitting traffic from different VLANs along different paths.
By configuring an individual RRPP domain for transmitting the traffic from the specified VLANs (protected
VLANs) in a ring network, traffic from different VLANs can be transmitted according to different topologies in the ring network for load balancing.
As shown in
Figure 16 , Ring 1 is configured as the primary ring of Domain 1 and Domain 2, which are
configured with different protected VLANs. Device A is the master node of Ring 1 in Domain 1. Device
B is the master node of Ring 1 in Domain 2. With such configurations, traffic from different VLANs can be transmitted on different links for load balancing in the single-ring network.
RRPP ring group
In an edge node RRPP ring group, only an activated subring with the lowest domain ID and ring ID can send Edge-Hello packets. In an assistant-edge node RRPP ring group, any activated subring that has received Edge-Hello packets forwards these packets to the other activated subrings. With an edge node
RRPP ring group and an assistant-edge node RRPP ring group configured, only one subring sends
54
Edge-Hello packets on the edge node, and only one subring receives Edge-Hello packets on the assistant-edge node, reducing CPU workload.
, Device B is the edge node of Ring 2 and Ring 3, and Device C is the assistant-edge node of Ring 2 and Ring 3. Device B and Device C send or receive Edge-Hello packets frequently. If more subrings are configured or load balancing is configured for more multiple domains,
Device B and Device C sends or receives a mass of Edge-Hello packets.
To reduce Edge-Hello traffic, assign Ring 2 and Ring 3 to an RRPP ring group configured on the edge node Device B, and assign Ring 2 and Ring 3 to an RRPP ring group configured on Device C. After such configurations, if all rings are activated, only Ring 2 on Device B sends Edge-Hello packets.
Fast detection mechanism
Ideally, an RRPP ring can fast converge because its transit nodes can detect link failures fast and send out notifications immediately. In practice, some devices on an RRPP ring may not support RRPP. RRPP can detect link failures between these devices only through the timeout mechanism. This results in long-time traffic interruption and failure to implement millisecond-level convergence.
To address this problem, a fast detection mechanism was introduced. The mechanism works as follows:
• The master node sends Fast-Hello packets out its primary port at the interval specified by the
Fast-Hello timer. If the secondary port receives the Fast-Hello packets sent by the local master node before the Fast-Fail timer expires, the entire ring is in Health state. Otherwise, the ring transits into the Disconnect state.
•
The edge node sends Fast-Edge-Hello packets out its common ports at the interval specified by the timer resolution. If the assistant-edge node fails to receive the Fast-Edge-Hello packets within three times the timer resolution, the SRPTs transit to Disconnect state.
As shown in
Figure 12 , with fast detection enabled for RRPP domain 1, Device A, the master node of Ring
1, sends out Fast-Hello packets periodically and determines the ring status according to whether
Fast-Hello packets are received before the Fast-Fail timer expires, implementing link status fast detection.
NOTE:
• Timer resolution refers to the shortest-period timer provided on an RRPP node.
• To implement fast detection on an RRPP ring, enable fast detection on the master node, edge node, and assistant-edge node of the RRPP ring.
Typical RRPP networking
This section lists the typical networking applications of RRPP.
Single ring
As shown in
Figure 12 , only a single ring exists in the network topology. You only need to define one RRPP
domain.
55
Figure 12 Schematic diagram for a single-ring network
Tangent rings
, two or more rings exist in the network topology and only one common node exists between rings. You must define an RRPP domain for each ring.
Figure 13 Schematic diagram for a tangent-ring network
Intersecting rings
As shown in
, two or more rings exist in the network topology and two common nodes exist between rings. You only need to define an RRPP domain, and configure one ring as the primary ring and the other rings as subrings.
56
Figure 14 Schematic diagram for an intersecting-ring network
Dual-homed rings
As shown in
, two or more rings exist in the network topology and two similar common nodes exist between rings. You only need to define an RRPP domain, and configure one ring as the primary ring and the other rings as subrings.
Figure 15 Schematic diagram for a dual-homed-ring network
Single-ring load balancing
In a single-ring network, you can achieve load balancing by configuring multiple domains.
, Ring 1 is configured as the primary ring of both Domain 1 and Domain 2.
Domain 1 and Domain 2 are configured with different protected VLANs. In Domain 1, Device A is configured as the master node of Ring 1. In Domain 2, Device B is configured as the master node of Ring
1. Such configurations enable the ring to block different links based on VLANs and achieve single-ring load balancing.
57
Figure 16 Schematic diagram for a single-ring load balancing network
Intersecting-ring load balancing
In an intersecting-ring network, you can also achieve load balancing by configuring multiple domains.
As shown in
Figure 17 , Ring 1 is the primary ring and Ring 2 is the subring in both Domain 1 and Domain
2. Domain 1 and Domain 2 are configured with different protected VLANs. Device A is configured as the master node of Ring 1 in Domain 1. Device D is configured as the master node of Ring 1 in Domain 2.
Device E is configured as the master node of Ring 2 in both Domain 1 and Domain 2. However, different ports on Device E are blocked in Domain 1 and Domain 2. With the configurations, you can enable traffic from different VLANs to travel over different paths in the subring and primary ring, achieving intersecting-ring load balancing.
Figure 17 Schematic diagram for an intersecting-ring load balancing network
Protocols and standards
RFC 3619, Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1.
58
RRPP configuration task list
You can create RRPP domains based on service planning, specify control VLANs and data VLANs for each RRPP domain, and then determine the ring roles and node roles based on the traffic paths in each
RRPP domain.
RRPP does not have an auto election mechanism, so you must configure each node in the ring network properly for RRPP to monitor and protect the ring network.
Before you configure RRPP, physically construct a ring-shaped Ethernet topology.
Task Remarks
Required.
Perform this task on all nodes in the RRPP domain.
Configuring RRPP fast detection
Configuring fast detection timers
Configuring an RRPP ring group
Required.
Perform this task on all nodes in the RRPP domain.
Required.
Perform this task on all nodes in the RRPP domain.
Required.
Perform this task on all nodes in the RRPP domain.
Required.
Perform this task on all nodes in the RRPP domain.
Required.
Perform this task on all nodes in the RRPP domain.
Optional.
Perform this task on the master node in the RRPP domain.
Optional.
Perform this task on the master node, edge node, and assistant-edge node in the RRPP domain.
Optional.
Perform this task on the master node in the RRPP domain.
Optional.
Perform this task on the edge node and assistant-edge node in the RRPP domain.
Creating an RRPP domain
When creating an RRPP domain, specify a domain ID, which uniquely identifies an RRPP domain. All devices in the same RRPP domain must be configured with the same domain ID.
Make this configuration on devices you want to configure as nodes in the RRPP domain.
59
To create an RRPP domain:
Step Command
1. Enter system view. system-view
2. Create an RRPP domain and enter RRPP domain view. rrpp domain domain-id
Configuring control VLANs
When configuring control VLANs for an RRPP domain, you only need to configure the primary control
VLAN. The system automatically configures the secondary control VLAN, and it uses the primary control
VLAN ID plus 1 as the secondary control VLAN ID. For the control VLAN configuration to succeed, make sure the IDs of the two control VLANs are consecutive and have not been assigned yet.
Configuration guidelines
• Before you configure RRPP rings in an RRPP domain, configure the same control VLANs for all nodes in the RRPP domain first.
•
Perform this configuration on all nodes in the RRPP domain to be configured.
•
To ensure proper forwarding of RRPPDUs, do not configure the default VLAN of a port accessing an
RRPP ring as the control VLAN, or enable 802.1Q in 802.1Q (QinQ) or VLAN mapping on the control VLANs.
•
Before configuring RRPP rings for an RRPP domain, you can delete or modify the control VLANs configured for the RRPP domain. However, after configuring RRPP rings for an RRPP domain, you cannot delete or modify the control VLANs of the domain. You can only use the undo control-vlan command to delete a control VLAN.
•
To transparently transmit RRPPDUs on a device not configured with RRPP, make sure only the two ports connecting the device to the RRPP ring permit packets from the control VLANs. Otherwise, the packets from other VLANs may enter the control VLANs in transparent transmission mode and strike the RRPP ring.
Configuration procedure
To configure control VLANs:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view.
3. Configure the primary control VLAN for the RRPP domain. rrpp domain domain-id control-vlan vlan-id
Configuring protected VLANs
Before you configure RRPP rings in an RRPP domain, configure the same protected VLANs for all nodes in the RRPP domain first. All VLANs that the RRPP ports are assigned to should be protected by the RRPP domains.
60
You can configure protected VLANs through referencing MSTIs. Before configuring protected VLANs, configure the mappings between MSTIs and the VLANs to be protected. (A device operating in PVST mode automatically maps VLANs to MSTIs.) For more information about MSTIs and PVST, see Layer
2—LAN Switching Configuration Guide.
When you configure load balancing, configure different protected VLANs for different RRPP domains.
Perform this configuration on all nodes in the RRPP domain to be configured.
For more information about the stp region-configuration, instance, vlan-mapping modulo, active region-configuration, and display stp region-configuration commands, see Layer 2—LAN Switching
Command Reference.
To configure protected VLANs:
Step Command
1. Enter system view.
2. Enter MST region view.
3.
7.
Enter RRPP domain view.
8. Configure protected VLANs for the RRPP domain. stp region-configuration
VLAN-to-instance mapping table.
6. Return to system view. system-view
•
Approach 1:
Configure the
• quit
vlan-list
Approach 2: vlan-mapping modulo modulo
4. Activate MST region configuration manually. active region-configuration
5. Display the currently activated configuration information of the MST region. display stp region-configuration [ |
{ begin | exclude | include }
regular-expression ] rrpp domain domain-id protected-vlan reference-instance
instance-id-list
Remarks
N/A
Not required if the device works in
PVST mode.
Optional.
Use either approach.
All VLANs in an MST region are mapped to MSTI 0 (the CIST) by default.
Not required if the device works in
PVST mode.
Not required if the device works in
PVST mode.
Optional.
Available in any view.
The output of the command includes VLAN-to-instance mappings.
Not required if the device works in
PVST mode.
N/A
By default, no protected VLAN is configured for an RRPP domain.
Configuring RRPP rings
This section describes how to configure RRPP rings.
Configuration guidelines
•
When you configure an RRPP ring, make some configurations on the ports connecting each node to the RRPP ring before configuring the nodes.
61
• RRPP ports (connecting devices to an RRPP ring) must be Layer 2 Ethernet interfaces or Layer 2 aggregate interfaces, and they cannot be member ports of any aggregation group, service loopback group, or smart link group.
• After configuring a Layer-2 aggregate interface as an RRPP port, you can still assign ports to or remove ports from the aggregation group corresponding to the interface.
Configuring RRPP ports
Follow these guidelines when you configure RRPP ports:
• RRPP ports always allow packets from the control VLANs to pass through.
•
For more information about the port link-type trunk, port trunk permit vlan, and undo stp enable commands, see Layer 2—LAN Switching Command Reference.
• Do not configure a port accessing an RRPP ring as the destination port of a mirroring group.
•
Do not configure physical-link-state change suppression time on a port accessing an RRPP ring to accelerate topology convergence. For more information, see the undo link-delay command (Layer
2—LAN Switching Command Reference).
• Perform this configuration on each node's ports intended for accessing RRPP rings.
To configure RRPP ports:
Remarks
N/A
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view. interface interface-type
interface-number
3. Configure the link type of the interface as trunk. port link-type trunk
4. Assign the trunk port to the protected VLANs of the RRPP domain. port trunk permit vlan { vlan-id-list
| all }
5. Disable the spanning tree feature. undo stp enable
N/A
By default, the link type of the interface is access.
By default, a trunk port only allows packets from VLAN 1 to pass through.
By default, the spanning tree feature is enabled.
Configuring RRPP nodes
If a device carries multiple RRPP rings in an RRPP domain, only one ring can be configured as the primary ring on the device and the role of the device on a subring can only be an edge node or an assistant-edge node.
Specifying a master node
Perform this configuration on a device to be configured as a master node.
To specify a master node:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view. rrpp domain domain-id
62
Step Command
3. Specify the current device as the master node of the ring, and specify the primary port and the secondary port. ring ring-id node-mode master [ primary-port interface-type
interface-number ] [ secondary-port interface-type
interface-number ] level level-value
Specifying a transit node
Perform this configuration on a device to be configured as a transit node.
To specify a transit node:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view. rrpp domain domain-id
3. Specify the current device as a transit node of the ring, and specify the primary port and the secondary port. ring ring-id node-mode transit [ primary-port interface-type
interface-number ] [ secondary-port interface-type
interface-number ] level level-value
Specifying an edge node
When you configure an edge node, first configure the primary ring before configuring the subrings.
Perform this configuration on a device to be configured as an edge node.
To specify an edge node:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view.
3. Specify the current device as a master node or transit node of the primary ring, and specify the primary port and the secondary port.
4. Specify the current device as the edge node of a subring, and specify the edge port. rrpp domain domain-id ring ring-id node-mode { master | transit } [ primary-port
interface-type interface-number ] [ secondary-port
interface-type interface-number ] level level-value ring ring-id node-mode edge [ edge-port interface-type
interface-number ]
Specifying an assistant-edge node
When you configure an assistant-edge node, first configure the primary ring before configuring the subrings.
Perform this configuration on a device to be configured as an assistant-edge node.
To specify an assistant-edge node:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view. rrpp domain domain-id
63
Step Command
3. Specify the current device as a master node or transit node of the primary ring, and specify the primary port and the secondary port. ring ring-id node-mode { master | transit } [ primary-port
interface-type interface-number ] [ secondary-port
interface-type interface-number ] level level-value
4. Specify the current device as the assistant-edge node of the subring, and specify an edge port. ring ring-id node-mode assistant-edge [ edge-port
interface-type interface-number ]
Activating an RRPP domain
To activate an RRPP domain on the current device, enable the RRPP protocol and RRPP rings for the RRPP domain on the current device.
Perform this operation on all nodes in the RRPP domain.
To prevent Hello packets of subrings from being looped on the primary ring, enable the primary ring on its master node before enabling the subrings on their separate master nodes. On an edge node or assistant-edge node, enable/disable the primary ring and subrings separately:
•
Enable the primary ring of an RRPP domain before enabling the subrings of the RRPP domain.
•
Disable the primary ring of an RRPP domain after disabling all subrings of the RRPP domain.
To activate an RRPP domain:
Step Command
1. Enter system view. system-view
2. Enable RRPP. rrpp enable
3. Enter RRPP domain view. rrpp domain domain-id
4. Enable the specified RRPP ring. ring ring-id enable
Remarks
N/A
By default, RRPP is disabled.
N/A
By default, the specified RRPP ring is disabled.
Configuring RRPP timers
Follow these guidelines when you configure RRPP timers:
•
Perform this configuration on the master node of an RRPP domain.
•
The Fail timer value must be equal to or greater than three times the Hello timer value.
• To avoid temporary loops when the primary ring fails in a dual-homed-ring network, make sure the difference between the Fail timer value on the master node of the subring and that on the master node of the primary ring is greater than twice the Hello timer value of the master node of the subring.
To configure RRPP timers:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view. rrpp domain domain-id
Remarks
N/A
N/A
64
Step Command
3. Configure the Hello timer and Fail timer for the RRPP domain. timer hello-timer hello-value fail-timer fail-value
Remarks
By default, the Hello timer value is 1 second and the Fail timer value is 3 seconds.
Configuring RRPP fast detection
Enabling fast detection
Follow these guidelines when you enable fast detection:
• Perform this configuration on the master node, edge node, and assistant-edge node in the RRPP domain to be configured.
•
To configure fast detection on the master node of a subring, make sure the edge node and assistant-edge node of the subring support fast detection. Otherwise, do not configure fast detection on the master node of the subring.
•
When configuring fast detection in an RRPP domain, enable fast detection first on the edge node, and then on the assistant-edge node. Otherwise, the assistant-edge node may fail to receive
Fast-Edge-Hello packets and erroneously conclude that the master node is faulty.
To enable fast detection:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view. rrpp domain domain-id
3. Enable fast detection. fast-detection enable
Remarks
N/A
N/A
By default, fast detection is disabled.
Configuring fast detection timers
Follow these guidelines when you configure fast detection timers:
•
Perform this configuration on the master node in the RRPP domain to be configured.
•
The value of the Fast-Fail timer must be equal to or greater than three times the Fast-Hello timer.
• In a dual-homed-ring network, to avoid temporary loops when the primary ring fails, make sure the
Fast-Fail timer value is equal to or greater than six times the timer resolution. Also, make sure the difference between the Fast-Fail timer value on the master node of the subring and that on the master node of the primary ring is greater than twice the Fast-Hello timer value of the master node of the subring.
To configure RRPP fast detection timers:
Step Command
1. Enter system view. system-view
2. Enter RRPP domain view. rrpp domain domain-id
Remarks
N/A
N/A
65
Step Command
3. Configure the Fast-Fail timer. timer fast-fail-timer fast-fail-value
4. Configure the
Fast-Hello timer. timer fast-hello-timer
fast-hello-value
Remarks
Optional.
By default, the Fast-Fail timer is 600 milliseconds.
Optional.
By default, the Fast-Hello timer is 200 milliseconds.
Configuring an RRPP ring group
This section describes how to configure an RRPP ring group.
Configuration guidelines
• To reduce Edge-Hello traffic, adopt the RRPP ring group mechanism by assigning subrings with the same edge node/assistant-edge node to an RRPP ring group. An RRPP ring group must be configured on both the edge node and the assistant-edge node, and can only be configured on these two types of nodes.
•
Perform this configuration on both the edge node and the assistant-edge node in an RRPP domain.
•
You can only assign a subring to one RRPP ring group. The RRPP ring group configured on the edge node and that configured on the assistant-edge node must contain the same subrings. Otherwise, the RRPP ring group cannot operate properly.
•
Make sure the subrings in an RRPP ring group share the same edge node and assistant-edge node, and the edge node and the assistant edge node have the same SRPTs.
•
Make sure a device plays the same role on the subrings in an RRPP ring group. The role can be the edge node or the assistant-edge node.
•
Make sure the RRPP ring group on the edge node and that on the assistant-edge node have the same configurations and activation status.
• Make sure all subrings in an RRPP ring group have the same SRPTs. If the SRPTs of these subrings are configured or modified differently, the RRPP ring group cannot operate properly.
Configuration procedure
To configure an RRPP ring group:
Step Command
1. Enter system view. system-view
2. Create an RRPP ring group and enter RRPP ring group view.
3. Assign the specified subrings to the RRPP ring group. rrpp ring-group ring-group-id domain domain-id ring ring-id-list
Displaying and maintaining RRPP
66
Task Command
Display brief RRPP information. display rrpp brief [ | { begin | exclude | include } regular-expression ]
Display RRPP group configuration information. display rrpp ring-group [ ring-group-id ] [ |
{ begin | exclude | include }
regular-expression ]
Display detailed RRPP information.
Display RRPP statistics.
Clear RRPP statistics. display rrpp verbose domain domain-id [ ring
ring-id ] [ | { begin | exclude | include }
regular-expression ] display rrpp statistics domain domain-id [ ring
ring-id ] [ | { begin | exclude | include }
regular-expression ] reset rrpp statistics domain domain-id [ ring
ring-id ]
Remarks
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in user view.
RRPP configuration examples
This section provides configuration examples for RRPP.
Single ring configuration example
Networking requirements
As shown in
,
• Device A, Device B, Device C, and Device D form RRPP domain 1. Specify the primary control VLAN of RRPP domain 1 as VLAN 4092, and specify that RRPP domain 1 protects VLANs 1 through 30.
•
Device A, Device B, Device C, and Device D form primary ring 1.
• Specify Device A as the master node of primary ring 1, GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port.
•
Specify Device B, Device C, and Device D as the transit nodes of primary ring 1, their
GigabitEthernet 1/0/1 as the primary port, and GigabitEthernet 1/0/2 as the secondary port.
Figure 18 Network diagram
67
Configuration procedure
1. Configure Device A:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceA> system-view
[DeviceA] vlan 1 to 30
[DeviceA] stp region-configuration
[DeviceA-mst-region] instance 1 vlan 1 to 30
[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] undo link-delay
[DeviceA-GigabitEthernet1/0/1] undo stp enable
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] undo link-delay
[DeviceA-GigabitEthernet1/0/2] undo stp enable
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceA] rrpp domain 1
[DeviceA-rrpp-domain1] control-vlan 4092
[DeviceA-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceA-rrpp-domain1] ring 1 enable
[DeviceA-rrpp-domain1] quit
# Enable RRPP.
[DeviceA] rrpp enable
2. Configure Device B:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceB> system-view
[DeviceB] vlan 1 to 30
[DeviceB] stp region-configuration
[DeviceB-mst-region] instance 1 vlan 1 to 30
[DeviceB-mst-region] active region-configuration
[DeviceB-mst-region] quit
68
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2, disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] undo link-delay
[DeviceB-GigabitEthernet1/0/1] undo stp enable
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] undo link-delay
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceB] rrpp domain 1
[DeviceB-rrpp-domain1] control-vlan 4092
[DeviceB-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device B as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceB-rrpp-domain1] ring 1 enable
[DeviceB-rrpp-domain1] quit
# Enable RRPP.
[DeviceB] rrpp enable
3. Configure Device C in the same way as you configure Device B.
4. Configure Device D in the same way as you configure Device B.
Verifying the configuration
Use the display command to view RRPP configuration and operational information on each device.
Intersecting ring configuration example
Networking requirements
As shown in
•
Device A, Device B, Device C, Device D, and Device E form RRPP domain 1, VLAN 4092 is the primary control VLAN of RRPP domain 1, and RRPP domain 1 protects VLANs 1 through 30.
• Device A, Device B, Device C, and Device D form primary ring 1, and Device B, Device C and
Device E form subring 2.
•
Device A is the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and
GigabitEthernet 1/0/2 the secondary port.
• Device E is the master node of subring 2, with GigabitEthernet 1/0/1 as the primary port and
GigabitEthernet 1/0/2 the secondary port.
69
• Device B is the transit node of primary ring 1 and the edge node of subring 2, and GigabitEthernet
1/0/3 is the edge port.
•
Device C is the transit node of primary ring 1 and the assistant-edge node of subring 1, and
GigabitEthernet 1/0/3 is the edge port.
• Device D is the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and
GigabitEthernet 1/0/2 the secondary port.
Figure 19 Network diagram
Configuration procedure
1. Configure Device A:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceA> system-view
[DeviceA] vlan 1 to 30
[DeviceA] stp region-configuration
[DeviceA-mst-region] instance 1 vlan 1 to 30
[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2, disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] undo link-delay
[DeviceA-GigabitEthernet1/0/1] undo stp enable
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] undo link-delay
[DeviceA-GigabitEthernet1/0/2] undo stp enable
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/2] quit
70
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceA] rrpp domain 1
[DeviceA-rrpp-domain1] control-vlan 4092
[DeviceA-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceA-rrpp-domain1] ring 1 enable
[DeviceA-rrpp-domain1] quit
# Enable RRPP.
[DeviceA] rrpp enable
2. Configure Device B:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceB> system-view
[DeviceB] vlan 1 to 30
[DeviceB] stp region-configuration
[DeviceB-mst-region] instance 1 vlan 1 to 30
[DeviceB-mst-region] active region-configuration
[DeviceB-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1,
GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3. Disable the spanning tree feature, configure the ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] undo link-delay
[DeviceB-GigabitEthernet1/0/1] undo stp enable
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] undo link-delay
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/2] quit
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] undo link-delay
[DeviceB-GigabitEthernet1/0/3] undo stp enable
[DeviceB-GigabitEthernet1/0/3] port link-type trunk
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/3] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceB] rrpp domain 1
[DeviceB-rrpp-domain1] control-vlan 4092
[DeviceB-rrpp-domain1] protected-vlan reference-instance 1
71
# Configure Device B as a transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceB-rrpp-domain1] ring 1 enable
# Configure Device B as the edge node of subring 2, with GigabitEthernet 1/0/3 as the edge port, and enable ring 2.
[DeviceB-rrpp-domain1] ring 2 node-mode edge edge-port gigabitethernet 1/0/3
[DeviceB-rrpp-domain1] ring 2 enable
[DeviceB-rrpp-domain1] quit
# Enable RRPP.
[DeviceB] rrpp enable
3. Configure Device C:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 1 to 30
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 1 to 30
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1,
GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3. Disable the spanning tree feature, configure the ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo link-delay
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo link-delay
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/2] quit
[DeviceC] interface gigabitethernet 1/0/3
[DeviceC-GigabitEthernet1/0/3] undo link-delay
[DeviceC-GigabitEthernet1/0/3] undo stp enable
[DeviceC-GigabitEthernet1/0/3] port link-type trunk
[DeviceC-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/3] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceC] rrpp domain 1
[DeviceC-rrpp-domain1] control-vlan 4092
[DeviceC-rrpp-domain1] protected-vlan reference-instance 1
72
# Configure Device C as a transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceC-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceC-rrpp-domain1] ring 1 enable
# Configure Device C as the assistant-edge node of subring 2, with GigabitEthernet 1/0/3 as the edge port, and enable ring 2.
[DeviceC-rrpp-domain1] ring 2 node-mode assistant-edge edge-port gigabitethernet
1/0/3
[DeviceC-rrpp-domain1] ring 2 enable
[DeviceC-rrpp-domain1] quit
# Enable RRPP.
[DeviceC] rrpp enable
4. Configure Device D:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceD> system-view
[DeviceD] vlan 1 to 30
[DeviceD] stp region-configuration
[DeviceD-mst-region] instance 1 vlan 1 to 30
[DeviceD-mst-region] active region-configuration
[DeviceD-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] undo link-delay
[DeviceD-GigabitEthernet1/0/1] undo stp enable
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] undo link-delay
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceD] rrpp domain 1
[DeviceD-rrpp-domain1] control-vlan 4092
[DeviceD-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device D as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceD-rrpp-domain1] ring 1 enable
[DeviceD-rrpp-domain1] quit
73
# Enable RRPP.
[DeviceD] rrpp enable
5. Configure Device E:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceE> system-view
[DeviceE] vlan 1 to 30
[DeviceE] stp region-configuration
[DeviceE-mst-region] instance 1 vlan 1 to 30
[DeviceE-mst-region] active region-configuration
[DeviceE-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceE] interface gigabitethernet 1/0/1
[DeviceE-GigabitEthernet1/0/1] undo link-delay
[DeviceE-GigabitEthernet1/0/1] undo stp enable
[DeviceE-GigabitEthernet1/0/1] port link-type trunk
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/1] quit
[DeviceE] interface gigabitethernet 1/0/2
[DeviceE-GigabitEthernet1/0/2] undo link-delay
[DeviceE-GigabitEthernet1/0/2] undo stp enable
[DeviceE-GigabitEthernet1/0/2] port link-type trunk
[DeviceE-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceE] rrpp domain 1
[DeviceE-rrpp-domain1] control-vlan 4092
[DeviceE-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device E as the master node of subring 2, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 2.
[DeviceE-rrpp-domain1] ring 2 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1
[DeviceE-rrpp-domain1] ring 2 enable
[DeviceE-rrpp-domain1] quit
# Enable RRPP.
[DeviceE] rrpp enable
Verifying the configuration
Use the display command to view RRPP configuration and operational information on each device.
Dual homed rings configuration example
Networking requirements
As shown in
,
74
• Device A through Device H form RRPP domain 1. Specify the primary control VLAN of RRPP domain
1 as VLAN 4092, and specify that RRPP domain 1 protects VLANs 1 through 30.
•
Device A through Device D form primary ring 1. Device A, Device B, and Device E form subring 2.
Device A, Device B, and Device F form subring 3. Device C, Device D, and Device G form subring
4. Device C, Device D, and Device H form subring 5.
•
Specify Device A as the master node of primary ring 1, GigabitEthernet 1/0/1 as the primary port, and GigabitEthernet 1/0/2 as the secondary port. Specify Device E as the master node of subring
2, GigabitEthernet 1/0/1 as the primary port, and GigabitEthernet 1/0/2 as the secondary port.
Specify Device F as the master node of subring 3, GigabitEthernet 1/0/1 as the primary port and
GigabitEthernet 1/0/2 as the secondary port. Specify Device G as the master node of subring 4,
GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port.
Specify Device H as the master node of subring 5, GigabitEthernet 1/0/1 as the primary port, and
GigabitEthernet 1/0/2 as the secondary port.
•
Specify Device A as the edge node of the connected subrings, its GigabitEthernet 1/0/3 and
GigabitEthernet 1/0/4 as the edge ports. Specify Device D as the transit node of the primary ring and edge node of the connected subrings, its GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 as the edge ports. Specify Device B and Device C as the transit node of the primary ring and assistant-edge nodes of the connected subrings, their GigabitEthernet 1/0/3 and GigabitEthernet
1/0/4 as the edge ports.
NOTE:
Configure the primary and secondary ports on the master nodes properly to make sure other protocols still work normally when data VLANs are denied by the secondary ports.
Figure 20 Network diagram
Device E
Master node
GE1/0/1
G
E1
/0/2
Device A
Edge node & master node
GE1/0/4 GE1/0/2
Ring 2
G
E1/
0/3
GE1/0/1
Domain 1
Device D
Edge node
GE1/0/2
GE1/0/1
Device G
Master node
GE1/0/3
GE1/0
/4
Ring 4
GE1/0/1
G
E1/
0/2
Ring 1
1
GE1/0/
GE1/0/2
Ring 3
GE1/0/
GE1/0/3
4
GE1/0/1
GE1/0/2
GE1/0/2
GE1/0/1
/3
GE1/0
GE1/04
Ring 5
GE1/0
/1
GE1/0/2
Device F
Master node
Device B
Assistant edge node
Device C
Assistant edge node
Device H
Master node
Configuration procedure
1. Configure Device A:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceA> system-view
75
[DeviceA] vlan 1 to 30
[DeviceA] stp region-configuration
[DeviceA-mst-region] instance 1 vlan 1 to 30
[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through
GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] undo link-delay
[DeviceA-GigabitEthernet1/0/1] undo stp enable
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] undo link-delay
[DeviceA-GigabitEthernet1/0/2] undo stp enable
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/2] quit
[DeviceA] interface gigabitethernet 1/0/3
[DeviceA-GigabitEthernet1/0/3] undo link-delay
[DeviceA-GigabitEthernet1/0/3] undo stp enable
[DeviceA-GigabitEthernet1/0/3] port link-type trunk
[DeviceA-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/3] quit
[DeviceA] interface gigabitethernet 1/0/4
[DeviceA-GigabitEthernet1/0/4] undo link-delay
[DeviceA-GigabitEthernet1/0/4] undo stp enable
[DeviceA-GigabitEthernet1/0/4] port link-type trunk
[DeviceA-GigabitEthernet1/0/4] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/4] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceA] rrpp domain 1
[DeviceA-rrpp-domain1] control-vlan 4092
[DeviceA-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceA-rrpp-domain1] ring 1 enable
# Configure Device A as the edge node of subring 2, with GigabitEthernet 1/0/4 as the edge port, and enable subring 2.
[DeviceA-rrpp-domain1] ring 2 node-mode edge edge-port gigabitethernet 1/0/4
[DeviceA-rrpp-domain1] ring 2 enable
# Configure Device A as the edge node of subring 3, with GigabitEthernet 1/0/3 as the edge port, and enable subring 3.
76
[DeviceA-rrpp-domain1] ring 3 node-mode edge edge-port gigabitethernet 1/0/3
[DeviceA-rrpp-domain1] ring 3 enable
[DeviceA-rrpp-domain1] quit
# Enable RRPP.
[DeviceA] rrpp enable
2. Configure Device B:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceB> system-view
[DeviceB] vlan 1 to 30
[DeviceB] stp region-configuration
[DeviceB-mst-region] instance 1 vlan 1 to 30
[DeviceB-mst-region] active region-configuration
[DeviceB-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through
GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] undo link-delay
[DeviceB-GigabitEthernet1/0/1] undo stp enable
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] undo link-delay
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/2] quit
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] undo link-delay
[DeviceB-GigabitEthernet1/0/3] undo stp enable
[DeviceB-GigabitEthernet1/0/3] port link-type trunk
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/3] quit
[DeviceB] interface gigabitethernet 1/0/4
[DeviceB-GigabitEthernet1/0/4] undo link-delay
[DeviceB-GigabitEthernet1/0/4] undo stp enable
[DeviceB-GigabitEthernet1/0/4] port link-type trunk
[DeviceB-GigabitEthernet1/0/4] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/4] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceB] rrpp domain 1
[DeviceB-rrpp-domain1] control-vlan 4092
[DeviceB-rrpp-domain1] protected-vlan reference-instance 1
77
# Configure Device B as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceB-rrpp-domain1] ring 1 enable
# Configure Device B as the assistant-edge node of subring 2, with GigabitEthernet 1/0/4 as the edge port, and enable subring 2.
[DeviceB-rrpp-domain1] ring 2 node-mode assistant-edge edge-port gigabitethernet
1/0/4
[DeviceB-rrpp-domain1] ring 2 enable
# Configure Device B as the assistant-edge node of subring 3, with GigabitEthernet 1/0/3 as the edge port, and enable subring 3.
[DeviceB-rrpp-domain1] ring 3 node-mode assistant-edge edge-port gigabitethernet
1/0/3
[DeviceB-rrpp-domain1] ring 3 enable
[DeviceB-rrpp-domain1] quit
# Enable RRPP.
[DeviceB] rrpp enable
3. Configure Device C:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 1 to 30
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 1 to 30
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through
GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo link-delay
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo link-delay
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/2] quit
[DeviceC] interface gigabitethernet 1/0/3
[DeviceC-GigabitEthernet1/0/3] undo link-delay
[DeviceC-GigabitEthernet1/0/3] undo stp enable
[DeviceC-GigabitEthernet1/0/3] port link-type trunk
[DeviceC-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/3] quit
78
[DeviceC] interface gigabitethernet 1/0/4
[DeviceC-GigabitEthernet1/0/4] undo link-delay
[DeviceC-GigabitEthernet1/0/4] undo stp enable
[DeviceC-GigabitEthernet1/0/4] port link-type trunk
[DeviceC-GigabitEthernet1/0/4] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/4] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceC] rrpp domain 1
[DeviceC-rrpp-domain1] control-vlan 4092
[DeviceC-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device C as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceC-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceC-rrpp-domain1] ring 1 enable
# Configure Device C as the assistant-edge node of subring 4, with GigabitEthernet 1/0/3 as the edge port, and enable subring 4.
[DeviceC-rrpp-domain1] ring 4 node-mode assistant-edge edge-port gigabitethernet
1/0/3
[DeviceC-rrpp-domain1] ring 4 enable
# Configure Device C as the assistant-edge node of subring 5, with GigabitEthernet 1/0/4 as the edge port, and enable subring 5.
[DeviceC-rrpp-domain1] ring 5 node-mode assistant-edge edge-port gigabitethernet
1/0/4
[DeviceC-rrpp-domain1] ring 5 enable
[DeviceC-rrpp-domain1] quit
# Enable RRPP.
[DeviceC] rrpp enable
4. Configure Device D:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceD> system-view
[DeviceD] vlan 1 to 30
[DeviceD] stp region-configuration
[DeviceD-mst-region] instance 1 vlan 1 to 30
[DeviceD-mst-region] active region-configuration
[DeviceD-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through
GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] undo link-delay
[DeviceD-GigabitEthernet1/0/1] undo stp enable
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/1] quit
79
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] undo link-delay
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/2] quit
[DeviceD] interface gigabitethernet 1/0/3
[DeviceD-GigabitEthernet1/0/3] undo link-delay
[DeviceD-GigabitEthernet1/0/3] undo stp enable
[DeviceD-GigabitEthernet1/0/3] port link-type trunk
[DeviceD-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/3] quit
[DeviceD] interface gigabitethernet 1/0/4
[DeviceD-GigabitEthernet1/0/4] undo link-delay
[DeviceD-GigabitEthernet1/0/4] undo stp enable
[DeviceD-GigabitEthernet1/0/4] port link-type trunk
[DeviceD-GigabitEthernet1/0/4] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/4] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceD] rrpp domain 1
[DeviceD-rrpp-domain1] control-vlan 4092
[DeviceD-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device D as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceD-rrpp-domain1] ring 1 enable
# Configure Device D as the edge node of subring 4, with GigabitEthernet 1/0/3 as the edge port, and enable subring 4.
[DeviceD-rrpp-domain1] ring 4 node-mode edge edge-port gigabitethernet 1/0/3
[DeviceD-rrpp-domain1] ring 4 enable
# Configure Device D as the edge node of subring 5, with GigabitEthernet 1/0/4 as the edge port, and enable subring 5.
[DeviceD-rrpp-domain1] ring 5 node-mode edge edge-port gigabitethernet 1/0/4
[DeviceD-rrpp-domain1] ring 5 enable
[DeviceD-rrpp-domain1] quit
# Enable RRPP.
[DeviceD] rrpp enable
5. Configure Device E:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceE> system-view
[DeviceE] vlan 1 to 30
[DeviceE] stp region-configuration
[DeviceE-mst-region] instance 1 vlan 1 to 30
[DeviceE-mst-region] active region-configuration
80
[DeviceE-mst-region] quit
# Cancel the physical state change suppression interval setting GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceE] interface gigabitethernet 1/0/1
[DeviceE-GigabitEthernet1/0/1] undo link-delay
[DeviceE-GigabitEthernet1/0/1] undo stp enable
[DeviceE-GigabitEthernet1/0/1] port link-type trunk
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/1] quit
[DeviceE] interface gigabitethernet 1/0/2
[DeviceE-GigabitEthernet1/0/2] undo link-delay
[DeviceE-GigabitEthernet1/0/2] undo stp enable
[DeviceE-GigabitEthernet1/0/2] port link-type trunk
[DeviceE-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceE] rrpp domain 1
[DeviceE-rrpp-domain1] control-vlan 4092
[DeviceE-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device E as the master node of subring 2, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 2.
[DeviceE-rrpp-domain1] ring 2 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1
[DeviceE-rrpp-domain1] ring 2 enable
[DeviceE-rrpp-domain1] quit
# Enable RRPP.
[DeviceE] rrpp enable
6. Configure Device F:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceF> system-view
[DeviceF] vlan 1 to 30
[DeviceF] stp region-configuration
[DeviceF-mst-region] instance 1 vlan 1 to 30
[DeviceF-mst-region] active region-configuration
[DeviceF-mst-region] quit
# Cancel the physical state change suppression interval setting GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceF] interface gigabitethernet 1/0/1
[DeviceF-GigabitEthernet1/0/1] undo link-delay
[DeviceF-GigabitEthernet1/0/1] undo stp enable
[DeviceF-GigabitEthernet1/0/1] port link-type trunk
[DeviceF-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceF-GigabitEthernet1/0/1] quit
81
[DeviceF] interface gigabitethernet 1/0/2
[DeviceF-GigabitEthernet1/0/2] undo link-delay
[DeviceF-GigabitEthernet1/0/2] undo stp enable
[DeviceF-GigabitEthernet1/0/2] port link-type trunk
[DeviceF-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceF-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceF] rrpp domain 1
[DeviceF-rrpp-domain1] control-vlan 4092
[DeviceF-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device F as the master node of subring 3, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 3.
[DeviceF-rrpp-domain1] ring 3 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1
[DeviceF-rrpp-domain1] ring 3 enable
[DeviceF-rrpp-domain1] quit
# Enable RRPP.
[DeviceF] rrpp enable
7. Configure Device G:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceG> system-view
[DeviceG] vlan 1 to 30
[DeviceG] stp region-configuration
[DeviceG-mst-region] instance 1 vlan 1 to 30
[DeviceG-mst-region] active region-configuration
[DeviceG-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceG] interface gigabitethernet 1/0/1
[DeviceG-GigabitEthernet1/0/1] undo link-delay
[DeviceG-GigabitEthernet1/0/1] undo stp enable
[DeviceG-GigabitEthernet1/0/1] port link-type trunk
[DeviceG-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceG-GigabitEthernet1/0/1] quit
[DeviceG] interface gigabitethernet 1/0/2
[DeviceG-GigabitEthernet1/0/2] undo link-delay
[DeviceG-GigabitEthernet1/0/2] undo stp enable
[DeviceG-GigabitEthernet1/0/2] port link-type trunk
[DeviceG-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceG-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceG] rrpp domain 1
[DeviceG-rrpp-domain1] control-vlan 4092
82
[DeviceG-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device G as the master node of subring 4, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 4.
[DeviceG-rrpp-domain1] ring 4 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1
[DeviceG-rrpp-domain1] ring 4 enable
[DeviceG-rrpp-domain1] quit
# Enable RRPP.
[DeviceG] rrpp enable
8. Configure Device H:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceH> system-view
[DeviceH] vlan 1 to 30
[DeviceH] stp region-configuration
[DeviceH-mst-region] instance 1 vlan 1 to 30
[DeviceH-mst-region] active region-configuration
[DeviceH-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceH] interface gigabitethernet 1/0/1
[DeviceH-GigabitEthernet1/0/1] undo link-delay
[DeviceH-GigabitEthernet1/0/1] undo stp enable
[DeviceH-GigabitEthernet1/0/1] port link-type trunk
[DeviceH-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceH-GigabitEthernet1/0/1] quit
[DeviceH] interface gigabitethernet 1/0/2
[DeviceH-GigabitEthernet1/0/2] undo link-delay
[DeviceH-GigabitEthernet1/0/2] undo stp enable
[DeviceH-GigabitEthernet1/0/2] port link-type trunk
[DeviceH-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceH-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceH] rrpp domain 1
[DeviceH-rrpp-domain1] control-vlan 4092
[DeviceH-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device H as the master node of subring 5, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 5.
[DeviceH-rrpp-domain1] ring 5 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1
[DeviceH-rrpp-domain1] ring 5 enable
[DeviceH-rrpp-domain1] quit
# Enable RRPP.
[DeviceH] rrpp enable
83
Verifying the configuration
Use the display command to view RRPP configuration and operational information on each device.
Load balanced intersecting-ring configuration example
Networking requirements
As shown in
•
Device A, Device B, Device C, Device D, and Device F form RRPP domain 1, and VLAN 100 is the primary control VLAN of the RRPP domain.
{
Device A is the master node of the primary ring, Ring 1.
{
{
Device D is the transit node of Ring 1.
Device F is the master node of the subring Ring 3.
{
{
Device C is the edge node of the subring Ring 3.
Device B is the assistant-edge node of the subring Ring 3.
•
Device A, Device B, Device C, Device D, and Device E form RRPP domain 2, and VLAN 105 is the primary control VLAN of the RRPP domain.
{
{
{
{
Device A is the master node of the primary ring, Ring 1.
Device D is the transit node of Ring 1.
Device E is the master node of the subring Ring 2.
Device C is the edge node of the subring Ring 2.
{
Device B is the assistant-edge node of the subring Ring 2.
•
Specify VLAN 11 as the protected VLAN of domain 1, and VLAN 12 the protected VLAN of domain
2. You can implement VLAN-based load balancing on Ring 1.
• Ring 2 has the same edge node and assistant-edge node, and the two subrings have the same
SRPTs, so you can add Ring 2 and Ring 3 to the RRPP ring group to reduce Edge-Hello traffic.
Figure 21 Network diagram
Device A
Master node
Domain 2
GE1/0/1
Device B
Assistant edge node
GE1/0/1
GE1/0/1
GE1/0/3
GE1/0/4
Ring 2
GE1/0/2 GE1/0/2
Ring 1
GE1/0/2
Device E
Master node
Device D
Transit node
GE1/0/2 GE1/0/1
GE1/0/3
GE1/0/1
GE1/0/2
Device C
Edge node
GE1/0/4
Ring 3
GE1/0/1
GE1/0/2
Device F
Master node
Domain 1
84
Configuration procedure
1. Configure Device A:
# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.
<DeviceA> system-view
[DeviceA] vlan 11 to 12
[DeviceA] stp region-configuration
[DeviceA-mst-region] instance 1 vlan 11
[DeviceA-mst-region] instance 2 vlan 12
[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN
11 as their default VLAN.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] undo link-delay
[DeviceA-GigabitEthernet1/0/1] undo stp enable
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 11 12
[DeviceA-GigabitEthernet1/0/1] port trunk pvid vlan 11
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] undo link-delay
[DeviceA-GigabitEthernet1/0/2] undo stp enable
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 11 12
[DeviceA-GigabitEthernet1/0/2] port trunk pvid vlan 11
[DeviceA-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.
[DeviceA] rrpp domain 1
[DeviceA-rrpp-domain1] control-vlan 100
[DeviceA-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceA-rrpp-domain1] ring 1 enable
[DeviceA-rrpp-domain1] quit
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.
[DeviceA] rrpp domain 2
[DeviceA-rrpp-domain2] control-vlan 105
[DeviceA-rrpp-domain2] protected-vlan reference-instance 2
85
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/2 as the master port and GigabitEthernet 1/0/1 as the secondary port, and enable ring 1.
[DeviceA-rrpp-domain2] ring 1 node-mode master primary-port gigabitethernet 1/0/2 secondary-port gigabitethernet 1/0/1 level 0
[DeviceA-rrpp-domain2] ring 1 enable
[DeviceA-rrpp-domain2] quit
# Enable RRPP.
[DeviceA] rrpp enable
2. Configure Device B:
# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.
<DeviceB> system-view
[DeviceB] vlan 11 to 12
[DeviceB] stp region-configuration
[DeviceB-mst-region] instance 1 vlan 11
[DeviceB-mst-region] instance 2 vlan 12
[DeviceB-mst-region] active region-configuration
[DeviceB-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN
11 as their default VLAN.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] undo link-delay
[DeviceB-GigabitEthernet1/0/1] undo stp enable
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 11 12
[DeviceB-GigabitEthernet1/0/1] port trunk pvid vlan 11
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] undo link-delay
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 11 12
[DeviceB-GigabitEthernet1/0/2] port trunk pvid vlan 11
[DeviceB-GigabitEthernet1/0/2] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/3.
Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from
VLAN 1, assign it to VLAN 12, and configure VLAN 12 as its default VLAN.
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] undo link-delay
[DeviceB-GigabitEthernet1/0/3] undo stp enable
[DeviceB-GigabitEthernet1/0/3] port link-type trunk
[DeviceB-GigabitEthernet1/0/3] undo port trunk permit vlan 1
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 12
[DeviceB-GigabitEthernet1/0/3] port trunk pvid vlan 12
86
[DeviceB-GigabitEthernet1/0/3] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/4.
Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from
VLAN 1, assign it to VLAN 11, and configure VLAN 11 as its default VLAN.
[DeviceB] interface gigabitethernet 1/0/4
[DeviceB-GigabitEthernet1/0/4] undo link-delay
[DeviceB-GigabitEthernet1/0/4] undo stp enable
[DeviceB-GigabitEthernet1/0/4] port link-type trunk
[DeviceB-GigabitEthernet1/0/4] undo port trunk permit vlan 1
[DeviceB-GigabitEthernet1/0/4] port trunk permit vlan 11
[DeviceB-GigabitEthernet1/0/4] port trunk pvid vlan 11
[DeviceB-GigabitEthernet1/0/4] quit
# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.
[DeviceB] rrpp domain 1
[DeviceB-rrpp-domain1] control-vlan 100
[DeviceB-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device B as a transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceB-rrpp-domain1] ring 1 enable
# Configure Device B as the assistant-edge node of subring 3 in RRPP domain 1, with
GigabitEthernet 1/0/4 as the edge port, and enable subring 3.
[DeviceB-rrpp-domain1] ring 3 node-mode assistant-edge edge-port gigabitethernet
1/0/4
[DeviceB-rrpp-domain1] ring 3 enable
[DeviceB-rrpp-domain1] quit
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.
[DeviceB] rrpp domain 2
[DeviceB-rrpp-domain2] control-vlan 105
[DeviceB-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device B as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceB-rrpp-domain2] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceB-rrpp-domain2] ring 1 enable
# Configure Device B as the assistant-edge node of subring 2 in RRPP domain 2, with
GigabitEthernet 1/0/3 as the edge port, and enable subring 2.
[DeviceB-rrpp-domain2] ring 2 node-mode assistant-edge edge-port gigabitethernet
1/0/3
[DeviceB-rrpp-domain2] ring 2 enable
[DeviceC-rrpp-domain2] quit
# Enable RRPP.
[DeviceB] rrpp enable
3. Configure Device C:
87
# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 11 to 12
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 11
[DeviceC-mst-region] instance 2 vlan 12
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN
11 as their default VLAN.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo link-delay
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 11 12
[DeviceC-GigabitEthernet1/0/1] port trunk pvid vlan 11
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo link-delay
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 11 12
[DeviceC-GigabitEthernet1/0/2] port trunk pvid vlan 11
[DeviceC-GigabitEthernet1/0/2] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/3.
Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from
VLAN 1, assign it to VLAN 12, and configure VLAN 12 as its default VLAN.
[DeviceC] interface gigabitethernet 1/0/3
[DeviceC-GigabitEthernet1/0/3] undo link-delay
[DeviceC-GigabitEthernet1/0/3] undo stp enable
[DeviceC-GigabitEthernet1/0/3] port link-type trunk
[DeviceC-GigabitEthernet1/0/3] undo port trunk permit vlan 1
[DeviceC-GigabitEthernet1/0/3] port trunk permit vlan 12
[DeviceC-GigabitEthernet1/0/3] port trunk pvid vlan 12
[DeviceC-GigabitEthernet1/0/3] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/4.
Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from
VLAN 1, assign it to VLAN 11, and configure VLAN 11 as its default VLAN.
[DeviceC] interface gigabitethernet 1/0/4
[DeviceC-GigabitEthernet1/0/4] undo link-delay
[DeviceC-GigabitEthernet1/0/4] undo stp enable
[DeviceC-GigabitEthernet1/0/4] port link-type trunk
[DeviceC-GigabitEthernet1/0/4] undo port trunk permit vlan 1
88
[DeviceC-GigabitEthernet1/0/4] port trunk permit vlan 11
[DeviceC-GigabitEthernet1/0/4] port trunk pvid vlan 11
[DeviceC-GigabitEthernet1/0/4] quit
# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.
[DeviceC] rrpp domain 1
[DeviceC-rrpp-domain1] control-vlan 100
[DeviceC-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device C as the transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceC-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceC-rrpp-domain1] ring 1 enable
# Configure Device C as the edge node of subring 3 in RRPP domain 1, with GigabitEthernet
1/0/4 as the edge port, and enable subring 3.
[DeviceC-rrpp-domain1] ring 3 node-mode edge edge-port gigabitethernet 1/0/4
[DeviceC-rrpp-domain1] ring 3 enable
[DeviceC-rrpp-domain1] quit
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.
[DeviceC] rrpp domain 2
[DeviceC-rrpp-domain2] control-vlan 105
[DeviceC-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device C as the transit node of primary ring 1 in RRPP domain 2, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceC-rrpp-domain2] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceC-rrpp-domain2] ring 1 enable
# Configure Device C as the edge node of subring 2 in RRPP domain 2, with GigabitEthernet
1/0/3 as the edge port, and enable subring 2.
[DeviceC-rrpp-domain2] ring 2 node-mode edge edge-port gigabitethernet 1/0/3
[DeviceC-rrpp-domain2] ring 2 enable
[DeviceC-rrpp-domain2] quit
# Enable RRPP.
[DeviceC] rrpp enable
4. Configure Device D:
# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.
<DeviceD> system-view
[DeviceD] vlan 11 to 12
[DeviceD] stp region-configuration
[DeviceD-mst-region] instance 1 vlan 11
[DeviceD-mst-region] instance 2 vlan 12
[DeviceD-mst-region] active region-configuration
[DeviceD-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk
89
ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN
11 as their default VLAN.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] undo link-delay
[DeviceD-GigabitEthernet1/0/1] undo stp enable
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 11 12
[DeviceD-GigabitEthernet1/0/1] port trunk pvid vlan 11
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] undo link-delay
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 11 12
[DeviceD-GigabitEthernet1/0/2] port trunk pvid vlan 11
[DeviceD-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.
[DeviceD] rrpp domain 1
[DeviceD-rrpp-domain1] control-vlan 100
[DeviceD-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device D as the transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceD-rrpp-domain1] ring 1 enable
[DeviceD-rrpp-domain1] quit
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.
[DeviceD] rrpp domain 2
[DeviceD-rrpp-domain2] control-vlan 105
[DeviceD-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device D as the transit node of primary ring 1 in RRPP domain 2, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceD-rrpp-domain2] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceD-rrpp-domain2] ring 1 enable
[DeviceD-rrpp-domain2] quit
# Enable RRPP.
[DeviceD] rrpp enable
5. Configure Device E:
# Create VLAN 12, map VLAN 12 to MSTI 2, and activate MST region configuration.
<DeviceE> system-view
[DeviceE] vlan 12
[DeviceE-vlan12] quit
90
[DeviceE] stp region-configuration
[DeviceE-mst-region] instance 2 vlan 12
[DeviceE-mst-region] active region-configuration
[DeviceE-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLAN 12, and configure VLAN 12 as their default VLAN.
[DeviceE] interface gigabitethernet 1/0/1
[DeviceE-GigabitEthernet1/0/1] undo link-delay
[DeviceE-GigabitEthernet1/0/1] undo stp enable
[DeviceE-GigabitEthernet1/0/1] port link-type trunk
[DeviceE-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan 12
[DeviceE-GigabitEthernet1/0/1] port trunk pvid vlan 12
[DeviceE-GigabitEthernet1/0/1] quit
[DeviceE] interface gigabitethernet 1/0/2
[DeviceE-GigabitEthernet1/0/2] undo link-delay
[DeviceE-GigabitEthernet1/0/2] undo stp enable
[DeviceE-GigabitEthernet1/0/2] port link-type trunk
[DeviceE-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceE-GigabitEthernet1/0/2] port trunk permit vlan 12
[DeviceE-GigabitEthernet1/0/2] port trunk pvid vlan 12
[DeviceE-GigabitEthernet1/0/2] quit
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN, and configure the
VLAN mapped to MSTI 2 as the protected VLAN.
[DeviceE] rrpp domain 2
[DeviceE-rrpp-domain2] control-vlan 105
[DeviceE-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device E as the master mode of subring 2 in RRPP domain 2, with GigabitEthernet
1/0/2 as the primary port and GigabitEthernet 1/0/1 as the secondary port, and enable ring 2.
[DeviceE-rrpp-domain2] ring 2 node-mode master primary-port gigabitethernet 1/0/2 secondary-port gigabitethernet 1/0/1 level 1
[DeviceE-rrpp-domain2] ring 2 enable
[DeviceE-rrpp-domain2] quit
# Enable RRPP.
[DeviceE] rrpp enable
6. Configure Device F:
# Create VLAN 11, map VLAN 11 to MSTI 1, and activate MST region configuration.
<DeviceF> system-view
[DeviceF] vlan 11
[DeviceF-vlan11] quit
[DeviceF] stp region-configuration
[DeviceF-mst-region] instance 1 vlan 11
[DeviceF-mst-region] active region-configuration
[DeviceF-mst-region] quit
91
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLAN 11, and configure VLAN 11 as their default VLAN.
[DeviceF] interface gigabitethernet 1/0/1
[DeviceF-GigabitEthernet1/0/1] undo link-delay
[DeviceF-GigabitEthernet1/0/1] undo stp enable
[DeviceF-GigabitEthernet1/0/1] port link-type trunk
[DeviceF-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceF-GigabitEthernet1/0/1] port trunk permit vlan 11
[DeviceF-GigabitEthernet1/0/1] port trunk pvid vlan 11
[DeviceF-GigabitEthernet1/0/1] quit
[DeviceF] interface gigabitethernet 1/0/2
[DeviceF-GigabitEthernet1/0/2] undo link-delay
[DeviceF-GigabitEthernet1/0/2] undo stp enable
[DeviceF-GigabitEthernet1/0/2] port link-type trunk
[DeviceF-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceF-GigabitEthernet1/0/2] port trunk permit vlan 11
[DeviceF-GigabitEthernet1/0/2] port trunk pvid vlan 11
[DeviceF-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN, and configure the
VLAN mapped to MSTI 1 as the protected VLAN.
[DeviceF] rrpp domain 1
[DeviceF-rrpp-domain1] control-vlan 100
[DeviceF-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device F as the master node of subring 3 in RRPP domain 1, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring
3.
[DeviceF-rrpp-domain1] ring 3 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1
[DeviceF-rrpp-domain1] ring 3 enable
[DeviceF-rrpp-domain1] quit
# Enable RRPP.
[DeviceF] rrpp enable
7. Configure RRPP ring group settings on Device B and Device C:
# Create RRPP ring group 1 on Device B, and add subrings 2 and 3 to the RRPP ring group.
[DeviceB] rrpp ring-group 1
[DeviceB-rrpp-ring-group1] domain 2 ring 2
[DeviceB-rrpp-ring-group1] domain 1 ring 3
# Create RRPP ring group 1 on Device C, and add subrings 2 and 3 to the RRPP ring group.
[DeviceC] rrpp ring-group 1
[DeviceC-rrpp-ring-group1] domain 2 ring 2
[DeviceC-rrpp-ring-group1] domain 1 ring 3
Verifying the configuration
Use the display command to view RRPP configuration and operational information on each device.
92
Fast detection configuration example
Network requirements
As shown in
• Device A, Device B, Device C, and Device D form RRPP domain 1. VLAN 4092 is the primary control VLAN of RRPP domain 1, and RRPP domain 1 protects VLANs 1 through 30.
•
Device A is the master node and supports RRPP fast detection. Device D is a transit node. Device B and Device C do not support RRPP.
When the link between Device B and Device C fails, the link failure cannot be detected by the master node in a timely manner, because neither Device B nor Device C supports RRPP. Configure RRPP fast detection to implement fast link switchover even when the link between Device B and Device C fails.
Figure 22 Network diagram
Configuration procedure
1. Configure Device A:
# Create VLANs 1 through 30, map the VLANs to MSTI 1, and activate MST region configuration.
<DeviceA> system-view
[DeviceA] vlan 1 to 30
[DeviceA] stp region-configuration
[DeviceA-mst-region] instance 1 vlan 1 to 30
[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] undo link-delay
[DeviceA-GigabitEthernet1/0/1] undo stp enable
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] undo link-delay
93
[DeviceA-GigabitEthernet1/0/2] undo stp enable
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceA] rrpp domain 1
[DeviceA-rrpp-domain1] control-vlan 4092
[DeviceA-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device A as the master node of the primary ring Ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable Ring 1.
[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceA-rrpp-domain1] ring 1 enable
# Enable fast detection, and set the Fast-Hello timer and Fast-Fail timer to 100 milliseconds and
300 milliseconds respectively. Set the Fast-Fail timer equal to or greater than three times the
Fast-Hello timer value. Otherwise, the configuration fails.
[DeviceA-rrpp-domain1] fast-detection enable
[DeviceA-rrpp-domain1] timer fast-hello-timer 100
[DeviceA-rrpp-domain1] timer fast-fail-timer 300
[DeviceA-rrpp-domain1] quit
# Enable the RRPP protocol.
[DeviceA] rrpp enable
2. Configure Device B:
# Create VLANs 4092 and 4093.
<DeviceB> system-view
[DeviceB] vlan 4092 to 4093
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30, 4092, and 4093.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] undo link-delay
[DeviceB-GigabitEthernet1/0/1] undo stp enable
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30 4092 4093
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] undo link-delay
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30 4092 4093
3. Configure Device C:
# Create VLANs 4092 and 4093.
<DeviceC> system-view
[DeviceC] vlan 4092 to 4093
94
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30, 4092, and 4093.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo link-delay
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30 4092 4093
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo link-delay
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30 4092 4093
4. Configure Device D:
# Create VLANs 1 through 30, map the VLANs to MSTI 1, and activate MST region configuration.
<DeviceD> system-view
[DeviceD] vlan 1 to 30
[DeviceD] stp region-configuration
[DeviceD-mst-region] instance 1 vlan 1 to 30
[DeviceD-mst-region] active region-configuration
[DeviceD-mst-region] quit
# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] undo link-delay
[DeviceD-GigabitEthernet1/0/1] undo stp enable
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] undo link-delay
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 4092 as the primary VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.
[DeviceD] rrpp domain 1
[DeviceD-rrpp-domain1] control-vlan 4092
[DeviceD-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device D as a transit node of the primary ring Ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable Ring 1.
[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 0
[DeviceD-rrpp-domain1] ring 1 enable
[DeviceD-rrpp-domain1] quit
95
# Enable the RRPP protocol.
[DeviceD] rrpp enable
Verifying the configuration
Use the display command to view RRPP configuration and operational information on Device A and
Device D.
Troubleshooting
This section provides troubleshooting advice.
Symptom
When the link state is normal, the master node cannot receive Hello packets, and the master node unblocks the secondary port.
Analysis
The following reasons may apply:
•
RRPP is not enabled on some nodes in the RRPP ring.
•
The domain ID or primary control VLAN ID is not the same for the nodes in the RRPP ring.
• Some ports are abnormal.
Solution
•
Use the display rrpp brief command to examine whether RRPP is enabled for all nodes. If not, use the rrpp enable command and the ring enable command to enable RRPP and RRPP rings for all nodes.
•
Use the display rrpp brief command to examine whether the domain ID and primary control VLAN
ID are the same for all nodes. If not, set the same domain ID and primary control VLAN ID for the nodes.
• Use the display rrpp verbose command to examine the link state of each port in each ring.
•
Use the debugging rrpp command on each node to examine whether a port receives or transmits
Hello packets. If not, Hello packets are lost.
96
Configuring Smart Link
This chapter describes how to configure Smart Link.
Overview
To avoid single-point failures and guarantee network reliability, downstream devices are usually dual-homed to upstream devices, as shown in
.
Figure 23 Dual-uplink network diagram
Core network
Device B
Port3
Po rt1
Por t2
Port3
Po rt1
Device A
Por t2
Por t1
Po rt2
Port3
Device E
Master link
Slave link
Smart link group
Device C
Port1
Port3
Port2 Port2
Port3
Port1
Device D
User network User network
To remove network loops on a dual-homed network, you can use a spanning tree protocol or RRPP.
However, convergence time is long with STP, which makes it unsuitable for users who have high demand on convergence speed. RRPP can meet demand on convergence speed, but it involves complicated networking and configurations, and is mainly used in ring-shaped networks.
For more information about STP, see Layer 2—LAN Switching Configuration Guide.
For more information about RRPP, see " Configuring RRPP ."
Smart Link addresses the slow convergence issue with STP. It provides link redundancy as well as fast convergence in a dual uplink network, allowing the backup link to take over quickly when the primary link fails. Smart Link has the following features:
•
Dedicated to dual-uplink networks
97
• Subsecond convergence
•
Easy to configure
Terminology
The following terms are used in Smart Link configuration.
Smart link group
A smart link group consists of only two member ports: the primary port and the secondary port. Only one port is active for forwarding at a time, and the other port is blocked and in standby state. When link failure occurs on the active port due to port shutdown, or the presence of a unidirectional link, for example, the standby port becomes active and takes over, and the original active port transits to blocked state.
, Port1 and Port2 of Device C and Port1 and Port2 of Device D each form a smart link group, with Port1 active and Port2 standby.
Primary/secondary port
Primary port and secondary port are two port roles in a smart link group. When both ports in a smart link group are up, the primary port preferentially transits to the forwarding state, and the secondary port stays in standby state. When the primary port fails, the secondary port takes over to forward traffic. As shown in
, you can configure Port1 of Device C and Device D as primary ports, and Port2 of
Device C and Device D secondary ports.
Primary/secondary link
The link that connects the primary port in a smart link group is the primary link; the link that connects the secondary port is the secondary link.
Flush message
Flush messages are used by a smart link group to notify other devices to refresh their MAC address forwarding entries and ARP/ND entries when link switchover occurs in the smart link group. Flush messages are common multicast data packets, and are dropped by a blocked receiving port.
Protected VLAN
A smart link group controls the forwarding state of some data VLANs (protected VLANs). Different smart link groups on a port control different protected VLANs. The state of the port in a protected VLAN is determined by the state of the port in the smart link group.
Transmit control VLAN
The transmit control VLAN is used for transmitting flush messages. When link switchover occurs, the devices (such as Device C and Device D in
) broadcast flush messages within the transmit control VLAN.
Receive control VLAN
The receive control VLAN is used for receiving and processing flush messages. When link switchover
occurs, the devices (such as Device A, Device B, and Device E in Figure 23
) receive and process flush messages in the receive control VLAN and refresh their MAC address forwarding entries and ARP/ND entries.
98
How Smart Link works
This section explains how Smart Link works in further detail.
Link backup mechanism
As shown in
, the link on Port1 of Device C is the primary link, and the link on Port2 of Device
C is the secondary link. Typically, Port1 is in forwarding state, and Port2 is in standby state. When the primary link fails, Port2 takes over to forward traffic and Port1 is blocked and placed in standby state.
When a port switches to the forwarding state, the system outputs log information to notify the user of the port state change.
Topology change mechanism
Link switchover can outdate the MAC address forwarding entries and ARP/ND entries on all devices, so a forwarding entry update mechanism is needed to ensure proper transmission. The following update mechanisms are provided:
•
Uplink traffic-triggered MAC address learning—Update is triggered by uplink traffic. This mechanism applies to environments with network devices that do not support Smart Link, including devices of other vendors.
•
Flush update—A Smart Link-enabled device updates its information by transmitting flush messages over the backup link to its upstream devices. This mechanism requires the upstream devices to be capable of recognizing Smart Link flush messages to update their MAC address forwarding entries and ARP/ND entries.
Role preemption mechanism
, the link on Port1 of Device C is the primary link and the link on Port2 of Device
C is the secondary link. Once the primary link fails, Port1 is automatically blocked and placed in standby state, and Port2 takes over to forward traffic.
When the primary link recovers:
• If the smart link group is not configured with role preemption, Port1 stays blocked, and no link switchover occurs, ensuring traffic stability. Port1 does not transition to forwarding state until the next link switchover occurs.
•
If the smart link group is configured with role preemption, Port1 takes over to forward traffic as soon as its link recovers, and Port2 is automatically blocked and placed in standby state.
Load sharing mechanism
A ring network can carry traffic of multiple VLANs. Smart Link can forward traffic from different VLANs in different smart link groups for load sharing.
To implement load sharing, assign a port to multiple smart link groups (each configured with different protected VLANs). Make sure that the state of the port is different in these smart link groups. In this way, traffic of different VLANs can be forwarded along different paths.
You can configure protected VLANs for a smart link group by referencing MSTIs.
Smart Link collaboration mechanisms
Configure a monitoring function to monitor the uplink ports of upstream devices and trigger Smart Link to perform the switchover when faults occur.
99
Collaboration between Smart Link and Monitor Link
Smart Link cannot sense when faults occur on the uplink of the upstream devices or when faults are cleared. To monitor the uplink status of the upstream devices, configure the Monitor Link function to monitor the uplink ports of the upstream devices. Monitor Link adapts the up/down state of downlink ports to the up/down state of uplink ports, triggering Smart Link to perform link switchover on the downstream device.
For more information about Monitor Link, see " Configuring Monitor Link ."
Collaboration between Smart Link and CC of CFD
When faults such as unidirectional link, misconnected fibers, or packet loss occur on the intermediate devices or network paths, or when faults are cleared, Smart Link cannot sense this on its own. To examine the link status, Smart Link ports must use link detection protocols. When a fault is detected or cleared, the link detection protocols inform Smart Link to switch over the links.
With the collaboration between Smart Link and the Continuity Check function of CFD configured, CFD notifies the ports of fault detection events on the basis of detection VLANs and detection ports. A port responds to a continuity check event only when the control VLAN of the smart link group to which it belongs matches the detection VLAN.
For more information about the CC function of CFD, see "
."
Smart Link configuration task list
Task
Configuring a Smart Link device
Configuring protected VLANs for a smart link group
Configuring member ports for a smart link group
Configuring role preemption for a smart link group
Enabling the sending of flush messages
Remarks
Required.
Required.
Optional.
Optional.
Configuring the collaboration between Smart Link and CC of CFD
Optional.
Configuring an associated device
Enabling the receiving of flush messages
Required.
Configuring a Smart Link device
A Smart Link device is a device that supports Smart Link and is configured with a smart link group and a transmit control VLAN to transmit flush messages. Device C and Device D in
are two examples of Smart Link devices.
Configuration prerequisites
Before you configure a Smart Link device, complete the following tasks:
• Shut down a port to prevent loops before configuring a port as a smart link group member. You can bring up the port only after completing the smart link group configuration.
•
Disable STP and RRPP on the ports you want to add to the smart link group, making sure the ports are not member ports of any aggregation group or service loopback group.
100
NOTE:
A loop may occur on the network during the time when STP is disabled but Smart Link has not yet taken effect on a port.
Configuring protected VLANs for a smart link group
Configure protected VLANs for a smart link group by referencing MSTIs. Before configuring the protected
VLANs, configure the mappings between MSTIs and the VLANs to be protected. (A device operating in
PVST mode automatically maps VLANs to MSTIs.) For more information about MSTIs and PVST, see Layer
2—LAN Switching Configuration Guide.
For more information about the stp region-configuration, instance, vlan-mapping modulo, active region-configuration, and display stp region-configuration commands, see Layer 2—LAN Switching
Command Reference.
To configure the protected VLANs for a smart link group:
Step Command
1. Enter system view. system-view
2. Enter MST region view.
3. Configure the
VLAN-to-instance mapping table.
•
Approach 1:
• instance instance-id vlan
vlan-list
Approach 2: vlan-mapping modulo
modulo
4. Activate MST region configuration manually. active region-configuration
5. Display the currently activated configuration information of the MST region. display stp region-configuration
[ | { begin | exclude | include }
regular-expression ]
6. Return to system view. stp region-configuration quit
Remarks
N/A
Not required if the device operates in PVST mode.
Optional.
Use either approach.
All VLANs in an MST region are mapped to CIST (MSTI 0) by default.
Not required if the device operates in PVST mode.
Not required if the device operates in PVST mode.
Optional.
Available in any view.
The output from the command includes VLAN-to-instance mappings.
Not required if the device operates in PVST mode.
7. Create a smart link group and enter smart link group view.
8. Configure protected VLANs for the smart link group. smart-link group group-id protected-vlan reference-instance
instance-id-list
N/A
By default, no protected VLAN is configured for a smart link group.
Configuring member ports for a smart link group
You can configure member ports for a smart link group either in smart link group view or in interface view.
The configurations made in these two views have the same effect.
101
In smart link group view
To configure member ports for a smart link group in smart link group view:
Step Command
1. Enter system view. system-view
2. Create a smart link group and enter smart link group view. smart-link group group-id
3. Configure member ports for a smart link group. port interface-type interface-number { master | slave }
In interface view
To configure member ports for a smart link group in interface view:
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view. interface interface-type interface-number
3. Configure member ports for a smart link group. port smart-link group group-id { master | slave }
Configuring role preemption for a smart link group
Step Command
1. Enter system view. system-view
2. Create a smart link group and enter smart link group view. smart-link group group-id
Remarks
N/A
N/A
3. Enable role preemption. preemption mode role
4. Configure the preemption delay. preemption delay delay-time
By default, role preemption is disabled.
Optional.
The default is 1 second.
The preemption delay configuration takes effect only after role preemption is enabled.
Enabling the sending of flush messages
Follow these guidelines when you enable the sending of flush messages:
• The control VLAN configured for a smart link group must be different than that configured for any other smart link group.
•
Make sure the configured control VLAN already exists, and assign the smart link group member ports to the control VLAN.
• The control VLAN of a smart link group should also be one of its protected VLANs. Do not remove the control VLAN. Otherwise, flush messages cannot be sent properly.
To enable the sending of flush messages:
102
Step Command
1. Enter system view. system-view
2. Create a smart link group and enter smart link group view. smart-link group group-id
Remarks
N/A
N/A
3. Enable flush update in the specified control VLAN. flush enable [ control-vlan
vlan-id ]
Optional.
By default, flush update is enabled, and
VLAN 1 is the control VLAN.
Configuring the collaboration between Smart Link and CC of
CFD
When you configure the collaboration between Smart Link and the CC function of CFD on a smart link member port, make sure the control VLAN of the smart link group to which the port belongs matches the detection VLAN of the CC function of CFD.
To configure the collaboration between smart link and the CC function of CFD on a smart link member port:
Remarks
N/A
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view. interface interface-type
interface-number
3.
Configure the collaboration between Smart Link and the
CC function of CFD on the port. port smart-link group group-id track cfd cc
N/A
Optional.
By default, the collaboration between Smart Link and the CC function of CFD is not configured.
Configuring an associated device
An associated device is a device that supports Smart Link, and receives flush messages sent from the
specified control VLAN. Device A, Device B, and Device E in Figure 23
are examples of associated devices.
Configuration prerequisites
Disable the spanning tree feature on the associated device's ports that connect to the member ports of the smart link group. Otherwise, the ports will discard flush messages when they are not in forwarding state in case of a topology change.
Enabling the receiving of flush messages
Follow these guidelines when you enable the receiving of flush messages:
•
You do not need to enable all ports on the associated devices to receive flush messages sent from the transmit control VLAN, only those on the primary and secondary links between the Smart Link device and the destination device.
103
• Configure all the control VLANs to receive flush messages.
•
If no control VLAN is specified for processing flush messages, the device forwards the received flush messages without processing them.
• Make sure the receive control VLAN is the same as the transmit control VLAN configured on the
Smart Link device. If they are not the same, the associated device will forward the received flush messages directly without any processing.
•
Do not remove the control VLANs. Otherwise, flush messages cannot be sent properly.
• Make sure the control VLANs are existing VLANs, and assign the ports capable of receiving flush messages to the control VLANs.
To enable the receiving of flush messages:
Remarks
N/A
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view. interface interface-type
interface-number
3. Configure the control VLANs for receiving flush messages. smart-link flush enable
[ control-vlan vlan-id-list ]
N/A
By default, no control VLAN exists for receiving flush messages.
Displaying and maintaining Smart Link
Task Command
Display smart link group information. display smart-link group { group-id
| all } [ | { begin | exclude | include } regular-expression ]
Display information about the received flush messages. display smart-link flush [ | { begin
| exclude | include }
regular-expression ]
Clear the statistics about flush messages. reset smart-link statistics
Remarks
Available in any view.
Available in any view.
Available in user view.
Smart Link configuration examples
This section provides examples for various Smart Link configurations.
Single smart link group configuration example
Network requirements
As shown in
:
•
Device C and Device D are Smart Link devices. Device A, Device B, and Device E are associated devices. Traffic of VLANs 1 through 30 on Device C and Device D are dually uplinked to Device A.
• Configure Smart Link on Device C and Device D for dual uplink backup.
104
Figure 24 Network diagram
Configuration procedure
1. Configure Device C:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 1 to 30
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 1 to 30
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on them, configure them as trunk ports, and assign them to VLANs 1 through 30.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] shutdown
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] shutdown
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/2] quit
# Create smart link group 1, and configure all VLANs mapped to MSTI 1 as the protected VLANs.
[DeviceC] smart-link group 1
[DeviceC-smlk-group1] protected-vlan reference-instance 1
# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.
[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave
105
# Enable flush message sending in smart link group 1, and configure VLAN 10 as the transmit control VLAN.
[DeviceC-smlk-group1] flush enable control-vlan 10
[DeviceC-smlk-group1] quit
# Bring up GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 again.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo shutdown
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo shutdown
[DeviceC-GigabitEthernet1/0/2] quit
2. Configure Device D:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.
<DeviceD> system-view
[DeviceD] vlan 1 to 30
[DeviceD] stp region-configuration
[DeviceD-mst-region] instance 1 vlan 1 to 30
[DeviceD-mst-region] active region-configuration
[DeviceD-mst-region] quit
# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure them as trunk ports, and assign them to VLANs 1 through 30.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] shutdown
[DeviceD-GigabitEthernet1/0/1] undo stp enable
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] shutdown
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/2] quit
# Create smart link group 1, and configure all VLANs mapped to MSTI 1 as the protected VLANs.
[DeviceD] smart-link group 1
[DeviceD-smlk-group1] protected-vlan reference-instance 1
# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.
[DeviceD-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceD-smlk-group1] port gigabitethernet 1/0/2 slave
# Enable flush message sending in smart link group 1, and configure VLAN 20 as the transmit control VLAN.
[DeviceD-smlk-group1] flush enable control-vlan 20
[DeviceD-smlk-group1] quit
# Bring up GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 again.
106
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] undo shutdown
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] undo shutdown
[DeviceD-GigabitEthernet1/0/2] quit
3. Configure Device B:
# Create VLANs 1 through 30.
<DeviceB> system-view
[DeviceB] vlan 1 to 30
# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 30. Enable flush message receiving on it, and configure VLAN 10 and VLAN 20 as the receive control VLANs.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 20
[DeviceB-GigabitEthernet1/0/1] quit
# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 20 as the receive control VLAN.
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] smart-link flush enable control-vlan 20
[DeviceB-GigabitEthernet1/0/2] quit
# Configure GigabitEthernet 1/0/3 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 as the receive control VLAN.
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] port link-type trunk
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/3] undo stp enable
[DeviceB-GigabitEthernet1/0/3] smart-link flush enable control-vlan 10
[DeviceB-GigabitEthernet1/0/3] quit
4. Configure Device E:
# Create VLANs 1 through 30.
<DeviceE> system-view
[DeviceE] vlan 1 to 30
# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 30. Enable flush message receiving on it, and configure VLAN 10 and VLAN 20 as the receive control VLANs.
[DeviceE] interface gigabitethernet 1/0/1
[DeviceE-GigabitEthernet1/0/1] port link-type trunk
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 20
[DeviceE-GigabitEthernet1/0/1] quit
107
# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 as the receive control VLAN.
[DeviceE] interface gigabitethernet 1/0/2
[DeviceE-GigabitEthernet1/0/2] port link-type trunk
[DeviceE-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/2] undo stp enable
[DeviceE-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10
[DeviceE-GigabitEthernet1/0/2] quit
# Configure GigabitEthernet 1/0/3 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 20 as the receive control VLAN.
[DeviceE] interface gigabitethernet 1/0/3
[DeviceE-GigabitEthernet1/0/3] port link-type trunk
[DeviceE-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/3] undo stp enable
[DeviceE-GigabitEthernet1/0/3] smart-link flush enable control-vlan 20
[DeviceE-GigabitEthernet1/0/3] quit
5. Configure Device A:
# Create VLANs 1 through 30.
<DeviceA> system-view
[DeviceA] vlan 1 to 30
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, assign them to
VLANs 1 through 30, enable flush message receiving on them, and configure VLAN 10 and VLAN
20 as the receive control VLANs.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 20
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 20
[DeviceA-GigabitEthernet1/0/2] quit
Verifying the configuration
Use the display smart-link group command to display the smart link group configuration on a device.
# Display the smart link group configuration on Device C.
[DeviceC] display smart-link group 1
Smart link group 1 information:
Device ID: 000f-e23d-5af0
Preemption mode: NONE
Preemption delay: 1(s)
Control VLAN: 10
Protected VLAN: Reference Instance 1
Member Role State Flush-count Last-flush-time
-----------------------------------------------------------------------------
108
GigabitEthernet1/0/1 MASTER ACTVIE 5 16:37:20 2010/02/21
GigabitEthernet1/0/2 SLAVE STANDBY 1 17:45:20 2010/02/21
You can use the display smart-link flush command to display the flush messages received on a device.
# Display the flush messages received on Device B.
[DeviceB] display smart-link flush
Received flush packets : 5
Receiving interface of the last flush packet : GigabitEthernet1/0/3
Receiving time of the last flush packet : 16:25:21 2009/02/21
Device ID of the last flush packet : 000f-e23d-5af0
Control VLAN of the last flush packet : 10
Multiple smart link groups load sharing configuration example
Network requirements
As shown in
:
•
Device C is a Smart Link device. Device A, Device B, and Device D are associated devices. Traffic of VLANs 1 through 200 on Device C is dually uplinked to Device A by Device B and Device D.
•
Implement dual uplink backup and load sharing on Device C: traffic of VLANs 1 through 100 is uplinked to Device A by Device B and traffic of VLANs 101 through 200 is uplinked to Device A by
Device D.
Figure 25 Network diagram
Configuration procedure
1. Configure Device C:
# Create VLAN 1 through VLAN 200, map VLANs 1 through 100 to MSTI 1, and VLANs 101 through 200 to MSTI 2, and activate MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 1 to 200
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 1 to 100
[DeviceC-mst-region] instance 2 vlan 101 to 200
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
109
# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on them, configure them as trunk ports, and assign them to VLAN 1 through VLAN 200.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] shutdown
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] shutdown
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceC-GigabitEthernet1/0/2] quit
# Create smart link group 1 and configure all VLANs mapped to MSTI 1 as the protected VLANs for smart link group 1.
[DeviceC] smart-link group 1
[DeviceC-smlk-group1] protected-vlan reference-instance 1
# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.
[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave
# Enable role preemption in smart link group 1, enable flush message sending, and configure
VLAN 10 as the transmit control VLAN.
[DeviceC-smlk-group1] preemption mode role
[DeviceC-smlk-group-1] flush enable control-vlan 10
[DeviceC-smlk-group-1] quit
# Create smart link group 2 and configure all VLANs mapped to MSTI 2 as the protected VLANs for smart link group 2.
[DeviceC] smart-link group 2
[DeviceC-smlk-group2] protected-vlan reference-instance 2
# Configure GigabitEthernet 1/0/1 as the secondary port and GigabitEthernet 1/0/2 as the primary port for smart link group 2.
[DeviceC-smlk-group2] port gigabitethernet 1/0/2 master
[DeviceC-smlk-group2] port gigabitethernet 1/0/1 slave
# Enable role preemption in smart link group 2, enable flush message sending, and configure
VLAN 110 as the transmit control VLAN.
[DeviceC-smlk-group2] preemption mode role
[DeviceC-smlk-group2] flush enable control-vlan 110
[DeviceC-smlk-group2] quit
# Bring up GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo shutdown
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo shutdown
[DeviceC-GigabitEthernet1/0/2] quit
110
2. Configure Device B:
# Create VLAN 1 through VLAN 200.
<DeviceB> system-view
[DeviceB] vlan 1 to 200
# Configure GigabitEthernet 1/0/1 as a trunk port, assign it to VLANs 1 through 200, enable flush message receiving, and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceB-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110
[DeviceB-GigabitEthernet1/0/1] quit
# Configure GigabitEthernet 1/0/2 as a trunk port, assign it to VLANs 1 through 200, disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 and
VLAN 110 as the receive control VLANs.
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110
[DeviceB-GigabitEthernet1/0/2] quit
3. Configure Device D:
# Create VLAN 1 through VLAN 200.
<DeviceD> system-view
[DeviceD] vlan 1 to 200
# Configure GigabitEthernet 1/0/1 as a trunk port, assign it to VLANs 1 through 200, enable flush message receiving, and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceD-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110
[DeviceD-GigabitEthernet1/0/1] quit
# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 200, disable the spanning tree feature and enable flush message receiving, and configure VLAN 10 and VLAN
110 as the receive control VLANs on the port.
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110
[DeviceD-GigabitEthernet1/0/2] quit
4. Configure Device A:
# Create VLAN 1 through VLAN 200.
<DeviceA> system-view
[DeviceA] vlan 1 to 200
111
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, assign them to
VLANs 1 through 200, enable flush message receiving, and configure VLAN 10 and VLAN 110 as the receive control VLANs on the ports.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110
[DeviceA-GigabitEthernet1/0/2] quit
Verifying the configuration
Use the display smart-link group command to display the smart link group configuration on a device.
# Display the smart link group configuration on Device C.
[DeviceC] display smart-link group all
Smart link group 1 information:
Device ID: 000f-e23d-5af0
Preemption delay: 1(s)
Preemption mode: ROLE
Control VLAN: 10
Protected VLAN: Reference Instance 1
Member Role State Flush-count Last-flush-time
-----------------------------------------------------------------------------
GigabitEthernet1/0/1 MASTER ACTVIE 5 16:37:20 2010/02/21
GigabitEthernet1/0/2 SLAVE STANDBY 1 17:45:20 2010/02/21
Smart link group 2 information:
Device ID: 000f-e23d-5af0
Preemption mode: ROLE
Preemption delay: 1(s)
Control VLAN: 110
Protected VLAN: Reference Instance 2
Member Role State Flush-count Last-flush-time
-----------------------------------------------------------------------------
GigabitEthernet1/0/2 MASTER ACTVIE 5 16:37:20 2010/02/21
GigabitEthernet1/0/1 SLAVE STANDBY 1 17:45:20 2010/02/21
Use the display smart-link flush command to display the flush messages received on a device.
# Display the flush messages received on Device B.
[DeviceB] display smart-link flush
Received flush packets : 5
Receiving interface of the last flush packet : GigabitEthernet1/0/2
Receiving time of the last flush packet : 16:25:21 2010/02/21
112
Device ID of the last flush packet : 000f-e23d-5af0
Control VLAN of the last flush packet : 10
Smart Link and CFD collaboration configuration example
Network requirements
As shown in
:
• Device A, Device B, Device C, and Device D form a MD of level 5. Device C is a Smart Link device, and Device A, Device B, and Device D are associated devices. Traffic of VLANs 1 through 200 on
Device C is dually uplinked to Device A by Device B and Device D.
• Configure the CFD CC function for Smart Link so that traffic of VLANs 1 through 100 is uplinked to
Device A by Device C through GigabitEthernet 1/0/1 (primary port of smart link group 1). Traffic of VLANs 101 through 200 is uplinked to Device A by Device C through GigabitEthernet 1/0/2
(primary port of smart link group 2). When the link between Device C and Device A fails, traffic is rapidly switched to the secondary port of each smart link group, and switched back to the primary
ports after the fault is cleared. For more information about CFD, see " Configuring CFD
."
Figure 26 Network diagram
MD
Device A
Device B
GE
1/0
/1
GE
1/0
/1
GE
1/0
/2 GE
1/0
/1
GE
1/0
/2
GE
1/0
/1
Device C
GE
1/0
/2
GE
1/0
/2
Device D
Outward-facing MEP
User network
Configuration procedure
1. Configure Device A:
# Create VLAN 1 through VLAN 200.
<DeviceA> system-view
[DeviceA] vlan 1 to 200
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports and assign them to
VLANs 1 through 200. Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110
[DeviceA-GigabitEthernet1/0/1] quit
113
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110
[DeviceA-GigabitEthernet1/0/2] quit
# Enable CFD and create an MD of level 5.
[DeviceA] cfd enable
[DeviceA] cfd md MD level 5
# Create MA MA_A for the MD, configure the MA to serve VLAN 10, and create service instance
1 for the MD and MA.
[DeviceA] cfd ma MA_A md MD vlan 10
[DeviceA] cfd service-instance 1 md MD ma MA_A
# Create a MEP list in service instance 1, create and enable outward-facing MEP 1002, and enable CCM sending in service instance 1 on GigabitEthernet 1/0/1.
[DeviceA] cfd meplist 1001 1002 service-instance 1
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] cfd mep 1002 service-instance 1 outbound
[DeviceA-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1002 enable
[DeviceA-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1002 enable
[DeviceA-GigabitEthernet1/0/1] quit
# Create MA MA_B for the MD, configure the MA to serve VLAN 110, and create service instance
2 for the MD and MA.
[DeviceA] cfd ma MA_B md MD vlan 110
[DeviceA] cfd service-instance 2 md MD ma MA_B
# Create a MEP list in service instance 2, create and enable outward-facing MEP 1002, and enable CCM sending in service instance 2 on GigabitEthernet 1/0/2.
[DeviceA] cfd meplist 2001 2002 service-instance 2
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] cfd mep 2002 service-instance 2 outbound
[DeviceA-GigabitEthernet1/0/2] cfd mep service-instance 2 mep 2002 enable
[DeviceA-GigabitEthernet1/0/2] cfd cc service-instance 2 mep 2002 enable
[DeviceA-GigabitEthernet1/0/2] quit
2. Configure Device B:
# Create VLAN 1 through VLAN 200.
<DeviceB> system-view
[DeviceB] vlan 1 to 200
# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 200. Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on
GigabitEthernet 1/0/1.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceB-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110
[DeviceB-GigabitEthernet1/0/1] quit
# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 200. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 and
VLAN 110 as the receive control VLANs.
114
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110
[DeviceB-GigabitEthernet1/0/2] quit
3. Configure Device C:
# Create VLAN 1 through VLAN 200, map VLANs 1 through 100 to MSTI 1, and VLANs 101 through 200 to MSTI 2, and activate MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 1 to 200
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 1 to 100
[DeviceC-mst-region] instance 2 vlan 101 to 200
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure the ports as trunk ports, and assign them to VLAN 1 through VLAN 200.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] shutdown
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] shutdown
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceC-GigabitEthernet1/0/2] quit
# Create smart link group 1 and configure all VLANs mapped to MSTI 1 as the protected VLANs for smart link group 1.
[DeviceC] smart-link group 1
[DeviceC-smlk-group1] protected-vlan reference-instance 1
# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.
[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave
# Enable role preemption in smart link group 1, enable flush message sending, and configure
VLAN 10 as the transmit control VLAN.
[DeviceC-smlk-group1] preemption mode role
[DeviceC-smlk-group1] flush enable control-vlan 10
[DeviceC-smlk-group1] quit
# Create smart link group 2 and configure all VLANs mapped to MSTI 2 as the protected VLANs for smart link group 2.
[DeviceC] smart-link group 2
115
[DeviceC-smlk-group2] protected-vlan reference-instance 2
# Configure GigabitEthernet 1/0/1 as the secondary port and GigabitEthernet 1/0/2 as the primary port for smart link group 2.
[DeviceC-smlk-group2] port gigabitethernet 1/0/2 master
[DeviceC-smlk-group2] port gigabitethernet 1/0/1 slave
# Enable role preemption in smart link group 2, enable flush message sending, and configure
VLAN 110 as the transmit control VLAN.
[DeviceC-smlk-group2] preemption mode role
[DeviceC-smlk-group2] flush enable control-vlan 110
[DeviceC-smlk-group2] quit
# Enable CFD and create an MD of level 5.
[DeviceC] cfd enable
[DeviceC] cfd md MD level 5
# Create MA MA_A for the MD and configure the MA to serve VLAN 10, and create service instance 1 for the MD and MA.
[DeviceC] cfd ma MA_A md MD vlan 10
[DeviceC] cfd service-instance 1 md MD ma MA_A
# Create a MEP list in service instance 1, create and enable outward-facing MEP 1001, and enable CCM sending in service instance 1 on GigabitEthernet 1/0/1.
[DeviceC] cfd meplist 1001 1002 service-instance 1
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] cfd mep 1001 service-instance 1 outbound
[DeviceC-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1001 enable
[DeviceC-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1001 enable
[DeviceC-GigabitEthernet1/0/1] quit
# Create MA MA_B for the MD and configure the MA to serve VLAN 110, and create service instance 2 for the MD and MA.
[DeviceC] cfd ma MA_B md MD vlan 110
[DeviceC] cfd service-instance 2 md MD ma MA_B
# Create a MEP list in service instance 2, create and enable outward-facing MEP 2001, and enable CCM sending in service instance 2 on GigabitEthernet 1/0/2.
[DeviceC] cfd meplist 2001 2002 service-instance 2
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] cfd mep 2001 service-instance 2 outbound
[DeviceC-GigabitEthernet1/0/2] cfd mep service-instance 2 mep 2001 enable
[DeviceC-GigabitEthernet1/0/2] cfd cc service-instance 2 mep 2001 enable
[DeviceC-GigabitEthernet1/0/2] quit
# Configure the collaboration between the primary port GigabitEthernet 1/0/1 of smart link group 1 and the CC function of CFD, and bring up the port.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] port smart-link group 1 track cfd cc
[DeviceC-GigabitEthernet1/0/1] undo shutdown
[DeviceC-GigabitEthernet1/0/1] quit
# Configure the collaboration between the primary port GigabitEthernet 1/0/2 of smart link group 2 and the CC function of CFD, and bring up the port.
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] port smart-link group 2 track cfd cc
116
[DeviceC-GigabitEthernet1/0/2] undo shutdown
[DeviceC-GigabitEthernet1/0/2] quit
4. Configure Device D:
# Create VLAN 1 through VLAN 200.
<DeviceD> system-view
[DeviceD] vlan 1 to 200
# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 200. Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on
GigabitEthernet 1/0/1.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200
[DeviceD-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110
[DeviceD-GigabitEthernet1/0/1] quit
# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 200. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 and
VLAN 110 as the receive control VLANs.
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110
[DeviceD-GigabitEthernet1/0/2] quit
Verifying the configuration
Assume that the optical fiber between Device A and Device B fails. Use the display smart-link group command to display the smart link group configuration on a device.
# Display the smart link group configuration on Device C.
[DeviceC] display smart-link group all
Smart link group 1 information:
Device ID: 000f-e23d-5af0
Preemption mode: ROLE
Preemption delay: 1(s)
Control VLAN: 10
Protected VLAN: Reference Instance 1
Member Role State Flush-count Last-flush-time
-----------------------------------------------------------------------------
GigabitEthernet1/0/1 MASTER DOWN 5 16:37:20 2010/02/21
GigabitEthernet1/0/2 SLAVE ACTVIE 3 17:45:20 2010/02/21
Smart link group 2 information:
Device ID: 000f-e23d-5af0
Preemption mode: ROLE
Preemption delay: 1(s)
Control VLAN: 110
Protected VLAN: Reference Instance 2
117
Member Role State Flush-count Last-flush-time
-----------------------------------------------------------------------------
GigabitEthernet1/0/2 MASTER ACTVIE 5 16:37:20 2010/02/21
GigabitEthernet1/0/1 SLAVE STANDBY 1 17:45:20 2010/02/21
The output shows that primary port GigabitEthernet 1/0/1 of smart link group 1 fails, and secondary port GigabitEthernet 1/0/2 is in forwarding state.
118
Configuring Monitor Link
Monitor Link is typically used in conjunction with Smart Link in a dual-homed network to enable faster link switchover than spanning tree protocols. This chapter describes basic Monitor Link concepts, its working mechanism, and configuration procedure.
Overview
Monitor Link works together with Layer 2 topology protocols to adapt the up/down state of a downlink port to the state of an uplink port. This feature enables fast link switchover on a downstream device in response to the uplink state change on its upstream device.
Figure 27 Monitor Link application scenario
Terminology
The following terms are associated with Monitor Link configuration.
Monitor link group
A monitor link group is a set of uplink and downlink ports. A port can belong to only one monitor link group. As shown in
Figure 27 , ports Port 1 and Port 2 of Device B and those of Device D each form a
monitor link group. Port 1 is an uplink port on both devices, and Port 2 is a downlink port on both devices.
Uplink/Downlink ports
Uplink port and downlink port are two port roles in monitor link groups:
119
• Uplink ports are the monitored ports—The state of a monitor link group adapts to that of its member uplink ports. When a monitor link group contains no uplink port or all uplink ports are down, the monitor link group goes down. As long as one member uplink port is up, the monitor link group stays up.
• Downlink ports are the monitoring ports—The state of the downlink port of a monitor link group adapts to that of the monitor link group. When the state of a monitor link group changes, the state of its member downlink ports change accordingly. The state of the downlink ports in a monitor link group is always the same as that of the monitor link group.
Uplink/Downlink
The uplink is the link that connects the uplink ports in a monitor link group, and the downlink is the link that connects the downlink ports.
How Monitor Link works
Each monitor link group operates independently of other monitor link groups. When a monitor link group contains no uplink port or all its uplink ports are down, the monitor link group goes down, which forces all its downlink ports down at the same time. When any uplink port goes up, the monitor link group goes up and brings up all its downlink ports.
HP does not recommend that you manually shut down or bring up the downlink ports in a monitor link group.
Configuring Monitor Link
This section provides instructions for configuring Monitor Link.
Configuration prerequisites
Make sure the port is not a member port of any aggregation group or service loopback group.
Creating a monitor link group
Step Command
1. Enter system view. system-view
2. Create a monitor link group and enter monitor link group view. monitor-link group group-id
Configuring monitor link group member ports
You can configure member ports for a monitor link group either in monitor link group view or interface view. The configurations made in these two views have the same result.
In monitor link group view
To configure member ports for a monitor link group:
Step Command
1. Enter system view. system-view
120
Step Command
2. Enter monitor link group view. monitor-link group group-id
3. Configure member ports for the monitor link group. port interface-type interface-number { uplink | downlink }
In interface view
To configure member ports for a monitor link group:
Step Command
1. Enter system view. system-view
2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view. interface interface-type
interface-number
Remarks
N/A
N/A
3. Configure the current interface as a member of a monitor link group. port monitor-link group group-id
{ uplink | downlink }
•
You can assign a Layer 2
Ethernet interface or Layer 2 aggregate interface to a monitor link group as a member port.
•
A port can be assigned to only one monitor link group.
•
To avoid undesired down/up state changes on the downlink ports, configure uplink ports prior to downlink ports.
Displaying and maintaining Monitor Link
Remarks Task Command
Display monitor link group information. display monitor-link group
{ group-id | all } [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Monitor Link configuration example
Network requirements
, Device C is a smart link device, and Device A, Device B, and Device D are associated devices. Traffic of VLANs 1 through 30 on Device C is dual-uplinked to Device A through a smart link group. For more information about Smart Link, see "
Implement dual uplink backup on Device C. Make sure that when the link between Device A and Device
B (or Device D) fails, Device C must be able to sense the link fault and perform uplink switchover in the smart link group.
121
Figure 28 Network diagram
Configuration procedure
1. Configure Device C:
# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate MST region configuration.
<DeviceC> system-view
[DeviceC] vlan 1 to 30
[DeviceC] stp region-configuration
[DeviceC-mst-region] instance 1 vlan 1 to 30
[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Disable the spanning tree feature on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure them as trunk ports, and assign them to VLANs 1 through 30.
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/1] quit
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] undo stp enable
[DeviceC-GigabitEthernet1/0/2] port link-type trunk
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/2] quit
# Create smart link group 1 and configure all the VLANs mapped to MSTI 1 as the protected
VLANs for smart link group 1.
[DeviceC] smart-link group 1
[DeviceC-smlk-group1] protected-vlan reference-instance 1
# Configure GigabitEthernet 1/0/1 as the master port and GigabitEthernet 1/0/2 as the subordinate port for smart link group 1.
[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave
# Enable the smart link group to transmit flush messages.
[DeviceC-smlk-group1] flush enable
[DeviceC-smlk-group1] quit
122
2. Configure Device A:
# Create VLANs 1 through 30.
<DeviceA> system-view
[DeviceA] vlan 1 to 30
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, assign them to
VLANs 1 through 30, and enable flush message receiving on them.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] smart-link flush enable
[DeviceA-GigabitEthernet1/0/1] quit
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] port link-type trunk
[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/2] smart-link flush enable
[DeviceA-GigabitEthernet1/0/2] quit
3. Configure Device B:
# Create VLANs 1 through 30.
<DeviceB> system-view
[DeviceB] vlan 1 to 30
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, and assign them to VLANs 1 through 30. Disable the spanning tree feature on GigabitEthernet 1/0/2 and enable flush message receiving on the two ports.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/1] smart-link flush enable
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] undo stp enable
[DeviceB-GigabitEthernet1/0/2] port link-type trunk
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/2] smart-link flush enable
[DeviceB-GigabitEthernet1/0/2] quit
# Create monitor link group 1 and configure GigabitEthernet 1/0/1 as an uplink port and
GigabitEthernet 1/0/2 as a downlink port for monitor link group 1.
[DeviceB] monitor-link group 1
[DeviceB-mtlk-group1] port gigabitethernet 1/0/1 uplink
[DeviceB-mtlk-group1] port gigabitethernet 1/0/2 downlink
[DeviceB-mtlk-group1] quit
4. Configure Device D:
# Create VLANs 1 through 30.
<DeviceD> system-view
[DeviceD] vlan 1 to 30
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, and assign them to VLANs 1 through 30. Disable the spanning tree feature on GigabitEthernet 1/0/2 and enable flush message receiving on the two ports.
123
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/1] smart-link flush enable
[DeviceD-GigabitEthernet1/0/1] quit
[DeviceD] interface gigabitethernet 1/0/2
[DeviceD-GigabitEthernet1/0/2] undo stp enable
[DeviceD-GigabitEthernet1/0/2] port link-type trunk
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/2] smart-link flush enable
[DeviceD-GigabitEthernet1/0/2] quit
# Create monitor link group 1 and configure GigabitEthernet 1/0/1 as an uplink port and
GigabitEthernet 1/0/2 as a downlink port for monitor link group 1.
[DeviceD] monitor-link group 1
[DeviceD-mtlk-group1] port gigabitethernet 1/0/1 uplink
[DeviceD-mtlk-group1] port gigabitethernet 1/0/2 downlink
[DeviceD-mtlk-group1] quit
Verifying the configuration
Use the display monitor-link group command to display the monitor link group information on devices.
For example, when GigabitEthernet 1/0/2 on Device A goes down due to a link fault:
# Examine information about monitor link group 1 on Device B.
[DeviceB] display monitor-link group 1
Monitor link group 1 information:
Group status: UP
Last-up-time: 16:37:20 2009/4/21
Last-down-time: 16:35:26 2009/4/21
Member Role Status
------------------------------------------
GigabitEthernet1/0/1 UPLINK UP
GigabitEthernet1/0/2 DOWNLINK UP
# Examine information about monitor link group 1 on Device D.
[DeviceD] display monitor-link group 1
Monitor link group 1 information:
Group status: DOWN
Last-up-time: 16:35:27 2009/4/21
Last-down-time: 16:37:19 2009/4/21
Member Role Status
------------------------------------------
GigabitEthernet1/0/1 UPLINK DOWN
GigabitEthernet1/0/2 DOWNLINK DOWN
124
Configuring VRRP
This chapter describes how to configure VRRP.
VRRP overview
on a LAN. All packets destined to other network segments are sent over the default route to the gateway, which then forwards the packets. However, when the gateway fails, the hosts that use the gateway as the default next-hop router cannot communicate with external networks.
Figure 29 LAN networking
Configuring a default route for network hosts facilitates your configuration, but also requires high performance stability of the device that acts as the gateway. Using more egress gateways can improve availability, but introduce routing problems among the egresses.
VRRP is designed to address this problem. VRRP adds multiple routers that can act as network gateways to a VRRP group, which forms a virtual router. Routers in the VRRP group elect a master through the VRRP election mechanism to act as a gateway, and hosts on a LAN only need to configure the virtual router as their default gateway.
VRRP avoids single points of failure and simplifies the configuration on hosts. When the master in the
VRRP group for a multicast or broadcast LAN (for example, an Ethernet network) fails, another gateway in the VRRP group can take over without causing dynamic route recalculation, route rediscovery, gateway reconfiguration on the hosts, or traffic interruption.
VRRP operates in standard mode, and includes two versions: IETF VRRPv2 for IPv4 and VRRPv3 for IPv6.
For more information, see "
VRRP standard mode
This section describes basic concepts of standard mode VRRP.
125
VRRP group
VRRP combines a group of routers (one master and multiple backups) on a LAN into a virtual router called a VRRP group.
A VRRP group has the following features:
•
A virtual router has a virtual IP address. A host on the LAN only needs to know the IP address of the virtual router and uses the IP address as the next hop of the default route.
• Every host on the LAN communicates with external networks through the virtual router.
• Routers in the VRRP group elect a master that acts as the gateway according to their priorities. The other routers function as backups. When the master fails, to make sure the hosts in the network segment can communicate without interruption with the external networks, the backups in the VRRP group elect a new master to act as the gateway.
Figure 30 Network diagram
, Router A, Router B, and Router C form a virtual router, which has its own IP address. Hosts on the Ethernet use the virtual router as the default gateway.
The router with the highest priority is elected as the master to act as the gateway and the other two are backups.
The IP address of the virtual router can be either an unused IP address on the segment 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.
Only one IP address owner can be configured for a VRRP group.
A router in a VRRP group can be in master, backup, or initialize status.
VRRP priority
VRRP determines the role (master or backup) of each router in a VRRP group by priority. A router with a higher priority is more likely to become the master.
VRRP priority is in the range of 0 to 255. The greater the number, the higher the priority. Priorities 1 to
254 are configurable. Priority 0 is reserved and priority 255 is for the IP address owner. The router acting as the IP address owner in a VRRP group always has the running priority 255 and acts as the master as long as it operates properly.
126
Operation mode
A router in a VRRP group operates in either of the following modes:
•
Non-preemptive mode—When a router in the VRRP group becomes the master, it stays as the master as long as it operates properly, even if a backup is assigned a higher priority later.
• Preemptive mode—When a backup finds it has a higher priority than the master, the backup sends
VRRP advertisements to start a new master election in the VRRP group and becomes the master. The original master becomes a backup.
Authentication mode
To avoid attacks from unauthorized users, VRRP member routers add authentication keys in VRRP packets to authenticate one another. VRRP provides the following authentication modes:
• simple—Simple text 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 are the same, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate.
• md5—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 authentication header. The receiver performs the same operation by using the authentication key and MD5 algorithm, and compares the result with the content in the authentication header. If the results are the same, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate.
On a secure network, you can choose to not authenticate VRRP packets.
VRRP timers
VRRP timers include VRRP advertisement interval and VRRP preemption delay timer.
VRRP advertisement interval
The master in a VRRP group periodically sends VRRP advertisements to inform all the other routers in the
VRRP group that it is operating properly.
You can adjust the interval for sending VRRP advertisements by setting the VRRP advertisement interval.
If a backup receives no advertisements in a period three times the interval, the backup regards itself as the master and sends VRRP advertisements to start a new master election.
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, a backup does not immediately become the master after it receives an advertisement that carries the priority lower than the local priority. Instead, it waits for a period of time (the preemption delay time), and then sends VRRP advertisements to start a new master election in the VRRP group before becoming the master.
Packet format
The master periodically multicasts VRRP packets to declare its presence. VRRP packets are also used for examining the parameters of the virtual router and electing the master.
VRRP packets are encapsulated in IP packets, with the protocol number 112. Figure 31
shows the VRRPv2 packet format and
shows the VRRPv3 packet format.
127
Figure 31 VRRPv2 packet format
Figure 32 VRRPv3 packet format
0 3 7
Version Type Virtual Rtr ID
Auth Type Adver Int
15
Priority
23
Count IPv6 Addrs
Checksum
31
IPv6 address 1
IPv6 address n
Authentication data 1
Authentication data 2
A VRRP packet includes the following fields:
•
Version—Version number of the protocol, 2 for VRRPv2 and 3 for VRRPv3.
• Type—Type of the VRRPv2 or VRRPv3 packet. It must be VRRP advertisement, represented by 1.
• Virtual Rtr ID (VRID)—ID of the virtual router. It ranges from 1 to 255.
•
Priority—Priority of the router in the VRRP group, in the range of 0 to 255. A greater value represents a higher priority.
• Count IP Addrs/Count IPv6 Addrs—Number of virtual IPv4 or IPv6 addresses for the VRRP group.
A VRRP group can have multiple virtual IPv4 or IPv6 addresses.
•
Auth Type—Authentication type. 0 means no authentication, 1 means simple text authentication, and 2 means MD5 authentication. VRRPv3 does not support MD5 authentication.
• Adver Int—Interval for sending advertisement packets. For VRRPv2, the interval is in seconds and defaults to 1. For VRRPv3, the interval is in centiseconds and defaults to 100.
•
Checksum—16-bit checksum for validating the data in VRRP packets.
128
• IP Address/IPv6 Address—Virtual IPv4 or IPv6 address entry of the VRRP group. The Count IP
Addrs or Count IPv6 Addrs field defines the number of virtual IPv4 or IPv6 addresses.
•
Authentication Data—Authentication key. This field is used only for simple authentication and is 0 for any other authentication mode.
VRRP principles
The working principles of VRRP are:
• Routers in a VRRP group determine their roles by priority. The router with the highest priority is the master, and the others are the backups. The master periodically sends VRRP advertisements to notify the backups that it is operating properly, and each backup starts a timer to wait for advertisements from the master.
• In preemptive mode, when a backup receives a VRRP advertisement, it compares the priority in the packet with its own priority. If the priority of the backup is higher, the backup becomes the master.
Otherwise, it remains as a backup. In preemptive mode, a VRRP group always has the router with the highest priority as the master for forwarding packets.
• In non-preemptive mode, a backup with higher priority than the master does not preempt the master if the master is operating properly. The non-preemptive mode avoids frequent master and backup switchover.
• If the timer of a backup expires but the backup does not receive any VRRP advertisement, it considers that the master has failed. In this case, the backup considers itself as the master and sends
VRRP advertisements to start a new master election.
•
When multiple routers in a VRRP group declare that they are the master because of inconsistent configuration or 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.
•
When a backup router receives an advertisement, it compares its priority with the advertised priority.
If its priority is higher, it takes over as the master.
VRRP tracking
To enable VRRP tracking, first configure the routers in the VRRP group to operate in preemptive mode, so the router with the highest priority always operates as the master for packet forwarding.
Tracking a specified interface
The interface tracking function expands the backup functionality of VRRP. It provides backup not only when the interface to which a VRRP group is assigned fails, but also when other interfaces (such as uplink interfaces) on the router become unavailable.
If the uplink interface of a router in a VRRP group fails, usually the VRRP group cannot be aware of the uplink interface failure. If the router is the master of the VRRP group, hosts on the LAN are unable to access external networks. This problem can be solved by tracking a specified uplink interface. If the tracked uplink interface is down or removed, the priority of the master is automatically decreased by a specified value. A higher priority router in the VRRP group becomes the master.
Monitoring a track entry
By monitoring a track entry, you can:
• Monitor an uplink and change the priority of the router according to the uplink state.
If the uplink fails, hosts in the LAN cannot access external networks through the router. The state of the monitored track entry is negative and the priority of the router decreases by a specified value.
129
Then, a higher priority router in the VRRP group becomes the master to maintain the proper communication between the hosts in the LAN and external networks.
•
Monitor the master on a backup.
When the master fails, the backup immediately takes over to maintain normal communication.
For more information about track entries, see " Configuring track
."
VRRP application
This section describes an IPv4 VRRP application.
Master/backup
In master/backup mode, only the master forwards packets. When the master fails, a new master is elected from the backups. This mode requires only one VRRP group, in which each router holds a different priority and the one with the highest priority becomes the master.
Figure 33 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 LAN.
Load sharing
You can create more than one VRRP group on an interface of a router to allow the router to be the master of one VRRP group but a backup of another at the same time.
In load sharing mode, multiple routers provide services simultaneously. This mode requires two or more
VRRP groups, each of which comprises a master and one or more backups. The master roles in the VRRP groups are assumed by different routers.
130
Figure 34 VRRP in load sharing mode
A router can be in multiple VRRP groups and hold a different priority in a different group.
As shown in
, the following VRRP groups are present:
•
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.
For load sharing among Router A, Router B, and Router C, configure the hosts on the LAN to use VRRP group 1, 2, and 3, respectively, as the default gateways. When configuring VRRP priorities, make sure each router is prioritized properly in each VRRP group so that it can take the expected role in the group.
General configuration restrictions
You can perform interface-specific VRRP configuration only on Layer 3 Ethernet interfaces, VLAN interfaces, and Layer 3 aggregate interfaces, unless otherwise specified. 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).
VRRP cannot be configured on interfaces in a link aggregation group.
Configuring VRRP for IPv4
This section provides instructions for configuring VRRP for IPv4.
VRRP for IPv4 configuration task list
To form a VRRP group, perform the following configurations on each device in the VRRP group.
131
Task Remarks
Specifying the type of MAC addresses mapped to virtual IP addresses
Optional.
Creating a VRRP group and configuring virtual IP addresses
Configuring router priority, preemptive mode, and tracking function
Configuring VRRP packet attributes
Enabling the trap function for VRRP
Required.
Optional.
Optional.
Optional.
Specifying the type of MAC addresses mapped to virtual IP addresses
You can configure VRRP in standard mode to map real or virtual MAC addresses to the virtual IP addresses of VRRP groups, so the master in a VRRP group uses the specified type of MAC address as the source MAC address for sending packets and for answering ARP requests.
• Virtual MAC to virtual IP mapping—By default, a virtual MAC address is automatically assigned when a VRRP group is created, and the virtual IP address of the VRRP group is mapped to the virtual
MAC address. In this mapping approach, the hosts do not need to update the gateway IP and MAC mapping entry when the master changes.
• Real MAC to virtual IP mapping—If a VRRP group has an IP address owner, configure real MAC to virtual IP mapping to avoid the problem of one IP address mapped to two MAC addresses (the real and the virtual). In this approach, the virtual IP address of the VRRP group is mapped to the real
MAC address of the IP address owner, and all packets from hosts are forwarded to the IP address owner.
If VRRP groups with the same ID are created on multiple interfaces and the VRRP advertisements of these
VRRP groups are to be sent across a QinQ network, HP recommends that you use real MAC to virtual IP mapping to guarantee successful transmission of the VRRP advertisements.
To specify the type of MAC addresses mapped to virtual IP addresses:
Step Command
1. Enter system view. system-view
2. Specify the type of MAC addresses mapped to virtual IP addresses. vrrp method { real-mac | virtual-mac }
Remarks
N/A
Optional.
By default, virtual MAC addresses are mapped to virtual IP addresses.
Creating a VRRP group and configuring virtual IP addresses
This section describes how to create a VRRP and configure virtual IP addresses.
Configuration guidelines
•
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.
• The VRRP group is automatically created when you specify the first virtual IP address. If you later specify another virtual IP address for the VRRP group, the virtual IP address is added to the virtual
IP address list of the VRRP group.
132
• The virtual IP address assigned to the VRRP group must be a legal host address and in the same subnet as the interface IP address. If not, the state of the VRRP group is always initialize and VRRP does not take effect. For example, although you can successfully configure a network address or broadcast address as the virtual IP address of a VRRP group, the group cannot work.
• HP recommends that you not create a VRRP group on the VLAN interface of a super VLAN because network performance can be adversely affected.
•
When VRRP operates 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. In the latter case, the router is called the IP address owner.
•
When a router is the IP address owner in a VRRP group, HP recommends you 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.
•
A VRRP group is removed after you remove all its virtual IP addresses, and all its configurations become invalid.
• 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 address of a VRRP group cannot be 0.0.0.0, 255.255.255.255, loopback addresses, non-class A/B/C addresses or other illegal IP addresses such as 0.0.0.1.
Configuration prerequisites
Before you create a VRRP group and configure a virtual IP address on an interface, configure an IP address for the interface and make sure it is in the same subnet as the virtual IP address.
Configuration procedure
To create a VRRP group and configure a virtual IP address:
Remarks
N/A
Step Command
1.
Enter system view. system-view
2. Enter the specified interface view.
3. Create a VRRP group and configure a virtual IP address for the VRRP group. interface interface-type
interface-number vrrp vrid virtual-router-id virtual-ip
virtual-address
N/A
By default, no VRRP group is created.
Configuring router priority, preemptive mode, and tracking function
This section describes how to configure router priority, preemptive mode, and tracking function.
Configuration guidelines
• The running priority of an IP address owner is always 255. You do not need to configure it. An IP address owner always operates in preemptive mode.
•
If you configure an interface to be tracked or a track entry to be monitored on a router that is the IP address owner in a VRRP group, the configuration does not take effect. If the router is not the IP address owner in the VRRP group later, the configuration takes effect.
133
• If the state of a tracked interface changes from down or removed to up, the priority of the router where the interface resides automatically restores.
•
If the state of a track entry changes from negative or invalid to positive, the priority of the router where the track entry is configured automatically restores.
Configuration prerequisites
Before you configure router priority, preemptive mode, and tracking function, create a VRRP group on an interface and configure a virtual IP address for it.
Configuration procedure
The router priority, preemptive mode, and track function can determine which router in the VRRP group serves as the master.
To configure router priority, preemptive mode and the tracking function:
Step Command
1. Enter system view. system-view
2. Enter interface view. interface interface-type
interface-number
3. Configure router priority in the
VRRP group. vrrp vrid virtual-router-id priority
priority-value
Remarks
N/A
N/A
4. Configure the router in the
VRRP group to operate in preemptive mode and configure preemption delay. vrrp vrid virtual-router-id preempt-mode [ timer delay
delay-value ]
Optional.
The default is 100.
Optional.
By default, the router in the VRRP group operates in preemptive mode and the preemption delay is
0 seconds.
5. Configure the interface to be tracked.
6. Configure VRRP to track a specified track entry. vrrp vrid virtual-router-id track interface interface-type
interface-number [ reduced
priority-reduced ] vrrp vrid virtual-router-id track
track-entry-number [ reduced
priority-reduced | switchover ]
Optional.
By default, no interface is being tracked.
Optional.
By default, VRRP is not configured to track a specified track entry.
Configuring VRRP packet attributes
This section describes how to configure VRRP packet attributes.
Configuration guidelines
• You can configure different authentication modes and authentication keys for the VRRP groups on an interface. However, the members of the same VRRP group must use the same authentication mode and authentication key.
• Excessive traffic can cause a backup to trigger a change of its status, because the backup does not receive any VRRP advertisements for a specified period of time. To solve this problem, prolong the time interval for sending VRRP advertisements.
•
Configuring different intervals for sending VRRP advertisements on the routers in a VRRP group can cause a backup to trigger a change of its status, because the backup does not receive any VRRP
134
advertisements for the specified period of time. To solve this problem, configure the same interval for sending VRRP advertisements on each router in the VRRP group.
Configuration prerequisites
Before you configure VRRP packet attributes, create a VRRP group and configure a virtual IP address for it.
Configuration procedure
To configure VRRP packet attributes:
Step Command
1. Enter system view. system-view
2. Configure the DSCP priority of
VRRP packets. vrrp dscp dscp-value
Remarks
N/A
Optional.
By default, the DSCP priority of VRRP packets is 48.
This command is available in Release
1203 and later versions.
3. Enter the specified interface view.
4. Configure the authentication mode and authentication key when the VRRP groups send and receive VRRP packets.
5. Configure the time interval for the master in the VRRP group to send VRRP advertisements. interface interface-type
interface-number vrrp vrid virtual-router-id authentication-mode { md5 | simple } [ cipher ] key vrrp vrid virtual-router-id timer advertise adver-interval
N/A
Optional.
By default, no authentication is performed.
Optional.
The default is 1 second.
6. Disable TTL check on VRRP packets. vrrp un-check ttl
Optional.
By default, TTL check on VRRP packets is enabled.
You do not need to create a VRRP group before executing this command.
Enabling the trap function for VRRP
When the trap function is enabled for VRRP, VRRP generates traps with severity level errors to report its key events. The traps are sent to the information center of the device, where you can configure whether to output the trap information and the output destination. For how to configure the information center, see
Network Management and Monitoring Configuration Guide.
To enable the trap function for VRRP:
1. Enter system view. system-view N/A
135
2. Enable the trap function for
VRRP. snmp-agent trap enable vrrp
[ authfailure | newmaster ]
Optional.
By default, the trap function for
VRRP is enabled.
For more information about the snmp-agent trap enable vrrp command, see the snmp-agent trap enable command in Network
Management and Monitoring
Command Reference.
Displaying and maintaining VRRP for IPv4
Task Command
Display VRRP group status. display vrrp [ verbose ] [ interface
interface-type interface-number
[ vrid virtual-router-id ] ] [ | { begin
| exclude | include }
regular-expression ]
Display VRRP group statistics. display vrrp statistics [ interface
interface-type interface-number
[ vrid virtual-router-id ] ] [ | { begin
| exclude | include }
regular-expression ]
Clear VRRP group statistics. reset vrrp statistics [ interface
interface-type interface-number
[ vrid virtual-router-id ] ]
Remarks
Available in any view.
Available in any view.
Available in user view.
Configuring VRRP for IPv6
Follow these instructions to configure VRRP for IPv6.
VRRP for IPv6 configuration task list
Task Remarks
Specifying the type of mapped MAC addresses
Optional.
Creating a VRRP group and configuring a virtual IPv6 address
Configuring router priority, preemptive mode, and tracking function
Configuring VRRP packet attributes
Required.
Optional.
Optional.
Specifying the type of mapped MAC addresses
You can configure VRRP in standard protocol mode to map real or virtual MAC addresses to the virtual
IPv6 addresses of VRRP groups, so the master in a VRRP group uses the specified type of MAC address as the source MAC address for sending packets and for answering ARP requests.
136
The following types of MAC addresses are available to be mapped to the virtual IPv6 address of a VRRP group:
•
Virtual MAC to virtual IP mapping—By default, a virtual MAC address is automatically assigned when a VRRP group is created, and the virtual IPv6 address of the VRRP group is mapped to the virtual MAC address. In this mapping approach, the hosts do not need to update the mapping between the IPv6 address and the MAC address when the master changes.
•
Real MAC to virtual IP mapping—If a VRRP group has an IP address owner, configure real MAC to virtual IP mapping to avoid the problem of one IPv6 address mapped to two MAC addresses (the real and the virtual). In this approach, the virtual IP address of the VRRP group is mapped to the real
MAC address of the IP address owner, and all packets from hosts are forwarded to the IP address owner.
To specify the type of MAC addresses mapped to virtual IPv6 addresses:
Step Command
1. Enter system view.
2. Specify the type of MAC addresses mapped to virtual
IPv6 addresses. system-view vrrp ipv6 method { real-mac | virtual-mac }
Remarks
N/A
Optional.
Virtual MAC address by default.
Creating a VRRP group and configuring a virtual IPv6 address
When creating a VRRP group, configure a virtual IPv6 address for the VRRP group. You can configure multiple virtual IPv6 addresses for a VRRP group.
A VRRP group is automatically created when you specify the first virtual IPv6 address for the VRRP group.
If you specify another virtual IPv6 address for the VRRP group later, the virtual IPv6 address is added to the virtual IPv6 address list of the VRRP group.
Configuration guidelines
• Do not create VRRP groups on the VLAN interface of a super VLAN. Otherwise, network performance can be adversely affected.
•
When a router is the IP address owner in a VRRP group, HP recommends that you not configure the ospfv3 area command on the interface to use the IPv6 address of the interface or the virtual IPv6 address of the VRRP group to establish an OSPFv3 neighbor relationship with the adjacent router.
For more information about the ospfv3 area command, see Layer 3—IP Routing Command
Reference.
• A VRRP group is removed after you remove all its virtual IPv6 addresses and all of its configurations become invalid.
•
Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the collision, change the IPv6 address of the interface on the IP address owner before you remove the
VRRP group from the interface.
Configuration prerequisites
Before you create a VRRP group and configure a virtual IPv6 address on an interface, configure an IPv6 address for the interface. Make sure that it is in the same network segment as the virtual IPv6 address.
Configuration procedure
To create a VRRP group and configure its virtual IPv6 address:
137
Step Command
1. Enter system view. system-view
2. Enter the specified interface view. interface interface-type
interface-number
Remarks
N/A
N/A
3. Create a VRRP group and configure its virtual IPv6 address, which is a link local address.
4. Configure the VRRP group with a virtual IPv6 address, which is a global unicast address. vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address link-local vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address
By default, no VRRP group is created.
The first virtual IPv6 address of the
VRRP group must be a link local address. Only one link local address is allowed in a VRRP group, and must be removed the last.
Optional.
By default, no global unicast address is configured as the virtual
IPv6 address of a VRRP group.
Configuring router priority, preemptive mode, and tracking function
This section covers router priority, preemptive mode, and the tracking function.
Configuration guidelines
• The running priority of an IP address owner is always 255. You do not need to configure it. An IP address owner always operates in preemptive mode.
•
Interface tracking is not configurable on an IP address owner.
•
If you configure an interface to be tracked or a track entry to be monitored on a router that is the IP address owner in a VRRP group, the configuration does not take effect. If the router is not the IP address owner in the VRRP group later, the configuration takes effect.
•
If the state of a tracked interface changes from down or removed to up, the priority of the router that owns the interface automatically restores.
• If the state of a track entry changes from negative or invalid to positive, the priority of the router where the track entry is configured automatically restores.
Configuration prerequisites
Before you configure router priority, preemptive mode and tracking function, create a VRRP group and configure its virtual IPv6 address.
Configuration procedure
The router priority, preemptive mode, and the track function determine which router in the VRRP group serves as the master.
To configure router priority, preemptive mode, and interface tracking:
Step Command
1. Enter system view. system-view
Remarks
N/A
138
Step Command
2. Enter the specified interface view. interface interface-type
interface-number
3. Configure the priority of the router in the VRRP group.
4. Configure the router in the
VRRP group to operate in preemptive mode and configure preemption delay of the VRRP group.
5. Configure the interface to be tracked.
6. Configure VRRP to monitor a specified track entry.
Remarks
N/A vrrp ipv6 vrid virtual-router-id priority priority-value vrrp ipv6 vrid virtual-router-id preempt-mode [ timer delay
delay-value ]
Optional.
The default is 100.
Optional.
The router in the VRRP group operates in preemptive mode and the preemption delay is 0 seconds by default. vrrp ipv6 vrid virtual-router-id track interface interface-type
interface-number [ reduced
priority-reduced ]
Optional.
By default, no interface is being tracked. vrrp ipv6 vrid virtual-router-id track
track-entry-number [ reduced
priority-reduced | switchover ]
Optional.
By default, VRRP is not configured to monitor a specified track entry.
Configuring VRRP packet attributes
This section describes how to configure VRRP packet attributes.
Configuration guidelines
• You can configure different authentication modes and authentication keys for the VRRP groups on an interface. However, members of the same VRRP group must use the same authentication mode and authentication key.
• Excessive traffic can cause a backup to trigger a change of its status, because the backup does not receive any VRRP advertisements for the specified period of time. To solve this problem, increase the time interval for sending VRRP advertisements.
•
Configuring different intervals for sending VRRP advertisements on the routers in a VRRP group can cause a backup to trigger a change of its status, because the backup does not receive any VRRP advertisements for the specified period of time. To solve this problem, configure the same interval for sending VRRP advertisements on each router in the VRRP group.
Configuration prerequisites
Before you configure VRRP packet attributes, create a VRRP group and configure a virtual IPv6 address.
139
Configuration procedure
To configure VRRP packet attributes:
Step Command
1. Enter system view.
2. Configure the DSCP priority of
VRRP packets. system-view vrrp ipv6 dscp dscp-value
Remarks
N/A
Optional.
By default, the DSCP priority of
VRRP packets is 56.
This command is available in
Release 1203 and later versions.
3. Enter the specified interface view.
4. Configure the authentication mode and authentication key when the VRRP groups send or receive VRRP packets.
5. Configure the time interval for the master in the VRRP group to send VRRP advertisement. interface interface-type
interface-number vrrp ipv6 vrid virtual-router-id authentication-mode simple
[ cipher ] key vrrp ipv6 vrid virtual-router-id timer advertise adver-interval
N/A
Optional.
By default, no authentication is performed.
Optional.
The default is 100 centiseconds.
Displaying and maintaining VRRP for IPv6
Task Command
Display VRRP group status. display vrrp ipv6 [ verbose ] [ interface
interface-type interface-number [ vrid
virtual-router-id ] ] [ | { begin | exclude | include } regular-expression ]
Display VRRP group statistics.
Clear VRRP group statistics. display vrrp ipv6 statistics [ interface
interface-type interface-number [ vrid
virtual-router-id ] ] [ | { begin | exclude | include } regular-expression ] reset vrrp ipv6 statistics [ interface
interface-type interface-number [ vrid
virtual-router-id ] ]
Remarks
Available in any view.
Available in any view.
Available in user view.
IPv4 VRRP configuration examples
This section provides examples for IPv4 VRRP configuration on switches.
Single VRRP group configuration example
Network requirements
•
Switch A and Switch B form a VRRP group and use the virtual IP address 202.38.160.111/24 to provide gateway service for the LAN where Host A resides.
140
• 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 35 Network diagram
Configuration procedure
1. Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0
# Create VRRP group 1 and set its virtual IP address to 202.38.160.111.
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# Assign Switch A higher priority than Switch B so Switch A can become the master.
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# Configure Switch A to operate in preemptive mode so that it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
2. Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] vlan 2
[SwitchB-Vlan2] port gigabitethernet 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0
# Create VRRP group 1 and set its virtual IP address to 202.38.160.111.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# Set Switch B to operate in preemptive mode and set the preemption delay to five seconds.
141
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
Verifying the configuration
After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp verbose command.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 5
Auth Type : None
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.1
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 5
Become Master : 4200ms left
Auth Type : None
Virtual IP : 202.38.160.111
Master IP : 202.38.160.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.
When Switch A fails, you can successfully ping Host B on Host A. Use the display vrrp verbose command to view detailed information about the VRRP group on Switch B.
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
142
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 5
Auth Type : None
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.2
The output shows that when Switch A fails, Switch B becomes the master to forward packets from Host A to Host B.
# After Switch A resumes normal operation, display detailed information about VRRP group 1 on Switch
A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 5
Auth Type : None
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.1
The output shows that after Switch A resumes normal operation, it becomes the master to forward packets from Host A to Host B.
VRRP interface tracking configuration example
Network requirements
•
As shown in Figure 36 , Switch A and Switch B form a VRRP group and use the virtual IP address
202.38.160.111/24 to provide gateway service for the LAN where Host A resides.
• Switch A operates as the master to forward packets from Host A to Host B. When VLAN-interface
3 used by Switch A to provide gateway service fails, Switch B takes over to forward packets for Host
A.
• Configure Switch A and Switch B to authenticate VRRP packets to prevent fabricated packets. Set the authentication mode to plain text and the authentication key to hello.
143
Figure 36 Network diagram
Virtual IP address:
202.38.160.111/24
GE1/0/5
Vlan-int2
202.38.160.1/24
Vlan-int3
Switch A
202.38.160.3/24
Internet
203.2.3.1/24
Host B
Host A
GE1/0/5
Vlan-int2
202.38.160.2/24
Switch B
Configuration procedure
1. Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0
# Create a VRRP group 1 and set its virtual IP address to 202.38.160.111.
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# Assign Switch 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 the authentication mode of the VRRP group as simple and the authentication key as hello.
[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# Set the interval for the master to send VRRP advertisement to four seconds.
[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 4
# Configure Switch A to operate in preemptive mode, so it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
# Configure VLAN-interface 3 as a tracked interface and set the reduced priority to 30 so when
VLAN-interface 3 fails, the priority of Switch A drops below 100 and Switch B takes over.
[SwitchA-Vlan-interface2] vrrp vrid 1 track interface vlan-interface 3 reduced 30
2. Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] vlan 2
144
[SwitchB-vlan2] port gigabitethernet 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0
# Create a VRRP group 1 and set its virtual IP address to 202.38.160.111.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# Configure the authentication mode of the VRRP group as simple and the authentication key as hello.
[SwitchB-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# Set the interval for the master to send VRRP advertisement to four seconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 timer advertise 4
# Configure Switch B to operate in preemptive mode, so Switch B can become the master after the priority of Switch A decreases below 100. Configure the preemption delay as five seconds to avoid frequent status switchover.
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
Verifying the configuration
After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp verbose command.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 4
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 5
Auth Type : Simple Key : ******
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.1
VRRP Track Information:
Track Interface: Vlan3 State : Up Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 4
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 5
145
Become Master : 2200ms left
Auth Type : Simple Key : ******
Virtual IP : 202.38.160.111
Master IP : 202.38.160.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.
If interface VLAN-interface 3 through which Switch A connects to the Internet is not available, you can still ping Host B successfully on Host A. To display detailed information about the VRRP group, use the display vrrp verbose command.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 4
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 : 202.38.160.111
Master IP : 202.38.160.2
VRRP Track Information:
Track Interface: Vlan3 State : Down Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 4
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 5
Auth Type : Simple Key : ******
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.2
The output shows that when VLAN-interface 3 on Switch A is not available, the priority of Switch A is reduced to 80 and it becomes the backup. Switch B becomes the master to forward packets from Host A to Host B.
146
VRRP with multiple VLANs configuration example
Network requirements
• Switch A and Switch B form two VRRP groups. VRRP group 1 uses virtual IP address
202.38.160.100/25 to provide gateway service for hosts in VLAN 2, and VRRP group 2 uses virtual
IP address 202.38.160.200/25 to provide gateway service for hosts in VLAN 3.
•
Assign Switch A higher priority than Switch B in VRRP group 1 but 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 37 Network diagram
VLAN 2
Gateway:
202.38.160.100/25
Virtual IP address 1:
202.38.160.100/25
GE1/0/5
Vlan-int2
202.38.160.1/25
GE1/0/6
Vlan-int3
202.38.160.130/25
Switch A
VLAN 3
Gateway:
202.38.160.200/25
GE1/0/5
Vlan-int2
202.38.160.2/25
GE1/0/6
Vlan-int3
202.38.160.131/25
Switch B
Virtual IP address 2:
202.38.160.200/25
Configuration procedure
1. Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.128
# Create a VRRP group 1 and set its virtual IP address to 202.38.160.100.
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.100
# Assign Switch 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 gigabitethernet 1/0/6
[SwitchA-vlan3] quit
[SwitchA] interface vlan-interface 3
[SwitchA-Vlan-interface3] ip address 202.38.160.130 255.255.255.128
147
Internet
# Create a VRRP group 2 and set its virtual IP address to 202.38.160.200.
[SwitchA-Vlan-interface3] vrrp vrid 2 virtual-ip 202.38.160.200
2. Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.128
# Create a VRRP group 1 and set its virtual IP address to 202.38.160.100.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.100
[SwitchB-Vlan-interface2] quit
# Configure VLAN 3.
[SwitchB] vlan 3
[SwitchB-vlan3] port gigabitethernet 1/0/6
[SwitchB-vlan3] quit
[SwitchB] interface vlan-interface 3
[SwitchB-Vlan-interface3] ip address 202.38.160.131 255.255.255.128
# Create VRRP group 2 and set its virtual IP address to 202.38.160.200.
[SwitchB-Vlan-interface3] vrrp vrid 2 virtual-ip 202.38.160.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
Verifying the configuration
To verify your configuration, use the display vrrp verbose command.
# Display detailed information about the VRRP groups on Switch A.
[SwitchA-Vlan-interface3] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 2
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 202.38.160.100
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.1
Interface Vlan-interface3
VRID : 2 Adver Timer : 1
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
148
Become Master : 2200ms left
Auth Type : None
Virtual IP : 202.38.160.200
Master IP : 202.38.160.131
# Display detailed information about the VRRP groups on Switch B.
[SwitchB-Vlan-interface3] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 2
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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 : 202.38.160.100
Master IP : 202.38.160.1
Interface Vlan-interface3
VRID : 2 Adver Timer : 1
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 202.38.160.200
Virtual MAC : 0000-5e00-0102
Master IP : 202.38.160.131
The output shows that Switch A is operating as the master in VRRP group 1 to forward Internet traffic for the hosts that use the default gateway 202.38.160.100/25. Switch B is operating as the master in VRRP group 2 to forward Internet traffic for the hosts that use the default gateway 202.38.160.200/25.
IPv6 VRRP configuration examples
This section provides a configuration example or IPv6 VRRP.
Single VRRP group configuration example
Network requirements
•
Switch A and Switch B form a VRRP group and use the virtual IPv6 addresses 1::10/64 and
FE80::10 to provide gateway service for the LAN where Host A resides.
•
Host A learns 1::10/64 as its default gateway from the RA messages sent by the switches.
•
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.
149
Figure 38 Network diagram
Configuration procedure
1. Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] ipv6
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ipv6 address fe80::1 link-local
[SwitchA-Vlan-interface2] ipv6 address 1::1 64
# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10
# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110
# Configure Switch A to operate in preemptive mode so it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Enable Switch A to send RA messages so Host A can learn the default gateway address.
[SwitchA-Vlan-interface2] undo ipv6 nd ra halt
2. Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] ipv6
[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 1/0/5
[SwitchB-vlan2] quit
150
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local
[SwitchB-Vlan-interface2] ipv6 address 1::2 64
# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10
# Configure Switch B to operate in preemptive mode and set the preemption delay to five seconds.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Enable Switch B to send RA messages, so Host A can learn the default gateway address.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
Verifying the configuration
After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp ipv6 verbose command.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
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 : FE80::10
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
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 : 4200ms left
Auth Type : None
Virtual IP : FE80::10
1::10
Master IP : FE80::1
151
The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from Host
A to Host B.
When Switch A fails, you can still successfully ping Host B on Host A. To view the detailed information about the VRRP group on Switch B, use the display vrrp ipv6 verbose command.
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
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 : FE80::10
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::2
The output shows that when Switch A fails, Switch B takes over to forward packets from Host A to Host B.
# After Switch A resumes normal operation, use the display vrrp ipv6 verbose command to display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
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 : FE80::10
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1
The output shows that after Switch A resumes normal operation, it becomes the master to forward packets from Host A to Host B.
VRRP interface tracking configuration example
Network requirements
•
As shown in Figure 39 , Switch A and Switch B form a VRRP group and use the virtual IP addresses
1::10/64 and FE80::10 to provide gateway service for the LAN where Host A resides.
152
• Host A learns 1::10/64 as its default gateway from the RA messages sent by the switches.
•
Switch A operates as the master to forward packets from Host A to Host B. When VLAN-interface
3 used by Switch A to provide gateway service fails, Switch B takes over to forward packets for Host
A.
• Configure Switch A and Switch B to authenticate VRRP packets to prevent fabricated packets. Set the authentication mode to plain text and the authentication key to hello.
Figure 39 Network diagram
Configuration procedure
1. Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] ipv6
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ipv6 address fe80::1 link-local
[SwitchA-Vlan-interface2] ipv6 address 1::1 64
# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10
# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110
# Set the authentication mode for VRRP group 1 to simple and the authentication key to hello.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 authentication-mode simple hello
# Set the VRRP advertisement interval to 400 centiseconds.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 timer advertise 400
# Configure Switch A to operate in preemptive mode, so it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.
153
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Configure VLAN-interface 3 as a tracked interface and set the reduced priority to 30 so when
VLAN-interface 3 fails, the priority of Switch A drops below 100 and Switch B takes over.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 track interface vlan-interface 3 reduced
30
# Enable Switch A to send RA messages so Host A can learn the default gateway address.
[SwitchA-Vlan-interface2] undo ipv6 nd ra halt
2. Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] ipv6
[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local
[SwitchB-Vlan-interface2] ipv6 address 1::2 64
# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10
# Set the authentication mode for VRRP group 1 to simple and the authentication key to hello.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 authentication-mode simple hello
# Set the VRRP advertisement interval to 400 centiseconds.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 timer advertise 400
# Configure Switch B to operate in preemptive mode, so it B can become the master after the priority of Switch A drops below 100. Configure the preemption delay as five seconds to avoid frequent status switchover.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Enable Switch B to send RA messages so Host A can learn the default gateway address.
[SwitchB-Vlan-interface2] undo ipv6 nd ra halt
Verifying the configuration
After the configuration, Host B can be pinged successfully on Host A. To verify the configuration, use the display vrrp ipv6 verbose command.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 400
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 5
Auth Type : Simple Key : ******
Virtual IP : FE80::10
154
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1
VRRP Track Information:
Track Interface: Vlan3 State : Up Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 400
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 5
Become Master : 4200ms left
Auth Type : Simple Key : ******
Virtual IP : FE80::10
1::10
Master IP : FE80::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.
When interface VLAN-interface 3 on Switch A is not available, you can ping Host B successfully on Host
A. To view the detailed information about the VRRP group, use the display vrrp ipv6 verbose command.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 400
Admin Status : Up State : Backup
Config Pri : 110 Running Pri : 80
Preempt Mode : Yes Delay Time : 5
Become Master : 4200ms left
Auth Type : Simple Key : ******
Virtual IP : FE80::10
1::10
Master IP : FE80::2
VRRP Track Information:
Track Interface: Vlan3 State : Down Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
155
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 400
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 5
Auth Type : Simple Key : ******
Virtual IP : FE80::10
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::2
The output shows that when VLAN-interface 3 on Switch A is not available, the priority of Switch A is reduced to 80, and Switch A becomes the backup. Switch B becomes the master and packets sent from
Host A to Host B are forwarded by Switch B.
VRRP with multiple VLANs configuration example
Network requirements
•
, Switch A and Switch B form two VRRP groups. VRRP group 1 uses virtual
IPv6 addresses 1::10/64 and FE80::10 to provide gateway service for hosts in VLAN 2, and VRRP group 2 uses virtual IPv6 addresses 2::10/64 and FE90::10 to provide gateway service for hosts in
VLAN 3.
•
Hosts in VLAN 2 learn 1::10/64 as their default gateway and hosts in VLAN 3 learn 2::10/64 as their default gateway from the RA messages sent by the switches.
•
Assign Switch A higher priority than Switch B in VRRP group 1 but 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 40 Network diagram
156
Configuration procedure
1. Configure Switch A:
# Configure VLAN 2.
<SwitchA> system-view
[SwitchA] ipv6
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ipv6 address fe80::1 link-local
[SwitchA-Vlan-interface2] ipv6 address 1::1 64
# Create VRRP group 1 and set its virtual IPv6 addresses to FE80::10 to 1::10.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10
# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master in the group.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110
[SwitchA-Vlan-interface2] quit
# Enable Switch A to send RA messages so hosts in VLAN 2 can learn the default gateway address.
[SwitchA-Vlan-interface2] undo ipv6 nd ra halt
[SwitchA-Vlan-interface2] quit
# Configure VLAN 3.
[SwitchA] vlan 3
[SwitchA-vlan3] port gigabitethernet 1/0/6
[SwitchA-vlan3] quit
[SwitchA] interface vlan-interface 3
[SwitchA-Vlan-interface3] ipv6 address fe90::1 link-local
[SwitchA-Vlan-interface3] ipv6 address 2::1 64
# Create VRRP group 2 and set its virtual IPv6 addresses to FE90::10 and 2::10.
[SwitchA-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip fe90::10 link-local
[SwitchA-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip 2::10
# Enable Switch A to send RA messages so hosts in VLAN 3 can learn the default gateway address.
[SwitchA-Vlan-interface3] undo ipv6 nd ra halt
2. Configure Switch B:
# Configure VLAN 2.
<SwitchB> system-view
[SwitchB] ipv6
[SwitchB-vlan2] port gigabitethernet 1/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local
[SwitchB-Vlan-interface2] ipv6 address 1::2 64
# Create VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local
157
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10
[SwitchB-Vlan-interface2] quit
# Enable Switch B to send RA messages so hosts in VLAN 2 can learn the default gateway address.
[SwitchB-Vlan-interface2] undo ipv6 nd ra halt
[SwitchB-Vlan-interface2] quit
# Configure VLAN 3.
[SwitchB] vlan 3
[SwitchB-vlan3] port gigabitethernet 1/0/6
[SwitchB-vlan3] quit
[SwitchB] interface vlan-interface 3
[SwitchB-Vlan-interface3] ipv6 address fe90::2 link-local
[SwitchB-Vlan-interface3] ipv6 address 2::2 64
# Create VRRP group 2 and set its virtual IPv6 addresses to FE90::10 and 2::10.
[SwitchB-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip fe90::10 link-local
[SwitchB-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip 2::10
# 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 ipv6 vrid 2 priority 110
# Enable Switch B to send RA messages, so hosts in VLAN 3 can learn the default gateway address.
[SwitchB-Vlan-interface3] undo ipv6 nd ra halt
Verifying the configuration
To verify the configuration, use the display vrrp ipv6 verbose command.
# Display detailed information about the VRRP groups on Switch A.
[SwitchA-Vlan-interface3] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
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 : FE80::10
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1
Interface Vlan-interface3
VRID : 2 Adver Timer : 100
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Become Master : 2200ms left
158
Auth Type : None
Virtual IP : FE90::10
2::10
Master IP : FE90::2
# Display detailed information about the VRRP groups on Switch B.
[SwitchB-Vlan-interface3] display vrrp ipv6 verbose
IPv6 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
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 : 2200ms left
Auth Type : None
Virtual IP : FE80::10
1::10
Master IP : FE80::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 : FE90::10
2::10
Virtual MAC : 0000-5e00-0202
Master IP : FE90::2
The output shows that Switch A is operating as the master in VRRP group 1 to forward Internet traffic for the hosts that use the default gateway 1::10/64, and Switch B is operating as the master in VRRP group
2 to forward Internet traffic for the hosts that use the default gateway 2::10/64.
Troubleshooting VRRP
The screen frequently displays error prompts
Symptom
The screen frequently displays error prompts.
Analysis
This error is probably caused by:
•
Inconsistent configuration of the devices in the VRRP group.
•
A device is attempting to send illegitimate VRRP packets.
159
Solution
•
In the first case, modify the configuration.
•
In the latter case, resort to non-technical measures.
Multiple masters are present in a VRRP group
Symptom
Multiple masters are present in a VRRP group.
Analysis
•
Multiple masters coexist for a short period. This is normal and requires no manual intervention.
•
Multiple masters coexist for a long period. This is because devices in the VRRP group cannot receive
VRRP packets, or the received VRRP packets are illegal.
Solution
Ping between these masters, and do the following:
•
If the ping fails, verify network connectivity.
• If the ping succeeds, verify that their configurations are consistent in terms of number of virtual IP addresses, virtual IP addresses, advertisement interval, and authentication.
Frequent VRRP state transition
Symptom
Frequent VRRP state transition.
Analysis
The VRRP advertisement interval is set too short.
Solution
Increase the interval for sending VRRP advertisements or configure a preemption delay.
160
Configuring BFD
BFD provides a general-purpose, standard, medium-independent, and protocol-independent fast failure detection mechanism. This chapter describes the BFD working mechanism and configuration procedure.
Overview
Fault detection methods include:
•
Hardware detection—Detects link failures by sending hardware detection signals, such as SDH alarms.
Hardware detection can quickly detect link failures, but is media dependent.
• Hello mechanism—Devices can use the hello mechanism of a routing protocol to detect link failures.
The hello mechanism takes seconds to detect a link failure. However, that detection rate is too slow for voice services and other delay-sensitive services. It is also too slow for high-speed data transmission, such as Gigabit data transmission, where a detection rate slower than one second can cause serious data loss.
•
Other detection methods—Some protocols provide dedicated detection mechanisms, which however, cannot be deployed for inter-system communications.
BFD provides a single mechanism to quickly detect and monitor the connectivity of links or IP forwarding in networks.
How BFD works
BFD can uniformly and quickly detect the failures of the bidirectional forwarding paths between two routers for protocols such as routing protocols and MPLS.
BFD provides no neighbor discovery mechanism. Protocols that BFD services notify BFD of routers to which it needs to establish sessions. After a session is established, if no BFD control packet is received from the peer within the negotiated BFD interval, BFD notifies a failure to the protocol, which then takes appropriate measures.
Establishing a BFD session
A BFD session begins with neighbor discovery on the network.
Figure 41 BFD session establishment (on OSPF routers)
As shown in Figure 41 , BFD sessions are established as follows:
161
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.
Detecting BFD faults
Figure 42 BFD fault detection (on OSPF routers)
3
4
2
3
1
Router A
5
Router B
Fault
BFD neighbors
BFD notifies the OSPF link failure
Backup link
OSPF neighbors
As shown in Figure 42 , when BFD detects a fault, the following process occurs:
1. BFD detects a link failure.
2. BFD clears the neighbor session.
3. BFD notifies the protocol of the failure.
4. The protocol terminates the neighborship on the link.
5. If a backup link is available, the protocol uses it to forward packets.
NOTE:
No detection time resolution is defined in the BFD draft. Most devices supporting BFD provide detection measured in milliseconds.
BFD detection methods
Detection methods for BFD include:
•
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 can be overlapped.
•
Bidirectional detection—Sends detection packets at two sides of a bidirectional link to detect the bidirectional link status, finding link failures in milliseconds. (BFD LSP detection is a special case, in which BFD control packets are sent in one direction, and the peer device reports the link status through other links.)
BFD session modes
Session modes for BFD include:
• Control packet mode—Both ends of the link exchange BFD control packets to monitor link status.
162
•
Echo packet mode—One end of the link sends Echo packets to the other end, which then forwards the packets back to the originating end. This mode monitors link status in both directions.
BFD operating modes
Before a BFD session is established, BFD has two operating modes, active and passive.
•
Active mode—BFD actively sends BFD control packets regardless of whether any BFD control packet is received from the peer.
• Passive mode—BFD does not send control packets until a BFD control packet is received from the peer.
At least one end must operate in active mode for a BFD session to be established.
After a BFD session is established, both ends 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.
When a BFD session is maintained by sending Echo packets, the session is independent of the operating mode.
Dynamic BFD parameter changes
After a BFD session is established, both ends can negotiate the related BFD parameters, such as the minimum transmit interval, minimum receive interval, and initialization mode. After that, both ends use the negotiated parameters, without affecting the current session state.
BFD packet format
BFD control packets are encapsulated into UDP packets with port number 3784 for single-hop detection or port number 4784 for multi-hop detection (also can be 3784 based on the configuration task.) BFD echo packets have a similar format as BFD control packets with UDP port number 3785 except that the Desired
Min TX Interval and Required Min RX Interval fields are null. Figure 43
illustrates the packet format.
Figure 43 BFD packet format
•
Vers—Protocol version. The protocol version is 1.
•
Diag—This bit indicates the reason for the last transition of the local session from up to some other state.
lists the states.
Table 19 Diag bit values
Diag Description
1
2
Control detection time expired.
Echo function failed.
163
Diag Description
3 Neighbor signaled session down.
4 Forwarding plane reset.
8 Reverse concatenated path down.
9–31 Reserved for future use.
•
State (Sta)—Current BFD session state. Its value can be 0 for AdminDown, 1 for Down, 2 for Init, and
3 for Up.
• Poll (P)—If set, the transmitting system is requesting verification of connectivity, or of a parameter change. If clear, the transmitting system is not requesting verification of the configuration.
•
Final (F)—If set, the transmitting system is responding to a received BFD control packet that had the Poll
(P) bit set. If clear, the transmitting system is not responding to a Poll.
• Control Plane Independent (C)—If set, the transmitting system's BFD implementation does not share fate with its control plane. BFD is implemented in the forwarding plane and can continue to function through disruptions in the control plane. If clear, the transmitting system's BFD implementation shares fate with its control plane.
• Authentication Present (A)—If set, the Authentication Section is present and the session is to be authenticated.
•
Demand (D)—If set, Demand mode is active in the transmitting system. The system would like to operate in Demand mode, knows that the session is up in both directions, and is directing the remote system to stop the periodic transmission of BFD control packets. If clear, Demand mode is not active in the transmitting system.
• Reserved (R)—This byte must be set to zero on transmit, and ignored on receipt.
• Detect Mult—Detection time multiplier.
•
Length—Length of the BFD control packet, in bytes.
•
My Discriminator—A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems.
• Your Discriminator—The discriminator received from the remote system. This field reflects back the received value of My Discriminator, or is 0 if that value is unknown.
•
Desired Min TX Interval—The minimum interval (in milliseconds) that the local system would like to use when transmitting BFD control packets. The value zero is reserved.
•
Required Min RX Interval—The minimum interval (in milliseconds) between received BFD control packets that this system is capable of supporting. If this value is zero, the transmitting system does not want the remote system to send any periodic BFD control packets.
• Required Min Echo RX Interval—The minimum interval (in milliseconds) between received BFD echo packets that this system is capable of supporting. If this value is zero, the transmitting system does not support the receipt of BFD echo packets.
• Auth Type—The authentication type in use, if the Authentication Present (A) bit is set.
• Auth Len—The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields.
164
Supported features
• OSPF. For more information, see Layer 3—IP Routing Configuration Guide.
• OSPFv3. For more information, see Layer 3—IP Routing Configuration Guide.
•
IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.
•
IPv6 IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.
• RIP. For more information, see Layer 3—IP Routing Configuration Guide.
• Static routing. For more information, see Layer 3—IP Routing Configuration Guide.
•
BGP. For more information, see Layer 3—IP Routing Configuration Guide.
•
IPv6 BGP. For more information, see Layer 3—IP Routing Configuration Guide.
• PIM. For more information, see IP Multicast Configuration Guide.
• MPLS. For more information, see MPLS Configuration Guide.
•
Track. For more information, see "
•
IP fast reroute (FRR). IP FRR is supported by OSPF, RIP, IS-IS and static routing. For more information, see
Layer 3—IP Routing Configuration Guide.
Protocols and standards
•
RFC 5880, Bidirectional Forwarding Detection (BFD)
• RFC 5881, Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
•
RFC 5882, Generic Application of Bidirectional Forwarding Detection (BFD)
•
RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths
•
RFC 5884, Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
• RFC 5885, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV)
Configuring BFD basic functions
The BFD basic function configuration is the basis for configuring BFD for other protocols.
Before configuring BFD basic functions, complete the following tasks:
• Configure the network layer addresses of the interfaces so that adjacent nodes are reachable to each other at the network layer.
The term "interface" in BFD 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).
• Configure the routing protocols that support BFD.
To configure BFD basic functions:
Step Command
1. Enter system view. system-view
2. Specify the mode for establishing a BFD session. bfd session init-mode { active | passive }
Remarks
N/A
Optional.
The default is active.
165
Step Command
3. Configure the destination port number for multi-hop BFD control packets. bfd multi-hop destination-port
port-number
Remarks
Optional.
The default is 4784.
4. Configure the source IP address of echo packets. bfd echo-source-ip ip-address
Optional.
The source IP address should not be on the same network segment as any local interface's IP address.
Otherwise, a large number of
ICMP redirect packets may be sent from the peer, resulting in link congestion.
5. Enter interface view. interface interface-type
interface-number
N/A
6. Configure the minimum interval for receiving BFD echo packets. bfd min-echo-receive-interval
value
7. Configure the minimum interval for transmitting BFD control packets. bfd min-transmit-interval value
Optional.
For more information, see the description of the Required Min
Echo RX Interval field in "
The default is 400 milliseconds.
Optional.
For more information, see the description of the Desired Min TX
Interval field in " BFD packet format
."
The default is 400 milliseconds.
8. Configure the minimum interval for receiving BFD control packets. bfd min-receive-interval value
Optional.
For more information, see the description of the Required Min RX
Interval field in " BFD packet format
."
The default is 400 milliseconds.
9. Configure the detection time multiplier. bfd detect-multiplier value
Optional.
For more information, see the description of the Detect Mult field in "
."
5 by default.
300 milliseconds, and Detect Mult as 5 on Router A, and then configure the Desired Min TX Interval as 150 milliseconds, Required Min RX Interval as 400 milliseconds, and Detect Mult as 10 on Router B.
•
The actual transmitting interval on Router A is 400 milliseconds, which is the greater value between the minimum interval for transmitting BFD control packets on Router A (100 milliseconds) and the minimum interval for receiving BFD control packets on Router B (400 milliseconds).
• The actual transmitting interval on Router B is 300 milliseconds, which is the greater value between the minimum interval for transmitting BFD control packets on Router B (150 milliseconds) and the minimum interval for receiving BFD control packets on Router A (300 milliseconds).
166
•
The actual detection time on Router A is 3000 milliseconds, which is 10 × 300 milliseconds (Detect
Mult on Router B × actual transmitting interval on Router B).
• The actual detection time on Router B is 2000 milliseconds, which is 5 × 400 milliseconds (Detect Mult on Router A × actual transmitting interval on Router A).
Displaying and maintaining BFD
Task Command
Display information about
BFD-enabled interfaces. display bfd interface [ verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Display information about enabled
BFD debugging.
Display BFD session information (in standalone mode).
Display BFD session information (in
IRF mode).
Remarks
Available in any view. display bfd debugging-switches [ |
{ begin | exclude | include }
regular-expression ]
Available in any view. display bfd session [ slot slot-number
[ all | verbose ] | verbose ] [ | { begin | exclude | include } regular-expression ]
Available in any view. display bfd session [ chassis
chassis-number slot slot-number [ all | verbose ] | verbose ] [ | { begin | exclude | include } regular-expression ]
Available in any view.
Clear BFD session statistics (in standalone mode). reset bfd session statistics [ slot
slot-number ]
Available in user view.
Clear BFD session statistics (in IRF mode). reset bfd session statistics [ chassis
chassis-number slot slot-number ]
Available in user view.
167
Configuring track
This chapter describes how to configure track.
Track overview
The track module implements collaboration by establishing associations between application modules
and detection modules, as shown in Figure 44
.
Collaboration is enabled after you associate the track module with a detection module and an application module, respectively. The detection module monitors 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, and the application module takes actions when the tracked object changes its state.
Figure 44 Collaboration through the track module
Detection modules
Application modules
NQA
Associates with a detection entry
BFD
Interface management
Sends the detection result
Track module
Associates with a track entry
Sends the track entry status
VRRP
Static routing
Policy-based routing
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, which then changes the status of the track entry:
•
If the tracked object functions normally, such as the target interface is up or the target network is reachable, the state of the track entry is Positive.
• If the tracked object functions abnormally, such as 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, such as the NQA test group that is associated with the track entry does not exist, the state of the track entry is Invalid.
The following detection modules can be associated with the track module:
• NQA
168
• BFD
•
Interface management module
Collaboration between the track module and an application module
When the status of the track entry changes, the track module notifies the associated application module, which then takes proper actions.
The following application modules can be associated with the track module:
•
VRRP
• Static routing
•
Policy-based routing
In some cases, when the status of a track entry changes, if the track module immediately notifies the application modules, communication may be interrupted because routes cannot be recovered in time.
For example, the master in a VRRP group monitors the uplink interface through the track module. When the uplink interface fails, the track module notifies the master to reduce its priority so that a backup with a higher priority can preempt as the master to forward packets. When the uplink interface recovers, if the track module immediately notifies the original master to restore its priority, the master immediately will forward packets. However, the uplink route has not been recovered yet, which may result in packet forwarding failure. Configure the track module to notify the application modules of the track entry status change after a specified delay time.
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 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.
Task Remarks
Associating the track module with a detection module
Associating track with interface management
Required.
Use one of the approaches.
169
Task Remarks
Associating the track module with an application module
Associating track with static routing
Required.
Use one of the approaches.
Associating the track module with a detection module
This section provides instructions for associating the track module with a detection module.
Associating track with NQA
An NQA test group periodically detects whether a destination is reachable or whether the TCP connection to a TCP server can be set up. When associated with a track entry, an NQA test group functions as follows:
• If the consecutive failures reach the specified threshold, the NQA module tells the track module that the tracked object is unreachable. The track module then sets the track entry to Negative state.
•
If the specified threshold is not reached, the NQA module tells the track module that the tracked object functions normally. 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
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 } * ]
Remarks
N/A
By default, no track entry is created.
If the specified NQA test group or the reaction entry in the track entry does not exist, the status of the track entry is Invalid.
Associating track with BFD
BFD supports the control packet mode and echo packet mode. Only echo-mode BFD can be associated with a track entry.
When associated with a track entry, the BFD functions as follows:
•
If BFD detects that the link fails, it informs the track entry of the link failure. The track module then sets the track entry to Negative state.
• If BFD detects that the link is normal, the track module sets the track entry to Positive state.
For more information about BFD, see " Configuring BFD ."
170
Configuration prerequisites
Before you associate track with BFD, configure the source address of the BFD echo packets.
Configuration procedure
To associate track with BFD:
Step Command
1. Enter system view. 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. 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 } * ]
Remarks
N/A
By default, no track entry is created.
When you associate track with
BFD, 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 physical status or network-layer protocol status of the interface. When associated with a track entry, the interface management module functions as follows:
• When the physical 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 physical 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 Command
1. Enter system view. system-view
2. Associating track with interface management.
•
Create a track entry, associate it with the interface management module to monitor the physical 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 | ipv6 } [ delay
{ negative negative-time | positive positive-time }
* ]
Remarks
N/A
Use either approach.
By default, no track entry is created.
171
Associating the track module with an application module
This section provides instructions for associating the track module with an application module.
Associating track with VRRP
VRRP is an error-tolerant protocol. It adds a group of routers that can act as network gateways to a VRRP group, which forms a virtual router. Routers in the VRRP group elect the master acting as the gateway according to their priorities. A router with a higher priority is more likely to become the master. The other routers function as the backups. When the master fails, to ensure that the hosts in the network segment can uninterruptedly communicate with external networks, the backups in the VRRP group elect a new gateway to undertake the responsibility of the failed master. For more information about VRRP, see
"
You can associate the track module with a VRRP group to implement the following objects:
• 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 cannot be 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 specified value. This allows a higher priority router in the VRRP group to become the master to maintain 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 immediately switches to the master to maintain normal communication.
Configuration restrictions
•
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 Invalid, the associated router automatically restores its priority.
•
You can associate a nonexistent track entry with a VRRP group. The association takes effect only after you create the track entry with the track command.
Configuration procedure
To associate track with VRRP group:
Step Command
1. Enter system view. system-view
2. Enter interface view.
3. Create a VRRP group and configure its virtual IP address. interface interface-type
interface-number vrrp vrid virtual-router-id virtual-ip
virtual-address
Remarks
N/A
N/A
By default, no VRRP group is created.
172
Step Command
4. Associate a track entry with a
VRRP group. vrrp [ ipv6 ] vrid virtual-router-id track track-entry-number [ reduced
priority-reduced | switchover ]
Remarks
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 examine the reachability of a static route in real time, establish an association between the 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 examine the reachability of the static route according to the status of the track entry.
•
Positive—The next hop of the static route is reachable, and the configured static route is valid.
• Negative—The next hop of the static route is not reachable, and the configured static route is invalid.
•
Invalid—The reachability of the next hop of the static route is unknown, and the static route is valid.
Configuration restrictions
• You can associate a nonexistent track entry with a static route. The association takes effect only after you create the track entry with the track command.
•
If the track module detects the next hop accessibility of the static route in a private network through
NQA, the VPN instance name of the next hop of the static route must be consistent with that configured for the NQA test group. Otherwise, the accessibility detection cannot function properly.
•
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 can be considered invalid.
Configuration procedure
To associate track with static routing:
Step Command
1. Enter system view. system-view
Remarks
N/A
173
Step Command
2. Associate the static route with a track entry to examine the reachability of the next hop.
•
Approach 1: ip route-static dest-address { mask |
mask-length } { next-hop-address | vpn-instance d-vpn-instance-name
next-hop-address } track track-entry-number
[ preference preference-value ] [ tag
tag-value ] [ description description-text ]
•
Approach 2: ip route-static vpn-instance
s-vpn-instance-name&<1-6> dest-address
{ mask | mask-length } { next-hop-address
[ public ] track track-entry-number | vpn-instance d-vpn-instance-name
next-hop-address track track-entry-number }
[ preference preference-value ] [ tag
tag-value ] [ description description-text ]
Remarks
Use either approach.
By default, this command is not configured.
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 (based on the source address and other criteria) to route packets. For more information about PBR, see Layer 3—IP Routing Configuration
Guide.
PBR cannot detect the availability of any action taken on packets. When an action is not available, packets processed by the action may be discarded. For example, configure PBR to forward packets that match certain criteria through a specific interface. When the specified interface fails, PBR cannot sense the failure, and continues to forward matching packets out of the interface.
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.
• Positive—The object is available and the apply clause is valid.
•
Negative—The object is not available and the apply clause is invalid.
•
Invalid—The apply clause is valid.
The following objects can be associated with a track entry:
• Next hop
•
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
To associate track with PBR:
174
Step Command
1. Enter system view.
2. Create a policy or policy node and enter PBR policy node view. system-view policy-based-route policy-name [ deny | permit ] node node-number
3. Define an ACL match criterion.
4. Associate track with PBR.
Remarks
N/A
N/A if-match acl acl-number
Optional.
By default, no packets are filtered.
•
Set the next hop and associate it with a track entry: apply ip-address next-hop ip-address
[ direct ] [ track track-entry-number ]
[ ip-address [ direct ] [ track
track-entry-number ] ]
•
Set the default next hop, and associate it with a track entry: apply ip-address default next-hop
ip-address [ track track-entry-number ]
[ ip-address [ track track-entry-number ] ]
Use either command.
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.
Displaying and maintaining track entries
Display information about the specified or all track entries. display track { track-entry-number | all } [ | { begin | exclude | include } regular-expression ]
Available in any view.
Track configuration examples
This section provides track configuration examples.
VRRP-track-NQA collaboration configuration example (the master monitors the uplink)
Network requirements
•
, 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 form a VRRP group, which uses the virtual IP address 10.1.1.10.
•
When Switch A is operating properly, packets from Host A to Host B are forwarded through Switch
A. When VRRP finds that a fault occurs on the uplink of Switch A through NQA, packets from Host
A to Host B are forwarded through Switch B.
175
Figure 45 Network diagram
Configuration procedure
1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each
VLAN interface as shown in
. (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 ms.
[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.
176
[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# Configure the master to send VRRP packets at an interval of five seconds.
[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 5
# Configure Switch A to operate in preemptive mode and set the preemption delay to five 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 five seconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 timer advertise 5
# Configure Switch B to operate in preemptive mode and set the preemption delay to five 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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 5
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 Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
177
VRID : 1 Adver Timer : 5
Admin Status : Up State : Backup
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 Switch A is operating as the master in VRRP group 1 to send packets from Host A to Host B, and Switch B is operating as a backup.
When a fault occurs 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 occurs on the link between
Switch A and Switch C.
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 5
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 occurs on the link between
Switch A and Switch C.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 5
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
178
The output shows that when a fault occurs 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 to send packets from Host A to Host B.
Configuring BFD for a VRRP backup to monitor the master (the master monitors the uplink)
Network requirements
• As shown in
, Switch A and Switch B form VRRP group 1, which uses the virtual IP address
192.168.0.10.
•
The default gateway of the hosts in the LAN is 192.168.0.10. When Switch A is operating properly, 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 BFD is not configured, when the master in a VRRP group fails, the backup cannot become the master until the configured timeout timer expires. The timeout is generally three to four seconds, which makes the switchover slow. 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 46 Network diagram
Internet
Switch A
Master
Vlan-int2
192.168.0.101/24
Virtual router
Virtual IP address:
192.168.0.10
Switch B
Backup
Vlan-int2
192.168.0.102/24
L2 switch
BFD probe packets
VRRP packets
Configuration procedure
1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each
VLAN interface as shown in
. (Details not shown.)
2. On Switch A, 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> system-view
179
[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] return
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 examine 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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Become Master : 2200ms left
Auth Type : None
180
Virtual IP : 192.168.0.10
Master IP : 192.168.0.101
VRRP Track Information:
Track Object : 1 State : Positive Switchover
# Display information about track entry 1 on Switch B.
<SwitchB> display track 1
Track ID: 1
Status: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
BFD session:
Packet type: Echo
Interface : Vlan-interface2
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 2008 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 2008 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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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
181
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.
Configuring BFD for the VRRP master to monitor the uplinks
Network requirements
•
As shown in Figure 47 , Switch A and Switch B form VRRP group 1, which uses the virtual IP address
192.168.0.10.
•
The default gateway of the hosts in the LAN is 192.168.0.10.
•
When Switch A is operating properly, 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 47 Network diagram
Internet
Master uplink device
Vlan-int3
1.1.1.2/24
Uplink
Vlan-int3
1.1.1.1/24
Switch A
Master
Vlan-int2
192.168.0.101/24
Virtual router
Virtual IP address:
192.168.0.10
Backup uplink device
Uplink
Switch B
Backup
Vlan-int2
192.168.0.102/24
L2 switch
VRRP packets
Configuration procedure
1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each
VLAN interface as shown in
. (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 examine 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
182
BFD probe packets
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, and configure VRRP group 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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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
Status: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
BFD session:
Packet type: Echo
Interface : Vlan-interface2
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
183
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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
Status: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
BFD session:
Packet type: Echo
Interface : Vlan-interface2
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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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 Standby Information:
184
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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
The output shows that when Switch A detects that the uplink fails through BFD, it decreases its priority by
20 to make sure Switch B can preempt as the master.
Static routing-track-NQA collaboration configuration example
Network requirements
As shown in Figure 48 , Switch A, Switch B, Switch C, and Switch D are connected to two segments
20.1.1.0/24 and 30.1.1.0/24. Configure static routes on these switches 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-NQA collaboration to determine whether the master route is available in real time. If the master route is unavailable, the backup route takes effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C.
Similarly, Switch D 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 D, 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 D forwards packets to 20.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-NQA collaboration to determine whether the master route is available in real time. If the master route is unavailable, the backup route takes effect, and Switch D forwards packets to 20.1.1.0/24 through Switch C.
185
Figure 48 Network diagram
Configuration procedure
1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each
VLAN interface as shown in
. (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.1.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.1.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 a static route to 10.2.1.4, with the address of the next hop as 10.1.1.2.
[SwitchA] ip route-static 10.2.1.4 24 10.1.1.2
# Create an NQA test group with the administrator admin and the operation tag test.
[SwitchA] nqa entry admin test
# Configure the test type as ICMP-echo.
[SwitchA-nqa-admin-test] type icmp-echo
# Configure the destination address of the test as 10.2.1.4 and the next hop address as 10.1.1.2 to examine the connectivity of the path from Switch A to Switch B and then to Switch D through
NQA.
[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.2.1.4
[SwitchA-nqa-admin-test-icmp-echo] next-hop 10.1.1.2
# Configure the test frequency as 100 ms.
[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
186
# Start the NQA test.
[SwitchA] nqa schedule admin test start-time now lifetime forever
# 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
3. Configure Switch B:
# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.2.1.4.
<SwitchB> system-view
[SwitchB] ip route-static 30.1.1.0 24 10.2.1.4
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.1.1.1.
[SwitchB] ip route-static 20.1.1.0 24 10.1.1.1
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.4.
<SwitchC> system-view
[SwitchC] ip route-static 30.1.1.0 24 10.4.1.4
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.3.1.1.
[SwitchC] ip route-static 20.1.1.0 24 10.3.1.1
5. Configure Switch D:
# Configure a static route to 20.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.
<SwitchD> system-view
[SwitchD] ip route-static 20.1.1.0 24 10.2.1.2 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.
[SwitchD] ip route-static 20.1.1.0 24 10.4.1.3 preference 80
# Configure a static route to 10.1.1.1, with the address of the next hop as 10.2.1.2.
[SwitchD] ip route-static 10.1.1.1 24 10.2.1.2
# Create an NQA test group with the administrator admin and the operation tag test.
[SwitchD] nqa entry admin test
# Configure the test type as ICMP-echo.
[SwitchD-nqa-admin-test] type icmp-echo
# Configure the destination address of the test as 10.1.1.1 and the next hop address as 10.2.1.2 to examine the connectivity of the path from Switch D to Switch B and then to Switch A through
NQA.
[SwitchD-nqa-admin-test-icmp-echo] destination ip 10.1.1.1
[SwitchD-nqa-admin-test-icmp-echo] next-hop 10.2.1.2
# Configure the test frequency as 100 ms.
[SwitchD-nqa-admin-test-icmp-echo] frequency 100
# Configure reaction entry 1, specifying that five consecutive probe failures trigger the static routing-track-NQA collaboration.
[SwitchD-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only
[SwitchD-nqa-admin-test-icmp-echo] quit
# Start the NQA test.
[SwitchD] nqa schedule admin test start-time now lifetime forever
187
# 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).
[SwitchD] track 1 nqa entry admin test reaction 1
Verifying the configuration
# Display information about the track entry on Switch A.
[SwitchA] display track all
Track ID: 1
Status: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
NQA entry: admin test
Reaction: 1
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 10 Routes : 10
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Static 60 0 10.1.1.2 Vlan2
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 Vlan6
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.0/24 Static 60 0 10.1.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 NQA test result: the master route is available (the status of the track entry is Positive), and 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
Status: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
NQA entry: admin test
Reaction: 1
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Routing Tables: Public
188
Destinations : 10 Routes : 10
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Static 60 0 10.1.1.2 Vlan2
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 Vlan6
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 NQA test result: the master route is unavailable. (The status of the track entry is
Negative.) The backup static route takes effect and Switch A forwards packets to 30.1.1.0/24 through
Switch C.
# 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
--- 30.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
# The output on Switch D 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
--- 20.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
189
Static routing-track-BFD collaboration configuration example
Network requirements
As shown in
Figure 49 , 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. 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. Switch B forwards packets to 20.1.1.0/24 through Switch C and Switch A.
Figure 49 Network diagram
Configuration procedure
1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each
VLAN interface as shown in
. (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
190
# 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. Examine whether Switch A can be interoperated with the next hop (Switch B) of static route.
[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 examine 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
[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
Status: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
BFD Session:
Packet type: Echo
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 Routes : 9
191
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 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 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) and 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 of the track entry on Switch A.
[SwitchA] display track all
Track ID: 1
Status: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
BFD Session:
Packet type: Echo
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 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 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), the backup static route takes effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C and Switch B.
192
# 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
--- 30.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 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
--- 20.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
VRRP-track-interface management collaboration configuration example (the master monitors the uplink interface)
Network requirements
•
As shown in
, 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 form a VRRP group, which uses the virtual IP address 10.1.1.10.
•
When operating properly, Switch A sends packets from Host A to Host B. When VRRP detects that a fault occurs on the uplink interface of Switch A through the interface management module, Switch
B sends packets from Host A to Host B.
193
Figure 50 Network diagram
Configuration procedure
1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each
VLAN interface as shown in
. (Details not shown.)
2. On Switch A, configure track entry 1 and associate it with the physical 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. On Switch B, create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.
<SwitchB> system-view
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
Verifying the configuration
After configuration, ping Host B on Host A. 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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Master
194
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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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.
[SwitchA-Vlan-interface3] display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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:
195
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 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
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.
196
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
197
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
[ ]
{ x | y | ... }
[ x | y | ... ]
{ x | y | ... } *
[ x | y | ... ] *
&<1-n>
Italic text represents arguments that you replace with actual values.
Square brackets enclose syntax choices (keywords or arguments) that are optional.
Braces enclose a set of required syntax choices separated by vertical bars, from which you select one.
Square brackets enclose a set of optional syntax choices separated by vertical bars, from which you select one or none.
Asterisk-marked braces enclose a set of required syntax choices separated by vertical bars, from which you select at least one.
Asterisk-marked square brackets enclose optional syntax choices separated by vertical bars, from which you select one choice, multiple choices, or none.
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
Symbols
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
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
NOTE
An alert that calls attention to essential information.
An alert that contains additional or supplementary information.
TIP
An alert that provides helpful information.
198
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.
Port numbering in examples
The port numbers in this document are for illustration only and might be unavailable on your device.
199
Index
802.1 (configuring CFD protocol version), 21 activating RRPP domain, 64 active operation mode (BFD), 163 switchover (high availability technologies), 3 switchover configuration, 5 address learning (Smart Link), 99 advertisement interval timer (VRRP), 127 link state (DLDP), 32 setting DLDP send advertisement packet interval,
39 alarm (Ethernet OAM fault detection), 8 application associating module with track, 172 associating track with PBR, 174 associating track with static routing, 173 associating track with VRRP, 172
IPv4 VRRP, 130 track, 169 assistant-edge node
RRPP type, 51 specifying RRPP, 63 associating track module with detection module, 170 track with application module, 172 track with BFD, 170 track with interface management, 171 track with NQA, 170 track with PBR, 174 track with static routing, 173 track with VRRP, 172 association maintenance (CFD), 18 attribute
IPv4 VRRP packet, 134
IPv6 VRRP packet, 139 authenticating configuring DLDP authentication, 41
DLDP non-authentication mode, 34
DLDP plain text authentication mode, 34
MD5 authentication mode (DLDP), 34
VRRP authentication mode, 127 auto mode (DLDP port shutdown), 40 automatic shut down (unidirectional links), 42 auto-recovery (DLDP link mechanism), 37 backup mechanism (Smart Link), 99
200
BFD active operation mode, 163 associating with track, 170 basic configuration, 165 bidirectional detection, 162 configuration, 161 configuring for VRRP backup monitoring, 179 configuring for VRRP uplink monitoring, 182 configuring static routing-track-BFD collaboration,
190 control packet mode, 162 control packet session mode, 162 detection method, 162 displaying, 167 dynamic parameter change, 163 echo packet mode, 162 echo packet session mode, 162 establishing session, 161 fault detection, 162 high availability fault detection technologies, 2 how it works, 161 maintaining, 167 multi-hop detection, 162 packet format, 163, 166 passive operation mode, 163 protocols and standards, 165 single-hop detection, 162 supported features, 165 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183 verifying static routing-track-BFD collaboration configuration, 191
BGP
BFD supported feature, 165
IPv6 BGP (BFD supported feature), 165 bidirectional forwarding detection. See BFD broadcast (RRPP storm suppression mechanism), 54 calculating
MTBF, 1
MTTR, 1
CFD basic concepts, 17 configuration, 17, 20, 21, 26 configuring continuity check on MEP, 24
configuring function, 24 configuring linktrace on MEP, 25 configuring loopback on MEP, 25 configuring MEP, 23 configuring MIP generation rules, 23 continuity check function, 20 displaying, 26 high availability fault detection technologies, 2 linktrace function, 20 loopback function, 20 maintaining, 26 maintenance association, 18 maintenance domain, 17 maintenance point, 18
MEP list, 19 protocols and standards, 20
Smart Link-CFD continuity check collaboration,
100 verifying configuration, 29 changing BFD parameter dynamically, 163 collaborating between track and application modules, 169 between track and detection modules, 168
BFD for VRRP backup monitoring configuration,
179
BFD for VRRP uplink monitoring configuration, 182
CFD continuity check and Smart Link, 100
Monitor Link and Smart Link, 100
Smart Link collaboration mechanism, 99 static routing-track-BFD collaboration configuration,
190 static routing-track-NQA collaboration configuration, 185 track configuration, 168, 169, 175 track fundamentals, 168
VRRP-track-interface management collaboration configuration, 193
VRRP-track-NQA collaboration track configuration,
175 common port (RRPP), 52 common-flush-FDB RRPPDU type, 52 complete-flush-FDB RRPPDU type, 52 configurable MEP (CFD), 19, 23 configuring active switchover, 5 basic BFD, 165 basic CFD settings, 21
BFD, 161
BFD for VRRP backup monitoring, 179
BFD for VRRP uplink monitoring, 182
CFD, 17, 20, 26
CFD continuity check on MEP, 24
CFD function, 24
CFD linktrace on MEP, 25
CFD loopback on MEP, 25
CFD MIP generation rules, 23
CFD protocol version, 21
CFD service instances, 22
DLDP, 31, 38, 42
DLDP authentication, 41
DLDP duplex mode, 38
Ethernet interface speed (DLDP), 38
Ethernet OAM, 8, 11, 15
Ethernet OAM basic function, 11
Ethernet OAM connection detection timer, 12
Ethernet OAM errored frame event detection, 13
Ethernet OAM errored frame period event detection, 13
Ethernet OAM errored frame seconds event detection, 14
Ethernet OAM errored symbol event detection, 13
Ethernet OAM link monitoring, 12
IPv4 VRRP interface tracking, 143
IPv4 VRRP packet attribute, 134
IPv4 VRRP single group, 140
IPv4 VRRP trap function, 135
IPv4 VRRP with multiple VLANs, 147
IPv6 VRRP, 149
IPv6 VRRP interface tracking, 152
IPv6 VRRP packet attribute, 139
IPv6 VRRP preemptive mode, 138
IPv6 VRRP router priority, 138
IPv6 VRRP single group, 149
IPv6 VRRP tracking function, 138
IPv6 VRRP with multiple VLANs, 156 member port for Smart Link group, 101 member port in interface view, 102 member port in Smart Link group view, 102
MEP (CFD), 23
Monitor Link, 119, 120, 121
Monitor Link group member port, 120
Monitor Link group member port in group view,
120
Monitor Link group member port in interface view,
121 protected VLAN for Smart Link group, 101 role preemption for Smart Link group, 102
RRPP, 50, 59, 67
RRPP control VLAN, 60
RRPP dual homed rings, 74
RRPP fail timer, 64
RRPP fast detection, 65, 93
201
RRPP fast detection timer, 65
RRPP hello timer, 64
RRPP intersecting rings, 69
RRPP load balanced intersecting rings, 84
RRPP node, 62
RRPP port, 62
RRPP protected VLAN, 60
RRPP ring, 61
RRPP ring group, 66
RRPP single ring, 67
Smart Link, 97, 100, 104
Smart Link and CFD continuity check collaboration,
103
Smart Link and CFD continuity check collaboration,
113
Smart Link associated device, 103
Smart Link device, 100
Smart Link multiple groups, 109
Smart Link single group, 104 static routing-track-BFD collaboration, 190 static routing-track-NQA collaboration, 185 track, 168, 169, 175
VRRP, 125
VRRP preemptive mode, 133
VRRP router priority, 133
VRRP tracking function, 133
VRRP virtual IP address, 132
VRRP virtual IPv6 address, 136, 137
VRRP-track-interface management collaboration,
193
VRRP-track-NQA collaboration (track), 175 connection detection timer (Ethernet OAM), 12 establishing (Ethernet OAM), 9 connectivity failure detection. See CFD continuity check
CFD, 20 configuring on MEP, 24 configuring Smart Link collaboration, 103 message, 20
Smart Link collaboration, 113 control VLAN
RRPP, 51
RRPP configuration, 60 creating
CFD service instance with MD name, 22
CFD service instance without MD name, 22
IPv6 VRRP group, 136, 137
Monitor Link group, 120
RRPP domain, 59
VRRP group, 132
202 data VLAN (RRPP), 51
DelayDown
DLDP link state, 32
DLDP timer setting, 40 detecting associating track and detection modules, 170 associating track with application module, 172 associating track with BFD, 170 associating track with interface management, 171 associating track with NQA, 170 associating track with PBR, 174 associating track with static routing, 173 associating track with VRRP, 172
BFD configuration, 161, 165
BFD fault, 162 collaboration between track and application modules, 169 collaboration between track and detection modules, 168 configuring Ethernet OAM errored frame event detection, 13 configuring Ethernet OAM errored frame period event detection, 13 configuring Ethernet OAM errored frame seconds event detection, 14 configuring Ethernet OAM errored symbol event detection, 13 configuring RRPP fast detection, 65 configuring RRPP fast detection timer, 65
DLDP configuration, 31, 38, 42 enabling RRPP fast detection, 59, 65
Ethernet OAM fault detection, 8 high availability fault detection technologies, 2 high availability protection switchover technologies, 3 method (BFD), 162 remote fault (Ethernet OAM), 11
RRPP fast detection mechanism, 55 device activating RRPP domain, 64 configuring Smart Link and CFD continuity check collaboration, 103 configuring Smart Link associate, 103 creating RRPP domain, 59 link detection protocol. See DLDP loopback (CFD), 20
Monitor Link downlink, 120
Monitor Link downlink port, 119
Monitor Link uplink, 120
Monitor Link uplink port, 119 restarting standby MPU, 6
Smart Link configuration, 100 disable (DLDP link state), 32 disconnect state (RRPP ring), 51 displaying active switchover, 7
BFD, 167
CFD, 26
DLDP, 42
Ethernet OAM configuration, 14
IPv4 VRRP, 136
IPv6 VRRP, 140
Monitor Link, 121
RRPP, 66
Smart Link, 104 standby switchover, 7 track entries, 175
DLDP active timer, 32 advertisement timer, 32 auto shutdown of unidirectional link, 42 configuration, 31, 38, 42 configuring authentication, 41 configuring duplex mode, 38 configuring Ethernet interface speed, 38 delaydown timer, 32 displaying, 42 echo timer, 32 enabling, 38 enhanced timer, 32 entry timer, 32 high availability fault detection technologies, 2 how it works, 32 link auto-recovery mechanism, 37 link state, 32 maintaining, 42 manual shutdown of unidirectional link, 46
MD5 authentication mode, 34 non-authentication mode, 34 operation mode, 33 probe timer, 32 processes, 35 recoverprobe timer, 32 resetting state, 41 resetting state in port/port group view, 42 resetting state in system view, 41 setting DelayDown timer, 40 setting mode, 39 setting port shutdown mode, 40 setting send advertisement packet interval, 39 simple authentication mode, 34 state and packet type, 35
203 troubleshooting, 49 two-way neighbor state, 38 unidirectional neighbor state, 38 unknown neighbor state, 38 verifying auto shutdown of unidirectional link, 44 verifying manual shutdown of unidirectional link,
47 domain activating (RRPP), 64 creating (RRPP), 59 maintenance (CFD), 17
RRPP, 50 downlink
Monitor Link, 120
Monitor Link port, 119 dual-homed rings (RRPP network), 57 duplex mode (DLDP), 38 edge edge-hello RRPPDU type, 52
RRPP node type, 51
RRPP port type, 52 specifying RRPP node, 63 enabling
CFD, 21
DLDP, 38
RRPP fast detection, 59, 65
Smart Link flush message receipt, 103
Smart Link flush message send, 102 enhanced mode setting (DLDP), 39 errored frame event detection (Ethernet OAM), 13 frame period event detection (Ethernet OAM), 13 frame seconds event detection (Ethernet OAM), 14 symbol event detection (Ethernet OAM), 13 establishing connection (Ethernet OAM), 9
Ethernet configuring interface speed (DLDP), 38 enabling DLDP, 38
IPv4 VRRP configuration, 131, 140
IPv4 VRRP configuration restrictions, 131
IPv4 VRRP interface tracking configuration, 143
IPv4 VRRP multiple VLANs configuration, 147
IPv4 VRRP single group configuration, 140
IPv6 VRRP configuration, 136, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156 link aggregation (protection switchover technologies), 3
OAM. See Ethernet OAM
RRPP configuration, 50, 59, 67
RRPP dual homed rings configuration, 74
RRPP fast detection configuration, 93
RRPP intersecting rings configuration, 69
RRPP load balanced intersecting rings configuration, 84
RRPP single ring configuration, 67
Ethernet OAM configuration, 8, 11, 15 configuring basic function, 11 configuring connection detection timer, 12 configuring errored frame event detection, 13 configuring errored frame period event detection,
13 configuring errored frame seconds event detection,
14 configuring errored symbol event detection, 13 configuring link monitoring, 12 displaying configuration, 14 establishing connection, 9 fault detection and alarm, 8 high availability fault detection technology, 2 how it works, 9 link monitoring, 10 link performance monitoring, 8 maintaining configuration, 14
OAMPDU
, 8
OAMPDU field description, 8
OAMPDU format, 8
OAMPDU function, 8 protocols and standards, 11 remote fault detection, 11 remote loopback, 8 verifying configuration, 15 evaluating network availability, 1 event detection errored frame (Ethernet OAM), 13 errored frame period (Ethernet OAM), 13 errored frame seconds (Ethernet OAM), 14 errored symbol (Ethernet OAM), 13 fail timer (RRPP), 53 fast detection configuration (RRPP), 65, 93 detection enabling (RRPP), 59, 65 detection mechanism (RRPP), 55 detection timer configuration (RRPP), 65 failure detection configuration (BFD), 161, 165 fast-edge-hello RRPPDU type, 52 fast-fail timer (RRPP), 53 fast-hello RRPPDU type, 52 fast-hello timer (RRPP), 53 fault detection
BFD, 162
CFD configuration (high availability), 17, 20, 21,
26
CFD maintenance domain, 17
Ethernet OAM, 8 high availability protection switchover technologies, 3 high availability technologies, 2 remote (Ethernet OAM), 11 field description (Ethernet OAMPDU), 8 flush
Smart Link message, 98, 102, 103 update mechanism (Smart Link), 99 format
BFD packet, 163, 166
Ethernet OAMPDU, 8
VRRP packet, 127 frame continuity check message (CFD), 20 linktrace message (CFD), 20 loopback message (CFD), 20
FRR high availability protection switchover technology,
3
IP FRR (BFD supported features), 165 function configuring (CFD), 24 configuring (Ethernet OAM), 11 configuring CFD continuity check on MEP, 24 configuring CFD linktrace on MEP, 25 configuring CFD loopback on MEP, 25 continuity check (CFD), 20
Ethernet OAMPDU, 8 linktrace (CFD), 20 loopback (CFD), 20 generating MIPs (CFD), 23
GR (high availability protection switchover technology), 3 group configuring Monitor Link member port, 120 configuring Monitor Link member port in group view, 120 configuring Monitor Link member port in interface view, 121 configuring protected VLAN for Smart Link group,
101 configuring RRPP ring, 66 creating IPv6 VRRP group, 136, 137 creating VRRP group, 132
IPv4 VRRP load sharing, 130
204
IPv4 VRRP master/backup mode, 130
Monitor Link, 119
Monitor Link creation, 120 resetting DLDP state in port/port group view, 42
RRPP ring, 52, 54
Smart Link and CFD continuity check collaboration configuration, 113
Smart Link multiple groups configuration, 109
Smart Link single group configuration, 104 terminology (Smart Link), 98
VRRP, 126 hardware detection (BFD configuration), 161, 165 health state (RRPP ring), 51 hello
RRPPDU type, 52 timer (RRPP), 53 high availability active switchover configuration, 5
BFD for VRRP backup monitoring configuration,
179
BFD for VRRP uplink monitoring configuration, 182
CFD configuration, 17, 20, 21, 26 configuring RRPP fast detection, 65 displaying active switchover, 7 displaying BFD, 167 displaying CFD, 26 displaying DLDP, 42 displaying IPv4 VRRP, 136 displaying IPv6 VRRP, 140 displaying Monitor Link, 121 displaying RRPP, 66 displaying Smart Link, 104 displaying standby switchover, 7 displaying track entries, 175
DLDP configuration, 31, 38, 42
Ethernet OAM. See Ethernet OAM evaluation, 1 fault detection technologies, 2 ignoring standby MPU version check, 5
IPv4 VRRP configuration, 131, 140
IPv4 VRRP interface tracking configuration, 143
IPv4 VRRP multiple VLANs configuration, 147
IPv4 VRRP single group configuration, 140
IPv6 VRRP configuration, 136, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156 maintaining BFD, 167 maintaining CFD, 26 maintaining DLDP, 42 maintaining IPv4 VRRP, 136
205 maintaining IPv6 VRRP, 140 maintaining Monitor Link, 121 maintaining RRPP, 66 maintaining Smart Link, 104 maintaining track entries, 175
Monitor Link configuration, 119, 120, 121
MTBF, 1
MTTR, 1 performing active switchover manually, 6 performing standby switchover manually, 6 protection switchover technologies, 3 remote loopback (Ethernet OAM), 8 requirements, 1 restarting standby MPU, 6
RRPP configuration, 50, 59, 67
RRPP dual homed rings configuration, 74
RRPP fast detection configuration, 93
RRPP intersecting rings configuration, 69
RRPP load balanced intersecting rings configuration, 84
RRPP single ring configuration, 67
Smart Link and CFD continuity check collaboration configuration, 113
Smart Link configuration, 97, 100, 104
Smart Link multiple groups configuration, 109
Smart Link single group configuration, 104 standby switchover configuration, 5 static routing-track-BFD collaboration configuration,
190 static routing-track-NQA collaboration configuration, 185 switchover configuration restrictions, 5 technologies, 2 track configuration, 168, 169, 175 troubleshooting DLDP, 49
VRRP configuration, 125
VRRP-track-interface management collaboration configuration, 193
VRRP-track-NQA collaboration track configuration,
175 ignoring standby MPU version check, 5 interface management (associating with track), 171 intersecting rings
RRPP load balancing, 58
RRPP network, 56 interval (DLDP send advertisement packets), 39
IP FRR (BFD supported features), 165
IPv4 VRRP application, 130 configuring packet attribute, 134 configuring trap function, 135
displaying, 136 interface tracking configuration, 143 load sharing, 130 maintaining, 136 master/backup mode, 130 multiple VLANs configuration, 147 specifying MAC address type mapped to virtual IP address, 132 verifying interface tracking configuration, 145 verifying single group configuration, 142 verifying with multiple VLANs configuration, 148
IPv6 BGP (BFD supported feature), 165
IPv6 IS-IS (BFD supported features), 165
IPv6 VRRP configuration, 136, 149 configuring packet attribute, 139 configuring virtual address, 136, 137 creating group, 136, 137 displaying, 140 interface tracking configuration, 152 maintaining, 140 multiple VLANs configuration, 156 single group configuration, 149 specifying MAC address type mapped to virtual IP address, 136 verifying interface tracking configuration, 154 verifying single group configuration, 151 verifying with multiple VLANs configuration, 158
IRF high availability switchover configuration restrictions, 5
IS-IS
BFD supported features, 165
IPv6 IS-IS (BFD supported features), 165
Layer 2 Ethernet OAM configuration, 8, 11, 15
Layer 3
IPv4 VRRP configuration, 131, 140
IPv4 VRRP configuration restrictions, 131
IPv4 VRRP interface tracking configuration, 143
IPv4 VRRP multiple VLANs configuration, 147
IPv4 VRRP single group configuration, 140
IPv6 VRRP configuration, 136, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156 link active state (DLDP), 32 advertisement state (DLDP), 32 auto shutdown of unidirectional link (DLDP), 42 backup mechanism (Smart Link), 99 configuring CFD linktrace on MEP, 25 configuring monitoring (Ethernet OAM), 12
206 delaydown state (DLDP), 32 disable state (DLDP), 32
DLDP auto-recovery mechanism, 37
DLDP configuration, 31, 38, 42
DLDP operation mode and unidirectional link, 33 enabling DLDP, 38
Ethernet OAM configuration, 8, 11, 15 inactive state (DLDP), 32 initial state (DLDP), 32 linktrace (CFD), 20 manual shutdown of unidirectional link (DLDP), 46
Monitor Link configuration, 119, 120, 121
Monitor Link downlink, 120
Monitor Link uplink, 120 monitoring (Ethernet OAM), 10 performance monitoring (Ethernet OAM), 8 probe state (DLDP), 32
RRPP link down mechanism, 54
Smart Link configuration, 97, 100, 104
Smart Link primary link, 98
Smart Link secondary link, 98 link-down RRPPDU type, 52 linktrace
CFD, 20 configuring on MEP, 25 load balancing (RRPP intersecting rings), 58 balancing (RRPP single ring), 57 balancing (RRPP), 54 sharing (IPv4 VRRP), 130 sharing (Smart Link mechanism), 99 loopback
CFD, 20 configuring on MEP, 25
MA (CFD service instance configuration), 22
MAC address
Smart Link uplink traffic-triggered MAC address learning, 99 specifying type mapped to virtual IPv4 address
(VRRP), 132 specifying type mapped to virtual IPv6 address
(VRRP), 136 maintaining
BFD, 167
CFD, 26
DLDP, 42
Ethernet OAM configuration, 14
IPv4 VRRP, 136
IPv6 VRRP, 140
Monitor Link, 121
RRPP, 66
Smart Link, 104 track entries, 175 maintenance association (CFD), 18 domain (CFD), 17
MEP list (CFD), 19 point (CFD), 18 major-fault RRPPDU type, 52 manual
DLDP port shutdown mode, 40 unidirectional link shutdown, 46 mapping specifying MAC address type mapped to virtual
IPv4 address (VRRP), 132 specifying MAC address type mapped to virtual
IPv6 address (VRRP), 136 master
IPv4 VRRP master/backup mode, 130
RRPP node specification, 62
RRPP node type, 51
MD configuring CFD service instances, 22 creating CFD service instance with MD name, 22 creating CFD service instance without MD name,
22 md5 authentication mode (VRRP), 127 mean time between failures. See MTBF to report. See MTTR mechanism
RRPP broadcast storm suppression, 54
RRPP fast detection, 55
RRPP link down, 54
RRPP polling, 53
MEP
CFD continuity check function, 20
CFD linktrace function, 20
CFD loopback function, 20
CFD maintenance point, 18 configuration (CFD), 23 configuring CFD service instances, 22 list, 19 message continuity check (CFD), 20 enabling Smart Link flush message receipt, 103 enabling Smart Link flush send, 102 flush (Smart Link), 98 linktrace (CFD), 20 linktrace reply (CFD), 20 loopback (CFD), 20 loopback reply (CFD), 20
207 method (BFD connectivity detection), 162
MIP
CFD maintenance point, 18 configuring CFD service instances, 22 configuring generation rules (CFD), 23 mode
BFD control packet session, 162
BFD echo packet session, 162 configuring IPv6 VRRP preemptive mode, 138 configuring VRRP preemptive mode, 133
DLDP duplex, 38
DLDP enhanced, 33
DLDP MD5 authentication mode, 34
DLDP non-authentication mode, 34
DLDP normal, 33
DLDP simple authentication mode, 34
IPv4 VRRP master/backup, 130 setting DLDP mode, 39 setting DLDP port shutdown mode, 40
VRRP authentication, 127
VRRP operation, 127
VRRP standard, 125 module collaboration between track and application modules, 169 collaboration between track and detection modules, 168 track configuration, 168, 169, 175
VRRP-track-NQA collaboration track configuration,
175
Monitor Link configuration, 119, 120, 121 configuring group member port, 120 configuring group member port in group view, 120 configuring group member port in interface view,
121 creating group, 120 displaying, 121 downlink, 120 downlink port, 119 group, 119 high availability fault detection technologies, 2 how it works, 120 maintaining, 121
Smart Link collaboration, 100
Smart Link configuration, 119, 120, 121 terminology, 119 uplink, 120 uplink port, 119 verifying configuration, 124 monitoring
configuring link (Ethernet OAM), 12
Ethernet OAM, 8 link (Ethernet OAM), 10 track entry (VRRP), 129
MPLS (BFD supported feature), 165
MPU high availability switchover configuration restrictions, 5 ignoring version check, 5 restarting standby MPU, 6
MSTP (high availability protection switchover technology), 3
MTBF network availability evaluation, 1
MTTR network availability evaluation, 1 multicast continuity check message frame (CFD), 20 linktrace message frame (CFD), 20 multiple groups configuration (Smart Link), 109 name creating CFD service instance with MD name, 22 creating CFD service instance without MD name,
22 neighbor setting DLDP mode, 39 two-way (DLDP state), 38 unidirectional (DLDP state), 38 unknown (DLDP state), 38 network activating RRPP domain, 64
CFD maintenance association, 18
CFD maintenance domain, 17
CFD maintenance point, 18
CFD MEP list, 19 configuring RRPP control VLAN, 60 configuring RRPP node, 62 configuring RRPP port, 62 configuring RRPP protected VLAN, 60 configuring RRPP ring, 61 configuring Smart Link device, 100 enabling DLDP, 38 performing active switchover manually, 6 performing standby switchover manually, 6 restarting standby MPU, 6
RRPP control VLAN, 51
RRPP data VLAN, 51
RRPP domain, 50
RRPP load balancing, 54
RRPP ring group, 54
Smart Link load sharing mechanism, 99
Smart Link primary link, 98
Smart Link primary port, 98
Smart Link secondary link, 98
Smart Link secondary port, 98 network management auto shutdown of unidirectional link (DLDP), 42
BFD configuration, 161, 165
BFD for VRRP backup monitoring configuration,
179
BFD for VRRP uplink monitoring configuration, 182
CFD configuration (high availability), 17, 20, 21,
26
Ethernet OAM configuration, 8, 11, 15 high availability, 1 high availability active switchover configuration, 5 high availability evaluation, 1 high availability standby switchover configuration,
5
IPv4 VRRP configuration, 131, 140
IPv4 VRRP interface tracking configuration, 143
IPv4 VRRP multiple VLANs configuration, 147
IPv4 VRRP single group configuration, 140
IPv6 VRRP configuration, 136, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156 manual shutdown of unidirectional link (DLDP), 46
Monitor Link configuration, 119, 120, 121
RRPP configuration, 50, 59, 67
RRPP dual homed rings configuration, 74
RRPP fast detection configuration, 93
RRPP intersecting rings configuration, 69
RRPP load balanced intersecting rings configuration, 84
RRPP networking, 55
RRPP single ring configuration, 67
Smart Link and CFD continuity check collaboration configuration, 113
Smart Link configuration, 97, 100, 104
Smart Link multiple groups configuration, 109
Smart Link single group configuration, 104 static routing-track-BFD collaboration configuration,
190 static routing-track-NQA collaboration configuration, 185 track configuration, 168, 169, 175 troubleshooting DLDP, 49 verifying auto shutdown of unidirectional link
(DLDP), 44 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183
208
verifying CFD configuration, 29 verifying Ethernet OAM configuration, 15 verifying IPv4 VRRP interface tracking configuration, 145 verifying IPv4 VRRP single group configuration,
142 verifying IPv4 VRRP with multiple VLANs configuration, 148 verifying IPv6 VRRP interface tracking configuration, 154 verifying IPv6 VRRP single group configuration,
151 verifying IPv6 VRRP with multiple VLANs configuration, 158 verifying manual shutdown of unidirectional link
(DLDP), 47 verifying Monitor Link configuration, 124 verifying Smart Link and CFD continuity check collaboration configuration, 117 verifying Smart Link multiple groups configuration,
112 verifying Smart Link single group configuration,
108 verifying static routing-track-BFD collaboration configuration, 191 verifying static routing-track-NQA collaboration configuration, 188 verifying VRRP-track-interface management collaboration configuration, 194
VRRP configuration, 125
VRRP-track-interface management collaboration configuration, 193
VRRP-track-NQA collaboration track configuration,
175 networking
RRPP dual-homed rings topology, 57
RRPP intersecting rings load balancing, 58
RRPP intersecting rings topology, 56
RRPP single ring load balancing, 57
RRPP single ring topology, 55
RRPP tangent rings topology, 56 node configuring RRPP node, 62
RRPP assistant-edge type, 51
RRPP edge type, 51
RRPP master type, 51
RRPP transit type, 51 specifying RRPP assistant-edge node, 63 specifying RRPP edge node, 63 specifying RRPP master node, 62 specifying RRPP transit node, 63 non-preemptive mode (VRRP), 127 normal mode (DLDP), 39
NQA associating with track, 170 configuring static routing-track-NQA collaboration,
185 high availability fault detection technologies, 2 verifying static routing-track-NQA collaboration configuration, 188
VRRP-track-NQA collaboration track configuration,
175
NSR (high availability protection switchover technology), 3 operation mode
BFD active, 163
BFD passive, 163
DLDP enhanced, 33
DLDP normal, 33
VRRP priority, 127 operation, administration and maintenance. See
OAM
OSPF
BFD supported features, 165 v3 BFD supported features, 165 packet
BFD format, 163, 166 configuring IPv4 VRRP attribute, 134 configuring IPv6 VRRP attribute, 139
DLDP processing by type, 35
DLDP state and packet type, 35 setting DLDP send advertisement packet interval,
39
VRRP format, 127 parameter (BFD dynamic change), 163 passive operation mode (BFD), 163 performance monitoring (Ethernet OAM), 8 performing active switchover manually, 6 standby switchover manually, 6
PIM (BFD supported feature), 165 ping. See also loopback (CFD) point (CFD maintenance point), 18 polling mechanism (RRPP), 53 port configuring member port for Smart Link group, 101 configuring member port in interface view, 102 configuring member port in Smart Link group view,
102 configuring Monitor Link group member port, 120 configuring Monitor Link group member port in group view, 120
209
configuring Monitor Link group member port in interface view, 121 configuring role preemption for Smart Link group,
102 configuring RRPP port, 62 enabling DLDP, 38
IPv4 VRRP configuration, 131, 140
IPv4 VRRP configuration restrictions, 131
IPv4 VRRP interface tracking configuration, 143
IPv4 VRRP multiple VLANs configuration, 147
IPv4 VRRP single group configuration, 140
IPv6 VRRP configuration, 136, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156
Monitor Link downlink, 119
Monitor Link group, 119
Monitor Link uplink, 119 resetting DLDP state in port/port group view, 42
RRPP common, 52
RRPP edge, 52
RRPP primary master, 52
RRPP primary transit, 52
RRPP secondary master, 52
RRPP secondary transit, 52 setting DLDP shutdown mode, 40
Smart Link load sharing mechanism, 99
Smart Link primary port, 98
Smart Link secondary port, 98 preemption
Smart Link group, 102
Smart Link mechanism, 99
VRRP delay timer, 127 preemptive mode configuring (IPv6 VRRP), 138 configuring (VRRP), 133
VRRP, 127 primary
RRPP master port, 52
RRPP transit port, 52
Smart Link link, 98
Smart Link port, 98 priority configuring IPv6 VRRP router priority, 138 configuring VRRP router priority, 133
VRRP, 126 probe
DLDP link state, 32 procedure activating RRPP domain, 64 associating track and detection modules, 170
210 associating track with application module, 172 associating track with BFD, 170 associating track with interface management, 171 associating track with NQA, 170 associating track with PBR, 174 associating track with static routing, 173 associating track with VRRP, 172 configuring basic BFD, 165 configuring basic CFD settings, 21 configuring BFD for VRRP backup monitoring, 179 configuring BFD for VRRP uplink monitoring, 182 configuring CFD, 26 configuring CFD continuity check on MEP, 24 configuring CFD function, 24 configuring CFD linktrace on MEP, 25 configuring CFD loopback on MEP, 25 configuring CFD MEP, 23 configuring CFD MIP generation rules, 23 configuring CFD protocol version, 21 configuring CFD service instances, 22 configuring DLDP authentication, 41 configuring DLDP duplex mode, 38 configuring Ethernet interface speed (DLDP), 38 configuring Ethernet OAM basic functions, 11 configuring Ethernet OAM connection detection,
12 configuring Ethernet OAM errored frame event detection, 13 configuring Ethernet OAM errored frame period event detection, 13 configuring Ethernet OAM errored frame seconds event detection, 14 configuring Ethernet OAM errored symbol event detection, 13 configuring Ethernet OAM link monitoring, 12 configuring IPv4 VRRP interface tracking, 143 configuring IPv4 VRRP packet attribute, 134 configuring IPv4 VRRP single group, 140 configuring IPv4 VRRP trap function, 135 configuring IPv4 VRRP with multiple VLANs, 147 configuring IPv6 VRRP, 149 configuring IPv6 VRRP interface tracking, 152 configuring IPv6 VRRP packet attribute, 139 configuring IPv6 VRRP preemptive mode, 138 configuring IPv6 VRRP single group, 149 configuring IPv6 VRRP tracking function, 138 configuring IPv6 VRRP with multiple VLANs, 156 configuring member port for Smart Link group, 101 configuring member port in interface view, 102 configuring member port in Smart Link group view,
102
configuring Monitor Link group member port, 120 configuring Monitor Link group member port in group view, 120 configuring Monitor Link group member port in interface view, 121 configuring protected VLAN for Smart Link group,
101 configuring role preemption for Smart Link group,
102 configuring RRPP control VLAN, 60 configuring RRPP dual homed rings, 74 configuring RRPP fail timer, 64 configuring RRPP fast detection, 65, 93 configuring RRPP fast detection timer, 65 configuring RRPP hello timer, 64 configuring RRPP intersecting rings, 69 configuring RRPP load balanced intersecting rings,
84 configuring RRPP node, 62 configuring RRPP port, 62 configuring RRPP protected VLAN, 60 configuring RRPP ring, 61 configuring RRPP ring group, 66 configuring RRPP single ring, 67 configuring Smart Link and CFD continuity check collaboration, 103, 113 configuring Smart Link associated device, 103 configuring Smart Link device, 100 configuring Smart Link multiple groups, 109 configuring Smart Link single group, 104 configuring static routing-track-BFD collaboration,
190 configuring static routing-track-NQA collaboration,
185 configuring VRRP preemptive mode, 133 configuring VRRP router priority, 133, 138 configuring VRRP tracking function, 133 configuring VRRP virtual IP address, 132 configuring VRRP virtual IPv6 address, 136, 137 configuring VRRP-track-interface management collaboration, 193 configuring VRRP-track-NQA collaboration (track),
175 creating CFD service instance with MD name, 22 creating CFD service instance without MD name,
22 creating Monitor Link group, 120 creating RRPP domain, 59 displaying active switchover, 7 displaying standby switchover, 7 enabling CFD, 21
211 enabling DLDP, 38 enabling RRPP fast detection, 59, 65 enabling Smart Link flush message receipt, 103 enabling Smart Link flush message send, 102 ignoring standby MPU version check, 5 performing active switchover manually, 6 performing standby switchover manually, 6 resetting DLDP state, 41 resetting DLDP state in port/port group view, 42 resetting DLDP state in system view, 41 restarting standby MPU, 6 setting DLDP DelayDown timer, 40 setting DLDP mode, 39 setting DLDP port shutdown mode, 40 setting DLDP send advertisement packet interval,
39 specifying MAC address type mapped to virtual
IPv4 address (VRRP), 132 specifying MAC address type mapped to virtual
IPv6 address (VRRP), 136 specifying RRPP assistant-edge node, 63 specifying RRPP edge node, 63 specifying RRPP master node, 62 specifying RRPP transit node, 63 verifying auto shutdown of unidirectional link
(DLDP), 44 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183 verifying CFD configuration, 29 verifying IPv4 VRRP interface tracking configuration, 145 verifying IPv4 VRRP single group configuration,
142 verifying IPv4 VRRP with multiple VLANs configuration, 148 verifying IPv6 VRRP interface tracking configuration, 154 verifying IPv6 VRRP single group configuration,
151 verifying IPv6 VRRP with multiple VLANs configuration, 158 verifying manual shutdown of unidirectional link
(DLDP), 47 verifying Monitor Link configuration, 124 verifying RRPP dual homed rings configuration, 84 verifying RRPP fast detection configuration, 96 verifying RRPP intersecting rings configuration, 74 verifying RRPP load balanced intersecting rings configuration, 92
verifying RRPP single ring configuration, 69 verifying Smart Link and CFD continuity check collaboration configuration, 117 verifying Smart Link multiple groups configuration,
112 verifying Smart Link single group configuration,
108 verifying static routing-track-BFD collaboration configuration, 191 verifying static routing-track-NQA collaboration configuration, 188 verifying VRRP-track-interface management collaboration configuration, 194 process (DLDP), 35 protected VLAN configuring for Smart Link group, 101
RRPP configuration, 60
Smart Link, 98
Smart Link load sharing mechanism, 99 protection switchover (high availability technology), 2 protocols and standards
BFD, 165
CFD, 20 configuring CFD protocol version, 21
Ethernet OAM, 11
RRPP, 58
RRPP configuration, 50, 59, 67
Rapid Ring Protection Protocol. See RRPP real MAC to virtual IP mapping (VRRP), 132, 136 receive control VLAN (Smart Link), 98 recovering RRPP ring, 54 remote loopback (Ethernet OAM), 8
MEP (CFD), 19, 23 requirements (high availability), 1 restarting standby MPU, 6 restriction high availability switchover configuration, 5
IPv4 VRRP configuration, 131 ring configuring (RRPP), 61 configuring RRPP group, 66 disconnect state (RRPP), 51 health state (RRPP), 51 recovery (RRPP), 54
RRPP group, 52, 54
RIP (BFD supported feature), 165 role
Smart Link group preemption, 102
Smart Link preemption mechanism, 99 routing associating track with PBR, 174 associating track with static routing, 173
BFD packet format, 163, 166 configuring IPv6 VRRP preemptive mode, 138 configuring IPv6 VRRP router priority, 138 configuring IPv6 VRRP tracking function, 138 configuring static routing-track-BFD collaboration,
190 configuring static routing-track-NQA collaboration,
185 configuring VRRP preemptive mode, 133 configuring VRRP router priority, 133 configuring VRRP tracking function, 133 configuring VRRP virtual IP address, 132 configuring VRRP virtual IPv6 address, 136, 137 configuring VRRP-track-interface management collaboration, 193 creating IPv6 VRRP group, 136, 137 creating VRRP group, 132
IPv4 VRRP configuration, 131, 140
IPv4 VRRP configuration restrictions, 131
IPv4 VRRP interface tracking configuration, 143
IPv4 VRRP load sharing, 130
IPv4 VRRP master/backup mode, 130
IPv4 VRRP multiple VLANs configuration, 147
IPv4 VRRP single group configuration, 140
IPv6 VRRP configuration, 136, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156 monitoring track entry (VRRP), 129 tracking specified interface (VRRP), 129 verifying static routing-track-NQA collaboration configuration, 188
VRRP advertisement interval timer, 127
VRRP authentication mode, 127
VRRP configuration, 125
VRRP group, 126
VRRP operation mode, 127
VRRP packet format, 127
VRRP preemption delay timer, 127
VRRP principles, 129
VRRP priority, 126
VRRP standard mode, 125
VRRP timers, 127
VRRP tracking, 129
RRPP activating domain, 64 assistant-edge node type, 51 basic concepts, 50
212
broadcast storm suppression, 54 common port, 52 common-flush-FDB RRPPDU, 52 complete-flush-FDB RRPPDU, 52 configuration, 50, 59, 67 configuring control VLAN, 60 configuring fail timer, 64 configuring fast detection, 65 configuring fast detection timer, 65 configuring hello timer, 64 configuring node, 62 configuring port, 62 configuring protected VLAN, 60 configuring ring, 61 configuring ring group, 66 control VLAN, 51 creating domain, 59 data VLAN, 51 displaying, 66 domain, 50 dual homed rings configuration, 74 dual-homed rings networking, 57 edge node type, 51 edge port, 52 edge-hello RRPPDU, 52 enabling fast detection, 59, 65 fail timer, 53 fast detection configuration, 93 fast detection mechanism, 55 fast-edge-hello RRPPDU, 52 fast-fail timer, 53 fast-hello RRPPDU, 52 fast-hello timer, 53 hello RRPPDU, 52 hello timer, 53 high availability protection switchover technologies, 3 how it works, 53 intersecting rings configuration, 69 intersecting rings load balancing, 58 intersecting rings networking, 56 link down mechanism, 54 link-down RRPPDU, 52 load balanced intersecting rings configuration, 84 load balancing, 54 maintaining, 66 major-fault RRPPDU, 52 master node type, 51 networking, 55 node types, 51 polling mechanism, 53 primary master port, 52 primary transit port, 52 protocols and standards, 58 ring group, 52, 54 ring recovery, 54 ring topology, 51 secondary master port, 52 secondary transit port, 52 single ring configuration, 67 single ring load balancing, 57 single ring networking, 55 specifying assistant-edge node, 63 specifying edge node, 63 specifying master node, 62 specifying transit node, 63 tangent rings networking, 56 transit node type, 51 troubleshooting, 96 verifying dual homed rings configuration, 84 verifying fast detection configuration, 96 verifying intersecting rings configuration, 74 verifying load balanced intersecting rings configuration, 92 verifying single ring configuration, 69
RRPPDU, 51 common-flush-FDB type, 52 complete-flush-FDB type, 52 edge-hello type, 52 fast-edge-hello type, 52 fast-hello type, 52 hello type, 52 link-down type, 52 major-fault type, 52 rule (MIP generation), 23 secondary
RRPP master port, 52
RRPP transit port, 52
Smart Link link, 98
Smart Link port, 98 service instance (CFD), 22 session
BFD establishment, 161
BFD mode, 162 setting
DLDP DelayDown timer, 40
DLDP mode, 39
DLDP port shutdown mode, 40 resetting DLDP state, 41 resetting DLDP state in port/port group view, 42 resetting DLDP state in system view, 41 send advertisement packet interval (DLDP), 39
213
shutdown auto shutdown of unidirectional link (DLDP), 42
DLDP port mode, 40 manual shutdown of unidirectional link (DLDP), 46 simple authentication mode (VRRP), 127 single
RRPP ring network, 55
RRPP ring network load balancing, 57
Smart Link group configuration, 104
Smart Link
CFD continuity check collaboration, 100
CFD continuity check collaboration configuration,
113 collaborating mechanism, 99 configuration, 97, 100, 104 configuring associated device, 103 configuring CFD continuity check collaboration,
103 device configuration, 100 displaying, 104 enabling flush message receipt, 103 enabling flush message send, 102 flush message, 98 flush update mechanism, 99 group, 98 high availability protection switchover technologies, 3 how it works, 99 link backup mechanism, 99 load sharing mechanism, 99 maintaining, 104 member port configuration in interface view, 102 member port configuration in Smart Link group view, 102 member port for group configuration, 101
Monitor Link collaboration, 100
Monitor Link configuration, 119, 120, 121 multiple groups configuration, 109 primary link, 98 primary port, 98 protected VLAN, 98 protected VLAN for group configuration, 101 receive control VLAN, 98 role preemption for group configuration, 102 role preemption mechanism, 99 secondary link, 98 secondary port, 98 single group configuration, 104 terminology, 98 toplogy change mechanism, 99 transmit control VLAN, 98 verifying CFD continuity check collaboration configuration, 117 verifying multiple groups configuration, 112 verifying single group configuration, 108 software (ignoring standby MPU version check), 5 spanning tree (Monitor Link configuration), 119, 120,
121 specifying
MAC address type mapped to virtual IPv4 address
(VRRP), 132
MAC address type mapped to virtual IPv6 address
(VRRP), 136
RRPP assistant-edge node, 63
RRPP edge node, 63
RRPP master node, 62
RRPP transit node, 63
SRPT (RRPP broadcast storm suppression mechanism),
54 standard mode (VRRP), 125 standby performing manual switchover, 6 switchover (high availability technologies), 3 switchover configuration, 5 state active (DLDP link), 32 advertisement (DLDP link), 32 delaydown (DLDP link), 32 disable (DLDP link), 32
DLDP state and packet type, 35 inactive (DLDP link), 32 initial (DLDP link), 32 probe (DLDP link), 32 resetting (DLDP), 41 resetting DLDP state in port/port group view, 42 resetting DLDP state in system view, 41
RRPP ring disconnect state, 51
RRPP ring health state, 51 two-way (DLDP neighbor), 38 unidirectional (DLDP neighbor), 38 unknown (DLDP neighbor), 38 static routing
BFD supported features, 165 configuring static routing-track-BFD collaboration,
190 configuring static routing-track-NQA collaboration,
185 configuring VRRP-track-interface management collaboration, 193 verifying static routing-track-BFD collaboration configuration, 191
214
verifying static routing-track-NQA collaboration configuration, 188 switching
DLDP configuration, 31, 38, 42 high availability active switchover configuration, 5 high availability standby switchover configuration,
5 high availability switchover configuration restrictions, 5 performing active switchover manually, 6 performing standby switchover manually, 6 protection switchover technologies (high availability), 3 switchover (Monitor Link configuration), 119, 120,
121 symbol (Ethernet OAM event detection), 13 tangent rings (RRPP network), 56 technologies active switchover, 6 active switchover configuration, 5 standby switchover, 6 standby switchover configuration, 5 terminology flush message (Smart Link), 98 protected VLAN (Smart Link), 98 receive control VLAN (smart link), 98
Smart Link, 98
Smart Link group, 98 transmit control VLAN (Smart Link), 98 time
MTBF, 1
MTTR, 1 timer active (DLDP), 32 advertisement (DLDP), 32 configuring connection detection (Ethernet OAM),
12 configuring RRPP fail, 64 configuring RRPP fast detection timer, 65 configuring RRPP hello, 64 delaydown(DLDP), 32 echo (DLDP), 32 enhanced (DLDP), 32 entry (DLDP), 32 probe (DLDP), 32 recoverprobe (DLDP), 32
RRPP fail, 53
RRPP fast-fail, 53
RRPP fast-hello, 53
RRPP hello, 53 setting DLDP DelayDown timer, 40
VRRP, 127
VRRP advertisement interval, 127
VRRP preemption delay timer, 127 topology configuring RRPP port, 62 configuring RRPP ring, 61
RRPP configuration, 50, 59, 67
RRPP domain, 50
RRPP dual homed rings configuration, 74
RRPP dual-homed rings, 57
RRPP fast detection configuration, 93
RRPP intersecting rings, 56
RRPP intersecting rings configuration, 69
RRPP load balanced intersecting rings configuration, 84
RRPP networking, 55
RRPP ring group, 54
RRPP single ring, 55
RRPP single ring configuration, 67
RRPP tangent rings, 56
Smart Link change mechanism, 99 tracert. See also linktrace (CFD) track application, 169 associating detection module, 170 associating with application module, 172 associating with BFD, 170 associating with interface management, 171 associating with NQA, 170 associating with PBR, 174 associating with static routing, 173 associating with VRRP, 172
BFD for VRRP backup monitoring configuration,
179
BFD for VRRP uplink monitoring configuration, 182
BFD supported features, 165 collaboration, 168 collaboration between track and application modules, 169 collaboration between track and detection modules, 168 configuration, 168, 169, 175 displaying entries, 175 high availability fault detection technologies, 2 maintaining entries, 175 static routing-track-BFD collaboration configuration,
190 static routing-track-NQA collaboration configuration, 185 verifying BFD for VRRP backup monitoring configuration, 180
215
verifying BFD for VRRP uplink monitoring configuration, 183 verifying static routing-track-BFD collaboration configuration, 191 verifying static routing-track-NQA collaboration configuration, 188 verifying VRRP-track-interface management collaboration configuration, 194
VRRP-track-interface management collaboration configuration, 193
VRRP-track-NQA collaboration configuration, 175 tracking configuring IPv6 VRRP interface tracking, 152 configuring IPv6 VRRP tracking function, 138 configuring VRRP tracking function, 133 monitoring track entry (VRRP), 129 specified interface (VRRP), 129
VRRP, 129 traffic
RRPP load balancing, 54
Smart Link load sharing mechanism, 99
Smart Link uplink traffic-triggered MAC address learning, 99 transit node
RRPP type, 51 specifying RRPP, 63 transmit control VLAN (Smart Link), 98 trapping (IPv4 VRRP trap function configuration), 135 troubleshooting
DLDP, 49 frequent VRRP state transitions, 160 multiple masters present in VRRP group, 160
RRPP master node, 96 screen frequently displays error prompts (VRRP),
159
VRRP, 159 two-way neighbor state (DLDP), 38 type
DLDP state and packet type, 35 packet processing by DLDP state and packet type,
35
UDP (BFD packet format), 163, 166 unicast linktrace reply message frame (CFD), 20 loopback message frame (CFD), 20 unidirectional
DLDP link auto shutdown, 42
DLDP link configuration, 31, 38, 42
DLDP link operation mode, 33
DLDP link troubleshooting, 49
DLDP manual link shutdown, 46
DLDP neighbor state, 38 unknown neighbor state (DLDP), 38 update mechanism (Smart Link flush), 99 uplink
BFD for VRRP uplink monitoring, 182
Monitor Link, 120 port (Monitor Link), 119 traffic-triggered MAC address learning (Smart
Link), 99 verifying auto shutdown of unidirectional link (DLDP), 44
BFD for VRRP backup monitoring configuration,
180
BFD for VRRP uplink monitoring configuration, 183
CFD configuration, 29
Ethernet OAM configuration, 15
IPv4 VRRP interface tracking configuration, 145
IPv4 VRRP single group configuration, 142
IPv4 VRRP with multiple VLANs configuration, 148
IPv6 VRRP interface tracking configuration, 154
IPv6 VRRP single group configuration, 151
IPv6 VRRP with multiple VLANs configuration, 158 manual shutdown of unidirectional link (DLDP), 47
Monitor Link configuration, 124
RRPP dual homed rings configuration, 84
RRPP fast detection configuration, 96
RRPP intersecting rings configuration, 74
RRPP load balanced intersecting rings configuration, 92
RRPP single ring configuration, 69
Smart Link and CFD continuity check collaboration configuration, 117
Smart Link multiple groups configuration, 112
Smart Link single group configuration, 108 static routing-track-BFD collaboration configuration,
191 static routing-track-NQA collaboration configuration, 188
VRRP-track-interface management collaboration configuration, 194 version
CFD protocol version configuration, 21 check (standby MPU), 5 virtual
IP address configuration (IPv6 VRRP), 136, 137
IP address (MAC address type mapping), 132,
136
IP address configuration (VRRP), 132
MAC to virtual IP mapping (VRRP), 132, 136 router redundancy protocol. See VRRP
216
VRRP router, 126
VLAN
CFD configuration (high availability), 17, 20, 21,
26
CFD maintenance association, 18 configuring IPv6 VRRP with multiple VLANs, 156 configuring protected VLAN for Smart Link group,
101 configuring RRPP control VLAN, 60 configuring RRPP port, 62 configuring RRPP protected VLAN, 60 configuring Smart Link device, 100 control (RRPP), 51 data (RRPP), 51
IPv4 VRRP multiple VLANs configuration, 147
IPv6 VRRP configuration, 149
IPv6 VRRP interface tracking configuration, 152
IPv6 VRRP single group configuration, 149
IPv6 VRRP with multiple VLANs configuration, 156
MEP configuration (CFD), 23 protected VLAN (Smart Link), 98 receive control VLAN (Smart Link), 98
RRPP domain, 50
RRPP load balancing, 54
Smart Link load sharing mechanism, 99 transmit control VLAN (Smart Link), 98
VRRP advertisement interval, 127 authentication mode, 127 configuration, 125 configuring BFD for VRRP backup monitoring, 179 configuring BFD for VRRP uplink monitoring, 182 configuring IPv4 packet attribute, 134 configuring IPv4 trap function, 135 configuring IPv6 packet attribute, 139 configuring IPv6 preemptive mode, 138 configuring IPv6 router priority, 138 configuring IPv6 tracking function, 138 configuring preemptive mode, 133 configuring router priority, 133 configuring tracking function, 133 configuring virtual IP address, 132 configuring virtual IPv6 address, 136, 137 configuring VRRP-track-interface management collaboration collaboration, 193 creating group, 132
217 creating IPv6 group, 136, 137 group, 126 high availability protection switchover technologies, 3
IPv4 application, 130
IPv4 configuration, 131, 140
IPv4 configuration restrictions, 131
IPv4 interface tracking configuration, 143
IPv4 load sharing, 130
IPv4 master/backup mode, 130
IPv4 multiple VLANs configuration, 147
IPv4 single group configuration, 140
IPv6 configuration, 136, 149
IPv6 interface tracking configuration, 152
IPv6 single group configuration, 149
IPv6 with multiple VLANs configuration, 156 monitoring track entry, 129 operation mode, 127 packet format, 127 preemption delay timer, 127 principles, 129 priority, 126 specifying MAC address type mapped to virtual
IPv4 address, 132 specifying MAC address type mapped to virtual
IPv6 address, 136 standard mode, 125 timer, 127 tracking, 129 tracking specified interface, 129 troubleshooting, 159 troubleshooting frequent state transitions, 160 troubleshooting multiple masters present in group,
160 troubleshooting screen frequently displays error prompts, 159 v2 packet format, 127 v3 packet format, 127 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183 verifying VRRP-track-interface management collaboration configuration, 194
VRRP-track-NQA collaboration track configuration,
175
advertisement
Key Features
- Active and standby switchover
- Ethernet OAM
- CFD (Connectivity Fault Detection)
- DLDP (Dynamic Link Discovery Protocol)
- RRPP (Redundant Ring Protocol Plus)
- Smart Link
- Monitor Link
- VRRP (Virtual Router Redundancy Protocol)
- BFD (Bidirectional Forwarding Detection)
Frequently Answers and Questions
What are some of the high availability features for HP 10500 Switch Series?
How does the HP 10500 Switch Series detect and recover from network faults?
What are the key benefits of using high availability features on the HP 10500 Switch Series?
Related manuals
advertisement
Table of contents
- 1 Title Page
- 3 Contents
- 8 High availability overview
- 8 Availability requirements
- 8 Availability evaluation
- 8 MTBF
- 8 MTTR
- 9 High availability technologies
- 9 Fault detection technologies
- 10 Protection switchover technologies
- 12 Configuring active and standby switchover
- 12 Configuration restrictions and guidelines
- 12 Active and standby switchover configuration task list
- 12 Ignoring version check for the standby MPU
- 13 Restarting the standby MPU
- 13 Manually performing an active and standby switchover
- 14 Displaying and maintaining active and standby switchover
- 15 Configuring Ethernet OAM
- 15 Overview
- 15 Major functions of Ethernet OAM
- 15 Ethernet OAMPDUs
- 16 How Ethernet OAM works
- 16 Establishing an Ethernet OAM connection
- 17 Link monitoring
- 18 Remote fault detection
- 18 Protocols and standards
- 18 Ethernet OAM configuration task list
- 18 Configuring basic Ethernet OAM functions
- 19 Configuring the Ethernet OAM connection detection timers
- 19 Configuring link monitoring
- 20 Configuring errored symbol event detection
- 20 Configuring errored frame event detection
- 20 Configuring errored frame period event detection
- 21 Configuring errored frame seconds event detection
- 21 Displaying and maintaining Ethernet OAM configuration
- 22 Ethernet OAM configuration example
- 22 Network requirements
- 22 Configuration procedure
- 22 Verifying the configuration
- 24 Configuring CFD
- 24 Overview
- 24 Basic CFD concepts
- 24 MD
- 25 MA
- 25 MP
- 26 MEP list
- 27 CFD functions
- 27 CC
- 27 LB
- 27 LT
- 27 Protocols and standards
- 27 CFD configuration task list
- 28 Configuring basic CFD settings
- 28 Enabling CFD
- 28 Configuring the CFD protocol version
- 29 Configuring service instances
- 29 Creating a service instance with the MD name
- 29 Creating a service instance without the MD name
- 30 Configuring MEPs
- 30 Configuring MIP generation rules
- 31 Configuring CFD functions
- 31 Configuration prerequisites
- 31 Configuring CC on MEPs
- 31 Configuration guidelines
- 31 Configuration procedure
- 32 Configuring LB on MEPs
- 32 Configuring LT on MEPs
- 33 Displaying and maintaining CFD
- 33 CFD configuration example
- 33 Network requirements
- 34 Configuration procedure
- 36 Verifying the configuration
- 38 Configuring DLDP
- 39 How DLDP works
- 39 DLDP link states
- 39 DLDP timers
- 40 DLDP mode
- 41 DLDP authentication mode
- 42 DLDP processes
- 44 Link auto-recovery mechanism
- 45 DLDP neighbor state
- 45 DLDP configuration task list
- 45 Configuring the duplex mode and speed of an Ethernet interface
- 45 Enabling DLDP
- 46 Setting DLDP mode
- 46 Setting the interval to send advertisement packets
- 47 Setting the DelayDown timer
- 47 Setting the port shutdown mode
- 48 Configuring DLDP authentication
- 48 Resetting DLDP state
- 48 Resetting DLDP state in system view
- 49 Resetting DLDP state in port view/port group view
- 49 Displaying and maintaining DLDP
- 49 DLDP configuration examples
- 49 Automatically shutting down unidirectional links
- 49 Network requirements
- 50 Configuration procedure
- 51 Verifying the configuration
- 53 Manually shutting down unidirectional links
- 53 Network requirements
- 53 Configuration procedure
- 54 Verifying the configuration
- 56 Troubleshooting DLDP
- 56 Symptom
- 56 Analysis
- 56 Solution
- 57 Configuring RRPP
- 57 Overview
- 57 Basic RRPP concepts
- 57 RRPP domain
- 58 RRPP ring
- 58 Control VLAN and data VLAN
- 58 Node
- 59 Primary port and secondary port
- 59 Common port and edge port
- 59 RRPP ring group
- 59 RRPPDUs
- 60 RRPP timers
- 60 How RRPP works
- 60 Polling mechanism
- 61 Link down alarm mechanism
- 61 Ring recovery
- 61 Broadcast storm suppression mechanism in case of SRPT failure in a multi-homed subring
- 61 Load balancing
- 61 RRPP ring group
- 62 Fast detection mechanism
- 62 Typical RRPP networking
- 62 Single ring
- 63 Tangent rings
- 63 Intersecting rings
- 64 Dual-homed rings
- 64 Single-ring load balancing
- 65 Intersecting-ring load balancing
- 65 Protocols and standards
- 66 RRPP configuration task list
- 66 Creating an RRPP domain
- 67 Configuring control VLANs
- 67 Configuration guidelines
- 67 Configuration procedure
- 67 Configuring protected VLANs
- 68 Configuring RRPP rings
- 68 Configuration guidelines
- 69 Configuring RRPP ports
- 69 Configuring RRPP nodes
- 69 Specifying a master node
- 70 Specifying a transit node
- 70 Specifying an edge node
- 70 Specifying an assistant-edge node
- 71 Activating an RRPP domain
- 71 Configuring RRPP timers
- 72 Configuring RRPP fast detection
- 72 Enabling fast detection
- 72 Configuring fast detection timers
- 73 Configuring an RRPP ring group
- 73 Configuration guidelines
- 73 Configuration procedure
- 73 Displaying and maintaining RRPP
- 74 RRPP configuration examples
- 74 Single ring configuration example
- 74 Networking requirements
- 75 Configuration procedure
- 76 Verifying the configuration
- 76 Intersecting ring configuration example
- 76 Networking requirements
- 77 Configuration procedure
- 81 Verifying the configuration
- 81 Dual homed rings configuration example
- 81 Networking requirements
- 82 Configuration procedure
- 91 Verifying the configuration
- 91 Load balanced intersecting-ring configuration example
- 91 Networking requirements
- 92 Configuration procedure
- 99 Verifying the configuration
- 100 Fast detection configuration example
- 100 Network requirements
- 100 Configuration procedure
- 103 Verifying the configuration
- 103 Troubleshooting
- 103 Symptom
- 103 Analysis
- 103 Solution
- 104 Configuring Smart Link
- 104 Overview
- 105 Terminology
- 105 Smart link group
- 105 Primary/secondary port
- 105 Primary/secondary link
- 105 Flush message
- 105 Protected VLAN
- 105 Transmit control VLAN
- 105 Receive control VLAN
- 106 How Smart Link works
- 106 Link backup mechanism
- 106 Topology change mechanism
- 106 Role preemption mechanism
- 106 Load sharing mechanism
- 106 Smart Link collaboration mechanisms
- 107 Collaboration between Smart Link and Monitor Link
- 107 Collaboration between Smart Link and CC of CFD
- 107 Smart Link configuration task list
- 107 Configuring a Smart Link device
- 107 Configuration prerequisites
- 108 Configuring protected VLANs for a smart link group
- 108 Configuring member ports for a smart link group
- 109 In smart link group view
- 109 In interface view
- 109 Configuring role preemption for a smart link group
- 109 Enabling the sending of flush messages
- 110 Configuring the collaboration between Smart Link and CC of CFD
- 110 Configuring an associated device
- 110 Configuration prerequisites
- 110 Enabling the receiving of flush messages
- 111 Displaying and maintaining Smart Link
- 111 Smart Link configuration examples
- 111 Single smart link group configuration example
- 111 Network requirements
- 112 Configuration procedure
- 115 Verifying the configuration
- 116 Multiple smart link groups load sharing configuration example
- 116 Network requirements
- 116 Configuration procedure
- 119 Verifying the configuration
- 120 Smart Link and CFD collaboration configuration example
- 120 Network requirements
- 120 Configuration procedure
- 124 Verifying the configuration
- 126 Configuring Monitor Link
- 126 Overview
- 126 Terminology
- 126 Monitor link group
- 126 Uplink/Downlink ports
- 127 Uplink/Downlink
- 127 How Monitor Link works
- 127 Configuring Monitor Link
- 127 Configuration prerequisites
- 127 Creating a monitor link group
- 127 Configuring monitor link group member ports
- 127 In monitor link group view
- 128 In interface view
- 128 Displaying and maintaining Monitor Link
- 128 Monitor Link configuration example
- 128 Network requirements
- 129 Configuration procedure
- 131 Verifying the configuration
- 132 Configuring VRRP
- 132 VRRP overview
- 132 VRRP standard mode
- 133 VRRP group
- 133 VRRP priority
- 134 Operation mode
- 134 Authentication mode
- 134 VRRP timers
- 134 VRRP advertisement interval
- 134 VRRP preemption delay timer
- 134 Packet format
- 136 VRRP principles
- 136 VRRP tracking
- 136 Tracking a specified interface
- 136 Monitoring a track entry
- 137 VRRP application
- 137 Master/backup
- 137 Load sharing
- 138 General configuration restrictions
- 138 Configuring VRRP for IPv4
- 138 VRRP for IPv4 configuration task list
- 139 Specifying the type of MAC addresses mapped to virtual IP addresses
- 139 Creating a VRRP group and configuring virtual IP addresses
- 139 Configuration guidelines
- 140 Configuration prerequisites
- 140 Configuration procedure
- 140 Configuring router priority, preemptive mode, and tracking function
- 140 Configuration guidelines
- 141 Configuration prerequisites
- 141 Configuration procedure
- 141 Configuring VRRP packet attributes
- 141 Configuration guidelines
- 142 Configuration prerequisites
- 142 Configuration procedure
- 142 Enabling the trap function for VRRP
- 143 Displaying and maintaining VRRP for IPv4
- 143 Configuring VRRP for IPv6
- 143 VRRP for IPv6 configuration task list
- 143 Specifying the type of mapped MAC addresses
- 144 Creating a VRRP group and configuring a virtual IPv6 address
- 144 Configuration guidelines
- 144 Configuration prerequisites
- 144 Configuration procedure
- 145 Configuring router priority, preemptive mode, and tracking function
- 145 Configuration guidelines
- 145 Configuration prerequisites
- 145 Configuration procedure
- 146 Configuring VRRP packet attributes
- 146 Configuration guidelines
- 146 Configuration prerequisites
- 147 Configuration procedure
- 147 Displaying and maintaining VRRP for IPv6
- 147 IPv4 VRRP configuration examples
- 147 Single VRRP group configuration example
- 147 Network requirements
- 148 Configuration procedure
- 149 Verifying the configuration
- 150 VRRP interface tracking configuration example
- 150 Network requirements
- 151 Configuration procedure
- 152 Verifying the configuration
- 154 VRRP with multiple VLANs configuration example
- 154 Network requirements
- 154 Configuration procedure
- 155 Verifying the configuration
- 156 IPv6 VRRP configuration examples
- 156 Single VRRP group configuration example
- 156 Network requirements
- 157 Configuration procedure
- 158 Verifying the configuration
- 159 VRRP interface tracking configuration example
- 159 Network requirements
- 160 Configuration procedure
- 161 Verifying the configuration
- 163 VRRP with multiple VLANs configuration example
- 163 Network requirements
- 164 Configuration procedure
- 165 Verifying the configuration
- 166 Troubleshooting VRRP
- 166 The screen frequently displays error prompts
- 166 Symptom
- 166 Analysis
- 167 Solution
- 167 Multiple masters are present in a VRRP group
- 167 Symptom
- 167 Analysis
- 167 Solution
- 167 Frequent VRRP state transition
- 167 Symptom
- 167 Analysis
- 167 Solution
- 168 Configuring BFD
- 168 Overview
- 168 How BFD works
- 168 Establishing a BFD session
- 169 Detecting BFD faults
- 169 BFD detection methods
- 169 BFD session modes
- 170 BFD operating modes
- 170 Dynamic BFD parameter changes
- 170 BFD packet format
- 172 Supported features
- 172 Protocols and standards
- 172 Configuring BFD basic functions
- 174 Displaying and maintaining BFD
- 175 Configuring track
- 175 Track overview
- 175 Collaboration fundamentals
- 175 Collaboration between the track module and a detection module
- 176 Collaboration between the track module and an application module
- 176 Collaboration application example
- 176 Track configuration task list
- 177 Associating the track module with a detection module
- 177 Associating track with NQA
- 177 Associating track with BFD
- 178 Configuration prerequisites
- 178 Configuration procedure
- 178 Associating track with interface management
- 179 Associating the track module with an application module
- 179 Associating track with VRRP
- 179 Configuration restrictions
- 179 Configuration procedure
- 180 Associating track with static routing
- 180 Configuration restrictions
- 180 Configuration procedure
- 181 Associating track with PBR
- 181 Configuration prerequisites
- 181 Configuration procedure
- 182 Displaying and maintaining track entries
- 182 Track configuration examples
- 182 VRRP-track-NQA collaboration configuration example (the master monitors the uplink)
- 182 Network requirements
- 183 Configuration procedure
- 184 Verifying the configuration
- 186 Configuring BFD for a VRRP backup to monitor the master (the master monitors the uplink)
- 186 Network requirements
- 186 Configuration procedure
- 187 Verifying the configuration
- 189 Configuring BFD for the VRRP master to monitor the uplinks
- 189 Network requirements
- 189 Configuration procedure
- 190 Verifying the configuration
- 192 Static routing-track-NQA collaboration configuration example
- 192 Network requirements
- 193 Configuration procedure
- 195 Verifying the configuration
- 197 Static routing-track-BFD collaboration configuration example
- 197 Network requirements
- 197 Configuration procedure
- 198 Verifying the configuration
- 200 VRRP-track-interface management collaboration configuration example (the master monitors the uplink interface)
- 200 Network requirements
- 201 Configuration procedure
- 201 Verifying the configuration
- 204 Support and other resources
- 204 Contacting HP
- 204 Subscription service
- 204 Related information
- 204 Documents
- 204 Websites
- 205 Conventions
- 205 Command conventions
- 205 GUI conventions
- 205 Symbols
- 206 Network topology icons
- 206 Port numbering in examples
- 207 Index