10-High Availability Configuration Guide

HomeSupportResource CenterSwitchesS12500X-AF SeriesS12500X-AF SeriesTechnical DocumentsConfigure & DeployConfiguration GuidesH3C S12500X-AF Switch Series Configuration Guides(R26xx)-6W10210-High Availability Configuration Guide
Table of Contents
Related Documents
01-Text
Title Size Download
01-Text 1.90 MB

Contents

Configuring Ethernet OAM·· 1

Overview· 1

Major functions of Ethernet OAM·· 1

Ethernet OAMPDUs· 1

How Ethernet OAM works· 1

Protocols and standards· 3

Ethernet OAM configuration task list 3

Configuring basic Ethernet OAM functions· 3

Configuring the Ethernet OAM connection detection timers· 4

Configuring link monitoring· 4

Configuring errored symbol event detection· 4

Configuring errored frame event detection· 5

Configuring errored frame period event detection· 6

Configuring errored frame seconds event detection· 6

Configuring the action a port takes after it receives an Ethernet OAM event from the remote end· 7

Displaying and maintaining Ethernet OAM·· 8

Ethernet OAM configuration example· 8

Network requirements· 8

Configuration procedure· 8

Configuring DLDP·· 10

Overview· 10

Basic concepts· 11

How DLDP works· 12

Configuration restrictions and guidelines· 14

DLDP configuration task list 14

Enabling DLDP· 14

Setting the interval to send advertisement packets· 15

Setting the DelayDown timer 15

Setting the port shutdown mode· 15

Configuring DLDP authentication· 16

Displaying and maintaining DLDP· 16

DLDP configuration examples· 17

Automatically shutting down unidirectional links· 17

Manually shutting down unidirectional links· 20

Configuring RRPP·· 24

Overview· 24

Basic RRPP concepts· 24

RRPPDUs· 26

RRPP timers· 27

How RRPP works· 27

Typical RRPP networking· 28

Protocols and standards· 31

RRPP configuration task list 32

Creating an RRPP domain· 32

Configuring control VLANs· 32

Configuring protected VLANs· 33

Configuring RRPP rings· 34

Configuring RRPP ports· 34

Configuring RRPP nodes· 35

Activating an RRPP domain· 36

Configuring RRPP timers· 37

Configuring an RRPP ring group· 37

Enabling SNMP notifications for RRPP· 38

Displaying and maintaining RRPP· 38

RRPP configuration examples· 38

Single ring configuration example· 38

Intersecting ring configuration example· 41

Load-balanced intersecting-ring configuration example· 47

Troubleshooting RRPP· 57

Configuring Smart Link· 58

Overview· 58

Terminology· 59

How Smart Link works· 59

Collaboration between Smart Link and Monitor Link· 60

Smart Link configuration task list 60

Configuring a Smart Link device· 61

Configuration prerequisites· 61

Configuring protected VLANs for a smart link group· 61

Configuring member ports for a smart link group· 62

Configuring a preemption mode for a smart link group· 62

Enabling the sending of flush messages· 63

Configuring an associated device· 63

Configuration prerequisites· 63

Enabling the receiving of flush messages· 63

Displaying and maintaining Smart Link· 64

Smart Link configuration examples· 64

Single smart link group configuration example· 64

Multiple smart link groups load sharing configuration example· 69

Configuring Monitor Link· 74

Overview· 74

Configuration restrictions and guidelines· 75

Monitor Link configuration task list 75

Enabling Monitor Link globally· 75

Creating a monitor link group· 75

Configuring monitor link group member interfaces· 76

Configuring the uplink interface threshold for triggering monitor link group state switchover 77

Configuring the switchover delay for the downlink interfaces in a monitor link group· 77

Displaying and maintaining Monitor Link· 77

Monitor Link configuration example· 77

Configuring VRRP·· 82

Overview· 82

VRRP group· 83

VRRP standard mode· 83

Router priority in a VRRP group· 83

Preemption· 84

Authentication method· 84

VRRP timers· 84

Master election· 85

VRRP tracking· 85

VRRP application· 85

VRRP load balancing mode· 87

Virtual MAC address assignment 87

Virtual forwarder 89

Protocols and standards· 91

Configuring IPv4 VRRP· 91

IPv4 VRRP configuration task list 91

Specifying an IPv4 VRRP operating mode· 92

Specifying the IPv4 VRRP version· 92

Creating a VRRP group and assigning a virtual IP address· 92

Configuring the router priority, preemptive mode, and tracking function· 93

Configuring IPv4 VRRP packet attributes· 94

Configuring VF tracking· 95

Enabling SNMP notifications for VRRP· 95

Disabling an IPv4 VRRP group· 96

Displaying and maintaining IPv4 VRRP· 96

Configuring IPv6 VRRP· 96

IPv6 VRRP configuration task list 96

Specifying an IPv6 VRRP operating mode· 97

Creating a VRRP group and assigning a virtual IPv6 address· 97

Configuring the router priority, preemptive mode, and tracking function· 98

Configuring VF tracking· 99

Configuring IPv6 VRRP packet attributes· 99

Disabling an IPv6 VRRP group· 100

Displaying and maintaining IPv6 VRRP· 100

IPv4 VRRP configuration examples· 101

Single VRRP group configuration example· 101

Multiple VRRP groups configuration example· 103

VRRP load balancing configuration example· 106

IPv6 VRRP configuration examples· 114

Single VRRP group configuration example· 114

Multiple VRRP groups configuration example· 117

VRRP load balancing configuration example· 121

Troubleshooting VRRP· 129

An error prompt is displayed· 129

Multiple masters appear in a VRRP group· 129

Fast VRRP state flapping· 130

Configuring BFD·· 131

Overview· 131

BFD session establishment and termination· 131

BFD session modes and operating modes· 131

Supported features· 132

Protocols and standards· 132

Configuring BFD basic functions· 133

Configuring echo packet mode· 133

Configuring control packet mode· 134

Enabling SNMP notifications for BFD·· 135

Displaying and maintaining BFD·· 135

Configuring Track· 136

Overview· 136

Collaboration fundamentals· 136

Collaboration application example· 137

Track configuration task list 137

Associating the Track module with a detection module· 138

Associating Track with NQA· 138

Associating Track with BFD·· 138

Associating Track with interface management 139

Associating Track with route management 139

Associating the Track module with an application module· 140

Associating Track with VRRP· 140

Associating Track with static routing· 141

Associating Track with PBR· 142

Associating Track with VXLAN· 144

Associating Track with EAA· 144

Displaying and maintaining track entries· 145

Track configuration examples· 145

VRRP-Track-NQA collaboration configuration example· 145

Configuring BFD for a VRRP backup to monitor the master 149

Configuring BFD for the VRRP master to monitor the uplinks· 151

Static routing-Track-NQA collaboration configuration example· 155

Static routing-Track-BFD collaboration configuration example· 159

VRRP-Track-interface management collaboration configuration example· 162

VRRP-Track-route management collaboration configuration example· 165

Configuring process placement 169

Overview· 169

Process· 169

1:N process redundancy· 169

Process placement policy and optimization· 169

Configuration restrictions and guidelines· 170

Process placement configuration task list 171

Configuring process placement policy· 171

Configuring a location affinity· 171

Configuring a location type affinity· 171

Configuring a process affinity· 172

Configuring a self affinity· 172

Optimizing process placement 173

Displaying process placement 173

Index· 174


Configuring Ethernet OAM

Overview

Ethernet Operation, Administration, and Maintenance (OAM) is a tool that monitors Layer 2 link status and 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—Checks the connectivity of a link by sending OAM protocol data units (OAMPDUs) and reports to the network administrators when a link error occurs.

·     Remote loopback—Checks 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 that the administrator can effectively manage the network.

Ethernet OAMPDUs include the following types shown in Table 1.

Table 1 Functions of different types of OAMPDUs

OAMPDU type

Function

Information OAMPDU

Used for transmitting 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, and maintaining OAM connections.

Event Notification OAMPDU

Used by link monitoring to notify the remote OAM entity when it detects problems on the link in between.

Loopback Control OAMPDU

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.

 

 

NOTE:

Throughout this document, an Ethernet OAM-enabled port is called an Ethernet OAM entity or an OAM entity.

 

How Ethernet OAM works

This section describes the working procedures of Ethernet OAM.

Ethernet OAM connection establishment

Ethernet OAM connection is the basis of all the other Ethernet OAM functions. OAM connection establishment 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. To set up an OAM connection between two OAM entities, you must set at least one entity to operate in active mode.

Table 2 shows the actions that a device can perform in different modes.

Table 2 Active Ethernet OAM mode and passive Ethernet OAM mode

Item

Active Ethernet OAM mode

Passive Ethernet OAM mode

Initiating OAM Discovery

Available

Unavailable

Responding to OAM Discovery

Available

Available

Transmitting Information OAMPDUs

Available

Available

Transmitting Event Notification OAMPDUs

Available

Available

Transmitting Information OAMPDUs without any TLV

Available

Available

Transmitting Loopback Control OAMPDUs

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 receives no 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 one of the link error events listed in Table 3, an OAM 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.

Table 3 Ethernet OAM link error events

Ethernet OAM link events

Description

Errored symbol event

An errored symbol event occurs when the number of detected symbol errors in the detection window (specified number of received symbols) exceeds the predefined threshold.

Errored frame event

An errored frame event occurs when the number of detected error frames in the detection window (specified detection interval) exceeds the predefined threshold.

Errored frame period event

An errored frame period event occurs when the number of frame errors in the detection window (specified number of received frames) exceeds the predefined threshold.

Errored frame seconds event

An errored frame seconds event occurs when the number of errored frame seconds (the second in which an errored frame appears is called an errored frame second) detected on a port in the detection window (specified detection interval) reaches the predefined threshold.

 

Protocols and standards

IEEE 802.3ah, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications

Ethernet OAM configuration task list

Tasks at a glance

(Required.) Configuring basic Ethernet OAM functions

(Optional.) Configuring the Ethernet OAM connection detection timers

(Optional.) Configuring link monitoring

·     Configuring errored symbol event detection

·     Configuring errored frame event detection

·     Configuring errored frame period event detection

·     Configuring errored frame seconds event detection

(Optional.) Configuring the action a port takes after it receives an Ethernet OAM event from the remote end

 

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. An Ethernet OAM entity can initiate OAM connection only in active mode.

To change the Ethernet OAM mode on an Ethernet OAM-enabled port, first disable Ethernet OAM on the port.

To configure basic Ethernet OAM functions:

 

Step

Command

Remarks

1.     Enter system view.

System-view

N/A

2.     Enter Layer 2 Ethernet port view.

interface interface-type interface-number

N/A

3.     Set the Ethernet OAM mode.

oam mode { active | passive }

The default is active Ethernet OAM mode.

4.     Enable Ethernet OAM.

oam enable

Ethernet OAM is disabled by default.

 

Configuring the Ethernet OAM connection detection timers

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.

You can configure this command in system view or port view. The configuration in system view takes effect on all ports, and the configuration in port view takes effect on the specified port. For a port, the configuration in port view takes precedence.

After the timeout timer of an Ethernet OAM connection expires, the local OAM entity ages out and terminates its connection with the peer OAM entity. To keep the Ethernet OAM connections stable, set the connection timeout timer to be at least five times the handshake packet transmission interval.

To configure the Ethernet OAM connection detection timers globally:

 

Step

Command

Remarks

1.     Enter system view.

System-view

N/A

2.     Configure the Ethernet OAM handshake packet transmission interval.

oam global timer hello interval

The default is 1000 milliseconds.

3.     Configure the Ethernet OAM connection timeout timer.

oam global timer keepalive interval

The default is 5000 milliseconds.

 

To configure the Ethernet OAM connection detection timers on a port:

 

Step

Command

Remarks

1.     Enter system view.

System-view

N/A

2.     Enter Layer 2/Layer 3 Ethernet port view.

interface interface-type interface-number

N/A

3.     Configure the Ethernet OAM handshake packet transmission interval.

oam timer hello interval

By default, an interface uses the value configured globally.

4.     Configure the Ethernet OAM connection timeout timer.

oam timer keepalive interval

By default, an interface uses the value configured globally.

 

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.

Configuring errored symbol event detection

An errored symbol event occurs when the number of detected symbol errors in the detection window exceeds the predefined threshold. The detection window refers to the specified number of received symbols.

You can configure this command in system view or port view. The configuration in system view takes effect on all ports, and the configuration in port view takes effect on the specified port. For a port, the configuration in port view takes precedence.

To configure errored symbol event detection globally:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the errored symbol event detection window.

oam global errored-symbol-period window window-value

By default, the errored symbol event detection window is 100000000.

3.     Configure the errored symbol event triggering threshold.

oam global errored-symbol-period threshold threshold-value

By default, the errored symbol event triggering threshold is 1.

 

To configure errored symbol event detection on a port:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2/Layer 3 Ethernet port view.

interface interface-type interface-number

N/A

3.     Configure the errored symbol event detection window.

oam errored-symbol-period window window-value

By default, an interface uses the value configured globally.

4.     Configure the errored symbol event triggering threshold.

oam errored-symbol-period threshold threshold-value

By default, an interface uses the value configured globally.

 

Configuring errored frame event detection

An errored frame event occurs when the number of times that error frames in the detection window are detected exceeds the predefined threshold. The detection window refers to the specified detection interval.

You can configure this command in system view or port view. The configuration in system view takes effect on all ports, and the configuration in port view takes effect on the specified port. For a port, the configuration in port view takes precedence.

To configure errored frame event detection globally:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the errored frame event detection window.

oam global errored-frame window window-value

By default, the errored frame event detection window is 1000 milliseconds.

3.     Configure the errored frame event triggering threshold.

oam global errored-frame threshold threshold-value

By default, the errored frame event triggering threshold is 1.

 

To configure errored frame event detection on a port:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2/Layer 3 Ethernet port view.

interface interface-type interface-number

N/A

3.     Configure the errored frame event detection window.

oam errored-frame window window-value

By default, an interface uses the value configured globally.

4.     Configure the errored frame event triggering threshold.

oam errored-frame threshold threshold-value

By default, an interface uses the value configured globally.

 

Configuring errored frame period event detection

An errored frame period event occurs when the number of times that frame errors in the detection window are detected exceeds the predefined threshold. The detection window refers to the specified number of received frames.

You can configure this command in system view or port view. The configuration in system view takes effect on all ports, and the configuration in port view takes effect on the specified port. For a port, the configuration in port view takes precedence.

To configure errored frame period event detection globally:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the errored frame period event detection window.

oam global errored-frame-period window window-value

By default, the errored frame period event detection window is 10000000.

3.     Configure the errored frame period event triggering threshold.

oam global errored-frame-period threshold threshold-value

By default, the errored frame period event triggering threshold is 1.

 

To configure errored frame period event detection on a port:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2/Layer 3 Ethernet port view.

interface interface-type interface-number

N/A

3.     Configure the errored frame period event detection window.

oam errored-frame-period window window-value

By default, an interface uses the value configured globally.

4.     Configure the errored frame period event triggering threshold.

oam errored-frame-period threshold threshold-value

By default, an interface uses the value configured globally.

 

Configuring errored frame seconds event detection

CAUTION

CAUTION:

Make sure the errored frame seconds triggering threshold is less than the errored frame seconds detection window. Otherwise, no errored frame seconds event can be generated.

 

An errored frame seconds event occurs when the number of times that errored frame seconds are detected on a port in the detection window exceeds the predefined threshold. The detection window refers to the specified detection interval

You can configure this command in system view or port view. The configuration in system view takes effect on all ports, and the configuration in port view takes effect on the specified port. For a port, the configuration in port view takes precedence.

To configure errored frame seconds event detection globally:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the errored frame seconds event detection window.

oam global errored-frame-seconds window window-value

By default, the errored frame seconds event detection window is 60000 milliseconds.

3.     Configure the errored frame seconds event triggering threshold.

oam global errored-frame-seconds threshold threshold-value

By default, the errored frame seconds event triggering threshold is 1.

 

To configure errored frame seconds event detection on a port:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2/Layer 3 Ethernet port view.

interface interface-type interface-number

N/A

3.     Configure the errored frame seconds event detection window.

oam errored-frame-seconds window window-value

By default, an interface uses the value configured globally.

4.     Configure the errored frame seconds event triggering threshold.

oam errored-frame-seconds threshold threshold-value

By default, an interface uses the value configured globally.

 

Configuring the action a port takes after it receives an Ethernet OAM event from the remote end

This feature enables a port to log events and automatically terminate the OAM connection and set the link state to down.

To configure the action the port takes after it receives an Ethernet OAM event from the remote end:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2/Layer 3 Ethernet port view.

interface interface-type interface-number

N/A

3.     Configure the action the port takes after it receives an Ethernet OAM event from the remote end.

oam remote-failure { connection-expired | critical-event | dying-gasp | link-fault } action error-link-down

By default, the port only logs the Ethernet OAM event it receives from the remote end.

 

Displaying and maintaining Ethernet OAM

Execute display commands in any view and reset commands in user view:

 

Task

Command

Display information about an Ethernet OAM connection.

display oam { local | remote } [ interface interface-type interface-number ]

Display Ethernet OAM configuration.

display oam configuration [ interface interface-type interface-number ]

Display the statistics on critical events after an Ethernet OAM connection is established.

display oam critical-event [ interface interface-type interface-number ]

Display the statistics on Ethernet OAM link error events after an Ethernet OAM connection is established.

display oam link-event { local | remote } [ interface interface-type interface-number ]

Clear statistics on Ethernet OAM packets and Ethernet OAM link error events.

reset oam [ interface interface-type interface-number ]

 

Ethernet OAM configuration example

Network requirements

On the network shown in Figure 1, perform the following operations:

·     Enable Ethernet OAM on Device A and Device B to auto-detect link errors between the two devices

·     Determine the performance of the link between Device A and Device B by collecting statistics about the error frames received by Device A

Figure 1 Network diagram

Configuration procedure

1.     Configure Device A:

# Configure HundredGigE 1/0/1 to operate in active Ethernet OAM mode, and enable Ethernet OAM for it.

<DeviceA> system-view

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] oam mode active

[DeviceA-HundredGigE1/0/1] oam enable

# Set the errored frame event detection window to 20000 milliseconds, and set the errored frame event triggering threshold to 10.

[DeviceA-HundredGigE1/0/1] oam errored-frame window 200

[DeviceA-HundredGigE1/0/1] oam errored-frame threshold 10

[DeviceA-HundredGigE1/0/1] quit

2.     Configure Device B:

# Configure HundredGigE 1/0/1 to operate in passive Ethernet OAM mode (the default), and enable Ethernet OAM for it.

<DeviceB> system-view

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] oam mode passive

[DeviceB-HundredGigE1/0/1] oam enable

[DeviceB-HundredGigE1/0/1] quit

3.     Verify the configuration:

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 the ports of Device A.

[DeviceA] display oam critical-event

-----------[HundredGigE1/0/1] -----------

 Local link status   : UP

 Event statistics

   Link fault        : Not occurred

   Dying gasp        : Not occurred

   Critical event    : Not occurred

The output shows that no critical link event occurred on the link between Device A and Device B.

Use the display oam link-event command to display the statistics of Ethernet OAM link events. For example:

# Display Ethernet OAM link event statistics of the local end of Device A.

[DeviceA] display oam link-event local

------------ [HundredGigE1/0/1] -----------

 Link status: UP

 OAM local errored frame event

   Event time stamp        : 5789 x 100 milliseconds

   Errored frame window    : 200 x 100 milliseconds

   Errored frame threshold : 10 error frames

   Errored frame           : 13 error frames

   Error running total     : 350 error frames

   Event running total     : 17 events

The output shows the following:

¡     350 errors occurred after Ethernet OAM is enabled on Device A.

¡     17 errors were caused by error frames.

¡     The link is unstable.

 


Configuring DLDP

Overview

A link becomes unidirectional when only one end of the link can receive packets from the other end.

Unidirectional fiber links occur in the following cases:

·     Fibers are cross-connected.

·     A fiber is not connected at one end or one fiber of a fiber pair is broken.

Figure 2 shows a correct fiber connection and two types of unidirectional fiber connections.

Figure 2 Correct and incorrect fiber connections

 

Physical layer detection mechanisms, such as auto-negotiation, can detect physical signals and faults. However, they cannot detect communication failures for unidirectional links where the physical layer is in connected state.

