HP 10500 Switch Series network switches Configuration Guide

HP 10500 Switch Series network switches Configuration Guide
Add to My manuals

Below you will find brief information for network switches 10500 Switch Series. This document will guide you through the process of configuring high availability features on your HP 10500 Switch Series, enabling you to increase network reliability and minimize downtime. The guide covers various technologies like active and standby switchover, Ethernet OAM, CFD, DLDP, RRPP, Smart Link, Monitor Link, and VRRP, providing step-by-step instructions and configuration examples for implementing these features in your network.

advertisement

Assistant Bot

Need help? Our chatbot has already read the manual and is ready to assist you. Feel free to ask any questions about the device, but providing details will make the conversation more productive.

HP 10500 Switch Series Configuration Guide | Manualzz

HP 10500 Switch Series

High Availability

Configuration Guide

Part number: 5998-2215

Software version: Release 1201 and later

Document version: 6W102-20130530

Legal and notice information

© Copyright 2013 Hewlett-Packard Development Company, L.P.

No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P.

The information contained herein is subject to change without notice.

HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS

MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY

AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.

The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Contents

High availability overview ··········································································································································· 1

 

Availability requirements ·················································································································································· 1

Availability evaluation ······················································································································································ 1

High availability technologies ········································································································································· 2

Fault detection technologies ···································································································································· 2

Protection switchover technologies ························································································································· 3

 

 

 

 

 

Configuring active and standby switchover ··············································································································· 5

 

Configuration restrictions and guidelines ······················································································································· 5

Active and standby switchover configuration task list ·································································································· 5

Ignoring version check for the standby MPU ················································································································· 5

Restarting the standby MPU ············································································································································· 6

Manually performing an active and standby switchover ······························································································ 6

Displaying and maintaining active and standby switchover ························································································ 7

 

 

 

 

 

 

Configuring Ethernet OAM ········································································································································· 8

 

Overview ············································································································································································ 8

Major functions of Ethernet OAM ·························································································································· 8

Ethernet OAMPDUs ·················································································································································· 8

How Ethernet OAM works ······································································································································ 9

Protocols and standards ······································································································································· 11

Ethernet OAM configuration task list ··························································································································· 11

Configuring basic Ethernet OAM functions ················································································································· 11

Configuring the Ethernet OAM connection detection timers ····················································································· 12

Configuring link monitoring ·········································································································································· 12

Configuring errored symbol event detection ······································································································ 13

Configuring errored frame event detection ········································································································ 13

Configuring errored frame period event detection ···························································································· 13

Configuring errored frame seconds event detection ························································································· 14

Displaying and maintaining Ethernet OAM configuration ························································································ 14

Ethernet OAM configuration example ························································································································· 15

Network requirements ··········································································································································· 15

Configuration procedure ······································································································································ 15

Verifying the configuration ··································································································································· 15

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring CFD ························································································································································ 17

 

Overview ········································································································································································· 17

Basic CFD concepts ··············································································································································· 17

CFD functions ························································································································································· 20

Protocols and standards ······································································································································· 20

CFD configuration task list ············································································································································ 20

Configuring basic CFD settings ···································································································································· 21

Enabling CFD ························································································································································· 21

Configuring the CFD protocol version ················································································································· 21

Configuring service instances ······························································································································ 22

Configuring MEPs ·················································································································································· 23

Configuring MIP generation rules ························································································································ 23

Configuring CFD functions ············································································································································ 24

Configuration prerequisites ·································································································································· 24

Configuring CC on MEPs ····································································································································· 24

 

 

 

 

 

 

 

 

 

 

 

 

 

  i

Configuring LB on MEPs ······································································································································· 25

Configuring LT on MEPs ········································································································································ 25

Displaying and maintaining CFD ································································································································· 26

CFD configuration example ·········································································································································· 26

 

 

 

 

Configuring DLDP ······················································································································································· 31

 

How DLDP works ···························································································································································· 32

DLDP configuration task list ··········································································································································· 38

Configuring the duplex mode and speed of an Ethernet interface ··········································································· 38

Enabling DLDP ································································································································································ 38

Setting DLDP mode ························································································································································· 39

Setting the interval to send advertisement packets ····································································································· 39

Setting the DelayDown timer ········································································································································ 40

Setting the port shutdown mode ··································································································································· 40

Configuring DLDP authentication ·································································································································· 41

Resetting DLDP state ······················································································································································· 41

Displaying and maintaining DLDP ································································································································ 42

DLDP configuration examples ······································································································································· 42

Automatically shutting down unidirectional links ······························································································· 42

Manually shutting down unidirectional links ······································································································ 46

Troubleshooting DLDP ···················································································································································· 49

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring RRPP ······················································································································································· 50

 

Overview ········································································································································································· 50

Basic RRPP concepts ·············································································································································· 50

RRPPDUs ································································································································································· 52

RRPP timers ····························································································································································· 53

How RRPP works ···················································································································································· 53

Typical RRPP networking ······································································································································· 55

Protocols and standards ······································································································································· 58

RRPP configuration task list············································································································································ 59

Creating an RRPP domain ············································································································································· 59

Configuring control VLANs ··········································································································································· 60

Configuration guidelines ······································································································································ 60

Configuration procedure ······································································································································ 60

Configuring protected VLANs ······································································································································· 60

Configuring RRPP rings ·················································································································································· 61

Configuration guidelines ······································································································································ 61

Configuring RRPP ports ········································································································································· 62

Configuring RRPP nodes ······································································································································· 62

Activating an RRPP domain ··········································································································································· 64

Configuring RRPP timers ················································································································································ 64

Configuring RRPP fast detection ··································································································································· 65

Enabling fast detection ········································································································································· 65

Configuring fast detection timers ························································································································· 65

Configuring an RRPP ring group ·································································································································· 66

Configuration guidelines ······································································································································ 66

Configuration procedure ······································································································································ 66

Displaying and maintaining RRPP ································································································································ 66

RRPP configuration examples ········································································································································ 67

Single ring configuration example ······················································································································ 67

Intersecting ring configuration example ·············································································································· 69

Dual homed rings configuration example ·········································································································· 74

Load balanced intersecting-ring configuration example ··················································································· 84

Fast detection configuration example ················································································································· 93

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  ii

Troubleshooting ······························································································································································ 96

 

Configuring Smart Link ·············································································································································· 97

 

Overview ········································································································································································· 97

Terminology ··························································································································································· 98

How Smart Link works ·········································································································································· 99

Smart Link collaboration mechanisms ················································································································· 99

Smart Link configuration task list ································································································································ 100

Configuring a Smart Link device ································································································································ 100

Configuration prerequisites ································································································································ 100

Configuring protected VLANs for a smart link group ······················································································ 101

Configuring member ports for a smart link group ··························································································· 101

Configuring role preemption for a smart link group························································································ 102

Enabling the sending of flush messages ··········································································································· 102

Configuring the collaboration between Smart Link and CC of CFD ······························································ 103

Configuring an associated device ····························································································································· 103

Configuration prerequisites ································································································································ 103

Enabling the receiving of flush messages ········································································································· 103

Displaying and maintaining Smart Link ····················································································································· 104

Smart Link configuration examples ···························································································································· 104

Single smart link group configuration example ······························································································· 104

Multiple smart link groups load sharing configuration example ···································································· 109

Smart Link and CFD collaboration configuration example ············································································· 113

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring Monitor Link ········································································································································ 119

 

Overview ······································································································································································· 119

Terminology ························································································································································· 119

How Monitor Link works ····································································································································· 120

Configuring Monitor Link ············································································································································ 120

Configuration prerequisites ································································································································ 120

Creating a monitor link group ··························································································································· 120

Configuring monitor link group member ports ································································································· 120

Displaying and maintaining Monitor Link ················································································································· 121

Monitor Link configuration example ·························································································································· 121

 

 

 

 

 

 

 

 

 

Configuring VRRP ···················································································································································· 125

 

VRRP overview ······························································································································································ 125

VRRP standard mode ··················································································································································· 125

VRRP group ·························································································································································· 126

VRRP timers ·························································································································································· 127

Packet format ······················································································································································· 127

VRRP principles ···················································································································································· 129

VRRP tracking ······················································································································································· 129

VRRP application ················································································································································· 130

General configuration restrictions ······························································································································ 131

Configuring VRRP for IPv4 ··········································································································································· 131

VRRP for IPv4 configuration task list ·················································································································· 131

Specifying the type of MAC addresses mapped to virtual IP addresses ······················································· 132

Creating a VRRP group and configuring virtual IP addresses ········································································ 132

Configuring router priority, preemptive mode, and tracking function ··························································· 133

Configuring VRRP packet attributes ··················································································································· 134

Enabling the trap function for VRRP··················································································································· 135

Displaying and maintaining VRRP for IPv4 ······································································································· 136

Configuring VRRP for IPv6 ··········································································································································· 136

VRRP for IPv6 configuration task list ·················································································································· 136

Specifying the type of mapped MAC addresses ····························································································· 136

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  iii

Creating a VRRP group and configuring a virtual IPv6 address ···································································· 137

Configuring router priority, preemptive mode, and tracking function ··························································· 138

Configuring VRRP packet attributes ··················································································································· 139

Displaying and maintaining VRRP for IPv6 ······································································································· 140

IPv4 VRRP configuration examples ····························································································································· 140

Single VRRP group configuration example ······································································································· 140

VRRP interface tracking configuration example ······························································································· 143

VRRP with multiple VLANs configuration example ··························································································· 147

IPv6 VRRP configuration examples ····························································································································· 149

Single VRRP group configuration example ······································································································· 149

VRRP interface tracking configuration example ······························································································· 152

VRRP with multiple VLANs configuration example ··························································································· 156

Troubleshooting VRRP ·················································································································································· 159

The screen frequently displays error prompts ··································································································· 159

Multiple masters are present in a VRRP group ································································································· 160

Frequent VRRP state transition ···························································································································· 160

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring BFD ······················································································································································ 161

 

Overview ······································································································································································· 161

How BFD works ··················································································································································· 161

BFD packet format ··············································································································································· 163

Supported features ·············································································································································· 165

Protocols and standards ····································································································································· 165

Configuring BFD basic functions ································································································································ 165

Displaying and maintaining BFD ································································································································ 167

 

 

 

 

 

 

 

Configuring track ···················································································································································· 168

 

Track overview ····························································································································································· 168

Collaboration fundamentals ······························································································································· 168

Collaboration application example ··················································································································· 169

Track configuration task list ········································································································································· 169

Associating the track module with a detection module ··························································································· 170

Associating track with NQA ······························································································································ 170

Associating track with BFD ································································································································· 170

Associating track with interface management ································································································· 171

Associating the track module with an application module ······················································································ 172

Associating track with VRRP ······························································································································· 172

Associating track with static routing ·················································································································· 173

Associating track with PBR ································································································································· 174

Displaying and maintaining track entries ·················································································································· 175

Track configuration examples ····································································································································· 175

VRRP-track-NQA collaboration configuration example (the master monitors the uplink) ···························· 175

Configuring BFD for a VRRP backup to monitor the master (the master monitors the uplink) ····················· 179

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

Static routing-track-NQA collaboration configuration example ····································································· 185

Static routing-track-BFD collaboration configuration example ········································································ 190

VRRP-track-interface management collaboration configuration example (the master monitors the uplink interface)······························································································································································· 193

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Support and other resources ·································································································································· 197

 

Contacting HP ······························································································································································ 197

Subscription service ············································································································································ 197

Related information ······················································································································································ 197

Documents ···························································································································································· 197

Websites ······························································································································································· 197

Conventions ·································································································································································· 198

 

 

 

 

 

  iv

Index ········································································································································································ 200

  v

High availability overview

Because communication interruptions can seriously affect widely deployed value-added services, such as

IPTV and video conference, basic network infrastructures must be able to provide high availability.

The following are the effective ways to improve availability:

Increasing fault tolerance

Speeding up fault recovery

Reducing impact of faults on services

Availability requirements

Table 1

describes a typical availability model that divides availability requirements into different levels.

Table 1 Availability requirements

Level Requirements Solution

1

Decrease system software and hardware faults.

Hardware—Simplified circuit design, enhanced production techniques, and reliability tests.

Software—Reliability design and test.

2

Protect system functions from being affected by failures.

Device and link redundancy and switchover.

3

Enable the system to recover as fast as possible.

Fault detection, diagnosis, isolation, and recovery technologies.

Consider level 1 availability requirements during the design and production processes of network devices.

Consider level 2 availability requirements during network design.

Consider level 3 availability requirements during network deployment, according to the network infrastructure and service characteristics.

Availability evaluation

MTBF and MTTR are used to evaluate the availability of a network.

MTBF

MTBF is the predicted elapsed time between inherent failures of a system during operation. It is typically expressed in hours. A higher MTBF means a higher availability.

MTTR

MTTR is the average time required to repair a failed system. MTTR in a broad sense also involves spare parts management and customer services.

MTTR = fault detection time + hardware replacement time + system initialization time + link recovery time + routing time + forwarding recovery time. A smaller value of each item means a smaller MTTR and higher availability.

1

High availability technologies

Increasing MTBF or decreasing MTTR can enhance the availability of a network. The high availability technologies described in this section meet the level 2 and level 3 high-availability requirements in the aspect of decreasing MTTR.

High availability technologies can be classified as fault detection technologies or protection switchover technologies.

Fault detection technologies

Fault detection technologies enable detection and diagnosis of network faults.

CFD, DLDP, and Ethernet OAM are data link layer fault detection technologies.

BFD is a generic fault detection technology that can be used at any layer

NQA is used for diagnosis and evaluation of network quality.

Monitor Link and Track work along with other high availability technologies to detect faults through a collaboration mechanism.

Table 2 Fault detection technologies

Technology Introduction

CFD

CFD, which conforms to IEEE 802.1ag Connectivity Fault

Management, is an end-to-end per-VLAN link layer Operations,

Administration and Maintenance mechanism used for link connectivity detection, fault verification, and fault location.

DLDP

Ethernet OAM

BFD

The DLDP deals with unidirectional links that may occur in a network.

When detecting a unidirectional link, DLDP, as configured, can shut down the related port automatically or prompt users to take actions to avoid network problems.

As a tool monitoring Layer 2 link status, Ethernet OAM is mainly used to address common link-related issues on the last mile. You can monitor the status of the point-to-point link between two directly-connected devices by enabling Ethernet OAM on the two devices.

BFD provides a single mechanism to quickly detect and monitor the connectivity of links or IP forwarding in networks. Devices must quickly detect communication failures to restore communication through backup paths as soon as possible to improve network performance.

NQA

Monitor Link

Reference

"

Configuring CFD

"

"

Configuring

DLDP "

"

Configuring

Ethernet OAM

"

"

Configuring BFD

"

NQA analyzes network performance, services, and service quality through sending test packets, and provides network performance and service quality parameters, such as jitter, TCP connection delay, FTP connection delay, and file transfer rate.

Network

Management and

Monitoring

Configuration

Guide

Monitor Link works together with Layer 2 topology protocols to adapt the up/down state of a downlink port to the state of an uplink port. This feature enables fast link switchover on a downstream device in response to the uplink state change on its upstream device.

"

Configuring

Monitor Link

"

2

Technology Introduction

Track

The track module implements collaboration between different modules. The collaboration involves three sets of modules: application, track, and detection. These modules collaborate with one another through collaboration entries. The detection modules trigger the application modules to perform certain operations through the track module. The detection modules probe such items as link status and network performance, and inform the application modules of the detection result through the track module. Once notified of network status changes, the application modules use the changes to avoid communication interruption and network performance degradation.

Reference

"

Configuring track "

Protection switchover technologies

Protection switchover technologies aim at recovering network faults. They back up hardware, link, routing, and service information for switchover in case of network faults to ensure continuity of network services.

A single availability technology cannot solve all problems. You should use a combination of availability technologies, chosen on the basis of detailed analysis of network environments and user requirements, to enhance network availability. For example, access-layer devices should be connected to distribution-layer devices over redundant links, and core-layer devices should be fully meshed. Network availability should be considered during the planning stage.

Table 3 Protection switchover technologies

Technology Introduction

Active and standby switchover

Devices supporting active and standby switchover are normally equipped with two MPUs, with one being the active MPU, and the other being the standby MPU. The configurations on the standby

MPU are the same as those on the active MPU. When the active

MPU fails or is removed, the standby MPU automatically becomes the active MPU to ensure non-stop operating of the devices.

Ethernet link aggregation

Smart Link

Ethernet link aggregation, or link aggregation, aggregates multiple physical Ethernet links into one logical link to increase link bandwidth beyond the limits of any one single link. This logical link is an aggregate link. It allows for link redundancy because the member physical links can dynamically back up one another.

Smart Link addresses the slow convergence issue with the spanning tree protocol. It provides link redundancy as well as fast convergence in a dual uplink network, allowing the backup link to quickly take over when the primary link fails.

MSTP

RRPP

As a Layer 2 management protocol, the MSTP eliminates Layer 2 loops by selectively blocking redundant links in a network, and in the meantime, allows for link redundancy.

The RRPP is a link layer protocol designed for Ethernet rings. RRPP can prevent broadcast storms caused by data loops when an

Ethernet ring is healthy, and rapidly restore the communication paths between the nodes in the event that a link is disconnected on the ring.

Reference

" Configuring active and standby switchover

"

Layer 2—LAN

Switching

Configuration Guide

" Configuring Smart

Link

"

Layer 2—LAN

Switching

Configuration Guide

" Configuring RRPP "

3

Technology Introduction

FRR

GR

NSR

VRRP

FRR provides a quick per-link or per-node protection on an LSP.

Once a link or node fails on a path, FRR reroutes the path to a new link or node to bypass the failed link or node. This can happen as fast as 50 milliseconds minimizing data loss. Protocols such as RIP,

OSPF, IS-IS, static routing, and RSVP-TE support this technology.

GR ensures the continuity of packet forwarding when a protocol, such as BGP, IS-IS, OSPF, IPv6 BGP, IPv6 IS-IS, OSPFv3, LDP, or

RSVP-TE, restarts, or during an active/standby switchover process.

It needs other devices to implement routing information backup and recovery.

NSR ensures non-stop data transmission during an active/standby switchover by backing up IP forwarding information from the active

MPU to the standby MPU. Upon an active/standby switchover,

NSR can complete link state recovery and route re-generation without requiring the cooperation of other devices. OSPF supports this feature.

VRRP is an error-tolerant protocol, which provides highly reliable default links on multicast and broadcast LANs such as Ethernet, avoiding network interruption due to failure of a single link.

Reference

Layer 3—IP Routing

Configuration Guide,

MPLS Configuration

Guide, and configuration guide of the corresponding protocols

Related chapters in

Layer 3—IP Routing

Configuration Guide and MPLS

Configuration Guide

Layer 3—IP Routing

Configuration Guide

" Configuring VRRP "

4

Configuring active and standby switchover

The switch supports configuring two MPUs. The system uses the MPU with a smaller slot number as the active

MPU, and the other MPU as the standby MPU. The standby MPU keeps its configuration the same as the active MPU through the synchronization function. When the active MPU fails, the standby MPU becomes the active MPU to process services to ensure normal operation of the device. This switchover process is called an active and standby switchover.

Active and standby switchover functions in the following ways:

Automatic active and standby switchover—If the active MPU fails or is removed, the system automatically performs an active and standby switchover to enable the standby MPU to function as the active MPU.

Manual active and standby switchover—An active and standby switchover performed at the CLI.

Configuration restrictions and guidelines

All commands except the display switchover state command take effect only when the switch is operating in standalone mode. For more information about IRF, see IRF Configuration Guide.

Active/standby switchover configuration tasks must be performed at the CLI of the active MPU. The system can automatically propagate the configuration to the standby MPU.

When you upgrade the switch, make sure the software versions of the active and standby MPUs are the same, and reboot the switch after upgrade.

Active and standby switchover configuration task list

Task Remarks

Ignoring version check for the standby MPU

Optional.

Restarting the standby MPU

Manually performing an active and standby switchover

Optional.

Optional.

Ignoring version check for the standby MPU

To ensure normal device operation, HP recommends running the same software version on the active MPU and the standby MPU.

When the standby MPU attempts to start up, by default the system examines its software version against the active MPU's software version for inconsistency. If the versions of the active MPU and standby MPU are not consistent, the standby MPU cannot be started.

To disable the system from examining the standby MPU's software version:

Step Command

1. Enter system view.

Remarks system-view N/A

5

Step Command

2. Ignore version check for the standby MPU. ha slave-ignore-version-check

Remarks

By default, version check is enabled for the standby MPU.

NOTE:

If the software differences between the active and standby MPUs could possibly affect the normal operation of the device, the system will prevent the standby MPU from starting up, even if software version check has been disabled.

Restarting the standby MPU

You can manually restart the standby MPU. Before restarting, check the consistency of the versions of the active MPU and standby MPU. If they are not consistent, configure the system to ignore version check of the standby MPU.

After the standby MPU is restarted, the active MPU will perform initial synchronization on the standby MPU.

During this process, the system will not respond to your input. After the initial synchronization is completed, you can execute all configuration commands on the active MPU. The active MPU and standby MPU will keep a real-time synchronization process. Your configuration on the active MPU will be copied to the standby MPU to ensure the consistency of the current configuration of the active MPU and standby MPU.

To restart the standby MPU:

Step Command

1. Enter system view. system-view

2. Manually restart the standby MPU. slave restart

Manually performing an active and standby switchover

To avoid service interruption when you upgrade the active MPU, perform a manual active and standby switchover.

Before the switchover, verify that the standby MPU is running the same software version as the active MPU or software version check is disabled for the standby MPU.

To manually perform an active and standby switchover:

Step Command

1. Enter system view. system-view

2. Enable manual active and standby switchover. slave switchover { disable | enable }

Remarks

N/A

Optional.

By default, manual active and standby switchover is enabled.

3. Manually perform an active and standby switchover. slave switchover N/A

6

Displaying and maintaining active and standby switchover

Remarks Task Command

Display the switchover state of

MPUs (in standalone mode). display switchover state [ slot

slot-number ] [ | { begin | exclude

| include } regular-expression ]

Display the switchover state of

MPUs (in IRF mode). display switchover state [ chassis

chassis-number slot

slot-number ] [ | { begin | exclude

| include } regular-expression ]

Available in any view.

Available in any view.

7

Configuring Ethernet OAM

This chapter describes how to configure Ethernet OAM.

Overview

As a tool that monitors Layer 2 link status, Ethernet OAM addresses common link-related issues on the last mile. Ethernet OAM improves Ethernet management and maintainability. You can use it to monitor the status of the point-to-point link between two directly connected devices.

Major functions of Ethernet OAM

Ethernet OAM provides the following functions:

Link performance monitoring—Monitors the performance indices of a link, including packet loss, delay, and jitter, and collects traffic statistics of various types.

Fault detection and alarm—Examines the connectivity of a link by sending OAMPDUs and reports to the network administrators when a link error occurs.

Remote loopback—Examines link quality and locates link errors by looping back OAMPDUs.

Ethernet OAMPDUs

Ethernet OAM operates on the data link layer. Ethernet OAM reports the link status by periodically exchanging OAMPDUs between devices so the administrator can effectively manage the network.

Throughout this document, an Ethernet OAM-enabled port is referred to as an Ethernet OAM entity or an

OAM entity.

Ethernet OAMPDUs include the following types: Information, Event Notification, and Loopback Control,

as shown in Figure 1 .

Figure 1 Formats of different types of Ethernet OAMPDUs

Table 4 OAMPDU fields

Field Description

Dest addr

Destination MAC address of the Ethernet OAMPDU.

It is a slow protocol multicast address 0180c2000002. Bridges cannot forward slow protocol packets, so Ethernet OAMPDUs cannot be forwarded.

8

Field Description

Source addr

Source MAC address of the Ethernet OAMPDU.

It is the bridge MAC address of the sending side and is a unicast MAC address.

Type

Subtype

Type of the encapsulated protocol in the Ethernet OAMPDU.

The value is 0x8809.

Protocol being encapsulated in the Ethernet OAMPDU.

The value is 0x03.

Status information of an Ethernet OAM entity. Flags

Code Type of the Ethernet OAMPDU.

Table 5 Functions of different types of OAMPDUs

OAMPDU type Function

Information OAMPDU

Transmits state information of an Ethernet OAM entity (including the information about the local device and remote devices, and customized information) to the remote Ethernet OAM entity. Also, maintains OAM connections.

Event Notification

OAMPDU

Loopback Control

OAMPDU

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

Used for remote loopback control. By inserting the information used to enable/disable loopback to a loopback control OAMPDU, you can enable/disable loopback on a remote OAM entity.

How Ethernet OAM works

This section describes the working procedures of Ethernet OAM.

Establishing an Ethernet OAM connection

Ethernet OAM connection is the base of all of the other Ethernet OAM functions. Establishing the OAM connection is also known as the "Discovery phase," where an Ethernet OAM entity discovers the remote

OAM entity to establish a session.

In this phase, two connected OAM entities exchange Information OAMPDUs to advertise their OAM configuration and capabilities to each other for a comparison. If their Loopback, link detection, and link event settings match, the OAM entities establish an OAM connection.

An OAM entity operates in active mode or passive mode. OAM entities in active mode initiate OAM connections, and OAM entities in passive mode wait and respond to the OAM connection requests.

IMPORTANT:

To set up an OAM connection between two OAM entities, set at least one entity to operate in active mode.

Table 6

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

Table 6 Active Ethernet OAM mode and passive Ethernet OAM mode actions

Item

Initiating OAM Discovery

Active Ethernet OAM mode

Available

Passive Ethernet OAM mode

Unavailable

9

Item

Responding to OAM Discovery

Transmitting Information

OAMPDUs

Transmitting Event Notification

OAMPDUs

Transmitting Information

OAMPDUs without any TLV

Transmitting Loopback Control

OAMPDUs

Active Ethernet OAM mode

Available

Passive Ethernet OAM mode

Available

Available Available

Available Available

Available Available

Available Unavailable

Responding to Loopback Control

OAMPDUs

Available when both sides are operating in active OAM mode

Available

After an Ethernet OAM connection is established, the Ethernet OAM entities exchange Information

OAMPDUs at the handshake packet transmission interval to detect the availability of the Ethernet OAM connection. If an Ethernet OAM entity does not receive any Information OAMPDU within the Ethernet

OAM connection timeout time, the Ethernet OAM connection is considered disconnected.

Link monitoring

Error detection in an Ethernet is difficult, especially when the physical connection in the network is not disconnected, but network performance is degrading gradually.

Link monitoring detects link faults in various environments. Ethernet OAM entities monitor link status by exchanging Event Notification OAMPDUs. When detecting a link error event listed in

Table 7 , 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.

The system transforms the period of detecting errored frame period events into the maximum number of

64-byte frames (excluding interframe spacing and preamble) that a port can send in the specified period.

The system takes the maximum number of frames sent as the period. The maximum number of frames sent is calculated using this formula:

Maximum number of frames = Interface bandwidth (bps) × errored frame period event detection period

(in ms)/(64 × 8 × 1000)

If errored frames appear in a certain second, that second is an errored frame second.

Table 7 Ethernet OAM link error events

Ethernet OAM link events

Errored symbol event

Errored frame event

Errored frame period event

Errored frame seconds event

Description

Number of detected symbol errors over a specific detection interval has exceeded the configured threshold.

Number of detected error frames over a specific interval has exceeded the configured threshold.

Number of frame errors in a specified number of received frames has exceeded the configured threshold.

Number of error frame seconds detected on a port over a specific detection interval has reached the error threshold.

10

Remote fault detection

Information OAMPDUs are exchanged periodically among Ethernet OAM entities across established

OAM connections. On a network where traffic is interrupted due to device failures or unavailability, the flag field defined in Information OAMPDUs allows an Ethernet OAM entity to send error information to its peer. (This can include any critical link event type shown in

Table 8

.) In this way, you can keep track of link status through the log information and troubleshoot in a timely fashion.

The switch is able to receive Information OAMPDUs carrying the critical link events listed in Table

8 .

The switch does not support the sending of Information OAMPDUs carrying Link Fault events.

The switch is able to send Information OAMPDUs carrying Dying Gasp events when the device is rebooted or relevant ports are manually shut down. Physical IRF ports, however, are unable to send this type of OAMPDUs. For more information about physical IRF ports, see IRF Configuration Guide.

This Switch Series is unable to send Information OAMPDUs carrying Critical Events.

Table 8 Critical link events

Type Description

Link Fault Peer link signal is lost.

Dying Gasp

Critical Event

An unexpected fault, such as power failure, occurred.

An undetermined critical event happened.

OAMPDU transmission frequencies

Once per second.

Non-stop.

Non-stop.

Protocols and standards

Ethernet OAM is defined in IEEE 802.3ah (CSMA/CD) Access Method and Physical Layer

Specifications.

Ethernet OAM configuration task list

Task

Configuring basic Ethernet OAM functions

Configuring the Ethernet OAM connection detection timers

Configuring link monitoring

Configuring errored symbol event detection

Configuring errored frame event detection

Configuring errored frame period event detection

Configuring errored frame seconds event detection

Remarks

Required.

Optional.

Optional.

Optional.

Optional.

Optional.

Configuring basic Ethernet OAM functions

To set up an Ethernet OAM connection between two Ethernet OAM entities, you must set at least one entity to operate in active mode. Only in active mode can an Ethernet OAM entity initiate OAM connection. To change the Ethernet OAM mode on an Ethernet OAM-enabled port, first disable Ethernet

OAM on the port.

11

To configure basic Ethernet OAM functions:

Step Command

1. Enter system view. system-view

2. Enter Layer 2 Ethernet interface view. interface interface-type

interface-number

Remarks

N/A

N/A

3. Set the Ethernet OAM mode. oam mode { active | passive }

4. Enable Ethernet OAM on the current port. oam enable

Optional.

The default is active Ethernet OAM mode.

By default, Ethernet OAM is disabled.

Configuring the Ethernet OAM connection detection timers

CAUTION:

After the timeout timer of an Ethernet OAM connection expires, the local OAM entity ages out its connection with the peer OAM entity, causing the OAM connection to disconnect. HP recommends setting the connection timeout timer at least five times the handshake packet transmission interval to ensure the stability of Ethernet OAM connections.

After an Ethernet OAM connection is established, the Ethernet OAM entities exchange Information

OAMPDUs at the handshake packet transmission interval to detect the availability of the Ethernet OAM connection. If an Ethernet OAM entity receives no Information OAMPDU within the Ethernet OAM connection timeout time, the Ethernet OAM connection is considered disconnected.

By adjusting the handshake packet transmission interval and the connection timeout timer, you can change the detection time resolution for Ethernet OAM connections.

To configure the Ethernet OAM connection detection timers:

Step Command

1. Enter system view. system-view

2. Configure the Ethernet OAM handshake packet transmission interval. oam timer hello interval

3. Configure the Ethernet OAM connection timeout timer. oam timer keepalive interval

Remarks

N/A

Optional.

The default is 1000 milliseconds.

Optional.

The default is 5000 milliseconds.

Configuring link monitoring

After Ethernet OAM connections are established, the link monitoring periods and thresholds configured in this section automatically take effect on all Ethernet ports.

12

Configuring errored symbol event detection

An errored symbol event occurs when the number of detected symbol errors over a specific detection interval exceeds the configured threshold.

To configure errored symbol event detection:

Step Command

1. Enter system view. system-view

2. Configure the errored symbol event detection interval. oam errored-symbol period

period-value

3. Configure the errored symbol event triggering threshold. oam errored-symbol threshold

threshold-value

Remarks

N/A

Optional.

The default is 1 second.

Optional.

The default is 1.

Configuring errored frame event detection

An errored frame event occurs when the number of detected error frames over a specific interval exceeds the configured threshold.

To configure errored frame event detection:

Remarks

N/A

Step Command

1. Enter system view. system-view

2. Configure the errored frame event detection interval. oam errored-frame period period-value

3. Configure the errored frame event triggering threshold. oam errored-frame threshold

threshold-value

Optional.

The default is 1 second.

Optional.

The default is 1.

Configuring errored frame period event detection

An errored frame period event occurs if the number of frame errors in a specific number of received frames exceeds the configured threshold.

To configure errored frame period event detection:

Step Command

1. Enter system view. system-view

2. Configure the errored frame period event detection period. oam errored-frame-period period

period-value

3. Configure the errored frame period event triggering threshold.

oam errored-frame-period threshold threshold-value

Remarks

N/A

Optional.

The default is 1000.

Optional.

The default is 1.

13

Configuring errored frame seconds event detection

An errored frame seconds event occurs when the number of error frame seconds detected on a port over a detection interval exceeds the error threshold. Make sure the errored frame seconds triggering threshold is less than the errored frame seconds detection interval. Otherwise, no errored frame seconds event can be generated.

To configure errored frame seconds event detection:

Remarks

N/A

Step Command

1. Enter system view. system-view

2. Configure the errored frame seconds event detection interval. oam errored-frame-seconds period

period-value

3. Configure the errored frame seconds event triggering threshold. oam errored-frame-seconds threshold threshold-value

Optional.

The default is 60 seconds.

Optional.

The default is 1.

Displaying and maintaining Ethernet OAM configuration

Task Command

Display global Ethernet OAM configuration. display oam configuration [ |

{ begin | exclude | include }

regular-expression ]

Display the statistics on critical events after an Ethernet OAM connection is established. display oam critical-event

[ interface interface-type

interface-number ] [ | { begin | exclude | include }

regular-expression ]

Display the statistics on Ethernet

OAM link error events after an

Ethernet OAM connection is established.

Display information about an

Ethernet OAM connection. display oam link-event { local | remote } [ interface interface-type

interface-number ] [ | { begin | exclude | include }

regular-expression ] display oam { local | remote }

[ interface interface-type

interface-number ] [ | { begin | exclude | include }

regular-expression ]

Clear statistics on Ethernet OAM packets and Ethernet OAM link error events. reset oam [ interface interface-type

interface-number ]

Remarks

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in user view.

14

Ethernet OAM configuration example

Network requirements

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

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

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

Figure 2 Network diagram

Configuration procedure

1. Configure Device A:

# Configure GigabitEthernet 1/0/1 to operate in passive Ethernet OAM mode and enable

Ethernet OAM for it.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] oam mode passive

[DeviceA-GigabitEthernet1/0/1] oam enable

[DeviceA-GigabitEthernet1/0/1] quit

# Set the errored frame detection interval to 20 seconds and set the errored frame event triggering threshold to 10.

[DeviceA] oam errored-frame period 20

[DeviceA] oam errored-frame threshold 10

2. On Device B, configure GigabitEthernet 1/0/1 to operate in active Ethernet OAM mode (the default) and enable Ethernet OAM for it.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

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

[DeviceB-GigabitEthernet1/0/1] oam enable

[DeviceB-GigabitEthernet1/0/1] quit

Verifying the configuration

Use the display oam configuration command to display the Ethernet OAM configuration. For example:

# Display the Ethernet OAM configuration on Device A.

[DeviceA] display oam configuration

Configuration of the link event window/threshold :

--------------------------------------------------------------------------

Errored-symbol Event period(in seconds) : 1

Errored-symbol Event threshold : 1

Errored-frame Event period(in seconds) : 20

15

Errored-frame Event threshold : 10

Errored-frame-period Event period(in ms) : 1000

Errored-frame-period Event threshold : 1

Errored-frame-seconds Event period(in seconds) : 60

Errored-frame-seconds Event threshold : 1

Configuration of the timer :

--------------------------------------------------------------------------

Hello timer(in ms) : 1000

Keepalive timer(in ms) : 5000

The output shows that the detection period of errored frame events is 20 seconds, the detection threshold is 10 seconds, and all other parameters use the default values.

You can use the display oam critical-event command to display the statistics of Ethernet OAM critical link events. For example:

# Display the statistics of Ethernet OAM critical link events on all ports of Device A.

[DeviceA] display oam critical-event

Port : GigabitEthernet1/0/1

Link Status : Up

Event statistic :

-------------------------------------------------------------------------

Link Fault :0 Dying Gasp : 0 Critical Event : 0

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

You can use the display oam link-event command to display the statistics of Ethernet OAM link error events. For example:

# Display Ethernet OAM link event statistics of the remote end of Device B.

[DeviceB] display oam link-event remote

Port :GigabitEthernet1/0/1

Link Status :Up

OAMRemoteErrFrameEvent : (ms = milliseconds)

---------------------------------------------------------------------

Event Time Stamp : 5789 Errored FrameWindow : 200(100ms)

Errored Frame Threshold : 10 Errored Frame : 13

Error Running Total : 350 Event Running Total : 17

The output shows that 350 errors occurred after Ethernet OAM was enabled on Device A, 17 of which were caused by error frames. The link is unstable.

16

Configuring CFD

This chapter describes how to configure CFD.

Overview

CFD is an end-to-end per-VLAN link layer OAM mechanism used for link connectivity detection, fault verification, and fault location. It conforms to IEEE 802.1ag CFM.

Basic CFD concepts

This section explains the concepts of CFD.

MD

A MD defines the network or part of the network where CFD plays its role. An MD is identified by its MD name.

To accurately locate faults, CFD assigns eight levels ranging from 0 to 7 to MDs. The bigger the number, the higher the level, and the larger the area covered. If the outer domain has a higher level than the nested one, domains can touch or nest, but they cannot intersect or overlap.

MD levels facilitate fault location and its accuracy. As shown in

Figure 3

, MD_A in light blue nests MD_B in dark blue. If a connectivity fault is detected at the boundary of MD_A, any of the devices in MD_A, including Device A through Device E, may fail. If a connectivity fault is also detected at the boundary of

MD_B, the failure points may be any of Device B through Device D. If the devices in MD_B can operate properly, at least Device C is operational.

Figure 3 Two nested MDs

CFD exchanges messages and performs operations on a per-domain basis. By planning MDs properly in a network, you can use CFD to rapidly locate failure points.

17

MA

A MA is a part of an MD. You can configure multiple MAs in an MD as needed. An MA is identified by the "MD name + MA name".

An MA serves a VLAN. Packets sent by the MPs in an MA carry the relevant VLAN tag. An MP can receive packets sent by other MPs in the same MA. The level of an MA equals the level of the MD that the

MA belongs to.

MP

An MP is configured on a port and belongs to an MA. MPs include MEPs and MIPs.

MEPs

MEPs define the boundary of the MA. Each MEP is identified by a MEP ID.

The MA to which a MEP belongs defines the VLAN of packets sent by the MEP. The level of a MEP is equal to the level of the MD to which the MEP belongs, and the level of packets sent by a MEP equals the level of the MEP. The level of a MEP determines the levels of packets that the MEP can process. A MEP forwards packets at a higher level and processes packets of its own level or lower.

The processing procedure is specific to packets in the same VLAN. Packets of different VLANs are independent.

MEPs are either inward-facing or outward-facing. An outward-facing MEP sends packets to its host port. An inward-facing MEP does not send packets to its host port. Rather, it sends packets to other ports on the device.

MIP

A MIP is internal to an MA. It cannot send CFD packets actively. However, a MIP can handle and respond to CFD packets. By cooperating with MEPs, a MIP can perform a function similar to ping and traceroute. A MIP forwards packets of a different level without any processing and only processes packet of its own level.

The MA to which a MIP belongs defines the VLAN of packets that the MEP can receive. The level of a MIP is defined by its generation rule and the MD that the MIP belongs to. MIPs are generated on each port automatically according to related MIP generation rules. If a port has no MIP, the system will examine the MAs in each MD (from low to high levels), and follow the procedure as

described in Figure 4

to determine whether to create MIPs at the relevant level.

18

Figure 4 Procedure of creating MIPs

Figure 5

demonstrates a grading example of the CFD module. Four levels of MDs (0, 2, 3, and 5) are designed. The bigger the number, the higher the level, and the larger the area covered. MPs are configured on the ports of device A through device F. Port 1 of device B is configured with the following

MPs—a level 5 MIP, a level 3 inward-facing MEP, a level 2 inward-facing MEP, and a level 0 outward-facing MEP.

Figure 5 CFD grading example

MEP list

A MEP list is a collection of configurable local MEPs and the remote MEPs to be monitored in the same

MA. It lists all MEPs configured on different devices in the same MA. The MEPs all have unique MEP IDs.

19

When a MEP receives from a remote device a CCM with a MEP ID not included in the MEP list of the MA, it drops the message.

CFD functions

CFD works effectively only in properly configured networks. Its functions, which are implemented through the MPs, include:

Continuity check (CC)

Loopback (LB)

Linktrace (LT)

CC

Connectivity faults are usually caused by device faults or configuration errors. CC examines the connectivity between MEPs. This function is implemented through periodic sending of CCMs by the MEPs.

A CCM sent by one MEP is intended to be received by all of the other MEPs in the same MA. If a MEP fails to receive the CCMs within 3.5 times the sending interval, the link is considered faulty and a log is generated. When multiple MEPs send CCMs at the same time, the multipoint-to-multipoint link check is achieved. CCM frames are multicast frames.

LB

Similar to ping at the IP layer, LB verifies the connectivity between a source device and a target device.

To implement this function, the source MEP sends LBMs to the target MEP. Depending on whether the source MEP can receive a LBR from the target MEP, the link state between the two can be verified. LBM frames and LBR frames are unicast frames.

LT

LT is similar to traceroute. It identifies the path between the source MEP and the target MP. This function is implemented in the following way—the source MEP sends the LTMs to the target MP. After receiving the messages, the target MP and the MIPs that the LTM frames pass send back LTRs to the source MEP. Based on the reply messages, the source MEP can identify the path to the target MP. LTM frames are multicast frames and LTRs are unicast frames.

Protocols and standards

IEEE 802.1ag, Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault

Management

CFD configuration task list

For CFD to operate properly, design the network by performing the following tasks:

Grade the MDs in the entire network and define the boundary of each MD.

Assign a name for each MD. Make sure the same MD has the same name on different devices.

Define the MA in each MD according to the VLAN you want to monitor.

Assign a name for each MA. Make sure the same MA in the same MD has the same name on different devices.

Determine the MEP list of each MA in each MD. Make sure devices in the same MA maintain the same MEP list.

20

At the edges of MD and MA, MEPs should be designed at the device port. MIPs can be designed on devices or ports that are not at the edges.

Tasks Remarks

Enabling CFD

Required.

Optional.

Configuring basic CFD settings

Configuring the CFD protocol version

Configuring service instances

Creating a service instance with the MD name

Creating a service instance without the MD name

Configuring MEPs

Configuring MIP generation rules

Required.

Perform either task.

Required.

Required.

Configuring CC on MEPs

Required.

Configuring CFD functions

Configuring LB on MEPs

Optional.

Configuring LT on MEPs

Optional.

Typically, a port blocked by the spanning tree feature cannot receive or send CFD messages except in the following cases:

The port is configured as an outward-facing MEP.

The port is configured as a MIP or an inward-facing MEP that can still receive and send CFD messages except CCM messages.

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

Configuring basic CFD settings

This section provides procedures for configuring basic CFD settings.

Enabling CFD

Enable CFD before you perform other configuration tasks.

To enable CFD on a device:

Step Command

1. Enter system view. system-view

2. Enable CFD. cfd enable

Remarks

N/A

By default, CFD is disabled.

Configuring the CFD protocol version

Three CFD protocol versions are available: IEEE 802.1ag draft5.2 version, IEEE 802.1ag draft5.2 interim version, and IEEE 802.1ag standard version. This Switch Series supports only the standard version of

IEEE 802.1ag.

Devices in the same MD must use the same CFD protocol version. Otherwise, they cannot exchange CFD protocol packets.

21

If an MD is created by using the cfd md command or automatically generated by using the cfd service-instance maid format command on a device, you cannot switch between the standard version and draft5.2 version (or draft5.2 interim version). However, you can switch between the draft5.2 version and draft5.2 interim version. This restriction does not apply to the device without an MD configured.

To configure the CFD protocol version:

Step Command

1. Enter system view. system-view

2. Configure the CFD protocol version. cfd version { draft5 | draft5-plus | standard }

Remarks

N/A

Optional.

By default, CFD uses the standard version of IEEE 802.1ag.

Configuring service instances

Before configuring the MEPs and MIPs, first configure service instances. A service instance is a set of SAPs, and belongs to an MA in an MD.

A service instance is indicated by an integer to represent an MA in an MD. The MD and MA define the level and VLAN attribute of the messages handled by the MPs in a service instance.

Service instances fall into two types:

Service instance with the MD name, which takes effect in any version of CFD.

Service instance without the MD name, which takes effect in only CFD IEEE 802.1ag.

You can create either type of service instance as needed.

Creating a service instance with the MD name

To create a service instance with the MD name, create the MD and MA for the service instance first.

To configure a service instance with the MD name:

Step Command

1. Enter system view. system-view

2. Create an MD.

Remarks

N/A cfd md md-name level level-value By default, no MD is created.

3. Create an MA.

4. Create a service instance with the MD name cfd ma ma-name md md-name vlan

vlan-id cfd service-instance instance-id md

md-name ma ma-name

By default, no MA is created.

By default, no service instance with the MD name is created.

Creating a service instance without the MD name

When you create a service instance without the MD name, the system automatically creates the MA and

MD for the service instance.

To create a service instance without the MD name:

Step Command

1. Enter system view. system-view

Remarks

N/A

22

Step Command

2. Create a service instance without the MD name. cfd service-instance instance-id maid format { icc-based ma-name | string

ma-name } level level-value vlan vlan-id

Remarks

By default, no service instance without the MD name is created.

Configuring MEPs

CFD is implemented through various operations on MEPs. A MEP is configured on a service instance, so the MD level and VLAN attribute of the service instance become the attribute of the MEP.

Before creating MEPs, configure the MEP list. A MEP list is a collection of local configurable MEPs in an

MA and the remote MEPs to be monitored.

To configure a MEP:

Step Command

1. Enter system view. system-view

2. Configure a MEP list.

3. Enter Layer 2 Ethernet interface view.

4. Create a MEP.

5. Enable the MEP.

Remarks

N/A cfd meplist mep-list service-instance instance-id

By default, no MEP list is configured.

To create a MEP, the MEP ID must be included in the MEP list of the service instance. interface interface-type

interface-number

N/A cfd mep mep-id service-instance

instance-id { inbound | outbound } By default, no MEP is created. cfd mep service-instance

instance-id mep mep-id enable

By default, the MEP is disabled.

Configuring MIP generation rules

As functional entities in a service instance, MIPs respond to various CFD frames, such as LTM frames, LBM frames, 1DM frames, DMM frames, and TST frames. You can choose appropriate MIP generation rules based on your network design.

Any of the following actions or cases can cause MIPs to be created or deleted after you configure the cfd mip-rule command:

Enabling or disabling CFD.

Creating or deleting the MEPs on a port.

Changes occur to the VLAN attribute of a port.

The rule specified in the cfd mip-rule command changes.

To configure the rules for generating MIPs:

Step Command

1. Enter system view. system-view

Remarks

N/A

23

Step Command

2. Configure the rules for generating MIPs. cfd mip-rule { default | explicit } service-instance instance-id

Configuring CFD functions

This section provides information about configuring CFD functions.

Remarks

By default, neither MIPs nor the rules for generating MIPs are configured.

Configuration prerequisites

Complete basic CFD settings.

Configuring CC on MEPs

This section describes how to configure CC on MEPs.

Configuration guidelines

Configure CC before you configure other CFD functions. After the CC function is configured, MEPs can send CCM frames to each other to examine the connectivity between them.

Configure the same interval field value in CCM messages sent by the MEPs belonging to the same

MA.

Table 9 Relationship between the interval field value in the CCM message, the interval between CCM messages, and the timeout time of the remote MEP

4

5

The interval field value in the CCM message

3

The interval between CCM messages

100 milliseconds

1 second

10 second

6

7

Configuration procedure

To configure CC on a MEP:

60 seconds

600 seconds

Step Command

1. Enter system view. system-view

2. Configure the interval field value in the CCM messages sent by MEPs. cfd cc interval interval-value service-instance instance-id

3. Enter Layer 2 Ethernet interface view. interface interface-type

interface-number

The timeout time of the remote MEP

350 milliseconds

3.5 seconds

35 seconds

210 seconds

2100 seconds

Remarks

N/A

Optional.

By default, the interval field value is 4.

N/A

24

Step Command

4. Enable CCM sending on a

MEP. cfd cc service-instance

instance-id mep mep-id enable

Remarks

By default, CCM sending on a MEP is disabled.

Configuring LB on MEPs

The LB function can verify the link state between the local MEP and the remote MEP or MIP.

To configure LB on a MEP:

Remarks Task Command

Enable LB. cfd loopback service-instance

instance-id mep mep-id

{ target-mep target-mep-id | target-mac mac-address } [ number

number ]

By default, LB is disabled.

Available in any view.

Configuring LT on MEPs

LT can trace the path between the source and target MEPs, and can also locate link faults by sending LT messages automatically. The two functions are implemented in the following way:

To implement the first function, the source MEP first sends LTM messages to the target MEP. Based on the LTR messages in response to the LTM messages, the path between the two MEPs can be identified.

In the latter case, after LT messages automatic sending is enabled, if the source MEP fails to receive the CCM frames from the target MEP within 3.5 times the transmission interval, the link between the two is considered faulty. LTM frames will be sent out with the target MEP as the destination and the

TTL field in the LTM frames set to the maximum value 255. Based on the LTRs that the MIPs return, the fault source can be located.

To configure LT on MEPs:

Remarks Step Command

1. Find the path between a source

MEP and a target MEP. cfd linktrace service-instance

instance-id mep mep-id { target-mep

target-mep-id | target-mac

mac-address } [ ttl ttl-value ] [ hw-only ]

2. Enter system view. system-view

3. Enable LT messages automatic sending. cfd linktrace auto-detection [ size

size-value ]

Available in any view.

N/A

By default, LT messages automatic sending is disabled.

25

Displaying and maintaining CFD

Task Command

Display CFD status. display cfd status [ | { begin | exclude | include } regular-expression ]

Display the CFD protocol version. display cfd version [ | { begin | exclude | include } regular-expression ]

Display MD configuration information.

Display MA configuration information.

Display service instance configuration information.

Display MEP list in a service instance.

Display MP information.

Display the attribute and running information of the

MEPs.

Display LTR information received by a MEP.

Display the information of a remote MEP. display cfd md [ | { begin | exclude | include } regular-expression ] display cfd ma [ [ ma-name ] md { md-name

| level level-value } ] [ | { begin | exclude | include } regular-expression ] display cfd service-instance [ instance-id ]

[ | { begin | exclude | include }

regular-expression ] display cfd meplist [ service-instance

instance-id ] [ | { begin | exclude | include } regular-expression ] display cfd mp [ interface interface-type

interface-number ] [ | { begin | exclude | include } regular-expression ] display cfd mep mep-id service-instance

instance-id [ | { begin | exclude | include }

regular-expression ] display cfd linktrace-reply

[ service-instance instance-id [ mep

mep-id ] ] [ | { begin | exclude | include }

regular-expression ] display cfd remote-mep service-instance

instance-id mep mep-id [ | { begin | exclude | include } regular-expression ]

Display the content of the LTR messages received as responses to the automatically sent LTMs. display cfd linktrace-reply auto-detection

[ size size-value ] [ | { begin | exclude | include } regular-expression ]

Remarks

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in any view.

CFD configuration example

Network requirements

As shown in

Figure 6

:

The network comprises five devices and is divided into two MDs: MD_A (level 5) and MD_B (level

3). All ports belong to VLAN 100, and the MAs in the two MDs all serve VLAN 100. Assume that the MAC addresses of Device A through Device E are 0010-FC00-6511, 0010-FC00-6512,

0010-FC00-6513, 0010-FC00-6514, and 0010-FC00-6515, respectively.

MD_A has three edge ports: GigabitEthernet 1/0/1 on Device A, GigabitEthernet 1/0/3 on

Device D, and GigabitEthernet 1/0/4 on Device E. They are all inward-facing MEPs. MD_B has

26

two edge ports: GigabitEthernet 1/0/3 on Device B and GigabitEthernet 1/0/1 on Device D.

They are both outward-facing MEPs.

In MD_A, Device B is designed to have MIPs when its port is configured with low-level MEPs. Port

GigabitEthernet 1/0/3 is configured with MEPs of MD_B, and the MIPs of MD_A can be configured on this port. Configure the MIP generation rule of MD_A as explicit.

The MIPs of MD_B are designed on Device C, and are configured on all ports. You should configure the MIP generation rule as default.

Configure CC to monitor the connectivity among all the MEPs in MD_A and MD_B. Configure LB to locate link faults.

Use LT to identify the path between a source MEP and a target MEP or identify any link failure on the path.

Figure 6 Network diagram

Configuration procedure

1. Configure a VLAN and assign ports to it.

On each device shown in

Figure 6

, create VLAN 100 and assign ports GigabitEthernet 1/0/1 through GigabitEthernet 1/0/4 to VLAN 100.

2. Enable CFD on Device A.

<DeviceA> system-view

[DeviceA] cfd enable

Enable CFD on Device B through Device E using the same method.

3. Configure service instances:

# Create MD_A (level 5) on Device A, create MA_A, which serves VLAN 100, in MD_A, and create service instance 1 for MD_A and MA_A.

[DeviceA] cfd md MD_A level 5

[DeviceA] cfd ma MA_A md MD_A vlan 100

[DeviceA] cfd service-instance 1 md MD_A ma MA_A

Configure Device E as you configure Device A.

27

# Create MD_A (level 5) on Device B, create MA_A that serves VLAN 100, in MD_A, and then create service instance 1 for MD_A and MA_A. In addition, create MD_B (level 3) and MA_B that serves VLAN 100, in MD_B, and then create service instance 2 for MD_B and MA_B.

[DeviceB] cfd md MD_A level 5

[DeviceB] cfd ma MA_A md MD_A vlan 100

[DeviceB] cfd service-instance 1 md MD_A ma MA_A

[DeviceB] cfd md MD_B level 3

[DeviceB] cfd ma MA_B md MD_B vlan 100

[DeviceB] cfd service-instance 2 md MD_B ma MA_B

Configure Device D in the same way as Device B.

# Create MD_B (level 3) on Device C, create MA_B that serves VLAN 100, in MD_B, and then create service instance 2 for MD_B and MA_B.

[DeviceC] cfd md MD_B level 3

[DeviceC] cfd ma MA_B md MD_B vlan 100

[DeviceC] cfd service-instance 2 md MD_B ma MA_B

4. Configure MEPs:

# On Device A, configure a MEP list in service instance 1. Create and enable inward-facing MEP

1001 in service instance 1 on GigabitEthernet 1/0/1.

[DeviceA] cfd meplist 1001 4002 5001 service-instance 1

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] cfd mep 1001 service-instance 1 inbound

[DeviceA-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1001 enable

[DeviceA-GigabitEthernet1/0/1] quit

# On Device B, configure a MEP list in service instances 1 and 2 respectively. Create and enable outward-facing MEP 2001 in service instance 2 on GigabitEthernet 1/0/3.

[DeviceB] cfd meplist 1001 4002 5001 service-instance 1

[DeviceB] cfd meplist 2001 4001 service-instance 2

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] cfd mep 2001 service-instance 2 outbound

[DeviceB-GigabitEthernet1/0/3] cfd mep service-instance 2 mep 2001 enable

[DeviceB-GigabitEthernet1/0/3] quit

# On Device D, configure a MEP list in service instances 1 and 2 respectively, create and enable outward-facing MEP 4001 in service instance 2 on GigabitEthernet 1/0/1, and then create and enable inward-facing MEP 4002 in service instance 1 on GigabitEthernet 1/0/3.

[DeviceD] cfd meplist 1001 4002 5001 service-instance 1

[DeviceD] cfd meplist 2001 4001 service-instance 2

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] cfd mep 4001 service-instance 2 outbound

[DeviceD-GigabitEthernet1/0/1] cfd mep service-instance 2 mep 4001 enable

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/3

[DeviceD-GigabitEthernet1/0/3] cfd mep 4002 service-instance 1 inbound

[DeviceD-GigabitEthernet1/0/3] cfd mep service-instance 1 mep 4002 enable

[DeviceD-GigabitEthernet1/0/3] quit

# On Device E, configure a MEP list in service instance 1. Create and enable inward-facing MEP

5001 in service instance 1 on GigabitEthernet 1/0/4.

[DeviceE] cfd meplist 1001 4002 5001 service-instance 1

28

[DeviceE] interface gigabitethernet 1/0/4

[DeviceE-GigabitEthernet1/0/4] cfd mep 5001 service-instance 1 inbound

[DeviceE-GigabitEthernet1/0/4] cfd mep service-instance 1 mep 5001 enable

[DeviceE-GigabitEthernet1/0/4] quit

5. Configure MIP generation rules:

# Configure the MIP generation rule in service instance 1 on Device B as explicit.

[DeviceB] cfd mip-rule explicit service-instance 1

# Configure the MIP generation rule in service instance 2 on Device C as default.

[DeviceC] cfd mip-rule default service-instance 2

6. Configure CC:

# On Device A, enable the sending of CCM frames for MEP 1001 in service instance 1 on

GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1001 enable

[DeviceA-GigabitEthernet1/0/1] quit

# On Device B, enable the sending of CCM frames for MEP 2001 in service instance 2 on

GigabitEthernet 1/0/3.

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] cfd cc service-instance 2 mep 2001 enable

[DeviceB-GigabitEthernet1/0/3] quit

# On Device D, enable the sending of CCM frames for MEP 4001 in service instance 2 on

GigabitEthernet 1/0/1. Enable the sending of CCM frames for MEP 4002 in service instance 1 on GigabitEthernet 1/0/3.

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] cfd cc service-instance 2 mep 4001 enable

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/3

[DeviceD-GigabitEthernet1/0/3] cfd cc service-instance 1 mep 4002 enable

[DeviceD-GigabitEthernet1/0/3] quit

# On Device E, enable the sending of CCM frames for MEP 5001 in service instance 1 on

GigabitEthernet 1/0/4.

[DeviceE] interface gigabitethernet 1/0/4

[DeviceE-GigabitEthernet1/0/4] cfd cc service-instance 1 mep 5001 enable

[DeviceE-GigabitEthernet1/0/4] quit

Verifying the configuration

1. When the CC function detects a link fault, use LB on Device A to examine the status of the link between MEP 1001 and MEP 5001 in service instance 1.

[DeviceA] cfd loopback service-instance 1 mep 1001 target-mep 5001

Loopback to 0010-FC00-6515 with the sequence number start from 1001-43404:

Reply from 0010-FC00-6515: sequence number=1001-43404 time=5ms

Reply from 0010-FC00-6515: sequence number=1001-43405 time=5ms

Reply from 0010-FC00-6515: sequence number=1001-43406 time=5ms

Reply from 0010-FC00-6515: sequence number=1001-43407 time=5ms

Reply from 0010-FC00-6515: sequence number=1001-43408 time=5ms

Send:5 Received:5 Lost:0

29

After the whole network status is obtained with the CC function, use the LT function to identify the paths between source and target MEPs and to locate faults.

2. Use LT to identify the path between MEP 1001 and MEP 5001 in service instance 1 on Device A.

[DeviceA] cfd linktrace service-instance 1 mep 1001 target-mep 5001

Linktrace to MEP 5001 with the sequence number 1001-43462

MAC Address TTL Last MAC Relay Action

0010-FC00-6515 63 0010-FC00-6512 Hit

30

Configuring DLDP

Unidirectional links occur when one end of a bidirectional link can receive packets. Unidirectional links cause problems such as loops in an STP-enabled network.

For example, the link between two switches, Switch A and Switch B, is a bidirectional link when they are connected through a fiber pair, with one fiber used for sending packets from A to B and the other for sending packets from B to A. When one of the fibers stops operating, the link becomes a unidirectional link (one-way link).

Unidirectional fiber links are either:

Cross-connected.

Disconnected at one end or one fiber in the fiber pair is broken.

Figure 7

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

Figure 7 Correct and incorrect fiber connections

Correct fiber conecton

Device A

Unidirectional connection type 1

Cross-connected fibers

Device A

Unidirectional connection type 2

One fiber of a fiber pair Is not connected or Is broken

Device A

Port 1 Port 2 Port 1 Port 2 Port 1 Port 2

Port 1 Port 2 Port 1 Port 2 Port 1 Port 2

Device B Device B Device B

Ethernet optical port

Tx end Rx end Fiber link Unconnected or broken fiber

The DLDP detects unidirectional links (fiber links or twisted-pair links). DLDP can be configured to shut down the faulty port automatically or prompt users to take actions to avoid network problems.

As a data link layer protocol, DLDP cooperates with physical layer protocols to monitor link status. When the auto-negotiation mechanism provided by the physical layer detects physical signals and faults, DLDP performs operations such as identifying peer devices, detecting unidirectional links, and shutting down unreachable ports. The auto-negotiation mechanism and DLDP operate together to make sure physical/logical unidirectional links are detected and shut down, and to prevent failure of other protocols such as STP. If both ends of a link are operating normally at the physical layer, DLDP detects

31

whether the link is correctly connected at the link layer and whether the two ends can exchange packets properly. This is beyond the capability of the auto-negotiation mechanism at the physical layer.

How DLDP works

This section describes the function of DLDP.

DLDP link states

Table 10

describes DLDP link states.

Table 10 DLDP link states

State Description

Initial DLDP is disabled.

Inactive

Active

Advertisement

DLDP is enabled and the link is down.

DLDP is enabled and the link is up or the neighbor entries have been cleared.

All neighbors are bi-directionally reachable or DLDP has been in active state for more than five seconds. This is a relatively stable state where no unidirectional link has been detected.

Probe

Disable

DelayDown

DLDP enters this state if it receives a packet from an unknown neighbor. In this state, DLDP sends packets to examine whether the link is unidirectional. When

DLDP enters this state, a probe timer starts and an echo timeout timer starts for each neighbor to be probed.

A port enters this state when:

A unidirectional link is detected.

The contact with the neighbor in enhanced mode gets lost.

In this state, the port does not receive or send packets other than DLDPDUs.

A port in the Active, Advertisement, or Probe DLDP link state enters this state rather than removing the corresponding neighbor entry, and enters the Inactive state when it detects a port-down event. When a port enters this state, the DelayDown timer is triggered.

DLDP timers

Table 11 DLDP timers

DLDP timer

Active timer

Advertisement timer

Probe timer

Description

Determines the interval for sending Advertisement packets with RSY tags (default is to 1 second). By default, a device in the active DLDP link state sends one

Advertisement packet with RSY tags every second. The maximum number of advertisement packets with RSY tags that can be sent successively is 5.

Determines the interval for sending common advertisement packets (default is 5 seconds).

Determines the interval for sending Probe packets (default is 1 second). By default, a device in the probe state sends one Probe packet every second. The maximum number of Probe packets that can be sent successively is 10.

32

DLDP timer

Echo timer

Entry timer

Enhanced timer

DelayDown timer

Description

This timer is set to 10 seconds. It is triggered when a device transits to the Probe state or when an enhanced detect is launched. When the Echo timer expires and no Echo packet has been received from a neighbor device, the state of the link is set to unidirectional. The device transits to the Disable state and does the following:

Sends Disable packets.

Either prompts the user to shut down the port or shuts down the port automatically (depending on the DLDP down mode configured).

Removes the corresponding neighbor entries.

When a new neighbor joins, a neighbor entry is created and the corresponding entry timer is triggered. When a DLDP packet is received, the device updates the corresponding neighbor entry and the entry timer.

In normal mode, if no packet is received from a neighbor when the corresponding entry timer expires, DLDP sends advertisement packets with RSY tags and removes the neighbor entry.

In enhanced mode, if no packet is received from a neighbor when the Entry timer expires, DLDP triggers the enhanced timer.

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

In enhanced mode, this timer is triggered if no packet is received from a neighbor when the entry timer expires. Enhanced timer is set to 1 second.

After the Enhanced timer is triggered, the device sends up to eight probe packets to the neighbor at a frequency of one packet per second.

A device in Active, Advertisement, or Probe DLDP link state transits to DelayDown state and transits to the Inactive state when it detects a port-down event.

When a device transits to this state, the DelayDown timer is triggered. A device in

DelayDown state only responds to port-up events.

If a device in the DelayDown state detects a port-up event before the DelayDown timer expires, it resumes its original DLDP state. If not, when the DelayDown timer expires, the device removes the corresponding DLDP neighbor information and transits to the Inactive state.

RecoverProbe timer

This timer is set to 2 seconds. A port in the Disable state sends one RecoverProbe packet every two seconds to detect whether a unidirectional link has been restored to bidirectional.

DLDP mode

DLDP can operate in normal or enhanced mode.

In normal DLDP mode, when an entry timer expires, the device removes the corresponding neighbor entry and sends an Advertisement packet with the RSY tag.

In enhanced DLDP mode, when an entry timer expires, the Enhanced timer is triggered and the device tests the neighbor by sending up to eight Probe packets at the frequency of one packet per second. If no Echo packet has been received from the neighbor when the Echo timer expires, the device transits to the Disable state.

Table 12

shows the relationship between the DLDP modes and neighbor entry aging.

33

Table 12 DLDP mode and neighbor entry aging

DLDP mode

Detecting a neighbor after the corresponding neighbor entry ages out

Removing the neighbor entry immediately after the

Entry timer expires

Triggering the Enhanced timer after an Entry timer expires

Normal DLDP mode

No Yes No

Enhanced

DLDP mode

Yes No Yes

Table 13

shows the relationship between DLDP modes and unidirectional link types.

Table 13 DLDP mode and unidirectional link types

Unidirectional link type

Occurs on fibers

Occurs on copper twisted pairs

DLDP mode in which unidirectional links can be detected

Cross-connected link

Yes No Both normal and enhanced modes

Connectionless or broken link

Yes Yes

Only enhanced mode. The port that can receive signals is in Disable state, and the port that does not receive signals is in Inactive state.

Enhanced DLDP mode is designed for addressing black holes. It prevents situations where one end of a link is up and the other is down.

When forced speed and full duplex mode are configured on a port, the situation shown in

Figure 8

can occur (such as the fiber link). Without DLDP enabled, the port on Device B is actually down, but its state cannot be detected by common data link protocols, so the port on Device A is still up. However, in enhanced DLDP mode, the following occurs:

The port on Device B is in Inactive DLDP state because it is physically down.

The port on Device A tests the peer port on Device B after the Entry timer for the port on Device B expires.

The port on Device A transits to the Disable state if it receives no Echo packet from the port on

Device B when the Echo timer expires.

Figure 8 A scenario for the enhanced DLDP mode

DLDP authentication mode

You can use DLDP authentication to prevent network attacks and illegal detecting. The following DLDP authentication modes are available:

Non-authentication:

34

{

{

{

{

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

The receiving side examines the values of the two fields in received DLDP packets and drops any packets when there is a conflict with the corresponding local configuration.

Simple authentication:

{

Before sending a DLDP packet, the sending side sets the Authentication field to the user configured password and sets the Authentication type field to 1.

{

The receiving side examines the values of the two fields in received DLDP packets and drops any packets when there is a conflict with the corresponding local configuration.

MD5 authentication:

Before sending a packet, the sending side encrypts the user configured password by using MD5 algorithm, assigns the digest to the Authentication field, and sets the Authentication type field to

2.

The receiving side examines the values of the two fields in received DLDP packets and drops any packets conflicting with the corresponding local configuration.

DLDP processes

1. On a DLDP-enabled link that is in up state, DLDP sends DLDP packets to the peer device and processes the DLDP packets received from the peer device. DLDP packets sent vary with DLDP states.

Table 14 DLDP packet types and DLDP states

DLDP state

Active

Advertisement

Type of DLDP packets sent

Advertisement packet with RSY tag.

Normal Advertisement packet.

Disable Disable packet and then RecoverProbe packet.

NOTE:

A device sends Flush packets when it transits to Initial state from Active, Advertisement, Probe, or

DelayDown state, but does not send them when it transits to Initial state from Inactive or Disable state.

2. DLDP processes the packet received from a neighbor in the following ways:

{

In any of the three authentication modes, drops the packet if it fails to pass authentication.

{

{

Drops the packet if it carries an advertisement interval different than the local setting.

Processes the packet and handles DLDP port state as shown in Table 15

depending on its type.

Table 15 Processing incoming DLDP packets by packet type

Packet type Processing procedure

Advertisement with

RSY tag

Retrieves the neighbor information

If no matching neighbor entry exists, creates the neighbor entry, triggers the Entry timer, and changes the DLDP port state to

Probe.

If a matching neighbor entry already exists, resets the Entry timer and changes the DLDP port state to Probe.

35

Packet type Processing procedure

Normal

Advertisement

Retrieves the neighbor information

If no matching neighbor entry exists, creates the neighbor entry, triggers the Entry timer, and changes the DLDP port state to

Probe.

If a matching neighbor entry already exists, resets the Entry timer.

Flush packet

Examines whether the local DLDP port state is Disable

If yes, no process is performed.

If no, removes the matching neighbor entry (if any).

Probe

Echo

Disable

Retrieves the neighbor information

Retrieves the neighbor information

Examines whether the local DLDP port state is Disable

If no matching neighbor entry exists, creates the neighbor entry, transits to the Probe state, and returns Echo packets.

If a matching neighbor entry already exists, resets the Entry timer and returns Echo packets.

If no matching neighbor entry exists, creates the neighbor entry, triggers the Entry timer, and changes the DLDP port state to

Probe.

If a matching neighbor entry already exists:

Drops the packet if it carries information that conflicts with the neighbor entry.

Otherwise, sets the state of the neighbor to two way

(bidirectional). If all the neighbors are in two way state, changes from the Probe state to the Advertisement state and disable the Echo timer.

If yes, no process is performed.

If no, sets the state of the neighbor to one way (unidirectional), and then examines the state of other neighbors to determine the subsequent action to take:

If all the neighbors are in one way state, changes the local

DLDP port state to Disable.

If the state of some neighbors is still unknown, takes no action until the state of these neighbors is determined.

If any two-way neighbor is present, removes all one-way neighbors, but does not change the DLDP port state.

If yes, returns RecoverEcho packets.

RecoverProbe

Examines whether the local port is in

Disable or

Advertisement state

If no, no process is performed.

RecoverEcho

Examines whether the local DLDP port state is Disable

If yes, changes the local DLDP port state to Active if the neighbor information the packet carries is consistent with the local port information.

If no, no process is performed.

36

Packet type Processing procedure

LinkDown packet

Examines whether the local port operates in

Enhanced mode

If yes and the local port is not in Disable state, sets the state of the neighbor to one way, and then examines the state of other neighbors to determine the subsequent action to take:

If all the neighbors are in one way state, changes the local

DLDP port state to Disable.

If the state of some neighbors is still unknown, takes no action until the state of these neighbors is determined.

If any two-way neighbor is present, removes all one-way neighbors, but does not change the DLDP port state.

If no, no process is performed.

3.

If no echo packet is received from a neighbor, DLDP takes action as described in Table 16 .

Table 16 Action to take when no echo packet is received from a neighbor

No echo packet received from the neighbor Action

In normal mode, no echo packet is received when the Echo timer expires.

In enhanced mode, no echo packet is received when the Echo timer expires.

DLDP sets the state of the neighbor to one way, and determines the subsequent action to take depending on the state of the other neighbors:

If all the neighbors are in one way state, removes all the neighbor entries, changes the DLDP port state to Disable, outputs log and tracking information, and sends Disable packets to the neighbors. In addition, depending on the user-defined DLDP down mode, shuts down the local port or prompts users to shut down the port.

If the state of some neighbors is unknown, takes no action until the state of these neighbors is determined.

If a two-way neighbor is present, removes all the one-way neighbors, but does not change the DLDP port state.

Link auto-recovery mechanism

If the port shutdown mode upon detection of a unidirectional link is set to auto, DLDP automatically sets the state of the port where a unidirectional link is detected to DLDP down. A DLDP down port cannot forward data traffic or send/receive any PDUs except DLDPDUs.

On a DLDP down port, DLDP monitors the unidirectional link. Once DLDP finds out that the state of the link has been restored to bidirectional, it brings up the port. The specific process is as follows:

1. The DLDP down port sends out a RecoverProbe packet every two seconds, which only carries information about the local port.

2. Upon receiving the RecoverProbe packet, the remote end returns a RecoverEcho packet.

3. Upon receiving the RecoverEcho packet, the local port examines whether neighbor information in the RecoverEcho packet is the same as the local port information. If they are the same, the link between the local port and the neighbor is considered to have been restored to a bidirectional link, and the port will transit from Disable state to Active state and re-establish relationship with the neighbor.

Only DLDP down ports can send and process Recover packets, including RecoverProbe packets and

RecoverEcho packets. If related ports are manually shut down with the shutdown command, the auto-recovery mechanism does not take effect.

37

DLDP neighbor state

A DLDP neighbor can be in one of the states described in

Table 17 .

Table 17 DLDP neighbor state description

DLDP neighbor state Description

Unknown

The neighbor is just detected and is being probed. It transits to Two way state or

Unidirectional state after the probe operation finishes.

Two way

Unidirectional

The neighbor has received response from its peer.

The link connecting the neighbor is detected to be a unidirectional link. After a device transits to this state, the corresponding neighbor entries maintained on other devices are removed.

DLDP configuration task list

For DLDP to operate properly, enable DLDP on both sides and make sure these settings are consistent: the interval to send Advertisement packets, DLDP authentication mode, and password.

DLDP does not process any LACP events. The links in an aggregation are treated as individual links in DLDP.

Make sure the DLDP version running on devices on the two ends are the same.

Task Remarks

Configuring the duplex mode and speed of an Ethernet interface

Required.

Enabling DLDP

Setting DLDP mode

Setting the interval to send advertisement packets

Setting the DelayDown timer

Setting the port shutdown mode

Configuring DLDP authentication

Resetting DLDP state

Required.

Optional.

Optional.

Optional.

Optional.

Optional.

Optional.

Configuring the duplex mode and speed of an

Ethernet interface

To make sure DLDP operates properly on a link, configure the full duplex mode for the ports at two ends of the link, and configure a speed for the two ports, rather than letting them negotiate a speed. For more information about the duplex and speed commands, see Layer 2—LAN Switching Command Reference.

Enabling DLDP

To properly configure DLDP on the device, first enable DLDP globally, and then enable it on each port.

To enable DLDP:

38

Step Command

1. Enter system view. system-view

Remarks

N/A

2. Enable DLDP globally. dldp enable

By default, DLDP is disabled globally.

3. Enter Layer 2 Ethernet interface view or port group view.

Enter Layer 2 Ethernet interface view: interface interface-type

interface-number

Enter port group view: port-group manual

port-group-name

Use either command.

Configurations made in Ethernet interface view apply to the current port only. Configurations made in port group view apply to all ports in the port group.

4. Enable DLDP. dldp enable

By default, DLDP is disabled on a port.

NOTE:

• DLDP takes effect only on Ethernet interfaces (fiber or copper).

• DLDP can detect unidirectional links only after all physical links are connected. Therefore, before enabling DLDP, make sure optical fibers or copper twisted pairs are connected.

Setting DLDP mode

DLDP operates in normal or enhanced mode.

Normal mode—DLDP does not actively detect neighbors when the corresponding neighbor entries age out.

Enhanced mode—DLDP actively detects neighbors when the corresponding neighbor entries age out.

To set DLDP mode:

Step Command

1. Enter system view. system-view

2. Set DLDP mode. dldp work-mode { enhance | normal }

Remarks

N/A

Optional.

By default DLDP operates in normal mode.

Setting the interval to send advertisement packets

DLDP detects unidirectional links by sending Advertisement packets. To make sure DLDP can detect unidirectional links promptly before network performance deteriorates, set the advertisement interval appropriate for your network environment. Set the interval shorter than one third of the STP convergence time. If the interval is too long, STP loops may occur before unidirectional links are detected and shut down. If the interval is too short, the number of advertisement packets increases. HP recommends that you use the default interval in most cases.

To set the Advertisement packet sending interval:

39

Step Command

1. Enter system view. system-view

2. Set the interval to send

Advertisement packets. dldp interval time

Remarks

N/A

The default is 5 seconds.

This setting applies to all

DLDP-enabled ports.

To enable DLDP to operate properly, make sure the two sides of the link use the same Advertisement packet sending interval.

Setting the DelayDown timer

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

On some ports, when the Tx line fails, the port goes down and then comes up again, causing optical signal jitters on the Rx line. To avoid this problem, when a port goes down due to a Tx failure, the device transits to the DelayDown state instead of the Inactive state. This prevents the corresponding neighbor entries from being removed. At the same time, the device triggers the DelayDown timer. If the port goes up before the timer expires, the device restores the original state. If the port remains down when the timer expires, the device transits to the Inactive state.

To set the DelayDown timer

Step Command

1. Enter system view. system-view

2. Set the DelayDown timer. dldp delaydown-timer time

Remarks

N/A

Optional.

The default is 1 second.

Setting the port shutdown mode

On detecting a unidirectional link, the ports can be shut down by using one of the following two modes.

Manual mode—This mode applies to low performance networks, where normal links may be treated as unidirectional links. It protects data traffic transmission against false unidirectional links.

In this mode, DLDP only detects unidirectional links, but does not automatically shut down unidirectional link ports. Instead, the DLDP state machine generates logs and traps to prompt you to manually shut down unidirectional link ports with the shutdown command. HP recommends that you follow these instructions. Then the DLDP state machine transits to the Disable state.

Auto mode—In this mode, when a unidirectional link is detected, DLDP transits to Disable state, generates log and traps, and sets the port state to DLDP Down.

If the device is busy, or the CPU usage is high, normal links may be treated as unidirectional links. In this case, you can set the port shutdown mode to manual mode to override false unidirectional link report.

To set port shutdown mode:

Step Command

1. Enter system view. system-view

Remarks

N/A

40

Step Command

2. Set port shutdown mode. dldp unidirectional-shutdown { auto |

Remarks

Optional.

The default is auto.

Configuring DLDP authentication

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

To enable DLDP to operate properly, make sure DLDP authentication modes and passwords on both sides of a link are the same.

To configure DLDP authentication:

Step Command

1. Enter system view. system-view

2. Configure DLDP authentication. dldp authentication-mode { none |

{ md5 | simple } password }

Remarks

N/A

The default is none.

Resetting DLDP state

After DLDP detects a unidirectional link on a port, the port enters Disable state. In this case, DLDP prompts you to manually shut down the port or automatically shuts down the port depending on the user-defined port shutdown mode. To enable the port to perform DLDP detect again, reset the DLDP state of the port by using one of the following methods:

If the port is shut down manually with the shutdown command, run the undo shutdown command on the port.

If DLDP automatically shuts down the port, run the dldp reset command on the port to enable the port to perform DLDP detection again. Alternatively, you can wait for DLDP to automatically enable the port when it detects that the link has been restored to bidirectional. For how to reset the DLDP state by using the dldp reset command, see "

Resetting DLDP state in system view " and "

Resetting

DLDP state in port view/port group view ."

The DLDP state that the port transits to upon the DLDP state reset operation depends on its physical state.

If the port is physically down, it transits to Inactive state. If the port is physically up, it transits to Active state.

Resetting DLDP state in system view

Resetting DLDP state in system view applies to all ports of the device.

41

To reset DLDP in system view:

Step Command

1. Enter system view. system-view

2.

Reset DLDP state. dldp reset

Resetting DLDP state in port view/port group view

Resetting DLDP state in port view or port group view applies to the current port or all ports in the port group.

To reset DLDP state in port view/port group view:

Step Command

1. Enter system view. system-view

2. Enter Layer 2 Ethernet interface view or port group view.

Enter Layer 2 Ethernet interface view: interface interface-type

interface-number

Enter port group view: port-group manual

port-group-name

3. Reset DLDP state. dldp reset

Remarks

N/A

Use either approach.

Configurations made in Ethernet interface view only apply to the current port. Configurations made in port group view apply to all ports in the port group.

N/A

Displaying and maintaining DLDP

Task Command

Display the DLDP configuration of a port. display dldp [ interface-type

interface-number ] [ | { begin | exclude | include } regular-expression ]

Display the statistics on DLDP packets passing through a port.

Clear the statistics on DLDP packets passing through a port. display dldp statistics [ interface-type

interface-number ] [ | { begin | exclude | include } regular-expression ] reset dldp statistics [ interface-type

interface-number ]

DLDP configuration examples

This section provides examples of DLDP configuration.

Remarks

Available in any view.

Available in any view.

Available in user view.

Automatically shutting down unidirectional links

Network requirements

As shown in

Figure 9 , Device A and Device B are connected with two fiber pairs.

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

42

Figure 9 Network diagram

Configuration procedure

1. Configure Device A:

# Enable DLDP globally.

<DeviceA> system-view

[DeviceA] dldp enable

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

[DeviceA] interface gigabitethernet 1/0/49

[DeviceA-GigabitEthernet1/0/49] duplex full

[DeviceA-GigabitEthernet1/0/49] speed 1000

[DeviceA-GigabitEthernet1/0/49] dldp enable

[DeviceA-GigabitEthernet1/0/49] quit

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

[DeviceA] interface gigabitethernet 1/0/50

[DeviceA-GigabitEthernet1/0/50] duplex full

[DeviceA-GigabitEthernet1/0/50] speed 1000

[DeviceA-GigabitEthernet1/0/50] dldp enable

[DeviceA-GigabitEthernet1/0/50] quit

# Set the DLDP mode to enhanced.

[DeviceA] dldp work-mode enhance

# Set the port shutdown mode to auto.

[DeviceA] dldp unidirectional-shutdown auto

2. Configure Device B:

43

# Enable DLDP globally.

<DeviceB> system-view

[DeviceB] dldp enable

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

[DeviceB] interface gigabitethernet 1/0/49

[DeviceB-GigabitEthernet1/0/49] duplex full

[DeviceB-GigabitEthernet1/0/49] speed 1000

[DeviceB-GigabitEthernet1/0/49] dldp enable

[DeviceB-GigabitEthernet1/0/49] quit

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

[DeviceB] interface gigabitethernet 1/0/50

[DeviceB-GigabitEthernet1/0/50] duplex full

[DeviceB-GigabitEthernet1/0/50] speed 1000

[DeviceB-GigabitEthernet1/0/50] dldp enable

[DeviceB-GigabitEthernet1/0/50] quit

# Set the DLDP mode to enhanced.

[DeviceB] dldp work-mode enhance

# Set the port shutdown mode to auto.

[DeviceB] dldp unidirectional-shutdown auto

Verifying the configuration

After the configurations are complete, you can use the display dldp command to display the DLDP configuration information on ports.

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

[DeviceA] display dldp

DLDP global status : enable

DLDP interval : 5s

DLDP work-mode : enhance

DLDP authentication-mode : none

DLDP unidirectional-shutdown : auto

DLDP delaydown-timer : 1s

The number of enabled ports is 2.

Interface GigabitEthernet1/0/49

DLDP port state : advertisement

DLDP link state : up

The neighbor number of the port is 1.

Neighbor mac address : 0023-8956-3600

Neighbor port index : 59

Neighbor state : two way

Neighbor aged time : 11

Interface GigabitEthernet1/0/50

DLDP port state : advertisement

DLDP link state : up

44

The neighbor number of the port is 1.

Neighbor mac address : 0023-8956-3600

Neighbor port index : 60

Neighbor state : two way

Neighbor aged time : 12

The output shows that both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 are in Advertisement state, which means both links are bidirectional.

# Enable system information monitoring on Device A and enable the display of log and trap information.

[DeviceA] quit

<DeviceA> terminal monitor

<DeviceA> terminal logging

<DeviceA> terminal trapping

The following log and trap information is displayed on Device A:

<DeviceA>

#Jan 18 17:36:18:798 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap

1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825792.

%Jan 18 17:36:18:799 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is DOWN.

%Jan 18 17:36:18:799 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_AUTO: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/49. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.

The shutdown mode is AUTO. DLDP shuts down the port.

#Jan 18 17:36:20:189 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap

1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825793.

%Jan 18 17:36:20:189 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is DOWN.

%Jan 18 17:36:20:190 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_AUTO: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/50. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.

The shutdown mode is AUTO. DLDP shuts down the port.

%Jan 15 16:54:56:040 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_AUTO_ENHANCE: -Slot=1; In enhanced DLDP mode, port GigabitEthernet1/0/49 cannot detect its aged-out neighbor. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor. The shutdown mode is AUTO. DLDP shuts down the port.

The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is down, and DLDP has detected a unidirectional link on both ports and has automatically shut them down.

Assume that in this example, the unidirectional links are caused by cross-connected fibers. Correct the fiber connections on detecting the unidirectional link problem. As a result, the ports shut down by DLDP automatically recover and Device A displays the following log information:

<DeviceA>

%Jan 18 17:47:33:869 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is UP.

%Jan 18 17:47:35:894 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is UP.

The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is now up.

45

Manually shutting down unidirectional links

Network requirements

As shown in

Figure 10

, Device A and Device B are connected with two fiber pairs.

Configure DLDP to send information when a unidirectional link is detected, which reminds the network administrator to manually shut down the faulty port.

Figure 10 Network diagram

Configuration procedure

1. Configure Device A:

# Enable DLDP globally.

<DeviceA> system-view

[DeviceA] dldp enable

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

[DeviceA] interface gigabitethernet 1/0/49

[DeviceA-GigabitEthernet1/0/49] duplex full

[DeviceA-GigabitEthernet1/0/49] speed 1000

[DeviceA-GigabitEthernet1/0/49] dldp enable

[DeviceA-GigabitEthernet1/0/49] quit

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

[DeviceA] interface gigabitethernet 1/0/50

[DeviceA-GigabitEthernet1/0/50] duplex full

[DeviceA-GigabitEthernet1/0/50] speed 1000

46

[DeviceA-GigabitEthernet1/0/50] dldp enable

[DeviceA-GigabitEthernet1/0/50] quit

# Set the DLDP mode to enhanced.

[DeviceA] dldp work-mode enhance

# Set the port shutdown mode to manual.

[DeviceA] dldp unidirectional-shutdown manual

2. Configure Device B:

# Enable DLDP globally.

<DeviceB> system-view

[DeviceB] dldp enable

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

[DeviceB] interface gigabitethernet 1/0/49

[DeviceB-GigabitEthernet1/0/49] duplex full

[DeviceB-GigabitEthernet1/0/49] speed 1000

[DeviceB-GigabitEthernet1/0/49] dldp enable

[DeviceB-GigabitEthernet1/0/49] quit

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

[DeviceB] interface gigabitethernet 1/0/50

[DeviceB-GigabitEthernet1/0/50] duplex full

[DeviceB-GigabitEthernet1/0/50] speed 1000

[DeviceB-GigabitEthernet1/0/50] dldp enable

[DeviceB-GigabitEthernet1/0/50] quit

# Set the DLDP mode to enhanced.

[DeviceB] dldp work-mode enhance

# Set the port shutdown mode to manual.

[DeviceB] dldp unidirectional-shutdown manual

Verifying the configuration

After the configurations are complete, you can use the display dldp command to display the DLDP configuration information on ports.

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

[DeviceA] display dldp

DLDP global status : enable

DLDP interval : 5s

DLDP work-mode : enhance

DLDP authentication-mode : none

DLDP unidirectional-shutdown : manual

DLDP delaydown-timer : 1s

The number of enabled ports is 2.

Interface GigabitEthernet1/0/49

DLDP port state : advertisement

DLDP link state : up

The neighbor number of the port is 1.

Neighbor mac address : 0023-8956-3600

47

Neighbor port index : 59

Neighbor state : two way

Neighbor aged time : 11

Interface GigabitEthernet1/0/50

DLDP port state : advertisement

DLDP link state : up

The neighbor number of the port is 1.

Neighbor mac address : 0023-8956-3600

Neighbor port index : 60

Neighbor state : two way

Neighbor aged time : 12

The output shows that both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 are in Advertisement state, which means both links are bidirectional.

# Enable system information monitoring on Device A and enable the display of log and trap information.

[DeviceA] quit

<DeviceA> terminal monitor

<DeviceA> terminal logging

<DeviceA> terminal trapping

The following log and trap information is displayed on Device A:

<DeviceA>

#Jan 18 18:10:38:481 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap

1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825792.

%Jan 18 18:10:38:481 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_MANUAL: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/49. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.

The shutdown mode is MANUAL. The port needs to be shut down by the user.

#Jan 18 18:10:38:618 2010 DeviceA DLDP/1/TrapOfUnidirectional: -Slot=1; Trap

1.3.6.1.4.1.25506.2.43.2.1.1 : DLDP detects a unidirectional link in port 17825793.

%Jan 18 18:10:38:618 2010 DeviceA DLDP/3/DLDP_UNIDIRECTION_MANUAL: -Slot=1; DLDP detects a unidirectional link on port GigabitEthernet1/0/50. The transceiver has malfunction in the Tx direction or cross-connected links exist between the local device and its neighbor.

The shutdown mode is MANUAL. The port needs to be shut down by the user.

The output shows that DLDP has detected a unidirectional link on both GigabitEthernet 1/0/49 and

GigabitEthernet 1/0/50, and is asking you to shut down the faulty ports manually.

After you shut down GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50, the following log information is displayed:

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/49

[DeviceA-GigabitEthernet1/0/49] shutdown

%Jan 18 18:16:12:044 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is DOWN.

[DeviceA-GigabitEthernet1/0/49] quit

[DeviceA] interface gigabitethernet 1/0/50

[DeviceA-GigabitEthernet1/0/50] shutdown

48

%Jan 18 18:18:03:583 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is DOWN.

The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is down.

Assume that in this example, the unidirectional links are caused by cross-connected fibers. Correct the fiber connections and then bring up the ports shut down earlier.

# On Device A, bring up GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50:

[DeviceA-GigabitEthernet1/0/50] undo shutdown

[DeviceA-GigabitEthernet1/0/50]

%Jan 18 18:22:11:698 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/50 link status is UP.

[DeviceA-GigabitEthernet1/0/50] quit

[DeviceA] interface gigabitethernet 1/0/49

[DeviceA-GigabitEthernet1/0/49] undo shutdown

[DeviceA-GigabitEthernet1/0/49]

%Jan 18 18:22:46:065 2010 DeviceA IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/49 link status is UP.

The output shows that the link status of both GigabitEthernet 1/0/49 and GigabitEthernet 1/0/50 is now up.

Troubleshooting DLDP

Symptom

This section provides troubleshooting advice.

Two DLDP-enabled devices, Device A and Device B, are connected through two fiber pairs, in which two fibers are cross-connected. The unidirectional links cannot be detected. All the four ports involved are in

Advertisement state.

Analysis

The problem can be caused by the following:

The intervals to send Advertisement packets on Device A and Device B are not the same.

DLDP authentication modes/passwords on Device A and Device B are not the same.

Solution

Make sure the interval to send Advertisement packets, the authentication mode, and the password configured on Device A and Device B are the same.

49

Configuring RRPP

This chapter describes how to configure RRPP.

Overview

The RRPP is a link layer protocol designed for Ethernet rings. RRPP can prevent broadcast storms caused by data loops when an Ethernet ring is healthy and rapidly restore the communication paths between the nodes in the event that a link is disconnected on the ring.

Metropolitan area networks and enterprise networks typically use the ring topology to improve reliability.

However, services are interrupted if any node in the ring network fails. A ring network usually uses RPR or Ethernet rings. RPR is high in cost as it needs dedicated hardware. In contrast, the Ethernet ring technology is more mature and economical, so it is more and more widely used in MANs and enterprise networks.

RSTP, PVST, MSTP, and RRPP can eliminate Layer-2 loops. RSTP, PVST, and MSTP are mature, but they take several seconds to converge. RRPP is an Ethernet ring-specific data link layer protocol, and converges faster than RSTP, PVST, and MSTP. Additionally, the convergence time of RRPP is independent of the number of nodes in the Ethernet ring, so it can be applied to large-diameter networks.

Basic RRPP concepts

The basic parts of an RRPP network are shown

Figure 11 :

Figure 11 RRPP networking diagram

RRPP domain

Interconnected devices with the same domain ID and control VLANs constitute an RRPP domain. An RRPP domain contains the following elements: primary ring, subring, control VLAN, master node, transit node, primary port, secondary port, common port, and edge port.

As shown in

Figure 11 , Domain 1 is an RRPP domain, including two RRPP rings: Ring 1 and Ring 2. All

nodes on the two RRPP rings belong to the RRPP domain.

50

RRPP ring

A ring-shaped Ethernet topology is called an "RRPP ring". RRPP rings include primary rings and subrings.

You can configure a ring as either the primary ring or a subring by specifying its ring level. The primary ring is level 0, and a subring is level 1. An RRPP domain contains one or multiple RRPP rings, one serving as the primary ring and the others serving as subrings. A ring can be in one of the following states:

Health state—All physical links on the Ethernet ring are connected.

Disconnect state—Some physical links on the Ethernet ring are broken.

As shown in Figure 11 , Domain 1 contains two RRPP rings: Ring 1 and Ring 2. The level of Ring 1 is set

to 0, and that of Ring 2 is set to 1. Ring 1 is configured as the primary ring and Ring 2 is configured as a subring.

Control VLAN and data VLAN

1. Control VLAN

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

An RRPP domain is configured with two control VLANs: one primary control VLAN, which is the control VLAN for the primary ring, and one secondary control VLAN, which is the control VLAN for subrings. All subrings in the same RRPP domain share the same secondary control VLAN. After you specify a VLAN as the primary control VLAN, the system automatically configures the VLAN whose

ID is the primary control VLAN ID plus one as the secondary control VLAN.

IP address configuration is prohibited on the control VLAN interfaces.

2. Data VLAN

A data VLAN is a VLAN dedicated to transferring data packets. Both RRPP ports and non-RRPP ports can be assigned to a data VLAN.

Node

Each device on an RRPP ring is a node. The role of a node is configurable. RRPP has the following node roles:

Master node—Each ring has only one master node. The master node initiates the polling mechanism and determines the operations to be performed after a change in topology.

Transit node—Transit nodes include all nodes except the master node on the primary ring and all nodes on subrings except the master nodes and the nodes where the primary ring intersects with the subrings. A transit node monitors the state of its directly-connected RRPP links and notifies the master node of any link state changes. Based on the link state changes, the master node chooses the operations to be performed.

Edge node—A special node residing on both the primary ring and a subring at the same time. An edge node serves as a master node or transit node on the primary ring and an edge node on the subring.

Assistant-edge node—A special node residing on both the primary ring and a subring at the same time. An assistant-edge node serves as a master node or transit node on the primary ring and an assistant-edge node on the subring. This node works in conjunction with the edge node to detect the integrity of the primary ring and perform loop guard.

As shown in

Figure 11 , Ring 1 is the primary ring and Ring 2 is a subring. Device A is the master node

of Ring 1. Device B, Device C, and Device D are the transit nodes of Ring 1. Device E is the master node of Ring 2, Device B is the edge node of Ring 2, and Device C is the assistant-edge node of Ring 2.

51

Primary port and secondary port

Each master node or transit node has two ports connected to an RRPP ring, one serving as the primary port and the other serving as the secondary port. You can determine the role of a port. The functional differences are:

1. Master node—The primary port and the secondary port of a master node function differently:

{

The primary port sends loop-detect packets and the secondary port receives loop-detect packets.

{

{

When an RRPP ring is in Health state, the secondary port of the master node logically denies data VLANs and permits only the packets from the control VLANs.

When an RRPP ring is in Disconnect state, the secondary port of the master node forwards packets from data VLANs.

2. Transit node—The primary port and the secondary port of a transit node function the same. Both transfer protocol packets and data packets over an RRPP ring.

As shown in Figure 11 , Device A is the master node of Ring 1. Its Port 1 is the primary port and its Port 2

is the secondary port of the master node on Ring 1. Device B, Device C, and Device D are the transit nodes of Ring 1. Their Port 1 is the primary port and their Port 2 is the secondary port on Ring 1.

Common port and edge port

Edge node ports and assistant-edge node ports that connect to the primary ring are common ports. Edge node ports and assistant-edge node edge ports only connect to the subrings are edge ports.

As shown in Figure 11 , Device B and Device C lie 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, configure a group of subrings on the edge node or assistant-edge node. For more information about Edge-Hello packets, see "

RRPPDUs ." You must configure a device as the edge

node of these subrings, and another device as the assistant-edge node of these subrings. Additionally, the subrings of the edge node and assistant-edge node must connect to the same subring packet tunnels in major ring (SRPTs), so that Edge-Hello packets of the edge node of these subrings travel to the assistant-edge node of these subrings over the same link.

An RRPP ring group configured on the edge node is an edge node RRPP ring group. An RRPP ring group configured on an assistant-edge node is an assistant-edge node RRPP ring group. Up to one subring in an edge node RRPP ring group is allowed to send Edge-Hello packets.

RRPPDUs

RRPPDUs of subrings are transmitted as data packets in the primary ring, and RRPPDUs of the primary ring can only be transmitted within the primary ring.

Table 18 RRPPDU types and their functions

Type

Hello

Fast-Hello

Description

The master node initiates Hello packets to detect the integrity of a ring in a network.

The master node initiates Fast-Hello packets to fast detect the integrity of a ring in a network.

52

Type

Link-Down

Common-Flush-FDB

Complete-Flush-FDB

Edge-Hello

Fast-Edge-Hello

Major-Fault

Description

The transit node, the edge node or the assistant-edge node initiates Link-Down packets to notify the master node of the disappearance of a ring in case of a link failure.

The master node initiates Common-Flush-FDB packets to instruct the transit nodes to update their own MAC entries and ARP/ND entries when an RRPP ring transits to

Disconnect state.

The master node initiates Complete-Flush-FDB packets to instruct the transit nodes to update their own MAC entries and ARP/ND entries, and release blocked ports from being blocked temporarily when an RRPP ring transits to Health state.

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

The edge node initiates Fast-Edge-Hello packets to fast examine the SRPTs between it and the assistant-edge node.

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

RRPP timers

When RRPP examines the link state of an Ethernet ring, the master node sends Hello packets out the primary port according to the Hello timer, and determines whether its secondary port receives the Hello packets based on the Fail timer.

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

Fail timer—Specifies the maximum delay between the master node sending Hello packets out the primary port and the secondary port receiving the Hello packets from the primary port. If the secondary port receives the Hello packets sent by the local master node before the Fail timer expires, the overall ring is in Health state. Otherwise, the ring transits into Disconnect state.

Fast-Hello timer—Specifies the interval at which the master node sends Fast-Hello packets out from the primary port.

Fast-Fail timer—Specifies the maximum delay between the master node sending Fast-Hello packets out from the primary port and the secondary port receiving the Fast-Hello packets from the primary port. If the secondary port receives the Fast-Hello packets sent by the local master node before the

Fast-Fail timer expires, the entire ring is in Health state. Otherwise, the ring transits into the

Disconnect state.

In an RRPP domain, a transit node learns the Hello timer value and the Fail timer value on the master node through the received Hello packets, ensuring that all nodes in the ring network are consistent in the two timer settings. A transit node, however, cannot learn the Fast-Hello timer value and the Fast-Fail timer value set on the master node through received Fast-Hello packets.

How RRPP works

This section explains the way that RRPP works.

Polling mechanism

The polling mechanism is used by the master node of an RRPP ring to examine the Health state of the ring network.

53

The master node periodically sends Hello packets out from its primary port. These Hello packets travel through each transit node on the ring in turn:

If the ring is complete, the secondary port of the master node receives Hello packets before the Fail timer expires and the master node keeps the secondary port blocked.

If the ring is torn down, the secondary port of the master node fails to receive Hello packets before the Fail timer expires. The master node releases the secondary port from blocking data VLANs and sending Common-Flush-FDB packets to instruct all transit nodes to update their own MAC entries and ARP/ND entries.

Link down alarm mechanism

When a transit node, edge node, or assistant-edge node finds any of its own ports belonging to an RRPP domain is down, it immediately sends Link-Down packets to the master node. Upon the receipt of a

Link-Down packet, the master node releases the secondary port from blocking data VLANs, and sends

Common-Flush-FDB packet to instruct all transit nodes, edge nodes, and assistant-edge nodes to update their own MAC and ARP/ND entries. After each node updates its own entries, traffic is switched to the normal link.

Ring recovery

After the ports belonging to the RRPP domain on the transit nodes, edge nodes, or assistant-edge nodes are brought up again, the master node may find the ring is restored after a period of time. A temporary loop may arise in the data VLAN during this period, resulting in a broadcast storm.

To prevent temporary loops, when non-master nodes find that their ports accessing the ring are brought up again, they immediately block them and permit only the packets from the control VLAN to pass through. The blocked ports are activated only when the nodes confirm that the ports do not cause a loop.

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

As shown in

Figure 15

, Ring 1 is the primary ring, and Ring 2 and Ring 3 are subrings. When the two

SRPTs between the edge node and the assistant-edge node are down, the master nodes of Ring 2 and

Ring 3 open their respective secondary ports, and a loop among Device B, Device C, Device E, and

Device F is generated. As a result, broadcast storm occurs.

To avoid generating a loop, the edge node temporarily blocks the edge port. The blocked edge port is activated only when the edge node is sure that activating it does not cause a loop.

Load balancing

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

By configuring an individual RRPP domain for transmitting the traffic from the specified VLANs (protected

VLANs) in a ring network, traffic from different VLANs can be transmitted according to different topologies in the ring network for load balancing.

As shown in

Figure 16 , Ring 1 is configured as the primary ring of Domain 1 and Domain 2, which are

configured with different protected VLANs. Device A is the master node of Ring 1 in Domain 1. Device

B is the master node of Ring 1 in Domain 2. With such configurations, traffic from different VLANs can be transmitted on different links for load balancing in the single-ring network.

RRPP ring group

In an edge node RRPP ring group, only an activated subring with the lowest domain ID and ring ID can send Edge-Hello packets. In an assistant-edge node RRPP ring group, any activated subring that has received Edge-Hello packets forwards these packets to the other activated subrings. With an edge node

RRPP ring group and an assistant-edge node RRPP ring group configured, only one subring sends

54

Edge-Hello packets on the edge node, and only one subring receives Edge-Hello packets on the assistant-edge node, reducing CPU workload.

As shown in Figure 15

, Device B is the edge node of Ring 2 and Ring 3, and Device C is the assistant-edge node of Ring 2 and Ring 3. Device B and Device C send or receive Edge-Hello packets frequently. If more subrings are configured or load balancing is configured for more multiple domains,

Device B and Device C sends or receives a mass of Edge-Hello packets.

To reduce Edge-Hello traffic, assign Ring 2 and Ring 3 to an RRPP ring group configured on the edge node Device B, and assign Ring 2 and Ring 3 to an RRPP ring group configured on Device C. After such configurations, if all rings are activated, only Ring 2 on Device B sends Edge-Hello packets.

Fast detection mechanism

Ideally, an RRPP ring can fast converge because its transit nodes can detect link failures fast and send out notifications immediately. In practice, some devices on an RRPP ring may not support RRPP. RRPP can detect link failures between these devices only through the timeout mechanism. This results in long-time traffic interruption and failure to implement millisecond-level convergence.

To address this problem, a fast detection mechanism was introduced. The mechanism works as follows:

The master node sends Fast-Hello packets out its primary port at the interval specified by the

Fast-Hello timer. If the secondary port receives the Fast-Hello packets sent by the local master node before the Fast-Fail timer expires, the entire ring is in Health state. Otherwise, the ring transits into the Disconnect state.

The edge node sends Fast-Edge-Hello packets out its common ports at the interval specified by the timer resolution. If the assistant-edge node fails to receive the Fast-Edge-Hello packets within three times the timer resolution, the SRPTs transit to Disconnect state.

As shown in

Figure 12 , with fast detection enabled for RRPP domain 1, Device A, the master node of Ring

1, sends out Fast-Hello packets periodically and determines the ring status according to whether

Fast-Hello packets are received before the Fast-Fail timer expires, implementing link status fast detection.

NOTE:

• Timer resolution refers to the shortest-period timer provided on an RRPP node.

• To implement fast detection on an RRPP ring, enable fast detection on the master node, edge node, and assistant-edge node of the RRPP ring.

Typical RRPP networking

This section lists the typical networking applications of RRPP.

Single ring

As shown in

Figure 12 , only a single ring exists in the network topology. You only need to define one RRPP

domain.

55

Figure 12 Schematic diagram for a single-ring network

Tangent rings

As shown in Figure 13

, two or more rings exist in the network topology and only one common node exists between rings. You must define an RRPP domain for each ring.

Figure 13 Schematic diagram for a tangent-ring network

Intersecting rings

As shown in

Figure 14

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

56

Figure 14 Schematic diagram for an intersecting-ring network

Dual-homed rings

As shown in

Figure 15

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

Figure 15 Schematic diagram for a dual-homed-ring network

Single-ring load balancing

In a single-ring network, you can achieve load balancing by configuring multiple domains.

As shown in Figure 16

, Ring 1 is configured as the primary ring of both Domain 1 and Domain 2.

Domain 1 and Domain 2 are configured with different protected VLANs. In Domain 1, Device A is configured as the master node of Ring 1. In Domain 2, Device B is configured as the master node of Ring

1. Such configurations enable the ring to block different links based on VLANs and achieve single-ring load balancing.

57

Figure 16 Schematic diagram for a single-ring load balancing network

Intersecting-ring load balancing

In an intersecting-ring network, you can also achieve load balancing by configuring multiple domains.

As shown in

Figure 17 , Ring 1 is the primary ring and Ring 2 is the subring in both Domain 1 and Domain

2. Domain 1 and Domain 2 are configured with different protected VLANs. Device A is configured as the master node of Ring 1 in Domain 1. Device D is configured as the master node of Ring 1 in Domain 2.

Device E is configured as the master node of Ring 2 in both Domain 1 and Domain 2. However, different ports on Device E are blocked in Domain 1 and Domain 2. With the configurations, you can enable traffic from different VLANs to travel over different paths in the subring and primary ring, achieving intersecting-ring load balancing.

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

Protocols and standards

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

58

RRPP configuration task list

You can create RRPP domains based on service planning, specify control VLANs and data VLANs for each RRPP domain, and then determine the ring roles and node roles based on the traffic paths in each

RRPP domain.

RRPP does not have an auto election mechanism, so you must configure each node in the ring network properly for RRPP to monitor and protect the ring network.

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

Task Remarks

Creating an RRPP domain

Required.

Perform this task on all nodes in the RRPP domain.

Configuring control VLANs

Configuring protected VLANs

Configuring RRPP rings

Activating an RRPP domain

Configuring RRPP timers

Configuring RRPP fast detection

Configuring RRPP ports

Configuring RRPP nodes

Enabling fast detection

Configuring fast detection timers

Configuring an RRPP ring group

Required.

Perform this task on all nodes in the RRPP domain.

Required.

Perform this task on all nodes in the RRPP domain.

Required.

Perform this task on all nodes in the RRPP domain.

Required.

Perform this task on all nodes in the RRPP domain.

Required.

Perform this task on all nodes in the RRPP domain.

Optional.

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

Optional.

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

Optional.

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

Optional.

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

Creating an RRPP domain

When creating an RRPP domain, specify a domain ID, which uniquely identifies an RRPP domain. All devices in the same RRPP domain must be configured with the same domain ID.

Make this configuration on devices you want to configure as nodes in the RRPP domain.

59

To create an RRPP domain:

Step Command

1. Enter system view. system-view

2. Create an RRPP domain and enter RRPP domain view. rrpp domain domain-id

Configuring control VLANs

When configuring control VLANs for an RRPP domain, you only need to configure the primary control

VLAN. The system automatically configures the secondary control VLAN, and it uses the primary control

VLAN ID plus 1 as the secondary control VLAN ID. For the control VLAN configuration to succeed, make sure the IDs of the two control VLANs are consecutive and have not been assigned yet.

Configuration guidelines

Before you configure RRPP rings in an RRPP domain, configure the same control VLANs for all nodes in the RRPP domain first.

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

To ensure proper forwarding of RRPPDUs, do not configure the default VLAN of a port accessing an

RRPP ring as the control VLAN, or enable 802.1Q in 802.1Q (QinQ) or VLAN mapping on the control VLANs.

Before configuring RRPP rings for an RRPP domain, you can delete or modify the control VLANs configured for the RRPP domain. However, after configuring RRPP rings for an RRPP domain, you cannot delete or modify the control VLANs of the domain. You can only use the undo control-vlan command to delete a control VLAN.

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

Configuration procedure

To configure control VLANs:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view.

3. Configure the primary control VLAN for the RRPP domain. rrpp domain domain-id control-vlan vlan-id

Configuring protected VLANs

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

60

You can configure protected VLANs through referencing MSTIs. Before configuring protected VLANs, configure the mappings between MSTIs and the VLANs to be protected. (A device operating in PVST mode automatically maps VLANs to MSTIs.) For more information about MSTIs and PVST, see Layer

2—LAN Switching Configuration Guide.

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

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

For more information about the stp region-configuration, instance, vlan-mapping modulo, active region-configuration, and display stp region-configuration commands, see Layer 2—LAN Switching

Command Reference.

To configure protected VLANs:

Step Command

1. Enter system view.

2. Enter MST region view.

3.

7.

Enter RRPP domain view.

8. Configure protected VLANs for the RRPP domain. stp region-configuration

VLAN-to-instance mapping table.

6. Return to system view. system-view

Approach 1:

Configure the

• quit

vlan-list

Approach 2: vlan-mapping modulo modulo

4. Activate MST region configuration manually. active region-configuration

5. Display the currently activated configuration information of the MST region. display stp region-configuration [ |

{ begin | exclude | include }

regular-expression ] rrpp domain domain-id protected-vlan reference-instance

instance-id-list

Remarks

N/A

Not required if the device works in

PVST mode.

Optional.

Use either approach.

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

Not required if the device works in

PVST mode.

Not required if the device works in

PVST mode.

Optional.

Available in any view.

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

Not required if the device works in

PVST mode.

N/A

By default, no protected VLAN is configured for an RRPP domain.

Configuring RRPP rings

This section describes how to configure RRPP rings.

Configuration guidelines

When you configure an RRPP ring, make some configurations on the ports connecting each node to the RRPP ring before configuring the nodes.

61

RRPP ports (connecting devices to an RRPP ring) must be Layer 2 Ethernet interfaces or Layer 2 aggregate interfaces, and they cannot be member ports of any aggregation group, service loopback group, or smart link group.

After configuring a Layer-2 aggregate interface as an RRPP port, you can still assign ports to or remove ports from the aggregation group corresponding to the interface.

Configuring RRPP ports

Follow these guidelines when you configure RRPP ports:

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

For more information about the port link-type trunk, port trunk permit vlan, and undo stp enable commands, see Layer 2—LAN Switching Command Reference.

Do not configure a port accessing an RRPP ring as the destination port of a mirroring group.

Do not configure physical-link-state change suppression time on a port accessing an RRPP ring to accelerate topology convergence. For more information, see the undo link-delay command (Layer

2—LAN Switching Command Reference).

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

To configure RRPP ports:

Remarks

N/A

Step Command

1. Enter system view. system-view

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

interface-number

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

4. Assign the trunk port to the protected VLANs of the RRPP domain. port trunk permit vlan { vlan-id-list

| all }

5. Disable the spanning tree feature. undo stp enable

N/A

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

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

By default, the spanning tree feature is enabled.

Configuring RRPP nodes

If a device carries multiple RRPP rings in an RRPP domain, only one ring can be configured as the primary ring on the device and the role of the device on a subring can only be an edge node or an assistant-edge node.

Specifying a master node

Perform this configuration on a device to be configured as a master node.

To specify a master node:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view. rrpp domain domain-id

62

Step Command

3. Specify the current device as the master node of the ring, and specify the primary port and the secondary port. ring ring-id node-mode master [ primary-port interface-type

interface-number ] [ secondary-port interface-type

interface-number ] level level-value

Specifying a transit node

Perform this configuration on a device to be configured as a transit node.

To specify a transit node:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view. rrpp domain domain-id

3. Specify the current device as a transit node of the ring, and specify the primary port and the secondary port. ring ring-id node-mode transit [ primary-port interface-type

interface-number ] [ secondary-port interface-type

interface-number ] level level-value

Specifying an edge node

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

Perform this configuration on a device to be configured as an edge node.

To specify an edge node:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view.

3. Specify the current device as a master node or transit node of the primary ring, and specify the primary port and the secondary port.

4. Specify the current device as the edge node of a subring, and specify the edge port. rrpp domain domain-id ring ring-id node-mode { master | transit } [ primary-port

interface-type interface-number ] [ secondary-port

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

interface-number ]

Specifying an assistant-edge node

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

Perform this configuration on a device to be configured as an assistant-edge node.

To specify an assistant-edge node:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view. rrpp domain domain-id

63

Step Command

3. Specify the current device as a master node or transit node of the primary ring, and specify the primary port and the secondary port. ring ring-id node-mode { master | transit } [ primary-port

interface-type interface-number ] [ secondary-port

interface-type interface-number ] level level-value

4. Specify the current device as the assistant-edge node of the subring, and specify an edge port. ring ring-id node-mode assistant-edge [ edge-port

interface-type interface-number ]

Activating an RRPP domain

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

Perform this operation on all nodes in the RRPP domain.

To prevent Hello packets of subrings from being looped on the primary ring, enable the primary ring on its master node before enabling the subrings on their separate master nodes. On an edge node or assistant-edge node, enable/disable the primary ring and subrings separately:

Enable the primary ring of an RRPP domain before enabling the subrings of the RRPP domain.

Disable the primary ring of an RRPP domain after disabling all subrings of the RRPP domain.

To activate an RRPP domain:

Step Command

1. Enter system view. system-view

2. Enable RRPP. rrpp enable

3. Enter RRPP domain view. rrpp domain domain-id

4. Enable the specified RRPP ring. ring ring-id enable

Remarks

N/A

By default, RRPP is disabled.

N/A

By default, the specified RRPP ring is disabled.

Configuring RRPP timers

Follow these guidelines when you configure RRPP timers:

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

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

To avoid temporary loops when the primary ring fails in a dual-homed-ring network, make sure the difference between the Fail timer value on the master node of the subring and that on the master node of the primary ring is greater than twice the Hello timer value of the master node of the subring.

To configure RRPP timers:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view. rrpp domain domain-id

Remarks

N/A

N/A

64

Step Command

3. Configure the Hello timer and Fail timer for the RRPP domain. timer hello-timer hello-value fail-timer fail-value

Remarks

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

Configuring RRPP fast detection

Enabling fast detection

Follow these guidelines when you enable fast detection:

Perform this configuration on the master node, edge node, and assistant-edge node in the RRPP domain to be configured.

To configure fast detection on the master node of a subring, make sure the edge node and assistant-edge node of the subring support fast detection. Otherwise, do not configure fast detection on the master node of the subring.

When configuring fast detection in an RRPP domain, enable fast detection first on the edge node, and then on the assistant-edge node. Otherwise, the assistant-edge node may fail to receive

Fast-Edge-Hello packets and erroneously conclude that the master node is faulty.

To enable fast detection:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view. rrpp domain domain-id

3. Enable fast detection. fast-detection enable

Remarks

N/A

N/A

By default, fast detection is disabled.

Configuring fast detection timers

Follow these guidelines when you configure fast detection timers:

Perform this configuration on the master node in the RRPP domain to be configured.

The value of the Fast-Fail timer must be equal to or greater than three times the Fast-Hello timer.

In a dual-homed-ring network, to avoid temporary loops when the primary ring fails, make sure the

Fast-Fail timer value is equal to or greater than six times the timer resolution. Also, make sure the difference between the Fast-Fail timer value on the master node of the subring and that on the master node of the primary ring is greater than twice the Fast-Hello timer value of the master node of the subring.

To configure RRPP fast detection timers:

Step Command

1. Enter system view. system-view

2. Enter RRPP domain view. rrpp domain domain-id

Remarks

N/A

N/A

65

Step Command

3. Configure the Fast-Fail timer. timer fast-fail-timer fast-fail-value

4. Configure the

Fast-Hello timer. timer fast-hello-timer

fast-hello-value

Remarks

Optional.

By default, the Fast-Fail timer is 600 milliseconds.

Optional.

By default, the Fast-Hello timer is 200 milliseconds.

Configuring an RRPP ring group

This section describes how to configure an RRPP ring group.

Configuration guidelines

To reduce Edge-Hello traffic, adopt the RRPP ring group mechanism by assigning subrings with the same edge node/assistant-edge node to an RRPP ring group. An RRPP ring group must be configured on both the edge node and the assistant-edge node, and can only be configured on these two types of nodes.

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

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

Make sure the subrings in an RRPP ring group share the same edge node and assistant-edge node, and the edge node and the assistant edge node have the same SRPTs.

Make sure a device plays the same role on the subrings in an RRPP ring group. The role can be the edge node or the assistant-edge node.

Make sure the RRPP ring group on the edge node and that on the assistant-edge node have the same configurations and activation status.

Make sure all subrings in an RRPP ring group have the same SRPTs. If the SRPTs of these subrings are configured or modified differently, the RRPP ring group cannot operate properly.

Configuration procedure

To configure an RRPP ring group:

Step Command

1. Enter system view. system-view

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

3. Assign the specified subrings to the RRPP ring group. rrpp ring-group ring-group-id domain domain-id ring ring-id-list

Displaying and maintaining RRPP

66

Task Command

Display brief RRPP information. display rrpp brief [ | { begin | exclude | include } regular-expression ]

Display RRPP group configuration information. display rrpp ring-group [ ring-group-id ] [ |

{ begin | exclude | include }

regular-expression ]

Display detailed RRPP information.

Display RRPP statistics.

Clear RRPP statistics. display rrpp verbose domain domain-id [ ring

ring-id ] [ | { begin | exclude | include }

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

ring-id ] [ | { begin | exclude | include }

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

ring-id ]

Remarks

Available in any view.

Available in any view.

Available in any view.

Available in any view.

Available in user view.

RRPP configuration examples

This section provides configuration examples for RRPP.

Single ring configuration example

Networking requirements

As shown in

Figure 18

,

Device A, Device B, Device C, and Device D form RRPP domain 1. Specify the primary control VLAN of RRPP domain 1 as VLAN 4092, and specify that RRPP domain 1 protects VLANs 1 through 30.

Device A, Device B, Device C, and Device D form primary ring 1.

Specify Device A as the master node of primary ring 1, GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port.

Specify Device B, Device C, and Device D as the transit nodes of primary ring 1, their

GigabitEthernet 1/0/1 as the primary port, and GigabitEthernet 1/0/2 as the secondary port.

Figure 18 Network diagram

67

Configuration procedure

1. Configure Device A:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

[DeviceA] stp region-configuration

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

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceA] rrpp domain 1

[DeviceA-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceA-rrpp-domain1] ring 1 enable

[DeviceA-rrpp-domain1] quit

# Enable RRPP.

[DeviceA] rrpp enable

2. Configure Device B:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

[DeviceB] stp region-configuration

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

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

68

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2, disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

[DeviceB-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceB] rrpp domain 1

[DeviceB-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceB-rrpp-domain1] ring 1 enable

[DeviceB-rrpp-domain1] quit

# Enable RRPP.

[DeviceB] rrpp enable

3. Configure Device C in the same way as you configure Device B.

4. Configure Device D in the same way as you configure Device B.

Verifying the configuration

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

Intersecting ring configuration example

Networking requirements

As shown in

Figure 19 ,

Device A, Device B, Device C, Device D, and Device E form RRPP domain 1, VLAN 4092 is the primary control VLAN of RRPP domain 1, and RRPP domain 1 protects VLANs 1 through 30.

Device A, Device B, Device C, and Device D form primary ring 1, and Device B, Device C and

Device E form subring 2.

Device A is the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and

GigabitEthernet 1/0/2 the secondary port.

Device E is the master node of subring 2, with GigabitEthernet 1/0/1 as the primary port and

GigabitEthernet 1/0/2 the secondary port.

69

Device B is the transit node of primary ring 1 and the edge node of subring 2, and GigabitEthernet

1/0/3 is the edge port.

Device C is the transit node of primary ring 1 and the assistant-edge node of subring 1, and

GigabitEthernet 1/0/3 is the edge port.

Device D is the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port and

GigabitEthernet 1/0/2 the secondary port.

Figure 19 Network diagram

Configuration procedure

1. Configure Device A:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

[DeviceA] stp region-configuration

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

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2, disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/2] quit

70

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceA] rrpp domain 1

[DeviceA-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceA-rrpp-domain1] ring 1 enable

[DeviceA-rrpp-domain1] quit

# Enable RRPP.

[DeviceA] rrpp enable

2. Configure Device B:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

[DeviceB] stp region-configuration

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

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1,

GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3. Disable the spanning tree feature, configure the ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

[DeviceB-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/2] quit

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/3] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceB] rrpp domain 1

[DeviceB-rrpp-domain1] control-vlan 4092

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

71

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

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

[DeviceB-rrpp-domain1] ring 1 enable

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

[DeviceB-rrpp-domain1] ring 2 node-mode edge edge-port gigabitethernet 1/0/3

[DeviceB-rrpp-domain1] ring 2 enable

[DeviceB-rrpp-domain1] quit

# Enable RRPP.

[DeviceB] rrpp enable

3. Configure Device C:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

[DeviceC] stp region-configuration

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

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1,

GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3. Disable the spanning tree feature, configure the ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/2] quit

[DeviceC] interface gigabitethernet 1/0/3

[DeviceC-GigabitEthernet1/0/3] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/3] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceC] rrpp domain 1

[DeviceC-rrpp-domain1] control-vlan 4092

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

72

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

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

[DeviceC-rrpp-domain1] ring 1 enable

# Configure Device C as the assistant-edge node of subring 2, with GigabitEthernet 1/0/3 as the edge port, and enable ring 2.

[DeviceC-rrpp-domain1] ring 2 node-mode assistant-edge edge-port gigabitethernet

1/0/3

[DeviceC-rrpp-domain1] ring 2 enable

[DeviceC-rrpp-domain1] quit

# Enable RRPP.

[DeviceC] rrpp enable

4. Configure Device D:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

[DeviceD] stp region-configuration

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

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/2

[DeviceD-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceD-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceD] rrpp domain 1

[DeviceD-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceD-rrpp-domain1] ring 1 enable

[DeviceD-rrpp-domain1] quit

73

# Enable RRPP.

[DeviceD] rrpp enable

5. Configure Device E:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceE> system-view

[DeviceE] vlan 1 to 30

[DeviceE] stp region-configuration

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

[DeviceE-mst-region] active region-configuration

[DeviceE-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceE] interface gigabitethernet 1/0/1

[DeviceE-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceE-GigabitEthernet1/0/1] quit

[DeviceE] interface gigabitethernet 1/0/2

[DeviceE-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceE-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceE] rrpp domain 1

[DeviceE-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceE-rrpp-domain1] ring 2 enable

[DeviceE-rrpp-domain1] quit

# Enable RRPP.

[DeviceE] rrpp enable

Verifying the configuration

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

Dual homed rings configuration example

Networking requirements

As shown in

Figure 20

,

74

Device A through Device H form RRPP domain 1. Specify the primary control VLAN of RRPP domain

1 as VLAN 4092, and specify that RRPP domain 1 protects VLANs 1 through 30.

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

Device A, Device B, and Device F form subring 3. Device C, Device D, and Device G form subring

4. Device C, Device D, and Device H form subring 5.

Specify Device A as the master node of primary ring 1, GigabitEthernet 1/0/1 as the primary port, and GigabitEthernet 1/0/2 as the secondary port. Specify Device E as the master node of subring

2, GigabitEthernet 1/0/1 as the primary port, and GigabitEthernet 1/0/2 as the secondary port.

Specify Device F as the master node of subring 3, GigabitEthernet 1/0/1 as the primary port and

GigabitEthernet 1/0/2 as the secondary port. Specify Device G as the master node of subring 4,

GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port.

Specify Device H as the master node of subring 5, GigabitEthernet 1/0/1 as the primary port, and

GigabitEthernet 1/0/2 as the secondary port.

Specify Device A as the edge node of the connected subrings, its GigabitEthernet 1/0/3 and

GigabitEthernet 1/0/4 as the edge ports. Specify Device D as the transit node of the primary ring and edge node of the connected subrings, its GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 as the edge ports. Specify Device B and Device C as the transit node of the primary ring and assistant-edge nodes of the connected subrings, their GigabitEthernet 1/0/3 and GigabitEthernet

1/0/4 as the edge ports.

NOTE:

Configure the primary and secondary ports on the master nodes properly to make sure other protocols still work normally when data VLANs are denied by the secondary ports.

Figure 20 Network diagram

Device E

Master node

GE1/0/1

G

E1

/0/2

Device A

Edge node & master node

GE1/0/4 GE1/0/2

Ring 2

G

E1/

0/3

GE1/0/1

Domain 1

Device D

Edge node

GE1/0/2

GE1/0/1

Device G

Master node

GE1/0/3

GE1/0

/4

Ring 4

GE1/0/1

G

E1/

0/2

Ring 1

1

GE1/0/

GE1/0/2

Ring 3

GE1/0/

GE1/0/3

4

GE1/0/1

GE1/0/2

GE1/0/2

GE1/0/1

/3

GE1/0

GE1/04

Ring 5

GE1/0

/1

GE1/0/2

Device F

Master node

Device B

Assistant edge node

Device C

Assistant edge node

Device H

Master node

Configuration procedure

1. Configure Device A:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceA> system-view

75

[DeviceA] vlan 1 to 30

[DeviceA] stp region-configuration

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

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through

GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/2] quit

[DeviceA] interface gigabitethernet 1/0/3

[DeviceA-GigabitEthernet1/0/3] undo link-delay

[DeviceA-GigabitEthernet1/0/3] undo stp enable

[DeviceA-GigabitEthernet1/0/3] port link-type trunk

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

[DeviceA-GigabitEthernet1/0/3] quit

[DeviceA] interface gigabitethernet 1/0/4

[DeviceA-GigabitEthernet1/0/4] undo link-delay

[DeviceA-GigabitEthernet1/0/4] undo stp enable

[DeviceA-GigabitEthernet1/0/4] port link-type trunk

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

[DeviceA-GigabitEthernet1/0/4] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceA] rrpp domain 1

[DeviceA-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceA-rrpp-domain1] ring 1 enable

# Configure Device A as the edge node of subring 2, with GigabitEthernet 1/0/4 as the edge port, and enable subring 2.

[DeviceA-rrpp-domain1] ring 2 node-mode edge edge-port gigabitethernet 1/0/4

[DeviceA-rrpp-domain1] ring 2 enable

# Configure Device A as the edge node of subring 3, with GigabitEthernet 1/0/3 as the edge port, and enable subring 3.

76

[DeviceA-rrpp-domain1] ring 3 node-mode edge edge-port gigabitethernet 1/0/3

[DeviceA-rrpp-domain1] ring 3 enable

[DeviceA-rrpp-domain1] quit

# Enable RRPP.

[DeviceA] rrpp enable

2. Configure Device B:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

[DeviceB] stp region-configuration

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

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through

GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

[DeviceB-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/2] quit

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/3] quit

[DeviceB] interface gigabitethernet 1/0/4

[DeviceB-GigabitEthernet1/0/4] undo link-delay

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

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

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

[DeviceB-GigabitEthernet1/0/4] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceB] rrpp domain 1

[DeviceB-rrpp-domain1] control-vlan 4092

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

77

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

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

[DeviceB-rrpp-domain1] ring 1 enable

# Configure Device B as the assistant-edge node of subring 2, with GigabitEthernet 1/0/4 as the edge port, and enable subring 2.

[DeviceB-rrpp-domain1] ring 2 node-mode assistant-edge edge-port gigabitethernet

1/0/4

[DeviceB-rrpp-domain1] ring 2 enable

# Configure Device B as the assistant-edge node of subring 3, with GigabitEthernet 1/0/3 as the edge port, and enable subring 3.

[DeviceB-rrpp-domain1] ring 3 node-mode assistant-edge edge-port gigabitethernet

1/0/3

[DeviceB-rrpp-domain1] ring 3 enable

[DeviceB-rrpp-domain1] quit

# Enable RRPP.

[DeviceB] rrpp enable

3. Configure Device C:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

[DeviceC] stp region-configuration

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

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through

GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/2] quit

[DeviceC] interface gigabitethernet 1/0/3

[DeviceC-GigabitEthernet1/0/3] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/3] quit

78

[DeviceC] interface gigabitethernet 1/0/4

[DeviceC-GigabitEthernet1/0/4] undo link-delay

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

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

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

[DeviceC-GigabitEthernet1/0/4] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceC] rrpp domain 1

[DeviceC-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceC-rrpp-domain1] ring 1 enable

# Configure Device C as the assistant-edge node of subring 4, with GigabitEthernet 1/0/3 as the edge port, and enable subring 4.

[DeviceC-rrpp-domain1] ring 4 node-mode assistant-edge edge-port gigabitethernet

1/0/3

[DeviceC-rrpp-domain1] ring 4 enable

# Configure Device C as the assistant-edge node of subring 5, with GigabitEthernet 1/0/4 as the edge port, and enable subring 5.

[DeviceC-rrpp-domain1] ring 5 node-mode assistant-edge edge-port gigabitethernet

1/0/4

[DeviceC-rrpp-domain1] ring 5 enable

[DeviceC-rrpp-domain1] quit

# Enable RRPP.

[DeviceC] rrpp enable

4. Configure Device D:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

[DeviceD] stp region-configuration

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

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 through

GigabitEthernet 1/0/4. Disable the spanning tree feature, configure the four ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceD-GigabitEthernet1/0/1] quit

79

[DeviceD] interface gigabitethernet 1/0/2

[DeviceD-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceD-GigabitEthernet1/0/2] quit

[DeviceD] interface gigabitethernet 1/0/3

[DeviceD-GigabitEthernet1/0/3] undo link-delay

[DeviceD-GigabitEthernet1/0/3] undo stp enable

[DeviceD-GigabitEthernet1/0/3] port link-type trunk

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

[DeviceD-GigabitEthernet1/0/3] quit

[DeviceD] interface gigabitethernet 1/0/4

[DeviceD-GigabitEthernet1/0/4] undo link-delay

[DeviceD-GigabitEthernet1/0/4] undo stp enable

[DeviceD-GigabitEthernet1/0/4] port link-type trunk

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

[DeviceD-GigabitEthernet1/0/4] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceD] rrpp domain 1

[DeviceD-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceD-rrpp-domain1] ring 1 enable

# Configure Device D as the edge node of subring 4, with GigabitEthernet 1/0/3 as the edge port, and enable subring 4.

[DeviceD-rrpp-domain1] ring 4 node-mode edge edge-port gigabitethernet 1/0/3

[DeviceD-rrpp-domain1] ring 4 enable

# Configure Device D as the edge node of subring 5, with GigabitEthernet 1/0/4 as the edge port, and enable subring 5.

[DeviceD-rrpp-domain1] ring 5 node-mode edge edge-port gigabitethernet 1/0/4

[DeviceD-rrpp-domain1] ring 5 enable

[DeviceD-rrpp-domain1] quit

# Enable RRPP.

[DeviceD] rrpp enable

5. Configure Device E:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceE> system-view

[DeviceE] vlan 1 to 30

[DeviceE] stp region-configuration

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

[DeviceE-mst-region] active region-configuration

80

[DeviceE-mst-region] quit

# Cancel the physical state change suppression interval setting GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceE] interface gigabitethernet 1/0/1

[DeviceE-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceE-GigabitEthernet1/0/1] quit

[DeviceE] interface gigabitethernet 1/0/2

[DeviceE-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceE-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceE] rrpp domain 1

[DeviceE-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceE-rrpp-domain1] ring 2 enable

[DeviceE-rrpp-domain1] quit

# Enable RRPP.

[DeviceE] rrpp enable

6. Configure Device F:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceF> system-view

[DeviceF] vlan 1 to 30

[DeviceF] stp region-configuration

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

[DeviceF-mst-region] active region-configuration

[DeviceF-mst-region] quit

# Cancel the physical state change suppression interval setting GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceF] interface gigabitethernet 1/0/1

[DeviceF-GigabitEthernet1/0/1] undo link-delay

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

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

[DeviceF-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30

[DeviceF-GigabitEthernet1/0/1] quit

81

[DeviceF] interface gigabitethernet 1/0/2

[DeviceF-GigabitEthernet1/0/2] undo link-delay

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

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

[DeviceF-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30

[DeviceF-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceF] rrpp domain 1

[DeviceF-rrpp-domain1] control-vlan 4092

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

# Configure Device F as the master node of subring 3, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 3.

[DeviceF-rrpp-domain1] ring 3 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1

[DeviceF-rrpp-domain1] ring 3 enable

[DeviceF-rrpp-domain1] quit

# Enable RRPP.

[DeviceF] rrpp enable

7. Configure Device G:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceG> system-view

[DeviceG] vlan 1 to 30

[DeviceG] stp region-configuration

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

[DeviceG-mst-region] active region-configuration

[DeviceG-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceG] interface gigabitethernet 1/0/1

[DeviceG-GigabitEthernet1/0/1] undo link-delay

[DeviceG-GigabitEthernet1/0/1] undo stp enable

[DeviceG-GigabitEthernet1/0/1] port link-type trunk

[DeviceG-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30

[DeviceG-GigabitEthernet1/0/1] quit

[DeviceG] interface gigabitethernet 1/0/2

[DeviceG-GigabitEthernet1/0/2] undo link-delay

[DeviceG-GigabitEthernet1/0/2] undo stp enable

[DeviceG-GigabitEthernet1/0/2] port link-type trunk

[DeviceG-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30

[DeviceG-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceG] rrpp domain 1

[DeviceG-rrpp-domain1] control-vlan 4092

82

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

# Configure Device G as the master node of subring 4, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 4.

[DeviceG-rrpp-domain1] ring 4 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1

[DeviceG-rrpp-domain1] ring 4 enable

[DeviceG-rrpp-domain1] quit

# Enable RRPP.

[DeviceG] rrpp enable

8. Configure Device H:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceH> system-view

[DeviceH] vlan 1 to 30

[DeviceH] stp region-configuration

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

[DeviceH-mst-region] active region-configuration

[DeviceH-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceH] interface gigabitethernet 1/0/1

[DeviceH-GigabitEthernet1/0/1] undo link-delay

[DeviceH-GigabitEthernet1/0/1] undo stp enable

[DeviceH-GigabitEthernet1/0/1] port link-type trunk

[DeviceH-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30

[DeviceH-GigabitEthernet1/0/1] quit

[DeviceH] interface gigabitethernet 1/0/2

[DeviceH-GigabitEthernet1/0/2] undo link-delay

[DeviceH-GigabitEthernet1/0/2] undo stp enable

[DeviceH-GigabitEthernet1/0/2] port link-type trunk

[DeviceH-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30

[DeviceH-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceH] rrpp domain 1

[DeviceH-rrpp-domain1] control-vlan 4092

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

# Configure Device H as the master node of subring 5, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 5.

[DeviceH-rrpp-domain1] ring 5 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1

[DeviceH-rrpp-domain1] ring 5 enable

[DeviceH-rrpp-domain1] quit

# Enable RRPP.

[DeviceH] rrpp enable

83

Verifying the configuration

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

Load balanced intersecting-ring configuration example

Networking requirements

As shown in

Figure 21 ,

Device A, Device B, Device C, Device D, and Device F form RRPP domain 1, and VLAN 100 is the primary control VLAN of the RRPP domain.

{

Device A is the master node of the primary ring, Ring 1.

{

{

Device D is the transit node of Ring 1.

Device F is the master node of the subring Ring 3.

{

{

Device C is the edge node of the subring Ring 3.

Device B is the assistant-edge node of the subring Ring 3.

Device A, Device B, Device C, Device D, and Device E form RRPP domain 2, and VLAN 105 is the primary control VLAN of the RRPP domain.

{

{

{

{

Device A is the master node of the primary ring, Ring 1.

Device D is the transit node of Ring 1.

Device E is the master node of the subring Ring 2.

Device C is the edge node of the subring Ring 2.

{

Device B is the assistant-edge node of the subring Ring 2.

Specify VLAN 11 as the protected VLAN of domain 1, and VLAN 12 the protected VLAN of domain

2. You can implement VLAN-based load balancing on Ring 1.

Ring 2 has the same edge node and assistant-edge node, and the two subrings have the same

SRPTs, so you can add Ring 2 and Ring 3 to the RRPP ring group to reduce Edge-Hello traffic.

Figure 21 Network diagram

Device A

Master node

Domain 2

GE1/0/1

Device B

Assistant edge node

GE1/0/1

GE1/0/1

GE1/0/3

GE1/0/4

Ring 2

GE1/0/2 GE1/0/2

Ring 1

GE1/0/2

Device E

Master node

Device D

Transit node

GE1/0/2 GE1/0/1

GE1/0/3

GE1/0/1

GE1/0/2

Device C

Edge node

GE1/0/4

Ring 3

GE1/0/1

GE1/0/2

Device F

Master node

Domain 1

84

Configuration procedure

1. Configure Device A:

# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.

<DeviceA> system-view

[DeviceA] vlan 11 to 12

[DeviceA] stp region-configuration

[DeviceA-mst-region] instance 1 vlan 11

[DeviceA-mst-region] instance 2 vlan 12

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN

11 as their default VLAN.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] undo link-delay

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

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

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

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

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

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] undo link-delay

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

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

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

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

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

[DeviceA-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceA] rrpp domain 1

[DeviceA-rrpp-domain1] control-vlan 100

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

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

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

[DeviceA-rrpp-domain1] ring 1 enable

[DeviceA-rrpp-domain1] quit

# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceA] rrpp domain 2

[DeviceA-rrpp-domain2] control-vlan 105

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

85

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

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

[DeviceA-rrpp-domain2] ring 1 enable

[DeviceA-rrpp-domain2] quit

# Enable RRPP.

[DeviceA] rrpp enable

2. Configure Device B:

# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.

<DeviceB> system-view

[DeviceB] vlan 11 to 12

[DeviceB] stp region-configuration

[DeviceB-mst-region] instance 1 vlan 11

[DeviceB-mst-region] instance 2 vlan 12

[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN

11 as their default VLAN.

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo link-delay

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

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

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

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

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

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

[DeviceB-GigabitEthernet1/0/2] undo link-delay

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

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

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

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

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

[DeviceB-GigabitEthernet1/0/2] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/3.

Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from

VLAN 1, assign it to VLAN 12, and configure VLAN 12 as its default VLAN.

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] undo link-delay

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

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

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

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

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

86

[DeviceB-GigabitEthernet1/0/3] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/4.

Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from

VLAN 1, assign it to VLAN 11, and configure VLAN 11 as its default VLAN.

[DeviceB] interface gigabitethernet 1/0/4

[DeviceB-GigabitEthernet1/0/4] undo link-delay

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

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

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

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

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

[DeviceB-GigabitEthernet1/0/4] quit

# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceB] rrpp domain 1

[DeviceB-rrpp-domain1] control-vlan 100

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

# Configure Device B as a transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet

1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.

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

[DeviceB-rrpp-domain1] ring 1 enable

# Configure Device B as the assistant-edge node of subring 3 in RRPP domain 1, with

GigabitEthernet 1/0/4 as the edge port, and enable subring 3.

[DeviceB-rrpp-domain1] ring 3 node-mode assistant-edge edge-port gigabitethernet

1/0/4

[DeviceB-rrpp-domain1] ring 3 enable

[DeviceB-rrpp-domain1] quit

# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceB] rrpp domain 2

[DeviceB-rrpp-domain2] control-vlan 105

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

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

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

[DeviceB-rrpp-domain2] ring 1 enable

# Configure Device B as the assistant-edge node of subring 2 in RRPP domain 2, with

GigabitEthernet 1/0/3 as the edge port, and enable subring 2.

[DeviceB-rrpp-domain2] ring 2 node-mode assistant-edge edge-port gigabitethernet

1/0/3

[DeviceB-rrpp-domain2] ring 2 enable

[DeviceC-rrpp-domain2] quit

# Enable RRPP.

[DeviceB] rrpp enable

3. Configure Device C:

87

# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 11 to 12

[DeviceC] stp region-configuration

[DeviceC-mst-region] instance 1 vlan 11

[DeviceC-mst-region] instance 2 vlan 12

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN

11 as their default VLAN.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] undo link-delay

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

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

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

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

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

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] undo link-delay

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

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

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

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

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

[DeviceC-GigabitEthernet1/0/2] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/3.

Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from

VLAN 1, assign it to VLAN 12, and configure VLAN 12 as its default VLAN.

[DeviceC] interface gigabitethernet 1/0/3

[DeviceC-GigabitEthernet1/0/3] undo link-delay

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

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

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

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

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

[DeviceC-GigabitEthernet1/0/3] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/4.

Disable the spanning tree feature, and configure the port as a trunk port. Remove the port from

VLAN 1, assign it to VLAN 11, and configure VLAN 11 as its default VLAN.

[DeviceC] interface gigabitethernet 1/0/4

[DeviceC-GigabitEthernet1/0/4] undo link-delay

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

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

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

88

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

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

[DeviceC-GigabitEthernet1/0/4] quit

# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceC] rrpp domain 1

[DeviceC-rrpp-domain1] control-vlan 100

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

# Configure Device C as the transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet

1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.

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

[DeviceC-rrpp-domain1] ring 1 enable

# Configure Device C as the edge node of subring 3 in RRPP domain 1, with GigabitEthernet

1/0/4 as the edge port, and enable subring 3.

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

[DeviceC-rrpp-domain1] ring 3 enable

[DeviceC-rrpp-domain1] quit

# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceC] rrpp domain 2

[DeviceC-rrpp-domain2] control-vlan 105

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

# Configure Device C as the transit node of primary ring 1 in RRPP domain 2, with GigabitEthernet

1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.

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

[DeviceC-rrpp-domain2] ring 1 enable

# Configure Device C as the edge node of subring 2 in RRPP domain 2, with GigabitEthernet

1/0/3 as the edge port, and enable subring 2.

[DeviceC-rrpp-domain2] ring 2 node-mode edge edge-port gigabitethernet 1/0/3

[DeviceC-rrpp-domain2] ring 2 enable

[DeviceC-rrpp-domain2] quit

# Enable RRPP.

[DeviceC] rrpp enable

4. Configure Device D:

# Create VLANs 11 and 12, map VLAN 11 to MSTI 1 and VLAN 12 to MSTI 2, and activate MST region configuration.

<DeviceD> system-view

[DeviceD] vlan 11 to 12

[DeviceD] stp region-configuration

[DeviceD-mst-region] instance 1 vlan 11

[DeviceD-mst-region] instance 2 vlan 12

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk

89

ports. Remove the two ports from VLAN 1, assign them to VLANs 11 and 12, and configure VLAN

11 as their default VLAN.

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] undo link-delay

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

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

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

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

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

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/2

[DeviceD-GigabitEthernet1/0/2] undo link-delay

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

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

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

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

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

[DeviceD-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN of RRPP domain 1, and configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.

[DeviceD] rrpp domain 1

[DeviceD-rrpp-domain1] control-vlan 100

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

# Configure Device D as the transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet

1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.

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

[DeviceD-rrpp-domain1] ring 1 enable

[DeviceD-rrpp-domain1] quit

# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RRPP domain 2, and configure the VLAN mapped to MSTI 2 as the protected VLAN of RRPP domain 2.

[DeviceD] rrpp domain 2

[DeviceD-rrpp-domain2] control-vlan 105

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

# Configure Device D as the transit node of primary ring 1 in RRPP domain 2, with GigabitEthernet

1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.

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

[DeviceD-rrpp-domain2] ring 1 enable

[DeviceD-rrpp-domain2] quit

# Enable RRPP.

[DeviceD] rrpp enable

5. Configure Device E:

# Create VLAN 12, map VLAN 12 to MSTI 2, and activate MST region configuration.

<DeviceE> system-view

[DeviceE] vlan 12

[DeviceE-vlan12] quit

90

[DeviceE] stp region-configuration

[DeviceE-mst-region] instance 2 vlan 12

[DeviceE-mst-region] active region-configuration

[DeviceE-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLAN 12, and configure VLAN 12 as their default VLAN.

[DeviceE] interface gigabitethernet 1/0/1

[DeviceE-GigabitEthernet1/0/1] undo link-delay

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

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

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

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

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

[DeviceE-GigabitEthernet1/0/1] quit

[DeviceE] interface gigabitethernet 1/0/2

[DeviceE-GigabitEthernet1/0/2] undo link-delay

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

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

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

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

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

[DeviceE-GigabitEthernet1/0/2] quit

# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN, and configure the

VLAN mapped to MSTI 2 as the protected VLAN.

[DeviceE] rrpp domain 2

[DeviceE-rrpp-domain2] control-vlan 105

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

# Configure Device E as the master mode of subring 2 in RRPP domain 2, with GigabitEthernet

1/0/2 as the primary port and GigabitEthernet 1/0/1 as the secondary port, and enable ring 2.

[DeviceE-rrpp-domain2] ring 2 node-mode master primary-port gigabitethernet 1/0/2 secondary-port gigabitethernet 1/0/1 level 1

[DeviceE-rrpp-domain2] ring 2 enable

[DeviceE-rrpp-domain2] quit

# Enable RRPP.

[DeviceE] rrpp enable

6. Configure Device F:

# Create VLAN 11, map VLAN 11 to MSTI 1, and activate MST region configuration.

<DeviceF> system-view

[DeviceF] vlan 11

[DeviceF-vlan11] quit

[DeviceF] stp region-configuration

[DeviceF-mst-region] instance 1 vlan 11

[DeviceF-mst-region] active region-configuration

[DeviceF-mst-region] quit

91

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, and configure the two ports as trunk ports. Remove the two ports from VLAN 1, assign them to VLAN 11, and configure VLAN 11 as their default VLAN.

[DeviceF] interface gigabitethernet 1/0/1

[DeviceF-GigabitEthernet1/0/1] undo link-delay

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

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

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

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

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

[DeviceF-GigabitEthernet1/0/1] quit

[DeviceF] interface gigabitethernet 1/0/2

[DeviceF-GigabitEthernet1/0/2] undo link-delay

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

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

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

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

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

[DeviceF-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN, and configure the

VLAN mapped to MSTI 1 as the protected VLAN.

[DeviceF] rrpp domain 1

[DeviceF-rrpp-domain1] control-vlan 100

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

# Configure Device F as the master node of subring 3 in RRPP domain 1, with GigabitEthernet

1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring

3.

[DeviceF-rrpp-domain1] ring 3 node-mode master primary-port gigabitethernet 1/0/1 secondary-port gigabitethernet 1/0/2 level 1

[DeviceF-rrpp-domain1] ring 3 enable

[DeviceF-rrpp-domain1] quit

# Enable RRPP.

[DeviceF] rrpp enable

7. Configure RRPP ring group settings on Device B and Device C:

# Create RRPP ring group 1 on Device B, and add subrings 2 and 3 to the RRPP ring group.

[DeviceB] rrpp ring-group 1

[DeviceB-rrpp-ring-group1] domain 2 ring 2

[DeviceB-rrpp-ring-group1] domain 1 ring 3

# Create RRPP ring group 1 on Device C, and add subrings 2 and 3 to the RRPP ring group.

[DeviceC] rrpp ring-group 1

[DeviceC-rrpp-ring-group1] domain 2 ring 2

[DeviceC-rrpp-ring-group1] domain 1 ring 3

Verifying the configuration

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

92

Fast detection configuration example

Network requirements

As shown in

Figure 22 ,

Device A, Device B, Device C, and Device D form RRPP domain 1. VLAN 4092 is the primary control VLAN of RRPP domain 1, and RRPP domain 1 protects VLANs 1 through 30.

Device A is the master node and supports RRPP fast detection. Device D is a transit node. Device B and Device C do not support RRPP.

When the link between Device B and Device C fails, the link failure cannot be detected by the master node in a timely manner, because neither Device B nor Device C supports RRPP. Configure RRPP fast detection to implement fast link switchover even when the link between Device B and Device C fails.

Figure 22 Network diagram

Configuration procedure

1. Configure Device A:

# Create VLANs 1 through 30, map the VLANs to MSTI 1, and activate MST region configuration.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

[DeviceA] stp region-configuration

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

[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] undo link-delay

93

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

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

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

[DeviceA-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceA] rrpp domain 1

[DeviceA-rrpp-domain1] control-vlan 4092

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

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

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

[DeviceA-rrpp-domain1] ring 1 enable

# Enable fast detection, and set the Fast-Hello timer and Fast-Fail timer to 100 milliseconds and

300 milliseconds respectively. Set the Fast-Fail timer equal to or greater than three times the

Fast-Hello timer value. Otherwise, the configuration fails.

[DeviceA-rrpp-domain1] fast-detection enable

[DeviceA-rrpp-domain1] timer fast-hello-timer 100

[DeviceA-rrpp-domain1] timer fast-fail-timer 300

[DeviceA-rrpp-domain1] quit

# Enable the RRPP protocol.

[DeviceA] rrpp enable

2. Configure Device B:

# Create VLANs 4092 and 4093.

<DeviceB> system-view

[DeviceB] vlan 4092 to 4093

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30, 4092, and 4093.

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo link-delay

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

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

[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30 4092 4093

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

[DeviceB-GigabitEthernet1/0/2] undo link-delay

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

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

[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30 4092 4093

3. Configure Device C:

# Create VLANs 4092 and 4093.

<DeviceC> system-view

[DeviceC] vlan 4092 to 4093

94

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30, 4092, and 4093.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] undo link-delay

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

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

[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30 4092 4093

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] undo link-delay

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

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

[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 30 4092 4093

4. Configure Device D:

# Create VLANs 1 through 30, map the VLANs to MSTI 1, and activate MST region configuration.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

[DeviceD] stp region-configuration

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

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Cancel the physical state change suppression interval setting on GigabitEthernet 1/0/1 and

GigabitEthernet 1/0/2. Disable the spanning tree feature, configure the two ports as trunk ports, and assign them to VLANs 1 through 30.

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] undo link-delay

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

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

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

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/2

[DeviceD-GigabitEthernet1/0/2] undo link-delay

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

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

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

[DeviceD-GigabitEthernet1/0/2] quit

# Create RRPP domain 1, configure VLAN 4092 as the primary VLAN of RRPP domain 1, and configure the VLANs mapped to MSTI 1 as the protected VLANs of RRPP domain 1.

[DeviceD] rrpp domain 1

[DeviceD-rrpp-domain1] control-vlan 4092

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

# Configure Device D as a transit node of the primary ring Ring 1, with GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable Ring 1.

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

[DeviceD-rrpp-domain1] ring 1 enable

[DeviceD-rrpp-domain1] quit

95

# Enable the RRPP protocol.

[DeviceD] rrpp enable

Verifying the configuration

Use the display command to view RRPP configuration and operational information on Device A and

Device D.

Troubleshooting

This section provides troubleshooting advice.

Symptom

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

Analysis

The following reasons may apply:

RRPP is not enabled on some nodes in the RRPP ring.

The domain ID or primary control VLAN ID is not the same for the nodes in the RRPP ring.

Some ports are abnormal.

Solution

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

Use the display rrpp brief command to examine whether the domain ID and primary control VLAN

ID are the same for all nodes. If not, set the same domain ID and primary control VLAN ID for the nodes.

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

Use the debugging rrpp command on each node to examine whether a port receives or transmits

Hello packets. If not, Hello packets are lost.

96

Configuring Smart Link

This chapter describes how to configure Smart Link.

Overview

To avoid single-point failures and guarantee network reliability, downstream devices are usually dual-homed to upstream devices, as shown in

Figure 23

.

Figure 23 Dual-uplink network diagram

Core network

Device B

Port3

Po rt1

Por t2

Port3

Po rt1

Device A

Por t2

Por t1

Po rt2

Port3

Device E

Master link

Slave link

Smart link group

Device C

Port1

Port3

Port2 Port2

Port3

Port1

Device D

User network User network

To remove network loops on a dual-homed network, you can use a spanning tree protocol or RRPP.

However, convergence time is long with STP, which makes it unsuitable for users who have high demand on convergence speed. RRPP can meet demand on convergence speed, but it involves complicated networking and configurations, and is mainly used in ring-shaped networks.

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

For more information about RRPP, see " Configuring RRPP ."

Smart Link addresses the slow convergence issue with STP. It provides link redundancy as well as fast convergence in a dual uplink network, allowing the backup link to take over quickly when the primary link fails. Smart Link has the following features:

Dedicated to dual-uplink networks

97

Subsecond convergence

Easy to configure

Terminology

The following terms are used in Smart Link configuration.

Smart link group

A smart link group consists of only two member ports: the primary port and the secondary port. Only one port is active for forwarding at a time, and the other port is blocked and in standby state. When link failure occurs on the active port due to port shutdown, or the presence of a unidirectional link, for example, the standby port becomes active and takes over, and the original active port transits to blocked state.

As shown in Figure 23

, Port1 and Port2 of Device C and Port1 and Port2 of Device D each form a smart link group, with Port1 active and Port2 standby.

Primary/secondary port

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

Figure 23

, you can configure Port1 of Device C and Device D as primary ports, and Port2 of

Device C and Device D secondary ports.

Primary/secondary link

The link that connects the primary port in a smart link group is the primary link; the link that connects the secondary port is the secondary link.

Flush message

Flush messages are used by a smart link group to notify other devices to refresh their MAC address forwarding entries and ARP/ND entries when link switchover occurs in the smart link group. Flush messages are common multicast data packets, and are dropped by a blocked receiving port.

Protected VLAN

A smart link group controls the forwarding state of some data VLANs (protected VLANs). Different smart link groups on a port control different protected VLANs. The state of the port in a protected VLAN is determined by the state of the port in the smart link group.

Transmit control VLAN

The transmit control VLAN is used for transmitting flush messages. When link switchover occurs, the devices (such as Device C and Device D in

Figure 23

) broadcast flush messages within the transmit control VLAN.

Receive control VLAN

The receive control VLAN is used for receiving and processing flush messages. When link switchover

occurs, the devices (such as Device A, Device B, and Device E in Figure 23

) receive and process flush messages in the receive control VLAN and refresh their MAC address forwarding entries and ARP/ND entries.

98

How Smart Link works

This section explains how Smart Link works in further detail.

Link backup mechanism

As shown in

Figure 23

, the link on Port1 of Device C is the primary link, and the link on Port2 of Device

C is the secondary link. Typically, Port1 is in forwarding state, and Port2 is in standby state. When the primary link fails, Port2 takes over to forward traffic and Port1 is blocked and placed in standby state.

When a port switches to the forwarding state, the system outputs log information to notify the user of the port state change.

Topology change mechanism

Link switchover can outdate the MAC address forwarding entries and ARP/ND entries on all devices, so a forwarding entry update mechanism is needed to ensure proper transmission. The following update mechanisms are provided:

Uplink traffic-triggered MAC address learning—Update is triggered by uplink traffic. This mechanism applies to environments with network devices that do not support Smart Link, including devices of other vendors.

Flush update—A Smart Link-enabled device updates its information by transmitting flush messages over the backup link to its upstream devices. This mechanism requires the upstream devices to be capable of recognizing Smart Link flush messages to update their MAC address forwarding entries and ARP/ND entries.

Role preemption mechanism

As shown in Figure 23

, the link on Port1 of Device C is the primary link and the link on Port2 of Device

C is the secondary link. Once the primary link fails, Port1 is automatically blocked and placed in standby state, and Port2 takes over to forward traffic.

When the primary link recovers:

If the smart link group is not configured with role preemption, Port1 stays blocked, and no link switchover occurs, ensuring traffic stability. Port1 does not transition to forwarding state until the next link switchover occurs.

If the smart link group is configured with role preemption, Port1 takes over to forward traffic as soon as its link recovers, and Port2 is automatically blocked and placed in standby state.

Load sharing mechanism

A ring network can carry traffic of multiple VLANs. Smart Link can forward traffic from different VLANs in different smart link groups for load sharing.

To implement load sharing, assign a port to multiple smart link groups (each configured with different protected VLANs). Make sure that the state of the port is different in these smart link groups. In this way, traffic of different VLANs can be forwarded along different paths.

You can configure protected VLANs for a smart link group by referencing MSTIs.

Smart Link collaboration mechanisms

Configure a monitoring function to monitor the uplink ports of upstream devices and trigger Smart Link to perform the switchover when faults occur.

99

Collaboration between Smart Link and Monitor Link

Smart Link cannot sense when faults occur on the uplink of the upstream devices or when faults are cleared. To monitor the uplink status of the upstream devices, configure the Monitor Link function to monitor the uplink ports of the upstream devices. Monitor Link adapts the up/down state of downlink ports to the up/down state of uplink ports, triggering Smart Link to perform link switchover on the downstream device.

For more information about Monitor Link, see " Configuring Monitor Link ."

Collaboration between Smart Link and CC of CFD

When faults such as unidirectional link, misconnected fibers, or packet loss occur on the intermediate devices or network paths, or when faults are cleared, Smart Link cannot sense this on its own. To examine the link status, Smart Link ports must use link detection protocols. When a fault is detected or cleared, the link detection protocols inform Smart Link to switch over the links.

With the collaboration between Smart Link and the Continuity Check function of CFD configured, CFD notifies the ports of fault detection events on the basis of detection VLANs and detection ports. A port responds to a continuity check event only when the control VLAN of the smart link group to which it belongs matches the detection VLAN.

For more information about the CC function of CFD, see "

Configuring CFD

."

Smart Link configuration task list

Task

Configuring a Smart Link device

Configuring protected VLANs for a smart link group

Configuring member ports for a smart link group

Configuring role preemption for a smart link group

Enabling the sending of flush messages

Remarks

Required.

Required.

Optional.

Optional.

Configuring the collaboration between Smart Link and CC of CFD

Optional.

Configuring an associated device

Enabling the receiving of flush messages

Required.

Configuring a Smart Link device

A Smart Link device is a device that supports Smart Link and is configured with a smart link group and a transmit control VLAN to transmit flush messages. Device C and Device D in

Figure 23

are two examples of Smart Link devices.

Configuration prerequisites

Before you configure a Smart Link device, complete the following tasks:

Shut down a port to prevent loops before configuring a port as a smart link group member. You can bring up the port only after completing the smart link group configuration.

Disable STP and RRPP on the ports you want to add to the smart link group, making sure the ports are not member ports of any aggregation group or service loopback group.

100

NOTE:

A loop may occur on the network during the time when STP is disabled but Smart Link has not yet taken effect on a port.

Configuring protected VLANs for a smart link group

Configure protected VLANs for a smart link group by referencing MSTIs. Before configuring the protected

VLANs, configure the mappings between MSTIs and the VLANs to be protected. (A device operating in

PVST mode automatically maps VLANs to MSTIs.) For more information about MSTIs and PVST, see Layer

2—LAN Switching Configuration Guide.

For more information about the stp region-configuration, instance, vlan-mapping modulo, active region-configuration, and display stp region-configuration commands, see Layer 2—LAN Switching

Command Reference.

To configure the protected VLANs for a smart link group:

Step Command

1. Enter system view. system-view

2. Enter MST region view.

3. Configure the

VLAN-to-instance mapping table.

Approach 1:

• instance instance-id vlan

vlan-list

Approach 2: vlan-mapping modulo

modulo

4. Activate MST region configuration manually. active region-configuration

5. Display the currently activated configuration information of the MST region. display stp region-configuration

[ | { begin | exclude | include }

regular-expression ]

6. Return to system view. stp region-configuration quit

Remarks

N/A

Not required if the device operates in PVST mode.

Optional.

Use either approach.

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

Not required if the device operates in PVST mode.

Not required if the device operates in PVST mode.

Optional.

Available in any view.

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

Not required if the device operates in PVST mode.

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

8. Configure protected VLANs for the smart link group. smart-link group group-id protected-vlan reference-instance

instance-id-list

N/A

By default, no protected VLAN is configured for a smart link group.

Configuring member ports for a smart link group

You can configure member ports for a smart link group either in smart link group view or in interface view.

The configurations made in these two views have the same effect.

101

In smart link group view

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

Step Command

1. Enter system view. system-view

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

3. Configure member ports for a smart link group. port interface-type interface-number { master | slave }

In interface view

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

Step Command

1. Enter system view. system-view

2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view. interface interface-type interface-number

3. Configure member ports for a smart link group. port smart-link group group-id { master | slave }

Configuring role preemption for a smart link group

Step Command

1. Enter system view. system-view

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

Remarks

N/A

N/A

3. Enable role preemption. preemption mode role

4. Configure the preemption delay. preemption delay delay-time

By default, role preemption is disabled.

Optional.

The default is 1 second.

The preemption delay configuration takes effect only after role preemption is enabled.

Enabling the sending of flush messages

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

The control VLAN configured for a smart link group must be different than that configured for any other smart link group.

Make sure the configured control VLAN already exists, and assign the smart link group member ports to the control VLAN.

The control VLAN of a smart link group should also be one of its protected VLANs. Do not remove the control VLAN. Otherwise, flush messages cannot be sent properly.

To enable the sending of flush messages:

102

Step Command

1. Enter system view. system-view

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

Remarks

N/A

N/A

3. Enable flush update in the specified control VLAN. flush enable [ control-vlan

vlan-id ]

Optional.

By default, flush update is enabled, and

VLAN 1 is the control VLAN.

Configuring the collaboration between Smart Link and CC of

CFD

When you configure the collaboration between Smart Link and the CC function of CFD on a smart link member port, make sure the control VLAN of the smart link group to which the port belongs matches the detection VLAN of the CC function of CFD.

To configure the collaboration between smart link and the CC function of CFD on a smart link member port:

Remarks

N/A

Step Command

1. Enter system view. system-view

2. Enter Layer 2 Ethernet interface view. interface interface-type

interface-number

3.

Configure the collaboration between Smart Link and the

CC function of CFD on the port. port smart-link group group-id track cfd cc

N/A

Optional.

By default, the collaboration between Smart Link and the CC function of CFD is not configured.

Configuring an associated device

An associated device is a device that supports Smart Link, and receives flush messages sent from the

specified control VLAN. Device A, Device B, and Device E in Figure 23

are examples of associated devices.

Configuration prerequisites

Disable the spanning tree feature on the associated device's ports that connect to the member ports of the smart link group. Otherwise, the ports will discard flush messages when they are not in forwarding state in case of a topology change.

Enabling the receiving of flush messages

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

You do not need to enable all ports on the associated devices to receive flush messages sent from the transmit control VLAN, only those on the primary and secondary links between the Smart Link device and the destination device.

103

Configure all the control VLANs to receive flush messages.

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

Make sure the receive control VLAN is the same as the transmit control VLAN configured on the

Smart Link device. If they are not the same, the associated device will forward the received flush messages directly without any processing.

Do not remove the control VLANs. Otherwise, flush messages cannot be sent properly.

Make sure the control VLANs are existing VLANs, and assign the ports capable of receiving flush messages to the control VLANs.

To enable the receiving of flush messages:

Remarks

N/A

Step Command

1. Enter system view. system-view

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

interface-number

3. Configure the control VLANs for receiving flush messages. smart-link flush enable

[ control-vlan vlan-id-list ]

N/A

By default, no control VLAN exists for receiving flush messages.

Displaying and maintaining Smart Link

Task Command

Display smart link group information. display smart-link group { group-id

| all } [ | { begin | exclude | include } regular-expression ]

Display information about the received flush messages. display smart-link flush [ | { begin

| exclude | include }

regular-expression ]

Clear the statistics about flush messages. reset smart-link statistics

Remarks

Available in any view.

Available in any view.

Available in user view.

Smart Link configuration examples

This section provides examples for various Smart Link configurations.

Single smart link group configuration example

Network requirements

As shown in

Figure 24

:

Device C and Device D are Smart Link devices. Device A, Device B, and Device E are associated devices. Traffic of VLANs 1 through 30 on Device C and Device D are dually uplinked to Device A.

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

104

Figure 24 Network diagram

Configuration procedure

1. Configure Device C:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

[DeviceC] stp region-configuration

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

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on them, configure them as trunk ports, and assign them to VLANs 1 through 30.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] shutdown

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

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

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

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] shutdown

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

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

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

[DeviceC-GigabitEthernet1/0/2] quit

# Create smart link group 1, and configure all VLANs mapped to MSTI 1 as the protected VLANs.

[DeviceC] smart-link group 1

[DeviceC-smlk-group1] protected-vlan reference-instance 1

# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.

[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master

[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave

105

# Enable flush message sending in smart link group 1, and configure VLAN 10 as the transmit control VLAN.

[DeviceC-smlk-group1] flush enable control-vlan 10

[DeviceC-smlk-group1] quit

# Bring up GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 again.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] undo shutdown

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] undo shutdown

[DeviceC-GigabitEthernet1/0/2] quit

2. Configure Device D:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate the MST region configuration.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

[DeviceD] stp region-configuration

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

[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit

# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure them as trunk ports, and assign them to VLANs 1 through 30.

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] shutdown

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

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

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

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/2

[DeviceD-GigabitEthernet1/0/2] shutdown

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

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

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

[DeviceD-GigabitEthernet1/0/2] quit

# Create smart link group 1, and configure all VLANs mapped to MSTI 1 as the protected VLANs.

[DeviceD] smart-link group 1

[DeviceD-smlk-group1] protected-vlan reference-instance 1

# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.

[DeviceD-smlk-group1] port gigabitethernet 1/0/1 master

[DeviceD-smlk-group1] port gigabitethernet 1/0/2 slave

# Enable flush message sending in smart link group 1, and configure VLAN 20 as the transmit control VLAN.

[DeviceD-smlk-group1] flush enable control-vlan 20

[DeviceD-smlk-group1] quit

# Bring up GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 again.

106

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] undo shutdown

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/2

[DeviceD-GigabitEthernet1/0/2] undo shutdown

[DeviceD-GigabitEthernet1/0/2] quit

3. Configure Device B:

# Create VLANs 1 through 30.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 30. Enable flush message receiving on it, and configure VLAN 10 and VLAN 20 as the receive control VLANs.

[DeviceB] interface gigabitethernet 1/0/1

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

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

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

[DeviceB-GigabitEthernet1/0/1] quit

# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 20 as the receive control VLAN.

[DeviceB] interface gigabitethernet 1/0/2

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

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

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

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

[DeviceB-GigabitEthernet1/0/2] quit

# Configure GigabitEthernet 1/0/3 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 as the receive control VLAN.

[DeviceB] interface gigabitethernet 1/0/3

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

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

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

[DeviceB-GigabitEthernet1/0/3] smart-link flush enable control-vlan 10

[DeviceB-GigabitEthernet1/0/3] quit

4. Configure Device E:

# Create VLANs 1 through 30.

<DeviceE> system-view

[DeviceE] vlan 1 to 30

# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 30. Enable flush message receiving on it, and configure VLAN 10 and VLAN 20 as the receive control VLANs.

[DeviceE] interface gigabitethernet 1/0/1

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

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

[DeviceE-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 20

[DeviceE-GigabitEthernet1/0/1] quit

107

# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 as the receive control VLAN.

[DeviceE] interface gigabitethernet 1/0/2

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

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

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

[DeviceE-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10

[DeviceE-GigabitEthernet1/0/2] quit

# Configure GigabitEthernet 1/0/3 as a trunk port and assign it to VLANs 1 through 30. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 20 as the receive control VLAN.

[DeviceE] interface gigabitethernet 1/0/3

[DeviceE-GigabitEthernet1/0/3] port link-type trunk

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

[DeviceE-GigabitEthernet1/0/3] undo stp enable

[DeviceE-GigabitEthernet1/0/3] smart-link flush enable control-vlan 20

[DeviceE-GigabitEthernet1/0/3] quit

5. Configure Device A:

# Create VLANs 1 through 30.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, assign them to

VLANs 1 through 30, enable flush message receiving on them, and configure VLAN 10 and VLAN

20 as the receive control VLANs.

[DeviceA] interface gigabitethernet 1/0/1

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

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

[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 20

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

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

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

[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 20

[DeviceA-GigabitEthernet1/0/2] quit

Verifying the configuration

Use the display smart-link group command to display the smart link group configuration on a device.

# Display the smart link group configuration on Device C.

[DeviceC] display smart-link group 1

Smart link group 1 information:

Device ID: 000f-e23d-5af0

Preemption mode: NONE

Preemption delay: 1(s)

Control VLAN: 10

Protected VLAN: Reference Instance 1

Member Role State Flush-count Last-flush-time

-----------------------------------------------------------------------------

108

GigabitEthernet1/0/1 MASTER ACTVIE 5 16:37:20 2010/02/21

GigabitEthernet1/0/2 SLAVE STANDBY 1 17:45:20 2010/02/21

You can use the display smart-link flush command to display the flush messages received on a device.

# Display the flush messages received on Device B.

[DeviceB] display smart-link flush

Received flush packets : 5

Receiving interface of the last flush packet : GigabitEthernet1/0/3

Receiving time of the last flush packet : 16:25:21 2009/02/21

Device ID of the last flush packet : 000f-e23d-5af0

Control VLAN of the last flush packet : 10

Multiple smart link groups load sharing configuration example

Network requirements

As shown in

Figure 25

:

Device C is a Smart Link device. Device A, Device B, and Device D are associated devices. Traffic of VLANs 1 through 200 on Device C is dually uplinked to Device A by Device B and Device D.

Implement dual uplink backup and load sharing on Device C: traffic of VLANs 1 through 100 is uplinked to Device A by Device B and traffic of VLANs 101 through 200 is uplinked to Device A by

Device D.

Figure 25 Network diagram

Configuration procedure

1. Configure Device C:

# Create VLAN 1 through VLAN 200, map VLANs 1 through 100 to MSTI 1, and VLANs 101 through 200 to MSTI 2, and activate MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 1 to 200

[DeviceC] stp region-configuration

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

[DeviceC-mst-region] instance 2 vlan 101 to 200

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

109

# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on them, configure them as trunk ports, and assign them to VLAN 1 through VLAN 200.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] shutdown

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

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

[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] shutdown

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

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

[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

[DeviceC-GigabitEthernet1/0/2] quit

# Create smart link group 1 and configure all VLANs mapped to MSTI 1 as the protected VLANs for smart link group 1.

[DeviceC] smart-link group 1

[DeviceC-smlk-group1] protected-vlan reference-instance 1

# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.

[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master

[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave

# Enable role preemption in smart link group 1, enable flush message sending, and configure

VLAN 10 as the transmit control VLAN.

[DeviceC-smlk-group1] preemption mode role

[DeviceC-smlk-group-1] flush enable control-vlan 10

[DeviceC-smlk-group-1] quit

# Create smart link group 2 and configure all VLANs mapped to MSTI 2 as the protected VLANs for smart link group 2.

[DeviceC] smart-link group 2

[DeviceC-smlk-group2] protected-vlan reference-instance 2

# Configure GigabitEthernet 1/0/1 as the secondary port and GigabitEthernet 1/0/2 as the primary port for smart link group 2.

[DeviceC-smlk-group2] port gigabitethernet 1/0/2 master

[DeviceC-smlk-group2] port gigabitethernet 1/0/1 slave

# Enable role preemption in smart link group 2, enable flush message sending, and configure

VLAN 110 as the transmit control VLAN.

[DeviceC-smlk-group2] preemption mode role

[DeviceC-smlk-group2] flush enable control-vlan 110

[DeviceC-smlk-group2] quit

# Bring up GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] undo shutdown

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] undo shutdown

[DeviceC-GigabitEthernet1/0/2] quit

110

2. Configure Device B:

# Create VLAN 1 through VLAN 200.

<DeviceB> system-view

[DeviceB] vlan 1 to 200

# Configure GigabitEthernet 1/0/1 as a trunk port, assign it to VLANs 1 through 200, enable flush message receiving, and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceB] interface gigabitethernet 1/0/1

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

[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceB-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110

[DeviceB-GigabitEthernet1/0/1] quit

# Configure GigabitEthernet 1/0/2 as a trunk port, assign it to VLANs 1 through 200, disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 and

VLAN 110 as the receive control VLANs.

[DeviceB] interface gigabitethernet 1/0/2

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

[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

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

[DeviceB-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110

[DeviceB-GigabitEthernet1/0/2] quit

3. Configure Device D:

# Create VLAN 1 through VLAN 200.

<DeviceD> system-view

[DeviceD] vlan 1 to 200

# Configure GigabitEthernet 1/0/1 as a trunk port, assign it to VLANs 1 through 200, enable flush message receiving, and configure VLAN 10 and VLAN 110 as the receive control VLANs on the port.

[DeviceD] interface gigabitethernet 1/0/1

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

[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceD-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110

[DeviceD-GigabitEthernet1/0/1] quit

# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 200, disable the spanning tree feature and enable flush message receiving, and configure VLAN 10 and VLAN

110 as the receive control VLANs on the port.

[DeviceD] interface gigabitethernet 1/0/2

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

[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

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

[DeviceD-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110

[DeviceD-GigabitEthernet1/0/2] quit

4. Configure Device A:

# Create VLAN 1 through VLAN 200.

<DeviceA> system-view

[DeviceA] vlan 1 to 200

111

# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, assign them to

VLANs 1 through 200, enable flush message receiving, and configure VLAN 10 and VLAN 110 as the receive control VLANs on the ports.

[DeviceA] interface gigabitethernet 1/0/1

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

[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

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

[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110

[DeviceA-GigabitEthernet1/0/2] quit

Verifying the configuration

Use the display smart-link group command to display the smart link group configuration on a device.

# Display the smart link group configuration on Device C.

[DeviceC] display smart-link group all

Smart link group 1 information:

Device ID: 000f-e23d-5af0

Preemption delay: 1(s)

Preemption mode: ROLE

Control VLAN: 10

Protected VLAN: Reference Instance 1

Member Role State Flush-count Last-flush-time

-----------------------------------------------------------------------------

GigabitEthernet1/0/1 MASTER ACTVIE 5 16:37:20 2010/02/21

GigabitEthernet1/0/2 SLAVE STANDBY 1 17:45:20 2010/02/21

Smart link group 2 information:

Device ID: 000f-e23d-5af0

Preemption mode: ROLE

Preemption delay: 1(s)

Control VLAN: 110

Protected VLAN: Reference Instance 2

Member Role State Flush-count Last-flush-time

-----------------------------------------------------------------------------

GigabitEthernet1/0/2 MASTER ACTVIE 5 16:37:20 2010/02/21

GigabitEthernet1/0/1 SLAVE STANDBY 1 17:45:20 2010/02/21

Use the display smart-link flush command to display the flush messages received on a device.

# Display the flush messages received on Device B.

[DeviceB] display smart-link flush

Received flush packets : 5

Receiving interface of the last flush packet : GigabitEthernet1/0/2

Receiving time of the last flush packet : 16:25:21 2010/02/21

112

Device ID of the last flush packet : 000f-e23d-5af0

Control VLAN of the last flush packet : 10

Smart Link and CFD collaboration configuration example

Network requirements

As shown in

Figure 26

:

Device A, Device B, Device C, and Device D form a MD of level 5. Device C is a Smart Link device, and Device A, Device B, and Device D are associated devices. Traffic of VLANs 1 through 200 on

Device C is dually uplinked to Device A by Device B and Device D.

Configure the CFD CC function for Smart Link so that traffic of VLANs 1 through 100 is uplinked to

Device A by Device C through GigabitEthernet 1/0/1 (primary port of smart link group 1). Traffic of VLANs 101 through 200 is uplinked to Device A by Device C through GigabitEthernet 1/0/2

(primary port of smart link group 2). When the link between Device C and Device A fails, traffic is rapidly switched to the secondary port of each smart link group, and switched back to the primary

ports after the fault is cleared. For more information about CFD, see " Configuring CFD

."

Figure 26 Network diagram

MD

Device A

Device B

GE

1/0

/1

GE

1/0

/1

GE

1/0

/2 GE

1/0

/1

GE

1/0

/2

GE

1/0

/1

Device C

GE

1/0

/2

GE

1/0

/2

Device D

Outward-facing MEP

User network

Configuration procedure

1. Configure Device A:

# Create VLAN 1 through VLAN 200.

<DeviceA> system-view

[DeviceA] vlan 1 to 200

# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports and assign them to

VLANs 1 through 200. Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.

[DeviceA] interface gigabitethernet 1/0/1

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

[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110

[DeviceA-GigabitEthernet1/0/1] quit

113

[DeviceA] interface gigabitethernet 1/0/2

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

[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110

[DeviceA-GigabitEthernet1/0/2] quit

# Enable CFD and create an MD of level 5.

[DeviceA] cfd enable

[DeviceA] cfd md MD level 5

# Create MA MA_A for the MD, configure the MA to serve VLAN 10, and create service instance

1 for the MD and MA.

[DeviceA] cfd ma MA_A md MD vlan 10

[DeviceA] cfd service-instance 1 md MD ma MA_A

# Create a MEP list in service instance 1, create and enable outward-facing MEP 1002, and enable CCM sending in service instance 1 on GigabitEthernet 1/0/1.

[DeviceA] cfd meplist 1001 1002 service-instance 1

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] cfd mep 1002 service-instance 1 outbound

[DeviceA-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1002 enable

[DeviceA-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1002 enable

[DeviceA-GigabitEthernet1/0/1] quit

# Create MA MA_B for the MD, configure the MA to serve VLAN 110, and create service instance

2 for the MD and MA.

[DeviceA] cfd ma MA_B md MD vlan 110

[DeviceA] cfd service-instance 2 md MD ma MA_B

# Create a MEP list in service instance 2, create and enable outward-facing MEP 1002, and enable CCM sending in service instance 2 on GigabitEthernet 1/0/2.

[DeviceA] cfd meplist 2001 2002 service-instance 2

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] cfd mep 2002 service-instance 2 outbound

[DeviceA-GigabitEthernet1/0/2] cfd mep service-instance 2 mep 2002 enable

[DeviceA-GigabitEthernet1/0/2] cfd cc service-instance 2 mep 2002 enable

[DeviceA-GigabitEthernet1/0/2] quit

2. Configure Device B:

# Create VLAN 1 through VLAN 200.

<DeviceB> system-view

[DeviceB] vlan 1 to 200

# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 200. Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on

GigabitEthernet 1/0/1.

[DeviceB] interface gigabitethernet 1/0/1

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

[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceB-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110

[DeviceB-GigabitEthernet1/0/1] quit

# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 200. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 and

VLAN 110 as the receive control VLANs.

114

[DeviceB] interface gigabitethernet 1/0/2

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

[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

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

[DeviceB-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110

[DeviceB-GigabitEthernet1/0/2] quit

3. Configure Device C:

# Create VLAN 1 through VLAN 200, map VLANs 1 through 100 to MSTI 1, and VLANs 101 through 200 to MSTI 2, and activate MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 1 to 200

[DeviceC] stp region-configuration

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

[DeviceC-mst-region] instance 2 vlan 101 to 200

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Shut down GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2, disable the spanning tree feature on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure the ports as trunk ports, and assign them to VLAN 1 through VLAN 200.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] shutdown

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

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

[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] shutdown

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

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

[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

[DeviceC-GigabitEthernet1/0/2] quit

# Create smart link group 1 and configure all VLANs mapped to MSTI 1 as the protected VLANs for smart link group 1.

[DeviceC] smart-link group 1

[DeviceC-smlk-group1] protected-vlan reference-instance 1

# Configure GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port for smart link group 1.

[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master

[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave

# Enable role preemption in smart link group 1, enable flush message sending, and configure

VLAN 10 as the transmit control VLAN.

[DeviceC-smlk-group1] preemption mode role

[DeviceC-smlk-group1] flush enable control-vlan 10

[DeviceC-smlk-group1] quit

# Create smart link group 2 and configure all VLANs mapped to MSTI 2 as the protected VLANs for smart link group 2.

[DeviceC] smart-link group 2

115

[DeviceC-smlk-group2] protected-vlan reference-instance 2

# Configure GigabitEthernet 1/0/1 as the secondary port and GigabitEthernet 1/0/2 as the primary port for smart link group 2.

[DeviceC-smlk-group2] port gigabitethernet 1/0/2 master

[DeviceC-smlk-group2] port gigabitethernet 1/0/1 slave

# Enable role preemption in smart link group 2, enable flush message sending, and configure

VLAN 110 as the transmit control VLAN.

[DeviceC-smlk-group2] preemption mode role

[DeviceC-smlk-group2] flush enable control-vlan 110

[DeviceC-smlk-group2] quit

# Enable CFD and create an MD of level 5.

[DeviceC] cfd enable

[DeviceC] cfd md MD level 5

# Create MA MA_A for the MD and configure the MA to serve VLAN 10, and create service instance 1 for the MD and MA.

[DeviceC] cfd ma MA_A md MD vlan 10

[DeviceC] cfd service-instance 1 md MD ma MA_A

# Create a MEP list in service instance 1, create and enable outward-facing MEP 1001, and enable CCM sending in service instance 1 on GigabitEthernet 1/0/1.

[DeviceC] cfd meplist 1001 1002 service-instance 1

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] cfd mep 1001 service-instance 1 outbound

[DeviceC-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1001 enable

[DeviceC-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1001 enable

[DeviceC-GigabitEthernet1/0/1] quit

# Create MA MA_B for the MD and configure the MA to serve VLAN 110, and create service instance 2 for the MD and MA.

[DeviceC] cfd ma MA_B md MD vlan 110

[DeviceC] cfd service-instance 2 md MD ma MA_B

# Create a MEP list in service instance 2, create and enable outward-facing MEP 2001, and enable CCM sending in service instance 2 on GigabitEthernet 1/0/2.

[DeviceC] cfd meplist 2001 2002 service-instance 2

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] cfd mep 2001 service-instance 2 outbound

[DeviceC-GigabitEthernet1/0/2] cfd mep service-instance 2 mep 2001 enable

[DeviceC-GigabitEthernet1/0/2] cfd cc service-instance 2 mep 2001 enable

[DeviceC-GigabitEthernet1/0/2] quit

# Configure the collaboration between the primary port GigabitEthernet 1/0/1 of smart link group 1 and the CC function of CFD, and bring up the port.

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] port smart-link group 1 track cfd cc

[DeviceC-GigabitEthernet1/0/1] undo shutdown

[DeviceC-GigabitEthernet1/0/1] quit

# Configure the collaboration between the primary port GigabitEthernet 1/0/2 of smart link group 2 and the CC function of CFD, and bring up the port.

[DeviceC] interface gigabitethernet 1/0/2

[DeviceC-GigabitEthernet1/0/2] port smart-link group 2 track cfd cc

116

[DeviceC-GigabitEthernet1/0/2] undo shutdown

[DeviceC-GigabitEthernet1/0/2] quit

4. Configure Device D:

# Create VLAN 1 through VLAN 200.

<DeviceD> system-view

[DeviceD] vlan 1 to 200

# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to VLANs 1 through 200. Enable flush message receiving and configure VLAN 10 and VLAN 110 as the receive control VLANs on

GigabitEthernet 1/0/1.

[DeviceD] interface gigabitethernet 1/0/1

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

[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 200

[DeviceD-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 110

[DeviceD-GigabitEthernet1/0/1] quit

# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to VLANs 1 through 200. Disable the spanning tree feature and enable flush message receiving on it, and configure VLAN 10 and

VLAN 110 as the receive control VLANs.

[DeviceD] interface gigabitethernet 1/0/2

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

[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 1 to 200

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

[DeviceD-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 110

[DeviceD-GigabitEthernet1/0/2] quit

Verifying the configuration

Assume that the optical fiber between Device A and Device B fails. Use the display smart-link group command to display the smart link group configuration on a device.

# Display the smart link group configuration on Device C.

[DeviceC] display smart-link group all

Smart link group 1 information:

Device ID: 000f-e23d-5af0

Preemption mode: ROLE

Preemption delay: 1(s)

Control VLAN: 10

Protected VLAN: Reference Instance 1

Member Role State Flush-count Last-flush-time

-----------------------------------------------------------------------------

GigabitEthernet1/0/1 MASTER DOWN 5 16:37:20 2010/02/21

GigabitEthernet1/0/2 SLAVE ACTVIE 3 17:45:20 2010/02/21

Smart link group 2 information:

Device ID: 000f-e23d-5af0

Preemption mode: ROLE

Preemption delay: 1(s)

Control VLAN: 110

Protected VLAN: Reference Instance 2

117

Member Role State Flush-count Last-flush-time

-----------------------------------------------------------------------------

GigabitEthernet1/0/2 MASTER ACTVIE 5 16:37:20 2010/02/21

GigabitEthernet1/0/1 SLAVE STANDBY 1 17:45:20 2010/02/21

The output shows that primary port GigabitEthernet 1/0/1 of smart link group 1 fails, and secondary port GigabitEthernet 1/0/2 is in forwarding state.

118

Configuring Monitor Link

Monitor Link is typically used in conjunction with Smart Link in a dual-homed network to enable faster link switchover than spanning tree protocols. This chapter describes basic Monitor Link concepts, its working mechanism, and configuration procedure.

Overview

Monitor Link works together with Layer 2 topology protocols to adapt the up/down state of a downlink port to the state of an uplink port. This feature enables fast link switchover on a downstream device in response to the uplink state change on its upstream device.

Figure 27 Monitor Link application scenario

Terminology

The following terms are associated with Monitor Link configuration.

Monitor link group

A monitor link group is a set of uplink and downlink ports. A port can belong to only one monitor link group. As shown in

Figure 27 , ports Port 1 and Port 2 of Device B and those of Device D each form a

monitor link group. Port 1 is an uplink port on both devices, and Port 2 is a downlink port on both devices.

Uplink/Downlink ports

Uplink port and downlink port are two port roles in monitor link groups:

119

Uplink ports are the monitored ports—The state of a monitor link group adapts to that of its member uplink ports. When a monitor link group contains no uplink port or all uplink ports are down, the monitor link group goes down. As long as one member uplink port is up, the monitor link group stays up.

Downlink ports are the monitoring ports—The state of the downlink port of a monitor link group adapts to that of the monitor link group. When the state of a monitor link group changes, the state of its member downlink ports change accordingly. The state of the downlink ports in a monitor link group is always the same as that of the monitor link group.

Uplink/Downlink

The uplink is the link that connects the uplink ports in a monitor link group, and the downlink is the link that connects the downlink ports.

How Monitor Link works

Each monitor link group operates independently of other monitor link groups. When a monitor link group contains no uplink port or all its uplink ports are down, the monitor link group goes down, which forces all its downlink ports down at the same time. When any uplink port goes up, the monitor link group goes up and brings up all its downlink ports.

HP does not recommend that you manually shut down or bring up the downlink ports in a monitor link group.

Configuring Monitor Link

This section provides instructions for configuring Monitor Link.

Configuration prerequisites

Make sure the port is not a member port of any aggregation group or service loopback group.

Creating a monitor link group

Step Command

1. Enter system view. system-view

2. Create a monitor link group and enter monitor link group view. monitor-link group group-id

Configuring monitor link group member ports

You can configure member ports for a monitor link group either in monitor link group view or interface view. The configurations made in these two views have the same result.

In monitor link group view

To configure member ports for a monitor link group:

Step Command

1. Enter system view. system-view

120

Step Command

2. Enter monitor link group view. monitor-link group group-id

3. Configure member ports for the monitor link group. port interface-type interface-number { uplink | downlink }

In interface view

To configure member ports for a monitor link group:

Step Command

1. Enter system view. system-view

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

interface-number

Remarks

N/A

N/A

3. Configure the current interface as a member of a monitor link group. port monitor-link group group-id

{ uplink | downlink }

You can assign a Layer 2

Ethernet interface or Layer 2 aggregate interface to a monitor link group as a member port.

A port can be assigned to only one monitor link group.

To avoid undesired down/up state changes on the downlink ports, configure uplink ports prior to downlink ports.

Displaying and maintaining Monitor Link

Remarks Task Command

Display monitor link group information. display monitor-link group

{ group-id | all } [ | { begin | exclude | include }

regular-expression ]

Available in any view.

Monitor Link configuration example

Network requirements

As shown in Figure 28

, Device C is a smart link device, and Device A, Device B, and Device D are associated devices. Traffic of VLANs 1 through 30 on Device C is dual-uplinked to Device A through a smart link group. For more information about Smart Link, see "

Configuring Smart Link ."

Implement dual uplink backup on Device C. Make sure that when the link between Device A and Device

B (or Device D) fails, Device C must be able to sense the link fault and perform uplink switchover in the smart link group.

121

Figure 28 Network diagram

Configuration procedure

1. Configure Device C:

# Create VLANs 1 through 30, map these VLANs to MSTI 1, and activate MST region configuration.

<DeviceC> system-view

[DeviceC] vlan 1 to 30

[DeviceC] stp region-configuration

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

[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit

# Disable the spanning tree feature on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure them as trunk ports, and assign them to VLANs 1 through 30.

[DeviceC] interface gigabitethernet 1/0/1

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

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

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

[DeviceC-GigabitEthernet1/0/1] quit

[DeviceC] interface gigabitethernet 1/0/2

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

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

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

[DeviceC-GigabitEthernet1/0/2] quit

# Create smart link group 1 and configure all the VLANs mapped to MSTI 1 as the protected

VLANs for smart link group 1.

[DeviceC] smart-link group 1

[DeviceC-smlk-group1] protected-vlan reference-instance 1

# Configure GigabitEthernet 1/0/1 as the master port and GigabitEthernet 1/0/2 as the subordinate port for smart link group 1.

[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master

[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave

# Enable the smart link group to transmit flush messages.

[DeviceC-smlk-group1] flush enable

[DeviceC-smlk-group1] quit

122

2. Configure Device A:

# Create VLANs 1 through 30.

<DeviceA> system-view

[DeviceA] vlan 1 to 30

# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, assign them to

VLANs 1 through 30, and enable flush message receiving on them.

[DeviceA] interface gigabitethernet 1/0/1

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

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

[DeviceA-GigabitEthernet1/0/1] smart-link flush enable

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

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

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

[DeviceA-GigabitEthernet1/0/2] smart-link flush enable

[DeviceA-GigabitEthernet1/0/2] quit

3. Configure Device B:

# Create VLANs 1 through 30.

<DeviceB> system-view

[DeviceB] vlan 1 to 30

# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, and assign them to VLANs 1 through 30. Disable the spanning tree feature on GigabitEthernet 1/0/2 and enable flush message receiving on the two ports.

[DeviceB] interface gigabitethernet 1/0/1

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

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

[DeviceB-GigabitEthernet1/0/1] smart-link flush enable

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

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

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

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

[DeviceB-GigabitEthernet1/0/2] smart-link flush enable

[DeviceB-GigabitEthernet1/0/2] quit

# Create monitor link group 1 and configure GigabitEthernet 1/0/1 as an uplink port and

GigabitEthernet 1/0/2 as a downlink port for monitor link group 1.

[DeviceB] monitor-link group 1

[DeviceB-mtlk-group1] port gigabitethernet 1/0/1 uplink

[DeviceB-mtlk-group1] port gigabitethernet 1/0/2 downlink

[DeviceB-mtlk-group1] quit

4. Configure Device D:

# Create VLANs 1 through 30.

<DeviceD> system-view

[DeviceD] vlan 1 to 30

# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports, and assign them to VLANs 1 through 30. Disable the spanning tree feature on GigabitEthernet 1/0/2 and enable flush message receiving on the two ports.

123

[DeviceD] interface gigabitethernet 1/0/1

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

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

[DeviceD-GigabitEthernet1/0/1] smart-link flush enable

[DeviceD-GigabitEthernet1/0/1] quit

[DeviceD] interface gigabitethernet 1/0/2

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

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

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

[DeviceD-GigabitEthernet1/0/2] smart-link flush enable

[DeviceD-GigabitEthernet1/0/2] quit

# Create monitor link group 1 and configure GigabitEthernet 1/0/1 as an uplink port and

GigabitEthernet 1/0/2 as a downlink port for monitor link group 1.

[DeviceD] monitor-link group 1

[DeviceD-mtlk-group1] port gigabitethernet 1/0/1 uplink

[DeviceD-mtlk-group1] port gigabitethernet 1/0/2 downlink

[DeviceD-mtlk-group1] quit

Verifying the configuration

Use the display monitor-link group command to display the monitor link group information on devices.

For example, when GigabitEthernet 1/0/2 on Device A goes down due to a link fault:

# Examine information about monitor link group 1 on Device B.

[DeviceB] display monitor-link group 1

Monitor link group 1 information:

Group status: UP

Last-up-time: 16:37:20 2009/4/21

Last-down-time: 16:35:26 2009/4/21

Member Role Status

------------------------------------------

GigabitEthernet1/0/1 UPLINK UP

GigabitEthernet1/0/2 DOWNLINK UP

# Examine information about monitor link group 1 on Device D.

[DeviceD] display monitor-link group 1

Monitor link group 1 information:

Group status: DOWN

Last-up-time: 16:35:27 2009/4/21

Last-down-time: 16:37:19 2009/4/21

Member Role Status

------------------------------------------

GigabitEthernet1/0/1 UPLINK DOWN

GigabitEthernet1/0/2 DOWNLINK DOWN

124

Configuring VRRP

This chapter describes how to configure VRRP.

VRRP overview

As shown in Figure 29 , you can configure a default route with the gateway as the next hop for every host

on a LAN. All packets destined to other network segments are sent over the default route to the gateway, which then forwards the packets. However, when the gateway fails, the hosts that use the gateway as the default next-hop router cannot communicate with external networks.

Figure 29 LAN networking

Configuring a default route for network hosts facilitates your configuration, but also requires high performance stability of the device that acts as the gateway. Using more egress gateways can improve availability, but introduce routing problems among the egresses.

VRRP is designed to address this problem. VRRP adds multiple routers that can act as network gateways to a VRRP group, which forms a virtual router. Routers in the VRRP group elect a master through the VRRP election mechanism to act as a gateway, and hosts on a LAN only need to configure the virtual router as their default gateway.

VRRP avoids single points of failure and simplifies the configuration on hosts. When the master in the

VRRP group for a multicast or broadcast LAN (for example, an Ethernet network) fails, another gateway in the VRRP group can take over without causing dynamic route recalculation, route rediscovery, gateway reconfiguration on the hosts, or traffic interruption.

VRRP operates in standard mode, and includes two versions: IETF VRRPv2 for IPv4 and VRRPv3 for IPv6.

For more information, see "

VRRP standard mode ."

VRRP standard mode

This section describes basic concepts of standard mode VRRP.

125

VRRP group

VRRP combines a group of routers (one master and multiple backups) on a LAN into a virtual router called a VRRP group.

A VRRP group has the following features:

A virtual router has a virtual IP address. A host on the LAN only needs to know the IP address of the virtual router and uses the IP address as the next hop of the default route.

Every host on the LAN communicates with external networks through the virtual router.

Routers in the VRRP group elect a master that acts as the gateway according to their priorities. The other routers function as backups. When the master fails, to make sure the hosts in the network segment can communicate without interruption with the external networks, the backups in the VRRP group elect a new master to act as the gateway.

Figure 30 Network diagram

As shown in Figure 30

, Router A, Router B, and Router C form a virtual router, which has its own IP address. Hosts on the Ethernet use the virtual router as the default gateway.

The router with the highest priority is elected as the master to act as the gateway and the other two are backups.

The IP address of the virtual router can be either an unused IP address on the segment where the VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the router is called the IP address owner.

Only one IP address owner can be configured for a VRRP group.

A router in a VRRP group can be in master, backup, or initialize status.

VRRP priority

VRRP determines the role (master or backup) of each router in a VRRP group by priority. A router with a higher priority is more likely to become the master.

VRRP priority is in the range of 0 to 255. The greater the number, the higher the priority. Priorities 1 to

254 are configurable. Priority 0 is reserved and priority 255 is for the IP address owner. The router acting as the IP address owner in a VRRP group always has the running priority 255 and acts as the master as long as it operates properly.

126

Operation mode

A router in a VRRP group operates in either of the following modes:

Non-preemptive mode—When a router in the VRRP group becomes the master, it stays as the master as long as it operates properly, even if a backup is assigned a higher priority later.

Preemptive mode—When a backup finds it has a higher priority than the master, the backup sends

VRRP advertisements to start a new master election in the VRRP group and becomes the master. The original master becomes a backup.

Authentication mode

To avoid attacks from unauthorized users, VRRP member routers add authentication keys in VRRP packets to authenticate one another. VRRP provides the following authentication modes:

simple—Simple text authentication

The sender fills an authentication key into the VRRP packet, and the receiver compares the received authentication key with its local authentication key. If the two authentication keys are the same, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate.

md5—MD5 authentication

The sender computes a digest for the packet to be sent by using the authentication key and MD5 algorithm and saves the result in the authentication header. The receiver performs the same operation by using the authentication key and MD5 algorithm, and compares the result with the content in the authentication header. If the results are the same, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate.

On a secure network, you can choose to not authenticate VRRP packets.

VRRP timers

VRRP timers include VRRP advertisement interval and VRRP preemption delay timer.

VRRP advertisement interval

The master in a VRRP group periodically sends VRRP advertisements to inform all the other routers in the

VRRP group that it is operating properly.

You can adjust the interval for sending VRRP advertisements by setting the VRRP advertisement interval.

If a backup receives no advertisements in a period three times the interval, the backup regards itself as the master and sends VRRP advertisements to start a new master election.

VRRP preemption delay timer

To avoid frequent state changes among members in a VRRP group and provide the backups enough time to collect information, such as routing information, a backup does not immediately become the master after it receives an advertisement that carries the priority lower than the local priority. Instead, it waits for a period of time (the preemption delay time), and then sends VRRP advertisements to start a new master election in the VRRP group before becoming the master.

Packet format

The master periodically multicasts VRRP packets to declare its presence. VRRP packets are also used for examining the parameters of the virtual router and electing the master.

VRRP packets are encapsulated in IP packets, with the protocol number 112. Figure 31

shows the VRRPv2 packet format and

Figure 32

shows the VRRPv3 packet format.

127

Figure 31 VRRPv2 packet format

Figure 32 VRRPv3 packet format

0 3 7

Version Type Virtual Rtr ID

Auth Type Adver Int

15

Priority

23

Count IPv6 Addrs

Checksum

31

IPv6 address 1

IPv6 address n

Authentication data 1

Authentication data 2

A VRRP packet includes the following fields:

Version—Version number of the protocol, 2 for VRRPv2 and 3 for VRRPv3.

Type—Type of the VRRPv2 or VRRPv3 packet. It must be VRRP advertisement, represented by 1.

Virtual Rtr ID (VRID)—ID of the virtual router. It ranges from 1 to 255.

Priority—Priority of the router in the VRRP group, in the range of 0 to 255. A greater value represents a higher priority.

Count IP Addrs/Count IPv6 Addrs—Number of virtual IPv4 or IPv6 addresses for the VRRP group.

A VRRP group can have multiple virtual IPv4 or IPv6 addresses.

Auth Type—Authentication type. 0 means no authentication, 1 means simple text authentication, and 2 means MD5 authentication. VRRPv3 does not support MD5 authentication.

Adver Int—Interval for sending advertisement packets. For VRRPv2, the interval is in seconds and defaults to 1. For VRRPv3, the interval is in centiseconds and defaults to 100.

Checksum—16-bit checksum for validating the data in VRRP packets.

128

IP Address/IPv6 Address—Virtual IPv4 or IPv6 address entry of the VRRP group. The Count IP

Addrs or Count IPv6 Addrs field defines the number of virtual IPv4 or IPv6 addresses.

Authentication Data—Authentication key. This field is used only for simple authentication and is 0 for any other authentication mode.

VRRP principles

The working principles of VRRP are:

Routers in a VRRP group determine their roles by priority. The router with the highest priority is the master, and the others are the backups. The master periodically sends VRRP advertisements to notify the backups that it is operating properly, and each backup starts a timer to wait for advertisements from the master.

In preemptive mode, when a backup receives a VRRP advertisement, it compares the priority in the packet with its own priority. If the priority of the backup is higher, the backup becomes the master.

Otherwise, it remains as a backup. In preemptive mode, a VRRP group always has the router with the highest priority as the master for forwarding packets.

In non-preemptive mode, a backup with higher priority than the master does not preempt the master if the master is operating properly. The non-preemptive mode avoids frequent master and backup switchover.

If the timer of a backup expires but the backup does not receive any VRRP advertisement, it considers that the master has failed. In this case, the backup considers itself as the master and sends

VRRP advertisements to start a new master election.

When multiple routers in a VRRP group declare that they are the master because of inconsistent configuration or network problems, the one with the highest priority becomes the master. If two routers have the same priority, the one with the highest IP address becomes the master.

When a backup router receives an advertisement, it compares its priority with the advertised priority.

If its priority is higher, it takes over as the master.

VRRP tracking

To enable VRRP tracking, first configure the routers in the VRRP group to operate in preemptive mode, so the router with the highest priority always operates as the master for packet forwarding.

Tracking a specified interface

The interface tracking function expands the backup functionality of VRRP. It provides backup not only when the interface to which a VRRP group is assigned fails, but also when other interfaces (such as uplink interfaces) on the router become unavailable.

If the uplink interface of a router in a VRRP group fails, usually the VRRP group cannot be aware of the uplink interface failure. If the router is the master of the VRRP group, hosts on the LAN are unable to access external networks. This problem can be solved by tracking a specified uplink interface. If the tracked uplink interface is down or removed, the priority of the master is automatically decreased by a specified value. A higher priority router in the VRRP group becomes the master.

Monitoring a track entry

By monitoring a track entry, you can:

Monitor an uplink and change the priority of the router according to the uplink state.

If the uplink fails, hosts in the LAN cannot access external networks through the router. The state of the monitored track entry is negative and the priority of the router decreases by a specified value.

129

Then, a higher priority router in the VRRP group becomes the master to maintain the proper communication between the hosts in the LAN and external networks.

Monitor the master on a backup.

When the master fails, the backup immediately takes over to maintain normal communication.

For more information about track entries, see " Configuring track

."

VRRP application

This section describes an IPv4 VRRP application.

Master/backup

In master/backup mode, only the master forwards packets. When the master fails, a new master is elected from the backups. This mode requires only one VRRP group, in which each router holds a different priority and the one with the highest priority becomes the master.

Figure 33 VRRP in master/backup mode

Assume that Router A is acting as the master to forward packets to external networks and Router B and

Router C are backups in listening state. When Router A fails, Router B and Router C elect a new master to forward packets for hosts on the LAN.

Load sharing

You can create more than one VRRP group on an interface of a router to allow the router to be the master of one VRRP group but a backup of another at the same time.

In load sharing mode, multiple routers provide services simultaneously. This mode requires two or more

VRRP groups, each of which comprises a master and one or more backups. The master roles in the VRRP groups are assumed by different routers.

130

Figure 34 VRRP in load sharing mode

A router can be in multiple VRRP groups and hold a different priority in a different group.

As shown in

Figure 34

, the following VRRP groups are present:

VRRP group 1—Router A is the master. Router B and Router C are the backups.

VRRP group 2—Router B is the master. Router A and Router C are the backups.

VRRP group 3—Router C is the master. Router A and Router B are the backups.

For load sharing among Router A, Router B, and Router C, configure the hosts on the LAN to use VRRP group 1, 2, and 3, respectively, as the default gateways. When configuring VRRP priorities, make sure each router is prioritized properly in each VRRP group so that it can take the expected role in the group.

General configuration restrictions

You can perform interface-specific VRRP configuration only on Layer 3 Ethernet interfaces, VLAN interfaces, and Layer 3 aggregate interfaces, unless otherwise specified. You can set an Ethernet port as a Layer 3 interface by using the port link-mode route command (see Layer 2—LAN Switching

Configuration Guide).

VRRP cannot be configured on interfaces in a link aggregation group.

Configuring VRRP for IPv4

This section provides instructions for configuring VRRP for IPv4.

VRRP for IPv4 configuration task list

To form a VRRP group, perform the following configurations on each device in the VRRP group.

131

Task Remarks

Specifying the type of MAC addresses mapped to virtual IP addresses

Optional.

Creating a VRRP group and configuring virtual IP addresses

Configuring router priority, preemptive mode, and tracking function

Configuring VRRP packet attributes

Enabling the trap function for VRRP

Required.

Optional.

Optional.

Optional.

Specifying the type of MAC addresses mapped to virtual IP addresses

You can configure VRRP in standard mode to map real or virtual MAC addresses to the virtual IP addresses of VRRP groups, so the master in a VRRP group uses the specified type of MAC address as the source MAC address for sending packets and for answering ARP requests.

Virtual MAC to virtual IP mapping—By default, a virtual MAC address is automatically assigned when a VRRP group is created, and the virtual IP address of the VRRP group is mapped to the virtual

MAC address. In this mapping approach, the hosts do not need to update the gateway IP and MAC mapping entry when the master changes.

Real MAC to virtual IP mapping—If a VRRP group has an IP address owner, configure real MAC to virtual IP mapping to avoid the problem of one IP address mapped to two MAC addresses (the real and the virtual). In this approach, the virtual IP address of the VRRP group is mapped to the real

MAC address of the IP address owner, and all packets from hosts are forwarded to the IP address owner.

If VRRP groups with the same ID are created on multiple interfaces and the VRRP advertisements of these

VRRP groups are to be sent across a QinQ network, HP recommends that you use real MAC to virtual IP mapping to guarantee successful transmission of the VRRP advertisements.

To specify the type of MAC addresses mapped to virtual IP addresses:

Step Command

1. Enter system view. system-view

2. Specify the type of MAC addresses mapped to virtual IP addresses. vrrp method { real-mac | virtual-mac }

Remarks

N/A

Optional.

By default, virtual MAC addresses are mapped to virtual IP addresses.

Creating a VRRP group and configuring virtual IP addresses

This section describes how to create a VRRP and configure virtual IP addresses.

Configuration guidelines

You can configure multiple virtual IP addresses for the VRRP group on an interface that connects to multiple subnets for router backup on different subnets.

The VRRP group is automatically created when you specify the first virtual IP address. If you later specify another virtual IP address for the VRRP group, the virtual IP address is added to the virtual

IP address list of the VRRP group.

132

The virtual IP address assigned to the VRRP group must be a legal host address and in the same subnet as the interface IP address. If not, the state of the VRRP group is always initialize and VRRP does not take effect. For example, although you can successfully configure a network address or broadcast address as the virtual IP address of a VRRP group, the group cannot work.

HP recommends that you not create a VRRP group on the VLAN interface of a super VLAN because network performance can be adversely affected.

When VRRP operates in standard mode, the virtual IP address of a VRRP group can be either an unused IP address on the subnet where the VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the router is called the IP address owner.

When a router is the IP address owner in a VRRP group, HP recommends you not configure the network command on the interface to use the IP address of the interface, or the virtual IP address of the VRRP group, to establish a neighbor relationship with the adjacent router. For more information about the network command, see Layer 3—IP Routing Command Reference.

A VRRP group is removed after you remove all its virtual IP addresses, and all its configurations become invalid.

Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the collision, change the IP address of the interface on the IP address owner before you remove the

VRRP group from the interface.

The virtual IP address of a VRRP group cannot be 0.0.0.0, 255.255.255.255, loopback addresses, non-class A/B/C addresses or other illegal IP addresses such as 0.0.0.1.

Configuration prerequisites

Before you create a VRRP group and configure a virtual IP address on an interface, configure an IP address for the interface and make sure it is in the same subnet as the virtual IP address.

Configuration procedure

To create a VRRP group and configure a virtual IP address:

Remarks

N/A

Step Command

1.

Enter system view. system-view

2. Enter the specified interface view.

3. Create a VRRP group and configure a virtual IP address for the VRRP group. interface interface-type

interface-number vrrp vrid virtual-router-id virtual-ip

virtual-address

N/A

By default, no VRRP group is created.

Configuring router priority, preemptive mode, and tracking function

This section describes how to configure router priority, preemptive mode, and tracking function.

Configuration guidelines

The running priority of an IP address owner is always 255. You do not need to configure it. An IP address owner always operates in preemptive mode.

If you configure an interface to be tracked or a track entry to be monitored on a router that is the IP address owner in a VRRP group, the configuration does not take effect. If the router is not the IP address owner in the VRRP group later, the configuration takes effect.

133

If the state of a tracked interface changes from down or removed to up, the priority of the router where the interface resides automatically restores.

If the state of a track entry changes from negative or invalid to positive, the priority of the router where the track entry is configured automatically restores.

Configuration prerequisites

Before you configure router priority, preemptive mode, and tracking function, create a VRRP group on an interface and configure a virtual IP address for it.

Configuration procedure

The router priority, preemptive mode, and track function can determine which router in the VRRP group serves as the master.

To configure router priority, preemptive mode and the tracking function:

Step Command

1. Enter system view. system-view

2. Enter interface view. interface interface-type

interface-number

3. Configure router priority in the

VRRP group. vrrp vrid virtual-router-id priority

priority-value

Remarks

N/A

N/A

4. Configure the router in the

VRRP group to operate in preemptive mode and configure preemption delay. vrrp vrid virtual-router-id preempt-mode [ timer delay

delay-value ]

Optional.

The default is 100.

Optional.

By default, the router in the VRRP group operates in preemptive mode and the preemption delay is

0 seconds.

5. Configure the interface to be tracked.

6. Configure VRRP to track a specified track entry. vrrp vrid virtual-router-id track interface interface-type

interface-number [ reduced

priority-reduced ] vrrp vrid virtual-router-id track

track-entry-number [ reduced

priority-reduced | switchover ]

Optional.

By default, no interface is being tracked.

Optional.

By default, VRRP is not configured to track a specified track entry.

Configuring VRRP packet attributes

This section describes how to configure VRRP packet attributes.

Configuration guidelines

You can configure different authentication modes and authentication keys for the VRRP groups on an interface. However, the members of the same VRRP group must use the same authentication mode and authentication key.

Excessive traffic can cause a backup to trigger a change of its status, because the backup does not receive any VRRP advertisements for a specified period of time. To solve this problem, prolong the time interval for sending VRRP advertisements.

Configuring different intervals for sending VRRP advertisements on the routers in a VRRP group can cause a backup to trigger a change of its status, because the backup does not receive any VRRP

134

advertisements for the specified period of time. To solve this problem, configure the same interval for sending VRRP advertisements on each router in the VRRP group.

Configuration prerequisites

Before you configure VRRP packet attributes, create a VRRP group and configure a virtual IP address for it.

Configuration procedure

To configure VRRP packet attributes:

Step Command

1. Enter system view. system-view

2. Configure the DSCP priority of

VRRP packets. vrrp dscp dscp-value

Remarks

N/A

Optional.

By default, the DSCP priority of VRRP packets is 48.

This command is available in Release

1203 and later versions.

3. Enter the specified interface view.

4. Configure the authentication mode and authentication key when the VRRP groups send and receive VRRP packets.

5. Configure the time interval for the master in the VRRP group to send VRRP advertisements. interface interface-type

interface-number vrrp vrid virtual-router-id authentication-mode { md5 | simple } [ cipher ] key vrrp vrid virtual-router-id timer advertise adver-interval

N/A

Optional.

By default, no authentication is performed.

Optional.

The default is 1 second.

6. Disable TTL check on VRRP packets. vrrp un-check ttl

Optional.

By default, TTL check on VRRP packets is enabled.

You do not need to create a VRRP group before executing this command.

Enabling the trap function for VRRP

When the trap function is enabled for VRRP, VRRP generates traps with severity level errors to report its key events. The traps are sent to the information center of the device, where you can configure whether to output the trap information and the output destination. For how to configure the information center, see

Network Management and Monitoring Configuration Guide.

To enable the trap function for VRRP:

1. Enter system view. system-view N/A

135

2. Enable the trap function for

VRRP. snmp-agent trap enable vrrp

[ authfailure | newmaster ]

Optional.

By default, the trap function for

VRRP is enabled.

For more information about the snmp-agent trap enable vrrp command, see the snmp-agent trap enable command in Network

Management and Monitoring

Command Reference.

Displaying and maintaining VRRP for IPv4

Task Command

Display VRRP group status. display vrrp [ verbose ] [ interface

interface-type interface-number

[ vrid virtual-router-id ] ] [ | { begin

| exclude | include }

regular-expression ]

Display VRRP group statistics. display vrrp statistics [ interface

interface-type interface-number

[ vrid virtual-router-id ] ] [ | { begin

| exclude | include }

regular-expression ]

Clear VRRP group statistics. reset vrrp statistics [ interface

interface-type interface-number

[ vrid virtual-router-id ] ]

Remarks

Available in any view.

Available in any view.

Available in user view.

Configuring VRRP for IPv6

Follow these instructions to configure VRRP for IPv6.

VRRP for IPv6 configuration task list

Task Remarks

Specifying the type of mapped MAC addresses

Optional.

Creating a VRRP group and configuring a virtual IPv6 address

Configuring router priority, preemptive mode, and tracking function

Configuring VRRP packet attributes

Required.

Optional.

Optional.

Specifying the type of mapped MAC addresses

You can configure VRRP in standard protocol mode to map real or virtual MAC addresses to the virtual

IPv6 addresses of VRRP groups, so the master in a VRRP group uses the specified type of MAC address as the source MAC address for sending packets and for answering ARP requests.

136

The following types of MAC addresses are available to be mapped to the virtual IPv6 address of a VRRP group:

Virtual MAC to virtual IP mapping—By default, a virtual MAC address is automatically assigned when a VRRP group is created, and the virtual IPv6 address of the VRRP group is mapped to the virtual MAC address. In this mapping approach, the hosts do not need to update the mapping between the IPv6 address and the MAC address when the master changes.

Real MAC to virtual IP mapping—If a VRRP group has an IP address owner, configure real MAC to virtual IP mapping to avoid the problem of one IPv6 address mapped to two MAC addresses (the real and the virtual). In this approach, the virtual IP address of the VRRP group is mapped to the real

MAC address of the IP address owner, and all packets from hosts are forwarded to the IP address owner.

To specify the type of MAC addresses mapped to virtual IPv6 addresses:

Step Command

1. Enter system view.

2. Specify the type of MAC addresses mapped to virtual

IPv6 addresses. system-view vrrp ipv6 method { real-mac | virtual-mac }

Remarks

N/A

Optional.

Virtual MAC address by default.

Creating a VRRP group and configuring a virtual IPv6 address

When creating a VRRP group, configure a virtual IPv6 address for the VRRP group. You can configure multiple virtual IPv6 addresses for a VRRP group.

A VRRP group is automatically created when you specify the first virtual IPv6 address for the VRRP group.

If you specify another virtual IPv6 address for the VRRP group later, the virtual IPv6 address is added to the virtual IPv6 address list of the VRRP group.

Configuration guidelines

Do not create VRRP groups on the VLAN interface of a super VLAN. Otherwise, network performance can be adversely affected.

When a router is the IP address owner in a VRRP group, HP recommends that you not configure the ospfv3 area command on the interface to use the IPv6 address of the interface or the virtual IPv6 address of the VRRP group to establish an OSPFv3 neighbor relationship with the adjacent router.

For more information about the ospfv3 area command, see Layer 3—IP Routing Command

Reference.

A VRRP group is removed after you remove all its virtual IPv6 addresses and all of its configurations become invalid.

Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the collision, change the IPv6 address of the interface on the IP address owner before you remove the

VRRP group from the interface.

Configuration prerequisites

Before you create a VRRP group and configure a virtual IPv6 address on an interface, configure an IPv6 address for the interface. Make sure that it is in the same network segment as the virtual IPv6 address.

Configuration procedure

To create a VRRP group and configure its virtual IPv6 address:

137

Step Command

1. Enter system view. system-view

2. Enter the specified interface view. interface interface-type

interface-number

Remarks

N/A

N/A

3. Create a VRRP group and configure its virtual IPv6 address, which is a link local address.

4. Configure the VRRP group with a virtual IPv6 address, which is a global unicast address. vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address link-local vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address

By default, no VRRP group is created.

The first virtual IPv6 address of the

VRRP group must be a link local address. Only one link local address is allowed in a VRRP group, and must be removed the last.

Optional.

By default, no global unicast address is configured as the virtual

IPv6 address of a VRRP group.

Configuring router priority, preemptive mode, and tracking function

This section covers router priority, preemptive mode, and the tracking function.

Configuration guidelines

The running priority of an IP address owner is always 255. You do not need to configure it. An IP address owner always operates in preemptive mode.

Interface tracking is not configurable on an IP address owner.

If you configure an interface to be tracked or a track entry to be monitored on a router that is the IP address owner in a VRRP group, the configuration does not take effect. If the router is not the IP address owner in the VRRP group later, the configuration takes effect.

If the state of a tracked interface changes from down or removed to up, the priority of the router that owns the interface automatically restores.

If the state of a track entry changes from negative or invalid to positive, the priority of the router where the track entry is configured automatically restores.

Configuration prerequisites

Before you configure router priority, preemptive mode and tracking function, create a VRRP group and configure its virtual IPv6 address.

Configuration procedure

The router priority, preemptive mode, and the track function determine which router in the VRRP group serves as the master.

To configure router priority, preemptive mode, and interface tracking:

Step Command

1. Enter system view. system-view

Remarks

N/A

138

Step Command

2. Enter the specified interface view. interface interface-type

interface-number

3. Configure the priority of the router in the VRRP group.

4. Configure the router in the

VRRP group to operate in preemptive mode and configure preemption delay of the VRRP group.

5. Configure the interface to be tracked.

6. Configure VRRP to monitor a specified track entry.

Remarks

N/A vrrp ipv6 vrid virtual-router-id priority priority-value vrrp ipv6 vrid virtual-router-id preempt-mode [ timer delay

delay-value ]

Optional.

The default is 100.

Optional.

The router in the VRRP group operates in preemptive mode and the preemption delay is 0 seconds by default. vrrp ipv6 vrid virtual-router-id track interface interface-type

interface-number [ reduced

priority-reduced ]

Optional.

By default, no interface is being tracked. vrrp ipv6 vrid virtual-router-id track

track-entry-number [ reduced

priority-reduced | switchover ]

Optional.

By default, VRRP is not configured to monitor a specified track entry.

Configuring VRRP packet attributes

This section describes how to configure VRRP packet attributes.

Configuration guidelines

You can configure different authentication modes and authentication keys for the VRRP groups on an interface. However, members of the same VRRP group must use the same authentication mode and authentication key.

Excessive traffic can cause a backup to trigger a change of its status, because the backup does not receive any VRRP advertisements for the specified period of time. To solve this problem, increase the time interval for sending VRRP advertisements.

Configuring different intervals for sending VRRP advertisements on the routers in a VRRP group can cause a backup to trigger a change of its status, because the backup does not receive any VRRP advertisements for the specified period of time. To solve this problem, configure the same interval for sending VRRP advertisements on each router in the VRRP group.

Configuration prerequisites

Before you configure VRRP packet attributes, create a VRRP group and configure a virtual IPv6 address.

139

Configuration procedure

To configure VRRP packet attributes:

Step Command

1. Enter system view.

2. Configure the DSCP priority of

VRRP packets. system-view vrrp ipv6 dscp dscp-value

Remarks

N/A

Optional.

By default, the DSCP priority of

VRRP packets is 56.

This command is available in

Release 1203 and later versions.

3. Enter the specified interface view.

4. Configure the authentication mode and authentication key when the VRRP groups send or receive VRRP packets.

5. Configure the time interval for the master in the VRRP group to send VRRP advertisement. interface interface-type

interface-number vrrp ipv6 vrid virtual-router-id authentication-mode simple

[ cipher ] key vrrp ipv6 vrid virtual-router-id timer advertise adver-interval

N/A

Optional.

By default, no authentication is performed.

Optional.

The default is 100 centiseconds.

Displaying and maintaining VRRP for IPv6

Task Command

Display VRRP group status. display vrrp ipv6 [ verbose ] [ interface

interface-type interface-number [ vrid

virtual-router-id ] ] [ | { begin | exclude | include } regular-expression ]

Display VRRP group statistics.

Clear VRRP group statistics. display vrrp ipv6 statistics [ interface

interface-type interface-number [ vrid

virtual-router-id ] ] [ | { begin | exclude | include } regular-expression ] reset vrrp ipv6 statistics [ interface

interface-type interface-number [ vrid

virtual-router-id ] ]

Remarks

Available in any view.

Available in any view.

Available in user view.

IPv4 VRRP configuration examples

This section provides examples for IPv4 VRRP configuration on switches.

Single VRRP group configuration example

Network requirements

Switch A and Switch B form a VRRP group and use the virtual IP address 202.38.160.111/24 to provide gateway service for the LAN where Host A resides.

140

Switch A operates as the master to forward packets from Host A to Host B. When Switch A fails,

Switch B takes over to forward packets for Host A.

Figure 35 Network diagram

Configuration procedure

1. Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] vlan 2

[SwitchA-vlan2] port gigabitethernet 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0

# Create VRRP group 1 and set its virtual IP address to 202.38.160.111.

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111

# Assign Switch A higher priority than Switch B so Switch A can become the master.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

# Configure Switch A to operate in preemptive mode so that it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.

[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5

2. Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] vlan 2

[SwitchB-Vlan2] port gigabitethernet 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0

# Create VRRP group 1 and set its virtual IP address to 202.38.160.111.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111

# Set Switch B to operate in preemptive mode and set the preemption delay to five seconds.

141

[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5

Verifying the configuration

After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp verbose command.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : None

Virtual IP : 202.38.160.111

Virtual MAC : 0000-5e00-0101

Master IP : 202.38.160.1

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Become Master : 4200ms left

Auth Type : None

Virtual IP : 202.38.160.111

Master IP : 202.38.160.1

The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from Host

A to Host B.

When Switch A fails, you can successfully ping Host B on Host A. Use the display vrrp verbose command to view detailed information about the VRRP group on Switch B.

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

142

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Auth Type : None

Virtual IP : 202.38.160.111

Virtual MAC : 0000-5e00-0101

Master IP : 202.38.160.2

The output shows that when Switch A fails, Switch B becomes the master to forward packets from Host A to Host B.

# After Switch A resumes normal operation, display detailed information about VRRP group 1 on Switch

A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : None

Virtual IP : 202.38.160.111

Virtual MAC : 0000-5e00-0101

Master IP : 202.38.160.1

The output shows that after Switch A resumes normal operation, it becomes the master to forward packets from Host A to Host B.

VRRP interface tracking configuration example

Network requirements

As shown in Figure 36 , Switch A and Switch B form a VRRP group and use the virtual IP address

202.38.160.111/24 to provide gateway service for the LAN where Host A resides.

Switch A operates as the master to forward packets from Host A to Host B. When VLAN-interface

3 used by Switch A to provide gateway service fails, Switch B takes over to forward packets for Host

A.

Configure Switch A and Switch B to authenticate VRRP packets to prevent fabricated packets. Set the authentication mode to plain text and the authentication key to hello.

143

Figure 36 Network diagram

Virtual IP address:

202.38.160.111/24

GE1/0/5

Vlan-int2

202.38.160.1/24

Vlan-int3

Switch A

202.38.160.3/24

Internet

203.2.3.1/24

Host B

Host A

GE1/0/5

Vlan-int2

202.38.160.2/24

Switch B

Configuration procedure

1. Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] vlan 2

[SwitchA-vlan2] port gigabitethernet 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0

# Create a VRRP group 1 and set its virtual IP address to 202.38.160.111.

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111

# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

# Configure the authentication mode of the VRRP group as simple and the authentication key as hello.

[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello

# Set the interval for the master to send VRRP advertisement to four seconds.

[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 4

# Configure Switch A to operate in preemptive mode, so it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.

[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5

# Configure VLAN-interface 3 as a tracked interface and set the reduced priority to 30 so when

VLAN-interface 3 fails, the priority of Switch A drops below 100 and Switch B takes over.

[SwitchA-Vlan-interface2] vrrp vrid 1 track interface vlan-interface 3 reduced 30

2. Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] vlan 2

144

[SwitchB-vlan2] port gigabitethernet 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0

# Create a VRRP group 1 and set its virtual IP address to 202.38.160.111.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111

# Configure the authentication mode of the VRRP group as simple and the authentication key as hello.

[SwitchB-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello

# Set the interval for the master to send VRRP advertisement to four seconds.

[SwitchB-Vlan-interface2] vrrp vrid 1 timer advertise 4

# Configure Switch B to operate in preemptive mode, so Switch B can become the master after the priority of Switch A decreases below 100. Configure the preemption delay as five seconds to avoid frequent status switchover.

[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5

Verifying the configuration

After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp verbose command.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 4

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : Simple Key : ******

Virtual IP : 202.38.160.111

Virtual MAC : 0000-5e00-0101

Master IP : 202.38.160.1

VRRP Track Information:

Track Interface: Vlan3 State : Up Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 4

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

145

Become Master : 2200ms left

Auth Type : Simple Key : ******

Virtual IP : 202.38.160.111

Master IP : 202.38.160.1

The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from Host

A to Host B.

If interface VLAN-interface 3 through which Switch A connects to the Internet is not available, you can still ping Host B successfully on Host A. To display detailed information about the VRRP group, use the display vrrp verbose command.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 4

Admin Status : Up State : Backup

Config Pri : 110 Running Pri : 80

Preempt Mode : Yes Delay Time : 5

Become Master : 2200ms left

Auth Type : Simple Key : ******

Virtual IP : 202.38.160.111

Master IP : 202.38.160.2

VRRP Track Information:

Track Interface: Vlan3 State : Down Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 4

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Auth Type : Simple Key : ******

Virtual IP : 202.38.160.111

Virtual MAC : 0000-5e00-0101

Master IP : 202.38.160.2

The output shows that when VLAN-interface 3 on Switch A is not available, the priority of Switch A is reduced to 80 and it becomes the backup. Switch B becomes the master to forward packets from Host A to Host B.

146

VRRP with multiple VLANs configuration example

Network requirements

Switch A and Switch B form two VRRP groups. VRRP group 1 uses virtual IP address

202.38.160.100/25 to provide gateway service for hosts in VLAN 2, and VRRP group 2 uses virtual

IP address 202.38.160.200/25 to provide gateway service for hosts in VLAN 3.

Assign Switch A higher priority than Switch B in VRRP group 1 but lower priority in VRRP group 2 to distribute the traffic from VLAN 2 and VLAN 3 between the two switches. When one of the switches fails, the healthy switch provides gateway service for both VLANs.

Figure 37 Network diagram

VLAN 2

Gateway:

202.38.160.100/25

Virtual IP address 1:

202.38.160.100/25

GE1/0/5

Vlan-int2

202.38.160.1/25

GE1/0/6

Vlan-int3

202.38.160.130/25

Switch A

VLAN 3

Gateway:

202.38.160.200/25

GE1/0/5

Vlan-int2

202.38.160.2/25

GE1/0/6

Vlan-int3

202.38.160.131/25

Switch B

Virtual IP address 2:

202.38.160.200/25

Configuration procedure

1. Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] vlan 2

[SwitchA-vlan2] port gigabitethernet 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.128

# Create a VRRP group 1 and set its virtual IP address to 202.38.160.100.

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.100

# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master in the group.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

[SwitchA-Vlan-interface2] quit

# Configure VLAN 3.

[SwitchA] vlan 3

[SwitchA-vlan3] port gigabitethernet 1/0/6

[SwitchA-vlan3] quit

[SwitchA] interface vlan-interface 3

[SwitchA-Vlan-interface3] ip address 202.38.160.130 255.255.255.128

147

Internet

# Create a VRRP group 2 and set its virtual IP address to 202.38.160.200.

[SwitchA-Vlan-interface3] vrrp vrid 2 virtual-ip 202.38.160.200

2. Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] vlan 2

[SwitchB-vlan2] port gigabitethernet 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.128

# Create a VRRP group 1 and set its virtual IP address to 202.38.160.100.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.100

[SwitchB-Vlan-interface2] quit

# Configure VLAN 3.

[SwitchB] vlan 3

[SwitchB-vlan3] port gigabitethernet 1/0/6

[SwitchB-vlan3] quit

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] ip address 202.38.160.131 255.255.255.128

# Create VRRP group 2 and set its virtual IP address to 202.38.160.200.

[SwitchB-Vlan-interface3] vrrp vrid 2 virtual-ip 202.38.160.200

# Assign Switch B a higher priority than Switch A in VRRP group 2 so Switch B can become the master in the group.

[SwitchB-Vlan-interface3] vrrp vrid 2 priority 110

Verifying the configuration

To verify your configuration, use the display vrrp verbose command.

# Display detailed information about the VRRP groups on Switch A.

[SwitchA-Vlan-interface3] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 2

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 202.38.160.100

Virtual MAC : 0000-5e00-0101

Master IP : 202.38.160.1

Interface Vlan-interface3

VRID : 2 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

148

Become Master : 2200ms left

Auth Type : None

Virtual IP : 202.38.160.200

Master IP : 202.38.160.131

# Display detailed information about the VRRP groups on Switch B.

[SwitchB-Vlan-interface3] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 2

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

Virtual IP : 202.38.160.100

Master IP : 202.38.160.1

Interface Vlan-interface3

VRID : 2 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 202.38.160.200

Virtual MAC : 0000-5e00-0102

Master IP : 202.38.160.131

The output shows that Switch A is operating as the master in VRRP group 1 to forward Internet traffic for the hosts that use the default gateway 202.38.160.100/25. Switch B is operating as the master in VRRP group 2 to forward Internet traffic for the hosts that use the default gateway 202.38.160.200/25.

IPv6 VRRP configuration examples

This section provides a configuration example or IPv6 VRRP.

Single VRRP group configuration example

Network requirements

Switch A and Switch B form a VRRP group and use the virtual IPv6 addresses 1::10/64 and

FE80::10 to provide gateway service for the LAN where Host A resides.

Host A learns 1::10/64 as its default gateway from the RA messages sent by the switches.

Switch A operates as the master to forward packets from Host A to Host B. When Switch A fails,

Switch B takes over to forward packets for Host A.

149

Figure 38 Network diagram

Configuration procedure

1. Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] ipv6

[SwitchA] vlan 2

[SwitchA-vlan2] port gigabitethernet 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ipv6 address fe80::1 link-local

[SwitchA-Vlan-interface2] ipv6 address 1::1 64

# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10

# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110

# Configure Switch A to operate in preemptive mode so it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5

# Enable Switch A to send RA messages so Host A can learn the default gateway address.

[SwitchA-Vlan-interface2] undo ipv6 nd ra halt

2. Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] ipv6

[SwitchB] vlan 2

[SwitchB-vlan2] port gigabitethernet 1/0/5

[SwitchB-vlan2] quit

150

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local

[SwitchB-Vlan-interface2] ipv6 address 1::2 64

# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10

# Configure Switch B to operate in preemptive mode and set the preemption delay to five seconds.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5

# Enable Switch B to send RA messages, so Host A can learn the default gateway address.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5

Verifying the configuration

After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp ipv6 verbose command.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 100

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : None

Virtual IP : FE80::10

1::10

Virtual MAC : 0000-5e00-0201

Master IP : FE80::1

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 100

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Become Master : 4200ms left

Auth Type : None

Virtual IP : FE80::10

1::10

Master IP : FE80::1

151

The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from Host

A to Host B.

When Switch A fails, you can still successfully ping Host B on Host A. To view the detailed information about the VRRP group on Switch B, use the display vrrp ipv6 verbose command.

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 100

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Auth Type : None

Virtual IP : FE80::10

1::10

Virtual MAC : 0000-5e00-0201

Master IP : FE80::2

The output shows that when Switch A fails, Switch B takes over to forward packets from Host A to Host B.

# After Switch A resumes normal operation, use the display vrrp ipv6 verbose command to display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 100

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : None

Virtual IP : FE80::10

1::10

Virtual MAC : 0000-5e00-0201

Master IP : FE80::1

The output shows that after Switch A resumes normal operation, it becomes the master to forward packets from Host A to Host B.

VRRP interface tracking configuration example

Network requirements

As shown in Figure 39 , Switch A and Switch B form a VRRP group and use the virtual IP addresses

1::10/64 and FE80::10 to provide gateway service for the LAN where Host A resides.

152

Host A learns 1::10/64 as its default gateway from the RA messages sent by the switches.

Switch A operates as the master to forward packets from Host A to Host B. When VLAN-interface

3 used by Switch A to provide gateway service fails, Switch B takes over to forward packets for Host

A.

Configure Switch A and Switch B to authenticate VRRP packets to prevent fabricated packets. Set the authentication mode to plain text and the authentication key to hello.

Figure 39 Network diagram

Configuration procedure

1. Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] ipv6

[SwitchA] vlan 2

[SwitchA-vlan2] port gigabitethernet 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ipv6 address fe80::1 link-local

[SwitchA-Vlan-interface2] ipv6 address 1::1 64

# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10

# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110

# Set the authentication mode for VRRP group 1 to simple and the authentication key to hello.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 authentication-mode simple hello

# Set the VRRP advertisement interval to 400 centiseconds.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 timer advertise 400

# Configure Switch A to operate in preemptive mode, so it can become the master whenever it operates properly. Configure the preemption delay as five seconds to avoid frequent status switchover.

153

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5

# Configure VLAN-interface 3 as a tracked interface and set the reduced priority to 30 so when

VLAN-interface 3 fails, the priority of Switch A drops below 100 and Switch B takes over.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 track interface vlan-interface 3 reduced

30

# Enable Switch A to send RA messages so Host A can learn the default gateway address.

[SwitchA-Vlan-interface2] undo ipv6 nd ra halt

2. Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] ipv6

[SwitchB] vlan 2

[SwitchB-vlan2] port gigabitethernet 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local

[SwitchB-Vlan-interface2] ipv6 address 1::2 64

# Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10

# Set the authentication mode for VRRP group 1 to simple and the authentication key to hello.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 authentication-mode simple hello

# Set the VRRP advertisement interval to 400 centiseconds.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 timer advertise 400

# Configure Switch B to operate in preemptive mode, so it B can become the master after the priority of Switch A drops below 100. Configure the preemption delay as five seconds to avoid frequent status switchover.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5

# Enable Switch B to send RA messages so Host A can learn the default gateway address.

[SwitchB-Vlan-interface2] undo ipv6 nd ra halt

Verifying the configuration

After the configuration, Host B can be pinged successfully on Host A. To verify the configuration, use the display vrrp ipv6 verbose command.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 400

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : Simple Key : ******

Virtual IP : FE80::10

154

1::10

Virtual MAC : 0000-5e00-0201

Master IP : FE80::1

VRRP Track Information:

Track Interface: Vlan3 State : Up Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 400

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Become Master : 4200ms left

Auth Type : Simple Key : ******

Virtual IP : FE80::10

1::10

Master IP : FE80::1

The output shows that Switch A is operating as the master in VRRP group 1 to forward packets from Host

A to Host B.

When interface VLAN-interface 3 on Switch A is not available, you can ping Host B successfully on Host

A. To view the detailed information about the VRRP group, use the display vrrp ipv6 verbose command.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 400

Admin Status : Up State : Backup

Config Pri : 110 Running Pri : 80

Preempt Mode : Yes Delay Time : 5

Become Master : 4200ms left

Auth Type : Simple Key : ******

Virtual IP : FE80::10

1::10

Master IP : FE80::2

VRRP Track Information:

Track Interface: Vlan3 State : Down Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

155

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 400

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Auth Type : Simple Key : ******

Virtual IP : FE80::10

1::10

Virtual MAC : 0000-5e00-0201

Master IP : FE80::2

The output shows that when VLAN-interface 3 on Switch A is not available, the priority of Switch A is reduced to 80, and Switch A becomes the backup. Switch B becomes the master and packets sent from

Host A to Host B are forwarded by Switch B.

VRRP with multiple VLANs configuration example

Network requirements

As shown in Figure 40

, Switch A and Switch B form two VRRP groups. VRRP group 1 uses virtual

IPv6 addresses 1::10/64 and FE80::10 to provide gateway service for hosts in VLAN 2, and VRRP group 2 uses virtual IPv6 addresses 2::10/64 and FE90::10 to provide gateway service for hosts in

VLAN 3.

Hosts in VLAN 2 learn 1::10/64 as their default gateway and hosts in VLAN 3 learn 2::10/64 as their default gateway from the RA messages sent by the switches.

Assign Switch A higher priority than Switch B in VRRP group 1 but lower priority in VRRP group 2 to distribute the traffic from VLAN 2 and VLAN 3 between the two switches. When one of the switches fails, the healthy switch provides gateway service for both VLANs.

Figure 40 Network diagram

156

Configuration procedure

1. Configure Switch A:

# Configure VLAN 2.

<SwitchA> system-view

[SwitchA] ipv6

[SwitchA] vlan 2

[SwitchA-vlan2] port gigabitethernet 1/0/5

[SwitchA-vlan2] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] ipv6 address fe80::1 link-local

[SwitchA-Vlan-interface2] ipv6 address 1::1 64

# Create VRRP group 1 and set its virtual IPv6 addresses to FE80::10 to 1::10.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10

# Assign Switch A higher priority than Switch B in VRRP group 1 so Switch A can become the master in the group.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110

[SwitchA-Vlan-interface2] quit

# Enable Switch A to send RA messages so hosts in VLAN 2 can learn the default gateway address.

[SwitchA-Vlan-interface2] undo ipv6 nd ra halt

[SwitchA-Vlan-interface2] quit

# Configure VLAN 3.

[SwitchA] vlan 3

[SwitchA-vlan3] port gigabitethernet 1/0/6

[SwitchA-vlan3] quit

[SwitchA] interface vlan-interface 3

[SwitchA-Vlan-interface3] ipv6 address fe90::1 link-local

[SwitchA-Vlan-interface3] ipv6 address 2::1 64

# Create VRRP group 2 and set its virtual IPv6 addresses to FE90::10 and 2::10.

[SwitchA-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip fe90::10 link-local

[SwitchA-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip 2::10

# Enable Switch A to send RA messages so hosts in VLAN 3 can learn the default gateway address.

[SwitchA-Vlan-interface3] undo ipv6 nd ra halt

2. Configure Switch B:

# Configure VLAN 2.

<SwitchB> system-view

[SwitchB] ipv6

[SwitchB-vlan2] port gigabitethernet 1/0/5

[SwitchB-vlan2] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local

[SwitchB-Vlan-interface2] ipv6 address 1::2 64

# Create VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local

157

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 virtual-ip 1::10

[SwitchB-Vlan-interface2] quit

# Enable Switch B to send RA messages so hosts in VLAN 2 can learn the default gateway address.

[SwitchB-Vlan-interface2] undo ipv6 nd ra halt

[SwitchB-Vlan-interface2] quit

# Configure VLAN 3.

[SwitchB] vlan 3

[SwitchB-vlan3] port gigabitethernet 1/0/6

[SwitchB-vlan3] quit

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] ipv6 address fe90::2 link-local

[SwitchB-Vlan-interface3] ipv6 address 2::2 64

# Create VRRP group 2 and set its virtual IPv6 addresses to FE90::10 and 2::10.

[SwitchB-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip fe90::10 link-local

[SwitchB-Vlan-interface3] vrrp ipv6 vrid 2 virtual-ip 2::10

# Assign Switch B a higher priority than Switch A in VRRP group 2 so Switch B can become the master in the group.

[SwitchB-Vlan-interface3] vrrp ipv6 vrid 2 priority 110

# Enable Switch B to send RA messages, so hosts in VLAN 3 can learn the default gateway address.

[SwitchB-Vlan-interface3] undo ipv6 nd ra halt

Verifying the configuration

To verify the configuration, use the display vrrp ipv6 verbose command.

# Display detailed information about the VRRP groups on Switch A.

[SwitchA-Vlan-interface3] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 2

Interface Vlan-interface2

VRID : 1 Adver Timer : 100

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : FE80::10

1::10

Virtual MAC : 0000-5e00-0201

Master IP : FE80::1

Interface Vlan-interface3

VRID : 2 Adver Timer : 100

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

158

Auth Type : None

Virtual IP : FE90::10

2::10

Master IP : FE90::2

# Display detailed information about the VRRP groups on Switch B.

[SwitchB-Vlan-interface3] display vrrp ipv6 verbose

IPv6 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 2

Interface Vlan-interface2

VRID : 1 Adver Timer : 100

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

Virtual IP : FE80::10

1::10

Master IP : FE80::1

Interface Vlan-interface3

VRID : 2 Adver Timer : 100

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : FE90::10

2::10

Virtual MAC : 0000-5e00-0202

Master IP : FE90::2

The output shows that Switch A is operating as the master in VRRP group 1 to forward Internet traffic for the hosts that use the default gateway 1::10/64, and Switch B is operating as the master in VRRP group

2 to forward Internet traffic for the hosts that use the default gateway 2::10/64.

Troubleshooting VRRP

The screen frequently displays error prompts

Symptom

The screen frequently displays error prompts.

Analysis

This error is probably caused by:

Inconsistent configuration of the devices in the VRRP group.

A device is attempting to send illegitimate VRRP packets.

159

Solution

In the first case, modify the configuration.

In the latter case, resort to non-technical measures.

Multiple masters are present in a VRRP group

Symptom

Multiple masters are present in a VRRP group.

Analysis

Multiple masters coexist for a short period. This is normal and requires no manual intervention.

Multiple masters coexist for a long period. This is because devices in the VRRP group cannot receive

VRRP packets, or the received VRRP packets are illegal.

Solution

Ping between these masters, and do the following:

If the ping fails, verify network connectivity.

If the ping succeeds, verify that their configurations are consistent in terms of number of virtual IP addresses, virtual IP addresses, advertisement interval, and authentication.

Frequent VRRP state transition

Symptom

Frequent VRRP state transition.

Analysis

The VRRP advertisement interval is set too short.

Solution

Increase the interval for sending VRRP advertisements or configure a preemption delay.

160

Configuring BFD

BFD provides a general-purpose, standard, medium-independent, and protocol-independent fast failure detection mechanism. This chapter describes the BFD working mechanism and configuration procedure.

Overview

Fault detection methods include:

Hardware detection—Detects link failures by sending hardware detection signals, such as SDH alarms.

Hardware detection can quickly detect link failures, but is media dependent.

Hello mechanism—Devices can use the hello mechanism of a routing protocol to detect link failures.

The hello mechanism takes seconds to detect a link failure. However, that detection rate is too slow for voice services and other delay-sensitive services. It is also too slow for high-speed data transmission, such as Gigabit data transmission, where a detection rate slower than one second can cause serious data loss.

Other detection methods—Some protocols provide dedicated detection mechanisms, which however, cannot be deployed for inter-system communications.

BFD provides a single mechanism to quickly detect and monitor the connectivity of links or IP forwarding in networks.

How BFD works

BFD can uniformly and quickly detect the failures of the bidirectional forwarding paths between two routers for protocols such as routing protocols and MPLS.

BFD provides no neighbor discovery mechanism. Protocols that BFD services notify BFD of routers to which it needs to establish sessions. After a session is established, if no BFD control packet is received from the peer within the negotiated BFD interval, BFD notifies a failure to the protocol, which then takes appropriate measures.

Establishing a BFD session

A BFD session begins with neighbor discovery on the network.

Figure 41 BFD session establishment (on OSPF routers)

As shown in Figure 41 , BFD sessions are established as follows:

161

1. A protocol sends Hello messages to discover neighbors and establish neighborships.

2. After establishing neighborships, the protocol notifies BFD of the neighbor information, including destination and source addresses.

3. BFD uses the information to establish BFD sessions.

Detecting BFD faults

Figure 42 BFD fault detection (on OSPF routers)

3

4

2

3

1

Router A

5

Router B

Fault

BFD neighbors

BFD notifies the OSPF link failure

Backup link

OSPF neighbors

As shown in Figure 42 , when BFD detects a fault, the following process occurs:

1. BFD detects a link failure.

2. BFD clears the neighbor session.

3. BFD notifies the protocol of the failure.

4. The protocol terminates the neighborship on the link.

5. If a backup link is available, the protocol uses it to forward packets.

NOTE:

No detection time resolution is defined in the BFD draft. Most devices supporting BFD provide detection measured in milliseconds.

BFD detection methods

Detection methods for BFD include:

Single-hop detection—Detects the IP connectivity between two directly connected systems.

Multi-hop detection—Detects any of the paths between two systems. These paths have multiple hops and can be overlapped.

Bidirectional detection—Sends detection packets at two sides of a bidirectional link to detect the bidirectional link status, finding link failures in milliseconds. (BFD LSP detection is a special case, in which BFD control packets are sent in one direction, and the peer device reports the link status through other links.)

BFD session modes

Session modes for BFD include:

Control packet mode—Both ends of the link exchange BFD control packets to monitor link status.

162

Echo packet mode—One end of the link sends Echo packets to the other end, which then forwards the packets back to the originating end. This mode monitors link status in both directions.

BFD operating modes

Before a BFD session is established, BFD has two operating modes, active and passive.

Active mode—BFD actively sends BFD control packets regardless of whether any BFD control packet is received from the peer.

Passive mode—BFD does not send control packets until a BFD control packet is received from the peer.

At least one end must operate in active mode for a BFD session to be established.

After a BFD session is established, both ends periodically send BFD control packets to each other. BFD considers that the session is down if it receives no BFD control packets within a specific interval.

When a BFD session is maintained by sending Echo packets, the session is independent of the operating mode.

Dynamic BFD parameter changes

After a BFD session is established, both ends can negotiate the related BFD parameters, such as the minimum transmit interval, minimum receive interval, and initialization mode. After that, both ends use the negotiated parameters, without affecting the current session state.

BFD packet format

BFD control packets are encapsulated into UDP packets with port number 3784 for single-hop detection or port number 4784 for multi-hop detection (also can be 3784 based on the configuration task.) BFD echo packets have a similar format as BFD control packets with UDP port number 3785 except that the Desired

Min TX Interval and Required Min RX Interval fields are null. Figure 43

illustrates the packet format.

Figure 43 BFD packet format

Vers—Protocol version. The protocol version is 1.

Diag—This bit indicates the reason for the last transition of the local session from up to some other state.

Table 19

lists the states.

Table 19 Diag bit values

Diag Description

1

2

Control detection time expired.

Echo function failed.

163

Diag Description

3 Neighbor signaled session down.

4 Forwarding plane reset.

8 Reverse concatenated path down.

9–31 Reserved for future use.

State (Sta)—Current BFD session state. Its value can be 0 for AdminDown, 1 for Down, 2 for Init, and

3 for Up.

Poll (P)—If set, the transmitting system is requesting verification of connectivity, or of a parameter change. If clear, the transmitting system is not requesting verification of the configuration.

Final (F)—If set, the transmitting system is responding to a received BFD control packet that had the Poll

(P) bit set. If clear, the transmitting system is not responding to a Poll.

Control Plane Independent (C)—If set, the transmitting system's BFD implementation does not share fate with its control plane. BFD is implemented in the forwarding plane and can continue to function through disruptions in the control plane. If clear, the transmitting system's BFD implementation shares fate with its control plane.

Authentication Present (A)—If set, the Authentication Section is present and the session is to be authenticated.

Demand (D)—If set, Demand mode is active in the transmitting system. The system would like to operate in Demand mode, knows that the session is up in both directions, and is directing the remote system to stop the periodic transmission of BFD control packets. If clear, Demand mode is not active in the transmitting system.

Reserved (R)—This byte must be set to zero on transmit, and ignored on receipt.

Detect Mult—Detection time multiplier.

Length—Length of the BFD control packet, in bytes.

My Discriminator—A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems.

Your Discriminator—The discriminator received from the remote system. This field reflects back the received value of My Discriminator, or is 0 if that value is unknown.

Desired Min TX Interval—The minimum interval (in milliseconds) that the local system would like to use when transmitting BFD control packets. The value zero is reserved.

Required Min RX Interval—The minimum interval (in milliseconds) between received BFD control packets that this system is capable of supporting. If this value is zero, the transmitting system does not want the remote system to send any periodic BFD control packets.

Required Min Echo RX Interval—The minimum interval (in milliseconds) between received BFD echo packets that this system is capable of supporting. If this value is zero, the transmitting system does not support the receipt of BFD echo packets.

Auth Type—The authentication type in use, if the Authentication Present (A) bit is set.

Auth Len—The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields.

164

Supported features

OSPF. For more information, see Layer 3—IP Routing Configuration Guide.

OSPFv3. For more information, see Layer 3—IP Routing Configuration Guide.

IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.

IPv6 IS-IS. For more information, see Layer 3—IP Routing Configuration Guide.

RIP. For more information, see Layer 3—IP Routing Configuration Guide.

Static routing. For more information, see Layer 3—IP Routing Configuration Guide.

BGP. For more information, see Layer 3—IP Routing Configuration Guide.

IPv6 BGP. For more information, see Layer 3—IP Routing Configuration Guide.

PIM. For more information, see IP Multicast Configuration Guide.

MPLS. For more information, see MPLS Configuration Guide.

Track. For more information, see "

Configuring track ."

IP fast reroute (FRR). IP FRR is supported by OSPF, RIP, IS-IS and static routing. For more information, see

Layer 3—IP Routing Configuration Guide.

Protocols and standards

RFC 5880, Bidirectional Forwarding Detection (BFD)

RFC 5881, Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)

RFC 5882, Generic Application of Bidirectional Forwarding Detection (BFD)

RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths

RFC 5884, Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)

RFC 5885, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity

Verification (VCCV)

Configuring BFD basic functions

The BFD basic function configuration is the basis for configuring BFD for other protocols.

Before configuring BFD basic functions, complete the following tasks:

Configure the network layer addresses of the interfaces so that adjacent nodes are reachable to each other at the network layer.

The term "interface" in BFD collectively refers to Layer 3 interfaces, including VLAN interfaces and

Layer 3 Ethernet interfaces. You can set an Ethernet port as a Layer 3 interface by using the port link-mode route command (see Layer 2—LAN Switching Configuration Guide).

Configure the routing protocols that support BFD.

To configure BFD basic functions:

Step Command

1. Enter system view. system-view

2. Specify the mode for establishing a BFD session. bfd session init-mode { active | passive }

Remarks

N/A

Optional.

The default is active.

165

Step Command

3. Configure the destination port number for multi-hop BFD control packets. bfd multi-hop destination-port

port-number

Remarks

Optional.

The default is 4784.

4. Configure the source IP address of echo packets. bfd echo-source-ip ip-address

Optional.

The source IP address should not be on the same network segment as any local interface's IP address.

Otherwise, a large number of

ICMP redirect packets may be sent from the peer, resulting in link congestion.

5. Enter interface view. interface interface-type

interface-number

N/A

6. Configure the minimum interval for receiving BFD echo packets. bfd min-echo-receive-interval

value

7. Configure the minimum interval for transmitting BFD control packets. bfd min-transmit-interval value

Optional.

For more information, see the description of the Required Min

Echo RX Interval field in "

BFD packet format ."

The default is 400 milliseconds.

Optional.

For more information, see the description of the Desired Min TX

Interval field in " BFD packet format

."

The default is 400 milliseconds.

8. Configure the minimum interval for receiving BFD control packets. bfd min-receive-interval value

Optional.

For more information, see the description of the Required Min RX

Interval field in " BFD packet format

."

The default is 400 milliseconds.

9. Configure the detection time multiplier. bfd detect-multiplier value

Optional.

For more information, see the description of the Detect Mult field in "

BFD packet format

."

5 by default.

In Figure 41 , if you configure the Desired Min TX Interval as 100 milliseconds, Required Min RX Interval as

300 milliseconds, and Detect Mult as 5 on Router A, and then configure the Desired Min TX Interval as 150 milliseconds, Required Min RX Interval as 400 milliseconds, and Detect Mult as 10 on Router B.

The actual transmitting interval on Router A is 400 milliseconds, which is the greater value between the minimum interval for transmitting BFD control packets on Router A (100 milliseconds) and the minimum interval for receiving BFD control packets on Router B (400 milliseconds).

The actual transmitting interval on Router B is 300 milliseconds, which is the greater value between the minimum interval for transmitting BFD control packets on Router B (150 milliseconds) and the minimum interval for receiving BFD control packets on Router A (300 milliseconds).

166

The actual detection time on Router A is 3000 milliseconds, which is 10 × 300 milliseconds (Detect

Mult on Router B × actual transmitting interval on Router B).

The actual detection time on Router B is 2000 milliseconds, which is 5 × 400 milliseconds (Detect Mult on Router A × actual transmitting interval on Router A).

Displaying and maintaining BFD

Task Command

Display information about

BFD-enabled interfaces. display bfd interface [ verbose ] [ |

{ begin | exclude | include }

regular-expression ]

Display information about enabled

BFD debugging.

Display BFD session information (in standalone mode).

Display BFD session information (in

IRF mode).

Remarks

Available in any view. display bfd debugging-switches [ |

{ begin | exclude | include }

regular-expression ]

Available in any view. display bfd session [ slot slot-number

[ all | verbose ] | verbose ] [ | { begin | exclude | include } regular-expression ]

Available in any view. display bfd session [ chassis

chassis-number slot slot-number [ all | verbose ] | verbose ] [ | { begin | exclude | include } regular-expression ]

Available in any view.

Clear BFD session statistics (in standalone mode). reset bfd session statistics [ slot

slot-number ]

Available in user view.

Clear BFD session statistics (in IRF mode). reset bfd session statistics [ chassis

chassis-number slot slot-number ]

Available in user view.

167

Configuring track

This chapter describes how to configure track.

Track overview

The track module implements collaboration by establishing associations between application modules

and detection modules, as shown in Figure 44

.

Collaboration is enabled after you associate the track module with a detection module and an application module, respectively. The detection module monitors specific objects, such as interface status, link status, network reachability, and network performance, and informs the track module of detection results. The track module sends the detection results to the associated application module, and the application module takes actions when the tracked object changes its state.

Figure 44 Collaboration through the track module

Detection modules

Application modules

NQA

Associates with a detection entry

BFD

Interface management

Sends the detection result

Track module

Associates with a track entry

Sends the track entry status

VRRP

Static routing

Policy-based routing

Collaboration fundamentals

The track module collaborates with detection modules and application modules:

Collaboration between the track module and a detection module

Collaboration between the track module and an application module

Collaboration between the track module and a detection module

The detection module sends the detection result of the associated tracked object to the track module, which then changes the status of the track entry:

If the tracked object functions normally, such as the target interface is up or the target network is reachable, the state of the track entry is Positive.

If the tracked object functions abnormally, such as the target interface is down or the target network is unreachable, the state of the track entry is Negative.

If the detection result is not valid, such as the NQA test group that is associated with the track entry does not exist, the state of the track entry is Invalid.

The following detection modules can be associated with the track module:

NQA

168

BFD

Interface management module

Collaboration between the track module and an application module

When the status of the track entry changes, the track module notifies the associated application module, which then takes proper actions.

The following application modules can be associated with the track module:

VRRP

Static routing

Policy-based routing

In some cases, when the status of a track entry changes, if the track module immediately notifies the application modules, communication may be interrupted because routes cannot be recovered in time.

For example, the master in a VRRP group monitors the uplink interface through the track module. When the uplink interface fails, the track module notifies the master to reduce its priority so that a backup with a higher priority can preempt as the master to forward packets. When the uplink interface recovers, if the track module immediately notifies the original master to restore its priority, the master immediately will forward packets. However, the uplink route has not been recovered yet, which may result in packet forwarding failure. Configure the track module to notify the application modules of the track entry status change after a specified delay time.

Collaboration application example

The following is an example of collaboration between NQA, track, and static routing.

Configure a static route with next hop 192.168.0.88 on the device. If the next hop is reachable, the static route is valid. If the next hop becomes unreachable, the static route should become invalid. For this purpose, configure collaboration between the NQA, track, and static routing modules:

1. Create an NQA test group to monitor the accessibility of IP address 192.168.0.88.

2. Create a track entry and associate it with the NQA test group. When the next hop 192.168.0.88 is reachable, the track entry is in Positive state. When the next hop becomes unreachable, the track entry is in Negative state.

3. Associate the track entry with the static route. When the track entry turns to Positive state, the static route is valid. When the associated track entry turns to Negative state, the static route is invalid.

Track configuration task list

To implement the collaboration function, establish associations between the track module and the detection modules, and between the track module and the application modules.

Task Remarks

Associating track with NQA

Associating the track module with a detection module

Associating track with BFD

Associating track with interface management

Required.

Use one of the approaches.

169

Task Remarks

Associating track with VRRP

Associating the track module with an application module

Associating track with static routing

Associating track with PBR

Required.

Use one of the approaches.

Associating the track module with a detection module

This section provides instructions for associating the track module with a detection module.

Associating track with NQA

An NQA test group periodically detects whether a destination is reachable or whether the TCP connection to a TCP server can be set up. When associated with a track entry, an NQA test group functions as follows:

If the consecutive failures reach the specified threshold, the NQA module tells the track module that the tracked object is unreachable. The track module then sets the track entry to Negative state.

If the specified threshold is not reached, the NQA module tells the track module that the tracked object functions normally. The track module then sets the track entry to Positive state.

For more information about NQA, see Network Management and Monitoring Configuration Guide.

To associate track with NQA:

Step Command

1. Enter system view. system-view

2. Create a track entry, associate it with an NQA reaction entry, and specify the delay time for the track module to notify the associated application module when the track entry status changes. track track-entry-number nqa entry

admin-name operation-tag reaction

item-number [ delay { negative

negative-time | positive

positive-time } * ]

Remarks

N/A

By default, no track entry is created.

If the specified NQA test group or the reaction entry in the track entry does not exist, the status of the track entry is Invalid.

Associating track with BFD

BFD supports the control packet mode and echo packet mode. Only echo-mode BFD can be associated with a track entry.

When associated with a track entry, the BFD functions as follows:

If BFD detects that the link fails, it informs the track entry of the link failure. The track module then sets the track entry to Negative state.

If BFD detects that the link is normal, the track module sets the track entry to Positive state.

For more information about BFD, see " Configuring BFD ."

170

Configuration prerequisites

Before you associate track with BFD, configure the source address of the BFD echo packets.

Configuration procedure

To associate track with BFD:

Step Command

1. Enter system view. system-view

2. Create a track entry, associate it with the BFD session, and specify the delay time for the track module to notify the associated application module when the track entry status changes. track track-entry-number bfd echo interface interface-type

interface-number remote ip

remote-ip local ip local-ip [ delay

{ negative negative-time | positive

positive-time } * ]

Remarks

N/A

By default, no track entry is created.

When you associate track with

BFD, do not configure the virtual IP address of a VRRP group as the local or remote address of a BFD session.

Associating track with interface management

The interface management module monitors the physical status or network-layer protocol status of the interface. When associated with a track entry, the interface management module functions as follows:

When the physical or network-layer protocol status of the interface changes to up, the interface management module informs the track module of the change and the track module sets the track entry to Positive.

When the physical or network-layer protocol status of the interface changes to down, the interface management module informs the track module of the change and the track module sets the track entry to Negative.

To associate track with interface management:

Step Command

1. Enter system view. system-view

2. Associating track with interface management.

Create a track entry, associate it with the interface management module to monitor the physical status of an interface, and specify the delay time for the track module to notify the associated application module when the track entry status changes: track track-entry-number interface interface-type

interface-number [ delay { negative negative-time | positive positive-time } * ]

Create a track entry, associate it with the interface management module to monitor the Layer 3 protocol status of an interface, and specify the delay time for the track module to notify the associated application module when the track entry status changes: track track-entry-number interface interface-type

interface-number protocol { ipv4 | ipv6 } [ delay

{ negative negative-time | positive positive-time }

* ]

Remarks

N/A

Use either approach.

By default, no track entry is created.

171

Associating the track module with an application module

This section provides instructions for associating the track module with an application module.

Associating track with VRRP

VRRP is an error-tolerant protocol. It adds a group of routers that can act as network gateways to a VRRP group, which forms a virtual router. Routers in the VRRP group elect the master acting as the gateway according to their priorities. A router with a higher priority is more likely to become the master. The other routers function as the backups. When the master fails, to ensure that the hosts in the network segment can uninterruptedly communicate with external networks, the backups in the VRRP group elect a new gateway to undertake the responsibility of the failed master. For more information about VRRP, see

"

Configuring VRRP ."

You can associate the track module with a VRRP group to implement the following objects:

Change the priority of a router according to the status of the uplink—If a fault occurs on the uplink of the router, the VRRP group cannot be aware of the uplink failure. If the router is the master, hosts in the LAN cannot access the external network. This problem can be solved by establishing a track-VRRP group association. Use the detection modules to monitor the status of the uplink of the router and establish collaborations between the detection modules, track module, and VRRP. When the uplink fails, the detection modules notify the track module to change the status of the monitored track entry to Negative, and the priority of the master decreases by a specified value. This allows a higher priority router in the VRRP group to become the master to maintain proper communication between the hosts in the LAN and the external network.

Monitor the master on a backup—If a fault occurs on the master, the backup operating in switchover mode immediately switches to the master to maintain normal communication.

Configuration restrictions

VRRP tracking is not valid on an IP address owner. An IP address owner refers to a router when the

IP address of the virtual router is the IP address of an interface on the router in the VRRP group.

When the status of the track entry changes from Negative to Positive or Invalid, the associated router automatically restores its priority.

You can associate a nonexistent track entry with a VRRP group. The association takes effect only after you create the track entry with the track command.

Configuration procedure

To associate track with VRRP group:

Step Command

1. Enter system view. system-view

2. Enter interface view.

3. Create a VRRP group and configure its virtual IP address. interface interface-type

interface-number vrrp vrid virtual-router-id virtual-ip

virtual-address

Remarks

N/A

N/A

By default, no VRRP group is created.

172

Step Command

4. Associate a track entry with a

VRRP group. vrrp [ ipv6 ] vrid virtual-router-id track track-entry-number [ reduced

priority-reduced | switchover ]

Remarks

By default, no track entry is specified for a VRRP group.

Associating track with static routing

A static route is a manually configured route. With a static route configured, packets to the specified destination are forwarded through the path specified by the administrator. For more information about static route configuration, see Layer 3—IP Routing Configuration Guide.

The disadvantage of using static routes is that they cannot adapt to network topology changes. Faults or topological changes in the network can make the routes unreachable, causing network breaks.

To prevent this problem, configure another route to back up the static route. When the static route is reachable, packets are forwarded through the static route. When the static route is unreachable, packets are forwarded through the backup route, avoiding network breaks and enhancing network reliability.

To examine the reachability of a static route in real time, establish an association between the track and the static route.

If you specify the next hop, but not the egress interface when configuring a static route, you can establish collaborations among the static route, the track module, and detection modules. This enables you to examine the reachability of the static route according to the status of the track entry.

Positive—The next hop of the static route is reachable, and the configured static route is valid.

Negative—The next hop of the static route is not reachable, and the configured static route is invalid.

Invalid—The reachability of the next hop of the static route is unknown, and the static route is valid.

Configuration restrictions

You can associate a nonexistent track entry with a static route. The association takes effect only after you create the track entry with the track command.

If the track module detects the next hop accessibility of the static route in a private network through

NQA, the VPN instance name of the next hop of the static route must be consistent with that configured for the NQA test group. Otherwise, the accessibility detection cannot function properly.

If a static route needs route recursion, the associated track entry must monitor the next hop of the recursive route instead of that of the static route. Otherwise, a valid route can be considered invalid.

Configuration procedure

To associate track with static routing:

Step Command

1. Enter system view. system-view

Remarks

N/A

173

Step Command

2. Associate the static route with a track entry to examine the reachability of the next hop.

Approach 1: ip route-static dest-address { mask |

mask-length } { next-hop-address | vpn-instance d-vpn-instance-name

next-hop-address } track track-entry-number

[ preference preference-value ] [ tag

tag-value ] [ description description-text ]

Approach 2: ip route-static vpn-instance

s-vpn-instance-name&<1-6> dest-address

{ mask | mask-length } { next-hop-address

[ public ] track track-entry-number | vpn-instance d-vpn-instance-name

next-hop-address track track-entry-number }

[ preference preference-value ] [ tag

tag-value ] [ description description-text ]

Remarks

Use either approach.

By default, this command is not configured.

Associating track with PBR

PBR is a routing mechanism based on user-defined policies. Different from the traditional destination-based routing mechanism, PBR allows you to use a policy (based on the source address and other criteria) to route packets. For more information about PBR, see Layer 3—IP Routing Configuration

Guide.

PBR cannot detect the availability of any action taken on packets. When an action is not available, packets processed by the action may be discarded. For example, configure PBR to forward packets that match certain criteria through a specific interface. When the specified interface fails, PBR cannot sense the failure, and continues to forward matching packets out of the interface.

This problem can be solved by associating track with PBR, which improves the flexibility of the PBR application and enables PBR to sense topology changes.

After you associate a track entry with an apply clause, the detection module associated with the track entry sends the detection result of the availability of the object (an interface or an IP address) specified in the apply clause.

Positive—The object is available and the apply clause is valid.

Negative—The object is not available and the apply clause is invalid.

Invalid—The apply clause is valid.

The following objects can be associated with a track entry:

Next hop

Default next hop

Configuration prerequisites

Before you associate track with PBR, create a policy or a policy node and configure the match criteria as well.

Configuration procedure

To associate track with PBR:

174

Step Command

1. Enter system view.

2. Create a policy or policy node and enter PBR policy node view. system-view policy-based-route policy-name [ deny | permit ] node node-number

3. Define an ACL match criterion.

4. Associate track with PBR.

Remarks

N/A

N/A if-match acl acl-number

Optional.

By default, no packets are filtered.

Set the next hop and associate it with a track entry: apply ip-address next-hop ip-address

[ direct ] [ track track-entry-number ]

[ ip-address [ direct ] [ track

track-entry-number ] ]

Set the default next hop, and associate it with a track entry: apply ip-address default next-hop

ip-address [ track track-entry-number ]

[ ip-address [ track track-entry-number ] ]

Use either command.

You can associate a nonexistent track entry with

PBR. The association takes effect only after you use the track command to create the track entry.

Displaying and maintaining track entries

Display information about the specified or all track entries. display track { track-entry-number | all } [ | { begin | exclude | include } regular-expression ]

Available in any view.

Track configuration examples

This section provides track configuration examples.

VRRP-track-NQA collaboration configuration example (the master monitors the uplink)

Network requirements

As shown in Figure 45

, configure Host A to access Host B on the Internet. The default gateway of

Host A is 10.1.1.10/24.

Switch A and Switch B form a VRRP group, which uses the virtual IP address 10.1.1.10.

When Switch A is operating properly, packets from Host A to Host B are forwarded through Switch

A. When VRRP finds that a fault occurs on the uplink of Switch A through NQA, packets from Host

A to Host B are forwarded through Switch B.

175

Figure 45 Network diagram

Configuration procedure

1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each

VLAN interface as shown in

Figure 45

. (Details not shown.)

2. Configure an NQA test group on Switch A:

# Create an NQA test group with the administrator name admin and the operation tag test.

<SwitchA> system-view

[SwitchA] nqa entry admin test

# Configure the test type as ICMP-echo.

[SwitchA-nqa-admin-test] type icmp-echo

# Configure the destination address as 10.1.2.2.

[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.1.2.2

# Set the test frequency to 100 ms.

[SwitchA-nqa-admin-test-icmp-echo] frequency 100

# Configure reaction entry 1, specifying that five consecutive probe failures trigger the track module.

[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

[SwitchA-nqa-admin-test-icmp-echo] quit

# Start the NQA test.

[SwitchA] nqa schedule admin test start-time now lifetime forever

3. On Switch A, configure track entry 1, and associate it with reaction entry 1 of the NQA test group

(with the administrator admin and the operation tag test).

[SwitchA] track 1 nqa entry admin test reaction 1

4. Configure VRRP on Switch A:

# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10

# Set the priority of Switch A in VRRP group 1 to 110.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

# Set the authentication mode of VRRP group 1 to simple and the authentication key to hello.

176

[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello

# Configure the master to send VRRP packets at an interval of five seconds.

[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 5

# Configure Switch A to operate in preemptive mode and set the preemption delay to five seconds.

[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5

# Configure to monitor track entry 1 and specify the priority decrement to 30.

[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 30

5. Configure VRRP on Switch B:

<SwitchB> system-view

[SwitchB] interface vlan-interface 2

# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10

# Set the authentication mode of VRRP group 1 to simple and the authentication key to hello.

[SwitchB-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello

# Configure the master to send VRRP packets at an interval of five seconds.

[SwitchB-Vlan-interface2] vrrp vrid 1 timer advertise 5

# Configure Switch B to operate in preemptive mode and set the preemption delay to five seconds.

[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5

Verifying the configuration

After configuration, ping Host B on Host A and you can see that Host B is reachable. Use the display vrrp command to view the configuration result.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 5

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 5

Auth Type : Simple Key : ******

Virtual IP : 10.1.1.10

Virtual MAC : 0000-5e00-0101

Master IP : 10.1.1.1

VRRP Track Information:

Track Object : 1 State : Positive Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

177

VRID : 1 Adver Timer : 5

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Become Master : 2200ms left

Auth Type : Simple Key : ******

Virtual IP : 10.1.1.10

Master IP : 10.1.1.1

The output shows that Switch A is operating as the master in VRRP group 1 to send packets from Host A to Host B, and Switch B is operating as a backup.

When a fault occurs on the link between Switch A and Switch C, you can still successfully ping Host B on

Host A. Use the display vrrp command to view information about VRRP group 1.

# Display detailed information about VRRP group 1 on Switch A when a fault occurs on the link between

Switch A and Switch C.

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 5

Admin Status : Up State : Backup

Config Pri : 110 Running Pri : 80

Preempt Mode : Yes Delay Time : 5

Become Master : 2200ms left

Auth Type : Simple Key : ******

Virtual IP : 10.1.1.10

Master IP : 10.1.1.2

VRRP Track Information:

Track Object : 1 State : Negative Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B when a fault occurs on the link between

Switch A and Switch C.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 5

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 5

Auth Type : Simple Key : ******

Virtual IP : 10.1.1.10

Virtual MAC : 0000-5e00-0101

Master IP : 10.1.1.2

178

The output shows that when a fault occurs on the link between Switch A and Switch C, the priority of

Switch A decreases to 80. Switch A becomes the backup and Switch B becomes the master to send packets from Host A to Host B.

Configuring BFD for a VRRP backup to monitor the master (the master monitors the uplink)

Network requirements

As shown in

Figure 46

, Switch A and Switch B form VRRP group 1, which uses the virtual IP address

192.168.0.10.

The default gateway of the hosts in the LAN is 192.168.0.10. When Switch A is operating properly, the hosts in the LAN access the external network through Switch A. When Switch A fails, the hosts in the LAN access the external network through Switch B.

If BFD is not configured, when the master in a VRRP group fails, the backup cannot become the master until the configured timeout timer expires. The timeout is generally three to four seconds, which makes the switchover slow. To solve this problem, VRRP uses BFD to probe the state of the master. Once the master fails, the backup can become the new master in milliseconds.

Figure 46 Network diagram

Internet

Switch A

Master

Vlan-int2

192.168.0.101/24

Virtual router

Virtual IP address:

192.168.0.10

Switch B

Backup

Vlan-int2

192.168.0.102/24

L2 switch

BFD probe packets

VRRP packets

Configuration procedure

1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each

VLAN interface as shown in

Figure 46

. (Details not shown.)

2. On Switch A, create VRRP group 1 and configure the virtual IP address 192.168.0.10 for the group. Set the priority of Switch A in VRRP group 1 to 110.

<SwitchA> system-view

179

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

[SwitchA-Vlan-interface2] return

3. On Switch B, configure the source address of BFD echo packets as 10.10.10.10.

<SwitchB> system-view

[SwitchB] bfd echo-source-ip 10.10.10.10

4. On Switch B, create track entry 1 to be associated with the BFD session to examine whether Switch

A is reachable.

[SwitchB] track 1 bfd echo interface vlan-interface 2 remote ip 192.168.0.101 local ip 192.168.0.102

5. On Switch B, create VRRP group 1 and configure the virtual IP address 192.168.0.10 for the group. VRRP group 1 monitors the status of track entry 1. When the status of the track entry becomes Negative, Switch B quickly becomes the master.

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10

[SwitchB-Vlan-interface2] vrrp vrid 1 track 1 switchover

[SwitchB-Vlan-interface2] return

Verifying the configuration

# Display detailed information about VRRP group 1 on Switch A.

<SwitchA> display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 192.168.0.10

Virtual MAC : 0000-5e00-0101

Master IP : 192.168.0.101

# Display detailed information about VRRP group 1 on Switch B.

<SwitchB> display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

180

Virtual IP : 192.168.0.10

Master IP : 192.168.0.101

VRRP Track Information:

Track Object : 1 State : Positive Switchover

# Display information about track entry 1 on Switch B.

<SwitchB> display track 1

Track ID: 1

Status: Positive

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

BFD session:

Packet type: Echo

Interface : Vlan-interface2

Remote IP : 192.168.0.101

Local IP : 192.168.0.102

The output shows that when the status of the track entry becomes Positive, Switch A is the master and

Switch B the backup.

# Enable VRRP state debugging and BFD event debugging on Switch B.

<SwitchB> terminal debugging

<SwitchB> terminal monitor

<SwitchB> debugging vrrp state

<SwitchB> debugging bfd event

# When Switch A fails, the following output is displayed on Switch B.

*Dec 17 14:44:34:142 2008 SwitchB BFD/7/EVENT:Send sess-down Msg,

[Src:192.168.0.102,Dst:192.168.0.101,Vlan-interface2,Echo], instance:0, protocol:Track

*Dec 17 14:44:34:144 2008 SwitchB VRRP/7/DebugState: IPv4 Vlan-interface2 | Virtual Router

1 : Backup --> Master reason: The status of the tracked object changed

# Display detailed information about the VRRP group on Switch B.

<SwitchB> display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 192.168.0.10

Virtual MAC : 0000-5e00-0101

Master IP : 192.168.0.102

VRRP Track Information:

Track Object : 1 State : Negative Switchover

181

The output shows that when BFD detects that Switch A fails, it notifies VRRP through the track module to change the status of Switch B to master without waiting for a period three times the advertisement interval.

This ensures that a backup can quickly preempt as the master.

Configuring BFD for the VRRP master to monitor the uplinks

Network requirements

As shown in Figure 47 , Switch A and Switch B form VRRP group 1, which uses the virtual IP address

192.168.0.10.

The default gateway of the hosts in the LAN is 192.168.0.10.

When Switch A is operating properly, the hosts in the LAN access the external network through

Switch A. When Switch A detects that the uplink is down through BFD, it decreases its priority so that Switch B can preempt as the master, ensuring that the hosts in the LAN can access the external network through Switch B.

Figure 47 Network diagram

Internet

Master uplink device

Vlan-int3

1.1.1.2/24

Uplink

Vlan-int3

1.1.1.1/24

Switch A

Master

Vlan-int2

192.168.0.101/24

Virtual router

Virtual IP address:

192.168.0.10

Backup uplink device

Uplink

Switch B

Backup

Vlan-int2

192.168.0.102/24

L2 switch

VRRP packets

Configuration procedure

1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each

VLAN interface as shown in

Figure 47

. (Details not shown.)

2. On Switch A, configure the source address of BFD echo packets as 10.10.10.10.

<SwitchA> system-view

[SwitchA] bfd echo-source-ip 10.10.10.10

3. On Switch A, create track entry 1 to be associated with the BFD session to examine whether the uplink device with the IP address 1.1.1.2 is reachable.

[SwitchA] track 1 bfd echo interface vlan-interface 3 remote ip 1.1.1.2 local ip

1.1.1.1

182

BFD probe packets

4. On Switch A, create VRRP group 1 and configure the virtual IP address of the group as

192.168.0.10. Configure the priority of Switch A in VRRP group 1 as 110, and configure VRRP group 1 to monitor the status of track entry 1. When the status of the track entry becomes Negative, the priority of Switch A decreases by 20.

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 20

[SwitchA-Vlan-interface2] return

5. On Switch B, create VRRP group 1 and configure the virtual IP address of the group as

192.168.0.10.

<SwitchB> system-view

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 192.168.0.10

[SwitchB-Vlan-interface2] return

Verifying the configuration

# Display detailed information about the VRRP group on Switch A.

<SwitchA> display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 192.168.0.10

Virtual MAC : 0000-5e00-0101

Master IP : 192.168.0.101

VRRP Track Information:

Track Object : 1 State : Positive Pri Reduced : 20

# Display information about track entry 1 on Switch A.

<SwitchA> display track 1

Track ID: 1

Status: Positive

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

BFD session:

Packet type: Echo

Interface : Vlan-interface2

Remote IP : 1.1.1.2

Local IP : 1.1.1.1

# Display detailed information about the VRRP group on Switch B.

<SwitchB> display vrrp verbose

183

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

Virtual IP : 192.168.0.10

Master IP : 192.168.0.101

The output shows that when the status of track entry 1 becomes Positive, Switch A is the master, and

Switch B the backup.

# When the uplink of Switch A goes down, the status of track entry 1 becomes Negative.

<SwitchA> display track 1

Track ID: 1

Status: Negative

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

BFD session:

Packet type: Echo

Interface : Vlan-interface2

Remote IP : 1.1.1.2

Local IP : 1.1.1.1

# Display detailed information about VRRP group 1 on Switch A.

<SwitchA> display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 110 Running Pri : 90

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

Virtual IP : 192.168.0.10

Master IP : 192.168.0.102

VRRP Track Information:

Track Object : 1 State : Negative Pri Reduced : 20

# Display detailed information about VRRP group 1 on Switch B.

<SwitchB> display vrrp verbose

IPv4 Standby Information:

184

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 192.168.0.10

Virtual MAC : 0000-5e00-0101

Master IP : 192.168.0.102

The output shows that when Switch A detects that the uplink fails through BFD, it decreases its priority by

20 to make sure Switch B can preempt as the master.

Static routing-track-NQA collaboration configuration example

Network requirements

As shown in Figure 48 , Switch A, Switch B, Switch C, and Switch D are connected to two segments

20.1.1.0/24 and 30.1.1.0/24. Configure static routes on these switches so that the two segments can communicate with each other. Configure route backup to improve network reliability.

Switch A is the default gateway of the hosts in segment 20.1.1.0/24. Two static routes to 30.1.1.0/24 exist on Switch A, with the next hop being Switch B and Switch C respectively. These two static routes back up each other as follows:

The static route with Switch B as the next hop has a higher priority and is the master route. If this route is available, Switch A forwards packets to 30.1.1.0/24 through Switch B.

The static route with Switch C as the next hop acts as the backup route.

Configure static routing-track-NQA collaboration to determine whether the master route is available in real time. If the master route is unavailable, the backup route takes effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C.

Similarly, Switch D is the default gateway of the hosts in segment 30.1.1.0/24. Two static routes to

20.1.1.0/24 exist on Switch D, with the next hop being Switch B and Switch C, respectively. These two static routes back up each other as follows:

The static route with Switch B as the next hop has a higher priority and is the master route. If this route is available, Switch D forwards packets to 20.1.1.0/24 through Switch B.

The static route with Switch C as the next hop acts as the backup route.

Configure static routing-track-NQA collaboration to determine whether the master route is available in real time. If the master route is unavailable, the backup route takes effect, and Switch D forwards packets to 20.1.1.0/24 through Switch C.

185

Figure 48 Network diagram

Configuration procedure

1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each

VLAN interface as shown in

Figure 48

. (Details not shown.)

2. Configure Switch A:

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.1.1.2 and the default priority 60. This static route is associated with track entry 1.

<SwitchA> system-view

[SwitchA] ip route-static 30.1.1.0 24 10.1.1.2 track 1

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.3.1.3 and the priority 80.

[SwitchA] ip route-static 30.1.1.0 24 10.3.1.3 preference 80

# Configure a static route to 10.2.1.4, with the address of the next hop as 10.1.1.2.

[SwitchA] ip route-static 10.2.1.4 24 10.1.1.2

# Create an NQA test group with the administrator admin and the operation tag test.

[SwitchA] nqa entry admin test

# Configure the test type as ICMP-echo.

[SwitchA-nqa-admin-test] type icmp-echo

# Configure the destination address of the test as 10.2.1.4 and the next hop address as 10.1.1.2 to examine the connectivity of the path from Switch A to Switch B and then to Switch D through

NQA.

[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.2.1.4

[SwitchA-nqa-admin-test-icmp-echo] next-hop 10.1.1.2

# Configure the test frequency as 100 ms.

[SwitchA-nqa-admin-test-icmp-echo] frequency 100

# Configure reaction entry 1, specifying that five consecutive probe failures trigger the track module.

[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

[SwitchA-nqa-admin-test-icmp-echo] quit

186

# Start the NQA test.

[SwitchA] nqa schedule admin test start-time now lifetime forever

# Configure track entry 1 and associate it with reaction entry 1 of the NQA test group (with the administrator admin and the operation tag test).

[SwitchA] track 1 nqa entry admin test reaction 1

3. Configure Switch B:

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.2.1.4.

<SwitchB> system-view

[SwitchB] ip route-static 30.1.1.0 24 10.2.1.4

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.1.1.1.

[SwitchB] ip route-static 20.1.1.0 24 10.1.1.1

4. Configure Switch C:

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.4.1.4.

<SwitchC> system-view

[SwitchC] ip route-static 30.1.1.0 24 10.4.1.4

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.3.1.1.

[SwitchC] ip route-static 20.1.1.0 24 10.3.1.1

5. Configure Switch D:

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.2.1.2 and the default priority 60. This static route is associated with track entry 1.

<SwitchD> system-view

[SwitchD] ip route-static 20.1.1.0 24 10.2.1.2 track 1

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.4.1.3 and the priority 80.

[SwitchD] ip route-static 20.1.1.0 24 10.4.1.3 preference 80

# Configure a static route to 10.1.1.1, with the address of the next hop as 10.2.1.2.

[SwitchD] ip route-static 10.1.1.1 24 10.2.1.2

# Create an NQA test group with the administrator admin and the operation tag test.

[SwitchD] nqa entry admin test

# Configure the test type as ICMP-echo.

[SwitchD-nqa-admin-test] type icmp-echo

# Configure the destination address of the test as 10.1.1.1 and the next hop address as 10.2.1.2 to examine the connectivity of the path from Switch D to Switch B and then to Switch A through

NQA.

[SwitchD-nqa-admin-test-icmp-echo] destination ip 10.1.1.1

[SwitchD-nqa-admin-test-icmp-echo] next-hop 10.2.1.2

# Configure the test frequency as 100 ms.

[SwitchD-nqa-admin-test-icmp-echo] frequency 100

# Configure reaction entry 1, specifying that five consecutive probe failures trigger the static routing-track-NQA collaboration.

[SwitchD-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

[SwitchD-nqa-admin-test-icmp-echo] quit

# Start the NQA test.

[SwitchD] nqa schedule admin test start-time now lifetime forever

187

# Configure track entry 1 and associate it with reaction entry 1 of the NQA test group (with the administrator admin and the operation tag test).

[SwitchD] track 1 nqa entry admin test reaction 1

Verifying the configuration

# Display information about the track entry on Switch A.

[SwitchA] display track all

Track ID: 1

Status: Positive

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

NQA entry: admin test

Reaction: 1

# Display the routing table of Switch A.

[SwitchA] display ip routing-table

Routing Tables: Public

Destinations : 10 Routes : 10

Destination/Mask Proto Pre Cost NextHop Interface

10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2

10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.0/24 Static 60 0 10.1.1.2 Vlan2

10.3.1.0/24 Direct 0 0 10.3.1.1 Vlan3

10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0

20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan6

20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

30.1.1.0/24 Static 60 0 10.1.1.2 Vlan2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The output shows the NQA test result: the master route is available (the status of the track entry is Positive), and Switch A forwards packets to 30.1.1.0/24 through Switch B.

# Remove the IP address of interface VLAN-interface 2 on Switch B.

<SwitchB> system-view

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] undo ip address

# Display information about the track entry on Switch A.

[SwitchA] display track all

Track ID: 1

Status: Negative

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

NQA entry: admin test

Reaction: 1

# Display the routing table of Switch A.

[SwitchA] display ip routing-table

Routing Tables: Public

188

Destinations : 10 Routes : 10

Destination/Mask Proto Pre Cost NextHop Interface

10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2

10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.0/24 Static 60 0 10.1.1.2 Vlan2

10.3.1.0/24 Direct 0 0 10.3.1.1 Vlan3

10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0

20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan6

20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

30.1.1.0/24 Static 80 0 10.3.1.3 Vlan3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The output shows the NQA test result: the master route is unavailable. (The status of the track entry is

Negative.) The backup static route takes effect and Switch A forwards packets to 30.1.1.0/24 through

Switch C.

# When the master route fails, the hosts in 20.1.1.0/24 can still communicate with the hosts in

30.1.1.0/24.

[SwitchA] ping -a 20.1.1.1 30.1.1.1

PING 30.1.1.1: 56 data bytes, press CTRL_C to break

Reply from 30.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms

Reply from 30.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms

Reply from 30.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms

Reply from 30.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms

Reply from 30.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms

--- 30.1.1.1 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/1/2 ms

# The output on Switch D is similar to that on Switch A. When the master route fails, the hosts in

30.1.1.0/24 can still communicate with the hosts in 20.1.1.0/24.

[SwitchB] ping -a 30.1.1.1 20.1.1.1

PING 20.1.1.1: 56 data bytes, press CTRL_C to break

Reply from 20.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms

Reply from 20.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms

Reply from 20.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms

Reply from 20.1.1.1: bytes=56 Sequence=4 ttl=254 time=1 ms

Reply from 20.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms

--- 20.1.1.1 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/1/2 ms

189

Static routing-track-BFD collaboration configuration example

Network requirements

As shown in

Figure 49 , Switch A, Switch B, and Switch C are connected to two segments 20.1.1.0/24 and

30.1.1.0/24. Configure static routes on these routers so that the two segments can communicate with each other. Configure route backup to improve network reliability.

Switch A is the default gateway of the hosts in segment 20.1.1.0/24. Two static routes to 30.1.1.0/24 exist on Switch A, with the next hop being Switch B and Switch C respectively. These two static routes back up each other as follows:

The static route with Switch B as the next hop has a higher priority and is the master route. If this route is available, Switch A forwards packets to 30.1.1.0/24 through Switch B.

The static route with Switch C as the next hop acts as the backup route.

Configure static routing-track-BFD collaboration to determine whether the master route is available in real time. If the master route is unavailable, BFD can quickly detect the route failure to make the backup route take effect. Switch A forwards packets to 30.1.1.0/24 through Switch C and Switch B.

Similarly, Switch B is the default gateway of the hosts in segment 30.1.1.0/24. Two static routes to

20.1.1.0/24 exist on Switch B, with the next hop being Switch A and Switch C, respectively. These two static routes back up each other as follows:

The static route with Switch A as the next hop has a higher priority and is the master route. If this route is available, Switch B forwards packets to 20.1.1.0/24 through Switch A.

The static route with Switch C as the next hop acts as the backup route.

Configure static routing-track-BFD collaboration to determine whether the master route is available in real time. If the master route is unavailable, BFD can quickly detect the route failure to make the backup route take effect. Switch B forwards packets to 20.1.1.0/24 through Switch C and Switch A.

Figure 49 Network diagram

Configuration procedure

1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each

VLAN interface as shown in

Figure 49

. (Details not shown.)

2. Configure Switch A:

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.2.1.2 and the default priority 60. This static route is associated with track entry 1.

<SwitchA> system-view

[SwitchA] ip route-static 30.1.1.0 24 10.2.1.2 track 1

190

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.3.1.3 and the priority 80.

[SwitchA] ip route-static 30.1.1.0 24 10.3.1.3 preference 80

# Configure the source address of BFD echo packets as 10.10.10.10.

[SwitchA] bfd echo-source-ip 10.10.10.10

# Configure track entry 1 and associate it with the BFD session. Examine whether Switch A can be interoperated with the next hop (Switch B) of static route.

[SwitchA] track 1 bfd echo interface vlan-interface 2 remote ip 10.2.1.2 local ip

10.2.1.1

3. Configure Switch B:

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.2.1.1 and the default priority 60. This static route is associated with track entry 1.

<SwitchB> system-view

[SwitchB] ip route-static 20.1.1.0 24 10.2.1.1 track 1

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.4.1.3 and the priority 80.

[SwitchB] ip route-static 20.1.1.0 24 10.4.1.3 preference 80

# Configure the source address of BFD echo packets as 1.1.1.1.

[SwitchB] bfd echo-source-ip 1.1.1.1

# Configure track entry 1 that is associated with the BFD session to examine whether Switch B can communicate with the next hop (Switch A) of the static route.

[SwitchB] track 1 bfd echo interface vlan-interface 2 remote ip 10.2.1.1 local ip

10.2.1.2

4. Configure Switch C:

# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.4.1.2.

<SwitchC> system-view

[SwitchC] ip route-static 30.1.1.0 24 10.4.1.2

# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.3.1.1.

[SwitchB] ip route-static 20.1.1.0 24 10.3.1.1

Verifying the configuration

# Display information about the track entry on Switch A.

[SwitchA] display track all

Track ID: 1

Status: Positive

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

BFD Session:

Packet type: Echo

Interface : Vlan-interface2

Remote IP : 10.2.1.2

Local IP : 10.2.1.1

# Display the routing table of Switch A.

[SwitchA] display ip routing-table

Routing Tables: Public

Destinations : 9 Routes : 9

191

Destination/Mask Proto Pre Cost NextHop Interface

10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan2

10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.3.1.0/24 Direct 0 0 10.3.1.1 Vlan3

10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0

20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan5

20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

30.1.1.0/24 Static 60 0 10.2.1.2 Vlan2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The output shows the BFD detection result: the next hop 10.2.1.2 is reachable (the status of the track entry is Positive) and the master static route takes effect. Switch A forwards packets to 30.1.1.0/24 through

Switch B.

# Remove the IP address of interface VLAN-interface 2 on Switch B.

<SwitchB> system-view

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] undo ip address

# Display information of the track entry on Switch A.

[SwitchA] display track all

Track ID: 1

Status: Negative

Duration: 0 days 0 hours 0 minutes 32 seconds

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

BFD Session:

Packet type: Echo

Interface : Vlan-interface2

Remote IP : 10.2.1.2

Local IP : 10.2.1.1

# Display the routing table of Switch A.

[SwitchA] display ip routing-table

Routing Tables: Public

Destinations : 9 Routes : 9

Destination/Mask Proto Pre Cost NextHop Interface

10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan2

10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.3.1.0/24 Direct 0 0 10.3.1.1 Vlan3

10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0

20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan5

20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

30.1.1.0/24 Static 80 0 10.3.1.3 Vlan3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The output shows the BFD detection result: the next hop 10.2.1.2 is unreachable (the status of the track entry is Negative), the backup static route takes effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C and Switch B.

192

# When the master route fails, the hosts in 20.1.1.0/24 can still communicate with the hosts in

30.1.1.0/24.

[SwitchA] ping -a 20.1.1.1 30.1.1.1

PING 30.1.1.1: 56 data bytes, press CTRL_C to break

Reply from 30.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms

Reply from 30.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms

Reply from 30.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms

Reply from 30.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms

Reply from 30.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms

--- 30.1.1.1 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/1/2 ms

# The output on Switch B is similar to that on Switch A. When the master route fails, the hosts in

30.1.1.0/24 can still communicate with the hosts in 20.1.1.0/24.

[SwitchB] ping -a 30.1.1.1 20.1.1.1

PING 20.1.1.1: 56 data bytes, press CTRL_C to break

Reply from 20.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms

Reply from 20.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms

Reply from 20.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms

Reply from 20.1.1.1: bytes=56 Sequence=4 ttl=254 time=1 ms

Reply from 20.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms

--- 20.1.1.1 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/1/2 ms

VRRP-track-interface management collaboration configuration example (the master monitors the uplink interface)

Network requirements

As shown in

Figure 50

, Host A needs to access Host B on the Internet. The default gateway of Host

A is 10.1.1.10/24.

Switch A and Switch B form a VRRP group, which uses the virtual IP address 10.1.1.10.

When operating properly, Switch A sends packets from Host A to Host B. When VRRP detects that a fault occurs on the uplink interface of Switch A through the interface management module, Switch

B sends packets from Host A to Host B.

193

Figure 50 Network diagram

Configuration procedure

1. Create VLANs, assign corresponding ports to the VLANs, and configure the IP address of each

VLAN interface as shown in

Figure 50

. (Details not shown.)

2. On Switch A, configure track entry 1 and associate it with the physical status of the uplink interface

VLAN-interface 3.

[SwitchA] track 1 interface vlan-interface 3

3. Configure VRRP on Switch A:

# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10

# Set the priority of Switch A in VRRP group 1 to 110.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110

# Configure to monitor track entry 1 and specify the priority decrement as 30.

[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 30

4. On Switch B, create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.

<SwitchB> system-view

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10

Verifying the configuration

After configuration, ping Host B on Host A. You can see that Host B is reachable. Use the display vrrp command to view the configuration result.

# Display detailed information about VRRP group 1 on Switch A.

[SwitchA-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

194

Config Pri : 110 Running Pri : 110

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 10.1.1.10

Virtual MAC : 0000-5e00-0101

Master IP : 10.1.1.1

VRRP Track Information:

Track Object : 1 State : Positive Pri Reduced : 30

# Display detailed information about VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

Virtual IP : 10.1.1.10

Master IP : 10.1.1.1

The output shows that in VRRP group 1, Switch A is the master, and Switch B is a backup. Packets from

Host A to Host B are forwarded through Switch A.

# Shut down the uplink interface VLAN-interface 3 on Switch A.

[SwitchA-Vlan-interface2] interface vlan-interface 3

[SwitchA-Vlan-interface3] shutdown

After shutting down the uplink interface on Switch A, you can still successfully ping Host B on Host A. Use the display vrrp command to view information about VRRP group 1.

# After shutting down the uplink interface on Switch A, display detailed information about VRRP group

1 on Switch A.

[SwitchA-Vlan-interface3] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Backup

Config Pri : 110 Running Pri : 80

Preempt Mode : Yes Delay Time : 0

Become Master : 2200ms left

Auth Type : None

Virtual IP : 10.1.1.10

Master IP : 10.1.1.2

VRRP Track Information:

195

Track Object : 1 State : Negative Pri Reduced : 30

# After shutting down the uplink interface on Switch A, display detailed information about VRRP group

1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose

IPv4 Standby Information:

Run Mode : Standard

Run Method : Virtual MAC

Total number of virtual routers : 1

Interface Vlan-interface2

VRID : 1 Adver Timer : 1

Admin Status : Up State : Master

Config Pri : 100 Running Pri : 100

Preempt Mode : Yes Delay Time : 0

Auth Type : None

Virtual IP : 10.1.1.10

Virtual MAC : 0000-5e00-0101

Master IP : 10.1.1.2

The output shows that when the uplink interface on Switch A is shut down, the priority of Switch A decreases to 80. Switch A becomes the backup and Switch B becomes the master. Packets from Host A to Host B are forwarded through Switch B.

196

Support and other resources

Contacting HP

For worldwide technical support information, see the HP support website: http://www.hp.com/support

Before contacting HP, collect the following information:

Product model names and numbers

Technical support registration number (if applicable)

Product serial numbers

Error messages

Operating system type and revision level

Detailed questions

Subscription service

HP recommends that you register your product at the Subscriber's Choice for Business website: http://www.hp.com/go/wwalerts

After registering, you will receive email notification of product enhancements, new driver versions, firmware updates, and other product resources.

Related information

Documents

To find related documents, browse to the Manuals page of the HP Business Support Center website: http://www.hp.com/support/manuals

For related documentation, navigate to the Networking section, and select a networking category.

For a complete list of acronyms and their definitions, see HP FlexNetwork Technology Acronyms.

Websites

HP.com http://www.hp.com

HP Networking http://www.hp.com/go/networking

HP manuals http://www.hp.com/support/manuals

HP download drivers and software http://www.hp.com/support/downloads

HP software depot http://www.software.hp.com

HP Education http://www.hp.com/learn

197

Conventions

This section describes the conventions used in this documentation set.

Command conventions

Convention Description

Boldface Bold text represents commands and keywords that you enter literally as shown.

Italic

[ ]

{ x | y | ... }

[ x | y | ... ]

{ x | y | ... } *

[ x | y | ... ] *

&<1-n>

Italic text represents arguments that you replace with actual values.

Square brackets enclose syntax choices (keywords or arguments) that are optional.

Braces enclose a set of required syntax choices separated by vertical bars, from which you select one.

Square brackets enclose a set of optional syntax choices separated by vertical bars, from which you select one or none.

Asterisk-marked braces enclose a set of required syntax choices separated by vertical bars, from which you select at least one.

Asterisk-marked square brackets enclose optional syntax choices separated by vertical bars, from which you select one choice, multiple choices, or none.

The argument or keyword and argument combination before the ampersand (&) sign can be entered 1 to n times.

A line that starts with a pound (#) sign is comments. #

GUI conventions

Symbols

Convention Description

Boldface

Window names, button names, field names, and menu items are in bold text. For example, the New User window appears; click OK.

> Multi-level menus are separated by angle brackets. For example, File > Create > Folder.

Convention Description

WARNING

An alert that calls attention to important information that if not understood or followed can result in personal injury.

CAUTION

An alert that calls attention to important information that if not understood or followed can result in data loss, data corruption, or damage to hardware or software.

IMPORTANT

NOTE

An alert that calls attention to essential information.

An alert that contains additional or supplementary information.

TIP

An alert that provides helpful information.

198

Network topology icons

Represents a generic network device, such as a router, switch, or firewall.

Represents a routing-capable device, such as a router or Layer 3 switch.

Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports

Layer 2 forwarding and other Layer 2 features.

Port numbering in examples

The port numbers in this document are for illustration only and might be unavailable on your device.

199

Index

802.1 (configuring CFD protocol version), 21 activating RRPP domain, 64 active operation mode (BFD), 163 switchover (high availability technologies), 3 switchover configuration, 5 address learning (Smart Link), 99 advertisement interval timer (VRRP), 127 link state (DLDP), 32 setting DLDP send advertisement packet interval,

39 alarm (Ethernet OAM fault detection), 8 application associating module with track, 172 associating track with PBR, 174 associating track with static routing, 173 associating track with VRRP, 172

IPv4 VRRP, 130 track, 169 assistant-edge node

RRPP type, 51 specifying RRPP, 63 associating track module with detection module, 170 track with application module, 172 track with BFD, 170 track with interface management, 171 track with NQA, 170 track with PBR, 174 track with static routing, 173 track with VRRP, 172 association maintenance (CFD), 18 attribute

IPv4 VRRP packet, 134

IPv6 VRRP packet, 139 authenticating configuring DLDP authentication, 41

DLDP non-authentication mode, 34

DLDP plain text authentication mode, 34

MD5 authentication mode (DLDP), 34

VRRP authentication mode, 127 auto mode (DLDP port shutdown), 40 automatic shut down (unidirectional links), 42 auto-recovery (DLDP link mechanism), 37 backup mechanism (Smart Link), 99

200

BFD active operation mode, 163 associating with track, 170 basic configuration, 165 bidirectional detection, 162 configuration, 161 configuring for VRRP backup monitoring, 179 configuring for VRRP uplink monitoring, 182 configuring static routing-track-BFD collaboration,

190 control packet mode, 162 control packet session mode, 162 detection method, 162 displaying, 167 dynamic parameter change, 163 echo packet mode, 162 echo packet session mode, 162 establishing session, 161 fault detection, 162 high availability fault detection technologies, 2 how it works, 161 maintaining, 167 multi-hop detection, 162 packet format, 163, 166 passive operation mode, 163 protocols and standards, 165 single-hop detection, 162 supported features, 165 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183 verifying static routing-track-BFD collaboration configuration, 191

BGP

BFD supported feature, 165

IPv6 BGP (BFD supported feature), 165 bidirectional forwarding detection. See BFD broadcast (RRPP storm suppression mechanism), 54 calculating

MTBF, 1

MTTR, 1

CFD basic concepts, 17 configuration, 17, 20, 21, 26 configuring continuity check on MEP, 24

configuring function, 24 configuring linktrace on MEP, 25 configuring loopback on MEP, 25 configuring MEP, 23 configuring MIP generation rules, 23 continuity check function, 20 displaying, 26 high availability fault detection technologies, 2 linktrace function, 20 loopback function, 20 maintaining, 26 maintenance association, 18 maintenance domain, 17 maintenance point, 18

MEP list, 19 protocols and standards, 20

Smart Link-CFD continuity check collaboration,

100 verifying configuration, 29 changing BFD parameter dynamically, 163 collaborating between track and application modules, 169 between track and detection modules, 168

BFD for VRRP backup monitoring configuration,

179

BFD for VRRP uplink monitoring configuration, 182

CFD continuity check and Smart Link, 100

Monitor Link and Smart Link, 100

Smart Link collaboration mechanism, 99 static routing-track-BFD collaboration configuration,

190 static routing-track-NQA collaboration configuration, 185 track configuration, 168, 169, 175 track fundamentals, 168

VRRP-track-interface management collaboration configuration, 193

VRRP-track-NQA collaboration track configuration,

175 common port (RRPP), 52 common-flush-FDB RRPPDU type, 52 complete-flush-FDB RRPPDU type, 52 configurable MEP (CFD), 19, 23 configuring active switchover, 5 basic BFD, 165 basic CFD settings, 21

BFD, 161

BFD for VRRP backup monitoring, 179

BFD for VRRP uplink monitoring, 182

CFD, 17, 20, 26

CFD continuity check on MEP, 24

CFD function, 24

CFD linktrace on MEP, 25

CFD loopback on MEP, 25

CFD MIP generation rules, 23

CFD protocol version, 21

CFD service instances, 22

DLDP, 31, 38, 42

DLDP authentication, 41

DLDP duplex mode, 38

Ethernet interface speed (DLDP), 38

Ethernet OAM, 8, 11, 15

Ethernet OAM basic function, 11

Ethernet OAM connection detection timer, 12

Ethernet OAM errored frame event detection, 13

Ethernet OAM errored frame period event detection, 13

Ethernet OAM errored frame seconds event detection, 14

Ethernet OAM errored symbol event detection, 13

Ethernet OAM link monitoring, 12

IPv4 VRRP interface tracking, 143

IPv4 VRRP packet attribute, 134

IPv4 VRRP single group, 140

IPv4 VRRP trap function, 135

IPv4 VRRP with multiple VLANs, 147

IPv6 VRRP, 149

IPv6 VRRP interface tracking, 152

IPv6 VRRP packet attribute, 139

IPv6 VRRP preemptive mode, 138

IPv6 VRRP router priority, 138

IPv6 VRRP single group, 149

IPv6 VRRP tracking function, 138

IPv6 VRRP with multiple VLANs, 156 member port for Smart Link group, 101 member port in interface view, 102 member port in Smart Link group view, 102

MEP (CFD), 23

Monitor Link, 119, 120, 121

Monitor Link group member port, 120

Monitor Link group member port in group view,

120

Monitor Link group member port in interface view,

121 protected VLAN for Smart Link group, 101 role preemption for Smart Link group, 102

RRPP, 50, 59, 67

RRPP control VLAN, 60

RRPP dual homed rings, 74

RRPP fail timer, 64

RRPP fast detection, 65, 93

201

RRPP fast detection timer, 65

RRPP hello timer, 64

RRPP intersecting rings, 69

RRPP load balanced intersecting rings, 84

RRPP node, 62

RRPP port, 62

RRPP protected VLAN, 60

RRPP ring, 61

RRPP ring group, 66

RRPP single ring, 67

Smart Link, 97, 100, 104

Smart Link and CFD continuity check collaboration,

103

Smart Link and CFD continuity check collaboration,

113

Smart Link associated device, 103

Smart Link device, 100

Smart Link multiple groups, 109

Smart Link single group, 104 static routing-track-BFD collaboration, 190 static routing-track-NQA collaboration, 185 track, 168, 169, 175

VRRP, 125

VRRP preemptive mode, 133

VRRP router priority, 133

VRRP tracking function, 133

VRRP virtual IP address, 132

VRRP virtual IPv6 address, 136, 137

VRRP-track-interface management collaboration,

193

VRRP-track-NQA collaboration (track), 175 connection detection timer (Ethernet OAM), 12 establishing (Ethernet OAM), 9 connectivity failure detection. See CFD continuity check

CFD, 20 configuring on MEP, 24 configuring Smart Link collaboration, 103 message, 20

Smart Link collaboration, 113 control VLAN

RRPP, 51

RRPP configuration, 60 creating

CFD service instance with MD name, 22

CFD service instance without MD name, 22

IPv6 VRRP group, 136, 137

Monitor Link group, 120

RRPP domain, 59

VRRP group, 132

202 data VLAN (RRPP), 51

DelayDown

DLDP link state, 32

DLDP timer setting, 40 detecting associating track and detection modules, 170 associating track with application module, 172 associating track with BFD, 170 associating track with interface management, 171 associating track with NQA, 170 associating track with PBR, 174 associating track with static routing, 173 associating track with VRRP, 172

BFD configuration, 161, 165

BFD fault, 162 collaboration between track and application modules, 169 collaboration between track and detection modules, 168 configuring Ethernet OAM errored frame event detection, 13 configuring Ethernet OAM errored frame period event detection, 13 configuring Ethernet OAM errored frame seconds event detection, 14 configuring Ethernet OAM errored symbol event detection, 13 configuring RRPP fast detection, 65 configuring RRPP fast detection timer, 65

DLDP configuration, 31, 38, 42 enabling RRPP fast detection, 59, 65

Ethernet OAM fault detection, 8 high availability fault detection technologies, 2 high availability protection switchover technologies, 3 method (BFD), 162 remote fault (Ethernet OAM), 11

RRPP fast detection mechanism, 55 device activating RRPP domain, 64 configuring Smart Link and CFD continuity check collaboration, 103 configuring Smart Link associate, 103 creating RRPP domain, 59 link detection protocol. See DLDP loopback (CFD), 20

Monitor Link downlink, 120

Monitor Link downlink port, 119

Monitor Link uplink, 120

Monitor Link uplink port, 119 restarting standby MPU, 6

Smart Link configuration, 100 disable (DLDP link state), 32 disconnect state (RRPP ring), 51 displaying active switchover, 7

BFD, 167

CFD, 26

DLDP, 42

Ethernet OAM configuration, 14

IPv4 VRRP, 136

IPv6 VRRP, 140

Monitor Link, 121

RRPP, 66

Smart Link, 104 standby switchover, 7 track entries, 175

DLDP active timer, 32 advertisement timer, 32 auto shutdown of unidirectional link, 42 configuration, 31, 38, 42 configuring authentication, 41 configuring duplex mode, 38 configuring Ethernet interface speed, 38 delaydown timer, 32 displaying, 42 echo timer, 32 enabling, 38 enhanced timer, 32 entry timer, 32 high availability fault detection technologies, 2 how it works, 32 link auto-recovery mechanism, 37 link state, 32 maintaining, 42 manual shutdown of unidirectional link, 46

MD5 authentication mode, 34 non-authentication mode, 34 operation mode, 33 probe timer, 32 processes, 35 recoverprobe timer, 32 resetting state, 41 resetting state in port/port group view, 42 resetting state in system view, 41 setting DelayDown timer, 40 setting mode, 39 setting port shutdown mode, 40 setting send advertisement packet interval, 39 simple authentication mode, 34 state and packet type, 35

203 troubleshooting, 49 two-way neighbor state, 38 unidirectional neighbor state, 38 unknown neighbor state, 38 verifying auto shutdown of unidirectional link, 44 verifying manual shutdown of unidirectional link,

47 domain activating (RRPP), 64 creating (RRPP), 59 maintenance (CFD), 17

RRPP, 50 downlink

Monitor Link, 120

Monitor Link port, 119 dual-homed rings (RRPP network), 57 duplex mode (DLDP), 38 edge edge-hello RRPPDU type, 52

RRPP node type, 51

RRPP port type, 52 specifying RRPP node, 63 enabling

CFD, 21

DLDP, 38

RRPP fast detection, 59, 65

Smart Link flush message receipt, 103

Smart Link flush message send, 102 enhanced mode setting (DLDP), 39 errored frame event detection (Ethernet OAM), 13 frame period event detection (Ethernet OAM), 13 frame seconds event detection (Ethernet OAM), 14 symbol event detection (Ethernet OAM), 13 establishing connection (Ethernet OAM), 9

Ethernet configuring interface speed (DLDP), 38 enabling DLDP, 38

IPv4 VRRP configuration, 131, 140

IPv4 VRRP configuration restrictions, 131

IPv4 VRRP interface tracking configuration, 143

IPv4 VRRP multiple VLANs configuration, 147

IPv4 VRRP single group configuration, 140

IPv6 VRRP configuration, 136, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156 link aggregation (protection switchover technologies), 3

OAM. See Ethernet OAM

RRPP configuration, 50, 59, 67

RRPP dual homed rings configuration, 74

RRPP fast detection configuration, 93

RRPP intersecting rings configuration, 69

RRPP load balanced intersecting rings configuration, 84

RRPP single ring configuration, 67

Ethernet OAM configuration, 8, 11, 15 configuring basic function, 11 configuring connection detection timer, 12 configuring errored frame event detection, 13 configuring errored frame period event detection,

13 configuring errored frame seconds event detection,

14 configuring errored symbol event detection, 13 configuring link monitoring, 12 displaying configuration, 14 establishing connection, 9 fault detection and alarm, 8 high availability fault detection technology, 2 how it works, 9 link monitoring, 10 link performance monitoring, 8 maintaining configuration, 14

OAMPDU

, 8

OAMPDU field description, 8

OAMPDU format, 8

OAMPDU function, 8 protocols and standards, 11 remote fault detection, 11 remote loopback, 8 verifying configuration, 15 evaluating network availability, 1 event detection errored frame (Ethernet OAM), 13 errored frame period (Ethernet OAM), 13 errored frame seconds (Ethernet OAM), 14 errored symbol (Ethernet OAM), 13 fail timer (RRPP), 53 fast detection configuration (RRPP), 65, 93 detection enabling (RRPP), 59, 65 detection mechanism (RRPP), 55 detection timer configuration (RRPP), 65 failure detection configuration (BFD), 161, 165 fast-edge-hello RRPPDU type, 52 fast-fail timer (RRPP), 53 fast-hello RRPPDU type, 52 fast-hello timer (RRPP), 53 fault detection

BFD, 162

CFD configuration (high availability), 17, 20, 21,

26

CFD maintenance domain, 17

Ethernet OAM, 8 high availability protection switchover technologies, 3 high availability technologies, 2 remote (Ethernet OAM), 11 field description (Ethernet OAMPDU), 8 flush

Smart Link message, 98, 102, 103 update mechanism (Smart Link), 99 format

BFD packet, 163, 166

Ethernet OAMPDU, 8

VRRP packet, 127 frame continuity check message (CFD), 20 linktrace message (CFD), 20 loopback message (CFD), 20

FRR high availability protection switchover technology,

3

IP FRR (BFD supported features), 165 function configuring (CFD), 24 configuring (Ethernet OAM), 11 configuring CFD continuity check on MEP, 24 configuring CFD linktrace on MEP, 25 configuring CFD loopback on MEP, 25 continuity check (CFD), 20

Ethernet OAMPDU, 8 linktrace (CFD), 20 loopback (CFD), 20 generating MIPs (CFD), 23

GR (high availability protection switchover technology), 3 group configuring Monitor Link member port, 120 configuring Monitor Link member port in group view, 120 configuring Monitor Link member port in interface view, 121 configuring protected VLAN for Smart Link group,

101 configuring RRPP ring, 66 creating IPv6 VRRP group, 136, 137 creating VRRP group, 132

IPv4 VRRP load sharing, 130

204

IPv4 VRRP master/backup mode, 130

Monitor Link, 119

Monitor Link creation, 120 resetting DLDP state in port/port group view, 42

RRPP ring, 52, 54

Smart Link and CFD continuity check collaboration configuration, 113

Smart Link multiple groups configuration, 109

Smart Link single group configuration, 104 terminology (Smart Link), 98

VRRP, 126 hardware detection (BFD configuration), 161, 165 health state (RRPP ring), 51 hello

RRPPDU type, 52 timer (RRPP), 53 high availability active switchover configuration, 5

BFD for VRRP backup monitoring configuration,

179

BFD for VRRP uplink monitoring configuration, 182

CFD configuration, 17, 20, 21, 26 configuring RRPP fast detection, 65 displaying active switchover, 7 displaying BFD, 167 displaying CFD, 26 displaying DLDP, 42 displaying IPv4 VRRP, 136 displaying IPv6 VRRP, 140 displaying Monitor Link, 121 displaying RRPP, 66 displaying Smart Link, 104 displaying standby switchover, 7 displaying track entries, 175

DLDP configuration, 31, 38, 42

Ethernet OAM. See Ethernet OAM evaluation, 1 fault detection technologies, 2 ignoring standby MPU version check, 5

IPv4 VRRP configuration, 131, 140

IPv4 VRRP interface tracking configuration, 143

IPv4 VRRP multiple VLANs configuration, 147

IPv4 VRRP single group configuration, 140

IPv6 VRRP configuration, 136, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156 maintaining BFD, 167 maintaining CFD, 26 maintaining DLDP, 42 maintaining IPv4 VRRP, 136

205 maintaining IPv6 VRRP, 140 maintaining Monitor Link, 121 maintaining RRPP, 66 maintaining Smart Link, 104 maintaining track entries, 175

Monitor Link configuration, 119, 120, 121

MTBF, 1

MTTR, 1 performing active switchover manually, 6 performing standby switchover manually, 6 protection switchover technologies, 3 remote loopback (Ethernet OAM), 8 requirements, 1 restarting standby MPU, 6

RRPP configuration, 50, 59, 67

RRPP dual homed rings configuration, 74

RRPP fast detection configuration, 93

RRPP intersecting rings configuration, 69

RRPP load balanced intersecting rings configuration, 84

RRPP single ring configuration, 67

Smart Link and CFD continuity check collaboration configuration, 113

Smart Link configuration, 97, 100, 104

Smart Link multiple groups configuration, 109

Smart Link single group configuration, 104 standby switchover configuration, 5 static routing-track-BFD collaboration configuration,

190 static routing-track-NQA collaboration configuration, 185 switchover configuration restrictions, 5 technologies, 2 track configuration, 168, 169, 175 troubleshooting DLDP, 49

VRRP configuration, 125

VRRP-track-interface management collaboration configuration, 193

VRRP-track-NQA collaboration track configuration,

175 ignoring standby MPU version check, 5 interface management (associating with track), 171 intersecting rings

RRPP load balancing, 58

RRPP network, 56 interval (DLDP send advertisement packets), 39

IP FRR (BFD supported features), 165

IPv4 VRRP application, 130 configuring packet attribute, 134 configuring trap function, 135

displaying, 136 interface tracking configuration, 143 load sharing, 130 maintaining, 136 master/backup mode, 130 multiple VLANs configuration, 147 specifying MAC address type mapped to virtual IP address, 132 verifying interface tracking configuration, 145 verifying single group configuration, 142 verifying with multiple VLANs configuration, 148

IPv6 BGP (BFD supported feature), 165

IPv6 IS-IS (BFD supported features), 165

IPv6 VRRP configuration, 136, 149 configuring packet attribute, 139 configuring virtual address, 136, 137 creating group, 136, 137 displaying, 140 interface tracking configuration, 152 maintaining, 140 multiple VLANs configuration, 156 single group configuration, 149 specifying MAC address type mapped to virtual IP address, 136 verifying interface tracking configuration, 154 verifying single group configuration, 151 verifying with multiple VLANs configuration, 158

IRF high availability switchover configuration restrictions, 5

IS-IS

BFD supported features, 165

IPv6 IS-IS (BFD supported features), 165

Layer 2 Ethernet OAM configuration, 8, 11, 15

Layer 3

IPv4 VRRP configuration, 131, 140

IPv4 VRRP configuration restrictions, 131

IPv4 VRRP interface tracking configuration, 143

IPv4 VRRP multiple VLANs configuration, 147

IPv4 VRRP single group configuration, 140

IPv6 VRRP configuration, 136, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156 link active state (DLDP), 32 advertisement state (DLDP), 32 auto shutdown of unidirectional link (DLDP), 42 backup mechanism (Smart Link), 99 configuring CFD linktrace on MEP, 25 configuring monitoring (Ethernet OAM), 12

206 delaydown state (DLDP), 32 disable state (DLDP), 32

DLDP auto-recovery mechanism, 37

DLDP configuration, 31, 38, 42

DLDP operation mode and unidirectional link, 33 enabling DLDP, 38

Ethernet OAM configuration, 8, 11, 15 inactive state (DLDP), 32 initial state (DLDP), 32 linktrace (CFD), 20 manual shutdown of unidirectional link (DLDP), 46

Monitor Link configuration, 119, 120, 121

Monitor Link downlink, 120

Monitor Link uplink, 120 monitoring (Ethernet OAM), 10 performance monitoring (Ethernet OAM), 8 probe state (DLDP), 32

RRPP link down mechanism, 54

Smart Link configuration, 97, 100, 104

Smart Link primary link, 98

Smart Link secondary link, 98 link-down RRPPDU type, 52 linktrace

CFD, 20 configuring on MEP, 25 load balancing (RRPP intersecting rings), 58 balancing (RRPP single ring), 57 balancing (RRPP), 54 sharing (IPv4 VRRP), 130 sharing (Smart Link mechanism), 99 loopback

CFD, 20 configuring on MEP, 25

MA (CFD service instance configuration), 22

MAC address

Smart Link uplink traffic-triggered MAC address learning, 99 specifying type mapped to virtual IPv4 address

(VRRP), 132 specifying type mapped to virtual IPv6 address

(VRRP), 136 maintaining

BFD, 167

CFD, 26

DLDP, 42

Ethernet OAM configuration, 14

IPv4 VRRP, 136

IPv6 VRRP, 140

Monitor Link, 121

RRPP, 66

Smart Link, 104 track entries, 175 maintenance association (CFD), 18 domain (CFD), 17

MEP list (CFD), 19 point (CFD), 18 major-fault RRPPDU type, 52 manual

DLDP port shutdown mode, 40 unidirectional link shutdown, 46 mapping specifying MAC address type mapped to virtual

IPv4 address (VRRP), 132 specifying MAC address type mapped to virtual

IPv6 address (VRRP), 136 master

IPv4 VRRP master/backup mode, 130

RRPP node specification, 62

RRPP node type, 51

MD configuring CFD service instances, 22 creating CFD service instance with MD name, 22 creating CFD service instance without MD name,

22 md5 authentication mode (VRRP), 127 mean time between failures. See MTBF to report. See MTTR mechanism

RRPP broadcast storm suppression, 54

RRPP fast detection, 55

RRPP link down, 54

RRPP polling, 53

MEP

CFD continuity check function, 20

CFD linktrace function, 20

CFD loopback function, 20

CFD maintenance point, 18 configuration (CFD), 23 configuring CFD service instances, 22 list, 19 message continuity check (CFD), 20 enabling Smart Link flush message receipt, 103 enabling Smart Link flush send, 102 flush (Smart Link), 98 linktrace (CFD), 20 linktrace reply (CFD), 20 loopback (CFD), 20 loopback reply (CFD), 20

207 method (BFD connectivity detection), 162

MIP

CFD maintenance point, 18 configuring CFD service instances, 22 configuring generation rules (CFD), 23 mode

BFD control packet session, 162

BFD echo packet session, 162 configuring IPv6 VRRP preemptive mode, 138 configuring VRRP preemptive mode, 133

DLDP duplex, 38

DLDP enhanced, 33

DLDP MD5 authentication mode, 34

DLDP non-authentication mode, 34

DLDP normal, 33

DLDP simple authentication mode, 34

IPv4 VRRP master/backup, 130 setting DLDP mode, 39 setting DLDP port shutdown mode, 40

VRRP authentication, 127

VRRP operation, 127

VRRP standard, 125 module collaboration between track and application modules, 169 collaboration between track and detection modules, 168 track configuration, 168, 169, 175

VRRP-track-NQA collaboration track configuration,

175

Monitor Link configuration, 119, 120, 121 configuring group member port, 120 configuring group member port in group view, 120 configuring group member port in interface view,

121 creating group, 120 displaying, 121 downlink, 120 downlink port, 119 group, 119 high availability fault detection technologies, 2 how it works, 120 maintaining, 121

Smart Link collaboration, 100

Smart Link configuration, 119, 120, 121 terminology, 119 uplink, 120 uplink port, 119 verifying configuration, 124 monitoring

configuring link (Ethernet OAM), 12

Ethernet OAM, 8 link (Ethernet OAM), 10 track entry (VRRP), 129

MPLS (BFD supported feature), 165

MPU high availability switchover configuration restrictions, 5 ignoring version check, 5 restarting standby MPU, 6

MSTP (high availability protection switchover technology), 3

MTBF network availability evaluation, 1

MTTR network availability evaluation, 1 multicast continuity check message frame (CFD), 20 linktrace message frame (CFD), 20 multiple groups configuration (Smart Link), 109 name creating CFD service instance with MD name, 22 creating CFD service instance without MD name,

22 neighbor setting DLDP mode, 39 two-way (DLDP state), 38 unidirectional (DLDP state), 38 unknown (DLDP state), 38 network activating RRPP domain, 64

CFD maintenance association, 18

CFD maintenance domain, 17

CFD maintenance point, 18

CFD MEP list, 19 configuring RRPP control VLAN, 60 configuring RRPP node, 62 configuring RRPP port, 62 configuring RRPP protected VLAN, 60 configuring RRPP ring, 61 configuring Smart Link device, 100 enabling DLDP, 38 performing active switchover manually, 6 performing standby switchover manually, 6 restarting standby MPU, 6

RRPP control VLAN, 51

RRPP data VLAN, 51

RRPP domain, 50

RRPP load balancing, 54

RRPP ring group, 54

Smart Link load sharing mechanism, 99

Smart Link primary link, 98

Smart Link primary port, 98

Smart Link secondary link, 98

Smart Link secondary port, 98 network management auto shutdown of unidirectional link (DLDP), 42

BFD configuration, 161, 165

BFD for VRRP backup monitoring configuration,

179

BFD for VRRP uplink monitoring configuration, 182

CFD configuration (high availability), 17, 20, 21,

26

Ethernet OAM configuration, 8, 11, 15 high availability, 1 high availability active switchover configuration, 5 high availability evaluation, 1 high availability standby switchover configuration,

5

IPv4 VRRP configuration, 131, 140

IPv4 VRRP interface tracking configuration, 143

IPv4 VRRP multiple VLANs configuration, 147

IPv4 VRRP single group configuration, 140

IPv6 VRRP configuration, 136, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156 manual shutdown of unidirectional link (DLDP), 46

Monitor Link configuration, 119, 120, 121

RRPP configuration, 50, 59, 67

RRPP dual homed rings configuration, 74

RRPP fast detection configuration, 93

RRPP intersecting rings configuration, 69

RRPP load balanced intersecting rings configuration, 84

RRPP networking, 55

RRPP single ring configuration, 67

Smart Link and CFD continuity check collaboration configuration, 113

Smart Link configuration, 97, 100, 104

Smart Link multiple groups configuration, 109

Smart Link single group configuration, 104 static routing-track-BFD collaboration configuration,

190 static routing-track-NQA collaboration configuration, 185 track configuration, 168, 169, 175 troubleshooting DLDP, 49 verifying auto shutdown of unidirectional link

(DLDP), 44 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183

208

verifying CFD configuration, 29 verifying Ethernet OAM configuration, 15 verifying IPv4 VRRP interface tracking configuration, 145 verifying IPv4 VRRP single group configuration,

142 verifying IPv4 VRRP with multiple VLANs configuration, 148 verifying IPv6 VRRP interface tracking configuration, 154 verifying IPv6 VRRP single group configuration,

151 verifying IPv6 VRRP with multiple VLANs configuration, 158 verifying manual shutdown of unidirectional link

(DLDP), 47 verifying Monitor Link configuration, 124 verifying Smart Link and CFD continuity check collaboration configuration, 117 verifying Smart Link multiple groups configuration,

112 verifying Smart Link single group configuration,

108 verifying static routing-track-BFD collaboration configuration, 191 verifying static routing-track-NQA collaboration configuration, 188 verifying VRRP-track-interface management collaboration configuration, 194

VRRP configuration, 125

VRRP-track-interface management collaboration configuration, 193

VRRP-track-NQA collaboration track configuration,

175 networking

RRPP dual-homed rings topology, 57

RRPP intersecting rings load balancing, 58

RRPP intersecting rings topology, 56

RRPP single ring load balancing, 57

RRPP single ring topology, 55

RRPP tangent rings topology, 56 node configuring RRPP node, 62

RRPP assistant-edge type, 51

RRPP edge type, 51

RRPP master type, 51

RRPP transit type, 51 specifying RRPP assistant-edge node, 63 specifying RRPP edge node, 63 specifying RRPP master node, 62 specifying RRPP transit node, 63 non-preemptive mode (VRRP), 127 normal mode (DLDP), 39

NQA associating with track, 170 configuring static routing-track-NQA collaboration,

185 high availability fault detection technologies, 2 verifying static routing-track-NQA collaboration configuration, 188

VRRP-track-NQA collaboration track configuration,

175

NSR (high availability protection switchover technology), 3 operation mode

BFD active, 163

BFD passive, 163

DLDP enhanced, 33

DLDP normal, 33

VRRP priority, 127 operation, administration and maintenance. See

OAM

OSPF

BFD supported features, 165 v3 BFD supported features, 165 packet

BFD format, 163, 166 configuring IPv4 VRRP attribute, 134 configuring IPv6 VRRP attribute, 139

DLDP processing by type, 35

DLDP state and packet type, 35 setting DLDP send advertisement packet interval,

39

VRRP format, 127 parameter (BFD dynamic change), 163 passive operation mode (BFD), 163 performance monitoring (Ethernet OAM), 8 performing active switchover manually, 6 standby switchover manually, 6

PIM (BFD supported feature), 165 ping. See also loopback (CFD) point (CFD maintenance point), 18 polling mechanism (RRPP), 53 port configuring member port for Smart Link group, 101 configuring member port in interface view, 102 configuring member port in Smart Link group view,

102 configuring Monitor Link group member port, 120 configuring Monitor Link group member port in group view, 120

209

configuring Monitor Link group member port in interface view, 121 configuring role preemption for Smart Link group,

102 configuring RRPP port, 62 enabling DLDP, 38

IPv4 VRRP configuration, 131, 140

IPv4 VRRP configuration restrictions, 131

IPv4 VRRP interface tracking configuration, 143

IPv4 VRRP multiple VLANs configuration, 147

IPv4 VRRP single group configuration, 140

IPv6 VRRP configuration, 136, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156

Monitor Link downlink, 119

Monitor Link group, 119

Monitor Link uplink, 119 resetting DLDP state in port/port group view, 42

RRPP common, 52

RRPP edge, 52

RRPP primary master, 52

RRPP primary transit, 52

RRPP secondary master, 52

RRPP secondary transit, 52 setting DLDP shutdown mode, 40

Smart Link load sharing mechanism, 99

Smart Link primary port, 98

Smart Link secondary port, 98 preemption

Smart Link group, 102

Smart Link mechanism, 99

VRRP delay timer, 127 preemptive mode configuring (IPv6 VRRP), 138 configuring (VRRP), 133

VRRP, 127 primary

RRPP master port, 52

RRPP transit port, 52

Smart Link link, 98

Smart Link port, 98 priority configuring IPv6 VRRP router priority, 138 configuring VRRP router priority, 133

VRRP, 126 probe

DLDP link state, 32 procedure activating RRPP domain, 64 associating track and detection modules, 170

210 associating track with application module, 172 associating track with BFD, 170 associating track with interface management, 171 associating track with NQA, 170 associating track with PBR, 174 associating track with static routing, 173 associating track with VRRP, 172 configuring basic BFD, 165 configuring basic CFD settings, 21 configuring BFD for VRRP backup monitoring, 179 configuring BFD for VRRP uplink monitoring, 182 configuring CFD, 26 configuring CFD continuity check on MEP, 24 configuring CFD function, 24 configuring CFD linktrace on MEP, 25 configuring CFD loopback on MEP, 25 configuring CFD MEP, 23 configuring CFD MIP generation rules, 23 configuring CFD protocol version, 21 configuring CFD service instances, 22 configuring DLDP authentication, 41 configuring DLDP duplex mode, 38 configuring Ethernet interface speed (DLDP), 38 configuring Ethernet OAM basic functions, 11 configuring Ethernet OAM connection detection,

12 configuring Ethernet OAM errored frame event detection, 13 configuring Ethernet OAM errored frame period event detection, 13 configuring Ethernet OAM errored frame seconds event detection, 14 configuring Ethernet OAM errored symbol event detection, 13 configuring Ethernet OAM link monitoring, 12 configuring IPv4 VRRP interface tracking, 143 configuring IPv4 VRRP packet attribute, 134 configuring IPv4 VRRP single group, 140 configuring IPv4 VRRP trap function, 135 configuring IPv4 VRRP with multiple VLANs, 147 configuring IPv6 VRRP, 149 configuring IPv6 VRRP interface tracking, 152 configuring IPv6 VRRP packet attribute, 139 configuring IPv6 VRRP preemptive mode, 138 configuring IPv6 VRRP single group, 149 configuring IPv6 VRRP tracking function, 138 configuring IPv6 VRRP with multiple VLANs, 156 configuring member port for Smart Link group, 101 configuring member port in interface view, 102 configuring member port in Smart Link group view,

102

configuring Monitor Link group member port, 120 configuring Monitor Link group member port in group view, 120 configuring Monitor Link group member port in interface view, 121 configuring protected VLAN for Smart Link group,

101 configuring role preemption for Smart Link group,

102 configuring RRPP control VLAN, 60 configuring RRPP dual homed rings, 74 configuring RRPP fail timer, 64 configuring RRPP fast detection, 65, 93 configuring RRPP fast detection timer, 65 configuring RRPP hello timer, 64 configuring RRPP intersecting rings, 69 configuring RRPP load balanced intersecting rings,

84 configuring RRPP node, 62 configuring RRPP port, 62 configuring RRPP protected VLAN, 60 configuring RRPP ring, 61 configuring RRPP ring group, 66 configuring RRPP single ring, 67 configuring Smart Link and CFD continuity check collaboration, 103, 113 configuring Smart Link associated device, 103 configuring Smart Link device, 100 configuring Smart Link multiple groups, 109 configuring Smart Link single group, 104 configuring static routing-track-BFD collaboration,

190 configuring static routing-track-NQA collaboration,

185 configuring VRRP preemptive mode, 133 configuring VRRP router priority, 133, 138 configuring VRRP tracking function, 133 configuring VRRP virtual IP address, 132 configuring VRRP virtual IPv6 address, 136, 137 configuring VRRP-track-interface management collaboration, 193 configuring VRRP-track-NQA collaboration (track),

175 creating CFD service instance with MD name, 22 creating CFD service instance without MD name,

22 creating Monitor Link group, 120 creating RRPP domain, 59 displaying active switchover, 7 displaying standby switchover, 7 enabling CFD, 21

211 enabling DLDP, 38 enabling RRPP fast detection, 59, 65 enabling Smart Link flush message receipt, 103 enabling Smart Link flush message send, 102 ignoring standby MPU version check, 5 performing active switchover manually, 6 performing standby switchover manually, 6 resetting DLDP state, 41 resetting DLDP state in port/port group view, 42 resetting DLDP state in system view, 41 restarting standby MPU, 6 setting DLDP DelayDown timer, 40 setting DLDP mode, 39 setting DLDP port shutdown mode, 40 setting DLDP send advertisement packet interval,

39 specifying MAC address type mapped to virtual

IPv4 address (VRRP), 132 specifying MAC address type mapped to virtual

IPv6 address (VRRP), 136 specifying RRPP assistant-edge node, 63 specifying RRPP edge node, 63 specifying RRPP master node, 62 specifying RRPP transit node, 63 verifying auto shutdown of unidirectional link

(DLDP), 44 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183 verifying CFD configuration, 29 verifying IPv4 VRRP interface tracking configuration, 145 verifying IPv4 VRRP single group configuration,

142 verifying IPv4 VRRP with multiple VLANs configuration, 148 verifying IPv6 VRRP interface tracking configuration, 154 verifying IPv6 VRRP single group configuration,

151 verifying IPv6 VRRP with multiple VLANs configuration, 158 verifying manual shutdown of unidirectional link

(DLDP), 47 verifying Monitor Link configuration, 124 verifying RRPP dual homed rings configuration, 84 verifying RRPP fast detection configuration, 96 verifying RRPP intersecting rings configuration, 74 verifying RRPP load balanced intersecting rings configuration, 92

verifying RRPP single ring configuration, 69 verifying Smart Link and CFD continuity check collaboration configuration, 117 verifying Smart Link multiple groups configuration,

112 verifying Smart Link single group configuration,

108 verifying static routing-track-BFD collaboration configuration, 191 verifying static routing-track-NQA collaboration configuration, 188 verifying VRRP-track-interface management collaboration configuration, 194 process (DLDP), 35 protected VLAN configuring for Smart Link group, 101

RRPP configuration, 60

Smart Link, 98

Smart Link load sharing mechanism, 99 protection switchover (high availability technology), 2 protocols and standards

BFD, 165

CFD, 20 configuring CFD protocol version, 21

Ethernet OAM, 11

RRPP, 58

RRPP configuration, 50, 59, 67

Rapid Ring Protection Protocol. See RRPP real MAC to virtual IP mapping (VRRP), 132, 136 receive control VLAN (Smart Link), 98 recovering RRPP ring, 54 remote loopback (Ethernet OAM), 8

MEP (CFD), 19, 23 requirements (high availability), 1 restarting standby MPU, 6 restriction high availability switchover configuration, 5

IPv4 VRRP configuration, 131 ring configuring (RRPP), 61 configuring RRPP group, 66 disconnect state (RRPP), 51 health state (RRPP), 51 recovery (RRPP), 54

RRPP group, 52, 54

RIP (BFD supported feature), 165 role

Smart Link group preemption, 102

Smart Link preemption mechanism, 99 routing associating track with PBR, 174 associating track with static routing, 173

BFD packet format, 163, 166 configuring IPv6 VRRP preemptive mode, 138 configuring IPv6 VRRP router priority, 138 configuring IPv6 VRRP tracking function, 138 configuring static routing-track-BFD collaboration,

190 configuring static routing-track-NQA collaboration,

185 configuring VRRP preemptive mode, 133 configuring VRRP router priority, 133 configuring VRRP tracking function, 133 configuring VRRP virtual IP address, 132 configuring VRRP virtual IPv6 address, 136, 137 configuring VRRP-track-interface management collaboration, 193 creating IPv6 VRRP group, 136, 137 creating VRRP group, 132

IPv4 VRRP configuration, 131, 140

IPv4 VRRP configuration restrictions, 131

IPv4 VRRP interface tracking configuration, 143

IPv4 VRRP load sharing, 130

IPv4 VRRP master/backup mode, 130

IPv4 VRRP multiple VLANs configuration, 147

IPv4 VRRP single group configuration, 140

IPv6 VRRP configuration, 136, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156 monitoring track entry (VRRP), 129 tracking specified interface (VRRP), 129 verifying static routing-track-NQA collaboration configuration, 188

VRRP advertisement interval timer, 127

VRRP authentication mode, 127

VRRP configuration, 125

VRRP group, 126

VRRP operation mode, 127

VRRP packet format, 127

VRRP preemption delay timer, 127

VRRP principles, 129

VRRP priority, 126

VRRP standard mode, 125

VRRP timers, 127

VRRP tracking, 129

RRPP activating domain, 64 assistant-edge node type, 51 basic concepts, 50

212

broadcast storm suppression, 54 common port, 52 common-flush-FDB RRPPDU, 52 complete-flush-FDB RRPPDU, 52 configuration, 50, 59, 67 configuring control VLAN, 60 configuring fail timer, 64 configuring fast detection, 65 configuring fast detection timer, 65 configuring hello timer, 64 configuring node, 62 configuring port, 62 configuring protected VLAN, 60 configuring ring, 61 configuring ring group, 66 control VLAN, 51 creating domain, 59 data VLAN, 51 displaying, 66 domain, 50 dual homed rings configuration, 74 dual-homed rings networking, 57 edge node type, 51 edge port, 52 edge-hello RRPPDU, 52 enabling fast detection, 59, 65 fail timer, 53 fast detection configuration, 93 fast detection mechanism, 55 fast-edge-hello RRPPDU, 52 fast-fail timer, 53 fast-hello RRPPDU, 52 fast-hello timer, 53 hello RRPPDU, 52 hello timer, 53 high availability protection switchover technologies, 3 how it works, 53 intersecting rings configuration, 69 intersecting rings load balancing, 58 intersecting rings networking, 56 link down mechanism, 54 link-down RRPPDU, 52 load balanced intersecting rings configuration, 84 load balancing, 54 maintaining, 66 major-fault RRPPDU, 52 master node type, 51 networking, 55 node types, 51 polling mechanism, 53 primary master port, 52 primary transit port, 52 protocols and standards, 58 ring group, 52, 54 ring recovery, 54 ring topology, 51 secondary master port, 52 secondary transit port, 52 single ring configuration, 67 single ring load balancing, 57 single ring networking, 55 specifying assistant-edge node, 63 specifying edge node, 63 specifying master node, 62 specifying transit node, 63 tangent rings networking, 56 transit node type, 51 troubleshooting, 96 verifying dual homed rings configuration, 84 verifying fast detection configuration, 96 verifying intersecting rings configuration, 74 verifying load balanced intersecting rings configuration, 92 verifying single ring configuration, 69

RRPPDU, 51 common-flush-FDB type, 52 complete-flush-FDB type, 52 edge-hello type, 52 fast-edge-hello type, 52 fast-hello type, 52 hello type, 52 link-down type, 52 major-fault type, 52 rule (MIP generation), 23 secondary

RRPP master port, 52

RRPP transit port, 52

Smart Link link, 98

Smart Link port, 98 service instance (CFD), 22 session

BFD establishment, 161

BFD mode, 162 setting

DLDP DelayDown timer, 40

DLDP mode, 39

DLDP port shutdown mode, 40 resetting DLDP state, 41 resetting DLDP state in port/port group view, 42 resetting DLDP state in system view, 41 send advertisement packet interval (DLDP), 39

213

shutdown auto shutdown of unidirectional link (DLDP), 42

DLDP port mode, 40 manual shutdown of unidirectional link (DLDP), 46 simple authentication mode (VRRP), 127 single

RRPP ring network, 55

RRPP ring network load balancing, 57

Smart Link group configuration, 104

Smart Link

CFD continuity check collaboration, 100

CFD continuity check collaboration configuration,

113 collaborating mechanism, 99 configuration, 97, 100, 104 configuring associated device, 103 configuring CFD continuity check collaboration,

103 device configuration, 100 displaying, 104 enabling flush message receipt, 103 enabling flush message send, 102 flush message, 98 flush update mechanism, 99 group, 98 high availability protection switchover technologies, 3 how it works, 99 link backup mechanism, 99 load sharing mechanism, 99 maintaining, 104 member port configuration in interface view, 102 member port configuration in Smart Link group view, 102 member port for group configuration, 101

Monitor Link collaboration, 100

Monitor Link configuration, 119, 120, 121 multiple groups configuration, 109 primary link, 98 primary port, 98 protected VLAN, 98 protected VLAN for group configuration, 101 receive control VLAN, 98 role preemption for group configuration, 102 role preemption mechanism, 99 secondary link, 98 secondary port, 98 single group configuration, 104 terminology, 98 toplogy change mechanism, 99 transmit control VLAN, 98 verifying CFD continuity check collaboration configuration, 117 verifying multiple groups configuration, 112 verifying single group configuration, 108 software (ignoring standby MPU version check), 5 spanning tree (Monitor Link configuration), 119, 120,

121 specifying

MAC address type mapped to virtual IPv4 address

(VRRP), 132

MAC address type mapped to virtual IPv6 address

(VRRP), 136

RRPP assistant-edge node, 63

RRPP edge node, 63

RRPP master node, 62

RRPP transit node, 63

SRPT (RRPP broadcast storm suppression mechanism),

54 standard mode (VRRP), 125 standby performing manual switchover, 6 switchover (high availability technologies), 3 switchover configuration, 5 state active (DLDP link), 32 advertisement (DLDP link), 32 delaydown (DLDP link), 32 disable (DLDP link), 32

DLDP state and packet type, 35 inactive (DLDP link), 32 initial (DLDP link), 32 probe (DLDP link), 32 resetting (DLDP), 41 resetting DLDP state in port/port group view, 42 resetting DLDP state in system view, 41

RRPP ring disconnect state, 51

RRPP ring health state, 51 two-way (DLDP neighbor), 38 unidirectional (DLDP neighbor), 38 unknown (DLDP neighbor), 38 static routing

BFD supported features, 165 configuring static routing-track-BFD collaboration,

190 configuring static routing-track-NQA collaboration,

185 configuring VRRP-track-interface management collaboration, 193 verifying static routing-track-BFD collaboration configuration, 191

214

verifying static routing-track-NQA collaboration configuration, 188 switching

DLDP configuration, 31, 38, 42 high availability active switchover configuration, 5 high availability standby switchover configuration,

5 high availability switchover configuration restrictions, 5 performing active switchover manually, 6 performing standby switchover manually, 6 protection switchover technologies (high availability), 3 switchover (Monitor Link configuration), 119, 120,

121 symbol (Ethernet OAM event detection), 13 tangent rings (RRPP network), 56 technologies active switchover, 6 active switchover configuration, 5 standby switchover, 6 standby switchover configuration, 5 terminology flush message (Smart Link), 98 protected VLAN (Smart Link), 98 receive control VLAN (smart link), 98

Smart Link, 98

Smart Link group, 98 transmit control VLAN (Smart Link), 98 time

MTBF, 1

MTTR, 1 timer active (DLDP), 32 advertisement (DLDP), 32 configuring connection detection (Ethernet OAM),

12 configuring RRPP fail, 64 configuring RRPP fast detection timer, 65 configuring RRPP hello, 64 delaydown(DLDP), 32 echo (DLDP), 32 enhanced (DLDP), 32 entry (DLDP), 32 probe (DLDP), 32 recoverprobe (DLDP), 32

RRPP fail, 53

RRPP fast-fail, 53

RRPP fast-hello, 53

RRPP hello, 53 setting DLDP DelayDown timer, 40

VRRP, 127

VRRP advertisement interval, 127

VRRP preemption delay timer, 127 topology configuring RRPP port, 62 configuring RRPP ring, 61

RRPP configuration, 50, 59, 67

RRPP domain, 50

RRPP dual homed rings configuration, 74

RRPP dual-homed rings, 57

RRPP fast detection configuration, 93

RRPP intersecting rings, 56

RRPP intersecting rings configuration, 69

RRPP load balanced intersecting rings configuration, 84

RRPP networking, 55

RRPP ring group, 54

RRPP single ring, 55

RRPP single ring configuration, 67

RRPP tangent rings, 56

Smart Link change mechanism, 99 tracert. See also linktrace (CFD) track application, 169 associating detection module, 170 associating with application module, 172 associating with BFD, 170 associating with interface management, 171 associating with NQA, 170 associating with PBR, 174 associating with static routing, 173 associating with VRRP, 172

BFD for VRRP backup monitoring configuration,

179

BFD for VRRP uplink monitoring configuration, 182

BFD supported features, 165 collaboration, 168 collaboration between track and application modules, 169 collaboration between track and detection modules, 168 configuration, 168, 169, 175 displaying entries, 175 high availability fault detection technologies, 2 maintaining entries, 175 static routing-track-BFD collaboration configuration,

190 static routing-track-NQA collaboration configuration, 185 verifying BFD for VRRP backup monitoring configuration, 180

215

verifying BFD for VRRP uplink monitoring configuration, 183 verifying static routing-track-BFD collaboration configuration, 191 verifying static routing-track-NQA collaboration configuration, 188 verifying VRRP-track-interface management collaboration configuration, 194

VRRP-track-interface management collaboration configuration, 193

VRRP-track-NQA collaboration configuration, 175 tracking configuring IPv6 VRRP interface tracking, 152 configuring IPv6 VRRP tracking function, 138 configuring VRRP tracking function, 133 monitoring track entry (VRRP), 129 specified interface (VRRP), 129

VRRP, 129 traffic

RRPP load balancing, 54

Smart Link load sharing mechanism, 99

Smart Link uplink traffic-triggered MAC address learning, 99 transit node

RRPP type, 51 specifying RRPP, 63 transmit control VLAN (Smart Link), 98 trapping (IPv4 VRRP trap function configuration), 135 troubleshooting

DLDP, 49 frequent VRRP state transitions, 160 multiple masters present in VRRP group, 160

RRPP master node, 96 screen frequently displays error prompts (VRRP),

159

VRRP, 159 two-way neighbor state (DLDP), 38 type

DLDP state and packet type, 35 packet processing by DLDP state and packet type,

35

UDP (BFD packet format), 163, 166 unicast linktrace reply message frame (CFD), 20 loopback message frame (CFD), 20 unidirectional

DLDP link auto shutdown, 42

DLDP link configuration, 31, 38, 42

DLDP link operation mode, 33

DLDP link troubleshooting, 49

DLDP manual link shutdown, 46

DLDP neighbor state, 38 unknown neighbor state (DLDP), 38 update mechanism (Smart Link flush), 99 uplink

BFD for VRRP uplink monitoring, 182

Monitor Link, 120 port (Monitor Link), 119 traffic-triggered MAC address learning (Smart

Link), 99 verifying auto shutdown of unidirectional link (DLDP), 44

BFD for VRRP backup monitoring configuration,

180

BFD for VRRP uplink monitoring configuration, 183

CFD configuration, 29

Ethernet OAM configuration, 15

IPv4 VRRP interface tracking configuration, 145

IPv4 VRRP single group configuration, 142

IPv4 VRRP with multiple VLANs configuration, 148

IPv6 VRRP interface tracking configuration, 154

IPv6 VRRP single group configuration, 151

IPv6 VRRP with multiple VLANs configuration, 158 manual shutdown of unidirectional link (DLDP), 47

Monitor Link configuration, 124

RRPP dual homed rings configuration, 84

RRPP fast detection configuration, 96

RRPP intersecting rings configuration, 74

RRPP load balanced intersecting rings configuration, 92

RRPP single ring configuration, 69

Smart Link and CFD continuity check collaboration configuration, 117

Smart Link multiple groups configuration, 112

Smart Link single group configuration, 108 static routing-track-BFD collaboration configuration,

191 static routing-track-NQA collaboration configuration, 188

VRRP-track-interface management collaboration configuration, 194 version

CFD protocol version configuration, 21 check (standby MPU), 5 virtual

IP address configuration (IPv6 VRRP), 136, 137

IP address (MAC address type mapping), 132,

136

IP address configuration (VRRP), 132

MAC to virtual IP mapping (VRRP), 132, 136 router redundancy protocol. See VRRP

216

VRRP router, 126

VLAN

CFD configuration (high availability), 17, 20, 21,

26

CFD maintenance association, 18 configuring IPv6 VRRP with multiple VLANs, 156 configuring protected VLAN for Smart Link group,

101 configuring RRPP control VLAN, 60 configuring RRPP port, 62 configuring RRPP protected VLAN, 60 configuring Smart Link device, 100 control (RRPP), 51 data (RRPP), 51

IPv4 VRRP multiple VLANs configuration, 147

IPv6 VRRP configuration, 149

IPv6 VRRP interface tracking configuration, 152

IPv6 VRRP single group configuration, 149

IPv6 VRRP with multiple VLANs configuration, 156

MEP configuration (CFD), 23 protected VLAN (Smart Link), 98 receive control VLAN (Smart Link), 98

RRPP domain, 50

RRPP load balancing, 54

Smart Link load sharing mechanism, 99 transmit control VLAN (Smart Link), 98

VRRP advertisement interval, 127 authentication mode, 127 configuration, 125 configuring BFD for VRRP backup monitoring, 179 configuring BFD for VRRP uplink monitoring, 182 configuring IPv4 packet attribute, 134 configuring IPv4 trap function, 135 configuring IPv6 packet attribute, 139 configuring IPv6 preemptive mode, 138 configuring IPv6 router priority, 138 configuring IPv6 tracking function, 138 configuring preemptive mode, 133 configuring router priority, 133 configuring tracking function, 133 configuring virtual IP address, 132 configuring virtual IPv6 address, 136, 137 configuring VRRP-track-interface management collaboration collaboration, 193 creating group, 132

217 creating IPv6 group, 136, 137 group, 126 high availability protection switchover technologies, 3

IPv4 application, 130

IPv4 configuration, 131, 140

IPv4 configuration restrictions, 131

IPv4 interface tracking configuration, 143

IPv4 load sharing, 130

IPv4 master/backup mode, 130

IPv4 multiple VLANs configuration, 147

IPv4 single group configuration, 140

IPv6 configuration, 136, 149

IPv6 interface tracking configuration, 152

IPv6 single group configuration, 149

IPv6 with multiple VLANs configuration, 156 monitoring track entry, 129 operation mode, 127 packet format, 127 preemption delay timer, 127 principles, 129 priority, 126 specifying MAC address type mapped to virtual

IPv4 address, 132 specifying MAC address type mapped to virtual

IPv6 address, 136 standard mode, 125 timer, 127 tracking, 129 tracking specified interface, 129 troubleshooting, 159 troubleshooting frequent state transitions, 160 troubleshooting multiple masters present in group,

160 troubleshooting screen frequently displays error prompts, 159 v2 packet format, 127 v3 packet format, 127 verifying BFD for VRRP backup monitoring configuration, 180 verifying BFD for VRRP uplink monitoring configuration, 183 verifying VRRP-track-interface management collaboration configuration, 194

VRRP-track-NQA collaboration track configuration,

175

advertisement

Key Features

  • Active and standby switchover
  • Ethernet OAM
  • CFD (Connectivity Fault Detection)
  • DLDP (Dynamic Link Discovery Protocol)
  • RRPP (Redundant Ring Protocol Plus)
  • Smart Link
  • Monitor Link
  • VRRP (Virtual Router Redundancy Protocol)
  • BFD (Bidirectional Forwarding Detection)

Frequently Answers and Questions

What are some of the high availability features for HP 10500 Switch Series?
The HP 10500 Switch Series offers a range of high availability features, including active and standby switchover, Ethernet OAM, CFD, DLDP, RRPP, Smart Link, Monitor Link, and VRRP. These features help you enhance network reliability and minimize downtime.
How does the HP 10500 Switch Series detect and recover from network faults?
The switch uses various fault detection technologies, like CFD, DLDP, Ethernet OAM, and BFD, to detect network failures. Protection switchover technologies, such as active and standby switchover, RRPP, Smart Link, and VRRP, allow the switch to seamlessly reroute traffic and restore network connectivity.
What are the key benefits of using high availability features on the HP 10500 Switch Series?
Implementing high availability features on your HP 10500 Switch Series can significantly improve network reliability, minimize downtime, and ensure uninterrupted service delivery. This is crucial for critical applications like video conferencing, IPTV, and other essential services.

Related manuals

Download PDF

advertisement

Table of contents