As a data link layer protocol, the Device Link Detection Protocol (DLDP) detects the following:

·     Whether the fiber link or twisted-pair link is correctly connected at the link layer.

·     Whether the two ends of the link can exchange packets correctly.

When DLDP detects unidirectional links, it can automatically shut down the faulty port to avoid network problems. Alternatively, a user can manually shut down the faulty port. DLDP cooperates with physical layer protocols to monitor link status and avoid physical and logical unidirectional links.

Basic concepts

DLDP neighbor states

If port A can receive link-layer packets from port B on the same link, port B is a DLDP neighbor of port A. Two ports that can exchange packets are neighbors.

Table 4 DLDP neighbor states

DLDP timer

Description

Confirmed

The link to a DLDP neighbor is bidirectional.

Unconfirmed

The state of the link to a newly discovered neighbor is not determined.

 

DLDP port states

A DLDP-enabled port is called a DLDP port. A DLDP port can have multiple neighbors, and its state varies by the DLDP neighbor state.

Table 5 DLDP port states

State

Description

Initial

DLDP is enabled on the port, but is disabled globally.

Inactive

DLDP is enabled on the port and globally, and the link is physically down.

Bidirectional

DLDP is enabled on the port and globally, and at least one neighbor in Confirmed state exists.

Unidirectional

DLDP is enabled on the port and globally, and no neighbor in Confirmed state exists. In this state, a port does not send or receive packets other than DLDP packets any more.

 

DLDP timers

Table 6 DLDP timers

DLDP timer

Description

Advertisement timer

Advertisement packet sending interval (the default is 5 seconds and is configurable).

Probe timer

Probe packet sending interval. This timer is set to 1 second.

Echo timer

The Echo timer is triggered when a probe is launched for a new neighbor. This timer is set to 10 seconds.

Entry timer

When a new neighbor joins, a neighbor entry is created and the corresponding entry timer is triggered if the neighbor is in Confirmed state. When an Advertisement is received, the device updates the corresponding neighbor entry and the Entry timer.

The setting of an Entry timer is three times that of the Advertisement timer.

Enhanced timer

The Enhanced timer is triggered, together with the Echo timer, when the Entry timer expires. The Enhanced timer is set to 1 second.

DelayDown timer

If a port is physically down, the device triggers the DelayDown timer, rather than removing the corresponding neighbor entry. The default DelayDown timer is 1 second and is configurable.

When the DelayDown timer expires, the device removes the corresponding DLDP neighbor information if the port is down, and does not perform any operation if the port is up.

RecoverProbe timer

This timer is set to 2 seconds. A port in Unidirectional state regularly sends RecoverProbe packets to detect whether a unidirectional link has been restored to bidirectional.

 

DLDP authentication mode

You can use DLDP authentication to prevent network attacks and illegal detecting.

Table 7 DLDP authentication mode

Authentication mode

Processing at the DLDP packet sending side

Processing at the DLDP packet receiving side

Non-authentication

The sending side sets the Authentication field of DLDP packets to 0.

The receiving side examines the authentication information of received DLDP packets and drops packets where the authentication information conflicts with the local configuration.

Plaintext authentication

The sending side sets the Authentication field to the password configured in plain text.

MD5 authentication

The sending side encrypts the user configured password by using MD5 algorithm, and assigns the digest to the Authentication field.

 

How DLDP works

Detecting one neighbor

When two devices are connected through an optical fiber or a network cable, enable DLDP to detect unidirectional links to the neighbor. The following illustrates the unidirectional link detection process in two cases:

·     Unidirectional links occur before you enable DLDP.

Figure 3 Cross-connected fibers

 

As shown in Figure 3, before you enable DLDP, the optical fibers between Device A and Device B are cross-connected. After you enable DLDP, the four ports are all up and in Unidirectional state, and they send RecoverProbe packets. Take Port 1 as an example to illustrate the unidirectional link detection process.

a.     Port 1 receives the RecoverProbe packet from Port 4, and returns a RecoverEcho packet.

b.     Port 4 cannot receive any RecoverEcho packet from Port 1, so Port 4 cannot become the neighbor of Port 1.

c.     Port 3 can receive the RecoverEcho packet from Port 1, but Port 3 is not the intended destination, so Port 3 cannot become the neighbor of Port 1.

The same process occurs on the other three ports. The four ports are all in Unidirectional state.

·     Unidirectional links occur after you enable DLDP.

Figure 4 Broken fiber

 

As shown in Figure 4, Device A and Device B are connected through an optical fiber. After you enable DLDP, Port 1 and Port 2 establish the bidirectional neighborship in the following way:

a.     Port 1 that is physically up enters the Unidirectional state and sends a RecoverProbe packet.

b.     After receiving the RecoverProbe packet, Port 2 returns a RecoverEcho packet.

c.     After Port 1 receives the RecoverEcho packet, it examines the neighbor information in the packet. If the neighbor information matches the local information, Port 1 establishes the neighborship with Port 2 and transits to Bidirectional state. Port 1 then starts the Entry timer and periodically sends Advertisement packets.

d.     After Port 2 receives the Advertisement packet, it establishes the Unconfirmed neighborship with Port 1. Port 2 then starts the Echo timer and Probe timer, and periodically sends Probe packets.

e.     After receiving the Probe packet, Port 1 returns an Echo packet.

f.     After Port 2 receives the Echo packet, it examines the neighbor information in the packet. If the neighbor information matches the local information, the neighbor state of Port 1 becomes Confirmed. Port 2 then transits to Bidirectional state, starts the Entry timer, and periodically sends Advertisement packets.

The bidirectional neighborship between Port 1 and Port 2 is now established.

After that, when Port 2's Rx end fails to receive signals, Port 2 is physically down and enters the Inactive state. Because Port 2's Tx end can still send signals to Port 1, Port 1 stays up. After the Entry timer for Port 2 expires, Port 1 starts the Enhanced timer and Echo timer, and sends a probe packet to Port 2. Because Port 1's Tx line is broken, Port 1 cannot receive the Echo packet from Port 2 after the Echo timer expires. Port 1 then enters the Unidirectional state, and sends a Disable packet to Port 2. At the same time, Port 1 deletes the neighborship with Port 2, and starts the RecoverProbe timer. Port 2 stays in Inactive state during this process.

When an interface is physically down, but the Tx end of the interface is still operating, DLDP sends a LinkDown packet to inform the peer to delete the relevant neighbor entry.

Detecting multiple neighbors

When multiple devices are connected through a hub, enable DLDP on all interfaces connected to the hub to detect unidirectional links among the neighbors. When no Confirmed neighbor exists, an interface enters the Unidirectional state.

Figure 5 Network diagram

 

As shown in Figure 5, Device A through Device D are connected through a hub, and enabled with DLDP. When Ports 1, 2, and 3 detect that the link to Port 4 fails, they delete the neighborship with Port 4, but stay in Bidirectional state.

Configuration restrictions and guidelines

When you configure DLDP, follow these configuration restrictions and guidelines:

·     For DLDP to operate correctly, enable DLDP on both sides and make sure the following settings are consistent:

¡     Interval to send Advertisement packets.

¡     DLDP authentication mode.

¡     Password.

·     For DLDP to operate correctly, configure the full duplex mode for the ports at the two ends of the link, and configure the same speed for the two ports.

DLDP configuration task list

Tasks at a glance

(Required.) Enabling DLDP

(Optional.) Setting the interval to send advertisement packets

(Optional.) Setting the DelayDown timer

(Optional.) Setting the port shutdown mode

(Optional.) Configuring DLDP authentication

 

Enabling DLDP

To correctly configure DLDP on the device, you must enable DLDP globally and on each port.

To enable DLDP:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable DLDP globally.

dldp global enable

By default, DLDP is globally disabled.

3.     Enter Ethernet interface view.

interface interface-type interface-number

N/A

4.     Enable DLDP.

dldp enable

By default, DLDP is disabled on an interface.

 

Setting the interval to send advertisement packets

To make sure DLDP can detect unidirectional links before network performance deteriorates, set the advertisement interval appropriate for your network environment. As a best practice, use the default interval.

To set the Advertisement packet sending interval:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Set the interval to send Advertisement packets.

dldp interval interval

By default, the interval is 5 seconds.

 

Setting the DelayDown timer

When the Tx line fails, some ports might go down and then come up again, causing optical signal jitters on the Rx line. To prevent the device from removing neighbor entries in such cases, set the DelayDown timer for the device. The device starts the DelayDown timer when a port goes down due to a Tx line failure. If the port remains down when the timer expires, the device removes the DLDP neighbor information. If the port comes up, the device takes no action.

To set the DelayDown timer:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Set the DelayDown timer.

dldp delaydown-timer time

The default is 1 second.

The DelayDown timer setting applies to all DLDP-enabled ports.

 

Setting the port shutdown mode

On detecting a unidirectional link, DLDP shuts down the ports in one of the following modes:

·     Auto mode—When a unidirectional link is detected, DLDP changes the DLDP port state to Unidirectional. The unidirectional port periodically sends RecoverProbe packets. When a correct RecoverEcho packet is received, the link is restored to a bidirectional link, and the port state changes from Unidirectional to Bidirectional. This process is called link auto-recovery mechanism.

·     Manual mode—When a unidirectional link is detected, DLDP does not shut down the port, and you need to manually shut it down. When the link state is restored to Bidirectional, you must manually bring up the port. Use this mode to prevent normal links from being shut down because of false unidirectional link reports in the following cases:

¡     The network performance is low.

¡     The device is busy.

¡     The CPU usage is high.

To enable remote OAM loopback on a DLDP port, set the port shutdown mode to manual. Otherwise, DLDP automatically shuts down the port when it receives a packet sent by itself. This causes remote OAM loopback failure. For more information about Ethernet OAM, see "Configuring Ethernet OAM."

To set port shutdown mode:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Set port shutdown mode.

dldp unidirectional-shutdown { auto | manual }

The default mode is auto.

 

Configuring DLDP authentication

You can guard your network against attacks and malicious probes by configuring an appropriate DLDP authentication mode, which can be plain text authentication or MD5 authentication. If your network is safe, you can choose not to authenticate.

To configure DLDP authentication:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure a DLDP authentication mode.

dldp authentication-mode { md5 | none | simple }

The default authentication mode is none.

3.     Configure the password for DLDP authentication.

dldp authentication-password { cipher | simple } string

By default, no password is configured for DLDP authentication.

If you do not configure the authentication password after you configure the authentication mode, the authentication mode is none no matter which authentication mode you configure.

 

Displaying and maintaining DLDP

Execute display commands in any view and the reset command in user view.

 

Task

Command

Display the DLDP configuration globally and of a port.

display dldp [ interface interface-type interface-number ]

Display the statistics on DLDP packets passing through a port.

display dldp statistics [ interface interface-type interface-number ]

Clear the statistics on DLDP packets passing through a port.

reset dldp statistics [ interface interface-type interface-number ]

 

DLDP configuration examples

Automatically shutting down unidirectional links

Network requirements

As shown in Figure 6, Device A and Device B are connected through two fiber pairs.

Configure DLDP to automatically shut down the faulty port upon detecting a unidirectional link, and automatically bring up the port after you clear the fault.

Figure 6 Network diagram

Configuration procedure

1.     Configure Device A:

# Enable DLDP globally.

<DeviceA> system-view

[DeviceA] dldp global enable

# Configure HundredGigE 1/0/1 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on the port.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] duplex full

[DeviceA-HundredGigE1/0/1] speed 100000

[DeviceA-HundredGigE1/0/1] dldp enable

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on the port.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] duplex full

[DeviceA-HundredGigE1/0/2] speed 100000

[DeviceA-HundredGigE1/0/2] dldp enable

[DeviceA-HundredGigE1/0/2] quit

# Set the port shutdown mode to auto.

[DeviceA] dldp unidirectional-shutdown auto

2.     Configure Device B:

# Enable DLDP globally.

<DeviceB> system-view

[DeviceB] dldp global enable

# Configure HundredGigE 1/0/1 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on it.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] duplex full

[DeviceB-HundredGigE1/0/1] speed 100000

[DeviceB-HundredGigE1/0/1] dldp enable

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on it.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] duplex full

[DeviceB-HundredGigE1/0/2] speed 100000

[DeviceB-HundredGigE1/0/2] dldp enable

[DeviceB-HundredGigE1/0/2] quit

# Set the port shutdown mode to auto.

[DeviceB] dldp unidirectional-shutdown auto

3.     Verify the configuration:

# Display the DLDP configuration globally and on all the DLDP-enabled ports of Device A.

[DeviceA] display dldp

 DLDP global status: Enabled

 DLDP advertisement interval: 5s

 DLDP authentication-mode: None

 DLDP unidirectional-shutdown mode: Auto

 DLDP delaydown-timer value: 1s

 Number of enabled ports: 2

 

Interface HundredGigE1/0/1

 DLDP port state: Bidirectional

 Number of the port’s neighbors: 1

  Neighbor MAC address: 0023-8956-3600

  Neighbor port index: 1

  Neighbor state: Confirmed

  Neighbor aged time: 11s

 

Interface HundredGigE1/0/2

 DLDP port state: Bidirectional

 Number of the port’s neighbors: 1

  Neighbor MAC address: 0023-8956-3600

  Neighbor port index: 2

  Neighbor state: Confirmed

  Neighbor aged time: 12s

The output shows that both HundredGigE 1/0/1 and HundredGigE 1/0/2 are bidirectional.

# Enable the monitoring of logs on the current terminal on Device A. Set the lowest level of the logs that can be output to the current terminal to 6.

[DeviceA] quit

<DeviceA> terminal monitor

<DeviceA> terminal logging level 6

The following log information is displayed on Device A:

<DeviceA>%Jul 11 17:40:31:089 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is DOWN.

%Jul 11 17:40:31:091 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/1 is DOWN.

%Jul 11 17:40:31:677 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is DOWN.

%Jul 11 17:40:31:678 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/2 is DOWN.

%Jul 11 17:40:38:544 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is UP.

%Jul 11 17:40:38:836 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is UP.

The output shows the following:

¡     The port status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 is down and then up.

¡     The link status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 is always down.

# Display the DLDP configuration globally and of all the DLDP-enabled ports.

<DeviceA> display dldp

 DLDP global status: Enabled

 DLDP advertisement interval: 5s

 DLDP authentication-mode: None

 DLDP unidirectional-shutdown mode: Auto

 DLDP delaydown-timer value: 1s

 Number of enabled ports: 2

 

Interface HundredGigE1/0/1

 DLDP port state: Unidirectional

 Number of the port’s neighbors: 0 (Maximum number ever detected: 1)

 

Interface HundredGigE1/0/2

 DLDP port state: Unidirectional

 Number of the port’s neighbors: 0 (Maximum number ever detected: 1)

The output shows that the DLDP port status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 is unidirectional. DLDP detects unidirectional links on them and automatically shuts down the two ports.

The unidirectional links are caused by cross-connected fibers. Correct the fiber connections. As a result, the ports shut down by DLDP automatically recover, and Device A displays the following log information:

<DeviceA>%Jul 11 17:42:57:709 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is DOWN.

%Jul 11 17:42:58:603 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is DOWN.

%Jul 11 17:43:02:342 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is UP.

%Jul 11 17:43:02:343 2012 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was confirmed on interface HundredGigE1/0/1. The neighbor's system MAC is 0023-8956-3600, and the port index is 1.

%Jul 11 17:43:02:344 2012 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a bidirectional link on interface HundredGigE1/0/1.

%Jul 11 17:43:02:353 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/1 is UP.

%Jul 11 17:43:02:357 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is UP.

%Jul 11 17:43:02:362 2012 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was confirmed on interface HundredGigE1/0/2. The neighbor's system MAC is 0023-8956-3600, and the port index is 2.

%Jul 11 17:43:02:362 2012 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a bidirectional link on interface HundredGigE1/0/2.

%Jul 11 17:43:02:368 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/2 is UP.

The output shows that the port status and link status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 are now up and their DLDP neighbors are determined.

Manually shutting down unidirectional links

Network requirements

As shown in Figure 7, Device A and Device B are connected through two fiber pairs.

Configure DLDP to detect unidirectional links. When a unidirectional link is detected, the administrator must manually shut down the port.

Figure 7 Network diagram

Configuration procedure

1.     Configure Device A:

# Enable DLDP globally.

<DeviceA> system-view

[DeviceA] dldp enable

# Configure HundredGigE 1/0/1 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on the port.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] duplex full

[DeviceA-HundredGigE1/0/1] speed 100000

[DeviceA-HundredGigE1/0/1] dldp enable

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on the port.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] duplex full

[DeviceA-HundredGigE1/0/2] speed 100000

[DeviceA-HundredGigE1/0/2] dldp enable

[DeviceA-HundredGigE1/0/2] quit

# Set the port shutdown mode to manual.

[DeviceA] dldp unidirectional-shutdown manual

2.     Configure Device B:

# Enable DLDP globally.

<DeviceB> system-view

[DeviceB] dldp global enable

# Configure HundredGigE 1/0/1 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on it.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] duplex full

[DeviceB-HundredGigE1/0/1] speed 100000

[DeviceB-HundredGigE1/0/1] dldp enable

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 to operate in full duplex mode and at 100000 Mbps, and enable DLDP on it.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] duplex full

[DeviceB-HundredGigE1/0/2] speed 100000

[DeviceB-HundredGigE1/0/2] dldp enable

[DeviceB-HundredGigE1/0/2] quit

# Set the port shutdown mode to manual.

[DeviceB] dldp unidirectional-shutdown manual

3.     Verify the configuration:

# Display the DLDP configuration globally and on all the DLDP-enabled ports of Device A.

[DeviceA] display dldp

 DLDP global status: Enabled

 DLDP advertisement interval: 5s

 DLDP authentication-mode: None

 DLDP unidirectional-shutdown mode: Manual

 DLDP delaydown-timer value: 1s

 Number of enabled ports: 2

 

Interface HundredGigE1/0/1

 DLDP port state: Bidirectional

 Number of the port’s neighbors: 1

  Neighbor MAC address: 0023-8956-3600

  Neighbor port index: 1

  Neighbor state: Confirmed

  Neighbor aged time: 11s

 

Interface HundredGigE1/0/2

 DLDP port state: Bidirectional

 Number of the port’s neighbors: 1

  Neighbor MAC address: 0023-8956-3600

  Neighbor port index: 2

  Neighbor state: Confirmed

  Neighbor aged time: 12s

The output shows that both HundredGigE 1/0/1 and HundredGigE 1/0/2 are in Bidirectional state, which means both links are bidirectional.

# Enable the monitoring of logs on the current terminal on Device A. Set the lowest level of the logs that can be output to the current terminal to 6.

[DeviceA] quit

<DeviceA> terminal monitor

<DeviceA> terminal logging level 6

The following log information is displayed on Device A:

<DeviceA>%Jul 12 08:29:17:786 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is DOWN.

%Jul 12 08:29:17:787 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/1 is DOWN.

%Jul 12 08:29:17:800 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is DOWN.

%Jul 12 08:29:17:800 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/2 is DOWN.

%Jul 12 08:29:25:004 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is UP.

%Jul 12 08:29:25:005 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/1 is UP.

%Jul 12 08:29:25:893 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is UP.

%Jul 12 08:29:25:894 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/2 is UP.

The output shows that the port status and link status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 are down and then up.

# Display the DLDP configuration globally and of all the DLDP-enabled ports.

<DeviceA> display dldp

 DLDP global status: Enabled

 DLDP advertisement interval: 5s

 DLDP authentication-mode: None

 DLDP unidirectional-shutdown mode: Manual

 DLDP delaydown-timer value: 1s

 Number of enabled ports: 2

 

Interface HundredGigE1/0/1

 DLDP port state: Unidirectional

 Number of the port’s neighbors: 0 (Maximum number ever detected: 1)

 

Interface HundredGigE1/0/2

 DLDP port state: Unidirectional

 Number of the port’s neighbors: 0 (Maximum number ever detected: 1)

The output shows that the DLDP port status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 is unidirectional. DLDP detects unidirectional links on the two ports but does not shut them down.

The unidirectional links are caused by cross-connected fibers. Manually shut down the two ports:

# Shut down HundredGigE 1/0/1.

<DeviceA> system-view

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] shutdown

The following log information is displayed on Device A:

[DeviceA-HundredGigE1/0/1]%Jul 12 08:34:23:717 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is DOWN.

%Jul 12 08:34:23:718 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/1 is DOWN.

%Jul 12 08:34:23:778 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is DOWN.

%Jul 12 08:34:23:779 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/2 is DOWN.

The output shows that the port status and link status of both HundredGigE 1/0/1 and HundredGigE 1/0/2 are now down.

# Shut down HundredGigE 1/0/2.

[DeviceA-HundredGigE1/0/1] quit

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] shutdown

Correct the fiber connections and bring up the two ports:

# Bring up HundredGigE 1/0/2.

[DeviceA-HundredGigE1/0/2] undo shutdown

The following log information is displayed on Device A:

[DeviceA-HundredGigE1/0/2]%Jul 12 08:46:17:677 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/2 link status is UP.

%Jul 12 08:46:17:678 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/2 is UP.

%Jul 12 08:46:17:959 2012 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was confirmed on interface HundredGigE1/0/2. The neighbor's system MAC is 0023-8956-3600, and the port index is 2.

%Jul 12 08:46:17:959 2012 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a bidirectional link on interface HundredGigE1/0/2.

The output shows that the port status and link status of HundredGigE 1/0/2 are now up and its DLDP neighbors are determined.

# Bring up HundredGigE 1/0/1.

[DeviceA-HundredGigE1/0/2] quit

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] undo shutdown

The following log information is displayed on Device A:

[DeviceA-HundredGigE1/0/1]%Jul 12 08:48:25:952 2012 DeviceA IFNET/3/PHY_UPDOWN: HundredGigE1/0/1 link status is UP.

%Jul 12 08:48:25:952 2012 DeviceA DLDP/6/DLDP_NEIGHBOR_CONFIRMED: A neighbor was confirmed on interface HundredGigE1/0/1. The neighbor's system MAC is 0023-8956-3600, and the port index is 1.

%Jul 12 08:48:25:953 2012 DeviceA IFNET/5/LINK_UPDOWN: Line protocol on the interface HundredGigE1/0/1 is UP.

%Jul 12 08:48:25:953 2012 DeviceA DLDP/6/DLDP_LINK_BIDIRECTIONAL: DLDP detected a bidirectional link on interface HundredGigE1/0/1.

The output shows that the port status and link status of HundredGigE 1/0/1 are now up and its DLDP neighbors are determined.

 


Configuring RRPP

Overview

Metropolitan area networks (MANs) and enterprise networks typically use the ring topology to improve reliability. However, services will be interrupted if any node in the ring network fails. A ring network typically uses RPR or Ethernet rings. RPR is high in cost because it needs dedicated hardware. In contrast, the Ethernet ring technology is more mature and economical, so it is more and more popular in MANs and enterprise networks.

The Rapid Ring Protection Protocol (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. RRPP can also rapidly restore the communication paths between the nodes when a link is disconnected on the ring. The convergence time of RRPP is independent of the number of nodes in the Ethernet ring. RRPP is applicable to large-diameter networks.

Basic RRPP concepts

Figure 8 shows a typical RRPP network with two Ethernet rings and multiple nodes. RRPP detects ring status and sends topology change information by exchanging Rapid Ring Protection Protocol Data Units (RRPPDUs) among the nodes.

Figure 8 RRPP networking diagram

 

RRPP domain

An RRPP domain is uniquely identified by a domain ID. The interconnected devices with the same domain ID and control VLANs constitute an RRPP domain. An RRPP domain contains the following elements:

·     Primary ring and subring.

·     Control VLAN.

·     Master node, transit node, edge node, and assistant edge node.

·     Primary port, secondary port, common port, and edge port.

As shown in Figure 8, Domain 1 is an RRPP domain, containing two RRPP rings: Ring 1 and Ring 2. All the nodes on the two RRPP rings belong to the RRPP domain.

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 of level 0, and a subring is of 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 not connected.

As shown in Figure 8, Domain 1 contains two RRPP rings: Ring 1 and Ring 2. The level is set to 0 for Ring 1 and 1 for Ring 2. Ring 1 is configured as the primary ring, and Ring 2 is configured as a subring.

Control VLAN and protected VLAN

1.     Control VLAN

In an RRPP domain, a control VLAN is dedicated to transferring RRPPDUs. On a device, the ports accessing an RRPP ring belong to the control VLANs of the ring, and only these ports can join the control VLANs.

An RRPP domain is configured with the following control VLANs:

¡     One primary control VLAN, which is the control VLAN for the primary ring.

¡     One secondary control VLAN, which is the control VLAN for subrings.

After you specify a VLAN as the primary control VLAN, the system automatically configures the secondary control VLAN. The VLAN ID is the primary control VLAN ID plus one. All subrings in the same RRPP domain share the same secondary control VLAN. IP address configuration is prohibited on the control VLAN interfaces.

2.     Protected VLAN

A protected VLAN is dedicated to transferring data packets. Both RRPP ports and non-RRPP ports can be assigned to a protected 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 topology change.

·     Transit node—On the primary ring, transit nodes refer to all nodes except the master node. On the subring, transit nodes refer to all nodes except the master node and the nodes where the primary ring intersects with the subring. A transit node monitors the state of its directly connected RRPP links and notifies the master node of the link state changes, if any. Based on the link state changes, the master node determines 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 acts as a master node or transit node on the primary ring and as 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 acts as a master node or transit node on the primary ring and as 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 to perform loop guard.

As shown in Figure 8, 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.

Port

1.     Primary port and secondary port

Each master node or transit node has two ports connected to an RRPP ring, a primary port and a secondary port. You can determine the role of a port.

In terms of functionality, the primary port and the secondary port of a master node have the following differences:

¡     The primary port and the secondary port are designed to play the role of sending and receiving Hello packets, respectively.

¡     When an RRPP ring is in Health state, the secondary port logically denies protected VLANs and permits only the packets from the control VLANs.

¡     When an RRPP ring is in Disconnect state, the secondary port forwards packets from protected VLANs.

In terms of functionality, the primary port and the secondary port of a transit node are the same. Both are designed for transferring protocol packets and data packets over an RRPP ring.

As shown in Figure 8, Device A is the master node of Ring 1. Port 1 and Port 2 are the primary port and the secondary port of the master node on Ring 1, respectively. Device B, Device C, and Device D are the transit nodes of Ring 1. Their Port 1 and Port 2 are the primary port and the secondary port on Ring 1, respectively.

2.     Common port and edge port

The ports connecting the edge node and assistant edge node to the primary ring are common ports. The ports connecting the edge node and assistant edge node only to the subrings are edge ports. You can determine the role of a port.

As shown in Figure 8, Device B and Device C reside on Ring 1 and Ring 2. Device B's Port 1 and Port 2 and 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, you can configure a group of subrings on the edge node or assistant edge node. 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). 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. Only 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 8 RRPPDU types and their functions

Type

Description

Hello

The master node sends Hello packets (also known as Health packets) to detect the integrity of a ring in a network.

Link-Down

When a port on the transit node, edge node, or assistant edge node fails, the node initiates Link-Down packets to notify the master node of the disconnection of the ring.

Common-Flush-FDB

When an RRPP ring transits to Disconnect state, the master node initiates Common-Flush-FDB (FDB stands for Forwarding Database) packets. It uses the packets to instruct the transit nodes, edge nodes, and assistant edge nodes to update their own MAC address entries and ARP/ND entries.

Complete-Flush-FDB

When an RRPP ring transits to Health state, the master node sends Complete-Flush-FDB packets for the following purposes:

·     Instruct the transit nodes, edge nodes, and assistant edge nodes to update their MAC address entries and ARP/ND entries.

·     Instruct the transit nodes to unblock temporarily blocked ports.

Edge-Hello

The edge node sends Edge-Hello packets to examine the SRPTs between the edge node and the assistant edge node.

Major-Fault

The assistant edge node sends Major-Fault packets to notify the edge node of SRPT failure when an SRPT between assistant edge node and edge node is disconnected.

 

RRPP timers

When RRPP determines the link state of an Ethernet ring, it uses the following timers:

·     Hello timer—Specifies the interval at which the master node sends Hello packets out of the primary port.

·     Fail timer—Specifies the maximum delay of Hello packets sent from the primary port to the secondary port of the master node. If the secondary port receives the Hello packets sent by the local master node before the Fail timer expires, the ring is in Health state. Otherwise, the ring transits to Disconnect state.

In an RRPP domain, a transit node learns the Fail timer value on the master node through the received Hello packets. This ensures that all nodes in the ring network have consistent Fail timer settings.

How 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.

The master node sends Hello packets out of its primary port at the Hello interval. 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. The master node keeps the secondary port blocked.

·     If the ring is disconnected, 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 protected VLANs. It sends Common-Flush-FDB packets to instruct all transit nodes to update their own MAC address entries and ARP/ND entries.

Load balancing

In a ring network, traffic from multiple VLANs might be transmitted at the same time. RRPP can implement load balancing by transmitting traffic from different VLANs along different paths.

You can configure multiple RRPP domains for a ring network. Each RRPP domain transmits the traffic from the specified VLANs (protected VLANs). Traffic from different VLANs can be transmitted according to different topologies in the ring network for load balancing.

As shown in Figure 13, 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.

Link down alarm mechanism

In an RRPP domain, when the transit node, edge node, or assistant edge node finds that any of its ports is down, it immediately sends Link-Down packets to the master node. When the master node receives a Link-Down packet, it takes the following actions:

·     Releases the secondary port from blocking protected VLANs.

·     Sends Common-Flush-FDB packets to instruct all the transit nodes, edge nodes, and assistant edge nodes to update their MAC address entries and ARP/ND entries.

After each node updates its own entries, traffic is switched to the normal link.

Ring recovery

When the ports in an RRPP domain on the transit nodes, edge nodes, or assistant edge nodes come up again, the ring is recovered. However, the master node might detect the ring recovery after a period of time. A temporary loop might arise in the protected VLAN during this period. As a result, a broadcast storm occurs.

To prevent such cases, non-master nodes block the ports immediately when they find the ports accessing the ring are brought up again. The nodes block only the packets from the protected VLAN, and they permit only the packets from the control VLAN to pass through. The blocked ports are activated only when the nodes determine that no loop will be generated by these ports.

Broadcast storm suppression mechanism in case of SRPT failure in a multi-homed subring

As shown in Figure 12, 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 will open their secondary ports. A loop is generated among Device B, Device C, Device E, and Device F, causing a broadcast storm.

To avoid generating a loop, the edge node will temporarily block the edge port. The blocked edge port is activated only when the edge node determines that no loop will be generated when the edge port is activated.

RRPP ring group

In an edge node RRPP ring group, only the activated subring with the smallest 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 will forward these packets to the other activated subrings. When an edge node RRPP ring group and an assistant edge node RRPP ring group are configured, the CPU workload is reduced because of the following reasons:

·     Only one subring sends Edge-Hello packets on the edge node.

·     Only one subring receives Edge-Hello packets on the assistant edge node.

As shown in Figure 12, Device B is the edge node of Ring 2 and Ring 3. Device C is the assistant edge node of Ring 2 and Ring 3. Device B and Device C need to send or receive Edge-Hello packets frequently. If more subrings are configured or more domains are configured for load balancing, Device B and Device C will send or receive a large number of Edge-Hello packets.

To reduce Edge-Hello traffic, perform the following tasks:

·     Assign Ring 2 and Ring 3 to an RRPP ring group configured on the edge node Device B.

·     Assign Ring 2 and Ring 3 to an RRPP ring group configured on the assistant edge node Device C.

If all rings are activated, only Ring 2 on Device B sends Edge-Hello packets.

Typical RRPP networking

Single ring

As shown in Figure 9, only a single ring exists in the network topology. You need only define an RRPP domain.

Figure 9 Schematic diagram for a single-ring network

 

Tangent rings

As shown in Figure 10, 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 10 Schematic diagram for a tangent-ring network

 

Intersecting rings

As shown in Figure 11, two or more rings exist in the network topology and two common nodes exist between rings. You need only define an RRPP domain and configure one ring as the primary ring and the other rings as subrings.

Figure 11 Schematic diagram for an intersecting-ring network

 

Dual-homed rings

As shown in Figure 12, two or more rings exist in the network topology and two similar common nodes exist between rings. You need only define an RRPP domain and configure one ring as the primary ring and the other rings as subrings.

Figure 12 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.

As shown in Figure 13:

·     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.

Figure 13 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 14:

·     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.

Traffic from different VLANs can travel over different paths in the subring and primary ring.

Figure 14 Schematic diagram for an intersecting-ring load balancing network

 

Protocols and standards

RFC 3619, Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1

RRPP configuration task list

You can configure RRPP in the following order:

·     Create RRPP domains based on service planning.

·     Specify control VLANs and protected VLANs for each RRPP domain.

·     Determine the ring roles and node roles based on the traffic paths in each RRPP domain.

RRPP does not have an auto election mechanism. You must configure each node in the ring network correctly for RRPP to monitor and protect the ring network.

Before you configure RRPP, you must physically construct a ring-shaped Ethernet topology.

To configure RRPP, perform the following tasks:

 

Tasks at a glance

Remarks

(Required.) Creating an RRPP domain

Perform this task on all nodes in the RRPP domain.

(Required.) Configuring control VLANs

Perform this task on all nodes in the RRPP domain.

(Required.) Configuring protected VLANs

Perform this task on all nodes in the RRPP domain.

(Required.) Configuring RRPP rings:

·     Configuring RRPP ports

·     Configuring RRPP nodes

Perform this task on all nodes in the RRPP domain.

Perform this task on all nodes in the RRPP domain.

(Required.) Activating an RRPP domain

Perform this task on all nodes in the RRPP domain.

(Optional.) Configuring RRPP timers

Perform this task on the master node in the RRPP domain.

(Optional.) Configuring an RRPP ring group

Perform this task on the edge node and assistant edge node in the RRPP domain.

(Optional.) Enabling SNMP notifications for RRPP

N/A

 

Creating an RRPP domain

When you create an RRPP domain, specify a domain ID to uniquely identify the RRPP domain. All devices in the same RRPP domain must be configured with the same domain ID.

Perform this task on devices you want to configure as nodes in the RRPP domain.

To create an RRPP domain:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an RRPP domain and enter RRPP domain view.

rrpp domain domain-id

By default, no RRPP domains exist.

 

Configuring control VLANs

Before you configure RRPP rings in an RRPP domain, configure the same control VLANs for all nodes in the RRPP domain first. You need only configure the primary control VLAN for an RRPP domain. The system automatically configures the secondary control VLAN. 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 previously assigned.

Follow these guidelines when you configure control VLANs:

·     Do not configure the default VLAN of a port accessing an RRPP ring as the control VLAN, and do not enable VLAN mapping on control VLANs. If you do, RRPPDUs cannot be correctly forwarded.

·     The primary and secondary control VLAN IDs must be different from the Layer 3 Ethernet subinterface IDs of the master ring and subrings.

·     After you configure RRPP rings for an RRPP domain, you cannot delete or modify the primary control VLAN of the domain. You can only use the undo control-vlan command to delete a primary control VLAN.

·     To transparently transmit RRPPDUs on a device not configured with RRPP, make sure only the two ports accessing the RRPP ring permit packets from the control VLANs. Otherwise, the packets from other VLANs might enter the control VLANs in transparent transmission mode and strike the RRPP ring.

Perform this task on all nodes in the RRPP domain to be configured.

To configure control VLANs:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter RRPP domain view.

rrpp domain domain-id

N/A

3.     Configure the primary control VLAN for the RRPP domain.

control-vlan vlan-id

By default, no control VLAN exists in an RRPP domain.

 

Configuring protected VLANs

Before you configure RRPP rings in an RRPP domain, configure the same protected VLANs for all nodes in the RRPP domain. All VLANs to which the RRPP ports are assigned must be protected by the RRPP domains.

Protected VLANs are configured by referencing Multiple Spanning Tree Instances (MSTIs). The protected VLAN configuration method varies by the spanning tree mode:

·     In STP, RSTP, or MSTP mode, you must manually configure the mappings between VLANs and MSTIs.

·     In PVST mode, the device automatically maps each VLAN to an MSTI. When the spanning tree protocol is disabled globally, all VLANs are automatically mapped to MSTI 0.

For more information about spanning tree, see Layer 2—LAN Switching Configuration Guide.

 

IMPORTANT

IMPORTANT:

When you configure load balancing, you must configure different protected VLANs for different RRPP domains.

 

Perform this task on all nodes in the RRPP domain to be configured.

To configure protected VLANs:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter MST region view.

stp region-configuration

Not required if the device is operating in PVST mode.

For more information about the command, see Layer 2—LAN Switching Command Reference.

3.     Configure the VLAN-to-instance mapping table.

·     Method 1:
instance
instance-id vlan vlan-id-list

·     Method 2:
vlan-mapping modulo modulo

By default, all VLANs in an MST region are mapped to MSTI 0 (the CIST).

Not required if the device is operating in PVST mode.

For more information about the commands, see Layer 2—LAN Switching Command Reference.

4.     Activate MST region configuration.

active region-configuration

Not required if the device is operating in PVST mode.

For more information about the command, see Layer 2—LAN Switching Command Reference.

5.     (Optional.) Display the currently activated configuration information of the MST region.

display stp region-configuration

Available in any view.

The output of the command includes VLAN-to-instance mappings.

For more information about the command, see Layer 2—LAN Switching Command Reference.

6.     Return to system view.

quit

Not required if the device is operating in PVST mode.

7.     Enter RRPP domain view.

rrpp domain domain-id

N/A

8.     Configure protected VLANs for the RRPP domain.

protected-vlan reference-instance instance-id-list

By default, no protected VLANs exist in an RRPP domain.

 

Configuring RRPP rings

When you configure an RRPP ring, you must configure the ports connecting each node to the RRPP ring before configuring the nodes.

Configuring RRPP ports

Follow these guidelines when you configure RRPP ports:

·     Do not enable the OAM remote loopback function on an RRPP port. Otherwise, temporary broadcast storms might occur.

·     To accelerate topology convergence, use the link-delay command to enable link status rapid report function on an RRPP port. Use this command (or the undo link-delay command, depending on the device model) to set the physical state change suppression interval to 0 seconds. For more information about the link-delay command (or the undo link-delay command), see Layer 2—LAN Switching Command Reference.

Perform this task on each node's ports intended for accessing RRPP rings.

To configure RRPP ports:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.

interface interface-type interface-number

N/A

3.     Configure the link type of the interface as trunk.

port link-type trunk

By default, the link type of an interface is access.

For more information about the command, see Layer 2—LAN Switching Command Reference.

4.     Assign the trunk port to the protected VLANs of the RRPP domain.

port trunk permit vlan { vlan-id-list | all }

By default, a trunk port allows only packets from VLAN 1 to pass through.

RRPP ports always allow packets from the control VLANs to pass through.

For more information about the command, see Layer 2—LAN Switching Command Reference.

5.     Disable the spanning tree feature.

undo stp enable

By default, the spanning tree feature is enabled.

For more information about the command, see Layer 2—LAN Switching Command Reference.

 

Configuring RRPP nodes

If a device carries multiple RRPP rings in an RRPP domain, it can only be an edge node or an assistant edge node on a subring.

Specifying a master node

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter RRPP domain view.

rrpp domain domain-id

N/A

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

By default, a device is not a node of the RRPP ring.

 

Specifying a transit node

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter RRPP domain view.

rrpp domain domain-id

N/A

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

By default, a device is not a node of the RRPP ring.

 

Specifying an edge node

When you configure an edge node, you must configure the primary ring before configuring the subrings.

To specify an edge node:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter RRPP domain view.

rrpp domain domain-id

N/A

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

By default, a device is not a node of the RRPP ring.

4.     Specify the current device as the edge node of a subring, and specify the edge port.

ring ring-id node-mode edge [ edge-port interface-type interface-number ]

By default, a device is not a node of the RRPP ring.

 

Specifying an assistant edge node

When you configure an assistant edge node, you must configure the primary ring before configuring the subrings.

To specify an assistant edge node:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter RRPP domain view.

rrpp domain domain-id

N/A

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

By default, a device is not a node of the RRPP ring.

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 ]

By default, a device is not a node of the RRPP ring.

 

Activating an RRPP domain

Before you activate an RRPP domain on the current device, enable the RRPP protocol and RRPP rings for the RRPP domain on the current device.

Follow these guidelines when you activate an RRPP domain:

·     Before you enable subrings on a device, you must enable the primary ring. Before you disable the primary ring on the device, you must disable all subrings. Otherwise, the system displays error prompts.

·     To prevent Hello packets of subrings from being looped on the primary ring, enable the primary ring on its master node first. Then enable the subrings on their respective master nodes.

Perform this task on all nodes in the RRPP domain.

To activate an RRPP domain:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable RRPP.

rrpp enable

By default, RRPP is disabled.

3.     Enter RRPP domain view.

rrpp domain domain-id

N/A

4.     Enable the specified RRPP ring.

ring ring-id enable

By default, an RRPP ring is disabled.

 

Configuring RRPP timers

The Fail timer must be greater than or equal to three times the Hello timer.

In a dual-homed-ring network, make sure the difference between the Fail timer values on the master node of the subring and the master node of the primary ring is greater than twice the Hello timer value on the master node of the subring. Otherwise, temporary loops might occur when the primary ring fails.

Perform this task on the master node of an RRPP domain.

To configure RRPP timers:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter RRPP domain view.

rrpp domain domain-id

N/A

3.     Set the Hello timer and Fail timer for the RRPP domain.

timer hello-timer hello-value fail-timer fail-value

By default, the Hello timer value is 1 second and the Fail timer value is 3 seconds.

 

Configuring an RRPP ring group

To reduce Edge-Hello traffic, assign subrings with the same edge node and 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. It can only be configured on these two types of nodes.

Follow these guidelines when you configure an RRPP ring group:

·     You can assign a subring to only one RRPP ring group. The RRPP ring groups configured on the edge node and the assistant edge node must contain the same subrings. Otherwise, the RRPP ring group cannot operate correctly.

·     The subrings in an RRPP ring group must share the same edge node and assistant edge node. The edge node and the assistant edge node must have the same SRPTs.

·     Make sure a device is either the edge node or the assistant edge node on the subrings in an RRPP ring group.

·     Make sure the RRPP ring groups on the edge node and 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 different, the RRPP ring group cannot operate correctly.

Perform this task on both the edge node and the assistant edge node in an RRPP domain.

To configure an RRPP ring group:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an RRPP ring group and enter RRPP ring group view.

rrpp ring-group ring-group-id

By default, no RRPP ring groups exist.

3.     Assign the specified subrings to the RRPP ring group.

domain domain-id ring ring-id-list

By default, no subrings are assigned to an RRPP ring group.

 

Enabling SNMP notifications for RRPP

To report critical RRPP events to an NMS, enable SNMP notifications for RRPP. For RRPP event notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see the network management and monitoring configuration guide for the device.

To enable SNMP notifications for RRPP:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable SNMP notifications for RRPP.

snmp-agent trap enable rrpp [ major-fault | multi-master | ring-fail | ring-recover ] *

By default, SNMP notifications for RRPP are disabled.

 

Displaying and maintaining RRPP

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display brief RRPP information.

display rrpp brief

Display RRPP group configuration information.

display rrpp ring-group [ ring-group-id ]

Display RRPPDU statistics.

display rrpp statistics domain domain-id [ ring ring-id ]

Display detailed RRPP information.

display rrpp verbose domain domain-id [ ring ring-id ]

Clear RRPPDU statistics.

reset rrpp statistics domain domain-id [ ring ring-id ]

 

RRPP configuration examples

Single ring configuration example

Network requirements

As shown in Figure 15:

·     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. Specify the protected VLANs of RRPP domain 1 as 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, HundredGigE 1/0/1 as the primary port, and HundredGigE 1/0/2 as the secondary port.

·     Specify Device B, Device C, and Device D as the transit nodes of primary ring 1. Specify HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port on Device B, Device C, and Device D.

Figure 15 Network diagram

Configuration procedure

1.     Configure Device A:

# Create VLANs 1 through 30.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceA] stp region-configuration

[DeviceA-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceA-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceA-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceA-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] link-delay 0

[DeviceA-HundredGigE1/0/2] undo stp enable

[DeviceA-HundredGigE1/0/2] port link-type trunk

[DeviceA-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceA-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceA] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceA-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceA-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device A as the master node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port hundredgige 1/0/1 secondary-port hundredgige 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.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceB] stp region-configuration

[DeviceB-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceB-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] link-delay 0

[DeviceB-HundredGigE1/0/2] undo stp enable

[DeviceB-HundredGigE1/0/2] port link-type trunk

[DeviceB-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceB-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceB] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceB-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceB-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device B as the transit node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 1/0/2 level 0

[DeviceB-rrpp-domain1] ring 1 enable

[DeviceB-rrpp-domain1] quit

# Enable RRPP.

[DeviceB] rrpp enable

3.     Configure Device C:

Configure Device C in the same way Device B is configured.

4.     Configure Device D:

Configure Device D in the same way Device B is configured.

Verifying the configuration

# Use the display commands to view RRPP configuration and operational information on each device.

Intersecting ring configuration example

Network requirements

As shown in Figure 16:

·     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. RRPP domain 1 protects VLANs 1 through 30.

·     Device A, Device B, Device C, and Device D form primary ring 1. Device B, Device C, and Device E form subring 2.

·     Device A is the master node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 the secondary port.

·     Device E is the master node of subring 2, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 the secondary port.

·     Device B is the transit node of primary ring 1 and the edge node of subring 2, with HundredGigE 1/0/3 as the edge port.

·     Device C is the transit node of primary ring 1 and the assistant edge node of subring 1, with HundredGigE 1/0/3 as the edge port.

·     Device D is the transit node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 the secondary port.

Figure 16 Network diagram

Configuration procedure

1.     Configure Device A:

# Create VLANs 1 through 30.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceA] stp region-configuration

[DeviceA-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceA-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceA-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceA-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] link-delay 0

[DeviceA-HundredGigE1/0/2] undo stp enable

[DeviceA-HundredGigE1/0/2] port link-type trunk

[DeviceA-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceA-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceA] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceA-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceA-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device A as the master node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port hundredgige 1/0/1 secondary-port hundredgige 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.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceB] stp region-configuration

[DeviceB-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceB-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] link-delay 0

[DeviceB-HundredGigE1/0/2] undo stp enable

[DeviceB-HundredGigE1/0/2] port link-type trunk

[DeviceB-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceB-HundredGigE1/0/2] quit

# Configure HundredGigE 1/0/3 in the same way HundredGigE 1/0/1 is configured.

[DeviceB] interface hundredgige 1/0/3

[DeviceB-HundredGigE1/0/3] link-delay 0

[DeviceB-HundredGigE1/0/3] undo stp enable

[DeviceB-HundredGigE1/0/3] port link-type trunk

[DeviceB-HundredGigE1/0/3] port trunk permit vlan 1 to 30

[DeviceB-HundredGigE1/0/3] quit

# Create RRPP domain 1.

[DeviceB] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceB-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceB-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device B as a transit node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 1/0/2 level 0

[DeviceB-rrpp-domain1] ring 1 enable

# Configure Device B as the edge node of subring 2, with HundredGigE 1/0/3 as the edge port. Enable ring 2.

[DeviceB-rrpp-domain1] ring 2 node-mode edge edge-port hundredgige 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.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceC] stp region-configuration

[DeviceC-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceC-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceC-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceC-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] link-delay 0

[DeviceC-HundredGigE1/0/2] undo stp enable

[DeviceC-HundredGigE1/0/2] port link-type trunk

[DeviceC-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/0/2] quit

# Configure HundredGigE 1/0/3 in the same way HundredGigE 1/0/1 is configured.

[DeviceC] interface hundredgige 1/0/3

[DeviceC-HundredGigE1/0/3] link-delay 0

[DeviceC-HundredGigE1/0/3] undo stp enable

[DeviceC-HundredGigE1/0/3] port link-type trunk

[DeviceC-HundredGigE1/0/3] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/0/3] quit

# Create RRPP domain 1.

[DeviceC] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceC-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceC-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device C as a transit node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceC-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 1/0/2 level 0

[DeviceC-rrpp-domain1] ring 1 enable

# Configure Device C as the assistant edge node of subring 2, with HundredGigE 1/0/3 as the edge port. Enable ring 2.

[DeviceC-rrpp-domain1] ring 2 node-mode assistant-edge edge-port hundredgige 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.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceD] stp region-configuration

[DeviceD-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceD-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceD-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceD-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceD-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] link-delay 0

[DeviceD-HundredGigE1/0/2] undo stp enable

[DeviceD-HundredGigE1/0/2] port link-type trunk

[DeviceD-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceD-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceD] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceD-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceD-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device D as the transit node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 1/0/2 level 0

[DeviceD-rrpp-domain1] ring 1 enable

[DeviceD-rrpp-domain1] quit

# Enable RRPP.

[DeviceD] rrpp enable

5.     Configure Device E:

# Create VLANs 1 through 30.

<DeviceE> system-view

[DeviceE] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceE] stp region-configuration

[DeviceE-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceE-mst-region] active region-configuration

[DeviceE-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceE] interface hundredgige 1/0/1

[DeviceE-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceE-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceE-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceE-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceE-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceE] interface hundredgige 1/0/2

[DeviceE-HundredGigE1/0/2] link-delay 0

[DeviceE-HundredGigE1/0/2] undo stp enable

[DeviceE-HundredGigE1/0/2] port link-type trunk

[DeviceE-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceE-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceE] rrpp domain 1

# Configure VLAN 4092 as the primary control VLAN of RRPP domain 1.

[DeviceE-rrpp-domain1] control-vlan 4092

# Configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceE-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device E as the master node of subring 2, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 2.

[DeviceE-rrpp-domain1] ring 2 node-mode master primary-port hundredgige 1/0/1 secondary-port hundredgige 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 commands to view RRPP configuration and operational information on each device.

Load-balanced intersecting-ring configuration example

Network requirements

As shown in Figure 17:

·     Device A, Device B, Device C, Device D, and Device F form RRPP domain 1. 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. 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 and Ring 3 have the same edge node and assistant edge node, and the two subrings have the same SRPTs. You can add Ring 2 and Ring 3 to an RRPP ring group to reduce Edge-Hello traffic.

Figure 17 Network diagram

Configuration procedure

1.     Configure Device A:

# Create VLANs 11 and 12.

<DeviceA> system-view

[DeviceA] vlan 11 to 12

# Map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2.

[DeviceA] stp region-configuration

[DeviceA-mst-region] instance 1 vlan 11

[DeviceA-mst-region] instance 2 vlan 12

# Activate the MST region configuration.

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceA-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceA-HundredGigE1/0/1] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLANs 11 and 12.

[DeviceA-HundredGigE1/0/1] undo port trunk permit vlan 1

[DeviceA-HundredGigE1/0/1] port trunk permit vlan 11 12

# Configure VLAN 11 as the default VLAN.

[DeviceA-HundredGigE1/0/1] port trunk pvid vlan 11

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] link-delay 0

[DeviceA-HundredGigE1/0/2] undo stp enable

[DeviceA-HundredGigE1/0/2] port link-type trunk

[DeviceA-HundredGigE1/0/2] undo port trunk permit vlan 1

[DeviceA-HundredGigE1/0/2] port trunk permit vlan 11 12

[DeviceA-HundredGigE1/0/2] port trunk pvid vlan 11

[DeviceA-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceA] rrpp domain 1

# Configure VLAN 100 as the primary control VLAN of RRPP domain 1.

[DeviceA-rrpp-domain1] control-vlan 100

# Configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceA-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device A as the master node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port hundredgige 1/0/1 secondary-port hundredgige 1/0/2 level 0

[DeviceA-rrpp-domain1] ring 1 enable

[DeviceA-rrpp-domain1] quit

# Create RRPP domain 2.

[DeviceA] rrpp domain 2

# Configure VLAN 105 as the primary control VLAN of RRPP domain 2.

[DeviceA-rrpp-domain2] control-vlan 105

# Configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceA-rrpp-domain2] protected-vlan reference-instance 2

# Configure Device A as the master node of primary ring 1, with HundredGigE 1/0/2 as the master port and HundredGigE 1/0/1 as the secondary port. Enable ring 1.

[DeviceA-rrpp-domain2] ring 1 node-mode master primary-port hundredgige 1/0/2 secondary-port hundredgige 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.

<DeviceB> system-view

[DeviceB] vlan 11 to 12

# Map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2.

[DeviceB] stp region-configuration

[DeviceB-mst-region] instance 1 vlan 11

[DeviceB-mst-region] instance 2 vlan 12

# Activate the MST region configuration.

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceB-HundredGigE1/0/1] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLANs 11 and 12.

[DeviceB-HundredGigE1/0/1] undo port trunk permit vlan 1

[DeviceB-HundredGigE1/0/1] port trunk permit vlan 11 12

# Configure VLAN 11 as the default VLAN.

[DeviceB-HundredGigE1/0/1] port trunk pvid vlan 11

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] link-delay 0

[DeviceB-HundredGigE1/0/2] undo stp enable

[DeviceB-HundredGigE1/0/2] port link-type trunk

[DeviceB-HundredGigE1/0/2] undo port trunk permit vlan 1

[DeviceB-HundredGigE1/0/2] port trunk permit vlan 11 12

[DeviceB-HundredGigE1/0/2] port trunk pvid vlan 11

[DeviceB-HundredGigE1/0/2] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/3.

[DeviceB] interface hundredgige 1/0/3

[DeviceB-HundredGigE1/0/3] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/3] undo stp enable

# Configure the port as a trunk port.

[DeviceB-HundredGigE1/0/3] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLAN 12.

[DeviceB-HundredGigE1/0/3] undo port trunk permit vlan 1

[DeviceB-HundredGigE1/0/3] port trunk permit vlan 12

# Configure VLAN 12 as the default VLAN.

[DeviceB-HundredGigE1/0/3] port trunk pvid vlan 12

[DeviceB-HundredGigE1/0/3] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/4.

[DeviceB] interface hundredgige 1/0/4

[DeviceB-HundredGigE1/0/4] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/4] undo stp enable

# Configure the port as a trunk port.

[DeviceB-HundredGigE1/0/4] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLAN 11.

[DeviceB-HundredGigE1/0/4] undo port trunk permit vlan 1

[DeviceB-HundredGigE1/0/4] port trunk permit vlan 11

# Configure VLAN 11 as the default VLAN.

[DeviceB-HundredGigE1/0/4] port trunk pvid vlan 11

[DeviceB-HundredGigE1/0/4] quit

# Create RRPP domain 1.

[DeviceB] rrpp domain 1

# Configure VLAN 100 as the primary control VLAN of RRPP domain 1.

[DeviceB-rrpp-domain1] control-vlan 100

# Configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceB-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device B as a transit node of primary ring 1 in RRPP domain 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 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 HundredGigE 1/0/4 as the edge port. Enable subring 3.

[DeviceB-rrpp-domain1] ring 3 node-mode assistant-edge edge-port hundredgige 1/0/4

[DeviceB-rrpp-domain1] ring 3 enable

[DeviceB-rrpp-domain1] quit

# Create RRPP domain 2.

[DeviceB] rrpp domain 2

# Configure VLAN 105 as the primary control VLAN of RRPP domain 2.

[DeviceB-rrpp-domain2] control-vlan 105

# Configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceB-rrpp-domain2] protected-vlan reference-instance 2

# Configure Device B as the transit node of primary ring 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceB-rrpp-domain2] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 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 HundredGigE 1/0/3 as the edge port. Enable subring 2.

[DeviceB-rrpp-domain2] ring 2 node-mode assistant-edge edge-port hundredgige 1/0/3

[DeviceB-rrpp-domain2] ring 2 enable

[DeviceC-rrpp-domain2] quit

# Enable RRPP.

[DeviceB] rrpp enable

3.     Configure Device C:

# Create VLANs 11 and 12.

<DeviceC> system-view

[DeviceC] vlan 11 to 12

# Map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2.

[DeviceC] stp region-configuration

[DeviceC-mst-region] instance 1 vlan 11

[DeviceC-mst-region] instance 2 vlan 12

# Activate the MST region configuration.

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceC-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceC-HundredGigE1/0/1] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLANs 11 and 12.

[DeviceC-HundredGigE1/0/1] undo port trunk permit vlan 1

[DeviceC-HundredGigE1/0/1] port trunk permit vlan 11 12

# Configure VLAN 11 as the default VLAN.

[DeviceC-HundredGigE1/0/1] port trunk pvid vlan 11

[DeviceC-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] link-delay 0

[DeviceC-HundredGigE1/0/2] undo stp enable

[DeviceC-HundredGigE1/0/2] port link-type trunk

[DeviceC-HundredGigE1/0/2] undo port trunk permit vlan 1

[DeviceC-HundredGigE1/0/2] port trunk permit vlan 11 12

[DeviceC-HundredGigE1/0/2] port trunk pvid vlan 11

[DeviceC-HundredGigE1/0/2] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/3.

[DeviceC] interface hundredgige 1/0/3

[DeviceC-HundredGigE1/0/3] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceC-HundredGigE1/0/3] undo stp enable

# Configure the port as a trunk port.

[DeviceC-HundredGigE1/0/3] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLAN 12.

[DeviceC-HundredGigE1/0/3] undo port trunk permit vlan 1

[DeviceC-HundredGigE1/0/3] port trunk permit vlan 12

# Configure VLAN 12 as the default VLAN.

[DeviceC-HundredGigE1/0/3] port trunk pvid vlan 12

[DeviceC-HundredGigE1/0/3] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/4.

[DeviceC] interface hundredgige 1/0/4

[DeviceC-HundredGigE1/0/4] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceC-HundredGigE1/0/4] undo stp enable

# Configure the port as a trunk port.

[DeviceC-HundredGigE1/0/4] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLAN 11.

[DeviceC-HundredGigE1/0/4] undo port trunk permit vlan 1

[DeviceC-HundredGigE1/0/4] port trunk permit vlan 11

# Configure VLAN 11 as the default VLAN.

[DeviceC-HundredGigE1/0/4] port trunk pvid vlan 11

[DeviceC-HundredGigE1/0/4] quit

# Create RRPP domain 1.

[DeviceC] rrpp domain 1

# Configure VLAN 100 as the primary control VLAN of RRPP domain 1.

[DeviceC-rrpp-domain1] control-vlan 100

# Configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceC-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device C as the transit node of primary ring 1 in RRPP domain 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceC-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 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 HundredGigE 1/0/4 as the edge port. Enable subring 3.

[DeviceC-rrpp-domain1] ring 3 node-mode edge edge-port hundredgige 1/0/4

[DeviceC-rrpp-domain1] ring 3 enable

[DeviceC-rrpp-domain1] quit

# Create RRPP domain 2.

[DeviceC] rrpp domain 2

# Configure VLAN 105 as the primary control VLAN of RRPP domain 2.

[DeviceC-rrpp-domain2] control-vlan 105

# Configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceC-rrpp-domain2] protected-vlan reference-instance 2

# Configure Device C as the transit node of primary ring 1 in RRPP domain 2, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceC-rrpp-domain2] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 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 HundredGigE 1/0/3 as the edge port. Enable subring 2.

[DeviceC-rrpp-domain2] ring 2 node-mode edge edge-port hundredgige 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.

<DeviceD> system-view

[DeviceD] vlan 11 to 12

# Map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2.

[DeviceD] stp region-configuration

[DeviceD-mst-region] instance 1 vlan 11

[DeviceD-mst-region] instance 2 vlan 12

# Activate the MST region configuration.

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceD-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceD-HundredGigE1/0/1] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLANs 11 and 12.

[DeviceD-HundredGigE1/0/1] undo port trunk permit vlan 1

[DeviceD-HundredGigE1/0/1] port trunk permit vlan 11 12

# Configure VLAN 11 as the default VLAN.

[DeviceD-HundredGigE1/0/1] port trunk pvid vlan 11

[DeviceD-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] link-delay 0

[DeviceD-HundredGigE1/0/2] undo stp enable

[DeviceD-HundredGigE1/0/2] port link-type trunk

[DeviceD-HundredGigE1/0/2] undo port trunk permit vlan 1

[DeviceD-HundredGigE1/0/2] port trunk permit vlan 11 12

[DeviceD-HundredGigE1/0/2] port trunk pvid vlan 11

[DeviceD-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceD] rrpp domain 1

# Configure VLAN 100 as the primary control VLAN of RRPP domain 1.

[DeviceD-rrpp-domain1] control-vlan 100

# Configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceD-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device D as the transit node of primary ring 1 in RRPP domain 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 1/0/2 level 0

[DeviceD-rrpp-domain1] ring 1 enable

[DeviceD-rrpp-domain1] quit

# Create RRPP domain 2.

[DeviceD] rrpp domain 2

# Configure VLAN 105 as the primary control VLAN of RRPP domain 2.

[DeviceD-rrpp-domain2] control-vlan 105

# Configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceD-rrpp-domain2] protected-vlan reference-instance 2

# Configure Device D as the transit node of primary ring 1 in RRPP domain 2, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable ring 1.

[DeviceD-rrpp-domain2] ring 1 node-mode transit primary-port hundredgige 1/0/1 secondary-port hundredgige 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.

<DeviceE> system-view

[DeviceE] vlan 12

# Map VLAN 12 to MSTI 2.

[DeviceE-vlan12] quit

[DeviceE] stp region-configuration

[DeviceE-mst-region] instance 2 vlan 12

# Activate the MST region configuration.

[DeviceE-mst-region] active region-configuration

[DeviceE-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceE] interface hundredgige 1/0/1

[DeviceE-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceE-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceE-HundredGigE1/0/1] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLAN 12.

[DeviceE-HundredGigE1/0/1] undo port trunk permit vlan 1

[DeviceE-HundredGigE1/0/1] port trunk permit vlan 12

# Configure VLAN 12 as the default VLAN.

[DeviceE-HundredGigE1/0/1] port trunk pvid vlan 12

[DeviceE-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceE] interface hundredgige 1/0/2

[DeviceE-HundredGigE1/0/2] link-delay 0

[DeviceE-HundredGigE1/0/2] undo stp enable

[DeviceE-HundredGigE1/0/2] port link-type trunk

[DeviceE-HundredGigE1/0/2] undo port trunk permit vlan 1

[DeviceE-HundredGigE1/0/2] port trunk permit vlan 12

[DeviceE-HundredGigE1/0/2] port trunk pvid vlan 12

[DeviceE-HundredGigE1/0/2] quit

# Create RRPP domain 2.

[DeviceE] rrpp domain 2

# Configure VLAN 105 as the primary control VLAN of RRPP domain 2.

[DeviceE-rrpp-domain2] control-vlan 105

# Configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceE-rrpp-domain2] protected-vlan reference-instance 2

# Configure Device E as the master mode of subring 2 in RRPP domain 2, with HundredGigE 1/0/2 as the primary port and HundredGigE 1/0/1 as the secondary port. Enable ring 2.

[DeviceE-rrpp-domain2] ring 2 node-mode master primary-port hundredgige 1/0/2 secondary-port hundredgige 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.

<DeviceF> system-view

[DeviceF] vlan 11

[DeviceF-vlan11] quit

# Map VLAN 11 to MSTI 1.

[DeviceF] stp region-configuration

[DeviceF-mst-region] instance 1 vlan 11

# Activate the MST region configuration.

[DeviceF-mst-region] active region-configuration

[DeviceF-mst-region] quit

# Set the physical state change suppression interval to 0 seconds on HundredGigE 1/0/1.

[DeviceF] interface hundredgige 1/0/1

[DeviceF-HundredGigE1/0/1] link-delay 0

# Disable the spanning tree feature on the port.

[DeviceF-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceF-HundredGigE1/0/1] port link-type trunk

# Remove the port from VLAN 1, and assign it to VLAN 11.

[DeviceF-HundredGigE1/0/1] undo port trunk permit vlan 1

[DeviceF-HundredGigE1/0/1] port trunk permit vlan 11

# Configure VLAN 11 as the default VLAN.

[DeviceF-HundredGigE1/0/1] port trunk pvid vlan 11

[DeviceF-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceF] interface hundredgige 1/0/2

[DeviceF-HundredGigE1/0/2] link-delay 0

[DeviceF-HundredGigE1/0/2] undo stp enable

[DeviceF-HundredGigE1/0/2] port link-type trunk

[DeviceF-HundredGigE1/0/2] undo port trunk permit vlan 1

[DeviceF-HundredGigE1/0/2] port trunk permit vlan 11

[DeviceF-HundredGigE1/0/2] port trunk pvid vlan 11

[DeviceF-HundredGigE1/0/2] quit

# Create RRPP domain 1.

[DeviceF] rrpp domain 1

# Configure VLAN 100 as the primary control VLAN of RRPP domain 1.

[DeviceF-rrpp-domain1] control-vlan 100

# Configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceF-rrpp-domain1] protected-vlan reference-instance 1

# Configure Device F as the master node of subring 3 in RRPP domain 1, with HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port. Enable subring 3.

[DeviceF-rrpp-domain1] ring 3 node-mode master primary-port hundredgige 1/0/1 secondary-port hundredgige 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 commands to view RRPP configuration and operational information on each device.

Troubleshooting RRPP

Symptom

When the link state is normal, the master node cannot receive Hello packets, and it unblocks the secondary port.

Solution

To resolve the problem:

1.     Use the display rrpp brief command to determine whether RRPP is enabled for all nodes. If it is not, use the rrpp enable command and the ring enable command to enable RRPP and RRPP rings for all nodes.

2.     Use the display rrpp brief command to determine whether the domain ID and primary control VLAN ID are the same for all nodes. If they are not, set the same domain ID and primary control VLAN ID for the nodes.

3.     Use the display rrpp verbose command to examine the link state of each port in each ring.

4.     Use the debugging rrpp command on each node to determine whether a port receives or transmits Hello packets. If it does not, Hello packets are lost.

5.     If the problem persists, contact H3C Support.


Configuring 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 18.

Figure 18 Dual uplink network diagram

 

To remove network loops on a dual-homed network, you can use a spanning tree protocol or the Rapid Ring Protection Protocol (RRPP). However, convergence time is long with spanning tree protocols, 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 spanning tree protocols, see Layer 2—LAN Switching Configuration Guide. For more information about RRPP, see "Configuring RRPP."

Smart Link is a feature developed to address the slow convergence issue with STP. It provides link redundancy and fast convergence in a dual uplink network, allowing the backup link to take over quickly when the primary link fails. Smart Link features subsecond convergence time.

A Smart Link device is configured with a smart link group and a transmit control VLAN to transmit flush messages. For example, Device C and Device D in Figure 18 are Smart Link devices.

An associated device supports Smart Link, and receives flush messages sent from the specified control VLAN. For example, Device A, Device B, and Device E in Figure 18 are associated devices.

Terminology

Smart link group

A smart link group consists of only two member ports: the primary and the secondary ports. 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 unidirectional link, the standby port becomes active and takes over. The original active port transits to the blocked state.

As shown in Figure 18, Port 1 and Port 2 of Device C form a smart link group and those of Device D form another. Port 1 is active and Port 2 is standby.

Primary/secondary port

Primary port and secondary port are two port types in a smart link group. When both ports in a smart link group are up, the primary port preferentially transits to the forwarding state. The secondary port stays in standby state. When the primary port fails, the secondary port takes over to forward traffic.

As shown in Figure 18, Port 1 of Device C and that of Device D are primary ports. Port 2 of Device C and that of Device D are 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

When link switchover occurs, the smart link group uses flush messages to notify other devices to refresh their MAC address entries and ARP/ND entries. Flush messages are common multicast data packets, and will be dropped by a blocked receiving port.

Protected VLAN

A smart link group controls the forwarding state of protected VLANs. Each smart link group on a port controls a different protected VLAN. 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 Figure 18) send 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 18) receive and process flush messages in the receive control VLAN. In addition, they refresh their MAC address entries and ARP/ND entries.

How Smart Link works

Link backup

As shown in Figure 18, the link on Port 1 of Device C is the primary link. The link on Port 2 of Device C is the secondary link. Port 1 is in forwarding state, and Port 2 is in standby state. When the primary link fails, Port 2 takes over to forward traffic and Port 1 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

Link switchover might outdate the MAC address entries and ARP/ND entries on all devices. A flush update mechanism is provided to ensure correct packet transmission. With this mechanism, 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.

Preemption mode

As shown in Figure 18, the link on Port 1 of Device C is the primary link. The link on Port 2 of Device C is the secondary link. When the primary link fails, Port 1 is automatically blocked and placed in standby state, and Port 2 takes over to forward traffic. When the primary link recovers, one of the following actions occurs:

·     If the smart link group is not configured with a preemption mode, Port 1 stays blocked to keep traffic forwarding stable. Port 1 does not take over to forward traffic until the next link switchover.

·     If the smart link group is configured with a preemption mode and the preemption conditions are met, Port 1 takes over to forward traffic as soon as its link recovers. Port 2 is automatically blocked and placed in standby state.

Load sharing

A ring network might 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, you can assign a port to multiple smart link groups. Configure each group with a different protected VLAN. Make sure the state of the port is different in these smart link groups, so traffic from different VLANs can be forwarded along different paths.

You can configure protected VLANs for a smart link group by referencing Multiple Spanning Tree Instances (MSTIs). For more information about MSTIs, see Layer 2—LAN Switching Configuration Guide.

Collaboration between Smart Link and Monitor Link

Smart Link cannot detect when faults occur on the uplink of the upstream devices or when faults are cleared. You can configure the Monitor Link function to monitor the status of the uplink ports of the upstream devices. Monitor Link adapts the up/down state of downlink ports to uplink ports, and triggers Smart Link to perform link switchover on the downstream device. For more information about Monitor Link, see "Configuring Monitor Link."

Smart Link configuration task list

Tasks at a glance

Configuring a Smart Link device:

·     (Required.) Configuring protected VLANs for a smart link group

·     (Required.) Configuring member ports for a smart link group

·     (Optional.) Configuring a preemption mode for a smart link group

·     (Optional.) Enabling the sending of flush messages

Configuring an associated device

·     (Required.) Enabling the receiving of flush messages

 

Configuring a Smart Link device

Configuration prerequisites

Before configuring a Smart Link device, complete the following tasks:

·     To prevent loops, shut down a port before configuring it as a smart link group member. You can bring up the port only after completing the smart link group configuration.

·     Disable the spanning tree feature and RRPP on the ports you want to add to the smart link group.

 

 

NOTE:

·     A loop might occur on the network during the time when the spanning tree feature is disabled but Smart Link has not yet taken effect on a port.

·     If you configure a port as both an aggregation group member and a smart link group member, only the aggregation group configuration takes effect. The port is not shown in the output from the display smart-link group command. The smart link group configuration takes effect after the port leaves the aggregation group.

 

Configuring protected VLANs for a smart link group

Protected VLANs are configured by referencing MSTIs. The protected VLAN configuration method varies by the spanning tree mode:

In STP, RSTP, or MSTP mode, you must manually configure the mappings between VLANs and MSTIs.

In PVST mode, the device automatically maps each VLAN to an MSTI. When the spanning tree protocol is disabled globally, all VLANs are automatically mapped to MSTI 0.

To configure the protected VLANs for a smart link group:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter MST region view.

stp region-configuration

Skip this step if the device is operating in PVST mode.

For more information about the command, see Layer 2—LAN Switching Command Reference.

3.     Configure the VLAN-to-instance mapping table.

·     Method 1:
instance
instance-id vlan vlan-id-list

·     Method 2:
vlan-mapping modulo modulo

Skip this step if the device is operating in PVST mode.

All VLANs in an MST region are mapped to CIST (MSTI 0) by default.

For more information about the commands, see Layer 2—LAN Switching Command Reference.

4.     Manually activate MST region configuration.

active region-configuration

Skip this step if the device is operating in PVST mode.

For more information about the command, see Layer 2—LAN Switching Command Reference.

5.     (Optional.) Display the activated MST region configuration information.

display stp region-configuration

Available in any view.

The output of the command includes VLAN-to-instance mappings.

For more information about the command, see Layer 2—LAN Switching Command Reference.

6.     Return to system view.

quit

Skip this step if the device is operating in PVST mode.

7.     Create a smart link group and enter smart link group view.

smart-link group group-id

N/A

8.     Configure protected VLANs for the smart link group.

protected-vlan reference-instance instance-id-list

By default, a smart link group does not have protected VLANs.

 

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.

In smart link group view

To configure member ports for a smart link group in smart link group view:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a smart link group and enter smart link group view.

smart-link group group-id

N/A

3.     Configure member ports for a smart link group.

port interface-type interface-number { primary | secondary }

By default, no member port is configured for a smart link group.

 

In interface view

To configure member ports for a smart link group in interface view:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.

interface interface-type interface-number

N/A

3.     Configure member ports for a smart link group.

port smart-link group group-id { primary | secondary }

By default, an interface is not a smart link group member.

 

Configuring a preemption mode for a smart link group

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter smart link group view.

smart-link group group-id

N/A

3.     Configure a preemption mode for the smart link group.

preemption mode { role | speed [ threshold threshold-value ] }

By default, preemption is disabled.

4.     Configure the preemption delay.

preemption delay delay

By default, the preemption delay is 1 second.

The preemption delay configuration takes effect only after a preemption mode is configured.

 

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 from the control VLAN 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 must also be one of its protected VLANs. Do not remove the control VLAN. Otherwise, flush messages cannot be sent correctly.

To enable the sending of flush messages:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter smart link group view.

smart-link group group-id

N/A

3.     Enable flush update.

flush enable [ control-vlan vlan-id ]

By default, flush update is enabled, and VLAN 1 is the control VLAN.

 

Configuring an associated device

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 if a topology change occurs.

Enabling the receiving of flush messages

You do not need to enable all ports on the associated devices to receive flush messages. Enable the feature only on all control VLANs of ports on the primary and secondary links between the Smart Link device and the destination device.

Follow these guidelines when you enable the receiving of flush messages:

·     If no control VLAN is specified for processing flush messages, the device forwards the received flush messages without any processing.

·     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 correctly.

·     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:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.

interface interface-type interface-number

N/A

3.     Configure the control VLANs for receiving flush messages.

smart-link flush enable [ control-vlan vlan-id-list ]

By default, no control VLAN receives flush messages.

 

Displaying and maintaining Smart Link

Perform display commands in any view and the reset command in user view:

 

Task

Command

Display information about the received flush messages.

display smart-link flush

Display smart link group information.

display smart-link group { group-id | all }

Clear the statistics about flush messages.

reset smart-link statistics

 

Smart Link configuration examples

Single smart link group configuration example

Network requirements

As shown in Figure 19:

·     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 is dually uplinked to Device A.

·     Configure Smart Link on Device C and Device D for dual uplink backup.

Figure 19 Network diagram

Configuration procedure

1.     Configure Device C:

# Create VLANs 1 through 30.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceC] stp region-configuration

[DeviceC-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Shut down HundredGigE 1/0/1.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] shutdown

# Disable the spanning tree feature on the port.

[DeviceC-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceC-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceC-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] shutdown

[DeviceC-HundredGigE1/0/2] undo stp enable

[DeviceC-HundredGigE1/0/2] port link-type trunk

[DeviceC-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/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 HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port for smart link group 1.

[DeviceC-smlk-group1] port hundredgige 1/0/1 primary

[DeviceC-smlk-group1] port hundredgige 1/0/2 secondary

# 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 HundredGigE 1/0/1 and HundredGigE 1/0/2 again.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] undo shutdown

[DeviceC-HundredGigE1/0/1] quit

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] undo shutdown

[DeviceC-HundredGigE1/0/2] quit

2.     Configure Device D:

# Create VLANs 1 through 30.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceD] stp region-configuration

[DeviceD-mst-region] instance 1 vlan 1 to 30

# Activate the MST region configuration.

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Shut down HundredGigE 1/0/1.

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] shutdown

# Disable the spanning tree feature on the port.

[DeviceD-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceD-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceD-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceD-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] shutdown

[DeviceD-HundredGigE1/0/2] undo stp enable

[DeviceD-HundredGigE1/0/2] port link-type trunk

[DeviceD-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceD-HundredGigE1/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 HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port for smart link group 1.

[DeviceD-smlk-group1] port hundredgige 1/0/1 primary

[DeviceD-smlk-group1] port hundredgige 1/0/2 secondary

# 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 HundredGigE 1/0/1 and HundredGigE 1/0/2 again.

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] undo shutdown

[DeviceD-HundredGigE1/0/1] quit

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] undo shutdown

[DeviceD-HundredGigE1/0/2] quit

3.     Configure Device B:

# Create VLANs 1 through 30.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/1] port trunk permit vlan 1 to 30

# Enable flush message receiving and configure VLAN 10 and VLAN 20 as the receive control VLANs on the port.

[DeviceB-HundredGigE1/0/1] smart-link flush enable control-vlan 10 20

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 as a trunk port.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/2] port trunk permit vlan 1 to 30

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/2] undo stp enable

# Enable flush message receiving and configure VLAN 20 as the receive control VLAN on the port.

[DeviceB-HundredGigE1/0/2] smart-link flush enable control-vlan 20

[DeviceB-HundredGigE1/0/2] quit

# Configure HundredGigE 1/0/3 as a trunk port.

[DeviceB] interface hundredgige 1/0/3

[DeviceB-HundredGigE1/0/3] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/3] port trunk permit vlan 1 to 30

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/3] undo stp enable

# Enable flush message receiving and configure VLAN 10 as the receive control VLAN on the port.

[DeviceB-HundredGigE1/0/3] smart-link flush enable control-vlan 10

[DeviceB-HundredGigE1/0/3] quit

4.     Configure Device E:

# Create VLANs 1 through 30.

<DeviceE> system-view

[DeviceE] vlan 1 to 30

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceE] interface hundredgige 1/0/1

[DeviceE-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceE-HundredGigE1/0/1] port trunk permit vlan 1 to 30

# Enable flush message receiving and configure VLAN 10 and VLAN 20 as the receive control VLANs on the port.

[DeviceE-HundredGigE1/0/1] smart-link flush enable control-vlan 10 20

[DeviceE-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 as a trunk port.

[DeviceE] interface hundredgige 1/0/2

[DeviceE-HundredGigE1/0/2] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceE-HundredGigE1/0/2] port trunk permit vlan 1 to 30

# Disable the spanning tree feature on the port.

[DeviceE-HundredGigE1/0/2] undo stp enable

# Enable flush message receiving and configure VLAN 10 as the receive control VLAN on the port.

[DeviceE-HundredGigE1/0/2] smart-link flush enable control-vlan 10

[DeviceE-HundredGigE1/0/2] quit

# Configure HundredGigE 1/0/3 as a trunk port.

[DeviceE] interface hundredgige 1/0/3

[DeviceE-HundredGigE1/0/3] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceE-HundredGigE1/0/3] port trunk permit vlan 1 to 30

# Disable the spanning tree feature on the port.

[DeviceE-HundredGigE1/0/3] undo stp enable

# Enable flush message receiving and configure VLAN 20 as the receive control VLAN on the port.

[DeviceE-HundredGigE1/0/3] smart-link flush enable control-vlan 20

[DeviceE-HundredGigE1/0/3] quit

5.     Configure Device A:

# Create VLANs 1 through 30.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 30.

[DeviceA-HundredGigE1/0/1] port trunk permit vlan 1 to 30

# Enable flush message receiving and configure VLAN 10 and VLAN 20 as the receive control VLANs on the port.

[DeviceA-HundredGigE1/0/1] smart-link flush enable control-vlan 10 20

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] port link-type trunk

[DeviceA-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceA-HundredGigE1/0/2] smart-link flush enable control-vlan 10 20

[DeviceA-HundredGigE1/0/2] quit

Verifying the configuration

# 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

  -----------------------------------------------------------------------------

  HGE1/0/1                PRIMARY   ACTIVE  5               16:45:20 2012/04/21

  HGE1/0/2                SECONDARY STANDBY 1               16:37:20 2012/04/21

# Display the flush messages received on Device B.

[DeviceB] display smart-link flush

 Received flush packets                             : 5

 Receiving interface of the last flush packet       : HundredGigE1/0/3

 Receiving time of the last flush packet            : 16:50:21 2012/04/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 Figure 20:

·     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. Traffic of VLANs 101 through 200 is uplinked to Device A by Device D.

Figure 20 Network diagram

Configuration procedure

1.     Configure Device C:

# Create VLAN 1 through VLAN 200.

<DeviceC> system-view

[DeviceC] vlan 1 to 200

# Map VLANs 1 through 100 to MSTI 1, and VLANs 101 through 200 to MSTI 2.

[DeviceC] stp region-configuration

[DeviceC-mst-region] instance 1 vlan 1 to 100

[DeviceC-mst-region] instance 2 vlan 101 to 200

# Activate the MST region configuration.

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Shut down HundredGigE 1/0/1.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] shutdown

# Disable the spanning tree feature on the port.

[DeviceC-HundredGigE1/0/1] undo stp enable

# Configure the port as a trunk port.

[DeviceC-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLAN 1 through VLAN 200.

[DeviceC-HundredGigE1/0/1] port trunk permit vlan 1 to 200

[DeviceC-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] shutdown

[DeviceC-HundredGigE1/0/2] undo stp enable

[DeviceC-HundredGigE1/0/2] port link-type trunk

[DeviceC-HundredGigE1/0/2] port trunk permit vlan 1 to 200

[DeviceC-HundredGigE1/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 HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port for smart link group 1.

[DeviceC-smlk-group1] port hundredgige 1/0/1 primary

[DeviceC-smlk-group1] port hundredgige 1/0/2 secondary

# 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

[DeviceC-smlk-group2] protected-vlan reference-instance 2

# Configure HundredGigE 1/0/1 as the secondary port and HundredGigE 1/0/2 as the primary port for smart link group 2.

[DeviceC-smlk-group2] port hundredgige 1/0/2 primary

[DeviceC-smlk-group2] port hundredgige 1/0/1 secondary

# 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 HundredGigE 1/0/1 and HundredGigE 1/0/2.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] undo shutdown

[DeviceC-HundredGigE1/0/1] quit

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] undo shutdown

[DeviceC-HundredGigE1/0/2] quit

2.     Configure Device B:

# Create VLAN 1 through VLAN 200.

<DeviceB> system-view

[DeviceB] vlan 1 to 200

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 200.

[DeviceB-HundredGigE1/0/1] port trunk permit vlan 1 to 200

# Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceB-HundredGigE1/0/1] smart-link flush enable control-vlan 10 110

[DeviceB-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 as a trunk port.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] port link-type trunk

# Assign the port to VLANs 1 through 200.

[DeviceB-HundredGigE1/0/2] port trunk permit vlan 1 to 200

# Disable the spanning tree feature on the port.

[DeviceB-HundredGigE1/0/2] undo stp enable

# Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceB-HundredGigE1/0/2] smart-link flush enable control-vlan 10 110

[DeviceB-HundredGigE1/0/2] quit

3.     Configure Device D:

# Create VLAN 1 through VLAN 200.

<DeviceD> system-view

[DeviceD] vlan 1 to 200

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 200.

[DeviceD-HundredGigE1/0/1] port trunk permit vlan 1 to 200

# Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceD-HundredGigE1/0/1] smart-link flush enable control-vlan 10 110

[DeviceD-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 as a trunk port.

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] port link-type trunk

# Assign the port to VLANs 1 through 200.

[DeviceD-HundredGigE1/0/2] port trunk permit vlan 1 to 200

# Disable the spanning tree feature on the port.

[DeviceD-HundredGigE1/0/2] undo stp enable

# Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceD-HundredGigE1/0/2] smart-link flush enable control-vlan 10 110

[DeviceD-HundredGigE1/0/2] quit

4.     Configure Device A:

# Create VLAN 1 through VLAN 200.

<DeviceA> system-view

[DeviceA] vlan 1 to 200

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] port link-type trunk

# Assign the port to VLANs 1 through 200.

[DeviceA-HundredGigE1/0/1] port trunk permit vlan 1 to 200

# Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceA-HundredGigE1/0/1] smart-link flush enable control-vlan 10 110

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] port link-type trunk

[DeviceA-HundredGigE1/0/2] port trunk permit vlan 1 to 200

[DeviceA-HundredGigE1/0/2] smart-link flush enable control-vlan 10 110

[DeviceA-HundredGigE1/0/2] quit

Verifying the configuration

# 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

  -----------------------------------------------------------------------------

  HGE1/0/1                PRIMARY   ACTIVE  5               16:45:20 2012/04/21

  HGE1/0/2                SECONDARY STANDBY 1               16:37:20 2012/04/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

  -----------------------------------------------------------------------------

  HGE1/0/2                PRIMARY   ACTIVE  5               16:45:20 2012/04/21

  HGE1/0/1                SECONDARY STANDBY 1               16:37:20 2012/04/21

# Display the flush messages received on Device B.

[DeviceB] display smart-link flush

 Received flush packets                             : 5

 Receiving interface of the last flush packet       : HundredGigE1/0/2

 Receiving time of the last flush packet            : 16:25:21 2012/04/21

 Device ID of the last flush packet                 : 000f-e23d-5af0

 Control VLAN of the last flush packet              : 10

 


Configuring Monitor Link

Overview

Monitor Link associates the state of downlink interfaces with the state of uplink interfaces in a monitor link group. When Monitor Link shuts down the downlink interfaces because of an uplink failure, the downstream device changes connectivity to another link.

Figure 21 Monitor Link application scenario

 

A monitor link group contains uplink and downlink interfaces. An interface can belong to only one monitor link group.

·     Uplink interfaces are the monitored interfaces. The state of a monitor link group is associated with the state of its member uplink interfaces. When the number of uplink interfaces in up state in a monitor link group is less than the specified threshold, the monitor link group goes down and shuts down its downlink interfaces. When the number of uplink interfaces in up state reaches the threshold, the monitor link group comes up and brings up all its downlink interfaces.

·     Downlink interfaces are the monitoring interfaces. The state of the downlink interfaces is associated with the state of the monitor link group. When the state of the monitor link group changes, the state of its member downlink interfaces changes to be consistent with the group state.

As shown in Figure 21:

·     Port 1 and Port 2 of Device B form a monitor link group.

·     Port 1 and Port 2 of Device D form another monitor link group.

·     Port 1 is an uplink interface on both devices, and Port 2 is a downlink interface on both devices.

A monitor link group works independently of other monitor link groups. When the number of uplink interfaces in up state in a monitor link group is less than the specified threshold, the monitor link group goes down and shuts down its downlink interfaces. When the number of uplink interfaces in up state reaches the threshold, the monitor link group comes up and brings up all its downlink interfaces.

Configuration restrictions and guidelines

Follow these restrictions and guidelines when you configure Monitor Link:

·     Do not manually shut down or bring up the downlink interfaces in a monitor link group.

·     To avoid frequent state changes of downlink interfaces in the event that uplink interfaces in the monitor link group flap, you can configure a switchover delay. The switchover delay is the time that the downlink interfaces wait before they come up following an uplink interface.

Monitor Link configuration task list

Tasks at a glance

(Required.) Enabling Monitor Link globally

(Required.) Creating a monitor link group

(Required.) Configuring monitor link group member interfaces

(Optional.) Configuring the uplink interface threshold for triggering monitor link group state switchover

(Optional.) Configuring the switchover delay for the downlink interfaces in a monitor link group

 

Enabling Monitor Link globally

All monitor link groups can operate only after you enable Monitor Link globally. When you disable Monitor Link globally, all monitor link groups cannot operate and the downlink interfaces brought down by the monitor link groups resume their original states.

To enable Monitor Link globally:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable Monitor Link globally.

undo monitor-link disable

By default, Monitor Link is enabled globally.

 

Creating a monitor link group

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a monitor link group and enter monitor link group view.

monitor-link group group-id

By default, no monitor link groups exist.

 

Configuring monitor link group member interfaces

You can configure member interfaces for a monitor link group in monitor link group view or interface view. Configurations made in these views have the same effect. The configuration is supported by the following interfaces:

·     Layer 2 Ethernet interfaces and Layer 2 aggregate interfaces.

·     Layer 3 Ethernet interfaces/subinterfaces and Layer 3 aggregate interfaces/subinterfaces.

Follow these guidelines when you configure monitor link group member interfaces:

·     If you have configured an interface as the downlink interface of a monitor link group, do not configure its subinterfaces as the uplink interfaces of any monitor link group. Otherwise, the Monitor Link operation might be interrupted.

·     The state of subinterfaces is associated with the state of the interface. Do not add the interface and its subinterfaces to the same monitor link group. Otherwise, the monitor link group performance might be affected.

·     Do not add an aggregate interface and its member ports to the same monitor link group. Otherwise, the Monitor Link operation might be interrupted.

·     An interface can be assigned to only one monitor link group.

·     To avoid undesired down/up state changes on the downlink interfaces, configure uplink interfaces before you configure downlink interfaces.

In monitor link group view

To configure member interfaces for a monitor link group in monitor link group view:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter monitor link group view.

monitor-link group group-id

N/A

3.     Configure member interfaces for the monitor link group.

port interface-type { interface-number | interface-number.subnumber } { downlink | uplink }

By default, no member interfaces exist in a monitor link group.

 

In interface view

To configure member interfaces for a monitor link group in interface view:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view or subinterface view.

interface interface-type { interface-number | interface-number.subnumber }

N/A

3.     Configure the interface as a member of a monitor link group.

port monitor-link group group-id { downlink | uplink }

By default, the interface/subinterface is not a monitor link group member.

 

Configuring the uplink interface threshold for triggering monitor link group state switchover

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter monitor link group view.

monitor-link group group-id

N/A

3.     Configure the uplink interface threshold for triggering monitor link group state switchover.

uplink up-port-threshold number-of-port

By default, the uplink interface threshold for triggering monitor link group state switchover is 1.

 

Configuring the switchover delay for the downlink interfaces in a monitor link group

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter monitor link group view.

monitor-link group group-id

N/A

3.     Configure the switchover delay for the downlink interfaces in the monitor link group.

downlink up-delay delay

By default, the switchover delay is 0 seconds. The downlink interfaces come up as soon as an uplink interface comes up.

 

Displaying and maintaining Monitor Link

Execute the display command in any view:

 

Task

Command

Display monitor link group information.

display monitor-link group { group-id | all }

 

Monitor Link configuration example

Network requirements

As shown in Figure 22:

·     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.

·     Implement dual uplink backup on Device C. When the link between Device A and Device B (or Device D) fails, Device C can detect the link fault. It then performs uplink switchover in the smart link group.

For more information about Smart Link, see "Configuring Smart Link."

Figure 22 Network diagram

Configuration procedure

1.     Configure Device C:

# Create VLANs 1 through 30.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

# Map these VLANs to MSTI 1.

[DeviceC] stp region-configuration

[DeviceC-mst-region] instance 1 vlan 1 to 30

# Activate MST region configuration.

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Shut down HundredGigE 1/0/1.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] shutdown

# Disable the spanning tree feature on the interface.

[DeviceC-HundredGigE1/0/1] undo stp enable

# Configure the interface as a trunk port.

[DeviceC-HundredGigE1/0/1] port link-type trunk

# Assign the interface to VLANs 1 through 30.

[DeviceC-HundredGigE1/0/1] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] shutdown

[DeviceC-HundredGigE1/0/2] undo stp enable

[DeviceC-HundredGigE1/0/2] port link-type trunk

[DeviceC-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceC-HundredGigE1/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 HundredGigE 1/0/1 as the primary port and HundredGigE 1/0/2 as the secondary port for smart link group 1.

[DeviceC-smlk-group1] port hundredgige 1/0/1 primary

[DeviceC-smlk-group1] port hundredgige 1/0/2 secondary

# Enable the smart link group to transmit flush messages.

[DeviceC-smlk-group1] flush enable

[DeviceC-smlk-group1] quit

# Bring up HundredGigE 1/0/1 and HundredGigE 1/0/2.

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] undo shutdown

[DeviceC-HundredGigE1/0/1] quit

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] undo shutdown

[DeviceC-HundredGigE1/0/2] quit

2.     Configure Device A:

# Create VLANs 1 through 30.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] port link-type trunk

# Assign the interface to VLANs 1 through 30.

[DeviceA-HundredGigE1/0/1] port trunk permit vlan 1 to 30

# Enable flush message receiving on the interface.

[DeviceA-HundredGigE1/0/1] smart-link flush enable

[DeviceA-HundredGigE1/0/1] quit

# Configure HundredGigE 1/0/2 in the same way HundredGigE 1/0/1 is configured.

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] port link-type trunk

[DeviceA-HundredGigE1/0/2] port trunk permit vlan 1 to 30

[DeviceA-HundredGigE1/0/2] smart-link flush enable

[DeviceA-HundredGigE1/0/2] quit

3.     Configure Device B:

# Create VLANs 1 through 30.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

# Configure HundredGigE 1/0/1 as a trunk port.

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] port link-type trunk

# Assign the interface to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/1] port trunk permit vlan 1 to 30

# Enable flush message receiving on the interface.

[DeviceB-HundredGigE1/0/1] smart-link flush enable

[DeviceB-HundredGigE1/0/1] quit

# Disable the spanning tree feature on HundredGigE 1/0/2.

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] undo stp enable

# Configure the interface as a trunk port.

[DeviceB-HundredGigE1/0/2] port link-type trunk

# Assign the interface to VLANs 1 through 30.

[DeviceB-HundredGigE1/0/2] port trunk permit vlan 1 to 30

# Enable flush message receiving on the interface.

[DeviceB-HundredGigE1/0/2] smart-link flush enable

[DeviceB-HundredGigE1/0/2] quit

# Create monitor link group 1.

[DeviceB] monitor-link group 1

# Configure HundredGigE 1/0/1 as an uplink interface for monitor link group 1.

[DeviceB-mtlk-group1] port hundredgige 1/0/1 uplink

# Configure HundredGigE 1/0/2 as a downlink interface for monitor link group 1.

[DeviceB-mtlk-group1] port hundredgige 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 HundredGigE 1/0/1 as a trunk port.

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] port link-type trunk

# Assign the interface to VLANs 1 through 30.

[DeviceD-HundredGigE1/0/1] port trunk permit vlan 1 to 30

# Enable flush message receiving on the interface.

[DeviceD-HundredGigE1/0/1] smart-link flush enable

[DeviceD-HundredGigE1/0/1] quit

# Disable the spanning tree feature on HundredGigE 1/0/2.

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] undo stp enable

# Configure the interface as a trunk port.

[DeviceD-HundredGigE1/0/2] port link-type trunk

# Assign the interface to VLANs 1 through 30.

[DeviceD-HundredGigE1/0/2] port trunk permit vlan 1 to 30

# Enable flush message receiving on the interface.

[DeviceD-HundredGigE1/0/2] smart-link flush enable

[DeviceD-HundredGigE1/0/2] quit

# Create monitor link group 1.

[DeviceD] monitor-link group 1

# Configure HundredGigE 1/0/1 as an uplink interface for monitor link group 1.

[DeviceD-mtlk-group1] port hundredgige 1/0/1 uplink

# Configure HundredGigE 1/0/2 as a downlink interface for monitor link group 1.

[DeviceD-mtlk-group1] port hundredgige 1/0/2 downlink

[DeviceD-mtlk-group1] quit

Verifying the configuration

# When HundredGigE 1/0/2 on Device A goes down because of a link fault, verify information about monitor link group 1 on Device B.

[DeviceB] display monitor-link group 1

Monitor link group 1 information:

  Group status     : UP

  Downlink up-delay: 0(s)

  Last-up-time     : 16:38:26 2012/4/21

  Last-down-time   : 16:37:20 2012/4/21

  Up-port-threshold: 1

 

  Member                    Role       Status

  --------------------------------------------

  HGE1/0/1                  UPLINK     UP

  HGE1/0/2                  DOWNLINK   UP

# Verify information about monitor link group 1 on Device D.

[DeviceD] display monitor-link group 1

Monitor link group 1 information:

  Group status     : DOWN

  Downlink up-delay: 0(s)

  Last-up-time     : 16:37:20 2012/4/21

  Last-down-time   : 16:38:26 2012/4/21

  Up-port-threshold: 1

 

  Member                    Role       Status

  --------------------------------------------

  HGE1/0/1                  UPLINK     DOWN

  HGE1/0/2                  DOWNLINK   DOWN


Configuring VRRP

Overview

Typically, you can configure a default gateway for every host on a LAN. All packets destined for other networks are sent through the default gateway. As shown in Figure 23, when the default gateway fails, no hosts can communicate with external networks.

Figure 23 LAN networking

 

Using a default gateway facilitates your configuration but requires high availability. Using more egress gateways improves link availability but introduces the problem of routing among the egresses.

Virtual Router Redundancy Protocol (VRRP) is designed to address this issue. VRRP adds a group of network gateways to a VRRP group called a virtual router. The VRRP group has one master and multiple backups, and provides a virtual IP address. The hosts on the subnet use the virtual IP address as their default network gateway to communicate with external networks.

The virtual IP address of the virtual router can be either of the following IP addresses:

·     Unused IP address on the subnet where the VRRP group resides.

·     IP address of an interface on a router in the VRRP group.

In the latter case, the router is called the IP address owner. A VRRP group can have only one IP address owner.

VRRP avoids single points of failure and simplifies the configuration on hosts. When the master in the VRRP group on a multicast or broadcast LAN (for example, an Ethernet network) fails, another router in the VRRP group takes over. The switchover is complete without causing dynamic route recalculation, route re-discovery, gateway reconfiguration on the hosts, or traffic interruption.

VRRP operates in either of the following modes:

·     Standard mode—Implemented based on RFCs. For more information, see "VRRP standard mode."

·     Load balancing mode—Extends the VRRP standard mode to distribute load across VRRP group members. For more information, see "VRRP load balancing mode."

VRRP has two versions: VRRPv2 and VRRPv3. VRRPv2 supports IPv4 VRRP. VRRPv3 supports IPv4 VRRP and IPv6 VRRP.

VRRP group

VRRP adds a group of network gateways to a VRRP group called a virtual router. The VRRP group has one master and multiple backups, and provides a virtual IP address. The hosts on the subnet use the virtual IP address as their default network gateway to communicate with external networks.

The administrator can add a router to a VRRP group by creating the VRRP group on a Layer 3 interface on the router.

 

 

NOTE:

On a device, the interfaces added to VRRP groups having the same VRRP group number belong to different VRRP groups.

 

VRRP standard mode

In VRRP standard mode, only the master in the VRRP group can provide gateway service. When the master fails, the backup routers elect a new master to take over for nonstop gateway service.

Figure 24 VRRP networking

 

As shown in Figure 24, Router A, Router B, and Router C form a virtual router, which has its own IP address. Hosts on the subnet use the virtual router as the default gateway.

The router with the highest priority among the three routers is elected as the master, and the other two are backups.

Router priority in a VRRP group

VRRP determines the role (master or backup) of each router in a VRRP group by priority. A router with higher priority is more likely to become the master.

A VRRP priority can be in the range of 0 to 255, and a greater number represents a higher priority. Priorities 1 to 254 are configurable. Priority 0 is reserved for special uses, and priority 255 is for the IP address owner. The IP address owner in a VRRP group always has a running priority of 255 and acts as the master as long as it operates correctly.

Preemption

A router in a VRRP group operates in either non-preemptive mode or preemptive mode.

·     Non-preemptive mode—The master router acts as the master as long as it operates correctly, even if a backup router is later assigned a higher priority. Non-preemptive mode helps avoid frequent switchover between the master and backup routers.

·     Preemptive mode—A backup starts a new master election and takes over as master when it detects that it has a higher priority than the current master. Preemptive mode ensures that the router with the highest priority in a VRRP group always acts as the master.

Authentication method

To avoid attacks from unauthorized users, VRRP member routers add authentication keys in VRRP packets to authenticate one another. VRRP provides the following authentication methods:

·     Simple authentication

The sender fills an authentication key into the VRRP packet, and the receiver compares the received authentication key with its local authentication key. If the two authentication keys match, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate and gets discarded.

·     MD5 authentication

The sender computes a digest for the VRRP packet by using the authentication key and MD5 algorithm, and saves the result to the packet. The receiver performs the same operation with the authentication key and MD5 algorithm, and compares the result with the content in the authentication header. If the results match, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate and gets discarded.

On a secure network, you can choose to not authenticate VRRP packets.

 

 

NOTE:

IPv4 VRRPv3 and IPv6 VRRPv3 do not support VRRP packet authentication.

 

VRRP timers

Skew_Time

Skew_Time helps avoid the situation that multiple backups in a VRRP group become the master when the master in the VRRP group fails.

Skew_Time is not configurable; its value depends on the VRRP version.

·     In VRRPv2 (described in RFC 3768), Skew_Time is (256 – Router priority)/256.

·     In VRRPv3 (described in RFC 5798), Skew_Time is ((256 – Router priority) × VRRP advertisement interval)/256.

VRRP advertisement interval

The master in a VRRP group periodically sends VRRP advertisements to declare its presence.

You can configure the interval at which the master sends VRRP advertisements. If a backup does not receive any VRRP advertisement when the timer (3 × VRRP advertisement interval + Skew_Time) expires, it takes over as the master.

VRRP preemption delay timer

You can configure the VRRP preemption delay timer for the following purposes:

·     Avoid frequent state changes among members in a VRRP group.

·     Provide the backups with enough time to collect information (such as routing information).

In preempt mode, a backup does not immediately become the master after it receives an advertisement with lower priority than the local priority. Instead, it waits for a period of time (preemption delay time + Skew_Time) before taking over as the master.

Master election

Routers in a VRRP group determine their roles by priority. When a router joins a VRRP group, it has a backup role. The router role changes according to the following situations:

·     If the backup does not receive any VRRP advertisement when the timer (3 × advertisement interval + Skew_Time) expires, it becomes the master.

·     If the backup receives a VRRP advertisement with the same or greater priority within the timer (3 × advertisement interval + Skew_Time), it remains a backup.

·     If the backup receives a VRRP advertisement with a smaller priority within the timer (3 × advertisement interval + Skew_Time), the following results apply:

¡     It remains a backup when operating in non-preemptive mode.

¡     It becomes the master when operating in preemptive mode.

The elected master starts a VRRP advertisement interval to periodically send VRRP advertisements to notify the backups that it is operating correctly. Each of the backups starts a timer to wait for advertisements from the master.

After a backup receives a VRRP advertisement, it compares only the priority in the packet with its own priority.

When multiple routers in a VRRP group declare that they are the master because of network problems, the one with the highest priority becomes the master. If two routers have the same priority, the one with the highest IP address becomes the master.

VRRP tracking

To enable VRRP tracking, configure the routers in the VRRP group to operate in preemptive mode first. This configuration ensures that only the router with the highest priority operates as the master.

The VRRP tracking function uses network quality analyzer (NQA) or bidirectional forwarding detection (BFD) to monitor the state of the master or the upstream link. The collaboration between VRRP and NQA or BFD through a track entry implements the following functions:

·     Monitors the upstream link and changes the priority of the router according to the state of the link. If the upstream link fails, the hosts on the subnet cannot access external networks through the router and the state of the track entry becomes Negative. The priority of the master decreases by a specified value, and a router with a higher priority in the VRRP group becomes the master. The switchover ensures uninterrupted communication between the hosts on the subnet and external networks.

·     Monitors the state of the master on the backups. When the master fails, a backup immediately takes over to ensure uninterrupted communication.

When the track entry changes from Negative to Positive or Notready, the router automatically restores its priority. For more information about track entries, see "Configuring Track."

VRRP application

Master/backup

In master/backup mode, only the master forwards packets, as shown in Figure 25. When the master fails, a new master is elected from among the backups. This mode requires only one VRRP group, and each router in the group has a different priority. The one with the highest priority becomes the master.

Figure 25 VRRP in master/backup mode

 

Assume that Router A is acting as the master to forward packets to external networks, and Router B and Router C are backups in listening state. When Router A fails, Router B and Router C elect a new master to forward packets for hosts on the subnet.

Load sharing

A router can join multiple VRRP groups. With different priorities in different VRRP groups, the router can act as the master in one VRRP group and a backup in another.

In load sharing mode, multiple VRRP groups provide gateway services. This mode requires a minimum of two VRRP groups, and each group has one master and multiple backups. The master roles in the VRRP groups are assumed by different routers, as shown in Figure 26.

Figure 26 Load sharing of VRRP

 

A router can be in multiple VRRP groups and have a different priority in each group.

As shown in Figure 26, the following VRRP groups exist:

·     VRRP group 1—Router A is the master. Router B and Router C are the backups.

·     VRRP group 2—Router B is the master. Router A and Router C are the backups.

·     VRRP group 3—Router C is the master. Router A and Router B are the backups.

To implement load sharing among Router A, Router B, and Router C, perform the following tasks:

·     Configure the virtual IP addresses of VRRP group 1, 2, and 3 as default gateway IP addresses for hosts on the subnet.

·     Assign the highest priority to Router A, B, and C in VRRP group 1, 2, and 3, respectively.

VRRP load balancing mode

In a standard-mode VRRP group, only the master can forward packets and backups are in listening state. You can create multiple VRRP groups to share traffic, but you must configure different gateways for hosts on the subnet.

In load balancing mode, a VRRP group maps its virtual IP address to multiple virtual MAC addresses, assigning one virtual MAC address to each member router. Every router in this VRRP group can forward traffic and respond to IPv4 ARP requests or IPv6 ND requests from hosts. Because their virtual MAC addresses are different, traffic from hosts is distributed across the VRRP group members. Load balancing mode simplifies configuration and improves forwarding efficiency.

VRRP load balancing mode uses the same master election, preemption, and tracking mechanisms as the standard mode. New mechanisms have been introduced to VRRP load balancing mode, as described in the following sections.

Virtual MAC address assignment

In load balancing mode, the master assigns virtual MAC addresses to routers in the VRRP group. The master uses different MAC addresses to respond to ARP requests or ND requests from different hosts. The backup routers, however, do not answer ARP requests or ND requests from hosts.

In an IPv4 network, a load balanced VRRP group works as follows:

1.     The master assigns virtual MAC addresses to all member routers, including itself. This example assumes that the virtual IP address of the VRRP group is 10.1.1.1/24, Router A is the master, and Router B is the backup. Router A assigns 000f-e2ff-0011 for itself and 000f-e2ff-0012 for Router B. See Figure 27.

Figure 27 Virtual MAC address assignment

 

2.     When an ARP request arrives, the master (Router A) selects a virtual MAC address based on the load balancing algorithm to answer the ARP request. In this example, Router A returns the virtual MAC address of itself in response to the ARP request from Host A. Router A returns the virtual MAC address of Router B in response to the ARP request from Host B. See Figure 28.

Figure 28 Answering ARP requests

 

3.     Each host sends packets to the returned MAC address. As shown in Figure 29, Host A sends packets to Router A and Host B sends packets to Router B.

Figure 29 Sending packets to different routers for forwarding

 

In the ARP reply sent by the master, the source MAC address in the Ethernet header is different from the sender MAC address in the message body. For the Layer 2 device to forward the ARP packet, follow these configuration guidelines on the Layer 2 device:

·     Do not enable ARP packet source MAC address consistency check.

·     Do not specify the src-mac keyword when you enable ARP packet validity check for ARP detection.

For more information about ARP packet source MAC address consistency check and ARP detection, see Security Configuration Guide.

Virtual forwarder

Virtual forwarder creation

Virtual MAC addresses enable traffic distribution across routers in a VRRP group. To enable routers in the VRRP group to forward packets, VFs must be created on them. Each VF is associated with a virtual MAC address in the VRRP group and forwards packets that are sent to this virtual MAC address.

VFs are created on routers in a VRRP group, as follows:

1.     The master assigns virtual MAC addresses to all routers in the VRRP group. Each member router creates a VF for this MAC address and becomes the owner of this VF.

2.     Each VF owner advertises its VF information to the other member routers.

3.     After receiving the VF advertisement, each of the other routers creates the advertised VF.

Eventually, every member router maintains one VF for each virtual MAC address in the VRRP group.

VF weight and priority

The weight of a VF indicates the forwarding capability of a VF. A higher weight means higher forwarding capability. When the weight is lower than the lower limit of failure, the VF cannot forward packets.

The priority of a VF determines the VF state. Among the VFs created on different member routers for the same virtual MAC address, the VF with the highest priority is in active state. This VF, known as the active virtual forwarder (AVF), forwards packets. All other VFs listen to the state of the AVF and are known as the listening virtual forwarders (LVFs). VF priority is in the range of 0 to 255, where 255 is reserved for the VF owner. When the weight of a VF owner is higher than or equal to the lower limit of failure, the priority of the VF owner is 255.

The priority of a VF is calculated based on its weight.

·     If the VF weight is higher than or equal to the lower limit of failure, the following VF priorities apply:

¡     On a VF owner, the VF priority is 255.

¡     On a non-VF owner, the VF priority is calculated as weight/(number of local AVFs + 1).

·     If the VF weight is lower than the lower limit of failure, the VF priority is 0.

VF backup

The VFs corresponding to a virtual MAC address on different routers in the VRRP group back up one another.

Figure 30 VF information

 

Figure 30 shows the VF table on each router in the VRRP group and how the VFs back up one another. The master, Router A, assigns virtual MAC addresses 000f-e2ff-0011, 000f-e2ff-0012, and 000f-e2ff-0013 to itself, Router B, and Router C, respectively. Each router creates VF 1, VF 2, and VF 3 for virtual MAC addresses 000f-e2ff-0011, 000f-e2ff-0012, and 000f-e2ff-0013, respectively. The VFs for the same virtual MAC address on different routers back up one another. For example, the VF 1 instances on Router A, Router B, and Router C back up one another.

·     The VF 1 instance on Router A (the VF 1 owner) has priority 255. It acts as the AVF to forward packets sent to virtual MAC address 000f-e2ff-0011.

·     The VF 1 instances on Router B and Router C have a priority of 255/(1 + 1), or 127. Because their priorities are lower than the priority of the VF 1 instance on Router A, they act as LVFs. These LVFs listen to the state of the VF 1 instance on Router A.

·     When the VF 1 instance on Router A fails, the VF 1 instances on Router B and Router C elect the one with higher priority as the new AVF. This AVF forwards packets destined for virtual MAC address 000f-e2ff-0011. If the two LVFs' priorities are the same, the LVF with a greater device MAC address becomes the new AVF.

A VF always operates in preemptive mode. When an LVF finds its priority value higher than the one advertised by the AVF, the LVF declares itself as the AVF.

VF timers

When the AVF on a router fails, the new AVF on another router creates the following timers for the failed AVF:

·     Redirect timer—Before this timer expires, the master still uses the virtual MAC address corresponding to the failed AVF to respond to ARP/ND requests from hosts. The VF owner can share traffic load if the VF owner resumes normal operation within this time. When this timer expires, the master stops using the virtual MAC address corresponding to the failed AVF to respond to ARP/ND requests from hosts.

·     Timeout timer—The duration after which the new AVF takes over responsibilities of the failed VF owner. Before this timer expires, all routers in the VRRP group keep the VFs that correspond to the failed AVF. The new AVF forwards packets destined for the virtual MAC address of the failed AVF. When this timer expires, all routers in the VRRP group remove the VFs that correspond to the failed AVF, including the new AVF. Packets destined for the virtual MAC address of the failed AVF are not forwarded any longer.

VF tracking

An AVF forwards packets destined for the MAC address of the AVF. If the AVF's upstream link fails but no LVF takes over, the hosts that use the AVF's MAC address as their gateway MAC address cannot access the external network.

The VF tracking function can solve this problem. You can use NQA or BFD to monitor the upstream link state of the VF owner, and associate the VFs with NQA or BFD through the tracking function. This enables the collaboration between VRRP and NQA or BFD through the Track module. When the upstream link fails, the state of the track entry changes to Negative. The weights of the VFs (including the AVF) on the router decrease by a specific value. The corresponding LVF with a higher priority on another router becomes the AVF and forwards packets.

Protocols and standards

·     RFC 3768, Virtual Router Redundancy Protocol (VRRP)

·     RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Configuring IPv4 VRRP

VRRP cannot be configured on member ports of aggregation groups.

IPv4 VRRP configuration task list

Tasks at a glance

Remarks

(Required.) Specifying an IPv4 VRRP operating mode

N/A

(Optional.) Specifying the IPv4 VRRP version

N/A

(Required.) Creating a VRRP group and assigning a virtual IP address

N/A

(Optional.) Configuring the router priority, preemptive mode, and tracking function

N/A

(Optional.) Configuring IPv4 VRRP packet attributes

N/A

(Optional.) Configuring VF tracking

This configuration applies only to VRRP load balancing mode.

(Optional.) Enabling SNMP notifications for VRRP

N/A

(Optional.) Disabling an IPv4 VRRP group

N/A

 

Specifying an IPv4 VRRP operating mode

A VRRP group can operate in either of the following modes:

·     Standard mode—Only the master can forward packets.

·     Load balancing mode—All members that have an AVF can forward packets.

After an IPv4 VRRP operating mode is configured on a router, all IPv4 VRRP groups on the router operate in the specified operating mode.

To specify an IPv4 VRRP operating mode:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify an IPv4 VRRP operating mode.

·     Specify the standard mode:
undo vrrp mode

·     Specify the load balancing mode:
vrrp mode load-balance [ version-8 ]

By default, VRRP operates in standard mode.

 

Specifying the IPv4 VRRP version

The VRRP version on all routers in an IPv4 VRRP group must be the same.

To specify the version of IPv4 VRRP:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Specify the version of VRRP.

vrrp version version-number

By default, VRRPv3 is used.

 

Creating a VRRP group and assigning a virtual IP address

A VRRP group can operate correctly after you create it and assign a minimum of one virtual IP address to it. You can configure multiple virtual IP addresses for the VRRP group on an interface that connects to multiple subnets for router backup on different subnets.

Configuration guidelines

·     In VRRP load balancing mode, the device supports a maximum of MaxVRNum/N VRRP groups. MaxVRNum refers to the maximum number of VRRP groups supported by the device in VRRP standard mode. N refers to the number of devices in the VRRP group.

·     When VRRP is operating in standard mode, the virtual IP address of a VRRP group can be either of the following addresses:

¡     Unused IP address on the subnet where the VRRP group resides.

¡     IP address of an interface on a router in the VRRP group.

·     In load balancing mode, the virtual IP address of a VRRP group can be any unassigned IP address of the subnet where the VRRP group resides. It cannot be the IP address of any interface in the VRRP group. No IP address owner can exist in a VRRP group.

·     On an IP address owner, as a best practice, do not use the network command to enable OSPF on the interface owning the virtual IP address of the VRRP group. For more information about the network command, see Layer 3—IP Routing Command Reference.

·     If you create an IPv4 VRRP group without assigning virtual IP address to it, the VRRP group stays in inactive state and does not function.

·     Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the collision, change the IP address of the interface on the IP address owner before you remove the VRRP group from the interface.

·     The virtual IP address of an IPv4 VRRP group and the downlink interface IP address of the VRRP group must be in the same subnet. Otherwise, the hosts in the subnet might fail to access external networks.

Configuration procedure

To create a VRRP group and assign a virtual IP address:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Create a VRRP group and assign a virtual IP address.

vrrp vrid virtual-router-id virtual-ip virtual-address

By default, no VRRP groups exist.

 

Configuring the router priority, preemptive mode, and tracking function

The router priority determines which router in the VRRP group acts as the master. The preemptive mode enables a backup to take over as the master when it detects that it has a higher priority than the current master. The tracking function decreases the router priority or enables the backup to take over as the master when the state of the monitored track entry transits to Negative.

Configuration guidelines

·     The running priority of an IP address owner is always 255, and you do not need to configure it. An IP address owner always operates in preemptive mode.

·     If you configure the vrrp vrid track priority reduced or vrrp vrid track switchover command on an IP address owner, the configuration does not take effect until the router becomes a non-IP address owner.

Configuration procedure

To configure the router priority, preemptive mode, and tracking function:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Set the priority of the router in the VRRP group.

vrrp vrid virtual-router-id priority priority-value

The default setting is 100.

4.     Enable the preemptive mode for the router in a VRRP group and set the preemption delay time.

vrrp vrid virtual-router-id preempt-mode [ delay delay-value ]

By default, the router in a VRRP group operates in preemptive mode and the preemption delay time is 0 centiseconds, which means an immediate preemption.

5.     Associate a VRRP group with a track entry.

vrrp vrid virtual-router-id track track-entry-number { forwarder-switchover member-ip ip-address | priority reduced [ priority-reduced ] | switchover | weight reduced [ weight-reduced ] }

By default, a VRRP group is not associated with any track entries.

 

Configuring IPv4 VRRP packet attributes

Configuration guidelines

·     You can configure different authentication modes and authentication keys for VRRP groups on an interface. However, members of the same VRRP group must use the same authentication mode and authentication key.

·     In VRRPv2, all routers in a VRRP group must have the same VRRP advertisement interval.

·     In VRRPv3, authentication mode and authentication key settings do not take effect.

·     In VRRPv3, routers in an IPv4 VRRP group can have different intervals for sending VRRP advertisements. The master in the VRRP group sends VRRP advertisements at specified intervals, and carries the interval in the advertisements. After a backup receives the advertisement, it records the interval in the advertisement. If the backup does not receive a VRRP advertisement before the timer (3 x recorded interval + Skew_Time) expires, it regards the master as failed and takes over.

Configuration procedure

To configure VRRP packet attributes:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Configure the authentication mode and authentication key for an IPv4 VRRP group to send and receive VRRP packets.

vrrp vrid virtual-router-id authentication-mode { md5 | simple } { cipher | plain } string

By default, authentication is disabled.

4.     Set the interval at which the master in an IPv4 VRRP group sends VRRP advertisements.

vrrp vrid virtual-router-id timer advertise adver-interval

The default setting is 100 centiseconds.

As a best practice to maintain system stability, set the VRRP advertisement interval to be greater than 100 centiseconds.

5.     Specify the source interface for receiving and sending VRRP packets.

vrrp vrid virtual-router-id source-interface interface-type interface-number

By default, the source interface for receiving and sending VRRP packets is not specified. The interface where the VRRP group resides sends and receives VRRP packets.

6.     Enable TTL check for IPv4 VRRP packets.

vrrp check-ttl enable

By default, TTL check for IPv4 VRRP packets is enabled.

7.     Return to system view.

quit

N/A

8.     Set a DSCP value for VRRP packets.

vrrp dscp dscp-value

The DSCP value identifies the packet priority during transmission.

By default, the DSCP value for VRRP packets is 48.

 

Configuring VF tracking

You can configure VF tracking in both standard mode and load balancing mode, but the function takes effect only in load balancing mode.

In load balancing mode, you can establish the collaboration between the VFs and NQA or BFD through the tracking function. When the state of the track entry transits to Negative, the weights of all VFs in the VRRP group on the router decrease by a specific value. When the state of the track entry transits to Positive or Notready, the original weight values of the VFs restore.

Configuration guidelines

·     By default, the weight of a VF is 255, and its lower limit of failure is 10.

·     When the weight of a VF owner is higher than or equal to the lower limit of failure, its priority is always 255. The priority does not change with the weight. When the upstream link of the VF owner fails, an LVF must take over as the AVF. The switchover happens when the weight of the VF owner drops below the lower limit of failure. This requires that the reduced weight for the VF owner be higher than 245.

Configuration procedure

To configure VF tracking:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Configure the VFs in a VRRP group to monitor a track entry.

vrrp vrid virtual-router-id track track-entry-number { forwarder-switchover member-ip ip-address | priority reduced [ priority-reduced ] | switchover | weight reduced [ weight-reduced ] }

By default, no track entry is specified.

 

Enabling SNMP notifications for VRRP

To report critical VRRP events to an NMS, enable SNMP notifications for VRRP. For VRRP event notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see the network management and monitoring configuration guide for the device.

To enable SNMP notifications for VRRP:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable SNMP notifications for VRRP.

snmp-agent trap enable vrrp [ auth-failure | new-master ]

By default, SNMP notifications for VRRP are enabled.

 

Disabling an IPv4 VRRP group

You can temporarily disable an IPv4 VRRP group. After being disabled, the VRRP group stays in initialized state, and its configurations remain unchanged. You can change the configuration of a VRRP group when the VRRP group is disabled. Your changes take effect when you enable the VRRP group again.

To disable an IPv4 VRRP group:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Disable a VRRP group.

vrrp vrid virtual-router-id shutdown

By default, a VRRP group is enabled.

 

Displaying and maintaining IPv4 VRRP

Execute display commands in any view and the reset command in user view.

 

Task

Command

Display states of IPv4 VRRP groups.

display vrrp [ interface interface-type interface-number [ vrid virtual-router-id ] ] [ verbose ]

Display statistics for IPv4 VRRP groups.

display vrrp statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ]

Clear statistics for IPv4 VRRP groups.

reset vrrp statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ]

 

Configuring IPv6 VRRP

This section describes how to configure IPv6 VRRP.

IPv6 VRRP configuration task list

Tasks at a glance

Remarks

(Required.) Specifying an IPv6 VRRP operating mode

N/A

(Required.) Creating a VRRP group and assigning a virtual IPv6 address

N/A

(Optional.) Configuring the router priority, preemptive mode, and tracking function

N/A

(Optional.) Configuring VF tracking

This configuration applies only to VRRP load balancing mode.

(Optional.) Configuring IPv6 VRRP packet attributes

N/A

(Optional.) Disabling an IPv6 VRRP group

N/A

 

Specifying an IPv6 VRRP operating mode

A VRRP group can operate in either of the following modes:

·     Standard mode—Only the master can forward packets.

·     Load balancing mode—All members that have an AVF can forward packets.

After the IPv6 VRRP operating mode is specified on a router, all IPv6 VRRP groups on the router operate in the specified operating mode.

To specify an IPv6 VRRP operating mode:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify an IPv6 VRRP operating mode.

·     Specify the standard mode:
undo vrrp ipv6 mode

·     Specify the load balancing mode:
vrrp ipv6 mode load-balance

By default, VRRP operates in standard mode.

 

Creating a VRRP group and assigning a virtual IPv6 address

A VRRP group can work correctly after you create it and assign a minimum of one virtual IPv6 address for it. You can configure multiple virtual IPv6 addresses for the VRRP group on an interface that connects to multiple subnets for router backup.

Configuration guidelines

·     On an IP address owner, as a best practice, do not use the ospfv3 area command to enable OSPF on the interface owning the virtual IPv6 address of the VRRP group. For more information about the ospfv3 area command, see Layer 3—IP Routing Command Reference.

·     In load balancing mode, the virtual IPv6 address of a VRRP group cannot be the same as the IPv6 address of any interface in the VRRP group.

·     In VRRP load balancing mode, the device supports a maximum of MaxVRNum/N VRRP groups. MaxVRNum refers to the maximum number of VRRP groups supported by the device in VRRP standard mode. N refers to the number of devices in the VRRP group.

·     If you create an IPv6 VRRP group without assigning virtual IPv6 address to it, the VRRP group stays in inactive state and does not function.

·     Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the collision, change the IPv6 address of the interface on the IP address owner before you remove the VRRP group from the interface.

·     The virtual IPv6 address of an IPv6 VRRP group and the downlink interface IPv6 address of the VRRP group must be in the same subnet. Otherwise, the hosts in the subnet might fail to access external networks.

Configuration procedure

To create a VRRP group and assign a virtual IPv6 address:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Create a VRRP group and assign a virtual IPv6 address, which is a link-local address.

vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address link-local

By default, no VRRP groups exist.

The first virtual IPv6 address that you assign to an IPv6 VRRP group must be a link-local address. It must be the last address you remove. Only one link local address is allowed in a VRRP group.

4.     (Optional.) Assign a virtual IPv6 address, which is a global unicast address.

vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address

By default, no global unicast address is assigned for an IPv6 VRRP group.

 

Configuring the router priority, preemptive mode, and tracking function

Configuration guidelines

·     The running priority of an IP address owner is always 255, and you do not need to configure it. An IP address owner always operates in preemptive mode.

·     If you configure the vrrp ipv6 vrid track priority reduced or vrrp ipv6 vrid track switchover command on an IP address owner, the configuration does not take effect until the router becomes a non-IP address owner.

·     When the track entry changes from Negative to Positive or Notready, the router automatically restores its priority or the failed master router becomes the master again.

Configuration procedure

To configure the router priority, preemptive mode, and tracking function:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Set the priority of the router in the VRRP group.

vrrp ipv6 vrid virtual-router-id priority priority-value

The default setting is 100.

4.     Enable the preemptive mode for the router in a VRRP group and set the preemption delay time.

vrrp ipv6 vrid virtual-router-id preempt-mode [ delay delay-value ]

By default, the router in a VRRP group operates in preemptive mode and the preemption delay time is 0 centiseconds, which means an immediate preemption.

5.     Associate a VRRP group with a track entry.

vrrp ipv6 vrid virtual-router-id track track-entry-number { forwarder-switchover member-ip ipv6-address | priority reduced [ priority-reduced ] | switchover | weight reduced [ weight-reduced ] }

By default, a VRRP group is not associated with any track entries.

 

Configuring VF tracking

You can configure VF tracking in both standard mode and load balancing mode, but the function takes effect only in load balancing mode.

In load balancing mode, you can configure the VFs in a VRRP group to monitor a track entry. When the state of the track entry transits to Negative, the weights of all VFs in the VRRP group on the router decrease by a specific value. When the state of the track entry transits to Positive or Notready, the original weights of the VFs restore.

Configuration guidelines

·     By default, the weight of a VF is 255, and its lower limit of failure is 10.

·     When the weight of a VF owner is higher than or equal to the lower limit of failure, its priority is always 255. The priority does not change with the weight. When the upstream link of the VF owner fails, an LVF must take over as the AVF. The switchover happens when the weight of the VF owner drops below the lower limit of failure. This requires that the reduced weight for the VF owner be higher than 245.

Configuration procedure

To configure VF tracking:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Configure the VFs in a VRRP group to monitor a track entry.

vrrp ipv6 vrid virtual-router-id track track-entry-number { forwarder-switchover member-ip ipv6-address | priority reduced [ priority-reduced ] | switchover | weight reduced [ weight-reduced ] }

By default, no track entry is specified.

 

Configuring IPv6 VRRP packet attributes

This section describes how to configure IPv6 VRRP packet attributes.

Configuration guidelines

·     The routers in an IPv6 VRRP group can have different intervals for sending VRRP advertisements. The master in the VRRP group sends VRRP advertisements at the specified interval and carries the interval attribute in the advertisements. After a backup receives the advertisement, it records the interval in the advertisement. If the backup does not receive a VRRP advertisement before the timer (3 x recorded interval + Skew_Time) expires, it regards the master as failed and takes over.

·     A high volume of network traffic might cause a backup to fail to receive VRRP advertisements from the master within the specified time. As a result, an unexpected master switchover occurs. To solve this problem, configure a larger interval.

Configuration procedure

To configure the IPv6 VRRP packet attribute:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Set the IPv6 VRRP advertisement interval.

vrrp ipv6 vrid virtual-router-id timer advertise adver-interval

The default setting is 100 centiseconds.

As a best practice to maintain system stability, set the VRRP advertisement interval to be greater than 100 centiseconds.

4.     Return to system view.

quit

N/A

5.     Set a DSCP value for IPv6 VRRP packets.

vrrp ipv6 dscp dscp-value

The DSCP value identifies the packet priority during transmission.

By default, the DSCP value for IPv6 VRRP packets is 56.

 

Disabling an IPv6 VRRP group

You can temporarily disable an IPv6 VRRP group. After being disabled, the VRRP group stays in initialized state, and its configurations remain unchanged. You can change the configuration of a VRRP group when it is disabled. Your changes take effect when you enable the VRRP group again.

To disable an IPv6 VRRP group:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Disable an IPv6 VRRP group.

vrrp ipv6 vrid virtual-router-id shutdown

By default, an IPv6 VRRP group is enabled.

 

Displaying and maintaining IPv6 VRRP

Execute display commands in any view and the reset command in user view.

 

Task

Command

Display the states of IPv6 VRRP groups.

display vrrp ipv6 [ interface interface-type interface-number [ vrid virtual-router-id ] ] [ verbose ]

Display statistics for IPv6 VRRP groups.

display vrrp ipv6 statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ]

Clear statistics for IPv6 VRRP groups.

reset vrrp ipv6 statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ]

 

IPv4 VRRP configuration examples

Single VRRP group configuration example

Network requirements

As shown in Figure 31, Switch A and Switch B form a VRRP group. They use the virtual IP address 10.1.1.111/24 to provide gateway service for the subnet where Host A resides.

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 31 Network diagram

Configuration procedure

1.     Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] vlan 2

[SwitchA-vlan2] port hundredgige 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ip address 10.1.1.1 255.255.255.0

# Create VRRP group 1 on VLAN-interface 2, and set its virtual IP address to 10.1.1.111.

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.111

# Assign Switch A a higher priority than Switch B in VRRP group 1, so Switch A can become the master.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

# Configure Switch A to operate in preemptive mode, so it can become the master whenever it operates correctly. Set the preemption delay to 5000 centiseconds to avoid frequent status switchover.

[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5000

2.     Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] vlan 2

[SwitchB-Vlan2] port hundredgige 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ip address 10.1.1.2 255.255.255.0

# Create VRRP group 1 on VLAN-interface 2, and set its virtual IP address to 10.1.1.111.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.111

# Set the priority of Router B to 100 in VRRP group 1.

[SwitchB-Vlan-interface2] vrrp vrid 1 priority 100

# Configure Switch B to operate in preemptive mode, and set the preemption delay to 5000 centiseconds.

[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5000

Verifying the configuration

# Ping Host B from Host A. (Details not shown.)

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Standard

 Total number of virtual routers : 1

   Interface Vlan-interface2

     VRID           : 1                    Adver Timer  : 100

     Admin Status   : Up                   State        : Master

     Config Pri     : 110                  Running Pri  : 110

     Preempt Mode   : Yes                  Delay Time   : 5000

     Auth Type      : None

     Virtual IP     : 10.1.1.111

     Virtual MAC    : 0000-5e00-0101

     Master IP      : 10.1.1.1

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Standard

 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   : 5000

     Become Master  : 401ms left

     Auth Type      : None

     Virtual IP     : 10.1.1.111

     Master IP      : 10.1.1.1

The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from Host A to Host B.

# Disconnect the link between Host A and Switch A, and verify that Host A can still ping Host B. (Details not shown.)

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Standard

 Total number of virtual routers : 1

   Interface Vlan-interface2

     VRID           : 1                    Adver Timer  : 100

     Admin Status   : Up                   State        : Master

     Config Pri     : 100                  Running Pri  : 100

     Preempt Mode   : Yes                  Delay Time   : 5000

     Auth Type      : None

     Virtual IP     : 10.1.1.111

     Virtual MAC    : 0000-5e00-0101

     Master IP      : 10.1.1.2

The output shows that when Switch A fails, Switch B takes over to forward packets from Host A to Host B.

# Recover the link between Host A and Switch A, and display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Standard

 Total number of virtual routers : 1

   Interface Vlan-interface2

     VRID           : 1                    Adver Timer  : 100

     Admin Status   : Up                   State        : Master

     Config Pri     : 110                  Running Pri  : 110

     Preempt Mode   : Yes                  Delay Time   : 5000

     Auth Type      : None

     Virtual IP     : 10.1.1.111

     Virtual MAC    : 0000-5e00-0101

     Master IP      : 10.1.1.1

The output shows that after Switch A resumes normal operation, it becomes the master to forward packets from Host A to Host B.

Multiple VRRP groups configuration example

Network requirements

As shown in Figure 32, Switch A and Switch B form two VRRP groups. VRRP group 1 uses the virtual IP address 10.1.1.100/25 to provide gateway service for hosts in VLAN 2, and VRRP group 2 uses the virtual IP address 10.1.1.200/25 to provide gateway service for hosts in VLAN 3.

Assign a higher priority to Switch A than Switch B in VRRP group 1, but a lower priority in VRRP group 2. Traffic from VLAN 2 and VLAN 3 can then be distributed between the two switches. When one of the switches fails, the healthy switch provides gateway service for both VLANs.

Figure 32 Network diagram

Configuration procedure

1.     Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] vlan 2

[SwitchA-vlan2] port hundredgige 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ip address 10.1.1.1 255.255.255.128

# Create VRRP group 1, and set its virtual IP address to 10.1.1.100.

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.100

# Assign Switch A a higher priority than Switch B in VRRP group 1, so Switch A can become the master in the group.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

[SwitchA-Vlan-interface2] quit

# Configure VLAN 3.

[SwitchA] vlan 3

[SwitchA-vlan3] port hundredgige 1/0/6

[SwitchA-vlan3] quit

[SwitchA] interface vlan-interface 3

[SwitchA-Vlan-interface3] ip address 10.1.1.130 255.255.255.128

# Create VRRP group 2, and set its virtual IP address to 10.1.1.200.

[SwitchA-Vlan-interface3] vrrp vrid 2 virtual-ip 10.1.1.200

2.     Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] vlan 2

[SwitchB-vlan2] port hundredgige 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ip address 10.1.1.2 255.255.255.128

# Create VRRP group 1, and set its virtual IP address to 10.1.1.100.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.100

[SwitchB-Vlan-interface2] quit

# Configure VLAN 3.

[SwitchB] vlan 3

[SwitchB-vlan3] port hundredgige 1/0/6

[SwitchB-vlan3] quit

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] ip address 10.1.1.131 255.255.255.128

# Create VRRP group 2, and set its virtual IP address to 10.1.1.200.

[SwitchB-Vlan-interface3] vrrp vrid 2 virtual-ip 10.1.1.200

# Assign Switch B a higher priority than Switch A in VRRP group 2, so Switch B can become the master in the group.

[SwitchB-Vlan-interface3] vrrp vrid 2 priority 110

Verifying the configuration

# Display detailed information about the VRRP groups on Switch A.

[SwitchA-Vlan-interface3] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Standard

 Total number of virtual routers : 2

   Interface Vlan-interface2

     VRID           : 1                    Adver Timer  : 100

     Admin Status   : Up                   State        : Master

     Config Pri     : 110                  Running Pri  : 110

     Preempt Mode   : Yes                  Delay Time   : 0

     Auth Type      : None

     Virtual IP     : 10.1.1.100

     Virtual MAC    : 0000-5e00-0101

     Master IP      : 10.1.1.1

 

   Interface Vlan-interface3

     VRID           : 2                    Adver Timer  : 100

     Admin Status   : Up                   State        : Backup

     Config Pri     : 100                  Running Pri  : 100

     Preempt Mode   : Yes                  Delay Time   : 0

     Become Master  : 203ms left

     Auth Type      : None

     Virtual IP     : 10.1.1.200

     Master IP      : 10.1.1.131

# Display detailed information about the VRRP groups on Switch B.

[SwitchB-Vlan-interface3] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Standard

 Total number of virtual routers : 2

   Interface Vlan-interface2

     VRID           : 1                    Adver Timer  : 100

     Admin Status   : Up                   State        : Backup

     Config Pri     : 100                  Running Pri  : 100

     Preempt Mode   : Yes                  Delay Time   : 0

     Become Master  : 211ms left

     Auth Type      : None

     Virtual IP     : 10.1.1.100

     Master IP      : 10.1.1.1

 

   Interface Vlan-interface3

     VRID           : 2                    Adver Timer  : 100

     Admin Status   : Up                   State        : Master

     Config Pri     : 110                  Running Pri  : 110

     Preempt Mode   : Yes                  Delay Time   : 0

     Auth Type      : None

     Virtual IP     : 10.1.1.200

     Virtual MAC    : 0000-5e00-0102

     Master IP      : 10.1.1.131

The output shows the following information:

·     Switch A is operating as the master in VRRP group 1 to forward Internet traffic for hosts that use the default gateway 10.1.1.100/25.

·     Switch B is operating as the master in VRRP group 2 to forward Internet traffic for hosts that use the default gateway 10.1.1.200/25.

VRRP load balancing configuration example

Network requirements

As shown in Figure 33, Switch A, Switch B, and Switch C form a load-balanced VRRP group. They use the virtual IP address 10.1.1.1/24 to provide gateway service for subnet 10.1.1.0/24.

Configure VFs on Switch A, Switch B, and Switch C to monitor their respective VLAN-interface 3. When the interface on any one of them fails, the weights of the VFs on the problematic switch decrease so another AVF can take over.

Figure 33 Network diagram

Configuration procedure

1.     Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] vlan 2

[SwitchA-vlan2] port hundredgige 1/0/5

[SwitchA-vlan2] quit

# Configure VRRP to operate in load balancing mode.

[SwitchA] vrrp mode load-balance

# Create VRRP group 1, and set its virtual IP address to 10.1.1.1.

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ip address 10.1.1.2 24

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.1

# Assign Switch A the highest priority in VRRP group 1, so Switch A can become the master.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 120

# Configure Switch A to operate in preemptive mode, so it can become the master whenever it operates correctly. Set the preemption delay to 5000 centiseconds to avoid frequent status switchover.

[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5000

[SwitchA-Vlan-interface2] quit

# Create track entry 1 to monitor the upstream link status of VLAN-interface 3. When the upstream link fails, the track entry transits to Negative.

[SwitchA] track 1 interface vlan-interface 3

# Configure the VFs in VRRP group 1 to monitor track entry 1, and decrease their weights by 250 when the track entry transits to Negative.

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 weight reduced 250

2.     Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] vlan 2

[SwitchB-vlan2] port hundredgige 1/0/5

[SwitchB-vlan2] quit

# Configure VRRP to operate in load balancing mode.

[SwitchB] vrrp mode load-balance

# Create VRRP group 1, and set its virtual IP address to 10.1.1.1.

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ip address 10.1.1.3 24

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.1

# Assign Switch B a higher priority than Switch C in VRRP group 1, so Switch B can become the master when Switch A fails.

[SwitchB-Vlan-interface2] vrrp vrid 1 priority 110

# Configure Switch B to operate in preemptive mode, and set the preemption delay to 5000 centiseconds.

[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5000

[SwitchB-Vlan-interface2] quit

# Create track entry 1 to monitor the upstream link status of VLAN-interface 3. When the upstream link fails, the track entry transits to Negative.

[SwitchB] track 1 interface vlan-interface 3

# Configure the VFs in VRRP group 1 to monitor track entry 1, and decrease their weights by 250 when the track entry transits to Negative.

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] vrrp vrid 1 track 1 weight reduced 250

3.     Configure Switch C:

# Configure VLAN 2.

<SwitchC> system-view

[SwitchC] vlan 2

[SwitchC-vlan2] port hundredgige 1/0/5

[SwitchC-vlan2] quit

# Configure VRRP to operate in load balancing mode.

[SwitchC] vrrp mode load-balance

# Create VRRP group 1, and set its virtual IP address to 10.1.1.1.

[SwitchC] interface vlan-interface 2

[SwitchC-Vlan-interface2] ip address 10.1.1.4 24

[SwitchC-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.1

# Configure Switch C to operate in preemptive mode, and set the preemption delay to 5000 centiseconds.

[SwitchC-Vlan-interface2] vrrp vrid 1 preempt-mode delay 5000

[SwitchC-Vlan-interface2] quit

# Create track entry 1 to monitor the upstream link status of VLAN-interface 3. When the upstream link fails, the track entry transits to Negative.

[SwitchC] track 1 interface vlan-interface 3

# Configure the VFs in VRRP group 1 to monitor track entry 1, and decrease their weights by 250 when the track entry transits to Negative.

[SwitchC] interface vlan-interface 2

[SwitchC-Vlan-interface2] vrrp vrid 1 track 1 weight reduced 250

Verifying the configuration

# Verify that Host A can ping the external network. (Details not shown.)

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Virtual Router Information:

 Running Mode      : Load Balance

 Total number of virtual routers : 1

   Interface Vlan-interface2

     VRID           : 1                    Adver Timer  : 100

     Admin Status   : Up                   State        : Master

     Config Pri     : 120                  Running Pri  : 120

     Preempt Mode   : Yes                  Delay Time   : 5000

     Auth Type      : None

     Virtual IP     : 10.1.1.1

     Member IP List : 10.1.1.2 (Local, Master)

                      10.1.1.3 (Backup)

                      10.1.1.4 (Backup)

   Forwarder Information: 3 Forwarders 1 Active

     Config Weight  : 255

     Running Weight : 255

    Forwarder 01

     State          : Active

     Virtual MAC    : 000f-e2ff-0011 (Owner)

     Owner ID       : 0000-5e01-1101

     Priority       : 255

     Active         : local

    Forwarder 02

     State          : Listening

     Virtual MAC    : 000f-e2ff-0012 (Learnt)

     Owner ID       : 0000-5e01-1103

     Priority       : 127

     Active         : 10.1.1.3

    Forwarder 03

     State          : Listening

     Virtual MAC    : 000f-e2ff-0013 (Learnt)

     Owner ID       : 0000-5e01-1105

     Priority       : 127

     Active         : 10.1.1.4

   Forwarder Weight Track Information: