Implementing HP A-Series Networks Book 1

Implementing HP A-Series Networks
Rev. 11.21 - Course #: 00324573

Part Number: 00324573S11105 – Book 1 of 2
Student guide
HP Partner Learning
Rev. 11.21 - Course #: 00324573

Part Number: 00324573S11105 – Book 1 of 2
Student guide
HP Partner Learning
 Copyright 2011 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. 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.
This is an HP copyrighted work that may not be reproduced without the written permission of
HP. You may not use these materials to deliver training to any person outside of your
organization without the written permission of HP.
Printed in United States of America
Implementing HP A-Series Networks –v11.21
Student guide – Book 1 of 2
May 2011
HP Restricted
Contents
Introduction
Welcome to Implementing HP A-Series Networks ……………………………. 1
Module 1: VLANs and IP Gateway Features

Objectives – Agenda – References …………………………………………….. 1-1
Activity 1.1: VLAN Types ……………………………………………………….. 1-2
Activity 1.2: Special VLANs and Local Proxy ARP ……………………………. 1-11
Activity 1.3: Configuring MSTP and VRRP …………………………………….. 1-15
Appendix 1A: Port Link-Type and Frame Handling ………………………….. 1-20
Appendix 1B: Reference manuals for Learning Activities ……………………. 1-21
Module 2: WAN Links

Activity 2.1: PPP …………………………………………………………………. 2-2
Activity 2.2: Frame Relay ……………………………………………………….. 2-5
Appendix 2A: Reference manuals for Learning Activities ……………………. 2-6
Module 3: IP Routing
Activity 3.1: OSPF network types ………………………………………………. 3-2
Activity 3.2: Multi-area OSPF …………………………………………………... 3-6
Activity 3.3: eBGP ……………………………………………………………….. 3-11
Appendix 3A: Reference manuals for Learning Activities ……………………. 3-12
Rev. 11.21 i
Introduction
Welcome to Implementing HP A-Series Networks

This training can provide you with the skills necessary to deploy and configure HP
A-Series switches and routers to meet advanced connectivity needs of today’s
medium to large campuses. Emphasizing hands-on lab activities and interactive
classroom exercises, this training covers key elements that will be required anytime
you must deploy, re-deploy, or maintain HP A-Series switches and routers.
Prerequisites
The prerequisites for this training are:
HP AIS – Network Infrastructure certification or equivalent knowledge
HP A-Series Networking Technologies
HP Switching and Routing Technologies
Certification
Completing Implementing HP A-Series Networks, along with the prerequisites, helps
you prepare to take the examination for the HP ASE - Network Infrastructure
certification.
Rev. 11.21 Introduction – 1

VLANs and IP Gateway Features
Module 1
Objectives
At the end of this module you will be able to:
Describe and explain and implement in A-Series switches the following VLAN
features:
x Port-based VLANs, and in particular: Hybrid Link-type Ports
x Protocol-based VLANs, IP-subnet-based VLANs and MAC-address based
VLANs
x SuperVLANs and Isolate-user VLANs
Explain the need for and implement in A-Series switches the local-proxy-ARP
feature
Describe, explain and implement in A-Series switches the MSTP/VRRP
redundancy solution for LANs
Agenda
Activity 1.1: VLAN Types
Activity 1.2: Special VLANs and Local Proxy ARP
Activity 1.3: Combining MSTP and VRRP
Activity 1.4: LAB
References
For the Learner Activities in this module, read the following volumes of the
Operations Manual and/or Command Reference Manual at the end of this module
in Appendix 1B:
Topic Product Volume

VLAN Types H3C S7500 Series Switch 01 - Access
Special VLANs H3C S7500 Series Switch 01 - Access
Local-proxy ARP H3C S7500 Series Switch 02 - IP Services
MSTP H3C S7500 Series Switch 01 - Access
VRRP H3C S7500 Series Switch 08 - System
Table 1.0.1: References by Topic
Rev. 11.21 1 –1
Activity 1.1: VLAN Types

Introduction
In this first part of module 1 the following features will be reviewed:
VLAN Types
PVID
Port-based VLANs: Hybrid Ports
Protocol-based VLANs
IP-subnet-based VLANs
MAC-address-based VLANs
VLAN Types
Every frame inside an A-Series switch MUST have a VLAN ID.
x Technical Note: the frame is not modified by the ingress process. The VLAN
ID is stored in a “Packet Descriptor” database
This assignment is performed as part of the ingress process of every switch.
Figure 1.1: Ingress Port and VLAN ID
The VLAN type determines how Ethernet frames are assigned a VLAN ID.
1 –2 Rev. 11.21
A-Series VLAN Types

A-Series Switches support the following VLAN types:
x Port-based VLANs *
x Protocol-based VLANs
x IP-subnet-based VLANs
x MAC-address-based VLANs
x Voice-VLAN *
(*) Covered in the AIS Training Program
PVID (Port VLAN ID)

Factory default:
x All ports: Access link-type
x All PVIDs = 1
The PVID can be modified (In Ethernet Port View)
The PVID is also called the port’s default VLAN
Rev. 11.21 1 –3
Learner Activity: Look-up and discuss

Introduction
This activity consists of two phases:
Individual phase: Each learner will use the product manuals listed above to look
up the answers for the questions or the information required to fill the tables (see
below)
Group phase: The class as a whole will discuss and verify the answer to each
question
Question 1: Port-based VLANs / Port link-types

1. In the following table (2.1) enter the minimum and maximum number of
untagged and tagged VLANs supported by each port link-type.
Note:
x Min can be 0 or 1
x Max can be 0, 1 or Many
Access Trunk Hybrid

Min
Untagged VLANs
Max
Min
Tagged VLANs
Max
Table 1.1.1: Port link-types
1 –4 Rev. 11.21
Question 2: Port-based VLANs / Port link-types

In the following table fill in how an incoming frame is handled in each case:
a. Access Port
x Frame is Untagged Example: PVID is assigned to the frame and the frame
is processed
x Frame is Tagged
x FVID=PVID
x Frame is Tagged
x FVID<>PVID
Table 1.1.2: Access Link-type Frame Processing
b. Trunk Port
x Frame is Untagged
x Frame is Tagged
x FVID is in permitted
VLANs list
x Frame is Tagged
x FVID is not in
permitted VLANs list
Table 1.1.3: Trunk Link-type Frame Processing
Rev. 11.21 1 –5
c. Hybrid Port
x Frame is Untagged
x One or more untagged
VLANs are enabled in
the port
x Frame is Untagged
x Only Tagged VLANs are
enabled in the port
x No PVID is configured
in the port
x Frame is Untagged
x Only Tagged VLANs are
enabled in the port
x PVID is one of the
tagged VLANs
x Frame is Tagged
x FVID is in enabled
VLANs list
x Frame is Tagged
x FVID is not in enabled
VLANs list
Table 1.1.4: Hybrid Link-type Frame Processing
1 –6 Rev. 11.21
Question 3: Hybrid Port Link-type usage

In the space below, describe two situations for which hybrid ports are the solution.
Consider a two tier LAN.
Figure 1.2: Two-tier LAN
Rev. 11.21 1 –7
Question 4: VLAN Types

In the following table (2.2), for each column (VLAN type) mark with an X the field in
either the Ethernet of the IP header field used by the switch to identify the VLAN to
which the incoming frame belongs.
MAC-
Port- Protocol- IP-subnet-
address
based based based
-based
VLAN VLAN VLAN
VLAN
Destination Address
Source Address
Ethernet
802.1Q Tag
EtherType
ToS / DSCP
Source Address
IP
Destination Address
Protocol
Table 1.1.5: Frame fields and VLAN Types
1 –8 Rev. 11.21
Configuring VLAN Types in A-Series Switches

In this section basic configuration procedures are presented. No CLI commands are
shown. For these commands read the Access Volume of the Configuration /
Operations Guide and / or the Command Reference Guide of the A-Series device.
Hybrid Link-type
1. Create the VLANs
2. Enter Ethernet port view, layer-2 aggregate interface (link aggregation group)
view, or manual port group view:
3. Configure the port link type as hybrid
4. Configure current hybrid port(s) to permit the packets of the specified protocol-
based VLANs to pass through
Protocol-based VLAN
1. Create one or more hybrid port (See above)
5. Enter VLAN View
6. Create a protocol template for the VLAN
view, or manual port group view
8. Associate the hybrid port(s) with the specified protocol-based VLAN
IP-subnet-based VLAN
2. Enter VLAN View
3. Associate an IP subnet with the current VLAN
5. Associate the hybrid port(s) with the specified IP subnet-based VLAN
MAC-address-based VLAN
2. In system view, associate MAC addresses with a VLAN
Rev. 11.21 1 –9
4. Enable MAC-based VLAN
VLAN Match Precedence

If both MAC-based and IP-subnet based VLANs are enabled in the same port,
configure the matching precedence to select which address will be considered first.
By default the MAC address criterion takes precedence.
1 –10 Rev. 11.21

Activity 1.2: Special VLANs and Local Proxy ARP
Introduction
A-Series Switches support:
x SuperVLAN (chassis-based switches only)
x Isolate-user VLANs
x Basic and Selective (Class-based) QinQ **
x VLAN Mapping **
(**) Covered in the MASE training program
Isolate-user-VLAN and SuperVLAN

A-Series switches support 2 similar features:
x Isolate-user-VLANs:
Re-use VLAN IDs
Block communication between different groups of hosts within the same
VLAN
x SuperVLAN:
Share the IP default gateway among a group of VLANs
Rev. 11.21 1 –11


Introduction
below)
question
Question 1: Isolate-user-VLAN and SuperVLAN (2)

1. In the following table, mark with an X to which layer each one of these features
belongs:
Layer 2 Layer 3
Isolate-user-VLAN
SuperVLAN
Table 1.2.1: Special VLAN and OSI Layer
5. In the following table, mark with an X the VLAN Type represented in each
diagram.
Figure 2.1: Diagram 1 Figure 2.2: Diagram 2
! Important
SuperVLAN is only supported in chassis-based switches: A7500, A9500, and
A12500.
1 –12 Rev. 11.21

Question 2: Local-Proxy ARP

1. Explain why there is no communication between hosts in different sub-VLANs /
secondary VLANs.
2. Describe how Local-proxy ARP can re-establish that communication.
Rev. 11.21 1 –13

Configuring A-Series Switches

SuperVLAN
In an A-Series modular switch:
1. Create all VLANs (Do not assign ports to the super VLAN candidate)
2. In the VLAN view of the super VLAN candidate, define it as SuperVLAN and
assign the sub-VLANs
Isolate-user VLAN
In the Layer 2 Switch:
1. Create the VLAN (Isolate-user VLAN candidate) and assign it the uplink port
2. Configure the VLAN as an isolate-user-VLAN and assign them the respective
ports
3. In system view, associate the isolate-user-VLAN with the specified secondary
VLANs
Local-proxy ARP
Local-proxy ARP must be enabled in the VLAN interface of the SuperVLAN or the
Isolate-user VLAN.
1. Enter the VLAN interface
2. Configure the IPv4 address
3. Enable local-proxy ARP
1 –14 Rev. 11.21

Activity 1.3: Configuring MSTP and VRRP

Introduction
MSTP Review
Multiple STP regions
Multiple Spanning Trees per Region - Called “STP

Instances”
Each instance has a different root
VLANs mapped to Instances
VRRP Review
Provides IP Gateway redundancy
Load Balancing:
x Several Virtual Routers
With the same real routers
And different masters
x Different host groups use a
different Virtual Router as
gateway
Rev. 11.21 1 –15

Learner Activity: Group Analysis

Introduction
The class as a whole will discuss and verify the answer to each question
MSTP/VRRP Planning
Note
For simplicity and clarity a two tier network is considered for the following
analysis. In the lab debrief activity below, different cases of three tier LANs will
be analyzed.
Given the following conditions in the network shown in figure 2.3, answer questions
1 through 5:
Figure 1.3.1: Two tier redundant LAN
5 VLANs are configured (besides the Management VLAN) and all VLANs must
be available to all access layer switches
Given the applications, it is expected that, in average, the traffic distribution
among the different VLANs will be:
VLAN % of Total Traffic

2 10
3 25
4 30
5 30
6 5
Table 1.3.1: Traffic Load Distribution
The CIST (Instance 0 is reserved for the management VLAN)

Load balancing is required
All routing is done at the core level
1 –16 Rev. 11.21

Note
In some of the tables below there are more rows than necessary, fill only those
that are needed and leave the redundant rows blank.
1. How many spanning tree instances (besides the CIST) should be configured?
2. How should VLANs be mapped to spanning instances for optimal load

balancing? (Mark with an X)
Instance Nr: VLAN 2 VLAN 3 VLAN 4 VLAN 5 VLAN 6
0
1
2
3
4
Table 1.3.2: VLAN to Instance Mapping
3. How should the instance root roles be distributed among the core switches?
Instance Nr: Core Switch 1 Core Switch 2
0
1
2
3
4
Table 1.3.3: Instance Root Bridge Mapping
4. How many Virtual Routers should be created?
5. How should the VRRP master and backup roles be distributed between the core
switches?
Virtual Router Core Switch 1 Core Switch 2
1
2
3
4
Table 1.3.4: VRRP Master and Backup Router Mapping
Rev. 11.21 1 –17

Configuring the MSTP/VRRP solution in A-Series Switches

In this section, the procedure to configure the MSTP/VRRP redundancy solution in A-
Series switches is presented. The procedure presented refers to the network shown in
figure 2.3.
These steps assume that all VLANs and IP addresses have been already configured
in all devices.
MSTP
1. Configure MSTP in Core Switch 1
a. Enable STP
Note
In A-Series switches the default STP operation mode is MSTP.
b. Configure the MSTP region.

1) Assign a name
2) Map each VLAN to one of two MSTP instances (Instance 1 and
Instance 2)
3) Configure the revision-level
4) Activate the region
c. Configure the switch as the Primary Root of Instance 1 and Secondary Root
of Instance 2
2. Configure MSTP in Core Switch 2

a. Enable STP
b. Configure and activate the MSTP region using exactly the same parameters
as in the Core Switch 1
c. Configure the switch as the Primary Root of Instance 2 and Secondary Root
of Instance 1
3. Configure MSTP in each access layer switch

a. Enable STP
b. Configure and activate the MSTP region using exactly the same parameters
as in the Core Switch 1
1 –18 Rev. 11.21

VRRP
1. Configure VRRP in each Core Switch
a. In each VLAN interface
1) Configure the IP address of the virtual switch (vrid virtual-ip) that is the
default gateway for that VLAN
2) If this switch is the Primary Root for the Instance to which this VLAN has
been mapped, raise the virtual router priority above 100 (100 is the
default) to force this switch to be the master device for this virtual router
Rev. 11.21 1 –19

Appendix 1.A: Port Link-Type and Frame Handling

Note: FVID or “Frame VLAN ID” refers to the VLAN ID carried in the tagged frame
Port Link-Type: Access

Conditions Actions
x Frame is Untagged x PVID is assigned to Frame
x Frame is processed
x Frame is Tagged x FVID is preserved
x FVID=PVID x Frame is processed
x Frame is Tagged x Frame is discarded
x FVID<>PVID
Table 1.A.1: Frame Handling in Access Link-type Ports
Port Link-Type: Trunk

Conditions Actions
x Frame is processed
x FVID is in permitted VLANs list x Frame is processed
x FVID is not in permitted VLANs list
Table 1.A.2: Frame Handling in Trunk Link-type Ports
Port Link-Type: Hybrid (no other VLAN type configured in the port)
Conditions Actions
x One or more untagged VLANs are enabled Frame is processed
in the port
x Frame is Untagged x Frame is discarded
x Only Tagged VLANs are enabled in the port
x No PVID is configured in the port
x Only Tagged VLANs are enabled in the port Frame is processed
x PVID is one of the tagged VLANs
x FVID is in enabled VLANs list Frame is processed
x FVID is not in enabled VLANs list
Table 1.A.3: Frame Handling in Hybrid Link-type Ports
1 –20 Rev. 11.21

Appendix 1.B: Reference manuals for Learning

Activities
VLAN
Vlan configuration
Super Vlan configuration
Isolate-User-Vlan configuration
Voice Vlan Configuration
MSTP
MSTP configuration
ARP
ARP configuration
Proxy ARP configuration
ARP Attack Defense configuration
Voice Vlan Configuration
VRRP
VRRP configuration
Rev. 11.21 1 –21

Table of Contents
1 VLAN Configuration ··································································································································1-1

Introduction to VLAN ·······························································································································1-1
VLAN Overview ·······························································································································1-1
VLAN Fundamentals ·······················································································································1-2
Types of VLAN ································································································································1-3
Configuring Basic VLAN Settings ···········································································································1-3
Configuring Basic Settings of a VLAN Interface ·····················································································1-4
Port-Based VLAN Configuration ·············································································································1-5
Introduction to Port-Based VLAN ····································································································1-5
Assigning an Access Port to a VLAN ······························································································1-6
Assigning a Trunk Port to a VLAN···································································································1-7
Assigning a Hybrid Port to a VLAN ·································································································1-8
MAC-Based VLAN Configuration············································································································1-9
Introduction to MAC-Based VLAN···································································································1-9
Approaches to Creating MAC Address-to-VLAN Mappings··························································1-10
Configuring a MAC Address-Based VLAN ····················································································1-10
Protocol-Based VLAN Configuration·····································································································1-11
Introduction to Protocol-Based VLAN····························································································1-11
Configuring a Protocol-Based VLAN ·····························································································1-11
IP Subnet-Based VLAN Configuration ··································································································1-13
Introduction····································································································································1-13
Configuring an IP Subnet-Based VLAN ························································································1-13
Displaying and Maintaining VLAN·········································································································1-14
VLAN Configuration Example ···············································································································1-15
2 Super VLAN Configuration ·······················································································································2-1

Overview ·················································································································································2-1
Configuring a Super VLAN······················································································································2-1
Displaying and Maintaining Super VLAN ································································································2-2
Super VLAN Configuration Example·······································································································2-2
3 Isolate-User-VLAN Configuration ············································································································3-1

Overview ·················································································································································3-1
Configuring Isolate-User-VLAN···············································································································3-1
Displaying and Maintaining Isolate-User-VLAN······················································································3-3
Isolate-User-VLAN Configuration Example·····························································································3-3
4 Voice VLAN Configuration························································································································4-1

Overview ·················································································································································4-1
Voice VLAN Assignment Modes ·····································································································4-2
Security Mode and Normal Mode of Voice VLANs ·········································································4-3
Configuring a Voice VLAN ······················································································································4-3
Configuration Prerequisites ·············································································································4-3
Setting a Port to Operate in Automatic Voice VLAN Assignment Mode ·········································4-4
Setting a Port to Operate in Manual Voice VLAN Assignment Mode ·············································4-5
i
Displaying and Maintaining Voice VLAN·································································································4-6
Voice VLAN Configuration Examples ·····································································································4-6
Automatic Voice VLAN Mode Configuration Example ····································································4-6
Manual Voice VLAN Mode Configuration Example·········································································4-8
ii
1 VLAN Configuration
When configuring VLAN, go to these sections for information you are interested in:
z Introduction to VLAN
z Configuring Basic VLAN Settings
z Configuring Basic Settings of a VLAN Interface
z Port-Based VLAN Configuration
z MAC-Based VLAN Configuration
z Protocol-Based VLAN Configuration
z Displaying and Maintaining VLAN
z VLAN Configuration Example
Introduction to VLAN
VLAN Overview
Ethernet is a network technology based on the Carrier Sense Multiple Access/Collision Detect
(CSMA/CD) mechanism. As the medium is shared, collisions and excessive broadcasts cannot be
avoided on an Ethernet. To address the issue, virtual LAN (VLAN) was introduced.
The idea is to break a LAN down into separate VLANs, that is, Layer 2 broadcast domains whereby
frames are switched between ports assigned to the same VLAN. VLANs are isolated from each other at
Layer 2. A VLAN is a bridging domain, and all broadcast traffic is contained within it, as shown in Figure
1-1.
Figure 1-1 A VLAN diagram
VLAN 2
Switch A Switch B
Router
VLAN 5
A VLAN is logically divided on an organizational basis rather than on a physical basis. For example, all
workstations and servers used by a particular workgroup can be connected to the same LAN,
regardless of their physical locations.
VLAN technology delivers the following benefits:
1-1
1) Confining broadcast traffic within individual VLANs. This reduces bandwidth waste and improves
network performance.
2) Improving LAN security. By assigning user groups to different VLANs, you can isolate them at
Layer 2. To enable communication between VLANs, routers or Layer 3 switches are required.
3) Flexible virtual workgroup creation. As users from the same workgroup can be assigned to the
same VLAN regardless of their physical locations, network construction and maintenance is much
easier and more flexible.
VLAN Fundamentals
To enable a network device to identify frames of different VLANs, a VLAN tag field is inserted into the
data link layer encapsulation.
The format of VLAN-tagged frames is defined in IEEE 802.1Q issued by IEEE in 1999.
In the header of a traditional Ethernet data frame, the field after the destination MAC address and the
source MAC address is the Type field indicating the upper layer protocol type, as shown in Figure 1-2.
Figure 1-2 The format of a traditional Ethernet frame
IEEE 802.1Q inserts a four-byte VLAN tag after the DA&SA field, as shown in Figure 1-3.
Figure 1-3 The position and format of VLAN tag
A VLAN tag comprises four fields: tag protocol identifier (TPID), priority, canonical format indicator (CFI),
and VLAN ID.
z The 16-bit TPID field indicates that the frame is VLAN-tagged. The value specified by IEEE 802.1Q
is 0x8100.
z The 3-bit priority field indicates the 802.1p priority of the frame. For information about frame priority,
refer to QoS Configuration in the QoS Volume.
z The 1-bit CFI field specifies whether the MAC addresses are encapsulated in the standard format
when packets are transmitted across different media. Value 0 indicates that MAC addresses are
encapsulated in the standard format; value 1 indicates that MAC addresses are encapsulated in a
non-standard format. The filed is 0 by default.
z The 12-bit VLAN ID field identifies the VLAN the frame belongs to. The VLAN ID range is 0 to 4095.
As 0 and 4095 are reserved by the protocol, a VLAN ID actually ranges from 1 to 4094.
When receiving a frame, a network device looks at its VLAN tag to decide how to handle the frame. For
more information, refer to section Introduction to Port-Based VLAN.
1-2
z The Ethernet II encapsulation format is used here. Besides the Ethernet II encapsulation format,
other encapsulation formats, including 802.2 LLC, 802.2 SNAP, and 802.3 raw, are also supported
by Ethernet. The VLAN tag fields are also added to frames encapsulated in these formats for VLAN
identification.
z For a frame with multiple VLAN tags, the device handles it according to its outer-most VLAN tag,
while transmits its inner VLAN tags as payload.
Types of VLAN
You can implement VLAN based on:

z Port
z MAC address
z Protocol
z IP subnet
z Policy
z Other criteria
This chapter covers port-based VLAN, MAC-based VLAN, protocol-based VLAN, and IP-based VLAN.
You can configure the four types of VLANs on a port at the same time. When determining to which
VLAN a packet passing through the port should be assigned, the device looks up the VLANs in the
default order of MAC-based VLANs, IP-based VLANs, protocol-based VLANs, and port-based VLANs.
Configuring Basic VLAN Settings

Follow these steps to configure basic VLAN settings:
To do… Use the command… Remarks

Enter system view system-view —
Optional
vlan { vlan-id1 [ to
Create VLANs Using this command can create multiple
vlan-id2 ] | all }
VLANs in bulk.
Required
If the specified VLAN does not exist, this
Enter VLAN view vlan vlan-id command creates the VLAN first.
By default, only the default VLAN (that is,
VLAN 1) exists in the system.
Configure the Optional

description of the description text VLAN ID is used by default, for example,
current VLAN VLAN 0001.
1-3
z As the default VLAN, VLAN 1 cannot be created or removed.
z You cannot manually create or remove VLANs reserved for special purposes.
z Dynamic VLANs cannot be removed with the undo vlan command.
z A VLAN with a QoS policy applied cannot be removed.
z After associating an isolate-user-VLAN with a secondary VLAN, you cannot add ports to, remove
ports from, or remove, the VLANs. To do that, remove the association first.
z A VLAN operating as a probe VLAN for remote port mirroring or an RRPP protected VLAN cannot
be removed with the undo vlan command. To do that, remove the remote mirroring VLAN or
RRPP protected VLAN configuration from it first.
Configuring Basic Settings of a VLAN Interface

For hosts of different VLANs to communicate, you must use a router or Layer 3 switch to perform layer
3 forwarding. To achieve this, VLAN interfaces are used.
VLAN interfaces are virtual interfaces used for Layer 3 communication between different VLANs. They
do not exist as physical entities on devices. For each VLAN, you can create one VLAN interface. You
can assign the VLAN interface an IP address and specify it as the gateway of the VLAN to forward traffic
destined for an IP network segment different from that of the VLAN.
Follow these steps to configure basic settings of a VLAN interface:

Required
Create a VLAN interface and interface vlan-interface
enter VLAN interface view vlan-interface-id If the VLAN interface already exists,
you enter its view directly.
Optional
Assign an IP address to the ip address ip-address
VLAN interface { mask | mask-length } [ sub ] No IP address is assigned to any
VLAN interface by default.
Optional
Configure the description of VLAN interface name is used by
description text
the VLAN interface default, for example,
Vlan-interface1 Interface.
Optional
By default, a VLAN interface is in the
up state. In this case, the VLAN
interface is up so long as one port in
the VLAN is up and goes down if all
Bring up the VLAN interface undo shutdown ports in the VLAN go down.
An administratively shut down VLAN
interface however will be in the down
state until you bring it up, regardless
of how the state of the ports in the
VLAN changes.
1-4
Before creating a VLAN interface for a VLAN, create the VLAN first.
Port-Based VLAN Configuration

Introduction to Port-Based VLAN
Port-based VLANs group VLAN members by port. A port forwards traffic for a VLAN only after it is
assigned to the VLAN.
Port link type
Depending on the tag handling mode, the link type of a port can be one of the following three:
z Access. An access port belongs to only one VLAN and usually connects to a user device.
z Trunk. A trunk port can join multiple VLANs to receive and send traffic for them. It usually connects
to a network device.
z Hybrid. A hybrid port can join multiple VLANs to receive and send traffic for them. It can connect
either a user device or a network device.
A hybrid port is different from a trunk port in that:
z A hybrid port allows traffic of multiple VLANs to pass through untagged.
z A trunk port allows only traffic of the default VLAN to pass through untagged.
Default VLAN
By default, VLAN 1 is the default VLAN for all ports. You can configure the default VLAN for a port as
required.
Use the following guidelines when configuring the default VLAN on a port:
z Because an access port can join only one VLAN, its default VLAN is the VLAN to which it belongs
and cannot be configured.
z Because a trunk or hybrid port can join multiple VLANs, you can configure a default VLAN for the
port.
z You can use a nonexistent VLAN as the default VLAN for a hybrid or trunk port but not for an
access port. Therefore, after you remove the VLAN that an access port resides in with the undo
vlan command, the default VLAN of the port changes to VLAN 1. The removal of the VLAN
specified as the default VLAN of a trunk or hybrid port, however, does not affect the default VLAN
setting on the port.
1-5
z Do not set the voice VLAN as the default VLAN of a port in automatic voice VLAN assignment
mode. Otherwise, the system prompts error information. For information about voice VLAN, refer to
Voice VLAN Configuration.
z The local and remote ports must use the same default VLAN ID for the traffic of the default VLAN to
be transmitted properly.
A port configured with the default VLAN handles a frame as follows:
Actions (in the inbound direction) Actions (in the

Port type
Untagged frame Tagged frame outbound direction)
z Receive the frame if its

VLAN ID is the same as the
Tag the frame with default VLAN ID. Remove the default VLAN
Access the default VLAN
z Drop the frame if its VLAN tag and send the frame.
tag.
ID is different from the
default VLAN ID.
z Remove the tag and
send the frame if the
frame carries the
default VLAN tag.
Trunk z Send the frame without
Check whether the removing the tag if its
default VLAN is VLAN is carried on the
carried on the port: port but is different
z Receive the frame if its
z If yes, tag the VLAN is carried on the port. from the default one.
frame with the z Drop the frame if its VLAN
default VLAN Send the frame if its VLAN
is not carried on the port. is carried on the port. The
tag.
frame is sent with the
z If not, drop the
VLAN tag removed or
frame.
Hybrid intact depending on your
configuration with the port
hybrid vlan command.
This is true of the default
VLAN.
Assigning an Access Port to a VLAN
You can assign an access port to a VLAN in VLAN view, Ethernet port view, Layer-2 aggregate interface
view, or port group view.
1) In VLAN view
Follow these steps to assign one or multiple access ports to a VLAN in VLAN view:

Required
Enter VLAN view vlan vlan-id If the specified VLAN does not exist,
this command creates the VLAN first.
1-6
Assign one or a group of Required
access ports to the current port interface-list
VLAN By default, all ports belong to VLAN 1.
2) In interface or port group view

Follow these steps to assign an access port (in Ethernet port view) or multiple access ports (in Layer-2
aggregate interface view or port group view) to a VLAN:

Enter Ethernet interface interface-type Required
port view interface-number Use either command.
Enter Enter Layer-2 interface z In Ethernet port view, the
Ethernet port aggregate bridge-aggregation subsequent configurations apply to
view/port interface view interface-number the current port.
group z In port group view, the subsequent
view/Layer-2 configurations apply to all ports in
aggregate the port group.
interface Enter port port-group manual z In Layer-2 aggregate interface
view group view port-group-name view, the subsequent
configurations apply to the Layer-2
aggregate interface and all its
member ports.
Optional
Configure the link type of the
port link-type access The link type of a port is access by
port or ports as access
default.
Optional
Assign the current access port access vlan
port(s) to a VLAN vlan-id By default, all access ports belong to
VLAN 1.
Before assigning an access port to a VLAN, create the VLAN first.
Assigning a Trunk Port to a VLAN
A trunk port can carry multiple VLANs. You can assign it to a VLAN in Ethernet port view, Layer-2
aggregate interface view, or port group view.
1-7
Follow these steps to assign a trunk port to one or multiple VLANs:

Enter Required
interface interface-type
Ethernet port Use either command.
interface-number
view
z In Ethernet port view, the
Enter Enter Layer-2 interface subsequent configurations apply to
Ethernet port aggregate bridge-aggregation the current port.
view/port interface view interface-number z In port group view, the subsequent
group
configurations apply to all ports in
view/Layer-2
the port group.
aggregate
interface view z In Layer-2 aggregate interface
Enter port port-group manual view, the subsequent
group view port-group-name configurations apply to the Layer-2
aggregate interface and all its
member ports.
port link-type trunk Required
port or ports as trunk
Required
Assign the trunk port(s) to the port trunk permit vlan
specified VLAN(s) { vlan-id-list | all } By default, a trunk port carries only
VLAN 1.
Configure the default VLAN of port trunk pvid vlan Optional

the trunk port(s) vlan-id VLAN 1 is the default VLAN by default.
z To change the link type of a port from trunk to hybrid or vice versa, you must set the link type to
access first.
z The local and remote hybrid ports must use the same default VLAN ID for the traffic of the default
VLAN to be transmitted properly.
z After configuring the default VLAN for a trunk port, you must use the port trunk permit vlan
command to configure the trunk port to allow packets from the default VLAN to pass through, so
that the egress port can forward packets from the default VLAN.
Assigning a Hybrid Port to a VLAN
A hybrid port can carry multiple VLANs. You can assign it to a VLAN in Ethernet port view, Layer-2
aggregate interface view, or port group view.
Follow these steps to assign a hybrid port to one or multiple VLANs:
1-8
Enter Enter Layer-2 interface z In Ethernet port view, the
Ethernet aggregate bridge-aggregation subsequent configurations apply
port interface view interface-number to the current port.
view/port
z In port group view, the
group
subsequent configurations apply
view/Layer-
to all ports in the port group.
2 aggregate
interface Enter port port-group manual z In Layer-2 aggregate interface
view group view port-group-name view, the subsequent
configurations apply to the
Layer-2 aggregate interface and
all its member ports.
port link-type hybrid Required
port(s) as hybrid
Required
Assign the hybrid port(s) to port hybrid vlan vlan-id-list By default, a hybrid port allows only
the specified VLAN(s) { tagged | untagged } packets of VLAN 1 to pass through
untagged.
Configure the default VLAN of port hybrid pvid vlan Optional

the hybrid port vlan-id VLAN 1 is the default by default.
z To change the link type of a port from trunk to hybrid or vice versa, you must set the link type to
access first.
z Before assigning a hybrid port to a VLAN, create the VLAN first.
z The local and remote hybrid ports must use the same default VLAN ID for the traffic of the default
VLAN to be transmitted properly.
z After configuring the default VLAN for a hybrid port, you must use the port hybrid vlan command
to configure the hybrid port to allow packets from the default VLAN to pass through, so that the
egress port can forward packets from the default VLAN.
MAC-Based VLAN Configuration

Introduction to MAC-Based VLAN
MAC-based VLANs group VLAN members by MAC address. They only apply to untagged frames.
When receiving an untagged frame, the device looks up the list of MAC-to-VLAN mappings based on
the MAC address of the frame for a match. If a match is found, the system forwards the frame in the
corresponding VLAN. If no match is found, the system looks up other types of VLANs to make the
forwarding decision.
MAC-based VLANs are mostly used in conjunction with security technologies such as 802.1X to
provide secure, flexible network access for terminal devices.
1-9
Approaches to Creating MAC Address-to-VLAN Mappings
In addition to creating MAC address-to-VLAN mappings at the CLI, you can use an authentication
server to automatically issue MAC address-to-VLAN mappings.
z Manually Static configuration (through CLI)
You can associate MAC addresses with VLANs by using corresponding commands.
z Automatic configuration through the authentication server (that is, VLAN issuing)
The device associates MAC addresses with VLANs dynamically based on the information provided by
the authentication server. If a user goes offline, the corresponding MAC address-to-VLAN association is
removed automatically. Automatic configuration requires MAC address-to–VLAN mapping be
configured on the authentication server. For detailed information, refer to 802.1X Configuration in the
Security Volume.
The two configuration approaches can be used at the same time, that is, you can configure a MAC
address-to-VLAN entry on both the local device and the authentication server at the same time. Note
that the MAC address-to-VLAN entry configuration takes effect only when the configuration on the local
device is consistent with that on the authentication server. Otherwise, the previous configuration takes
effect.
Configuring a MAC Address-Based VLAN
MAC-based VLANs are available only on hybrid ports.
Follow these steps to configure a MAC-based VLAN:
To do... Use the command... Remarks

mac-vlan mac-address
Associate MAC addresses
mac-address [ mask mac-mask ] Required
with a VLAN
vlan vlan-id [ priority priority ]
Enter Use either command.
Enter Ethernet port In Ethernet port view, the
interface-number
Ethernet view subsequent configurations
port view apply only to the current port;
or port in port group view, the
group Enter port port-group manual subsequent configurations
view group view port-group-name apply to all ports in the port
group.
Configure the link type of
the port(s) as hybrid
Configure the current Required
hybrid port(s) to permit
port hybrid vlan vlan-id-list By default, a hybrid port only
packets of specific
{ tagged | untagged } permits the packets of VLAN 1
MAC-based VLANs to pass
through to pass through.
1-10
Required
Enable MAC-based VLAN mac-vlan enable
Disabled by default
Optional
Configure VLAN matching vlan precedence { mac-vlan | By default, VLANs are
precedence ip-subnet-vlan } preferentially matched based
on MAC addresses.
When the source MAC address of an untagged packet matches an MAC-VLAN entry and an OUI
address used in voice VLAN at the same time, the packet will be assigned to the MAC-based VLAN. As
a result, the packet will not be able to enter the voice VLAN. Therefore, we recommend you not to
configure the OUI addresses of voice packets in MAC-VLAN entries.
Protocol-Based VLAN Configuration

Introduction to Protocol-Based VLAN
Protocol-based VLANs are only applicable on hybrid ports.
In this approach, inbound packets are assigned to different VLANs based on their protocol types and
encapsulation formats. The protocols that can be used for VLAN assignment include IP, IPX, and
AppleTalk (AT). The encapsulation formats include Ethernet II, 802.3 raw, 802.2 LLC, and 802.2 SNAP.
A protocol-based VLAN is defined by a protocol template comprised of encapsulation format and
protocol type. A port can be associated with multiple protocol templates. An untagged packet reaching a
port associated with protocol-based VLANs will be processed as follows.
z If the packet matches a protocol template, the packet will be tagged with the VLAN tag
corresponding to the protocol template.
z If the packet matches no protocol template, the packet will be tagged with the default VLAN ID of
the port.
The port processes a tagged packet as it processes tagged packets of a port-based VLAN.
z If the port permits the VLAN ID of the packet to pass through, the port forwards the packet.
z If the port does not permit the VLAN ID of the packet to pass through, the port drops the packet.
This feature is mainly used to assign packets of the specific service type to a specific VLAN.
Configuring a Protocol-Based VLAN
Follow these steps to configure a protocol-based VLAN:
1-11
Required
Enter VLAN view vlan vlan-id If the specified VLAN does
not exist, this command
creates the VLAN first.
protocol-vlan
[ protocol-index ] { at | ipv4 |
ipv6 | ipx { ethernetii | llc |
Create a protocol template for the raw | snap } | mode
Required
VLAN { ethernetii etype etype-id |
llc { dsap dsap-id [ ssap
ssap-id ] | ssap ssap-id } |
snap etype etype-id } }
Exit VLAN view quit —
Enter Layer-2 interface z In Ethernet port view, the
aggregate bridge-aggregation subsequent configurations
Enter Ethernet interface view interface-number apply to the current port.
port view,
Layer-2
subsequent configurations
aggregate
apply to all ports in the port
interface view,
group.
or port group
view Enter port port-group manual z In Layer-2 aggregate
group view port-group-name interface view, the
apply to the Layer-2
aggregate interface and all
its member ports.
Configure the port link type as
hybrid
Configure current hybrid port(s) to Required

permit the packets of the specified port hybrid vlan vlan-id-list By default, all hybrid ports
protocol-based VLANs to pass { tagged | untagged } permit packets of VLAN 1 to
through pass through only.
Associate the hybrid port(s) with port hybrid protocol-vlan
the specified protocol-based vlan vlan-id { protocol-index Required
VLAN [ to protocol-end ] | all }
1-12
z Currently, H3C S7500E series Ethernet switches do not support associating an AppleTalk protocol
template with ports.
z Do not configure both the dsap-id and ssap-id arguments in the protocol-vlan command as 0xe0
or 0xff when configuring the user-defined template for llc encapsulation. Otherwise, the
encapsulation format of the matching packets will be the same as that of the ipx llc or ipx raw
packets respectively.
z When you use the mode keyword to configure a user-defined protocol template, do not set etype-id
in ethernetii etype etype-id to 0x0800, 0x8137, 0x809b, or 0x86dd. Otherwise, the encapsulation
format of the matching packets will be the same as that of the IPv4, IPX, AppleTalk, and IPv6
packets respectively.
z A protocol-based VLAN on a hybrid port can process only untagged inbound packets, whereas the
voice VLAN in automatic mode on a hybrid port can process only tagged voice traffic. Therefore, do
not configure a VLAN as both a protocol-based VLAN and a voice VLAN. For more information,
refer to Voice VLAN Configuration.
IP Subnet-Based VLAN Configuration

Introduction
In this approach, packets are assigned to VLANs based on their source IP addresses and subnet masks.
A port configured with IP subnet-based VLANs assigns a received untagged packet to a VLAN based on
the source address of the packet.
This feature is used to assign packets from the specified network segment or IP address to a specific
VLAN.
Configuring an IP Subnet-Based VLAN
This feature is only applicable on hybrid ports.
Follow these steps to configure an IP subnet-based VLAN:

Enter VLAN view vlan vlan-id —
1-13
Required
ip-subnet-vlan The IP network segment or IP
Associate an IP subnet with the address to be associated with
[ ip-subnet-index ] ip
current VLAN a VLAN cannot be a multicast
ip-address [ mask ]
network segment or a
multicast address.
Return to system view quit —
Enter Layer-2 interface z In Ethernet port view, the
aggregate bridge-aggregation subsequent configurations
Enter Ethernet interface view interface-number apply to the current port.
port view,
Layer-2
aggregate
apply to all ports in the port
interface view,
group.
or port group
view Enter port group port-group manual z In Layer-2 aggregate
view port-group-name interface view, the
apply to the Layer-2
aggregate interface and all
its member ports.
Configure port link type as hybrid port link-type hybrid Required
Configure the hybrid port(s) to
permit the specified IP port hybrid vlan vlan-id-list
Required
subnet-based VLANs to pass { tagged | untagged }
through
Associate the hybrid port(s) with
port hybrid ip-subnet-vlan
the specified IP subnet-based Required
vlan vlan-id
VLAN
Displaying and Maintaining VLAN

To do... Use the command… Remarks
display vlan [ vlan-id1 [ to vlan-id2 ] |
Display VLAN information Available in any view
all | dynamic | reserved | static ]
Display VLAN interface display interface vlan-interface
Available in any view
information [ vlan-interface-id ]
Display hybrid ports or trunk
display port { hybrid | trunk } Available in any view
ports on the device
display mac-vlan { all | dynamic |
Display MAC address-to-VLAN
mac-address mac-address [ mask Available in any view
entries
mac-mask ] | static | vlan vlan-id }
Display all interfaces with
display mac-vlan interface Available in any view
MAC-based VLAN enabled
Display protocol information
display protocol-vlan vlan { vlan-id
and protocol indexes of the Available in any view
[ to vlan-id ] | all }
specified VLANs
1-14
To do... Use the command… Remarks
Display protocol-based VLAN display protocol-vlan interface
information on specified { interface-type interface-number [ to Available in any view
interfaces interface-type interface-number ] | all }
Display IP subnet-based VLAN
display ip-subnet-vlan vlan { vlan-id
information and IP subnet Available in any view
[ to vlan-id ] | all }
indexes of specified VLANs
Display the IP subnet-based display ip-subnet-vlan interface
VLAN information and IP { interface-type interface-number1 [ to
subnet indexes of specified interface-type interface-number2 ] |
ports all }
Clear statistics on a VLAN reset counters interface
Available in user view
interface vlan-interface [ vlan-interface-id ]
VLAN Configuration Example

Network requirements
z Device A connects to Device B through a trunk port GigabitEthernet 2/0/1;

z The default VLAN ID of GigabitEthernet 2/0/1 is 100;
z GigabitEthernet 2/0/1 allows packets from VLAN 2, VLAN 6 through VLAN 50, and VLAN 100 to
pass through.
Network diagram
Figure 1-4 Network diagram for port-based VLAN configuration
Configuration procedure
1) Configure Device A
# Create VLAN 2, VLAN 6 through VLAN 50, and VLAN 100.
<DeviceA> system-view
[DeviceA] vlan 2
[DeviceA-vlan2] quit
[DeviceA] vlan 100
[DeviceA-vlan100] vlan 6 to 50
Please wait... Done.
# Enter GigabitEthernet 2/0/1 interface view.

[DeviceA] interface gigabitethernet 2/0/1
# Configure GigabitEthernet 2/0/1 as a trunk port and configure its default VLAN ID as 100.
[DeviceA-GigabitEthernet2/0/1] port link-type trunk
[DeviceA-GigabitEthernet2/0/1] port trunk pvid vlan 100
# Configure GigabitEthernet 2/0/1 to deny the packets of VLAN 1 (by default, the packets of VLAN 1 are
permitted to pass through on all the ports).
1-15
[DeviceA-GigabitEthernet2/0/1] undo port trunk permit vlan 1
# Configure GigabitEthernet 2/0/1 to permit packets from VLAN 2, VLAN 6 through VLAN 50, and VLAN
100 to pass through.
[DeviceA-GigabitEthernet2/0/1] port trunk permit vlan 2 6 to 50 100
Please wait... Done.
[DeviceA-GigabitEthernet2/0/1] quit
[DeviceA] quit
2) Configure Device B as you configure Device A.
Verification
Verifying the configuration on Device A is similar to that of Device B. So only Device A is taken for
example here.
# Display the information about GigabitEthernet 2/0/1 of Device A to verify the above configurations.
<DeviceA> display interface gigabitethernet 2/0/1
GigabitEthernet2/0/1 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 00e0-fc00-6504
Description: GigabitEthernet2/0/1 Interface
Loopback is not set
Media type is twisted pair
Port hardware type is 1000_BASE_T
Unknown-speed mode, unknown-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 1536
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
Allow jumbo frame to pass
PVID: 100
Mdi type: auto
Link delay is 0(sec)
Port link-type: trunk
VLAN passing : 2, 6-50, 100
VLAN permitted: 2, 6-50, 100
Trunk port encapsulation: IEEE 802.1q
Port priority: 0
Last 300 seconds input: 0 packets/sec 0 bytes/sec -%
Last 300 seconds output: 0 packets/sec 0 bytes/sec -%
Input (total): 0 packets, 0 bytes
0 broadcasts, 0 multicasts
Input (normal): 0 packets, - bytes
0 broadcasts, 0 multicasts
Input: 0 input errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 frame, - overruns, 0 aborts
- ignored, - parity errors
Output (total): 0 packets, 0 bytes
0 broadcasts, 0 multicasts, 0 pauses
1-16
Output (normal): 0 packets, - bytes
0 broadcasts, 0 multicasts, 0 pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, - no carrier
The output above shows that:

z The port (GigabitEthernet 2/0/1) is a trunk port.
z The default VLAN of the port is VLAN 100.
z The port permits packets of VLAN 2, VLAN 6 through VLAN 50, and VLAN 100 to pass through.
Therefore, the configuration is successful.
1-17
2 Super VLAN Configuration
When configuring super VLAN, go to these sections for information you are interested in:
z Overview
z Configuring a Super VLAN
z Displaying and Maintaining Super VLAN
z Super VLAN Configuration Example
Overview
Super VLAN, also called VLAN aggregation, was introduced to save the IP address space.
A super VLAN is associated with multiple sub-VLANs. You can create a VLAN interface for a super
VLAN and assign an IP address for the VLAN interface. However, you cannot create a VLAN interface
for a sub-VLAN. You cannot assign a physical port to a super VLAN, however, you can assign a physical
port to a sub-VLAN. All ports of a sub-VLAN use the VLAN interface IP address of the associated super
VLAN. Packets cannot be forwarded between sub-VLANs at Layer 2.
To enable Layer 3 communication between sub-VLANs, you should configure the VLAN interface IP
address of the associated super VLAN as the gateway IP address. This enables multiple sub-VLANs to
share the same gateway address and thus saves IP address resources.
After creating a super VLAN and the VLAN interface, enable local proxy Address Resolution Protocol
(ARP) on the device. The super VLAN can use local proxy ARP to forward and process ARP requests
and responses and thus achieve Layer 3 communication between sub-VLANs and between sub-VLANs
and other networks.
Configuring a Super VLAN

Follow these steps to configure a super VLAN:

Required
Enter VLAN view vlan vlan-id If the specified VLAN does not
exist, this command creates the
VLAN first.
Configure the VLAN as a super
supervlan Required
VLAN
Associate the super VLAN with
subvlan vlan-list Required
the specified sub-VLAN(s)
Exit the VLAN view quit —
Required
interface vlan-interface If the specified VLAN interface
Enter VLAN interface view
vlan-interface-id does not exist, this command
creates the VLAN interface first.
2-1
Required
Configure the IP address of the ip address ip-address
VLAN interface { mask | mask-length } [ sub ] By default, the IP address of a
VLAN interface is not configured.
Required
Enable local proxy ARP local-proxy-arp enable
Disabled by default
z The VLAN interface IP address in the above table is the IP address of the associated super VLAN.
z For more information about the local-proxy-arp enable command and the local proxy ARP
function, refer to ARP Commands and ARP Configuration in the IP Services Volume.
z You cannot configure a super VLAN as the guest VLAN for a port, and vice versa. For more
information about guest VLAN, refer to 802.1X Configuration in the Security Volume.
z You can configure Layer 2 multicast for a super VLAN. However, the configuration cannot take
effect.
z You can configure DHCP, Layer 3 multicast and dynamic routing for the VLAN interface of a super
VLAN. However, only DHCP can take effect.
z Configuring VRRP for the VLAN interface of a super VLAN affects network performance. Therefore,
it is not recommended to configure this function.
Displaying and Maintaining Super VLAN

Display the mapping between a super display supervlan
VLAN and its sub-VLAN(s) [ supervlan-id ]
Super VLAN Configuration Example

z Create super VLAN 10, and configure its VLAN interface IP address as 10.0.0.1/24.
z Create the sub-VLANs VLAN 2, VLAN 3, and VLAN 5.
z Assign GigabitEthernet 2/0/1 and GigabitEthernet 2/0/2 to VLAN 2, GigabitEthernet 2/0/3 and
GigabitEthernet 2/0/4 to VLAN 3, and GigabitEthernet 2/0/5 and GigabitEthernet 2/0/6 to VLAN 5.
z The sub-VLANs are isolated at Layer 2 but connected at Layer 3.
2-2
Network diagram
Figure 2-1 Network diagram for super-VLAN configuration
# Create VLAN 10, and configure its VLAN interface IP address as 10.0.0.1/24.
<Sysname> system-view
[Sysname] vlan 10
[Sysname-vlan10] interface vlan-interface 10
[Sysname-Vlan-interface10] ip address 10.0.0.1 255.255.255.0
# Enable local proxy ARP.

[Sysname-Vlan-interface10] local-proxy-arp enable
[Sysname-Vlan-interface10] quit
# Create VLAN 2, and assign GigabitEthernet 2/0/1 and GigabitEthernet 2/0/2 to it.
[Sysname] vlan 2
[Sysname-vlan2] port GigabitEthernet 2/0/1 GigabitEthernet 2/0/2
[Sysname-vlan2] quit
[Sysname] vlan 3
[Sysname] vlan 5
# Configure VLAN 10 as the super VLAN, and configure VLAN 2, VLAN 3, and VLAN 5 as its
sub-VLANs.
[Sysname] vlan 10
[Sysname-vlan10] supervlan
[Sysname-vlan10] subvlan 2 3 5
[Sysname] quit
Verification
# Display information about VLAN 10 to verify the above configuration.
2-3
<Sysname> display supervlan
SuperVLAN ID : 10
SubVLAN ID : 2-3 5
VLAN ID: 10
VLAN Type: static
It is a Super VLAN.
Route Interface: configured
IP Address: 10.0.0.1
Subnet Mask: 255.255.255.0
Description: VLAN 0010
Tagged Ports: none
Untagged Ports: none
VLAN ID: 2
VLAN Type: static
It is a Sub VLAN.
Subnet Mask: 255.255.255.0
Tagged Ports: none
Untagged Ports:
GigabitEthernet2/0/1 GigabitEthernet2/0/2
VLAN ID: 3
VLAN Type: static
It is a Sub VLAN.
Subnet Mask: 255.255.255.0
Tagged Ports: none
Untagged Ports:
VLAN ID: 5
VLAN Type: static
It is a Sub VLAN.
Subnet Mask: 255.255.255.0
Tagged Ports: none
Untagged Ports:
2-4
3 Isolate-User-VLAN Configuration
When configuring an isolate-user VLAN, go to these sections for information you are interested in:
z Overview
z Configuring Isolate-User-VLAN
z Displaying and Maintaining Isolate-User-VLAN
z Isolate-User-VLAN Configuration Example
Overview
An isolate-user-VLAN adopts a two-tier VLAN structure. In this approach, two types of VLANs,
isolate-user-VLAN and secondary VLAN, are configured on the same device.
The following are the characteristics of the isolate-user-VLAN implementation:
z Isolate-user-VLANs are mainly used for upstream data exchange. An isolate-user-VLAN can be
associated with multiple secondary VLANs. As the upstream device is aware of only the
isolate-user-VLAN but not the secondary VLANs, network configuration is simplified and VLAN
resources are saved.
z You can isolate the Layer 2 traffic of different users by assigning the ports connected to them to
different secondary VLANs. To enable communication between secondary VLANs associated with
the same isolate-user-VLAN, you can enable local proxy ARP on the upstream device to realize
Layer 3 communication between the secondary VLANs.
As illustrated in the following figure, the isolate-user-VLAN function is enabled on Switch B. VLAN 10 is
the isolate-user-VLAN, and VLAN 2, VLAN 5, and VLAN 8 are secondary VLANs associated with VLAN
10 and are invisible to Switch A.
Figure 3-1 An isolate-user-VLAN example
Configuring Isolate-User-VLAN
Configure the isolate-user-VLAN through the following steps:
1) Configure the isolate-user-VLAN;
2) Configure the secondary VLANs;
3-1
3) Assign non-trunk ports to the isolate-user-VLAN and ensure that at least one port takes the
isolate-user-VLAN as its default VLAN;
4) Assign non-trunk ports to each secondary VLAN and ensure that at least one port in a secondary
VLAN takes the secondary VLAN as its default VLAN;
5) Associate the isolate-user-VLAN with the specified secondary VLANs.
Follow these steps to configure an isolate-user-VLAN:
To do... Use the command Remarks

Create a VLAN and enter VLAN view vlan vlan-id —
Configure the VLAN as an
isolate-user-vlan enable Required
isolate-user-VLAN
Assign ports to the Refer to Assigning an Access Port
Access port
isolate-user-VLAN and to a VLAN
ensure that at least one
Use either approach.
port takes the Refer to Assigning a Hybrid Port
isolate-user-VLAN as its Hybrid port
to a VLAN
default VLAN
Create secondary VLANs vlan { vlan-id1 [ to vlan-id2 ] | all } Required
Quit to system view quit —
Assign ports to each
secondary VLAN and Refer to Assigning an Access Port
Access port
ensure that at least one to a VLAN
Required to choose
port in a secondary
either
VLAN takes the
secondary VLAN as its Refer to Assigning a Hybrid Port
Hybrid port
default VLAN to a VLAN

isolate-user-vlan
Associate the isolate-user-VLAN with
isolate-user-vlan-id secondary Required
the specified secondary VLANs
secondary-vlan-list
After associating an isolate-user-VLAN with the specified secondary VLANs, you cannot add/remove a
port to/from each involved VLAN or remove each involved VLAN. To do that, you must cancel the
association first.
3-2
Displaying and Maintaining Isolate-User-VLAN
Display the mapping between
display isolate-user-vlan
an isolate-user-VLAN and its Available in any view
[ isolate-user-vlan-id ]
secondary VLAN(s)
Isolate-User-VLAN Configuration Example

z Connect Device A to downstream devices Device B and Device C;

z Configure VLAN 5 on Device B as an isolate-user-VLAN, assign the uplink port GigabitEthernet
2/0/5 to VLAN 5, and associate VLAN 5 with secondary VLANs VLAN 2 and VLAN 3. Assign
GigabitEthernet 2/0/2 to VLAN 2 and GigabitEthernet 2/0/1 to VLAN 3.
z Configure VLAN 6 on Device C as an isolate-user-VLAN, assign the uplink port GigabitEthernet
2/0/5 to VLAN 6, and associate VLAN 6 with secondary VLANs VLAN 3 and VLAN 4. Assign
GigabitEthernet 2/0/3 to VLAN 3 and GigabitEthernet 2/0/4 to VLAN 4.
z For Device A, Device B only has VLAN 5 and Device C only has VLAN 6.
Network diagram
Figure 3-2 Network diagram for isolate-user-VLAN configuration
VLAN 5 VLAN 6
VLAN 3 VLAN 3
GE /3
2/0 2/0
Host A /1 GE Host C
GE2/0/5 GE2/0/5
GE
/2 2/0
2/0 /4
GE Device B Device A Device C
Host B Host D
VLAN 2 VLAN 4
The following part provides only the configuration on Device B and Device C.
1) Configure Device B
# Configure the isolate-user-VLAN.
<DeviceB> system-view
[DeviceB] vlan 5
[DeviceB-vlan5] isolate-user-vlan enable
[DeviceB-vlan5] port GigabitEthernet 2/0/5
[DeviceB-vlan5] quit
# Configure the secondary VLANs.

[DeviceB] vlan 3
3-3
[DeviceB] vlan 2
# Associate the isolate-user-VLAN with the secondary VLANs.

[DeviceB] isolate-user-vlan 5 secondary 2 to 3
2) Configure Device C
# Configure the isolate-user-VLAN.
<DeviceC> system-view
[DeviceC] vlan 6
[DeviceC-vlan6] isolate-user-vlan enable
[DeviceC-vlan6] port GigabitEthernet 2/0/5
[DeviceC-vlan6] quit
# Configure the secondary VLANs.

[DeviceC] vlan 3
[DeviceC] vlan 4
# Associate the isolate-user-VLAN with the secondary VLANs.

[DeviceC] isolate-user-vlan 6 secondary 3 to 4
Verification
# Display the isolate-user-VLAN configuration on Device B.

[DeviceB] display isolate-user-vlan
Isolate-user-VLAN VLAN ID : 5
Secondary VLAN ID : 2-3
VLAN ID: 5
VLAN Type: static
Isolate-user-VLAN type : isolate-user-VLAN
Route Interface: not configured
Tagged Ports: none
Untagged Ports:
GigabitEthernet2/0/1 GigabitEthernet2/0/2 GigabitEthernet2/0/5
VLAN ID: 2
VLAN Type: static
Isolate-user-VLAN type : secondary
Tagged Ports: none
Untagged Ports:
3-4
VLAN ID: 3
VLAN Type: static
Isolate-user-VLAN type : secondary
Tagged Ports: none
Untagged Ports:
3-5
4 Voice VLAN Configuration
When configuring a voice VLAN, go to these sections for information you are interested in:
z Overview
z Configuring a Voice VLAN
z Displaying and Maintaining Voice VLAN
z Voice VLAN Configuration
Overview
A voice VLAN is configured specially for voice traffic. After assigning the ports connecting to voice
devices to a voice VLAN, you can configure quality of service (QoS) parameters for the voice traffic,
thus improving transmission priority and ensuring voice quality.
A device determines whether a received packet is a voice packet by checking its source MAC address.
A packet whose source MAC address complies with the voice device Organizationally Unique Identifier
(OUI) address is regarded as voice traffic and assigned to the voice VLAN.
You can configure the OUI addresses in advance or use the default OUI addresses. Table 4-1 lists the
default OUI address for each vendor’s devices.
Table 4-1 The default OUI addresses of different vendors
Number OUI address Vendor

1 0001-e300-0000 Siemens phone
2 0003-6b00-0000 Cisco phone

3 0004-0d00-0000 Avaya phone
4 0060-b900-0000 Philips/NEC phone
5 00d0-1e00-0000 Pingtel phone
6 00e0-7500-0000 Polycom phone
7 00e0-bb00-0000 3Com phone
z In general, as the first 24 bits of a MAC address (in binary format), an OUI address is a globally
unique identifier assigned to a vendor by IEEE. OUI addresses mentioned in this document,
however, are different from those in common sense. OUI addresses in this document are used by
the system to determine whether a received packet is a voice packet. They are the results of the
AND operation of the two arguments mac-address and oui-mask in the voice vlan mac-address
command.
z You can remove the default OUI address of a device manually and then add new ones manually.
4-1
Voice VLAN Assignment Modes
A port can be assigned to a voice VLAN in one of the following two modes:
z In automatic mode, the system matches the source MAC addresses in the untagged protocol
packets sent when the IP phone is powered on against the OUI addresses. If a match is found, the
system automatically assigns the port to the voice VLAN, issues ACL rules and configures the
packet precedence. You can configure voice VLAN aging time on the device. The system will
remove a port from the voice VLAN if no voice packet is received from the port after the aging time
expires. Assigning/removing ports to/from a voice VLAN are automatically performed by the
system.
z In manual mode, you should assign an IP phone access port to a voice VLAN manually. Then, the
system matches the source MAC addresses in the packets against the OUI addresses. If a match
is found, the system issues ACL rules and configures the packet precedence. In this mode,
assigning/removing ports to/from a voice VLAN are performed manually.
z Both modes forward tagged packets according to their tags.
The following table lists the co-relation between the port voice VLAN mode, the voice traffic type of an IP
phone, and the port link type.
Table 4-2 Co-relation
Voice VLAN
Voice traffic type Port link type
assignment mode
Access: not supported
Trunk: supported if the default VLAN of the access
port exists and is not the voice VLAN and the access
port belongs to the voice VLAN
Tagged voice traffic
Automatic mode Hybrid: supported if the default VLAN of the access
port exists and is not the voice VLAN and the traffic of
the default VLAN is permitted to pass through the
access port tagged
Untagged voice traffic Access, Trunk, hybrid: not supported
Access: not supported

port exists and is not the voice VLAN and the access
port belongs to the default VLAN
Tagged voice traffic
Hybrid: supported if the default VLAN of the access
port exists and is not the voice VLAN, and the traffic of
the default VLAN is permitted to pass through the
access port tagged
Manual mode
Access: supported if the default VLAN of the access
port is the voice VLAN
Untagged voice port is the voice VLAN and that the voice VLAN is
traffic permitted to pass through the access port
Hybrid port: supported if the default VLAN of the
access port is the voice VLAN and is permitted to
pass through the access port untagged
4-2
If an IP phone sends tagged voice traffic and its access port is configured with 802.1X authentication
and guest VLAN, you should assign different VLAN IDs for the voice VLAN, the default VLAN of the
access port, and the 802.1X guest VLAN.
z The default VLANs for all ports are VLAN 1. You can configure the default VLAN of a port and
configure a port to permit a certain VLAN to pass through with commands. For more information,
refer to Port-Based VLAN Configuration.
z Use the display interface command to display the default VLAN of a port and the VLANs
permitted to pass through the port.
Security Mode and Normal Mode of Voice VLANs
Voice VLAN-enabled ports can operate in security mode or normal mode based on their inbound packet
filtering mechanisms.
z Security mode: only voice packets whose source MAC addresses comply with the recognizable
OUI addresses can pass through the voice VLAN-enabled inbound port, while other non-voice
packets are dropped, including authentication packets, such as 802.1X authentication packets.
z Normal mode: both voice packets and non-voice packets are allowed to pass through a voice
VLAN-enabled inbound port. Voice packets are forwarded according to the voice VLAN forwarding
mechanism whereas the non-voice packets are forwarded according to the normal VLAN
forwarding mechanism.
It is recommended not to transmit both voice packets and non-voice packets in a voice VLAN. If
necessary, please ensure that the voice VLAN security mode is disabled.
Configuring a Voice VLAN

Configuration Prerequisites
Before configuring a VLAN as a voice VLAN, create the VLAN first. Note that you cannot configure
VLAN 1 (the system-default VLAN) as a voice VLAN.
4-3
Setting a Port to Operate in Automatic Voice VLAN Assignment Mode
Follow these steps to set a port to operate in automatic voice VLAN assignment mode:

Optional
1440 minutes by default.
Set the voice VLAN aging time voice vlan aging minutes The voice VLAN aging time
configuration is only applicable
on ports in automatic voice
VLAN assignment mode.
Enable the voice VLAN security Optional

voice vlan security enable
mode Enabled by default.
Optional
voice vlan mac-address oui By default, each voice VLAN
Add a recognizable OUI has default OUI addresses
mask oui-mask [ description
address configured. Refer to Table 4-1
text ]
for the default OUI addresses
of different vendors.
Enable voice VLAN globally voice vlan vlan-id enable Required
Enter Ethernet port view —
interface-number
Optional
Automatic voice VLAN
Configure the port to operate in assignment mode is enabled by
automatic voice VLAN voice vlan mode auto default.
assignment mode The voice VLAN assignment
modes on different ports are
independent of one another.
Required
Enable voice VLAN on the port voice vlan enable
Not enabled by default
z A protocol-based VLAN on a hybrid port can process only untagged inbound packets, whereas the
voice VLAN in automatic mode on a hybrid port can process only tagged voice traffic. Therefore, do
not configure a VLAN as both a protocol-based VLAN and a voice VLAN. For more information,
refer to Port-Based VLAN Configuration.
z Do not configure the default VLAN of a port in automatic voice VLAN assignment mode as the
voice VLAN.
z You need to configure the voice vlan security enable command or the undo voice vlan
security enable command before enabling voice VLAN on a device globally. Otherwise, the
configurations will not take effect.
4-4
Setting a Port to Operate in Manual Voice VLAN Assignment Mode
Follow these steps to set a port to operate in manual voice VLAN assignment mode:

Enable the voice VLAN security Optional

voice vlan security enable
mode Enabled by default.
Optional
voice vlan mac-address oui By default, each voice VLAN
Add a recognizable OUI has default OUI addresses
mask oui-mask [ description
address configured. Refer to Table 4-1
text ]
for the default OUI addresses
of different vendors.
Enable voice VLAN globally voice vlan vlan-id enable Required
interface-number
Configure the port to operate in Required
manual voice VLAN undo voice vlan mode auto
assignment mode Disabled by default
Refer to Assigning an Access

Assign the Access port Use one of the three
Port to a VLAN.
port in manual approaches.
voice VLAN Refer to Assigning a Trunk Port After you assign an access port
Trunk port
assignment to a VLAN. to the voice VLAN, the voice
mode to the VLAN becomes the default
voice VLAN Refer to Assigning a Hybrid VLAN of the port automatically.
Hybrid port
Port to a VLAN.
Configure the Refer to section Assigning a Optional

voice VLAN Trunk port
Trunk Port to a VLAN. This operation is required for
as the default untagged inbound voice traffic
VLAN of the Refer to Assigning a Hybrid and prohibited for tagged
port Hybrid port
Port to a VLAN. inbound voice traffic.
Enable voice VLAN on the port voice vlan enable Required
4-5
z There can be only one voice VLAN on a device at a time and this voice VLAN must be a static
VLAN that already exists on the device.
z Voice VLAN is mutually exclusive with Link Aggregation Control Protocol (LACP) on a port.
z You need to configure the voice vlan security enable command or the undo voice vlan
security enable command before enabling voice VLAN on a device globally. Otherwise, the
configurations will not take effect.
z To make voice VLAN take effect on a port that is enabled with voice VLAN and operates in manual
voice VLAN assignment mode, you need to assign the port to the voice VLAN manually.
z When the source MAC address of an untagged packet matches an MAC-VLAN entry and an OUI
address used in voice VLAN at the same time, the packet will be assigned to the MAC-based VLAN.
As a result, the packet will not be able to enter the voice VLAN. Therefore, we recommend you not
to configure the OUI addresses of voice packets in MAC-VLAN entries.
Displaying and Maintaining Voice VLAN

Display the voice VLAN state display voice vlan state Available in any view
Display the OUI addresses
display voice vlan oui Available in any view
currently supported by system
Voice VLAN Configuration Examples

Automatic Voice VLAN Mode Configuration Example
Network requirement
z Create VLAN 2 and configure it as a voice VLAN with an aging time of 100 minutes.
z The IP phones send tagged voice traffic. Configure GigabitEthernet 2/0/1 as a hybrid port and
configure VLAN 6 as its default VLAN.
z The device allows voice packets with an OUI address of 0011-2200-0000 and a mask of
ffff-ff00-0000 to be forwarded through the voice VLAN.
4-6
Network diagram
Figure 4-1 Network diagram for automatic voice VLAN mode configuration
# Create VLAN 2 and VLAN 6.

[DeviceA] vlan 2
[DeviceA] vlan 6
# Configure the voice VLAN aging time.

[DeviceA] voice vlan aging 100
# Add a recognizable OUI address 0011-2200-0000.

[DeviceA] voice vlan mac-address 0011-2200-0000 mask ffff-ff00-0000
# Enable voice VLAN globally.

[DeviceA] voice vlan 2 enable
# Configure GigabitEthernet 2/0/1 to operate in automatic voice VLAN mode. (Optional, by default, a
port operates in automatic voice VLAN mode.)
[DeviceA-GigabitEthernet2/0/1] voice vlan mode auto
# Configure GigabitEthernet 2/0/1 as a hybrid port.

[DeviceA-GigabitEthernet2/0/1] port link-type hybrid
# Configure VLAN 6 as the default VLAN of GigabitEthernet 2/0/1 and configure GigabitEthernet 2/0/1
to allow packets from VLAN 6 to pass through tagged.
[DeviceA-GigabitEthernet2/0/1] port hybrid pvid vlan 6
[DeviceA-GigabitEthernet2/0/1] port hybrid vlan 6 tagged
# Enable voice VLAN on GigabitEthernet 2/0/1.

[DeviceA-GigabitEthernet2/0/1] voice vlan enable
[DeviceA-GigabitEthernet2/0/1] return
Verification
# Display the OUI addresses, OUI address masks, and description strings supported currently.
<DeviceA> display voice vlan oui
4-7
Oui Address Mask Description
0001-e300-0000 ffff-ff00-0000 Siemens phone
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
0011-2200-0000 ffff-ff00-0000
0060-b900-0000 ffff-ff00-0000 Philips/NEC phone
00d0-1e00-0000 ffff-ff00-0000 Pingtel phone
00e0-7500-0000 ffff-ff00-0000 Polycom phone
00e0-bb00-0000 ffff-ff00-0000 3com phone
# Display the current voice VLAN state.

<DeviceA> display voice vlan state
Voice VLAN status: ENABLE
Voice VLAN ID: 2
Voice VLAN security mode: Security
Voice VLAN aging time: 100 minutes
Voice VLAN enabled port and its mode:
PORT MODE
--------------------------------
GigabitEthernet2/0/1 AUTO
<DeviceA>
Manual Voice VLAN Mode Configuration Example
Network requirement
z Create VLAN 2 and configure it as a voice VLAN permitting only voice traffic to pass through.
z The IP phones send untagged voice traffic. Configure GigabitEthernet 2/0/1 as a hybrid port.
z Configure GigabitEthernet 2/0/1 to operate in manual voice VLAN mode. Configure
GigabitEthernet 2/0/1 to allow only voice traffic with an OUI address of 0011-2200-0000, a mask of
ffff-ff00-0000, and a description string test to be forwarded through the voice VLAN.
Network diagram
Figure 4-2 Network diagram for manual voice VLAN mode configuration
# Configure the voice VLAN to operate in security mode. (Optional, a voice VLAN operates in security
mode by default.)
4-8
[DeviceA] voice vlan security enable
# Add a recognizable OUI address 0011-2200-0000.

[DeviceA] voice vlan mac-address 0011-2200-0000 mask ffff-ff00-0000 description test
# Create VLAN 2 and configure it as the voice VLAN.

[DeviceA] vlan 2
[DeviceA] voice vlan 2 enable
# Configure GigabitEthernet 2/0/1 to operate in manual voice VLAN mode.

[DeviceA-GigabitEthernet2/0/1] undo voice vlan mode auto
# Configure GigabitEthernet 2/0/1 as a hybrid port.

[DeviceA-GigabitEthernet2/0/1]port link-type hybrid
# Configure the voice VLAN (VLAN 2) as the default VLAN of GigabitEthernet 2/0/1 and configure
GigabitEthernet 2/0/1 to permit the voice traffic of VLAN 2 to pass through untagged.
[DeviceA-GigabitEthernet2/0/1] port hybrid pvid vlan 2
[DeviceA-GigabitEthernet2/0/1] port hybrid vlan 2 untagged
# Enable voice VLAN on GigabitEthernet 2/0/1.

[DeviceA-GigabitEthernet2/0/1] voice vlan enable
Verification
# Display the OUI addresses, OUI address masks, and description strings supported currently.
<DeviceA> display voice vlan oui
Oui Address Mask Description
0001-e300-0000 ffff-ff00-0000 Siemens phone
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
0011-2200-0000 ffff-ff00-0000 test
0060-b900-0000 ffff-ff00-0000 Philips/NEC phone
00d0-1e00-0000 ffff-ff00-0000 Pingtel phone
00e0-7500-0000 ffff-ff00-0000 Polycom phone
00e0-bb00-0000 ffff-ff00-0000 3com phone
# Display the current voice VLAN state.

<DeviceA> display voice vlan state
Voice VLAN status: ENABLE
Voice VLAN ID: 2
Voice VLAN security mode: Security
Voice VLAN aging time: 100 minutes
Voice VLAN enabled port and its mode:
PORT MODE
--------------------------------
GigabitEthernet2/0/1 MANUAL
4-9
Table of Contents
1 MSTP Configuration ··································································································································1-1

MSTP Overview ······································································································································1-1
Introduction to STP··························································································································1-1
How STP works ·······························································································································1-3
Introduction to MSTP·······················································································································1-9
Protocols and Standards ···············································································································1-14
Configuration Task List ·························································································································1-14
Configuring the Root Bridge··················································································································1-16
Configuring an MST Region ··········································································································1-16
Specifying the Root Bridge or a Secondary Root Bridge ······························································1-17
Configuring the Work Mode of an MSTP Device ··········································································1-18
Configuring the Priority of the Current Device···············································································1-19
Configuring the Maximum Hops of an MST Region······································································1-20
Configuring the Network Diameter of a Switched Network ···························································1-20
Configuring Timers of MSTP ·········································································································1-21
Configuring the Timeout Factor·····································································································1-22
Configuring the Maximum Port Rate ·····························································································1-23
Configuring Ports as Edge Ports ···································································································1-24
Setting the Type of a Connected Link to P2P ···············································································1-25
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets········································1-26
Enabling the Output of Port State Transition Information······························································1-27
Enabling the MSTP Feature ··········································································································1-27
Configuring Leaf Nodes ························································································································1-28
Configuring an MST Region ··········································································································1-28
Configuring the Work Mode of MSTP····························································································1-28
Configuring the Timeout Factor·····································································································1-28
Configuring the Maximum Transmission Rate of Ports·································································1-28
Configuring Ports as Edge Ports ···································································································1-28
Configuring Path Costs of Ports ····································································································1-28
Configuring Port Priority ················································································································1-30
Setting the Type of a Connected Link to P2P ···············································································1-31
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets········································1-31
Enabling Output of Port State Transition Information····································································1-31
Enabling the MSTP Feature ··········································································································1-31
Performing mCheck ······························································································································1-31
Configuration Prerequisites ···········································································································1-31
Configuration Procedure················································································································1-31
Configuration Example ··················································································································1-32
Configuring Digest Snooping ················································································································1-32
Configuring No Agreement Check ········································································································1-34
i
Configuring Protection Functions··········································································································1-37
Configuration prerequisites ···········································································································1-37
Enabling BPDU Guard···················································································································1-37
Enabling Root Guard ·····················································································································1-38
Enabling Loop Guard·····················································································································1-39
Enabling TC-BPDU Attack Guard ·································································································1-39
Remotely Configuring MSTP for an ONU ·····························································································1-40
Displaying and Maintaining MSTP ········································································································1-41
MSTP Configuration Example···············································································································1-42
ii
1 MSTP Configuration
When configuring MSTP, go to these sections for information you are interested in:
z MSTP Overview
z Configuration Task List
z Configuring the Root Bridge
z Configuring Leaf Nodes
z Performing mCheck
z Configuring Digest Snooping
z Configuring No Agreement Check
z Configuring Protection Functions
z Remotely Configuring MSTP for an ONU
z Displaying and Maintaining MSTP
z MSTP Configuration Example
MSTP Overview
Introduction to STP
Why STP?
The Spanning Tree Protocol (STP) was developed based on the 802.1d standard of IEEE to eliminate
loops at the data link layer in a local area network (LAN). Devices running this protocol detect loops in
the network by exchanging information with one another and eliminate loops by selectively blocking
certain ports to prune the loop structure into a loop-free tree structure. This avoids proliferation and
infinite cycling of packets that would occur in a loop network and prevents decreased performance of
network devices caused by duplicate packets received.
In the narrow sense, STP refers to IEEE 802.1d STP; in the broad sense, STP refers to the IEEE 802.1d
STP and various enhanced spanning tree protocols derived from that protocol.
Protocol Packets of STP
STP uses bridge protocol data units (BPDUs), also known as configuration messages, as its protocol
packets.
STP-enabled network devices exchange BPDUs to establish a spanning tree. BPDUs contain sufficient
information for the network devices to complete spanning tree calculation.
In STP, BPDUs come in two types:
z Configuration BPDUs, used for calculating a spanning tree and maintaining the spanning tree
topology.
z Topology change notification (TCN) BPDUs, used for notifying the concerned devices of network
topology changes, if any.
Basic concepts in STP
1) Root bridge
1-1
A tree network must have a root; hence the concept of root bridge was introduced in STP.
There is one and only one root bridge in the entire network, and the root bridge can change along with
changes of the network topology. Therefore, the root bridge is not fixed.
After network convergence, the root bridge generates and sends out configuration BPDUs at a certain
interval, and other devices just forward the BPDUs. This mechanism ensures stable topologies.
2) Root port
On a non-root bridge, the port nearest to the root bridge is called the root port. The root port is
responsible for communication with the root bridge. Each non-root bridge has one and only one root
port. The root bridge has no root port.
3) Designated bridge and designated port
The following table describes designated bridges and designated ports.
Table 1-1 Description of designated bridges and designated ports:
Classification Designated bridge Designated port

A device directly connected with the The port through which the
For a device local device and responsible for designated bridge forwards BPDUs
forwarding BPDUs to the local device to this device
The port through which the
The device responsible for forwarding
For a LAN designated bridge forwards BPDUs
BPDUs to this LAN segment
to this LAN segment
As shown in Path cost, AP1 and AP2, BP1 and BP2, and CP1 and CP2 are ports on Device A, Device B,
and Device C respectively.
z If Device A forwards BPDUs to Device B through AP1, the designated bridge for Device B is Device
A, and the designated port of Device B is port AP1 on Device A.
z Two devices are connected to the LAN: Device B and Device C. If Device B forwards BPDUs to the
LAN, the designated bridge for the LAN is Device B, and the designated port for the LAN is the port
BP2 on Device B.
Figure 1-1 A schematic diagram of designated bridges and designated ports
1-2
Path cost
Path cost is a reference value used for link selection in STP. By calculating path costs, STP selects
relatively robust links and blocks redundant links, and finally prunes the network into a loop-free tree.
All the ports on the root bridge are designated ports.
How STP works
The devices on a network exchange BPDUs to identify the network topology. Configuration BPDUs
contain sufficient information for the network devices to complete spanning tree calculation. Important
fields in a configuration BPDU include:
z Root bridge ID: consisting of the priority and MAC address of the root bridge.
z Root path cost: the cost of the path to the root bridge.
z Designated bridge ID: consisting of the priority and MAC address of the designated bridge.
z Designated port ID: designated port priority plus port name.
z Message age: age of the configuration BPDU while it propagates in the network.
z Max age: maximum age of the configuration BPDU.
z Hello time: configuration BPDU interval.
z Forward delay: the delay used by STP bridges to transit the state of the root and designated ports
to forwarding.
For simplicity, the descriptions and examples below involve only four fields of configuration BPDUs:
z Root bridge ID (represented by device priority)
z Root path cost (related to the rate of the link connected to the port)
z Designated bridge ID (represented by device priority)
z Designated port ID (represented by port name)
Calculation process of the STP algorithm
1) Initial state
Upon initialization of a device, each port generates a BPDU with itself as the root bridge, in which the
root path cost is 0, designated bridge ID is the device ID, and the designated port is the local port.
2) Selection of the optimum configuration BPDU
Each device sends out its configuration BPDU and receives configuration BPDUs from other devices.
The process of selecting the optimum configuration BPDU is as follows:
1-3
Table 1-2 Selection of the optimum configuration BPDU
Step Actions
Upon receiving a configuration BPDU on a port, the device performs the following:
z If the received configuration BPDU has a lower priority than that of the configuration
BPDU generated by the port, the device discards the received configuration BPDU
1 and does not process the configuration BPDU of this port.
z If the received configuration BPDU has a higher priority than that of the
configuration BPDU generated by the port, the device replaces the content of the
configuration BPDU generated by the port with the content of the received
configuration BPDU.
The device compares the configuration BPDUs of all the ports and chooses the
2
optimum configuration BPDU.
The following are the principles of configuration BPDU comparison:

z The configuration BPDU that has the lowest root bridge ID has the highest priority.
z If all the configuration BPDUs have the same root bridge ID, their root path costs are compared.
Assume that the root path cost in a configuration BPDU plus the path cost of a receiving port is S.
The configuration BPDU with the smallest S value has the highest priority.
z If all configuration BPDUs have the same ports value, their designated bridge IDs, designated port
IDs, and the IDs of the receiving ports are compared in sequence. The configuration BPDU
containing a smaller ID wins out.
3) Selection of the root bridge

Initially, each STP-enabled device on the network assumes itself to be the root bridge, with the root
bridge ID being its own device ID. By exchanging configuration BPDUs, the devices compare their root
bridge IDs to elect the device with the smallest root bridge ID as the root bridge.
4) Selection of the root port and designated ports on a non-root device
The process of selecting the root port and designated ports is as follows:
Table 1-3 Selection of the root port and designated ports
Step Description
A non-root-bridge device regards the port on which it received the optimum
1
configuration BPDU as the root port.
Based on the configuration BPDU and the path cost of the root port, the device
calculates a designated port configuration BPDU for each of the rest ports.
z The root bridge ID is replaced with that of the configuration BPDU of the root port.
2 z The root path cost is replaced with that of the configuration BPDU of the root port
plus the path cost of the root port.
z The designated bridge ID is replaced with the ID of this device.
z The designated port ID is replaced with the ID of this port.
1-4
Step Description
The device compares the calculated configuration BPDU with the configuration
BPDU on the port of which the port role is to be defined, and acts depending on the
comparison result:
z If the calculated configuration BPDU is superior, the device considers this port as
3 the designated port, and replaces the configuration BPDU on the port with the
calculated configuration BPDU, which will be sent out periodically.
z If the configuration BPDU on the port is superior, the device blocks this port
without updating its configuration BPDU. The blocked port can receive BPDUs
but not send BPDUs or forward data.
When the network topology is stable, only the root port and designated ports forward traffic, while other
ports are all in the blocked state – they receive BPDUs but do not forward BPDUs or user traffic.
A tree-shape topology forms upon successful election of the root bridge, the root port on each non-root
bridge and the designated ports.
The following is an example of how the STP algorithm works. As shown in Figure 1-2, assume that the
priority of Device A is 0, the priority of Device B is 1, the priority of Device C is 2, and the path costs of
these links are 5, 10 and 4 respectively.
Figure 1-2 Network diagram for the STP algorithm
z Initial state of each device

The following table shows the initial state of each device.
Table 1-4 Initial state of each device
Device Port name BPDU of port

AP1 {0, 0, 0, AP1}
Device A
AP2 {0, 0, 0, AP2}
BP1 {1, 0, 1, BP1}
Device B
BP2 {1, 0, 1, BP2}
1-5
Device Port name BPDU of port
CP1 {2, 0, 2, CP1}
Device C
CP2 {2, 0, 2, CP2}
z Comparison process and result on each device

The following table shows the comparison process and result on each device.
Table 1-5 Comparison process and result on each device
BPDU of port after

Device Comparison process
comparison
z Port AP1 receives the configuration BPDU of Device B
{1, 0, 1, BP1}. Device A finds that the configuration
BPDU of the local port {0, 0, 0, AP1} is superior to the
received configuration BPDU, and therefore discards the
received configuration BPDU.
z Port AP2 receives the configuration BPDU of Device C
{2, 0, 2, CP1}. Device A finds that the BPDU of the local
port {0, 0, 0, AP2} is superior to the received AP1: {0, 0, 0, AP1}
Device A
configuration BPDU, and therefore discards the received AP2: {0, 0, 0, AP2}
configuration BPDU.
z Device A finds that both the root bridge and designated
bridge in the configuration BPDUs of all its ports are
itself, so it assumes itself to be the root bridge. In this
case, it does not make any change to the configuration
BPDU of each port, and starts sending out configuration
BPDUs periodically.
z Port BP1 receives the configuration BPDU of Device A
{0, 0, 0, AP1}. Device B finds that the received
configuration BPDU is superior to the configuration
BPDU of the local port {1, 0, 1, BP1}, and updates the
configuration BPDU of BP1. BP1: {0, 0, 0, AP1}
z Port BP2 receives the configuration BPDU of Device C BP2: {1, 0, 1, BP2}
{2, 0, 2, CP2}. Device B finds that the configuration
BPDU of the local port {1, 0, 1, BP2} is superior to the
received configuration BPDU, and therefore discards the
received configuration BPDU.
z Device B compares the configuration BPDUs of all its
Device B ports, and determines that the configuration BPDU of
BP1 is the optimum configuration BPDU. Then, it uses
BP1 as the root port, the configuration BPDUs of which
will not be changed.
Root port BP1:
z Based on the configuration BPDU of BP1 and the path
cost of the root port (5), Device B calculates a designated {0, 0, 0, AP1}
port configuration BPDU for BP2 {0, 5, 1, BP2}. Designated port BP2:
z Device B compares the calculated configuration BPDU {0, 5, 1, BP2}
{0, 5, 1, BP2} with the configuration BPDU of BP2. If the
calculated BPDU is superior, BP2 will act as the
designated port, and the configuration BPDU on this port
will be replaced with the calculated configuration BPDU,
which will be sent out periodically.
1-6
BPDU of port after
Device Comparison process
comparison
z Port CP1 receives the configuration BPDU of Device A
{0, 0, 0, AP2}. Device C finds that the received
configuration BPDU is superior to the configuration
BPDU of the local port {2, 0, 2, CP1}, and updates the
configuration BPDU of CP1. CP1: {0, 0, 0, AP2}
z Port CP2 receives the configuration BPDU of port BP2 of
Device B {1, 0, 1, BP2} before the configuration BPDU is CP2: {1, 0, 1, BP2}
updated. Device C finds that the received configuration
BPDU is superior to the configuration BPDU of the local
port {2, 0, 2, CP2}, and therefore updates the
configuration BPDU of CP2.
After comparison:
z The configuration BPDU of CP1 is elected as the
optimum configuration BPDU, so CP1 is identified as the Root port CP1:
root port, the configuration BPDUs of which will not be
changed. {0, 0, 0, AP2}
z Device C compares the calculated designated port Designated port CP2:
configuration BPDU {0, 10, 2, CP2} with the configuration {0, 10, 2, CP2}
BPDU of CP2, and CP2 becomes the designated port,
and the configuration BPDU of this port will be replaced
with the calculated configuration BPDU.
Device C z Then, port CP2 receives the updated configuration
BPDU of Device B {0, 5, 1, BP2}. Because the received
configuration BPDU is superior to its own configuration CP1: {0, 0, 0, AP2}
BPDU, Device C launches a BPDU update process.
z At the same time, port CP1 receives periodic CP2: {0, 5, 1, BP2}
configuration BPDUs from Device A. Device C does not
launch an update process after comparison.
After comparison:
z Because the root path cost of CP2 (9) (root path cost of
the BPDU (5) plus path cost corresponding to CP2 (4)) is
smaller than the root path cost of CP1 (10) (root path cost
of the BPDU (0) + path cost corresponding to CP2 (10)),
the BPDU of CP2 is elected as the optimum BPDU, and Blocked port CP2:
CP2 is elected as the root port, the messages of which {0, 0, 0, AP2}
will not be changed.
Root port CP2:
z After comparison between the configuration BPDU of
CP1 and the calculated designated port configuration {0, 5, 1, BP2}
BPDU, port CP1 is blocked, with the configuration BPDU
of the port unchanged, and the port will not receive data
from Device A until a spanning tree calculation process is
triggered by a new event, for example, the link from
Device B to Device C going down.
After the comparison processes described in the table above, a spanning tree with Device A as the root
bridge is established as shown in Figure 1-3.
1-7
Figure 1-3 The final calculated spanning tree
The spanning tree calculation process in this example is only simplified process.
The BPDU forwarding mechanism in STP
z Upon network initiation, every switch regards itself as the root bridge, generates configuration
BPDUs with itself as the root, and sends the configuration BPDUs at a regular hello interval.
z If it is the root port that received a configuration BPDU and the received configuration BPDU is
superior to the configuration BPDU of the port, the device increases the message age carried in the
configuration BPDU following a certain rule and starts a timer to time the configuration BPDU while
sending out this configuration BPDU through the designated port.
z If the configuration BPDU received on a designated port has a lower priority than the configuration
BPDU of the local port, the port immediately sends out its own configuration BPDU in response.
z If a path becomes faulty, the root port on this path will no longer receive new configuration BPDUs
and the old configuration BPDUs will be discarded due to timeout. In this case, the device will
generate a configuration BPDU with itself as the root and send out the BPDUs and TCN BPDUs.
This triggers a new spanning tree calculation process to establish a new path to restore the
network connectivity.
However, the newly calculated configuration BPDU will not be propagated throughout the network
immediately, so the old root ports and designated ports that have not detected the topology change
continue forwarding data along the old path. If the new root ports and designated ports begin to forward
data as soon as they are elected, a temporary loop may occur.
STP timers
STP calculation involves three important timing parameters: forward delay, hello time, and max age.
z Forward delay is the delay time for device state transition.
A path failure can cause spanning tree re-calculation to adapt the spanning tree structure to the change.
However, the resulting new configuration BPDU cannot propagate throughout the network immediately.
If the newly elected root ports and designated ports start to forward data right away, a temporary loop is
likely to occur.
1-8
For this reason, as a mechanism for state transition in STP, the newly elected root ports or designated
ports require twice the forward delay time before transiting to the forwarding state to ensure that the new
configuration BPDU has propagated throughout the network.
z Hello time is the time interval at which a device sends hello packets to the surrounding devices to
ensure that the paths are fault-free.
z Max age is a parameter used to determine whether a configuration BPDU held by the device has
expired. A configuration BPDU beyond the max age will be discarded.
Introduction to MSTP
Why MSTP
1) Weakness of STP and RSTP

STP does not support rapid state transition of ports. A newly elected root port or designated port must
wait twice the forward delay time before transiting to the forwarding state, even if it is a port on a
point-to-point link or an edge port, which directly connects to a user terminal rather than to another
device or a shared LAN segment.
The Rapid Spanning Tree Protocol (RSTP) is an optimized version of STP. RSTP allows a newly
elected root port or designated port to enter the forwarding state much quicker under certain conditions
than in STP. As a result, it takes a shorter time for the network to converge.
z In RSTP, a newly elected root port can enter the forwarding state rapidly if this condition is met: The
old root port on the device has stopped forwarding data and the upstream designated port has
started forwarding data.
z In RSTP, a newly elected designated port can enter the forwarding state rapidly if this condition is
met: The designated port is an edge port or a port connected with a point-to-point link. If the
designated port is an edge port, it can enter the forwarding state directly; if the designated port is
connected with a point-to-point link, it can enter the forwarding state immediately after the device
undergoes handshake with the downstream device and gets a response.
Although RSTP supports rapid network convergence, it has the same drawback as STP does: All
bridges within a LAN share the same spanning tree, so redundant links cannot be blocked based on
VLAN, and the packets of all VLANs are forwarded along the same spanning tree.
2) Features of MSTP
The Multiple Spanning Tree Protocol (MSTP) overcomes the shortcomings of STP and RSTP. In
addition to the support for rapid network convergence, it also allows data flows of different VLANs to be
forwarded along separate paths, thus providing a better load sharing mechanism for redundant links.
For description about VLANs, refer to VLAN Configuration in the Access Volume.
MSTP features the following:
z MSTP supports mapping VLANs to MST instances (MSTIs) by means of a VLAN-to-MSTI mapping
table. MSTP can reduce communication overheads and resource usage by mapping multiple
VLANs to one MSTI.
1-9
z MSTP divides a switched network into multiple regions, each containing multiple spanning trees
that are independent of one another.
z MSTP prunes a loop network into a loop-free tree, thus avoiding proliferation and endless cycling of
packets in a loop network. In addition, it provides multiple redundant paths for data forwarding, thus
supporting load balancing of VLAN data.
z MSTP is compatible with STP and RSTP.
Basic concepts in MSTP
Assume that all the four switches in Figure 1-4 are running MSTP. This section explains some basic
concepts of MSTP based on the figure.
Figure 1-4 Basic concepts in MSTP
1) MST region
A multiple spanning tree region (MST region) consists of multiple devices in a switched network and the
network segments among them. These devices have the following characteristics:
z All are MSTP-enabled,
z They have the same region name,
z They have the same VLAN-to-MSTI mapping configuration,
z They have the same MSTP revision level configuration, and
z They are physically linked with one another.
For example, all the devices in region A0 in Figure 1-4 have the same MST region configuration:
z The same region name,
z The same VLAN-to-MSTI mapping configuration (VLAN 1 is mapped to MSTI 1, VLAN 2 to MSTI 2,
and the rest to the common and internal spanning tree (CIST, that is, MSTI 0), and
z The same MSTP revision level (not shown in the figure).
1-10
Multiple MST regions can exist in a switched network. You can use an MSTP command to assign
multiple devices to the same MST region.
2) VLAN-to-MSTI mapping table
As an attribute of an MST region, the VLAN-to-MSTI mapping table describes the mapping relationships
between VLANs and MSTIs. In Figure 1-4, for example, the VLAN-to-MSTI mapping table of region A0
describes that the same region name, the same VLAN-to-MSTI mapping configuration (VLAN 1 is
mapped to MSTI 1, VLAN 2 to MSTI 2, and the rest to CIST). MSTP achieves load balancing by means
of the VLAN-to-MSTI mapping table.
3) IST
An internal spanning tree (IST) is a spanning tree that runs in an MST region.
ISTs in all MST regions and the common spanning tree (CST) jointly constitute the common and internal
spanning tree (CIST) of the entire network. An IST is a section of the CIST.
In Figure 1-4, for example, the CIST has a section in each MST region, and this section is the IST in the
respective MST region.
4) CST
The CST is a single spanning tree that connects all MST regions in a switched network. If you regard
each MST region as a “device”, the CST is a spanning tree calculated by these devices through STP or
RSTP. For example, the red lines in Figure 1-4 represent the CST.
5) CIST
Jointly constituted by ISTs and the CST, the CIST is a single spanning tree that connects all devices in a
switched network.
In Figure 1-4, for example, the ISTs in all MST regions plus the inter-region CST constitute the CIST of
the entire network.
6) MSTI
Multiple spanning trees can be generated in an MST region through MSTP, one spanning tree being
independent of another. Each spanning tree is referred to as a multiple spanning tree instance (MSTI).
In Figure 1-4, for example, multiple spanning trees can exist in each MST region, each spanning tree
corresponding to a VLAN. These spanning trees are called MSTIs.
7) Regional root bridge
The root bridge of the IST or an MSTI within an MST region is the regional root bridge of the IST or the
MSTI. Based on the topology, different spanning trees in an MST region may have different regional
roots.
For example, in region D0 in Figure 1-4, the regional root of MSTI 1 is device B, while that of MSTI 2 is
device C.
8) Common root bridge
The common root bridge is the root bridge of the CIST.
In Figure 1-4, for example, the common root bridge is a device in region A0.
9) Boundary port
A boundary port is a port that connects an MST region to another MST region, or to a single
spanning-tree region running STP, or to a single spanning-tree region running RSTP. In Figure 1-4, for
example, if a device in region A0 is interconnected with the first port of a device in region D0 and the
1-11
common root bridge of the entire switched network is located in region A0, the first port of that device in
region D0 is the boundary port of region D0.
During MSTP calculation, a boundary port’s role on an MSTI is consistent with its role on the CIST. But
that is not true with master ports. A master port in MSTIs is a root port in the CIST.
10) Roles of ports
MSTP calculation involves these port roles: root port, designated port, master port, alternate port,
backup port, and so on.
z Root port: a port responsible for forwarding data to the root bridge.
z Designated port: a port responsible for forwarding data to the downstream network segment or
device.
z Master port: A port on the shortest path from the current region to the common root bridge,
connecting the MST region to the common root bridge. If the region is seen as a node, the master
port is the root port of the region on the CST. The master port is a root port on IST/CIST and still a
master port on the other MSTIs.
z Alternate port: The standby port for the root port and the master port. When the root port or master
port is blocked, the alternate port becomes the new root port or master port.
z Backup port: The backup port of a designated port. When the designated port is blocked, the
backup port becomes a new designated port and starts forwarding data without delay. A loop
occurs when two ports of the same MSTP device are interconnected. Therefore, the device will
block either of the two ports, and the backup port is that port to be blocked.
A port can play different roles in different MSTIs.
Figure 1-5 Port roles
Figure 1-5 helps understand these concepts. In this figure:

z Devices A, B, C, and D constitute an MST region.
z Port 1 and port 2 of device A connect to the common root bridge.
z Port 5 and port 6 of device C form a loop.
z Port 3 and port 4 of device D connect downstream to other MST regions.
1-12
11) Port states
In MSTP, port states fall into the following three:
z Forwarding: the port learns MAC addresses and forwards user traffic;
z Learning: the port learns MAC addresses but does not forward user traffic;
z Discarding: the port neither learns MAC addresses nor forwards user traffic.
When in different MSTIs, a port can be in different states.
A port state is not exclusively associated with a port role. Table 1-6 lists the port state(s) supported by
each port role (“” indicates that the port supports this state, while “—“ indicates that the port does not
support this state).
Table 1-6 Ports states supported by different port roles
Port role (right) Root port/master Designated Alternate Backup

Port state (below) port port port port
Forwarding — —
Learning — —
Discarding
How MSTP works
MSTP divides an entire Layer 2 network into multiple MST regions, which are interconnected by a
calculated CST. Inside an MST region, multiple spanning trees are calculated, each being called an
MSTI. Among these MSTIs, MSTI 0 is the IST, while all the others are MSTIs. Similar to STP, MSTP
uses configuration BPDUs to calculate spanning trees. The only difference between the two protocols is
that an MSTP BPDU carries the MSTP configuration on the device from which this BPDU is sent.
1) CIST calculation
The calculation of a CIST tree is also the process of configuration BPDU comparison. During this
process, the device with the highest priority is elected as the root bridge of the CIST. MSTP generates
an IST within each MST region through calculation, and, at the same time, MSTP regards each MST
region as a single device and generates a CST among these MST regions through calculation. The CST
and ISTs constitute the CIST of the entire network.
2) MSTI calculation
Within an MST region, MSTP generates different MSTIs for different VLANs based on the
VLAN-to-MSTI mappings. MSTP performs a separate calculation process, which is similar to spanning
tree calculation in STP, for each spanning tree. For details, refer to How STP works.
In MSTP, a VLAN packet is forwarded along the following paths:
z Within an MST region, the packet is forwarded along the corresponding MSTI.
z Between two MST regions, the packet is forwarded along the CST.
1-13
Implementation of MSTP on devices
MSTP is compatible with STP and RSTP. STP and RSTP protocol packets can be recognized by
devices running MSTP and used for spanning tree calculation.
In addition to basic MSTP functions, many special functions are provided for ease of management, as
follows:
z Root bridge hold
z Root bridge backup
z Root guard
z BPDU guard
z Loop guard
z TC-BPDU guard
z Support for hot swapping of interface cards and active/standby changeover.
Protocols and Standards
MSTP is documented in:

z IEEE 802.1d: Spanning Tree Protocol
z IEEE 802.1w: Rapid Spanning Tree Protocol
z IEEE 802.1s: Multiple Spanning Tree Protocol
Configuration Task List

Before configuring MSTP, you need to know the position of each device in each MSTI: root bridge or
leave node. In each MSTI, one, and only one device acts as the root bridge, while all others as leaf
nodes.
Complete these tasks to configure MSTP:
Task Remarks
Configuring an MST Region Required
Specifying the Root Bridge or a Secondary Root Bridge Optional
Configuring the Work Mode of an MSTP Device Optional
Configuring the Priority of the Current Device Optional

Configuring the Maximum Hops of an MST Region Optional
Configuring the Network Diameter of a Switched Network Optional
Configuring Timers of MSTP Optional

Configuring the
Root Bridge Configuring the Timeout Factor Optional
Configuring the Maximum Port Rate Optional
Configuring Ports as Edge Ports Optional
Setting the Type of a Connected Link to P2P Optional
Configuring the Mode a Port Uses to Recognize/Send
Optional
MSTP Packets
Enabling the Output of Port State Transition Information Optional
Enabling the MSTP Feature Required
1-14
Task Remarks
Configuring an MST Region Required
Configuring the Work Mode of an MSTP Device Optional
Configuring the Timeout Factor Optional
Configuring the Maximum Port Rate Optional

Configuring Ports as Edge Ports Optional
Configuring Leaf Configuring Path Costs of Ports Optional
Nodes
Configuring Port Priority Optional
Setting the Type of a Connected Link to P2P Optional
Configuring the Mode a Port Uses to Recognize/Send
Optional
MSTP Packets
Enabling the Output of Port State Transition Information Optional
Enabling the MSTP Feature Required

Performing mCheck Optional
Configuring Digest Snooping Optional
Configuring No Agreement Check Optional

Configuring Protection Functions Optional
z If both GVRP and MSTP are enabled on a device at the same time, GVRP packets will be
forwarded along the CIST. Therefore, if you wish to advertise a certain VLAN within the network
through GVRP in this case, make sure that this VLAN is mapped to the CIST (MSTI 0) when
configuring the VLAN-to-MSTI mapping table. For the detailed information of GVRP, refer to GVRP
Configuration of the Access Volume.
z MSTP is mutually exclusive with any of the following functions on a port: service loopback, RRPP,
Smart Link, and BPDU tunnel.
z Configurations made in Layer-2 aggregate port view can take effect only on the aggregate port;
configurations made on an aggregation member port can take effect only after the port is removed
from the aggregation group. For detailed information about link aggregation, refer to Link
Aggregation Configuration in the Access Volume.
z After you enable MSTP on a Layer-2 aggregate port, the system performs MSTP calculation on the
Layer-2 aggregate port but not on the aggregation member ports. The MSTP enable state and
forwarding state of each selected port in an aggregation group is consistent with those of the
corresponding Layer-2 aggregate port.
z Though the member port of an aggregation group does not participate in MSTP calculation, the
port still reserves its MSTP configurations for participating MSTP calculation after leaving the
aggregation group.
An S7500E switch installed with an OLT card can work as an EPON OLT. In this case, you can remote
configure STP/RSTP/MSTP for ONUs in ONU port view to remove loops between attached ONUs, and
1-15
you can also remotely configure RSTP for UNIs on an ONU to remove loops between UNIs and terminal
users.
Complete the following tasks to configure MSTP:
Task Remarks
Remotely Configuring MSTP for an ONU Optional
Optional
Remotely Configure RSTP for UNIs of an ONU Refer to EPON-OLT Configuration in the
Access Volume
Configuring the Root Bridge

Configuring an MST Region
Follow these steps to configure an MST region:

Enter MST region view stp region-configuration —

Optional
Configure the MST region
region-name name The MST region name is the MAC
name
address by default.
instance instance-id vlan Optional
Configure the vlan-list Use either command.
VLAN-to-MSTI mapping
table vlan-mapping modulo All VLANs in an MST region are
modulo mapped to MSTI 0 by default.
Configure the MSTP Optional

revision level of the MST revision-level level
region 0 by default
Activate MST region active

Required
configuration manually region-configuration
Display all the
check
configuration information of Optional
region-configuration
the MST region
Display the currently
display stp The display command can be
effective MST region
region-configuration executed in any view.
configuration information
Two or more MSTP-enabled devices belong to the same MST region only if they are configured to have
the same MST region name, the same VLAN-to-MSTI mapping entries in the MST region and the same
MST region revision level, and they are interconnected via a physical link.
1-16
The configuration of MST region–related parameters, especially the VLAN-to-MSTI mapping table, will
cause MSTP to launch a new spanning tree calculation process, which may result in network topology
instability. To reduce the possibility of topology instability caused by configuration, MSTP will not
immediately launch a new spanning tree calculation process when processing MST region–related
configurations; instead, such configurations will take effect only after you:
z activate the MST region–related parameters using the active region-configuration command, or
z enable MSTP using the stp enable command.
Configuration example
# Configure the MST region name to be “info”, the MSTP revision level to be 1, and VLAN 2 through
VLAN 10 to be mapped to MSTI 1 and VLAN 20 through VLAN 30 to MSTI 2.
[Sysname] stp region-configuration
[Sysname-mst-region] region-name info
[Sysname-mst-region] instance 1 vlan 2 to 10
[Sysname-mst-region] instance 2 vlan 20 to 30
[Sysname-mst-region] revision-level 1
[Sysname-mst-region] active region-configuration
Specifying the Root Bridge or a Secondary Root Bridge
MSTP can determine the root bridge of a spanning tree through MSTP calculation. Alternatively, you
can specify the current device as the root bridge using the commands provided by the system.
Specifying the current device as the root bridge of a specific spanning tree
Follow these steps to specify the current device as the root bridge of a specific spanning tree:

stp [ instance instance-id ]
Specify the current device as root primary Required
the root bridge of a specific [ bridge-diameter By default, a device does not
spanning tree bridge-number ] [ hello-time function as the root bridge.
centi-seconds ]
Specifying the current device as a secondary root bridge of a specific spanning tree
Follow these steps to specify the current device as a secondary root bridge of a specific spanning tree:

stp [ instance instance-id ] Required
Specify the current device as a root secondary
secondary root bridge of a [ bridge-diameter By default, a device does not
specific spanning tree bridge-number ] [ hello-time function as a secondary root
centi-seconds ] bridge.
Note that:
1-17
z After specifying the current device as the root bridge or a secondary root bridge, you cannot
change the priority of the device.
z You can configure the current device as the root bridge or a secondary root bridge of an MSTI,
which is specified by instance instance-id in the command. If you set instance-id to 0, the current
device will be the root bridge or a secondary root bridge of the CIST.
z The current device has independent roles in different MSTIs. It can act as the root bridge or a
secondary root bridge of one instance while it can also act as the root bridge or a secondary root
bridge of another MSTI. However, the same device cannot be the root bridge and a secondary root
bridge in the same MSTI at the same time.
z There is one and only one root bridge in effect in a spanning tree instance. If two or more devices
have been designated to be root bridges of the same spanning tree instance, MSTP will select the
device with the lowest MAC address as the root bridge.
z You can specify multiple secondary root bridges for the same instance. Namely, you can specify
secondary root bridges for the same instance on two or more than two devices.
z When the root bridge of an instance fails or is shut down, the secondary root bridge (if you have
specified one) can take over the role of the primary root bridge. However, if you specify a new
primary root bridge for the instance at this time, the secondary root bridge will not become the root
bridge. If you have specified multiple secondary root bridges for an instance, when the root bridge
fails, MSTP will select the secondary root bridge with the lowest MAC address as the new root
bridge.
z When specifying the root bridge or a secondary root bridge, you can specify the network diameter
and hello time. However, these two options are effective only for MSTI 0, namely the CIST. If you
include these two options in your command for any other instance, the configuration can succeed,
but they will not actually work. For the description of network diameter and hello time, refer to
Configuring the Network Diameter of a Switched Network and Configuring Timers of MSTP.
z Alternatively, you can also specify the current device as the root bridge by setting the priority of the
device to 0. For the device priority configuration, refer to Configuring the Priority of the Current
Device.
# Specify the current device as the root bridge of MSTI 1 and a secondary root bridge of MSTI 2.
[Sysname] stp instance 1 root primary
[Sysname] stp instance 2 root secondary
Configuring the Work Mode of an MSTP Device
MSTP and RSTP can recognize each other’s protocol packets, so they are mutually compatible.
However, STP is unable to recognize MSTP packets. For hybrid networking with legacy STP devices
and for full interoperability with RSTP-enabled devices, MSTP supports three work modes:
STP-compatible mode, RSTP mode, and MSTP mode.
z In STP-compatible mode, all ports of the device send out STP BPDUs,
z In RSTP mode, all ports of the device send out RSTP BPDUs. If the device detects that it is
connected with a legacy STP device, the port connecting with the legacy STP device will
automatically migrate to STP-compatible mode.
z In MSTP mode, all ports of the device send out MSTP BPDUs. If the device detects that it is
connected with a legacy STP device, the port connecting with the legacy STP device will
automatically migrate to STP-compatible mode.
1-18
Follow these steps to configure the MSTP work mode:

Configure the work mode of Optional

stp mode { stp | rstp | mstp }
MSTP MSTP mode by default
# Configure MSTP to work in STP-compatible mode.

[Sysname] stp mode stp
Configuring the Priority of the Current Device
The priority of a device determines whether it can be elected as the root bridge of a spanning tree. A
lower value indicates a higher priority. By setting the priority of a device to a low value, you can specify
the device as the root bridge of the spanning tree. An MSTP-enabled device can have different priorities
in different MSTIs.
Follow these steps to configure the priority of the current device in a specified MSTI:

Configure the priority of the Optional
stp [ instance instance-id ]
current device in a specified
priority priority 32768 by default
MSTI
z After specifying the current device as the root bridge or a secondary root bridge, you cannot
change the priority of the device.
z During root bridge selection, if all devices in a spanning tree have the same priority, the one with
the lowest MAC address will be selected as the root bridge of the spanning tree.
# Set the device priority in MSTI 1 to 4096.

[Sysname] stp instance 1 priority 4096
1-19
Configuring the Maximum Hops of an MST Region
By setting the maximum hops of an MST region, you can restrict the region size. The maximum hops
configured on the regional root bridge will be used as the maximum hops of the MST region.
The regional root bridge always sends a configuration BPDU with a hop count set to the maximum value.
When a switch receives this configuration BPDU, it decrements the hop count by 1 and uses the new
hop count in the BPDUs it propagates. When the hop count of a BPDU reaches 0, it is discarded by the
device that received it. Thus, devices beyond the reach of the maximum hop can no longer take part in
spanning tree calculation, and thereby the size of the MST region is confined.
All the devices other than the root bridge in the MST region use the maximum hop value set for the root
bridge.
Follow these steps to configure the maximum number of hops of the MST region:

Configure the maximum hops Optional

stp max-hops hops
of the MST region 20 by default
A larger maximum hops setting means a larger size of the MST region. Only the maximum hops
configured on the regional root bridge can restrict the size of the MST region.
# Set the maximum hops of the MST region to 30.

[Sysname] stp max-hops 30
Configuring the Network Diameter of a Switched Network
Any two stations in a switched network are interconnected through a specific path composed of a series
of devices. The network diameter is the number of devices on the path composed of the most devices.
Follow these steps to configure the network diameter of the switched network:

Configure the network diameter stp bridge-diameter Optional

of the switched network bridge-number 7 by default
1-20
z The network diameter is a parameter that indicates the network size. A bigger network diameter
represents a larger network size.
z Based on the network diameter you configured, MSTP automatically sets an optimal hello time,
forward delay, and max age for the device.
z The configured network diameter is effective for the CIST only, and not for MSTIs. Each MST
region is considered as a device.
# Set the network diameter of the switched network to 6.

[Sysname] stp bridge-diameter 6
Configuring Timers of MSTP
MSTP involves three timers: forward delay, hello time and max age. You can configure these three
parameters for MSTP to calculate spanning trees.
Follow these steps to configure the timers of MSTP:

Optional
Configure the forward delay stp timer forward-delay
timer centi-seconds 1,500 centiseconds (15
seconds) by default
Optional
Configure the hello timer stp timer hello centi-seconds 200 centiseconds (2 seconds)
by default
Optional
stp timer max-age
Configure the max age timer 2,000 centiseconds (20
centi-seconds
seconds) by default
These three timers set on the root bridge of the CIST apply on all the devices on the entire switched
network.
1-21
z The length of the forward delay time is related to the network diameter of the switched network.
Typically, the larger the network diameter is, the longer the forward delay time should be. Note that
if the forward delay setting is too small, temporary redundant paths may be introduced; if the
forward delay setting is too big, it may take a long time for the network to converge. We recommend
that you use the default setting.
z An appropriate hello time setting enables the device to timely detect link failures on the network
without using excessive network resources. If the hello time is set too long, the device will take
packet loss as a link failure and trigger a new spanning tree calculation process; if the hello time is
set too short, the device will send repeated configuration BPDUs frequently, which adds to the
device burden and causes waste of network resources. We recommend that you use the default
setting.
z If the max age time setting is too small, the network devices will frequently launch spanning tree
calculations and may take network congestion as a link failure; if the max age setting is too large,
the network may fail to timely detect link failures and fail to timely launch spanning tree calculations,
thus reducing the auto-sensing capability of the network. We recommend that you use the default
setting.
The settings of hello time, forward delay and max age must meet the following formulae; otherwise
network instability will frequently occur.
z 2 × (forward delay – 1 second) ~ max age
z Max age ~ 2 × (hello time + 1 second)
We recommend that you specify the network diameter with the stp root primary command and let
MSTP automatically calculate optimal settings of these three timers.
# Set the forward delay to 1,600 centiseconds, hello time to 300 centiseconds, and max age to 2,100
centiseconds.
[Sysname] stp timer forward-delay 1600
[Sysname] stp timer hello 300
[Sysname] stp timer max-age 2100
Configuring the Timeout Factor
After the network topology is stabilized, each non-root-bridge device forwards configuration BPDUs to
the downstream devices at the interval of hello time to check whether any link is faulty. Typically, if a
device does not receive a BPDU from the upstream device within nine times the hello time, it will
assume that the upstream device has failed and start a new spanning tree calculation process.
In a very stable network, this kind of spanning tree calculation may occur because the upstream device
is busy. In this case, you can avoid such unwanted spanning tree calculation by lengthening the timeout
time.
1-22
Follow these steps to configure the timeout factor:

Configure the timeout factor of Optional

stp timer-factor number
the device 3 by default
z Timeout time = timeout factor × 3 × hello time.

z Typically, we recommend that you set the timeout factor to 5, or 6, or 7 for a stable network.
# Set the timeout factor to 6.

[Sysname] stp timer-factor 6
Configuring the Maximum Port Rate
The maximum rate of a port refers to the maximum number of MSTP packets that the port can send
within each hello time. The maximum rate of an Ethernet port is related to the physical status of the port
and the network structure.
Follow these steps to configure the maximum rate of a port or a group of ports:

Enter Ethernet Required
or Layer-2 interface interface-type Use either command.
Enter port aggregate port interface-number
view Configurations made in port view
view or port will take effect on the current
group view port only; configurations made in
Enter port port-group manual
port group view will take effect
group view port-group-name
on all ports in the port group.
Configure the maximum rate of stp transmit-limit Optional

the port(s) packet-number 10 by default
1-23
If the maximum rate setting of a port is too big, the port will send a large number of MSTP packets within
each hello time, thus using excessive network resources. We recommend that you use the default
setting.
# Set the maximum transmission rate of port GigabitEthernet 2/0/1 to 5.

[Sysname] interface GigabitEthernet 2/0/1
[Sysname-GigabitEthernet2/0/1] stp transmit-limit 5
Configuring Ports as Edge Ports
If a port directly connects to a user terminal rather than another device or a shared LAN segment, this
port is regarded as an edge port. When a network topology change occurs, an edge port will not cause
a temporary loop. Because a device does not know whether a port is directly connected to a terminal,
you need to manually configure the port to be an edge port. After that, this port can transition rapidly
from the blocked state to the forwarding state without delay.
Follow these steps to specify a port or a group of ports as edge port(s):

view Configurations made in port view will
view or port take effect on the current port only;
group view configurations made in port group
view will take effect on all ports in the
port group.
Required
Configure the port(s) as edge
stp edged-port enable All Ethernet ports are non-edge
port(s)
ports by default.
z With BPDU guard disabled, when a port set as an edge port receives a BPDU from another port, it
will become a non-edge port again. In this case, you must reset the port before you can configure it
to be an edge port again.
z If a port directly connects to a user terminal, configure it as an edge port and enable BPDU guard
for it. This enables the port to transition to the forwarding state fast while ensuring network security.
1-24
# Configure GigabitEthernet2/0/1 to be an edge port.

[Sysname] interface GigabitEthernet 2/0/1
[Sysname-GigabitEthernet2/0/1] stp edged-port enable
Setting the Type of a Connected Link to P2P
A point-to-point link is a link directly connecting two devices. If the two ports across a point-to-point link
are root ports or designated ports, the ports can rapidly transition to the forwarding state after a
proposal-agreement handshake process.
Follow these steps to set the type of a connected link to P2P:

port group.
Optional
stp point-to-point { auto
Setting the type of a connected The default setting is auto; namely
| force-false |
link to P2P the port automatically detects
force-true }
whether its link is point-to-point.
z A Layer-2 aggregate port can be configured to connect to a point-to-point link. If a port works in
auto-negotiation mode and the negotiation result is full duplex, this port can be configured as
connecting to a point-to-point link.
z If a port is configured as connecting to a point-to-point link, the setting takes effect for the port in all
MSTIs. If the physical link to which the port connects is not a point-to-point link and you force it to
be a point-to-point link by configuration, the configuration may incur a temporary loop.
# Configure port GigabitEthernet2/0/1 as connecting to a point-to-point link.

[Sysname] interface GigabitEthernet2/0/1
[Sysname-GigabitEthernet2/0/1] stp point-to-point force-true
1-25
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets
A port can send/recognize MSTP packets of two formats:

z 802.1s-compliant standard format, and
z Compatible format
By default, the packet format recognition mode of a port is auto, namely the port automatically
distinguishes the two MSTP packet formats, and determines the format of packets it will send based on
the recognized format. You can configure the MSTP packet format to be used by a port. After the
configuration, when working in MSTP mode, the port sends and receives only MSTP packets of the
format you have configured to communicate with devices that send packets of the same format.
Follow these steps to configure the MSTP packet format to be supported by a port or a group of ports:


view or view Configurations made in port view
port group will take effect on the current port
view only; configurations made in port
group view will take effect on all
ports in the port group.
Configure the mode the port Optional
stp compliance { auto | dot1s
uses to recognize/send
| legacy } auto by default
MSTP packets
z In MSTP mode, if a port is configured to recognize/send MSTP packets in a mode other than auto,
and if it receives a packet in a format different from the specified type, the port will become a
designated port and remain in the discarding state to prevent the occurrence of a loop.
z If a port receives MSTP packets of different formats frequently, this means that the MSTP packet
format configuration contains errors. In this case, if the port is working in MSTP mode, it will be
disabled for protection. Those ports closed thereby can be restored only by the network
administers.
# Configure GigabitEthernet2/0/1 to receive and send standard-format MSTP packets.

[Sysname-GigabitEthernet2/0/1] stp compliance dot1s
1-26
Enabling the Output of Port State Transition Information
In a large-scale, MSTP-enabled network, there are a large number of MSTIs, so ports may frequently
transition from one state to another. In this situation, you can enable devices to output the port state
transition information of all MSTIs or the specified MSTI so as to monitor the port states in real time.
Follow these steps to enable output of port state transition information:

Enable output of port state Optional

stp port-log { all | instance
transition information of all By default, this function is
instance-id }
MSTIs or a particular MSTI enabled.
Enabling the MSTP Feature
Follow these steps to enable the MSTP feature:

Enable the MSTP feature for the Required

stp enable
device By default, MSTP is disabled.
interface
or Layer-2 Use either command.
interface-type
Enter port aggregate port
interface-number Configurations made in port view will
view or port view
take effect on the current port only;
group view configurations made in port group view
will take effect on all ports in the port
group.
Optional
Enable the MSTP feature for the By default, MSTP is disabled on a port.
stp enable After you enable MSTP for the device
port(s)
globally, MSTP is enabled on all ports
automatically.
z You must enable MSTP for the device before any other MSTP-related configuration can take
effect.
z To control MSTP flexibly, you can use the stp disable or undo stp command to disable the MSTP
feature for certain ports so that they will not take part in spanning tree calculation and thus to save
the device’s CPU resources.
# Enable MSTP for the device and disable MSTP for port GigabitEthernet2/0/1.
1-27
[Sysname] stp enable
[Sysname-GigabitEthernet2/0/1] stp disable
Configuring Leaf Nodes

Configuring an MST Region
Refer to Configuring an MST Region in the section about root bridge configuration.
Configuring the Work Mode of MSTP
Refer to Configuring the Work Mode of an MSTP Device in the section about root bridge configuration.
Configuring the Timeout Factor
Refer to Configuring Timers of MSTP in the section about root bridge configuration.
Configuring the Maximum Transmission Rate of Ports
Refer to Configuring the Maximum Port Rate in the section about root bridge configuration.
Configuring Ports as Edge Ports
Refer to Configuring Ports as Edge Ports in the section about root bridge configuration.
Configuring Path Costs of Ports
Path cost is a parameter related to the rate of a port. On an MSTP-enabled device, a port can have
different path costs in different MSTIs. Setting appropriate path costs allows VLAN traffic flows to be
forwarded along different physical links, thus to enable VLAN-based load balancing.
The device can automatically calculate the default path cost; alternatively, you can also configure the
path cost for ports.
Specifying a standard that the device uses when calculating the default path cost
You can specify a standard for the device to use in automatic calculation for the default path cost. The
device supports the following standards:
z dot1d-1998: The device calculates the default path cost for ports based on IEEE 802.1d-1998.
z dot1t: The device calculates the default path cost for ports based on IEEE 802.1t.
z legacy: The device calculates the default path cost for ports based on a proprietary standard.
Follow these steps to specify a standard for the device to use when calculating the default path cost:

Specify a standard for the Optional

device to use when calculating stp pathcost-standard
the default path costs for ports { dot1d-1998 | dot1t | legacy } By default, the keyword legacy
of the device is used.
1-28
Table 1-7 Link speed vs. path cost
Link speed Duplex state 802.1D-1998 802.1t Private standard

0 — 65535 200,000,000 200,000
Single Port 100 2,000,000 2,000

Aggregate Link 2 Ports 100 1,000,000 1,800
10 Mbps
Aggregate Link 3 Ports 100 666,666 1,600
Aggregate Link 4 Ports 100 500,000 1,400
Single Port 19 200,000 200
Aggregate Link 2 Ports 19 100,000 180
100 Mbps
Single Port 4 20,000 20
1000 Mbps
Single Port 2 2,000 2
10 Gbps
Aggregate Link 3 Ports 2 666 1
Aggregate Link 4 Ports 2 500 1
When calculating path cost for an aggregate port, 802.1D-1998 does not take into account the number
of member ports in its aggregation group as 802.1T does. The calculation formula is: Path Cost =
200,000,000/link speed (in 100 kbps), where link speed is the sum of the link speed values of the
non-blocked ports in the aggregation group.
Configuring Path Costs of Ports
Follow these steps to configure the path cost of ports:

Enter port aggregate interface-number
port view Configurations made in port view will
port group.
Required
Configure the path cost of the stp [ instance
port(s) instance-id ] cost cost By default, MSTP automatically
calculates the path cost of each port.
1-29
z If you change the standard that the device uses in calculating the default path cost, the port path
cost value set through the stp cost command will be invalid.
z When the path cost of a port is changed, MSTP will re-calculate the role of the port and initiate a
state transition. If you use 0 as instance-id, you are setting the path cost of the CIST.
Configuring Port Priority
The priority of a port is an important factor in determining whether the port can be elected as the root
port of a device. If all other conditions are the same, the port with the highest priority will be elected as
the root port.
On an MSTP-enabled device, a port can have different priorities in different MSTIs, and the same port
can play different roles in different MSTIs, so that data of different VLANs can be propagated along
different physical paths, thus implementing per-VLAN load balancing. You can set port priority values
based on the actual networking requirements.
Follow these steps to configure the priority of a port or a group of ports:


port group.
stp [ instance Optional
Configure a priority for the
instance-id ] port priority
port(s) 128 for all Ethernet ports by default.
priority
z When the priority of a port is changed, MSTP will re-calculate the role of the port and initiate a state
transition.
z Generally, a lower configured value indicates a higher priority. If you configure the same priority
value for all the Ethernet ports on a device, the specific priority of a port depends on the index
number of the port. Changing the priority of an Ethernet port triggers a new spanning tree
calculation process.
1-30
# Set the priority of port GigabitEthernet2/0/1 to 16 in MSTI 1.

[Sysname-GigabitEthernet2/0/1] stp instance 1 port priority 16
Setting the Type of a Connected Link to P2P
Refer to Setting the Type of a Connected Link to P2P in the section about root bridge configuration.
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets
Refer to Configuring the Mode a Port Uses to Recognize/Send MSTP Packets in the section about root
bridge configuration.
Enabling Output of Port State Transition Information
Refer to Enabling the Output of Port State Transition Information in the section about root bridge
configuration.
Enabling the MSTP Feature
Refer to Enabling the MSTP Feature in the section about root bridge configuration.
Performing mCheck
Ports on an MSTP-enabled device have three working modes: STP compatible mode, RSTP mode, and
MSTP mode.
In a switched network, if a port on the device running MSTP (or RSTP) connects to a device running
STP, this port will automatically migrate to the STP-compatible mode. However, if the device running
STP is removed, the port on the MSTP (or RSTP) device will not be able to migrate automatically to the
MSTP (or RSTP) mode, but will remain working in the STP-compatible mode. In this case, you can
perform an mCheck operation to force the port to migrate to the MSTP (or RSTP) mode.
You can perform mCheck on a port through two approaches, which lead to the same result.
z MSTP has been correctly configured on the device.

z MSTP is configured to operate in MSTP mode or RSTP-compatible mode.
Configuration Procedure
Performing mCheck globally
Follow these steps to perform global mCheck:
Perform mCheck stp mcheck Required
1-31
Performing mCheck in port view
Follow these steps to perform mCheck in port view:

Enter Ethernet or Layer-2 interface interface-type
—
aggregate port view interface-number
Configuration Example
# Perform mCheck on port GigabitEthernet2/0/1.

1) Method 1: Perform mCheck globally.
[Sysname] stp mcheck
2) Method 2: Perform mCheck in port view.
[Sysname-GigabitEthernet2/0/1] stp mcheck
Configuring Digest Snooping

As defined in IEEE 802.1s, interconnected devices are in the same region only when the region-related
configuration (domain name, revision level, VLAN-to-MSTI mappings) on them is identical. An MSTP
enabled device identifies devices in the same MST region via checking the configuration ID in BPDU
packets. The configuration ID includes the region name, revision level, configuration digest that is in
16-byte length and is the result calculated via the HMAC-MD5 algorithm based on VLAN-to-MSTI
mappings.
Since MSTP implementations differ with vendors, the configuration digests calculated using private
keys is different; hence different vendors’ devices in the same MST region can not communicate with
each other.
Enabling the Digest Snooping feature on the port connecting the local device to another vendor’s device
in the same MST region can make the two devices communicate with other.
Associated devices of different vendors are interconnected and run MSTP.
1-32
Follow these steps to configure Digest Snooping:


aggregate port interface-number
Enter port view Configurations made in port
view or port view will take effect on the
group view current port only;
Enter port port-group manual configurations made in port
group view port-group-name group view will take effect on all
Enable digest snooping on the Required

stp config-digest-snooping
interface or port group Not enabled by default
Required
Enable global digest snooping stp config-digest-snooping
z You can enable Digest Snooping on only a device that is connected to another vendor’s device that
uses its proprietary key to calculate the configuration digest.
z With the Digest Snooping feature enabled, comparison of configuration digest is not needed for
in-the-same-region check, so the VLAN-to-MSTI mappings must be the same on associated ports.
z With global Digest Snooping enabled, modification of VLAN-to-MSTI mappings and removing of
the current region configuration using the undo stp region-configuration command are not
allowed. You can only modify the region name and revision level.
z You need to enable this feature both globally and on associated ports to make it take effect. It is
recommended to enable the feature on all associated ports first and then globally, making all
configured ports take effect, and disable the feature globally to disable it on all associated ports.
z It is not recommended to enable Digest Snooping on MST region edge ports to avoid loops.
z It is recommended to enable Digest Snooping first and then MSTP. Do not enable Digest Snooping
when the network works well to avoid traffic interruption.
z Device A and Device B connect to a third-party’s router and all the routers are in the same region.
z Enable Digest Snooping on Device A and Device B so that the three routers can communicate with
one another.
1-33
Network diagram
Figure 1-6 Digest Snooping configuration
Third-party switch
Root port
Designated port
GE2/0/2 GE2/0/1 Blocked port
GE2/0/1 GE2/0/2
GE2/0/1
GE2/0/2
Device A Device B
1) Enable Digest Snooping on Device A.

# Enable Digest Snooping on GigabitEthernet 2/0/1.
[DeviceA] interface GigabitEthernet 2/0/1
[DeviceA-GigabitEthernet 2/0/1] stp config-digest-snooping
# Enable global Digest Snooping.

[DeviceA-GigabitEthernet 2/0/1] quit
[DeviceA] stp config-digest-snooping
2) Enable Digest Snooping on Device B (the same as above, omitted)
Configuring No Agreement Check

Two types of messages are used for rapid state transition on designated RSTP and MSTP ports:
z Proposal: sent by designated ports to request rapid transition
z Agreement: used to acknowledge rapid transition requests
Both RSTP and MSTP switches can perform rapid transition on a designated port only when the port
receives an agreement packet from the downstream switch. The differences between RSTP and MSTP
switches are:
z For MSTP, the downstream device’s root port sends an agreement packet only after it receives an
agreement packet from the upstream device.
z For RSTP, the down stream device sends an agreement packet regardless of whether an
agreement packet from the upstream device is received.
Figure 1-7 and Figure 1-8 show the rapid state transition mechanism on MSTP and RSTP designated
ports.
1-34
Figure 1-7 Rapid state transition of an MSTP designated port
Upstream Switch Downstream switch
Proposal for rapid transition Root port blocks other

non-edge ports
Agreement Root port changes to

forwarding state and
sends Agreement
nt
e me
Agre
Designated port Root port
changes to Designated port
forwarding state
Figure 1-8 Rapid state transition of an RSTP designated port
If the upstream device comes from another vendor, the rapid state transition implementation may be
limited. For example, when the upstream device adopts RSTP, and the downstream device adopts
MSTP and does not support RSTP mode, the root port on the downstream device receives no
agreement packet from the upstream device and thus sends no agreement packets to the upstream
device. As a result, the designated port of the upstream switch fails to transit rapidly and can only
change to the forwarding state after a period twice the Forward Delay.
In this case, you can enable the No Agreement Check feature on the downstream device’s port to
enable the designated port of the upstream device to transit its state rapidly.
z A device is connected to an upstream device supporting MSTP via a point-to-point link.

z Configure the same region name, revision level and VLAN-to-MSTI mappings on the two devices,
thus assigning them to the same region.
1-35
Follow these steps to configure No Agreement Check:


aggregate port interface-number
Enter port or view Configurations made in port
port group view will take effect on the
view current port only;
group view port-group-name group view will take effect on
all ports in the port group.
Required
Enable No Agreement Check stp no-agreement-check
The No Agreement Check feature can only take effect on the root port or Alternate port after enabled.
z Device A connects to a third-party’s device that has different MSTP implementation. Both switches
are in the same region.
z Another vendor’s device is the regional root bridge, and Device A is the downstream device.
Network diagram
Figure 1-9 No Agreement Check configuration
# Enable No Agreement Check on GigabitEthernet 2/0/2 of Device A.

[DeviceA] interface GigabitEthernet 2/0/2
1-36
[DeviceA-GigabitEthernet 2/0/2] stp no-agreement-check
Configuring Protection Functions

An MSTP-enabled device supports the following protection functions:
z BPDU guard
z Root guard
z Loop guard
z TC-BPDU attack guard
Among loop guard, root guard and edge port settings, only one function can take effect on a port at the
same time.
Configuration prerequisites
MSTP has been correctly configured on the device.
Enabling BPDU Guard
z We recommend that you enable BPDU guard on a device with edge ports configured.
z BPDU Guard does not take effect on loopback test-enabled ports. For information about loopback
test, refer to Ethernet Interface Configuration in the Access Volume.
For access layer devices, the access ports generally connect directly with user terminals (such as PCs)
or file servers. In this case, the access ports are configured as edge ports to allow rapid transition. When
these ports receive configuration BPDUs, the system will automatically set these ports as non-edge
ports and start a new spanning tree calculation process. This will cause a change of network topology.
Under normal conditions, these ports should not receive configuration BPDUs. However, if someone
forges configuration BPDUs maliciously to attack the devices, network instability will occur.
MSTP provides the BPDU guard function to protect the system against such attacks. With the BPDU
guard function enabled on the devices, when edge ports receive configuration BPDUs, MSTP will close
these ports and notify the NMS that these ports have been closed by MSTP. Those ports closed thereby
can be restored only by the network administers.
Make this configuration on a device with edge ports configured.
1-37
Follow these steps to enable BPDU guard:

Enable the BPDU guard Required

stp bpdu-protection
function for the device Disabled by default
Enabling Root Guard
We recommend that you enable root guard on a designated port.
The root bridge and secondary root bridge of a panning tree should be located in the same MST region.
Especially for the CIST, the root bridge and secondary root bridge are generally put in a high-bandwidth
core region during network design. However, due to possible configuration errors or malicious attacks in
the network, the legal root bridge may receive a configuration BPDU with a higher priority. In this case,
the current legal root bridge will be superseded by another device, causing an undesired change of the
network topology. As a result, the traffic that should go over high-speed links is switched to low-speed
links, resulting in network congestion.
To prevent this situation from happening, MSTP provides the root guard function to protect the root
bridge. If the root guard function is enabled on a designated port on a root bridge, this port will keep
playing the role of designated port on all MSTIs. Once this port receives a configuration BPDU with a
higher priority from an MSTI, it immediately sets that port to the listening state in the MSTI, without
forwarding the packet (this is equivalent to disconnecting the link connected with this port in the MSTI).
If the port receives no BPDUs with a higher priority within twice the forwarding delay, the port will revert
to its original state.
Make this configuration on a designated port.
Follow these steps to enable root guard:


aggregate interface-number
Enter port port view Configurations made in port
view or port view will take effect on the
group view current port only;
group view port-group-name group view will take effect on all
Enable the root guard function Required

stp root-protection
for the port(s) Disabled by default
1-38
Enabling Loop Guard
We recommend that you enable loop guard on the root port or an alternate port of a device.
By keeping receiving BPDUs from the upstream device, a device can maintain the state of the root port
and blocked ports. However, due to link congestion or unidirectional link failures, these ports may fail to
receive BPDUs from the upstream devices. In this case, the downstream device will reselect the port
roles: those ports in forwarding state that failed to receive upstream BPDUs will become designated
ports, and the blocked ports will transition to the forwarding state, resulting in loops in the switched
network. The loop guard function can suppress the occurrence of such loops.
If a loop guard–enabled port fails to receive BPDUs from the upstream device, and if the port took part
in STP calculation, all the instances on the port, no matter what roles the port plays, will be set to, and
stay in, the Discarding state.
Make this configuration on the root port or an alternate port of a device.
Follow these steps to enable loop guard:

Enter port aggregate interface-number
port view Configurations made in port view will
port group.
Enable the loop guard function Required

stp loop-protection
for the port(s) Disabled by default
Enabling TC-BPDU Attack Guard
When receiving a TC-BPDU (a BPDU used as notification of a topology change), the device will delete
the corresponding forwarding address entry. If someone forges TC-BPDUs to attack the device, the
device will receive a larger number of TC-BPDUs within a short time, and frequent deletion operations
bring a big burden to the device and hazard network stability.
With the TC-BPDU guard function enabled, the device limits the maximum number of times of
immediately deleting forwarding address entries within 10 seconds after it receives the first TC-BPDUs
to the value set with the stp tc-protection threshold command (assume the value is X). At the same
time, the system monitors whether the number of TC-BPDUs received within that period of time is larger
than X. If so, the device will perform another deletion operation after that period of time elapses. This
prevents frequent deletion of forwarding address entries.
Follow these steps to enable TC-BPDU attack guard:
1-39
stp tc-protection Optional

Enable the TC-BPDU attack guard function
enable Enabled by default
Configure the maximum number of times the
device deletes forwarding address entries stp tc-protection Optional
within a certain period of time immediately threshold number 6 by default
after it receives the first TC-BPDU
We recommend that you keep this feature enabled.
Remotely Configuring MSTP for an ONU

An S7500E switch installed with an OLT card can work as an EPON OLT. In this case, you can remotely
configure MSTP for an ONU attached to the OLT in ONU port view, as shown in the table below.
Note that:
z An ONU port supports STP/RSTP/MSTP. However, an ONU port supports only MSTI 0 among all
MSTIs.
z The STP priority of an ONU port is fixed to 0. To ensure the network operates normally, do not
configure the ONU as the STP root bridge.
z When STP is enabled globally on an OLT switch, you must enable STP on all ONUs.
z STP runs normally only when all attached ONUs are H3C ONUs.
z STP configurations in the system view of the OLT switch take effect on all attached ONUs.
z An ONU port supports only MSTI 0 among all MSTIs. Therefore, the MST region configuration on
the OLT switch does not take effect on the attached ONUs.
Follow these steps to configure MSTP for an ONU port:

Required
interface interface-type In Ethernet port view, the configuration
Enter ONU port view
interface-number mentioned below takes effect on the
current port only.
Configure the maximum Optional
stp transmit-limit
transmission rate of the
packet-number 10 by default
port
1-40
Configure the port as an Required

stp edged-port enable
edge port By default, no port is an edge port.
Optional
Configure the path cost of
stp cost cost By default, MSTP automatically
the port
calculates the path cost of each port.
Optional
Configure the link type of stp point-to-point { auto | The default setting is auto; namely the
the port force-false | force-true } device automatically detects whether
an Ethernet port connects to a
point-to-point link.
Enable the MSTP feature Optional

stp enable
for the port Enabled by default.
Enable digest snooping Required

stp config-digest-snooping
on the port Disabled by default
Enable No Agreement Required

stp no-agreement-check
Check on the port Disabled by default
Enable root guard on the Required

stp root-protection
port Disabled by default
Enable loop guard on the Required

stp loop-protection
port Disabled by default
MSTP configuration commands in ONU port view are the same as those in Ethernet port view, and thus
are not otherwise described.
Displaying and Maintaining MSTP

View information about abnormally
display stp abnormal-port Available in any view
blocked ports
View information about ports blocked
display stp down-port Available in any view
by STP protection actions
View the information of port role display stp [ instance
calculation history for the specified instance-id ] history [ slot Available in any view
MSTI or all MSTIs slot-number ]
View the statistics of TC/TCN BPDUs
display stp [ instance
sent and received by all ports in the Available in any view
instance-id ] tc [ slot slot-number ]
specified MSTI or all MSTIs
1-41
display stp [ instance
View the status information and instance-id ] [ interface
statistics information of MSTP interface-list | slot slot-number ]
[ brief ]
View the MST region configuration
display stp region-configuration Available in any view
information that has taken effect
View the root bridge information of all
display stp root Available in any view
MSTIs
Clear the statistics information of
reset stp [ interface interface-list ] Available in user view
MSTP
MSTP Configuration Example

Configure MSTP so that packets of different VLANs are forwarded along different spanning trees. The
specific configuration requirements are as follows:
z All devices on the network are in the same MST region.
z Packets of VLAN 10 are forwarded along MSTI 1, those of VLAN 30 are forwarded along MSTI 3,
those of VLAN 40 are forwarded along MSTI 4, and those of VLAN 20 are forwarded along MSTI 0.
z Device A and Device B are distribution layer devices, while Device C and Device D are access
layer devices. VLAN 10 and VLAN 30 are terminated on the distribution layer devices, and VLAN
40 is terminated on the access layer devices, so the root bridges of MSTI 1 and MSTI 3 are Device
A and Device B respectively, while the root bridge of MSTI 4 is Device C.
Network diagram
Figure 1-10 Network diagram for MSTP configuration

Device A Device B
Permit˖all VLAN
Permit˖ Permit˖
VLAN 10ˈ20 VLAN 20ˈ30
Permit˖ Permit˖
VLAN 10ˈ20 VLAN 20ˈ30
Permit˖VLAN 20, 40
Device C Device D
“Permit:“ beside each link in the figure is followed by the VLANs the packets of which are permitted to
pass this link.
1-42
1) Configuration on Device A
# Enter MST region view.
[DeviceA] stp region-configuration
# Configure the region name, VLAN-to-MSTI mappings and revision level of the MST region.
[DeviceA-mst-region] region-name example
[DeviceA-mst-region] instance 1 vlan 10
[DeviceA-mst-region] revision-level 0
# Activate MST region configuration manually.

[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Define Device A as the root bridge of MSTI 1.

[DeviceA] stp instance 1 root primary
# Enable MSTP for the device.

[DeviceA] stp enable
# View the MST region configuration information that has taken effect.
[DeviceA] display stp region-configuration
Oper configuration
Format selector :0
Region name :example
Revision level :0
Instance Vlans Mapped

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40
2) Configuration on Device B
<DeviceB> system-view
[DeviceB] stp region-configuration
[DeviceB-mst-region] region-name example
[DeviceB-mst-region] instance 1 vlan 10
[DeviceB-mst-region] revision-level 0

[DeviceB-mst-region] active region-configuration
[DeviceB-mst-region] quit
1-43
# Define Device B as the root bridge of MSTI 3.
[DeviceB] stp instance 3 root primary

[DeviceB] stp enable
[DeviceB] display stp region-configuration
Oper configuration
Format selector :0
Revision level :0

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40
3) Configuration on Device C.
<DeviceC> system-view
[DeviceC] stp region-configuration
[DeviceC-mst-region] region-name example
[DeviceC-mst-region] instance 1 vlan 10
[DeviceC-mst-region] revision-level 0

[DeviceC-mst-region] active region-configuration
[DeviceC-mst-region] quit
# Define Device C as the root bridge of MSTI 4.

[DeviceC] stp instance 4 root primary

[DeviceC] stp enable
[DeviceC] display stp region-configuration
Oper configuration
Format selector :0
Revision level :0

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
1-44
4 40
4) Configuration on Device D.
<DeviceD> system-view
[DeviceD] stp region-configuration
[DeviceD-mst-region] region-name example
[DeviceD-mst-region] instance 1 vlan 10
[DeviceD-mst-region] revision-level 0

[DeviceD-mst-region] active region-configuration
[DeviceD-mst-region] quit

[DeviceD] stp enable
[DeviceD] display stp region-configuration
Oper configuration
Format selector :0
Revision level :0

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40
1-45
Table of Contents
1 ARP Configuration·····································································································································1-1
ARP Overview·········································································································································1-1
ARP Function ··································································································································1-1
ARP Message Format ·····················································································································1-1
ARP Address Resolution Process···································································································1-2
ARP Table ·······································································································································1-3
Configuring ARP ·····································································································································1-3
Configuring a Static ARP Entry ·······································································································1-3
Configuring the Maximum Number of ARP Entries for a VLAN Interface ·······································1-4
Setting the Aging Time for Dynamic ARP Entries ···········································································1-4
Enabling the ARP Entry Check ·······································································································1-5
Enabling the Support for ARP Requests from a Natural Network···················································1-5
ARP Configuration Example············································································································1-6
Configuring Gratuitous ARP····················································································································1-7
Introduction to Gratuitous ARP········································································································1-7
Configuring Gratuitous ARP ············································································································1-7
Displaying and Maintaining ARP·············································································································1-7
2 Proxy ARP Configuration ·························································································································2-1

Proxy ARP Overview·······························································································································2-1
Enabling Proxy ARP································································································································2-1
Displaying and Maintaining Proxy ARP ··································································································2-1
Proxy ARP Configuration Examples ·······································································································2-2
Proxy ARP Configuration Example ·································································································2-2
Local Proxy ARP Configuration Example in Case of Port Isolation ················································2-3
Local Proxy ARP Configuration Example in Super VLAN·······························································2-4
Local Proxy ARP Configuration Example in Isolate-user-vlan ························································2-5
3 ARP Attack Defense Configuration ·········································································································3-1

Configuring ARP Source Suppression····································································································3-1
Introduction to ARP Source Suppression························································································3-1
Configuring ARP Source Suppression ····························································································3-1
Displaying and Maintaining ARP Source Suppression ···································································3-1
Configuring ARP Defense Against IP Packet Attack ··············································································3-2
Introduction to ARP Defense Against IP Packet Attack ··································································3-2
Enabling ARP Defense Against IP Packet Attack ···········································································3-2
Configuring ARP Detection ·····················································································································3-2
Introduction to ARP Detection ·········································································································3-2
Enabling ARP Detection Based on DHCP Snooping Security Entries············································3-2
Configuring ARP Detection Based on Specified Objects ································································3-3
Configuring ARP Packet Rate Limit ································································································3-4
Displaying and Maintaining ARP Detection·····················································································3-4
ARP Detection Configuration Example ···························································································3-4
i
1 ARP Configuration
When configuring ARP, go to these sections for information you are interested in:
z ARP Overview
z Configuring ARP
z Configuring Gratuitous ARP
z Displaying and Maintaining ARP
ARP Overview
ARP Function
The Address Resolution Protocol (ARP) is used to resolve an IP address into an Ethernet MAC address
(or physical address).
In a LAN, when a device is to send data to another device, the sending device must know the network
layer address (that is, the IP address) of the destination device. Because IP datagrams must be
encapsulated within Ethernet frames before they can be transmitted over physical networks, the
sending device also needs to know the physical address of the destination device. Therefore, a
mapping between the IP address and the physical address is needed. ARP is the protocol to implement
the mapping function.
ARP Message Format
ARP messages are classified into ARP requests and ARP replies. Figure 1-1 shows the format of the
ARP request/reply.
Figure 1-1 ARP message format
The following explains the fields in Figure 1-1.

z Hardware type: This field specifies the hardware address type. The value “1” represents Ethernet.
z Protocol type: This field specifies the type of the protocol address to be mapped. The hexadecimal
value “0x0800” represents IP.
z Hardware address length and protocol address length: They respectively specify the length of a
hardware address and a protocol address, in bytes. For an Ethernet address, the value of the
hardware address length field is "6”. For an IP(v4) address, the value of the protocol address length
field is “4”.
1-1
z OP: Operation code. This field specifies the type of ARP message. The value “1” represents an
ARP request and “2” represents an ARP reply.
z Sender hardware address: This field specifies the hardware address of the device sending the
message.
z Sender protocol address: This field specifies the protocol address of the device sending the
message.
z Target hardware address: This field specifies the hardware address of the device the message is
being sent to.
z Target protocol address: This field specifies the protocol address of the device the message is
being sent to.
ARP Address Resolution Process
Suppose that Host A and Host B are on the same subnet and Host A sends a packet to Host B, as
shown in Figure 1-2. The resolution process is as follows:
1) Host A looks in its ARP table to see whether there is an ARP entry for Host B. If yes, Host A uses
the MAC address in the entry to encapsulate the IP packet into a data link layer frame and sends
the frame to Host B.
2) If Host A finds no entry for Host B, Host A buffers the packet and broadcasts an ARP request, in
which the source IP address and source MAC address are respectively the IP address and MAC
address of Host A and the destination IP address and MAC address are respectively the IP
address of Host B and an all-zero MAC address. Because the ARP request is broadcast, all hosts
on this subnet can receive the request, but only the requested host (namely, Host B) will process
the request.
3) Host B compares its own IP address with the destination IP address in the ARP request. If they are
the same, Host B saves the source IP address and source MAC address into its ARP table,
encapsulates its MAC address into an ARP reply, and unicasts the reply to Host A.
4) After receiving the ARP reply, Host A adds the MAC address of Host B into its ARP table.
Meanwhile, Host A encapsulates the IP packet and sends it out.
Figure 1-2 ARP address resolution process
If Host A and Host B are not on the same subnet, Host A first sends an ARP request to the gateway. The
destination IP address in the ARP request is the IP address of the gateway. After obtaining the MAC
address of the gateway from an ARP reply, Host A sends the packet to the gateway. If the gateway
maintains the ARP entry of Host B, it forwards the packet to Host B directly; if not, it broadcasts an ARP
request, in which the target IP address is the IP address of Host B. After obtaining the MAC address of
Host B, the gateway sends the packet to Host B.
1-2
ARP Table
After obtaining the destination MAC address, the device adds the IP-to-MAC mapping into its own ARP
table. This mapping is used for forwarding packets with the same destination in future.
An ARP table contains ARP entries, which fall into two categories: dynamic and static.
Dynamic ARP entry
A dynamic entry is automatically created and maintained by ARP. It can get aged, be updated by a new
ARP packet, or be overwritten by a static ARP entry. When the aging timer expires or the port goes
down, the corresponding dynamic ARP entry will be removed.
Static ARP entry
A static ARP entry is manually configured and maintained. It cannot get aged or be overwritten by a
dynamic ARP entry.
Using static ARP entries enhances communication security. After a static ARP entry is specified, only a
specific MAC address is associated with the specified IP address. Attack packets cannot modify the
IP-to-MAC mapping. Thus, communications between devices are protected.
Static ARP entries can be classified into permanent or non-permanent.
z A permanent static ARP entry can be directly used to forward packets. When configuring a
permanent static ARP entry, you must configure a VLAN and outbound port for the entry besides
the IP address and MAC address.
z A non-permanent static ARP entry cannot be directly used for forwarding data. When configuring a
non-permanent static ARP entry, you only need to configure the IP address and MAC address.
When forwarding IP packets, the device sends an ARP request. If the source IP and MAC
addresses in the received ARP reply are the same as the configured IP and MAC addresses, the
device adds the port receiving the ARP reply into the static ARP entry. Now the entry can be used
for forwarding IP packets.
z Usually ARP dynamically resolves IP addresses to MAC addresses, without manual intervention.
z To allow communication with a device using a fixed IP-to-MAC mapping, configure a short static
ARP entry for it. To allow communication with a device through a specific interface in a specific
VLAN and using a fixed IP-to-MAC mapping, configure a long static ARP entry for it.
Configuring ARP
Configuring a Static ARP Entry
A static ARP entry is effective when the device works normally. However, when a VLAN or VLAN
interface to which a static ARP entry corresponds is deleted, the entry, if permanent, will be deleted, and
if non-permanent and resolved, will become unresolved.
1-3
Follow these steps to configure a static ARP entry:

arp static ip-address mac-address Required

Configure a
vlan-id interface-type
permanent static No permanent static ARP entry is
interface-number [ vpn-instance
ARP entry configured by default.
vpn-instance-name ]
Configure a arp static ip-address mac-address Required

non-permanent [ vpn-instance No non-permanent static ARP entry
static ARP entry vpn-instance-name ] is configured by default.
z The vlan-id argument must be the ID of an existing VLAN which corresponds to the ARP entries. In
addition, the Ethernet interface following the argument must belong to that VLAN. A VLAN interface
must be created for the VLAN.
z The IP address of the VLAN interface corresponding to the vlan-id argument must belong to the
same network segment as the IP address specified by the ip-address argument.
Configuring the Maximum Number of ARP Entries for a VLAN Interface
Follow these steps to set the maximum number of dynamic ARP entries that a VLAN interface can
learn:

Enter VLAN interface view interface Vlan-interface vlan-id —
Set the maximum number of Optional
dynamic ARP entries that a arp max-learning-num number
VLAN interface can learn 8192 by default.
Setting the Aging Time for Dynamic ARP Entries
To keep pace with the network changes, the ARP table is refreshed. Each dynamic ARP entry in the
ARP table has a limited lifetime rather than is always valid. Dynamic ARP entries that are not refreshed
before expiration are deleted from the ARP table. The lifetime is called the aging time. The aging time is
reset each time the dynamic ARP entry is used within the lifetime. You can adjust the aging time for
dynamic ARP entries according to the actual network condition.
1-4
Follow these steps to set aging time for dynamic ARP entries:

Set aging time for dynamic Optional

arp timer aging aging-time
ARP entries 20 minutes by default.
Enabling the ARP Entry Check
The ARP entry check function disables the device from learning multicast MAC addresses. With the
ARP entry check enabled, the device cannot learn any ARP entry with a multicast MAC address, and
configuring such a static ARP entry is not allowed; otherwise, the system displays error messages.
After the ARP entry check is disabled, the device can learn the ARP entry with a multicast MAC address,
and you can also configure such a static ARP entry on the device.
Follow these steps to enable the ARP entry check:

Enable the ARP entry Optional

arp check enable
check Enabled by default.
Currently, enabling ARP entry check on an S7500E series Ethernet switch will disallow configuration of
static ARP entries with multicast MAC addresses; dynamic ARP entries with multicast MAC addresses
can never be learned.
Enabling the Support for ARP Requests from a Natural Network
When learning MAC addresses, if the device finds that the source IP address of an ARP packet and the
IP address of the inbound interface are not on the same subnet, the device will further judge whether
these two IP addresses are on the same natural network.
Suppose that the IP address of VLAN-interface 10 is 10.10.10.5/24 and that this interface receives an
ARP packet from 10.11.11.1/8. Because these two IP addresses are not on the same subnet,
VLAN-interface 10 cannot process the packet. With this feature enabled, the device will make a
judgment on natural network basis. Because the IP address of VLAN-interface 10 is a Class A address
and its default mask length is 8, these two IP addresses are on the same natural network. In this way,
VLAN-interface 10 can learn the MAC address of the source IP address 10.11.11.1.
1-5
Follow these steps to enable the support for ARP requests from a natural network:

Enable the support for ARP Required

naturemask-arp enable
requests from a natural network Disabled by default.
ARP Configuration Example
As shown in Figure 1-3, hosts are connected to Switch, which is connected to Router through interface
GigabitEthernet 2/0/1 belonging to VLAN 10. The IP address of Router is 192.168.1.1/24. The MAC
address of Router is 00e0-fc01-0000.
To enhance security of communications between each host and Switch, static ARP entries are
configured on Switch.
Figure 1-3 Network diagram for configuring static ARP entries
Configure Switch
# Create VLAN 10.
<Switch> system-view
[Switch] vlan 10
[Switch-vlan10] quit
# Add interfcace GigabitEthernet2/0/1 to VLAN 10.

[Switch] interface GigabitEthernet2/0/1
[Switch-GigabitEthernet2/0/1] port access vlan 10
[Switch-GigabitEthernet2/0/1] quit
# Create interface VLAN-interace 10 and configure its IP address.

[Switch] interface vlan-interface 10
[Switch-vlan-interface10] ip address 192.168.1.2 8
[Switch-vlan-interface10] quit
1-6
# Configure a static ARP entry with IP address 192.168.1.1 and MAC address 00e0-fc01-0000. The
outgoing interface corresponding to the static ARP entry is GigabitEthernet2/0/1 belonging to VLAN 10.
[Switch] arp static 192.168.1.1 00e0-fc01-0000 10 GigabitEthernet2/0/1
# View information about static ARP entries.

[Switch] display arp static
Type: S-Static D-Dynamic
IP Address MAC Address VLAN ID Interface Aging Type
192.168.1.1 00e0-fc01-0000 10 GE2/0/1 N/A S
Configuring Gratuitous ARP

Introduction to Gratuitous ARP
A gratuitous ARP packet is a special ARP packet, in which the source IP address and destination IP
address are both the IP address of the sender, the source MAC address is the MAC address of the
sender, and the destination MAC address is a broadcast address.
A device can implement the following functions by sending gratuitous ARP packets:
z Determining whether its IP address is already used by another device.
z Informing other devices of its MAC address change so that they can update their ARP entries.
A device receiving a gratuitous ARP packet can add the information carried in the packet to its own
dynamic ARP table if it finds no corresponding ARP entry for the ARP packet in the cache.
Configuring Gratuitous ARP
Follow these steps to configure gratuitous ARP:

Required
Enable the device to send
gratuitous ARP packets when gratuitous-arp-sending By default, a device cannot
receiving ARP requests from enable send gratuitous ARP packets
another network segment when receiving ARP requests
from another network segment.
Enable the gratuitous ARP gratuitous-arp-learning Optional

packet learning function enable Enabled by default.
Displaying and Maintaining ARP

display arp [ [ all | dynamic | static ]
[ slot slot-id ] | vlan vlan-id | interface
Display the ARP entries in the
interface-type interface-number ] Available in any view
ARP mapping table
[ [ verbose ] [ | { begin | exclude |
include } string ] | count ]
display arp ip-address [ slot slot-id ]
Display the ARP entries for a
[ verbose ] [ | { begin | exclude | Available in any view
specified IP address
include } string ]
1-7
Display the aging time for
display arp timer aging Available in any view
dynamic ARP entries
Display the configuration
information of ARP source display arp source-suppression Available in any view
suppression
display arp vpn-instance
Display the ARP entries for a
vpn-instance-name [ | { begin | exclude | Available in any view
specified VPN instance
include } string | count ]
reset arp { all | dynamic | static | slot
Clear ARP entries from the
slot-id | interface interface-type Available in user view
ARP mapping table
interface-number }
Executing the reset arp slot slot-id or the reset arp interface interface-type interface-number
command only removes dynamic ARP entries of the specified slot or port. To remove specified static
ARP entries, you need to use the undo arp ip-address command.
1-8
2 Proxy ARP Configuration
When configuring proxy ARP, go to these sections for information you are interested in:
z Proxy ARP Overview
z Enabling Proxy ARP
z Displaying and Maintaining Proxy ARP
Proxy ARP Overview

If a host sends an ARP request for the MAC address of another host that resides in another subnet or is
isolated from the sending host at layer 2, the device in between must be able to respond to the request
to allow Layer 3 communication between the two hosts (in this case, the sending host considers the
requested host is on the same subnet). This is achieved by proxy ARP.
Proxy ARP involves proxy ARP and local proxy ARP.
In one of the following cases, you need to enable local proxy ARP:
z Hosts connected to different isolated layer 2 ports in the same VLAN need to communicate at
Layer 3.
z If a super VLAN is configured, hosts in different sub VLANs of the super VLAN need to
communicate at Layer 3.
z If an isolate-user-vlan is configured, devices in different secondary VLANs of the isolate-user-vlan
need to communicate at layer 3.
Enabling Proxy ARP

Follow these steps to enable proxy ARP in VLAN interface view/Ethernet interface view or enable local
proxy ARP in VLAN interface view:

interface Vlan-interface
Enter VLAN interface view Required
vlan-id
Required
Enable proxy ARP proxy-arp enable
Disabled by default.
Required
Enable local proxy ARP local-proxy-arp enable
Disabled by default.
Displaying and Maintaining Proxy ARP

Display whether proxy ARP is display proxy-arp [ interface
enabled Vlan-interface vlan-id ]
2-1
Display whether local proxy display local-proxy-arp [ interface
ARP is enabled Vlan-interface vlan-id ]
Proxy ARP Configuration Examples

Proxy ARP Configuration Example
Host A and Host D have IP addresses of the same network segment. Host A belongs to VLAN 1, and
Host D belongs to VLAN 2. Configure proxy ARP on the device to enable the communication between
the two hosts.
Network diagram
Figure 2-1 Network diagram for proxy ARP
# Configure Proxy ARP on the device to enable the communication between Host A and Host D.
[Switch-Vlan-interface1] ip address 192.168.10.99 255.255.255.0
[Switch-Vlan-interface1] proxy-arp enable
[Switch-Vlan-interface1] quit
[Switch] vlan 2
[Switch-vlan2] quit
[Switch-Vlan-interface2] proxy-arp enable
2-2
Local Proxy ARP Configuration Example in Case of Port Isolation
z Host A and Host B belong to the same VLAN, and are connected to GigabitEthernet 2/0/2 and
GigabitEthernet 2/0/3 of Switch B respectively.
z Switch B is connected to Switch A via GigabitEthernet 2/0/1.
z On Switch B, port isolation are configured on GigabitEthernet 2/0/2 and GigabitEthernet 2/0/3.
Enable local proxy ARP on Switch A to allow communication between Host A and Host B.
Network diagram
Figure 2-2 Network diagram for local proxy ARP between isolated ports
SwitchA
GE2/0/2
VLAN 2
Vlan-int2
192.168.10.100/16
GE2/0/1
GE2/0/2 GE2/0/3
Host A SwitchB Host B

192.168.10.99/16 192.168.10.200/16
1) Configure Switch B
# Create VLAN 2 on Switch B, on which GigabitEthernet 2/0/1, GigabitEthernet 2/0/2 and
GigabitEthernet 2/0/3 belong to VLAN 2. Host A and Host B are isolated and unable to exchange Layer
2 packets.
<SwitchB> system-view
[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 2/0/1
[SwitchB-vlan2] quit
[SwitchB] interface gigabitethernet 2/0/2
[SwitchB-GigabitEthernet2/0/2] port-isolate enable
[SwitchB-GigabitEthernet2/0/2] quit
[SwitchB-GigabitEthernet2/0/3] port-isolate enable
2) Configure Switch A
# Configure an IP address of VLAN-interface 2.
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 2/0/2
[SwitchA-vlan2] quit
2-3
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.10.100 255.255.0.0
Ping Host B on Host A to verify that the two hosts cannot be pinged through, which indicates they are
isolated at Layer 2.
# Configure local proxy ARP to let Host A and Host B communicate at Layer 3.
[SwitchA-Vlan-interface2] local-proxy-arp enable
[SwitchA-Vlan-interface2] quit
Ping Host B on Host A to verify that the two hosts can be pinged through, which indicates Layer 3
communication is implemented.
Local Proxy ARP Configuration Example in Super VLAN
z A super VLAN, VLAN 10, is created, with the interface IP address being 192.168.10.100/16.
z Sub-VLANs (VLAN 2 and VLAN 3) are created.
z GigabitEthernet2/0/2 belongs to VLAN 2 and GigabitEthernet2/0/3 belongs to VLAN 3.
z Layer 3 communication is implemented between the sub-VLANs.
Network diagram
Figure 2-3 Network diagram for local proxy ARP in super VLAN
# Create the super VLAN and the sub-VLANs. Add GigabitEthernet 2/0/2 1/2 to VLAN 2 and
GigabitEthernet 2/0/3 to VLAN 3. Configure the IP address 192.168.10.100/16 for the interface of VLAN
10.
[Switch] vlan 2
[Switch-vlan2] port gigabitethernet 2/0/2
[Switch-vlan2] quit
[Switch] vlan 3
[Switch-vlan3] port gigabitethernet 2/0/3
[Switch-vlan3] quit
[Switch] vlan 10
[Switch-vlan10] supervlan
[Switch-vlan10] subvlan 2 3
2-4
[Switch-vlan10] interface vlan-interface 10
Ping Host B on Host A to verify that the two hosts are not reachable to each other, which indicates they
are isolated at Layer 2.
# Configure the local proxy ARP to implement Layer 3 communication between sub-VLANs.
[Switch-Vlan-interface10] local-proxy-arp enable
Ping Host B on Host A to verify that the two hosts are reachable to each other, which indicates Layer 3
Local Proxy ARP Configuration Example in Isolate-user-vlan
z Switch A is attached to Switch B through GigabitEthernet 2/0/1.

z VLAN 5 on Switch B is an isolate-user-vlan, which includes uplink port GigabitEthernet 2/0/1 and
two secondary VLANs (VLAN 2 and VLAN 3). GigabitEthernet 2/0/2 belongs to VLAN 2, and
GigabitEthernet 2/0/3 belongs to VLAN 3.
z Configure local proxy ARP on Switch A to implement Layer 3 communication between VLAN 2 and
VLAN 3.
Network diagram
Figure 2-4 Network diagram for local proxy ARP configuration in isolate-user-vlan
1) Configure the Switch B

# Create VLAN 2, VLAN 3, and VLAN 5 on Switch B. Add GigabitEthernet2/0/2 to VLAN 2,
GigabitEthernet 2/0/3 to VLAN 3, and GigabitEthernet 2/0/1 to VLAN 5. Configure VLAN 5 as the
isolate-user-vlan, and VLAN 2 and VLAN 3 as secondary VLANs. Configure the mappings between
isolate-user-vlan and the secondary VLANs.
2-5
[SwitchB] vlan 2
[SwitchB] vlan 3
[SwitchB] vlan 5
[SwitchB-vlan5] isolate-user-vlan enable
[SwitchB] isolate-user-vlan 5 secondary 2 3
# Create VLAN 5 and add GigabitEthernet2/0/1 to it.
<SwitchA> system-view
[SwitchA] vlan 5
[SwitchA-vlan5] interface vlan-interface 5
Ping Host B on Host A to verify that the two hosts are not reachable to each other, which indicates they
are isolated at Layer 2.
# Configure local proxy ARP to implement communication between VLAN 2 and VLAN 3.
[SwitchA-Vlan-interface5] local-proxy-arp enable
Ping Host B on Host A to verify that the two hosts are reachable to each other, which indicates Layer 3
2-6
3 ARP Attack Defense Configuration
When configuring ARP attack defense, go to these sections for information you are interested in:
z Configuring ARP Source Suppression
z Configuring ARP Defense Against IP Packet Attack
z Configuring ARP Detection
Configuring ARP Source Suppression

Introduction to ARP Source Suppression
If a device receives large numbers of IP packets from a host to unreachable destinations,

z The device sends large numbers of ARP requests to the destination subnets, which increases the
load of the destination subnets.
z The device continuously resolves destination IP addresses, which increase the load of the CPU.
To protect the device from such attacks, you can enable the ARP source suppression function. With the
function enabled, whenever the number of packets with unresolvable destination IP addresses from a
host within five seconds exceeds a specified threshold, the device suppress the sending host from
triggering any ARP requests within the following five seconds.
Configuring ARP Source Suppression
Follow these steps to configure ARP source suppression:

arp source-suppression Required

Enable ARP source suppression
enable Disabled by default.
Set the maximum number of packets
with the same source IP address but Optional
arp source-suppression limit
unresolvable destination IP
limit-value 10 by default.
addresses that the device can
receive in five consecutive seconds
Displaying and Maintaining ARP Source Suppression

Display the ARP source suppression display arp
configuration information source-suppression
3-1
Configuring ARP Defense Against IP Packet Attack
Introduction to ARP Defense Against IP Packet Attack
When forwarding an IP packet, a device depends on ARP to resolve the MAC address of the next hop.
If the address resolution is successful, the forwarding chip forwards the packet directly. Otherwise, the
device runs software for further processing. If the device cannot resolve the next hops for large
numbers of incoming packets, the CPU of the device will be exhausted. This is called IP packet attacks.
To protect a device against IP packet attacks, you can enable the ARP defense against IP packet attack
function. After receiving an IP packet whose next hop cannot be resolved by ARP, a device with this
function enabled creates a black hole route immediately and the forwarding chip simply drops all
packets matching the next hop during the age time of the black hole route.
Enabling ARP Defense Against IP Packet Attack
The ARP defense against IP packet attack function applies to packets to be forwarded and those
originated by the device.
Follow these steps to configure ARP defense against IP packet attack:

Enable ARP defense against IP Optional

arp resolving-route enable
packet attack Enabled by default.
Configuring ARP Detection

Introduction to ARP Detection
In normal cases, a Layer 2 access device broadcasts an ARP request within a VLAN, and forwards ARP
responses at Layer 2. If an attacker sends an ARP request with the source being the IP address of
another client, the corresponding ARP entry maintained by the gateway or other clients is modified.
Consequently, the attacker will receive the packets sent to the client.
The ARP detection feature allows only the ARP packets of legal clients to be forwarded.
Enabling ARP Detection Based on DHCP Snooping Security Entries
With this feature enabled, the device matches the source IP and MAC addresses of an ARP packet
received from the VLAN to the DHCP snooping security entries. If a match is found, the packet is
forwarded; if not, it is discarded.
You can set a port in the VLAN as trusted or untrusted. ARP packets received on a trusted port will be
forwarded directly, while ARP packets received on an untrusted port will be checked.
Before performing this configuration, make sure DHCP snooping is enabled. Refer to DHCP
Configuration in the IP Services Volume for how to enable DHCP snooping.
3-2
Follow these steps to enable ARP detection for a VLAN and specify a trusted port:

Enter VLAN view vlan vlan-id —

Required
Enable ARP detection arp detection enable Disabled by default. That is, the ARP
packets received on all the ports in the
VLAN will not be checked.
interface-number
Configure the port as a Optional

arp detection trust
trusted port The port is an untrusted port by default.
Configuring ARP Detection Based on Specified Objects
You can also specify objects in ARP packets to be detected. The objects involve:
z src-mac: Checks whether the sender MAC address of an ARP packet is identical to the source
MAC address in the Ethernet header. If they are identical, the packet is forwarded; otherwise, the
packet is discarded.
z dst-mac: Checks the target MAC address of ARP responses. If the target MAC address is all-zero,
all-F, or inconsistent with the destination MAC address in the Ethernet header, the packet is
considered invalid and discarded.
z ip: Checks both the source and destination IP addresses in an ARP packet. The all-zero, all-F or
multicast IP addresses are considered invalid and the corresponding packets are discarded. With
this object specified, the source IP address of both ARP requests and responses will be checked,
and destination IP address of ARP responses will be checked.
Before performing the following configuration, make sure you have configured the arp detection
enable command.
Follow these steps to configure ARP detection based on specified objects:

Required
Specify objects for ARP arp detection validate { dst-mac By default, the checking of the
detection | ip | src-mac } * MAC addresses and IP addresses
of ARP packets is disabled.
If both the ARP detection based on specified objects and the ARP detection based on snooping security
entries are enabled, the former one applies first, and then the latter applies.
3-3
Configuring ARP Packet Rate Limit
ARP packets that pass ARP detection are delivered to the CPU. This feature allows you to limit the rate
of ARP packets to be sent to the CPU.
Before performing the following configuration, make sure you have configured the arp detection
enable command.
Follow these steps to configure ARP packet rate limit:

interface-number
Required
arp rate-limit { disable | rate pps
Configure ARP packet rate limit ARP packet rate limit is
drop }
enabled by default.
Displaying and Maintaining ARP Detection

Display the VLANs enabled with
display arp detection
ARP detection
Available in any
display arp detection statistics view
Display the ARP detection
[ interface interface-type
statistics
interface-number ]
Clear the ARP detection reset arp detection statistics [ interface Available in user
statistics interface-type interface-number ] view
ARP Detection Configuration Example
z Configure Switch A as a DHCP server and enable DHCP snooping on Switch B. Enable ARP
detection for VLAN 10 to allow only packets from valid clients to pass.
z Configure Host A and Host B as DHCP clients.
3-4
Network diagram
Figure 3-1 Network diagram for ARP detection configuration
DHCP server
Switch A
Vlan-int10
10.1.1.1/24
VLAN10
DHCP snooping GE2/0/1
Switch B
GE2/0/2 GE2/0/3
DHCP client DHCP client

Host A Host B
1) Add all the ports on Switch B into VLAN 10, and configure the IP address of VLAN-interface 10 on
Switch A (the configuration procedure is omitted).
2) Configure Switch A as a DHCP server
[SwitchA] dhcp enable
[SwitchA] dhcp server ip-pool 0
[SwitchA-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0
[SwitchA-dhcp-pool-0] quit
3) Configure Host A and Host B as DHCP clients (the configuration procedure is omitted).
# Enable DHCP snooping.
[SwitchB] dhcp-snooping
[SwitchB-GigabitEthernet2/0/1] dhcp-snooping trust
# Enable ARP detection for VLAN 10. Configure the upstream port as a trusted port and the
downstream ports as untrusted ports (a port is an untrusted port by default).
[SwitchB] vlan 10
[SwitchB-vlan10] arp detection enable
[SwitchB-vlan10] interface gigabitethernet 2/0/1
[SwitchB-GigabitEthernet2/0/1] arp detection trust
# Enable the checking of the MAC addresses and IP addresses of ARP packets.
[SwitchB] arp detection validate dst-mac ip src-mac
# Specify the ARP packet rate on GigabitEthernet2/0/2 and GigabitEthernet2/0/3 as 150 pps.
[SwitchB] interface GigabitEthernet2/0/2
3-5
Table of Contents
1 VRRP Configuration ··································································································································1-1

Introduction to VRRP ······························································································································1-1
VRRP Overview·······························································································································1-1
VRRP Group Overview····················································································································1-2
VRRP Timers···································································································································1-4
Format of VRRP Packets ················································································································1-4
Principles of VRRP ··························································································································1-6
VRRP Tracking································································································································1-6
VRRP Application (Taking IPv4-Based VRRP for Example)···························································1-6
Configuring VRRP for IPv4 ·····················································································································1-8
VRRP for IPv4 Configuration Task List ···························································································1-8
Configuring a VRRP Group to Respond to Ping Packets Destined for Its Virtual IP Address ········1-8
Configuring the Association Between Virtual IP Address and MAC Address ·································1-9
Creating VRRP Group and Configuring Virtual IP Address ····························································1-9
Configuring Router Priority, Preemptive Mode and Tracking Function·········································1-11
Configuring VRRP Packet Attributes·····························································································1-12
Enabling the Trap Function of VRRP ····························································································1-13
Displaying and Maintaining VRRP for IPv4 ···················································································1-14
Configuring VRRP for IPv6 ···················································································································1-14
VRRP for IPv6 Configuration Task List ·························································································1-14
Configuring a VRRP Group to Respond to Ping Packets Destined for the Virtual IPv6 Address ·······1-14
Configuring the Association Between Virtual IPv6 Address and MAC Address ···························1-15
Creating VRRP Group and Configuring Virtual IPv6 Address·······················································1-15
Configuring Router Priority, Preemptive Mode and Interface Tracking·········································1-17
Configuring VRRP Packet Attributes·····························································································1-17
Displaying and Maintaining VRRP for IPv6 ···················································································1-18
IPv4-Based VRRP Configuration Examples ·························································································1-18
Single VRRP Group Configuration Example ·················································································1-18
VRRP Interface Tracking Configuration Example ·········································································1-21
Multiple VRRP Group Configuration Example ··············································································1-24
IPv6-Based VRRP Configuration Examples ·························································································1-26
Single VRRP Group Configuration Example ·················································································1-26
VRRP Interface Tracking Configuration Example ·········································································1-29
Multiple VRRP Group Configuration Example ··············································································1-33
Troubleshooting VRRP ·························································································································1-36
i
1 VRRP Configuration
When configuring VRRP, go to these sections for information you are interested in:
z Introduction to VRRP
z Configuring VRRP for IPv4
z Configuring VRRP for IPv6
z IPv4-Based VRRP Configuration Examples
z IPv6-Based VRRP Configuration Examples
z Troubleshooting VRRP
z The term switch in this document refers to a switch in a generic sense or a Layer 3 switch.
z At present, the interfaces that VRRP involves can only be VLAN interfaces unless otherwise
specified.
Introduction to VRRP
VRRP Overview
Normally, as shown in Figure 1-1, you can configure a default route with the gateway as the next hop for
every host on a network segment, allowing all packets destined to other network segments to be sent
over the default route to the gateway and then be forwarded by the gateway. This enables hosts on a
network segment to communicate with external networks. However, when the gateway fails, all the
hosts using the gateway as the default next-hop switch fail to communicate with the external network.
Figure 1-1 LAN networking
Host A
Network
Host B Gateway
Host C
1-1
Apparently, this approach to enabling hosts on a network to communicate with external networks is
easy to configure, but it imposes a very high requirement of performance stability on the device acting
as the gateway. A common way to improve system reliability is to use more egress gateways,
introducing the problem of routing among the multiple egresses.
Virtual Router Redundancy Protocol (VRRP) is designed to address this problem. VRRP can add
switches that can act as network gateways to a VRRP group, forming a virtual router. Switches in the
VRRP group elect a master through the VRRP election mechanism to take the responsibility of a
gateway, and hosts on a LAN only need to configure the virtual router as their default network gateway.
VRRP is an error-tolerant protocol, which improves the network reliability and simplifies configurations
on hosts. Deploying VRRP on multicast and broadcast LANs such as Ethernet, you can ensure that the
system can still provide highly reliable default links without changing configurations (such as dynamic
routing protocols, route discovery protocols) when a device fails, and prevent network interruption due
to a single link failure.
There are two VRRP versions: VRRPv2 and VRRPv3. VRRPv2 is based on IPv4, while VRRPv3 is
based on IPv6. The two versions implement the same functions but provide different commands.
VRRP Group Overview
VRRP combines a group of switches (including a master and multiple backups) on a LAN into a virtual
router called VRRP group.
A VRRP group has the following features:
z A virtual router has an 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.
z Every host on the LAN communicates with external networks through the virtual router.
z Switches in the VRRP group elect the gateway according to their priorities. Once the master acting
as the gateway fails, the other switches in the VRRP group elect a new gateway to undertake the
responsibility of the failed switch, thus ensuring that the hosts in the network segment can
communicate with the external networks uninterruptedly.
Figure 1-2 Network diagram for VRRP
Virtual router
Switch A
Host A
Switch B
Network
Host B
Switch C
Host C
As shown in Figure 1-2, Switch A, Switch B, and Switch C form a virtual router, which has its own IP
address. Hosts on the Ethernet use the virtual router as the default gateway.
1-2
The switch with the highest priority of the three switches is elected as the master to act as the gateway,
and the other two are backups.
z 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 switch in the VRRP group. In the latter
case, the switch is called the IP address owner.
z In a VRRP group, there can only be one IP address owner.
VRRP priority
VRRP determines the role (master or backup) of each switch in the VRRP group by priority. A switch
with a higher priority has more opportunity to become the master.
VRRP priority is in the range of 0 to 255. A bigger number means a higher priority. Priorities 1 to 254 are
configurable. Priority 0 is reserved for special uses and priority 255 for the IP address owner. When a
switch acts as the IP address owner, its priority is always 255. That is, if there is an IP address owner in
a VRRP group, it acts as the master as long as it works properly.
Working mode
A switch in a VRRP group can work in one of the following two modes:
z Non-preemptive mode
Once a switch in the VRRP group becomes the master, it stays as the master as long as it operates
normally, even if a backup is assigned a higher priority later.
z Preemptive mode
Once a backup finds its priority higher than that of the switch acting as the master, it sends VRRP
advertisements to start a new master election in the VRRP group and becomes the master. Accordingly,
the original master becomes a backup.
Authentication mode
VRRP provides two authentication modes:

z simple: Simple text authentication
You can adopt the simple text authentication mode in a network facing possible security problems. A
switch sending a packet fills an authentication key into the packet, and the switch receiving the packet
compares its local authentication key with that of the received packet. If the two authentication keys are
the same, the received VRRP packet is considered real and valid; otherwise, the received packet is
considered an invalid one.
z md5: MD5 authentication
You can adopt MD5 authentication in a network facing severe security problems. The switch encrypts a
packet to be sent using the authentication key and MD5 algorithm and saves the encrypted packet in
the authentication header. The switch receiving the packet uses the authentication key to decrypt the
packet and checks whether the packet is valid.
On a secure network, you need not set the authentication mode.
1-3
VRRP Timers
VRRP timers include VRRP advertisement interval timer and VRRP preemption delay timer.
VRRP advertisement interval timer
The master in a VRRP group sends VRRP advertisements periodically to inform the other switches in
the VRRP group that it operates properly.
You can adjust the interval of sending VRRP advertisements by setting the VRRP advertisement
interval timer. 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 members in a VRRP group from changing their states frequently and make backups have
enough time to collect information (such as routing information), each backup waits for a period of time
(the preemption delay time) after it receives an advertisement with the priority lower than the local
priority, then sends VRRP advertisements to start a new master election in the VRRP group and finally
becomes the master.
Format of VRRP Packets
VRRP uses multicast packets. The switch acting as the master sends VRRP packets periodically to
declare its existence. VRRP packets are also used for checking the parameters of the virtual router and
electing the master.
IPv4-based VRRP packet format
Figure 1-3 IPv4-based VRRP packet format

...
As shown in Figure 1-3, an IPv4-based VRRP packet consists of the following fields:
z Version: Version number of the protocol, 2 for VRRPv2.
z Type: Type of the VRRP packet. Only one VRRP packet type is present, that is, VRRP
advertisement, which is represented by 1.
z Virtual Rtr ID (VRID): Serial number of the virtual router, that is, serial number of the VRRP group.
It ranges from 1 to 255.
z Priority: Priority of the switch in the VRRP group, in the range 0 to 255. A greater value represents
a higher priority.
z Count IP Addrs: Number of virtual IP addresses for the VRRP group. A VRRP group can have
multiple virtual IP addresses.
1-4
z Auth Type: Authentication type. 0 means no authentication, 1 means simple text authentication,
and 2 means MD5 authentication.
z Adver Int: Interval for sending advertisement packets, in seconds. The default is 1.
z Checksum: 16-bit checksum for validating the data in VRRP packets.
z IP Address: Virtual IP address entry of the VRRP group. The allowed number is given by the Count
IP Addrs field.
z Authentication Data: Authentication key. Currently, this field is used only for simple authentication
and is 0 for any other authentication modes.
IPv6-based VRRP packet format
Figure 1-4 IPv6-based VRRP packet format
0 3 7 15 23 31
Version Type Virtual Rtr ID Priority Count IPv6 Addrs
Auth Type Adver Int Checksum
IPv6 address 1
...
IPv6 address n
Authentication data 1
Authentication data 2
As shown in Figure 1-4, an IPv6-based VRRP packet consists of the following fields:
z Version: Version number of the protocol, 3 for VRRPv3.
z Type: Type of the VRRP packet. Only one VRRP packet type is present, that is, VRRP
advertisement, which is represented by 1.
z Virtual Rtr ID (VRID): Serial number of the virtual router, that is, serial number of the VRRP group.
It ranges from 1 to 255.
z Priority: Priority of the switch in the VRRP group, in the range 0 to 255. A greater value represents
a higher priority.
z Count IPv6 Addrs: Number of virtual IPv6 addresses for the VRRP group. A VRRP group can have
multiple virtual IPv6 addresses.
z Auth Type: Authentication type. 0 means no authentication, and 1 means simple authentication.
VRRPv3 does not support MD5 authentication.
z Adver Int: Interval for sending advertisement packets, in centiseconds. The default is 100.
z Checksum: 16-bit checksum for validating the data in VRRPv3 packets.
z IPv6 Address: Virtual IPv6 address entry of the VRRP group. The allowed number is given by the
Count IPv6 Addrs field.
z Authentication Data: Authentication key. Currently, this field is used only for simple authentication
and is 0 for any other authentication modes.
1-5
Principles of VRRP
z With VRRP enabled, the switches determine their respective roles in the VRRP group by priority.
The switch with the highest priority becomes the master, while the others are the backups. The
master sends VRRP advertisement packets periodically to notify the backups that it is working
properly, and each of the backups starts a timer to wait for advertisement packets from the master.
z In preemptive mode, when a backup receives a VRRP advertisement packet, it compares the
priority in the packet with that of its own. If its priority is higher, it becomes the master; otherwise, it
remains a backup.
z In non-preemptive mode, the switch in the VRRP group remains as a master or backup as long as
the master does not fail. The backup will not become the master even if the former is configured
with a higher priority.
z If the timer of a backup expires but the backup still does not receive any VRRP advertisement
packet, it considers that the master fails. In this case, the backup considers itself as the master and
sends VRRP advertisements to start a new master election.
VRRP Tracking
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 on the switch
become unavailable. When a monitored interface goes down, the priority of the switch owning the
interface is automatically decreased by a specified value, allowing a higher priority switch in the VRRP
group to become the master.
Tracking a Track object
By monitoring a Track object, you can:

z Monitor the upper link. If there is a fault on the upper link, hosts in the LAN cannot access the
external network through the switch. In this case, the state of the monitored Track object changes
to negative, and the priority of the switch decreases by a specified value, allowing a higher priority
switch in the VRRP group to become the master to maintain the proper communication between
the hosts in the LAN and the external network.
z Monitor the master on a backup. If there is a fault on the master, the backup working in the
switchover mode will switch to the master immediately to maintain normal communication.
For details of Track object tracking, refer to Track Configuration in the System Volume.
VRRP Application (Taking IPv4-Based VRRP for Example)
Master/backup
In master/backup mode, only one switch, the master, provides services. When the master fails, a new
master is elected from the original backups. This mode requires only one VRRP group, in which each
1-6
switch holds a different priority and the one with the highest priority becomes the master, as shown in
Figure 1-5.
Figure 1-5 VRRP in master/backup mode
At the beginning, Switch A is the master and therefore can forward packets to external networks, while
Switch B and Switch C are backups and are thus in the state of listening. If Switch A fails, Switch B and
Switch C will elect for a new master. The new master takes over the forwarding task to provide services
to hosts on the LAN.
Load balancing
You can create more than one VRRP group on an interface of a switch, allowing the switch to be the
master of one VRRP group but a backup of another at the same time.
In load balancing mode, multiple switches provide services at the same time. This mode requires two or
more VRRP groups, each of which includes a master and one or more backups. The masters of the
VRRP groups can be assumed by different switches, as shown in Figure 1-6.
Figure 1-6 VRRP in load balancing mode
Virtual router 1 Virtual router 2 Virtual router 3
Switch A
Backup
Master Backup
Host A
Switch B
Backup
Backup Master
Network
Host B
Switch C
Master
Backup Backup
Host C
A switch can be in multiple VRRP groups and hold a different priority in different group.
1-7
In Figure 1-6, three VRRP groups are present:
z VRRP group 1: Switch A is the master; Switch B and Switch C are the backups.
z VRRP group 2: Switch B is the master; Switch A and Switch C are the backups.
z VRRP group 3: Switch C is the master; Switch A and Switch B are the backups.
For load balancing among Switch A, Switch B, and Switch C, hosts on the LAN need to be configured to
use VRRP group 1, 2, and 3 as the default gateways respectively. When configuring VRRP priorities,
make sure that each switch holds such a priority in each VRRP group that it will take the expected role
in the group.
Configuring VRRP for IPv4

VRRP for IPv4 Configuration Task List
Complete these tasks to configure VRRP for IPv4:
Task Remarks
Configuring a VRRP Group to Respond to Ping Packets Destined for Its Virtual
Optional
IP Address
Configuring the Association Between Virtual IP Address and MAC Address Optional
Creating VRRP Group and Configuring Virtual IP Address Required
Configuring Router Priority, Preemptive Mode and Tracking Function Optional
Configuring VRRP Packet Attributes Optional
Enabling the Trap Function of VRRP Optional
Configuring a VRRP Group to Respond to Ping Packets Destined for Its Virtual IP
Address
You can configure that the master of a VRRP group responds to the received ICMP echo requests, that
is, the virtual IP address of the VRRP group can be successfully pinged.
Follow these steps to configure a VRRP group to respond to ping packets destined for the virtual IP
address:

Optional
Configure a VRRP group to
respond to ping packets By default, a VRRP group
vrrp ping-enable responds to ping packets
destined for its virtual IP
address destined for its virtual IP
address.
Configure this function before creating a VRRP group. Otherwise, your configuration will fail.
1-8
Configuring the Association Between Virtual IP Address and MAC Address
After the virtual IP address of a VRRP group is associated with a MAC address, the master takes the
configured MAC address as the source MAC address of the packets to be sent, so that the hosts in the
internal network can learn the association between the IP address and the MAC address and thus
forward the packets to be forwarded to the other network segments to the master.
There are two types of association between virtual IP address and MAC address:
z Virtual IP address is associated with virtual router MAC address
By default, a MAC address is created for a VRRP group after the VRRP group is created, and the virtual
IP address is associated with the virtual MAC address. With such association adopted, the hosts in the
internal network do not need to update the association between IP address and MAC address when the
master changes.
z Virtual IP address is associated with real MAC address of the interface
If an IP address owner exists in a VRRP group and you associate the virtual IP address with the virtual
MAC address, two MAC addresses are associated with an IP address. In this case, you can associate
the virtual IP address of the VRRP group with the real MAC address, so that the packets from a host are
forwarded to the IP address owner according the real MAC address.
Follow these steps to configure the association between MAC address and virtual IP address:

Optional
Configure the association
vrrp method { real-mac | The virtual MAC address is
between virtual IP address and
virtual-mac } associated with the virtual IP
MAC address
address by default.
You should configure this function before creating a VRRP group. Otherwise, you cannot modify the
mapping between the virtual IP address and the MAC address.
Creating VRRP Group and Configuring Virtual IP Address
You need to configure a virtual IP address for a VRRP group when creating the VRRP group on an
interface. If the interface connects to multiple sub-networks, you can configure multiple virtual IP
addresses for the VRRP group to realize switch backup on different sub-networks.
A VRRP group is created automatically when you specify the first virtual IP address for the VRRP group.
If you specify another virtual IP address for the VRRP group later, the virtual IP address is added to the
virtual IP address list of the VRRP group.
1-9
It is not recommended to create VRRP groups on the VLAN interface of a super VLAN. Otherwise,
network performance may be affected.
Before creating a VRRP group and configuring a virtual IP address on an interface, you should first
configure an IP address for the interface and ensure that the virtual IP address to be configured is in the
same network segment as the IP address of the interface.
Follow these steps to create VRRP group and configure virtual IP address:

Enter the specified interface view —
interface-number
Create VRRP group and Required

vrrp vrid virtual-router-id
configure virtual IP address of the VRRP group is not
virtual-ip virtual-address
VRRP group created by default.
1-10
z For the S7500E series, the maximum number of VRRP groups on a switch is 255; if the real MAC
address of the interface is associated with the virtual IP address, the maximum number of VRRP
groups on an interface is 16; if the virtual MAC address is associated with the virtual IP address, the
maximum number of VRRP groups on an interface is 4.
z For the S7500E series, the maximum number of virtual IP addresses for a VRRP group is 16.
z A VRRP group is removed after you remove all the virtual IP addresses in it. In addition,
configurations on that VRRP group no longer take effect.
z The virtual 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 switch in the VRRP group. In
the latter case, the switch is called the IP address owner.
z Removal of the VRRP group on the IP address owner will cause IP address collision. In such a
case, it is recommended to modify the IP address of the interface on the IP address owner to
resolve the collision.
z The virtual IP address of the 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.
z Only when the configured virtual IP address and the interface IP address belong to the same
segment and are legal host addresses can the VRRP group operate normally. If the configured
virtual IP address and the interface IP address do not belong to the same network segment, or the
configured IP address is the network address or network broadcast address of the network
segment that the interface IP address belongs to, the state of the VRRP group is always initialize
though you can perform the configuration successfully, that is, VRRP does not take effect in this
case.
Configuring Router Priority, Preemptive Mode and Tracking Function
Before you configure these features, you should first create a VRRP group on the interface and
configure a virtual IP address for it.
By configuring switch priority, preemptive mode, interface tracking, or a Track object, you can decide
which switch in the VRRP group serves as the Master.
Follow these steps to configure switch priority, preemptive mode and the Track object tracking function:
Enter interface view —
interface-number
Configure switch priority in the vrrp vrid virtual-router-id Optional

VRRP group priority priority-value 100 by default.
1-11
Optional
The switch in the VRRP group
works in preemptive mode and
Configure the switch in the
vrrp vrid virtual-router-id the preemption delay is 0
VRRP group to work in
preempt-mode [ timer delay seconds by default.
preemptive mode and
delay-value ] If the switch in the VRRP group
configure preemption delay
works in non preemptive mode,
the preemption delay changes
to zero seconds automatically.
vrrp vrid virtual-router-id track Optional

Configure the interface to be interface interface-type
tracked interface-number [ reduced No interface is being tracked by
priority-reduced ] default.
vrrp vrid virtual-router-id track Optional

Configure VRRP to track a
track-entry-number [ reduced
specified Track object Not configured by default.
priority-reduced | switchover ]
z The running priority of an IP address owner is always 255 and you do not need to configure it. An IP
address owner always works in the preemptive mode.
z Do not configure VRRP tracking of an interface or an object on an IP address owner.
z If the state of the interface under tracking changes from down to up, the priority of the device
corresponding to the interface is restored automatically.
z If the state of a Track object changes from negative to positive, the priority of the device
corresponding to the Track object is restored automatically.
Configuring VRRP Packet Attributes
Before configuring the relevant attributes of VRRP packets, you should first create a VRRP group and
configure a virtual IP address.
Follow these steps to configure VRRP packet attributes:

Enter the specified interface interface interface-type
—
view interface-number
Configure the authentication Optional
vrrp vrid virtual-router-id
mode and authentication key
authentication-mode { md5 | Authentication is not performed
when the VRRP groups send
simple } key by default
and receive VRRP packets
1-12
Configure the time interval for Optional
vrrp vrid virtual-router-id timer
the Master in the VRRP group
advertise adver-interval 1 second by default
to send VRRP advertisement
Optional
Enabled by default
Disable TTL check on VRRP
vrrp un-check ttl You do not need to create a
packets
VRRP group before executing
this command.
z You may 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.
z Excessive traffic or different timer setting on switches can cause the Backup timer to time out
abnormally and trigger a change of the state. To solve this problem, you can prolong the time
interval to send VRRP packets.
Enabling the Trap Function of VRRP
After the trap function is enabled for a VRRP module, the VRRP module will generate traps with severity
level errors to report its key events. The generated traps will be sent to the information center of the
device, where you can configure whether to output the trap information and the output destination. For
information center configurations, refer to Information Center Configuration in the System Volume.
Follow these steps to enable the trap function of VRRP:

Enable the trap function of snmp-agent trap enable vrrp Optional

VRRP [ authfailure | newmaster ] Enabled by default.
For detailed description on the snmp-agent trap enable vrrp command, refer to command
snmp-agent trap enable in SNMP Commands in the System Volume.
1-13
Displaying and Maintaining VRRP for IPv4

display vrrp [ verbose ] [ interface
Display VRRP status interface-type interface-number [ vrid Available in any view
virtual-router-id ] ]
display vrrp statistics [ interface
Display VRRP statistics interface-type interface-number [ vrid Available in any view
reset vrrp statistics [ interface
Remove VRRP statistics interface-type interface-number [ vrid Available in user view
Configuring VRRP for IPv6

VRRP for IPv6 Configuration Task List
Complete these tasks to configure VRRP for IPv6:
Task Remarks
Configuring a VRRP Group to Respond to Ping Packets Destined for the Virtual
Optional
IPv6 Address
Configuring the Association Between Virtual IPv6 Address and MAC Address Optional
Creating VRRP Group and Configuring Virtual IPv6 Address Required
Configuring Router Priority, Preemptive Mode and Interface Tracking Optional
Configuring VRRP Packet Attributes Optional
Configuring a VRRP Group to Respond to Ping Packets Destined for the Virtual IPv6
Address
You can configure that the master of a VRRP group responds to the received ICMPv6 echo requests,
that is, the virtual IPv6 address of the VRRP group can be successfully pinged.
Follow these steps to configure a VRRP group to respond to ping packets destined for its virtual IPv6
address:

Optional
Configure a VRRP group to
respond to ping packets By default, a VRRP group
vrrp ipv6 ping-enable responds to ping packets
destined for its virtual IPv6
address destined for its virtual IPv6
address.
1-14
You should configure this function before creating a VRRP group. Otherwise, your configuration will fail.
Configuring the Association Between Virtual IPv6 Address and MAC Address
After the virtual IPv6 address of a VRRP group is associated with the MAC address, the master takes
the configured MAC address as the source MAC address of the packets to be sent, so that the hosts in
the internal network can learn the association between the IPv6 address and the MAC address and thus
forward the packets to be forwarded to the other network segments to the master.
There are two types of association between virtual IPv6 address and MAC address:
z Virtual IPv6 address is associated with virtual router MAC address
By default, a MAC address is created for a VRRP group after the VRRP group is created, and the virtual
IPv6 address is associated with the virtual MAC address. With such association adopted, the hosts in
the internal network do not need to update the association between IPv6 address and MAC address
when the master changes.
z Virtual IPv6 address is associated with real MAC address of the interface
If an IP address owner exists in a VRRP group and you associate the virtual IPv6 address with the
virtual MAC address, two MAC addresses are associated with an IPv6 address. In this case, you can
associate the virtual IPv6 address of the VRRP group with the real MAC address, so that the packets
from a host is forwarded to the IP address owner according the real MAC address.
Follow these steps to configure the association between MAC address and virtual IPv6 address:

Optional
Configure the association The virtual MAC address of the
vrrp ipv6 method { real-mac |
between virtual IPv6 address VRRP group is associated with
virtual-mac }
and MAC address the virtual IPv6 address by
default.
You should configure this function before creating a VRRP group. Otherwise, you cannot modify the
mapping between the virtual IPv6 address and the MAC address.
Creating VRRP Group and Configuring Virtual IPv6 Address
You need to configure a virtual IPv6 address for a VRRP group when creating the VRRP group. You can
configure multiple virtual IPv6 addresses for a VRRP group.
1-15
A VRRP group is created automatically 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.
It is not recommended to create VRRP groups on the VLAN interface of a super VLAN. Otherwise,
network performance may be affected.
Before creating a VRRP group and configuring a virtual IPv6 address, you should first configure an IPv6
address of the interface and ensure that the virtual IPv6 address to be configured is in the same network
segment as the IPv6 address of the interface.
Follow these steps to create VRRP group and configure its virtual IPv6 address:

—
Required
No VRRP group is created by
default.
Create a VRRP group and vrrp ipv6 vrid virtual-router-id The first virtual IPv6 address of
configure its virtual IPv6 virtual-ip virtual-address the VRRP group must be a link
address [ link-local ] local address. Only one link
local address is allowed in a
VRRP group, and must be
removed the last.
z For the S7500E series, the maximum number of IPv6 VRRP groups on a switch is 128; if the real
MAC address of a interface is associated with the virtual IPv6 address, the maximum number of
VRRP groups on an interface is 16; if the virtual MAC address is associated with the virtual IPv6
address, the maximum number of VRRP groups on an interface is 4.
z For the S7500E series, the maximum number of virtual IP addresses for a VRRP group is 16.
z A VRRP group is removed after you remove all the virtual IPv6 addresses in it. In addition,
configurations on that VRRP group no longer take effect.
z Removal of the VRRP group on the IP address owner will cause IP address collision. In such a
case, it is recommended to modify the IPv6 address of the interface on the IP address owner to
resolve the collision.
1-16
Configuring Router Priority, Preemptive Mode and Interface Tracking
Before configuring these features, you should first create a VRRP group and configure a virtual IPv6
address.
By configuring switch priority, preemptive mode and interface tracking, you can decide which switch in
the VRRP group serves as the Master.
Follow these steps to configure switch priority, preemptive mode and interface tracking:

—
Configure the priority of the vrrp ipv6 vrid virtual-router-id Optional

switch in the VRRP group priority priority-value 100 by default
Configure the switch in the Optional

VRRP group to work in vrrp ipv6 vrid virtual-router-id The switch in the VRRP group
preemptive mode and preempt-mode [ timer delay works in preemptive mode and
configure preemption delay of delay-value ] the preemption delay is zero
the VRRP group seconds by default.
vrrp ipv6 vrid virtual-router-id Optional
Configure the interface to be track interface interface-type
tracked interface-number [ reduced No interface is being tracked by
priority-reduced ] default.
z The running priority of an IP address owner is always 255 and you do not need to configure it. An IP
address owner always works in the preemptive mode.
z Interface tracking is not configurable on an IP address owner.
z If the state of the interface under tracking changes from down to up, the priority of the device
corresponding to the interface is restored automatically.
Configuring VRRP Packet Attributes
Before configuring the relevant attributes of VRRP packets, you should first create a VRRP group and
configure a virtual IPv6 address.
Follow these steps to configure VRRP packet attributes:
1-17
—
Configure the authentication Optional
vrrp ipv6 vrid virtual-router-id
mode and authentication key
authentication-mode simple Authentication is not performed
when the VRRP groups send or
key by default
receive VRRP packets
Configure the time interval for Optional
vrrp ipv6 vrid virtual-router-id
the Master in the VRRP group
timer advertise adver-interval 100 centiseconds by default
to send VRRP advertisement
You may 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 or different timer setting on switches can cause the Backup timer to time out
abnormally and change the state. To solve this problem, you can prolong the time interval to send VRRP
packets.
Displaying and Maintaining VRRP for IPv6

display vrrp ipv6 [ verbose ] [ interface
Display VRRP status interface-type interface-number [ vrid Available in any view
display vrrp ipv6 statistics [ interface
Display VRRP statistics interface-type interface-number [ vrid Available in any view
reset vrrp ipv6 statistics [ interface
Remove VRRP statistics interface-type interface-number [ vrid Available in user view
IPv4-Based VRRP Configuration Examples

This section provides these configuration examples:
z Single VRRP Group Configuration Example
z VRRP Interface Tracking Configuration Example
z Multiple VRRP Group Configuration Example
Single VRRP Group Configuration Example
z Host A needs to access Host B on the Internet, using 202.38.160.111/24 as its default gateway.
z Switch A and Switch B belong to VRRP group 1 with the virtual IP address of 202.38.160.111/24.
z If Switch A operates normally, packets sent from Host A to Host B are forwarded by Switch A; if
Switch A fails, packets sent from Host A to Host B are forwarded by Switch B.
1-18
Network diagram
Figure 1-7 Network diagram for single VRRP group configuration

Virtual IP address:
202.38.160.111/24
Vlan-int2
202.38.160.1/24
Switch A 203.2.3.1/24
202.38.160.3/24 Internet
Host B
Host A
Vlan-int2
202.38.160.2/24
Switch B
# Configure VLAN 2.
[SwitchA] vlan 2
# Create VRRP group 1 and set its virtual IP address to be 202.38.160.111.

[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# Set the priority of Switch A in VRRP group 1 to 110.

[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# Set Switch A to work in preemptive mode. The preemption delay is five seconds.
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
# Configure VLAN 2.
[SwitchB] vlan 2
[SwitchB-Vlan2] port gigabitethernet 2/0/5
[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 be 202.38.160.111.

[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# Set Switch B to work in preemptive mode. The preemption delay is five seconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
1-19
3) Verify the configuration
After the configuration, Host B can be pinged through on Host A. You can use the display vrrp verbose
command to verify the configuration.
# Display detailed information of VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Standby Information:
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 Run 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 of VRRP group 1 on Switch B.

[SwitchB-Vlan-interface2] display vrrp verbose
Admin Status : UP State : Backup
Auth Type : NONE
Virtual IP : 202.38.160.111
Master IP : 202.38.160.1
The above information indicates that in VRRP group 1 Switch A is the master, Switch B is the backup
and packets sent from Host A to Host B are forwarded by Switch A.
If Switch A fails, you can still ping through Host B on Host A. Use the display vrrp verbose command to
view the detailed information of the VRRP group on Switch B.
# If Switch A fails, the detailed information of VRRP group 1 on Switch B is displayed.
Auth Type : NONE
Virtual IP : 202.38.160.111
1-20
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.2
The above information indicates that if Switch A fails, Switch B becomes the master, and packets sent
from Host A to Host B are forwarded by Switch B.
VRRP Interface Tracking Configuration Example
z Host A needs to access Host B on the Internet, using 202.38.160.111/24 as its default gateway.
z Switch A and Switch B belong to VRRP group 1 with the virtual IP address of 202.38.160.111/24.
VLAN-interface 3 through which Switch A connects to the Internet is not available, packets sent
Network diagram
Figure 1-8 Network diagram for VRRP interface tracking

Virtual IP address:
202.38.160.111/24
Vlan-int2
202.38.160.1/24
Vlan-int3
Switch A 203.2.3.1/24
202.38.160.3/24
Internet
Host B
Host A
Vlan-int2
202.38.160.2/24
Switch B
# Configure VLAN 2.
[SwitchA] vlan 2
# Create a VRRP group 1 and set its virtual IP address to 202.38.160.111.

# Configure the priority of Switch A in the VRRP group to 110.

# Configure the authentication mode of the VRRP group as simple and authentication key as hello.
[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
1-21
# Set the interval for Master to send VRRP advertisement to five seconds.
[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 5
# Set the interface to be tracked.

[SwitchA-Vlan-interface2] vrrp vrid 1 track interface vlan-interface 3 reduced 30
# Configure VLAN 2.
[SwitchB] vlan 2

# Configure the authentication mode of the VRRP group as simple and authentication key as hello.
[SwitchB-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# Set the interval for Master to send VRRP advertisement to five seconds.
[SwitchB-Vlan-interface2] vrrp vrid 1 timer advertise 5
After the configuration, Host B can be pinged successfully on Host A. You can use the display vrrp
verbose command to verify the configuration.
Auth Type : SIMPLE TEXT Key : hello
Track IF : Vlan3 Pri Reduced : 30
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.1

1-22
Virtual IP : 202.38.160.111
Master IP : 202.38.160.1
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. Use the display vrrp verbose command to view the detailed
information of the VRRP group.
# If VLAN-interface 3 on Switch A is not available, the detailed information of VRRP group 1 on Switch A
is displayed.
Virtual IP : 202.38.160.111
Master IP : 202.38.160.2
# If VLAN-interface 3 on Switch A is not available, the detailed information of VRRP group 1 on Switch B
is displayed.
Virtual IP : 202.38.160.111
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.2
The above information indicates that if 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 and packets sent
1-23
Multiple VRRP Group Configuration Example
z Hosts in VLAN 2 use 202.38.160.100/25 as their default gateway and hosts in VLAN 3 use
202.38.160.200/25 as their default gateway.
z Switch A and Switch B belong to both VRRP group 1 and VRRP group 2. The virtual IP address of
VRRP group 1 is 202.38.160.100/25, and that of VRRP group 2 is 202.38.160.200/25.
z In VRRP group 1, Switch A has a higher priority than Switch B. In VRRP group 2, Switch B has a
higher priority than Switch A. In this case, hosts in VLAN 2 and VLAN 3 can communicate with the
outside through Switch A and Switch B respectively, and if Switch A or Switch B fails, the hosts can
use the other switch to communicate with the outside, so as to avoid communication interruption.
Network diagram
Figure 1-9 Network diagram for multiple VRRP group configuration
Virtual IP address 1:
202.38.160.100/25
Vlan-int2 Switch A
VLAN 2 202.38.160.1/25
Vlan-int3
Gateway: 202.38.160.130/25
202.38.160.100/25
Internet
VLAN 3
Vlan-int2
Gateway: 202.38.160.2/25
202.38.160.200/25 Vlan-int3
202.38.160.131/25
Switch B
Virtual IP address 2:
202.38.160.200/25
# Configure VLAN 2.
[SwitchA] vlan 2

# Configure the priority of Switch A in VRRP group 1 as 110.

# Configure VLAN 3.
[SwitchA] vlan 3
1-24

# Configure VLAN 2.
[SwitchB] vlan 2

[SwitchB-Vlan-interface2] quit
# Configure VLAN 3.
[SwitchB] vlan 3

# Configure the priority of Switch B in VRRP group 2 to 110.

[SwitchB-Vlan-interface3] vrrp vrid 2 priority 110
You can use the display vrrp verbose command to verify the configuration.
# Display detailed information of the VRRP group on Switch A.
Auth Type : NONE
Virtual IP : 202.38.160.100
Virtual MAC : 0000-5e00-0101
Master IP : 202.38.160.1
1-25
Auth Type : NONE
Virtual IP : 202.38.160.200
Master IP : 202.38.160.131
# Display detailed information of the VRRP group on Switch B.

Auth Type : NONE
Virtual IP : 202.38.160.100
Master IP : 202.38.160.1
Auth Type : NONE
Virtual IP : 202.38.160.200
Virtual MAC : 0000-5e00-0102
Master IP : 202.38.160.131
and hosts with the default gateway of 202.38.160.100/25 accesses the Internet through Switch A; in
VRRP group 2 Switch A is the backup, Switch B is the master and hosts with the default gateway of
202.38.160.200/25 accesses the Internet through Switch B.
IPv6-Based VRRP Configuration Examples

This section provides these configuration examples:
z Single VRRP Group Configuration Example
z VRRP Interface Tracking Configuration Example
z Multiple VRRP Group Configuration Example
Single VRRP Group Configuration Example
z Host A needs to access Host B on the Internet, using 1::10/64 as its default gateway.
1-26
z Switch A and Switch B belong to VRRP group 1 with the virtual IP address of 1::10/64 and
FE80::10.
Switch A fails, packets sent from Host A to Host B are forwarded by Switch B.
Network diagram
Figure 1-10 Network diagram for single VRRP group configuration
Virtual IPv6 address:

FE80::10
1::10/64
Vlan-int2
FE80::1
1::1/64
Switch A
Gateway:
1::10/64
Internet
Host A Host B
Vlan-int2
FE80::2
1::2/64
Switch B
# Configure VLAN 2.
[SwitchA] ipv6
[SwitchA] vlan 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 address 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

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 priority 110
# Set Switch A to work in preemptive mode, with the preemption delay set to 5 seconds.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Enable Switch A to send RA messages.

[SwitchA-Vlan-interface2] undo ipv6 nd ra halt
# Configure VLAN 2.
1-27
[SwitchB] ipv6
[SwitchB] vlan 2
[SwitchB-Vlan-interface2] ipv6 address fe80::2 link-local
[SwitchB-Vlan-interface2] ipv6 address 1::2 64
[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 work in the preemptive mode, with the preemption delay set to 5 seconds.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Enable Switch B to send RA messages.

[SwitchB-Vlan-interface2] undo ipv6 nd ra halt
After the configuration, Host B can be pinged through on Host A. You can use the display vrrp ipv6
[SwitchA-Vlan-interface2] display vrrp ipv6 verbose
Auth Type : NONE
Virtual IP : FE80::10
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1

[SwitchB-Vlan-interface2] display vrrp ipv6 verbose
Auth Type : NONE
1-28
1::10
Master IP : FE80::1
If Switch A fails, you can still ping through Host B on Host A. You can use the display vrrp ipv6
verbose command to view the detailed information of the VRRP group on Switch B.
# If Switch A fails, the detailed information of VRRP group 1 on Switch B is displayed.
Auth Type : NONE
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::2
The above information indicates that if Switch A fails, Switch B becomes the master, and packets sent
VRRP Interface Tracking Configuration Example
z Host A needs to access Host B on the Internet, using 1::10/64 as its default gateway.
z Switch A and Switch B belong to VRRP group 1 with the virtual IP address of 1::10/64 and
FE80::10.
VLAN-interface 3 through which Switch A connects to the Internet is not available, packets sent
1-29
Network diagram
Figure 1-11 Network diagram for VRRP interface tracking
Virtual IPv6 address:

FE80::10
1::10/64
Vlan-int2
FE80::1
1::1/64
Vlan-int3
Switch A
Gateway:
1::10/64
Internet
Host B
Host A Vlan-int2
FE80::2
1::2/64
Switch B
# Configure VLAN 2.
[SwitchA] ipv6
[SwitchA] vlan 2

# Set the authentication mode for VRRP group 1 to simple and authentication key to hello.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 authentication-mode simple hello
# Set the VRRP advertisement interval to 500 centiseconds.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 timer advertise 500
# Set Switch A work in preemptive mode. The preemption delay is five seconds.
[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
# Set the interface to be tracked.

[SwitchA-Vlan-interface2] vrrp ipv6 vrid 1 track interface vlan-interface 3 reduced 30
# Configure VLAN 2.
1-30
[SwitchB] ipv6
[SwitchB] vlan 2
# Set the authentication mode for VRRP group 1 to simple and authentication key to hello.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 authentication-mode simple hello
# Set the VRRP advertisement interval to 500 centiseconds.

[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 timer advertise 500
# Set Switch B to work in preemptive mode. The preemption delay is five seconds.
[SwitchB-Vlan-interface2] vrrp ipv6 vrid 1 preempt-mode timer delay 5
After the configuration, Host B can be pinged through on Host A. You can use the display vrrp ipv6
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1

1-31
1::10
Master IP : FE80::1
If interface VLAN-interface 3 on Switch A is not available, you can still ping Host B successfully on Host
A. You can use the display vrrp ipv6 verbose command to view the detailed information of the VRRP
group.
# If interface VLAN-interface 3 on Switch A is not available, the detailed information of VRRP group 1 on
Switch A is displayed.
1::10
Master IP : FE80::2
# If interface VLAN-interface 3 on Switch A is not available, the detailed information of VRRP group 1 on
Switch B is displayed.
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::2
The above information indicates that if 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.
1-32
Multiple VRRP Group Configuration Example
z Hosts in VLAN 2 use 1::10/64 as their default gateway and hosts in VLAN 3 use 2::10/64 as their
default gateway.
z Switch A and Switch B belong to both VRRP group 1 and VRRP group 2. The virtual IPv6 address
of VRRP group 1 is 1::10/64 and FE80::10, and that of VRRP group 2 is 2::10/64 and FE90::10.
z In VRRP group 1, Switch A has a higher priority than Switch B. In VRRP group 2, Switch B has a
higher priority than Switch A. In this case, hosts in VLAN 1 and VLAN can communicate with the
outside through Switch A and Switch B respectively, and if Switch A or Switch B fails, the hosts can
use the other switch to communicate with the outside, so as to avoid communication interruption.
Network diagram
Figure 1-12 Network diagram for multiple VRRP group configuration
# Configure VLAN 2.
[SwitchA] ipv6
[SwitchA] vlan 2
# Create VRRP group 1 and set its virtual IPv6 address to FE80::10 and 1::10.

1-33
# Configure VLAN 3.
[SwitchA] vlan 3
# Configure VLAN 2.
[SwitchB] ipv6
# Configure VLAN 3.
[SwitchB] vlan 3
# Set the priority of Switch B in VRRP group 2 to 110.

[SwitchB-Vlan-interface3] vrrp ipv6 vrid 2 priority 110
You can use the display vrrp ipv6 verbose command to verify the configuration.
# Display detailed information of the VRRP group on Switch A.
1-34
Auth Type : NONE
1::10
Virtual MAC : 0000-5e00-0201
Master IP : FE80::1
Auth Type : NONE
2::10
Master IP : FE90::2
# Display detailed information of the VRRP group on Switch B.

Auth Type : NONE
1::10
Master IP : FE80::1
Auth Type : NONE
2::10
Virtual MAC : 0000-5e00-0202
Master IP : FE90::2
and hosts with the default gateway of 1::10/64 accesses the Internet through Switch A; in VRRP group
1-35
2 Switch A is the backup, Switch B is the master and hosts with the default gateway of 2::10/64
accesses the Internet through Switch B.
Multiple VRRP groups are commonly used in actual networking. In IPv6 network, to implement load
sharing among multiple VRRP groups, you need to manually configure the default gateway for hosts.
Troubleshooting VRRP
Symptom 1:
The console screen displays error prompts frequently.

Analysis:
This error is probably caused by the following:
z Inconsistent configuration of the devices in the VRRP group.
z A device is attempting to send illegitimate VRRP packets.
Solution:
z In the first case, modify the configuration.
z In the latter case, you have to resort to non-technical measures.
Symptom 2:
Multiple masters are present in the same VRRP group.

Analysis:
z Multiple masters coexist for a short period: This is normal and requires no manual intervention.
z 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:
z If the ping fails, check network connectivity.
z If the ping succeeds, check that their configurations are consistent in terms of number of virtual IP
addresses, virtual IP addresses, advertisement interval, and authentication.
Symptom 3:
Frequent VRRP state transition.

Analysis:
The VRRP advertisement interval is set too short.
Solution:
Increase the interval to sent VRRP advertisement or introduce a preemption delay.
1-36
WAN Links
Module 2
Objectives
At the end of this module you will be able to:
Describe, explain, and implement PPP in A-Series Routers
Describe, explain, and implement Frame Relay in A-Series Routers
Agenda
Activity 2.1: PPP
Activity 2.2: Frame Relay
Activity 2.3: LAB
References
in Appendix 2A:
PPP H3C MSR Router 01 - Access
Frame Relay H3C MSR Router 01 - Access
Table 2.0.1: References by Topic
Rev. 11.21 2 –1
Activity 2.1: PPP - Point to Point Protocol

Introduction
below)
question
Question 1:
To what types of layer 1 links can PPP be applied?
Question 2:
What is the function of each one of the following PPP protocol?
LCP
NCP
PAP and
CHAP
2 –2 Rev. 11.21
WAN Links
Question 3:
What is the main difference between PAP and CHAP?
Question 4:
What is the function of the MD5 algorithm in CHAP? What is an MD5 challenge?
Question 5:
Describe how a PPP session is established.
Rev. 11.21 2 –3
Configuring PPP in A-Series Routers
To configure a PPP link between two A-Series routers, follow these steps:
1. In the interface view:
a. Configure PPP as the data link layer protocol
Note
PPP is the default data link layer protocol for most point to point WAN link
technologies: serial ports, T1/E1 lines, etc.
b. Configure the IP address
2. Configure PAP or CHAP
PAP
Router A (Authenticator)
1. In the interface view, configure the authentication mode as PAP
2. In system view create a local user account for PAP
a. Enter a password
b. Declare the service type as PPP
Router B (Authenticated)
1. In the interface view, configure the PPP PAP local-user and its password
CHAP
Router A (Authenticated)
1. In the interface view, configure the authentication mode as PAP
2. In system view create a local user account for PAP
a. Enter a password
b. Declare the service type as PPP
Router B (Authentication requestor)
1. In the interface view, configure the PPP CHAP local-user and its password
2 –4 Rev. 11.21
WAN Links
Activity 2.2: FR Review

Introduction
below)
question
Question 1:
What is a virtual circuit?
Question 2:
What types of virtual circuits can be implemented in Frame Relay?
Question 3:
Define DTE, DCE, UNI and NNI.
Rev. 11.21 2 –5
Question 4:
What is a DLCI?
Question 5:
Why do you need to map IP addresses to DLCIs and how can that be done?
Question 6:
What issue can arise in a Frame Relay interface if the routing protocol implements
Split Horizon (for example in RIP)?
Question 7:
What is a Frame Relay subinterface? What types of subinterfaces are available and
what is the difference between them in terms of address –to-DLCI mapping?
2 –6 Rev. 11.21
WAN Links
Configuring Frame Relay in A-Series Routers

To configure Frame Relay in an A-Series router follow these steps:
Note
The following steps describe the usual configuration of Frame Relay in routers. It
is assumed that the router is a DTE.
In the interface view:

1. Configure the IP address
2. Configure the data link protocol as FR
3. If necessary, configure the LMI type (ANSI, nonstandard, Q933A or
bidirectional). The default LMI type is Q933A.
4. Configure the DLCIs (one per virtual circuit)
5. Configure address mapping: choose manual mapping or InARP (the default is
InARP)
If you choose to use subinterfaces, create the subinterface and in its view:
1. Configure the IP address
2. Configure the subinterface type: p2p or p2mp
3. Configure the DLCIs
4. In p2mp subinterfaces: configure address mappings
Rev. 11.21 2 –7
Appendix 2.A: Reference manuals for Learning

Activities
PPP
PPP and MP configuration
PPPoE configuration
Frame Relay
Frame Relay configuration
Multilink Frame Relay configuration
PPPoFR configuration
MPoFR configuration
2 –8 Rev. 11.21
Table of Contents
1 PPP and MP Configuration ·······················································································································1-1

Introduction to PPP and MP····················································································································1-1
PPP··················································································································································1-1
MP ···················································································································································1-4
Configuring PPP······································································································································1-5
Configuring PPP ······························································································································1-5
Configuring the Local Device to Authenticate the Peer Using PAP ················································1-5
Configuring the Local Device to Authenticate the Peer Using CHAP ·············································1-6
Configuring the Local Device to be Authenticated by the Peer Using PAP ····································1-7
Configuring the Local Device to be Authenticated by the Peer Using CHAP ·································1-8
Configuring PPP Negotiation···········································································································1-8
Enabling PPP Link Quality Control································································································1-11
Enabling the Generating of PPP Accounting Statistics ·································································1-12
Configuring MP ·····································································································································1-12
Configuring MP Using a VT Interface····························································································1-12
Configuring an MP through an MP-group······················································································1-15
Configuring PPP Link Efficiency Mechanisms ······················································································1-15
Configuring PPP Link Efficiency Mechanisms ··············································································1-17
Displaying and Maintaining PPP/MP/PPP Link Efficiency Mechanism ················································1-18
Configuring L2TP-Based EAD ··············································································································1-19
Configuring L2TP-Based EAD·······································································································1-19
Displaying and Maintaining L2TP-Based EAD ··············································································1-20
PPP and MP Configuration Examples ··································································································1-20
PAP Authentication Configuration Example ··················································································1-20
CHAP Authentication Configuration Example ···············································································1-21
MP Configuration Example············································································································1-22
MP Binding Mode Configuration Examples···················································································1-24
L2TP-Based EAD Configuration Example ····························································································1-32
Network Requirements ··················································································································1-32
Network Diagram···························································································································1-33
Troubleshooting PPP Configuration······································································································1-34
2 PPPoE Configuration ································································································································2-1

Introduction to PPPoE·····························································································································2-1
Configuring a PPPoE Server ··················································································································2-2
Configuring a PPPoE Client····················································································································2-3
Introduction······································································································································2-3
Configuration Procedure··················································································································2-3
Resetting/Terminating a PPPoE Session························································································2-4
Displaying and Maintaining PPPoE ········································································································2-5
PPPoE Configuration Examples ·············································································································2-5
PPPoE Server Configuration Example····························································································2-5
i
PPPoE Client Configuration Example ·····························································································2-7
Connecting a LAN to the Internet Using an ADSL Modem ·····························································2-8
Using ADSL to Provide Backup Connection ·················································································2-10
Accessing the Internet through an ADSL Interface ·······································································2-11
ii
The support for this feature depends on the specific model of the MSR series routers.
z Refer to the command manual of this module for command and parameter support, default values
and value ranges of the MSR series routers.
z All the models of the MSR series routers are centralized devices.
1 PPP and MP Configuration
When configuring PPP and MP, go to these sections for information you are interested in:
z Introduction to PPP and MP
z Configuring PPP
z Configuring MP
z Configuring PPP Link Efficiency Mechanisms
z Displaying and Maintaining PPP/MP/PPP Link Efficiency Mechanism
z Configuring L2TP-Based EAD
z PPP and MP Configuration Examples
z L2TP-Based EAD Configuration Example
Introduction to PPP and MP

PPP
Point-to-Point Protocol (PPP) is a link layer protocol that carries network layer packets over
point-to-point links. It gains popularity because it provides user authentication, supports
synchronous/asynchronous communication, and allows for easy extension.
PPP contains a set of protocols, including a link control protocol (LCP), a network control protocol
(NCP), and authentication protocols such as Password Authentication Protocol (PAP) and Challenge
Handshake Authentication Protocol (CHAP). Among these protocols,
z The LCP is responsible for establishing, tearing down, and monitoring data links.
z The NCP is used for negotiating the packet format and type of data links.
z PAP and CHAP are for network security.
PAP authentication
PAP is a two-way handshake authentication protocol using plain text passwords. It operates as follows.
1) The requester sends its username and password to the authenticator.
2) The authenticator then checks the local user list to see if the username and password are correct
and returns an acknowledgement or negative acknowledge.
1-1
Figure 1-1 PAP Authentication
During PAP authentication, the password is transmitted on the link in plain text. In addition, the
authenticatee sends the username and the password repeatedly through the established PPP link until
the authentication is over. Therefore, PAP is not a secure authentication protocol. It cannot prevent
attacks.
CHAP authentication
CHAP is a three-way handshake authentication protocol using cipher text password.

Currently, two types of CHAP authentication exist: one-way CHAP authentication and two-way CHAP
authentication. By one-way CHAP authentication, one side of the link acts as the authenticator and the
other acts as the authenticatee. By two-way authentication, each side serves as both the authenticator
and the authenticatee. Normally, one-way CHAP authentication is adopted.
CHAP authentication is performed as follows.
1) The authenticator initiates an authentication by sending a randomly generated packet (Challenge).
The packet carries the local username with it.
2) After the authenticatee receives the authentication request, it checks to see if the default CHAP
password is configured on the local port. If yes, the authenticatee encrypts the packet using the
MD5 algorithm, with the packet ID and the default password as the parameters; and then sends
the encrypted packet and the local username to the authenticator (Response).
3) If the default CHAP password is not configured on the port, the authenticatee searches the local
user list for the password of username carried in the received packet, encrypts the packet using
the MD5 algorithm, with the packet ID and the password as the parameters, and then sends the
encrypted packet and the local username to the authenticator (Response).
4) The authenticator encrypts the original randomly generated packet using the MD5 algorithm, with
the password of the authenticatee it maintains as the parameter, compares the encrypted packet
with the one received from the authenticatee, and returns an Acknowledge or Not Acknowledge
packet depending on the comparison result.
1-2
Figure 1-2 CHAP Authentication
Operating mechanism of PPP
Figure 1-3 illustrates the PPP operating mechanism.

1) A PPP link is in the Establish phase when it is about to be established. In this phase, LCP
negotiation is performed, where LCP-related settings are determined, including operating mode
(SP or MP), the authentication mode, and the Maximum Transmission Unit (MTU). If the
negotiation is successful, the link enters the Opened state, indicating that the underlying layer link
has been established.
2) If the authentication (the remote verifies the local or the local verifies the remote) is configured, the
PPP link goes to the Authenticate phase, where CHAP or PAP authentication is performed.
3) If the authenticatee fails to pass the authentication, the link goes to the Terminate phase, where
the link is torn down and LCP goes down. If the authenticatee passes the authentication, the link
goes to the Network phase. In this phase, NCP negotiation is performed, the LCP state remains
Opened, and the state of IP Control Protocol (IPCP) is changed from Initial to Request.
4) NCP negotiation supports the negotiation of IPCP, through which the IP addresses of both sides
can be determined. NCP negotiation also determines and configures the network layer protocol to
be used. Note that a PPP link can carry a network layer protocol only after the NCP negotiation is
successful.
5) After the NCP negotiation is performed, the PPP link remains active until an LCP or NCP frame
close it explicitly or some external events take place (for example, the intervention of a user).
Figure 1-3 PPP operation flow chart
For more information about PPP, refer to RFC 1661.
1-3
MP
Multilink PPP (MP) provides an approach to increasing bandwidth. It allows multiple PPP links to form
an MP bundle. After receiving a packet that is larger than the minimum packet size for fragmentation,
MP segments the packet into fragments and distributes them over multiple PPP links to the remote end.
After the remote end receives these fragments, it assembles them into a packet and passes the packet
to the network layer.
Implementation
You can configure MPs through virtual templates (VT) or MP-group interfaces. VTs are used to
configure virtual access interfaces. After binding multiple PPP links to an MP, you need to create a VA
interface for the MP to enable it to exchange data with the peers. VT and MP-group differ in the
following.
z Configuring MP through VT interfaces can involve an authentication process. The device locates
the interfaces associated to a specified VT according to the username provided by the peers, and
creates a bundle (called VT channel in the system) corresponding to an MP link based on the
configurations of the template.
z Multiple bundles can be created on the same virtual template interface, each of which is an MP link.
From the perspective of the network layer, these links form a point to multipoint network topology.
In this sense, virtual template interfaces are more flexible than MP-group interfaces.
z Bundling mode can be used to distinguish multiple bundles created on a VT interface. You can use
the ppp mp binding-mode command in VT interface view to specify the bundling mode. Three
bundling modes are available: authentication, both (the default), and descriptor. The
authentication mode specifies to bundle links according to username, the descriptor mode
specifies to bundle links according to the peer descriptor (which is determined during LCP
negotiation), and the both mode specifies to bundle links according to both username and
descriptor.
z MP-group interfaces are intended only for MP. On an MP-group interface, only one bundle is
allowed. Compared with VT interfaces, the configuration of MP-group interfaces is simpler and
easier, and accordingly is fast and effective, easy to configure and understand.
Negotiation
MP negotiation involves two processes: first LCP negotiation, and then NCP negotiation.
z LCP negotiation, during which both sides negotiate the common LCP parameters and check
whether their peer interface is working in the MP mode. If not, the LCP negotiation fails. After the
LCP negotiation succeeds, NCP negotiation starts.
z NCP negotiation, which is performed based on the NCP parameters of the MP-group interface or
the specified VT interface. NCP parameters on physical interfaces are not effective.
MP link is established after the NCP negotiation succeeds.
Functions
MP functions to:
z Increase bandwidth, or dynamically increase/reduce bandwidth in combination with Dial Control
Center (DCC).
z Load sharing.
z Backup.
z Decrease transmission delay through fragmentation.
1-4
MP is available to any physical or virtual interfaces encapsulated with PPP, such as serial, ISDN
BRI/PRI, and PPPoX (PPPoE, PPPoA, or PPPoFR). However, a multilink bundle is preferred to include
only one type of interfaces.
Configuring PPP
Configuring PPP
Follow these steps to configure PPP:

interface-number
Configure PPP as the data link layer Optional

link-protocol ppp
protocol By default, PPP is used.
Optional
Set the polling interval timer hold seconds
10 seconds by default
Refer to Configuring the Local
Configure the way Employ PAP Device to Authenticate the Peer
for the local device Using PAP. Optional
to authenticate the PPP authentication is
peer (either PAP or Refer to Configuring the Local disabled by default.
Employ
CHAP) Device to Authenticate the Peer
CHAP
Using CHAP.
Refer to Configuring the Local
Configure the way Employ PAP Device to be Authenticated by
for the peer to the Peer Using PAP. Optional
authenticate the PPP authentication is
local device (either Refer to Configuring the Local disabled by default.
Employ
PAP or CHAP) Device to be Authenticated by
CHAP
the Peer Using CHAP.
Refer to Configuring PPP
Configure PPP negotiation Optional
Negotiation.
Configure PPP link quality control Refer to Enabling PPP Link
Optional
(LQC) Quality Control.
Refer to Enabling the
Enable the generating of PPP
Generating of PPP Accounting Optional
accounting statistics
Statistics
This chapter only discusses local authentication. For information about the remote AAA authentication,
refer to AAA RADIUS HWTACACS Configuration in the Security Volume.
Configuring the Local Device to Authenticate the Peer Using PAP
Follow these steps to configure the local device to authenticate the peer using PAP:
1-5
interface-number
Required
If you execute this command
with the domain keyword not
Configure the local device to ppp authentication-mode specified, the system-default
authenticate the peer using pap [ [ call-in ] domain domain (named system) will be
PAP isp-name ] used, local authentication is
performed, and the address
pool for address allocation
must be the one configured for
this domain.
Required
Create a local user account local-user username This command also leads you
to local user view.
Configure a password for the password { cipher | simple }
Required
local user password
service-type ppp
[ callback-nocheck |
Configure the service type of
callback-number
the local user as well as other Required
callback-number | call-number
attributes
call-number
[ :subcall-number ] ]
Create an ISP domain or enter domain { isp-name | default

Optional
an existing ISP domain view { disable | enable isp-name } }
Configure to authenticate
authentication ppp local Optional
domain users locally
For information about local user configuration and domain configuration, refer to AAA RADIUS
HWTACACS Configuration in the Security Volume.
Configuring the Local Device to Authenticate the Peer Using CHAP
Follow these steps to configure the local device to authenticate the peer using CHAP:

interface-number
1-6
Required
If you execute this
command with the domain
keyword not specified, the
Configure the local device to system-default domain
ppp authentication-mode chap
authenticate the peer using (named system) will be
[ [ call-in ] domain isp-name ]
CHAP used, local authentication
is performed, and the
address pool for address
allocation must be the one
configured for this domain.
Create a local user account ppp chap user username Required
Required
Set the local username local-user username This command also leads
you to local user view.
password { cipher | simple }
Configure the local password Required
password
service-type ppp
Configure the service type of [ callback-nocheck |
the local user as well as other callback-number callback-number Required
attributes | call-number call-number
[ :subcall-number ] ]
Create an ISP domain, or enter domain { isp-name | default
Optional
an existing ISP domain view { disable | enable isp-name } }
Configure to authenticate the
authentication ppp local Optional
domain user locally
For information about local user configuration and domain configuration, refer to AAA RADIUS
Configuring the Local Device to be Authenticated by the Peer Using PAP
Follow these steps to configure the local device to be authenticated by the peer using PAP:

interface-number
Set the PAP username and ppp pap local-user Required

password for the local device to be username password { cipher By default, the username
authenticated by the peer using PAP | simple } password and password are null.
1-7
Configuring the Local Device to be Authenticated by the Peer Using CHAP
Follow these steps to configure the local device to be authenticated by the peer using CHAP:

interface-number
Set the local username ppp chap user username Required
Set the default CHAP authentication ppp chap password { cipher |
Optional
password simple } password
Quit to system
quit —
view
Create a local Optional

Create a local
user account and local-user username This command also leads
user account
set the password you to local user view
password { cipher | simple }
Set the password Optional
password
Configuring PPP Negotiation
Introduction to PPP negotiation parameters
PPP negotiation parameters that can be configured include: negotiation timeout time, IP address
negotiation mode, and DNS server address negotiation mode.
Negotiation timeout time determines the interval to send request packets. During PPP negotiation, if no
response is received from the peer during a specific period after the local device sends a packet, the
device sends another one. The period is known as negotiation timeout time, which ranges from 1 to 10
seconds.
IP address negotiation can be implemented in the following two modes.
z The device operating as the client. You can configure the local interface to operate in this mode if
it uses PPP at the data link layer but it does not have an IP address, whereas the peer is
configured with an IP address, after which the interface can receive an IP address allocated by its
peer. This configuration applies to the situations where you access the Internet through ISP.
z The device operating as the server. In this case, you need to configure a local IP address pool in
domain view or system view to specify the range of the IP addresses to be allocated, and then bind
the address pool to the interface.
PPP address negotiation can also determine the DNS server address. You can configure a device to
allocate the DNS server address to the peer or receive the DNS server address from the peer. Normally,
for a PPP link between a PC and a device, the DNS server address is usually allocated by the device,
through which the PC can access the Internet directly using domain names. For a PPP link established
between a device and the access server of a carrier, the DNS server address is usually allocated by the
access server, through which the device can resolve domain names through the DNS server address
allocated by the access server.
Configuring PPP negotiation parameters
Follow these steps to configure PPP negotiation parameters:

1-8
Enter interface view interface interface-type interface-number —
Configure the negotiation Optional

ppp timer negotiate seconds
timeout time 3 seconds by default
Configure the IP address Refer to section Configuring IP address
Optional
negotiation negotiation
Configure DNS server Refer to section Configuring DNS server
Optional
address negotiation mode address negotiation.
Configuring IP address negotiation
Follow these steps to configure IP address negotiation:

interface-number
Configure the local end
Configure IP Refer to the section below
as the client Either of the two
address
Configure the local end is required.
negotiation Refer to the section below
as the server
1) Configuring the local end as the client

Follow these steps to configure the local end as the client:

interface-number
Enable IP address negotiation ip address ppp-negotiate Required
1-9
2) Configuring the local end as the server
Follow these steps to configure the local end as the server (for cases where PPP authentication is not
enabled):

ip pool pool-number
Required
low-ip-address
Assign an IP Define a global [ high-ip-address ] As for the remote address
address of a address pool and pool command, if the
global address interface interface-type pool-number argument is
bind it to the
pool for the peer interface-number not provided, the global
interface
or specify the IP address pool numbered 0 is
remote address pool used.
address to be [ pool-number ]
allocated to the
peer (use either Specify the IP interface interface-type
method) address to be interface-number Required
allocated to the
peer remote address ip-address
Follow these steps to configure the local end as the server (for cases where PPP authentication is
enabled):

Enter domain view domain domain-name Required
ip pool pool-number
Define the domain
low-ip-address Required
address pool
[ high-ip-address ]
interface-number
Required
If you execute the remote address pool
Specify the address pool remote address pool command without providing the
for IP address allocation [ pool-number ] pool-number argument, all the address
pools in the domain are used in turn for
IP address allocation.
Optional
Disable the peer end from By default, the peer end is allowed to use
ppp ipcp remote-address the locally configured IP address. In this
using the locally
forced case, the local end does not allocate an
configured IP address
IP address to the peer end if the latter
already has an IP address.
Note that the domain used in defining the pool address is the domain specified when performing PPP
authentication.
Configuring DNS server address negotiation
Configure DNS server settings depending on the role of your device in PPP negotiation.
1) Configure the local end as the client
1-10
Follow these steps to configure settings for DNS server address negotiation when the device is
functioning as the client in PPP negotiation:

interface-number
Required
Enable the local end to request
the peer for a DNS server ppp ipcp dns request By default, a device does not
address request its peer for a DNS
server address.
Optional
Enable the local end to accept
the DNS server address ppp ipcp dns admit-any By default, a device does not
assigned by the peer accept the DNS server address
assigned by the peer.
2) Configure the local end as the server

Follow these steps to configure settings for DNS server address negotiation when the device is
functioning as the server in PPP negotiation:

interface-number
ppp ipcp dns Required

Enable the local end to assign a
primary-dns-address By default, a device does not assign
DNS server address to the peer
[ secondary-dns-address ] a DNS server address to the peer.
Enabling PPP Link Quality Control
Introduction
PPP link quality control (LQC) monitors the quality of PPP links (including those in MP bundles) in
real-time. A link goes down when its quality drops below the PPP LQC close-percentage and goes up
when its quality recovers above the PPP LQC resume-percentage. To avoid frequent flapping, a delay
is introduced before a link is brought up.
If PPP LQC is not enabled, each end of a PPP link sends keepalive packets to its peer periodically. After
you enable PPP LQC, Link Quality Reports (LQRs) packets replace keepalive packets to monitor the
link.
With PPP LQC enabled, the system monitors link quality by processing LQR packets received and
shuts down the link if the link quality is below the PPP LQC close-percentage in two consecutive LQR
packet sending intervals. For a link shut down due to the link quality below the PPP LQC
close-percentage, the system detects its link quality in each period ten times of LQR packet sending
intervals, and brings the link up if the link quality is higher than the PPP LQC resume-percentage in
three consecutive such periods. This means a disabled link must experience at least 30 keepalive
periods before it can go up again. If a large keepalive period is specified, it may take long time for the
link to go up.
1-11
Follow these steps to enable PPP LQC:

interface-number
Required
ppp lqc close-percentage
Enable PPP LQC By default, resume-percentage
[ resume-percentage ]
is equal to close-percentage
Enabling the Generating of PPP Accounting Statistics
Introduction to PPP accounting statistics
PPP can generate traffic-based accounting statistics on each PPP link. The statistics include the
amount of the inbound and outbound information (in terms of bytes and the number of the packets) on
a link. The information can be used by AAA application modules for accounting and control purpose.
Enabling the generating of PPP accounting statistics
Follow these steps to enable the generating of PPP accounting statistics:

interface-number
Enable the generating of PPP Required

ppp account-statistics enable
accounting statistics Disabled by default.
Configuring MP
Configuring MP Using a VT Interface
Introduction
When configuring MP using a VT interface, you can do one of the following:

z Associating physical interfaces to the virtual template using the ppp mp virtual-template
command. In this case, the configuration of authentication is optional. If the authentication is not
performed, the system binds links according to the descriptor of the peer end. If the authentication
is performed, the system binds links according to both the username and the descriptor of the
peer.
1-12
z Associating a username to the virtual template. After a user passes the authentication, the system
searches for the virtual template interface associated to the username and bundles links according
to the username and the descriptor of the peer. To ensure a successful link negotiation, you need
to configure the ppp mp command and two-way authentication (CHAP or PAP) on the bundled
interfaces.
z The ppp mp command and the ppp mp virtual-template command are mutually exclusive on an
interface.
z You must configure the interfaces to be bundled in the same way.
z In actual use, you may configure one-way authentication, where one end associates physical
interfaces to a virtual template interface and the other end searches for the virtual template
interface by username.
z A virtual template interface is intended to provide only one service, such as MP, L2TP, or PPPoE.
When configuring MP on a virtual template interface, you can specify to bundle links by username, peer
descriptor, or both. The username discussed here refers to the username of the peer end received
during PAP or CHAP authentication. The descriptor is sent during LCP negotiation. It uniquely identifies
a device. The system distinguishes among the MP bundles created on a virtual template interface by
username and descriptor.
Follow these steps to configure MP using a virtual template interface:

Required
interface virtual-template
Create a VT interface This command also leads you to
number
VT interface view.
1-13
—
interface-number
Associate a Required
physical ppp mp virtual-template Specify the number of the VT
interface to number interface the interface to be
the virtual
bound to.
template
interface Configuration PPP Optional
authentication. Refer to PPP authentication has no effect
Associate a section Configuring PPP on the setup of MP
physical interface
or a username to ppp mp user username Required
the VT interface bind virtual-template Associate a VT interface to MP
number users.
(use either
method)
—
Associate a interface-number
username to Required
the VT
interface ppp mp Configure the interface
encapsulated with PPP to
operate in MP mode.
Configure two-way PPP
authentication. Refer to Required
Configuring PPP
Refer to Configuring other

Configure other MP parameters Optional
optional parameters
Configuring other optional parameters
Follow these steps to configure other optional parameters:

Required
Create an MP VT interface virtual-template
interface or enter dialer number The interface virtual-template
interface view command also leads you to VT interface
interface dialer number
view.
Optional
ppp mp binding-mode
Set the binding mode { authentication | both | By default, MP binding is based on both
descriptor } the PPP authentication username and the
descriptor.
Optional
Set the maximum
ppp mp max-bind 16 by default
number of links for MP
max-bind-num This command is available in VT interface
bundles
view and dialer interface view.
Set the minimum size of ppp mp min-fragment Optional

outgoing MP fragment size 128 bytes by default
1-14
z The maximum/minimum number of links configured with the ppp mp max-bind/ppp mp min-bind
command takes effect in an MP bundle only after you re-enable all the physical interfaces
contained in the MP bundle.
z When MP binding is based on descriptor only, users cannot be differentiated. Therefore, to bind
users to different MP bundles, set the binding mode as both.
z When MP binding is based on authentication username only, peer devices cannot be differentiated.
Therefore, if a MP bundle involves multiple devices, set the binding mode as both.
z For a VT interface, if a static route is used, you are recommended to specify the next hop rather
than the outgoing interface. If the outgoing interface must be specified, make sure that the physical
interfaces bound to the VT are active to ensure normal transport of packets.
z For information about configuring MP parameters in Dialer interface view, refer to DCC
configuration in the Access Volume.
Configuring an MP through an MP-group
Follow these steps to configure an MP through an MP-group:

Create an MP-group interface mp-group mp-number Required
interface-number
Add the interface to the
ppp mp mp-group mp-number Required
MP-group
Configuring PPP Link Efficiency Mechanisms

Four mechanisms are available for improving transmission efficiency on PPP links. They are IP Header
Compression (IPHC), Stac Lempel-Ziv Standard (Stac LZS) compression on PPP packets, V. Jacobson
Compressing TCP/IP Headers (VJ TCP header compression), and Link Fragmentation and
Interleaving (LFI).
IP header compression
IPHC is a host-to-host protocol used to carry real-time multimedia services such as voice and video
over IP networks. To decrease the bandwidth consumed by packet headers, you can enable IPHC on
PPP links to compress RTP (including IP, UDP, and RTP) headers or TCP headers. The following
describes how compression operates by taking RTP header compression as an example.
The Real-time Transport Protocol (RTP) is a UDP protocol using fixed port number and format. An RTP
packet comprises a 40-byte header and a data section. The 40-byte header, which is composed of a
20-byte IP header, an 8-byte UDP header, and a 12-byte RTP header, is large compared with the
payload, which is usually 20 bytes to 160 bytes in size. To reduce bandwidth consumption, you can use
IPHC to compress RTP packet headers. After compression, the 40-byte header can be reduced to 2 to
1-15
5 bytes. If the payload is 40 bytes, the compression ratio will be (40+40) / (40+5), about 1.78, which is
very efficient. The process of IPHC is illustrated in the following figure.
Figure 1-4 IP header compression
Stac LZS compression
Stac LZS compression is a link layer data compression standard developed by Stac Electronics. Stac
LZS is a Lempel-Ziv-based algorithm that compresses only packet payloads. It replaces a continuous
data flow with binary codes that can accommodate to the change of data. While allowing for more
flexibility, this requires more CPU resources.
VJ TCP header compression
VJ TCP header compression was defined in RFC 1144 for use on low-speed links.
Each TCP/IP packet transmitted over a TCP connection contains a typical 40-byte TCP/IP header
containing an IP header and a TCP header that are 20-byte long each. The information in some fields of
these headers, however, remains the same through the lifetime of the connection and thus needs to be
sent only once. In addition, although the information in some other fields changes, the changes are
predictable and are within a definite range. Based on such situation, VJ TCP header compression may
compress a 40-byte TCP/IP header to 3 to 5 bytes. It can significantly improve the transmission speed
of some applications, such as FTP, on a low-speed serial link like PPP.
Link fragmentation and interleaving
On a low speed serial link, packets of real-time interactive communications (such as Telnet and VoIP)
may be blocked or delayed if packets of other applications are also transmitted across the link. For
example, if a voice packet arrives when large packets are being scheduled and waiting for being
transmitted, it has to wait until all the large packets have been transmitted. For the real-time
applications such as VoIP, delays longer than 100 or 150 ms cause voice quality to drop dramatically
and thus cannot be tolerated.
On a 56 Kbps link, it costs approximately 215 ms to transmit a 1500-byte packet (the size of the MTU of
common links). To confine the delay of transmitting time-sensitive packets on low-speed links (such as
56 Kbps frame relay channels or 64 Kbps ISDN B channels) to an acceptable level, a method is
required to fragment larger packets and adding both the smaller packets and fragments of the large
packet to an output queue.
LFI reduces delays and jitters on low-speed links by fragmenting large packets into small fragments
and transmitting them along with small packets. The fragmented datagrams are reassembled at the
destination.
1-16
The following figure illustrates the process of LFI. When large packets and small voice packets arrive at
a WFQ-enabled interface at the same time, the large packets are fragmented into small fragments,
which are then added to the queues along with the voice packets.
Figure 1-5 Link fragmentation and interleaving
Configuring PPP Link Efficiency Mechanisms
Follow these steps to configure PPP Link efficiency mechanisms:

interface mp-group
Create an MP-group Required
mp-number
interface-number
ppp compression iphc
Enable IPHC Required
[ nonstandard ]
Configure ppp compression iphc
maximum number
IPHC tcp-connections number 16 by default
of TCP connections
(optional)
ppp compression iphc
maximum number
rtp-connections number 16 by default
of RTP connections
Optional
Disabled by default
Currently, outbound expedite
forwarding is not applicable on
Enable Stac-LZS compression ppp compression stac-lzs links with Stac-LZS
compression enabled.
Therefore, it is recommended
that you disable outbound
expedite forwarding before
performing this operation.
Enable VJ TCP header Optional

ip tcp vjcompress
compression Disabled by default
1-17
Enter VT interface virtual-template
interface number
view or
Required
MP-group
interface interface mp-group
view mp-number
Configure LFI Required
(optional) Enable LFI ppp mp lfi
Disabled by default
Configure
the Required
ppp mp lfi delay-per-frag
maximum
time 10 ms by default
delay of LFI
fragments
Displaying and Maintaining PPP/MP/PPP Link Efficiency Mechanism

Display the information about display interface mp-group
an existing MP-group interface [ mp-number ]
display virtual-access [ va-number |

Display the information about a dialer dialer-number | peer
VA interface peer-address | slot slot-number | user
user-name | vt vt-number ] *
Display the information about display interface virtual-template
an existing VT [ number ]
Display the information about display ppp mp [ interface
an MP interface interface-type interface-number ]
Display the statistics on TCP display ppp compression iphc tcp
header compression [ interface-type interface-number ]
Display statistics on RTP display ppp compression iphc rtp
Display statistics on STAC-LZS display ppp compression stac-lzs
Clear all statistics on IP header reset ppp compression iphc
compression [ interface-type interface-number ]
Clear statistics on STAC-LZS reset ppp compression stac-lzs
compression [ interface-type interface-number ]
The support for keywords dialer and slot of the display virtual-access command varies with device
models.
1-18
Configuring L2TP-Based EAD
When EAD is used, a PPP user that has passed access authentication must undergo security
authentication performed by the EAD server before they can access available network resources
normally. If the security authentication fails, the user can access only the resources in the isolation
area.
The detailed procedure is as follows:
1) The iNode client (the host) connects to the device through L2TP. After the host has passed the
PPP authentication, the CAMS server issues the isolation ACL to the device to filter the packets
from the client using the firewall.
2) After passing the IPCP negotiation, the CAMS server notifies its IP address which is permitted by
the isolation ACL of the iNode client by way of the device.
3) The CAMS server performs EAD authentication and security check for the iNode client. After
passing the security authentication, the CAMS server issues a security ACL to the device to enable
the client to access network resources normally.
z Make sure that the ACLs used for EAD authentication have been configured appropriately on the
authentication server. An empty ACL or incorrect ACL rules can cause EAD authentication failure.
z You can configure different ACLs for different hosts. A device filters packets of a host according to
the corresponding ACL.
z You are recommended to apply the function to remote clients across the Internet. Do not apply the
function to LAN users. Use the portal authentication for LAN users instead.
z For information about L2TP, refer to L2TP Configuration in the VPN Volume.
z For information about the packet filtering firewall, refer to Firewall Configuration in the Security
Volume.
z For information about AAA and RADIUS, refer to AAA RADIUS HWTACACS Configuration in the
Security Volume.
z For information about portal, refer to Portal Configuration in the Security Volume.
The configuration of AAA, RADIUS, L2TP, packet filtering firewall, and PPP has been completed.
Configuring L2TP-Based EAD
Follow these steps to configure L2TP-based EAD:

Create a VT interface and enter interface virtual-template

Required
VT interface view number
Enable L2TP-based EAD for Required

ppp access-control enable
PPP users Disabled by default.
1-19
Specify the fragment match Required
mode for all packet filtering ppp access-control
firewalls on the VA interfaces match-fragments Standard mode applies by
formed on the VT interface default.
Displaying and Maintaining L2TP-Based EAD

Display statistics about static firewalls on display ppp access-control
the VA interfaces created on the { interface interface-type Available in any view
specified VT interface interface-number }
PPP and MP Configuration Examples

PAP Authentication Configuration Example
As shown in Figure 1-6, Router A and Router B are interconnected through their Serial 2/0 interfaces. It
is required to authenticate Router B on Router A using PAP.
Network diagram
Figure 1-6 Network diagram for PAP and CHAP authentication
1) Configure Router A.
<RouterA> system-view
[RouterA] local-user user2
[RouterA-luser-user2] service-type ppp
[RouterA-luser-user2] password simple pass2
[RouterA-luser-user2] quit
[RouterA] interface serial 2/0
[RouterA-Serial2/0] link-protocol ppp
[RouterA-Serial2/0] ppp authentication-mode pap domain system
[RouterA-Serial2/0] ip address 200.1.1.1 16
[RouterA-Serial2/0] quit
[RouterA] domain system
[RouterA-isp-system] authentication ppp local
2) Configure Router B.
<RouterB> system-view
[RouterB] interface serial 2/0
[RouterB-Serial2/0] link-protocol ppp
1-20
[RouterB-Serial2/0] ppp pap local-user user2 password simple pass2
[RouterB-Serial2/0] ip address 200.1.1.2 16
CHAP Authentication Configuration Example
As shown in Figure 1-6, it is required to authenticate Router B on Router A using CHAP.
Approach I: use the local username and password to perform authentication

[RouterA-luser-user2] password simple hello
[RouterA-Serial2/0] ppp chap user user1
[RouterA-Serial2/0] ppp authentication-mode chap domain system
2) Configure router B.
[RouterB] local-user user1
[RouterB-luser-user1] service-type ppp
[RouterB-luser-user1] password simple hello
[RouterB-luser-user1] quit
[RouterB-Serial2/0] ppp chap user user2
Approach II: use the default CHAP password to perform authentication

[RouterA-Serial2/0] ppp authentication-mode chap domain system
1-21
4) Configure Router B.
[RouterB-Serial2/0] ppp chap user user2
[RouterB-Serial2/0] ppp chap password simple hello
If you configure the ppp authentication-mode chap command without specifying the domain
keyword, the default domain named system is adopted at the time of authentication and local
authentication is performed.
MP Configuration Example
In the network shown in Figure 1-7,

z On an E1 interface of Router A, four channels are created with the interface names being Serial
2/0:1, Serial 2/0:2, Serial 2/0:3, and Serial 2/0:4.
z On Router B, two channels are created with the interface names being Serial 2/0:1 and Serial 2/0:2.
It is the same case with Router C.
Do the following:
z Bind two channels on Router A with the two channels on Router B and another two channels with
the two channels on Router C.
z Adopt binding authentication.
Network diagram
Figure 1-7 Network diagram for MP configuration
1) Configure Router A:
# Create user accounts for Router B and Router C and set the passwords.
[RouterA] local-user router-b
[RouterA-luser-router-b] password simple router-b
[RouterA-luser-router-b] service-type ppp
[RouterA-luser-router-b] quit
[RouterA] local-user router-c
1-22
[RouterA-luser-router-c] password simple router-c
[RouterA-luser-router-c] service-type ppp
[RouterA-luser-router-c] quit
# Create two virtual-templates for the two user accounts.

[RouterA] ppp mp user router-b bind virtual-template 1
[RouterA] ppp mp user router-c bind virtual-template 2
# Configure the virtual-templates.

[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ip address 202.38.166.1 255.255.255.0
[RouterA-Virtual-Template1] quit
# Add interfaces Serial 2/0:1, Serial 2/0:2, Serial 2/0:3, and Serial 2/0:4 to MP channels, taking Serial
2/0:1 as an example.
[RouterA] interface serial 2/0:1
[RouterA-Serial2/0:1] link-protocol ppp
[RouterA-Serial2/0:1] ppp mp
[RouterA-Serial2/0:1] ppp authentication-mode pap domain system
[RouterA-Serial2/0:1] ppp pap local-user router-a password simple router-a
[RouterA-Serial2/0:1] quit
# Configure the users in the domain to use the local authentication scheme.
2) Configure Router B:
# Create a user account for Router A.
[RouterB] local-user router-a
[RouterB-luser-router-a] password simple router-a
[RouterB-luser-router-a] service-type ppp
[RouterB-luser-router-a] quit
# Create a virtual-template for the user and specify to use the NCP information of this template for PPP
negotiation.
[RouterB] ppp mp user router-a bind virtual-template 1
# Configure the virtual-template.

[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ip address 202.38.166.2 255.255.255.0
[RouterB-Virtual-Template1] quit
# Add interfaces Serial 2/0:1 and Serial 2/0/:2 to the MP channel, taking Serial 2/0:1 as an example.
[RouterB] interface serial 2/0:1
[RouterB-Serial2/0:1] ppp mp
[RouterB-Serial2/0:1] ppp authentication-mode pap domain system
[RouterB-Serial2/0:1] ppp pap local-user router-b password simple router-b
3) Configure Router C:
1-23
# Create a user account for Router A.
<RouterC> system-view
[RouterC] local-user router-a
[RouterC-luser-router-a] password simple router-a
[RouterC-luser-router-a] service-type ppp
[RouterC-luser-router-a] quit
# Create a virtual-template for the user and specify to use the NCP information of the template for PPP
negotiation.
[RouterC] ppp mp user router-a bind virtual-template 1
# Configure the virtual-template.

[RouterC] interface virtual-template 1
[RouterC-Virtual-Template1] ip address 202.38.168.2 255.255.255.0
[RouterC-Virtual-Template1] quit
# Add interfaces Serial 2/0:1 and Serial 2/0:2 to the MP channel, taking Serial 2/0:1 as an example.
[RouterC] interface serial 2/0:1
[RouterC-Serial2/0:1] ppp mp
[RouterC-Serial2/0:1] ppp authentication-mode pap domain system
[RouterC-Serial2/0:1] ppp pap local-user router-c password simple router-c
[RouterC-Serial2/0:1] quit
[RouterC] domain system
[RouterC-isp-system] authentication ppp local
MP Binding Mode Configuration Examples
As showed in Figure 1-8, Router A and Router B are connected together through Serial 2/0 and Serial
2/1 interfaces. It is designed to bind the links in the three MP binding modes.
Network diagram
Figure 1-8 Network diagram for MP binding mode configuration
1) Directly bind the physical interfaces to a virtual template interface

Configure Router A:
# Configure the username and password of Router B.
[RouterA] local-user rtb
[RouterA-luser-rtb] password simple rtb
[RouterA-luser-rtb] service-type ppp
1-24
[RouterA-luser-rtb] quit
# Create a virtual template interface and assign an IP address to it.

[RouterA-Virtual-Template1] ip address 8.1.1.1 24
[RouterA-Virtual-Template1] ppp mp binding-mode authentication
# Configure Serial 2/1.

[RouterA-Serial2/1] ppp pap local-user rta password simple rta
[RouterA-Serial2/1] ppp mp virtual-template 1
[RouterA-Serial2/1] shutdown
[RouterA-Serial2/1] undo shutdown

[RouterA] interface serial2/0
[RouterA-Serial2/0] ppp mp virtual-template 1
[RouterA-isp-system] quit
Configure Router B:
# Configure the username and password of Router A.
[RouterB] local-user rta
[RouterB-luser-rta] password simple rta
[RouterB-luser-rta] service-type ppp
[RouterB-luser-rta] quit
# Create a virtual-template interface and assign an IP address to it.

[RouterB-Virtual-Template1] ip address 8.1.1.2 24
[RouterB-Virtual-Template1] ppp mp binding-mode authentication

[RouterB-Serial2/1] ppp authentication-mode pap domain system
[RouterB-Serial2/1] ppp pap local-user rtb password simple rtb
[RouterB-Serial2/1] ppp mp virtual-template 1
1-25
[RouterB-Serial2/1] shutdown
[RouterB-Serial2/1] undo shutdown
[RouterB-Serial2/1] quit

[RouterB-Serial2/0] ppp mp virtual-template 1
# Configure the users in the domain to use local authentication scheme.

[RouterB] domain system
[RouterB-isp-system] authentication ppp local
[RouterB-isp-system] quit
# Verify the configuration on Router A:

[RouterA] display ppp mp
Template is Virtual-Template1
Bundle rtb, 2 member, Master link is Virtual-Template1:0
0 lost fragments, 0 reordered, 0 unassigned, 0 interleaved,
sequence 0/0 rcvd/sent
The bundled member channels are:
Serial2/1
Serial2/0
# Check information about virtual access interfaces:

[RouterA] display virtual-access
Virtual-Template1:0 current state: UP
Line protocol current state: UP
Description: Virtual-Template0:0 Interface
The Maximum Transmit Unit is 1500
Link layer protocol is PPP
LCP opened, MP opened, IPCP opened, OSICP opened
Physical is MP, baudrate: 64000 bps
Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0
Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0
Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0
Last 300 seconds input: 0 bytes/sec 0 packets/sec
Last 300 seconds output: 0 bytes/sec 0 packets/sec
520 packets input, 44132 bytes, 0 drops
527 packets output, 44566 bytes, 4 drops
The display about Router B is similar.

# Ping the IP address 8.1.1.1 on Router B.
[RouterB] ping 8.1.1.1
PING 8.1.1.1: 56 data bytes, press CTRL_C to break
1-26
Reply from 8.1.1.1: bytes=56 Sequence=1 ttl=255 time=29 ms
--- 8.1.1.1 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 29/30/31 ms
Because PPP authentication is configured on the physical interface, the bundle field in the output of
the display ppp mp command is the peer username. If authentication is disabled, the bundle field
should be the peer descriptor.
In addition, you can check the state of MP virtual channels by checking the state of virtual access
interfaces by using the display virtual-access command.
2) Associate the remote username with a virtual template interface
Configure Router A:
# Assign a virtual-template to user RTB.

[RouterA] ppp mp user rtb bind virtual-template 1
# Create a virtual-template and configure the IP address.

[RouterA-Virtual-Template1] ip address 8.1.1.1 24
[RouterA-Virtual-Template1] ppp mp binding authentication

[RouterA-Serial2/1] ppp mp

1-27
[RouterA-Serial2/0] ppp mp
# Configure the user in the domain to use the local authentication scheme.
Configure Router B
# Configure the username and password of Router A.
# Assign a virtual-template to user RTA.

[RouterB] ppp mp user rta bind virtual-template 1
# Create a virtual-template and configure the IP address.

[RouterB-Virtual-Template1] ip address 8.1.1.2 24
[RouterB-Virtual-Template1] ppp mp binding authentication

[RouterB-Serial2/1] ppp mp

[RouterB-Serial2/0] ppp mp
# Configure the user in the domain to use the local authentication scheme.
1-28
# Verify the configuration on Router A.

<RouterA> display ppp mp
Bundle rtb, 2 member, Master link is Virtual-Template1:0
Serial2/1
Serial2/0
# Verify the results on Router B.

[RouterB] display ppp mp
Bundle rta, 2 member, Master link is Virtual-Template1:0
Serial2/1
Serial2/0
# Check the information about the virtual access interface.

[RouterB] display virtual-access
Virtual-Template1:0 current state : UP
Line protocol current state : UP
Description : Virtual-Template1:0 Interface
The Maximum Transmit Unit is 1500
LCP opened, MP opened, IPCP opened, OSICP opened, MPLSCP opened
Physical is MP
Output queue : (Urgent queue : Size/Length/Discards) 0/500/0
5 minutes input rate 0 bytes/sec, 0 packets/sec
5 minutes output rate 0 bytes/sec, 0 packets/sec
# Ping the IP address 8.1.1.1 on Router B.

[RouterB] ping 8.1.1.1

1-29
0.00% packet loss
As for the configuration listed above, the following is incorrect.

If you want to bind interfaces Serial 2/1 and Serial 2/0 to the same MP, but you configured one as ppp
mp while the other as ppp mp virtual-template 1, the system will bind the two interfaces to different
MPs.
3) Configure an MP bundle on an MP-group interface
In addition to virtual template interfaces, the system provides MP-group interfaces to implement MP
bundle. This implementation is similar to directly adding physical interfaces to a virtual template.
Configure Router A:
# Create an MP-group interface, and assign an IP address to it.

[RouterA] interface mp-group 1
[RouterA-Mp-group1] ip address 111.1.1.1 24

[RouterA-Mp-group1] quit
[RouterA-Serial2/1] ppp mp mp-group 1

[RouterA-Serial2/0] ppp mp mp-group 1
Configure Router B:
# Configure username and password for Router A
1-30
# Create an Mp-group interface and assign an IP address to it.

[RouterB] interface mp-group 1
[RouterB-Mp-group1] ip address 111.1.1.2 24
[RouterB-Mp-group1] quit

[RouterB-Serial2/1] ppp mp mp-group 1

[RouterB-Serial2/0] ppp mp mp-group 1
# Verify the configuration on Router A.

[RouterA] display ppp mp
Mp-group is Mp-group1
Bundle Multilink, 2 member, Master link is Mp-group1
Serial2/0
Serial2/0
# Check the state of Mp-group1.

[RouterA] display interface Mp-group 1
Mp-group1 current state : UP
Line protocol current state : UP
Description : Mp-group1 Interface
1-31
The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
Internet Address is 111.1.1.1/24
LCP opened, MP opened, IPCP opened, MPLSCP opened
Physical is MP
Output queue : (Urgent queue : Size/Length/Discards) 0/500/0
5 minutes input rate 0 bytes/sec, 0 packets/sec
5 minutes output rate 0 bytes/sec, 0 packets/sec
# Ping the IP address 111.1.1.2 on Router A.

[RouterA] ping 111.1.1.2
0.00% packet loss
Note that in this approach, all the users are bound together to the MP group interface and the concept
of virtual access is not involved.
L2TP-Based EAD Configuration Example

Network Requirements
In Figure 1-9, configure the security collaborated router to implement EAD.

z In the public network, the Host communicates with the LNS at Layer 3 through L2TP tunnels.
z The intranet is on the network segment 10.100.0.0/24.
z Both the security policy server and the RADIUS server are configured on the CAMS platform with
IP address 10.110.91.146/24.
z The patch server with IP address 10.22.2.2/24 is in the isolation area.
z The client agent with IP address 10.22.2.1/24 is in the isolation area.
z The host is on the network segment 10.200.1.0/24.
The host must pass the security authentication of the authentication server for it to access all available
network resources. If the host fails to pass security authentication, it can access only the patch server.
1-32
Network Diagram
Figure 1-9 Network diagram for L2TP-based EAD configuration
1) Configure the Router

# Assign an IP address to Ethernet 1/1, which is connected to the CAMS server.
[Router] interface ethernet1/1
[Router-Ethernet1/1] ip address 10.110.91.1 255.255.255.0
[Router-Ethernet1/1] quit
# Assign an IP address to Ethernet 1/2, which is connected to the iNode client.

# Assign an IP address to Ethernet 1/3.

# Configure access authentication with the CAMS server, setting the IP address to 10.110.91.146/24,
and the key to sysname.
<Router> system-view
[Router] radius scheme cams
[Router-radius-cams] server-type extended
[Router-radius-cams] primary authentication ip 10.110.91.146
[Router-radius-cams] primary accounting ip 10.110.91.146
[Router-radius-cams] key authentication sysname
[Router-radius-cams] key accounting sysname
[Router-radius-cams] quit
1-33
# Configure the domain system to adopt CAMS authentication and configure the IP address pool
10.100.1.0/24 for assigning IP addresses to remote ends.
[Router] domain system
[Router-isp-system] scheme radius-scheme cams
[Router-isp-system] ip pool 1 10.200.1.2 10.200.1.254
[Router-isp-system] quit
# Configure access control for PPP.

[Router] interface virtual-template 1
[Router-Virtual-Template1] ppp authentication-mode pap
[Router-Virtual-Template1] ppp access-control enable
[Router-Virtual-Template1] ppp access-control match-fragments exactly
[Router-Virtual-Template1] ip address 10.200.1.1 255.255.255.0
[Router-Virtual-Template1] quit
# Configure L2TP.
[Router] l2tp enable
[Router] l2tp-group 1
[Router-l2tp1] undo tunnel authentication
[Router-l2tp1] allow l2tp virtual-template 1
[Router-l2tp1] quit
# Configure the packet filtering firewall.

[Router] firewall enable
[Router] firewall default deny
[Router] firewall fragments-inspect
[Router] acl number 2000
[Router-acl-basic-2000] acl rule permit ip
[Router-acl-basic-2000] rule 1 permit ip fragment
[Router-acl-basic-2000] quit
[Router] acl number 3000
[Router-acl-adv-3000] rule 0 permit ip destination 10.22.2.0 0.0.0.255
[Router-acl-adv-3000] rule 0 permit ip destination 10.22.2.0 0.0.0.255 fragment
2) Configure the CAMS server
Configure ACL 2000 as the security ACL and ACL 3000 as the isolation ACL in the security policy.
Refer to the related CAMS documentation for detailed configurations.
Troubleshooting PPP Configuration

Symptom 1: Cannot pass PPP authentication and the link never turns to up state.
Solution: This problem may arise if the parameters for authentication are incorrect.
Enable the debugging of PPP, and you can see the information describing that LCP went up upon a
successful LCP negotiation but went down after PAP or CHAP negotiation.
Check the PPP authentication settings at the local and peer ends to make sure that they are consistent.
See the part talking about PPP authentication configuration for reference.
Symptom 2: Physical link is down.
Solution: The physical link is down when:
1-34
z The interface is not brought up.
z The interface is shut down by the administrator.
z LCP negotiation fails.
Execute the display interface serial command to check the state of the interface. The output
information can be:
z serial number is administratively down, line protocol is down, which indicates that the
interface is shut down by the administrator.
z serial number is down, line protocol is down, which indicates that the interface is not activated
or the physical layer has not gone up yet.
z Virtual-template number is down, line protocol is spoofing up, which indicates that the
interface is a dialer interface and the call establishment attempt has failed.
z serial number is up, line protocol is up, which indicates that LCP negotiation succeeded.
z serial number is up, line protocol is down, which indicates that the interface is active, but LCP
negotiation failed.
1-35
2 PPPoE Configuration
When configuring PPPoE, go to these sections for information you are interested in:
z Introduction to PPPoE
z Configuring a PPPoE Server
z Configuring a PPPoE Client
z Displaying and Maintaining PPPoE
z PPPoE Configuration Examples
Introduction to PPPoE
PPPoE
Point-to-Point Protocol over Ethernet (PPPoE) can provide the access to the Internet for hosts in an
Ethernet through remote access devices. It also implements access control and accounting on a
per-host basis. As it is cost-effective, PPPoE gains popularity in various applications, such as
residential networks.
PPPoE adopts the client/server model. It can establish point-to-point links in Ethernet. With PPPoE
employed, PPP packets are encapsulated in Ethernet frames.
PPPoE undergoes two phases: discovery and PPP session, as described below.
z Discovery phase, where a PPPoE session is initiated. In this phase, the host obtains the MAC
address of the access end and generates the PPPoE session ID.
z PPP session phase, where PPP packets are encapsulated in Ethernet frames before being sent to
the peer. In the frame, the SESSION ID must be the one determined in the discovery phase, the
MAC address must be that of the peer, and the PPP packet section begins from the Protocol ID
field. In the session phase, either side of the link can terminate the session by sending PPPoE
Active Discovery Terminate (PADT) packets.
For more information about PPPoE, refer to RFC 2516.
PPPoE server
A device can operate as a PPPoE server to provide the following functions:

z Dynamic IP address allocation.
Multiple authentication methods, such as local authentication and RADIUS/TACACS+. When
accompanied by the packet-filtering firewall or state firewall, a PPPoE server can provide security for
networks connecting the Internet through Ethernet, such as campus networks and residential networks.
This, however, requires installation of PPPoE client dial-up software on hosts.
PPPoE client
PPPoE is widely used in ADSL broadband access applications. Normally, to enable a host to access
the Internet through ADSL, PPPoE client dial-up software is required on the host. You can run PPPoE
client dial-up software on a device. In This case, the device operates as a PPPoE client and can thus
2-1
provide Internet access for all the hosts in a LAN using a single ADSL account, even if the hosts do not
have PPPoE client software installed.
Figure 2-1 Network diagram for PPPoE client
As shown in the above figure, Host A and Host B are in an Ethernet and are connected to the device
operating as a PPPoE client. Data in the Ethernet and destined for the Internet is passed to the PPPoE
client and is then encapsulated by PPPoE before being transmitted to the PPPoE server, which in turn
transmits the data to the Internet. For Host A and Host B, the PPPoE client dial-up software is not
needed.
Configuring a PPPoE Server

You can configure PPPoE servers on Ethernet ports or virtual Ethernet interfaces created on ADSL
interfaces. For information about configuring PPPoE servers on virtual Ethernet interfaces, refer to
ATM configuration in the Access Volume.
Follow these steps to configure a PPPoE server:

interface virtual-template This operation also leads you to
Create a VT
number virtual interface template view.
Configure PPP parameters
(including authentication type, Refer to Configuring PPP Optional
IP address negotiation, etc)
Enter Ethernet port view Required
interface-number
Enable PPPoE on the Ethernet pppoe-server bind Required

port virtual-template number Disabled by default
pppoe-server max-sessions
PPPoE sessions allowed with
remote-mac number 100 by default
regard to a peer MAC address
2-2
Set the maximum number of
PPPoE sessions allowed with pppoe-server max-sessions Optional
regard to the local MAC local-mac number 100 by default
address
Optional
Set the maximum number of
pppoe-server max-sessions The maximum number of
PPPoE sessions allowed (for
total number PPPoE sessions allowed varies
centralized device)
by device.

pppoe-server max-sessions
PPPoE sessions allowed (for The default varies with the I/O
slot slot-number total number
distributed device) cards.
Refer to AAA RADIUS
Configure authentication and
HWTACACS Configuration in Optional
accounting on PPP users
the Security Volume.
pppoe-server Optional
Disable PPP log displaying
log-information off Enabled by default
When configuring a static route on a virtual template interface, specify the next hop instead of the
outgoing interface. If the outgoing interface is required, make sure that the physical interface bound to
the virtual template is effective to ensure normal transport of packets.
Configuring a PPPoE Client

Introduction
PPPoE client configuration includes dialer interface configuration and PPPoE session configuration.
Before establishing a PPPoE session, you need first to create a dialer interface and configure a dialer
bundle on the interface. Each PPPoE session uniquely corresponds to a dialer bundle and each dialer
bundle uniquely corresponds to a dialer interface. Thus, a PPPoE session uniquely corresponds to a
dialer interface.
You can establish a PPPoE session on an Ethernet port or a virtual Ethernet (VE) interface created on
an ADSL interface. To enable a device to access the Internet through an ADSL interface, you need to
establish a PPPoE session on a virtual Ethernet interface; to enable a device to access the Internet
through an ADSL modem attached to an Ethernet interface, you need to establish the PPPoE session
on the Ethernet interface.
For information about creating a PPPoE session on a virtual Ethernet interface, refer to ATM
Configuration in the Access volume.
Follow these steps to configure a PPPoE client:
2-3
dialer-rule dialer-group { protocol-name
Configure a dialer rule Required
{ permit | deny } | acl acl-number }
Create a dialer interface interface dialer number Required
Create a dialer user dialer user username Required
Assign an IP address to the ip address { address mask |
Required
interface ppp-negotiate }
Create a dialer bundle on the
dialer bundle bundle-number Required
interface
Create a dialer group on the
dialer-group group-number Required
interface
Enter Ethernet interface view interface ethernet interface-number —
pppoe-client dial-bundle-number
Create a PPPoE session number [ no-hostuniq ] [ idle-timeout Required
seconds [ queue-length packets ] ]
You can also perform configuration concerning PPP authentication on the dialer interface as needed.
For information about dialer interface, refer to DCC configuration in the Access Volume.
Resetting/Terminating a PPPoE Session
Introduction
PPPoE sessions fall into these two categories: permanent PPPoE session and packet-triggered
PPPoE session.
z A permanent PPPoE session is established immediately when the line is physically up. It remains
valid till a user terminates it explicitly.
z A packet-triggered PPPoE session is established when there is a demand for data transmitting. It
is terminated when idled for a specific period of time. That is, a packet-triggered PPPoE session
may not be established even if the line is physically up.
2-4
Resetting/terminating a PPPoE session
Follow these steps to reset/terminate a PPPoE session:

Reset a PPPoE session on a reset pppoe-client { all |
PPPoE client dial-bundle-number number }
reset pppoe-server { all | Available in user view

Reset a PPPoE session on a interface interface-type
PPPoE server interface-number |
virtual-template number }
Available in Ethernet interface
Terminate a PPPoE session on undo pppoe-client
view or virtual Ethernet
a PPPoE client dial-bundle-number number
interface view
Displaying and Maintaining PPPoE

Display the statistics and state
display pppoe-server session { all
information about a PPPoE Available in any view
| packet }
server
Display the statistics and state display pppoe-client session
information about a PPPoE { packet | summary } Available in any view
client [ dial-bundle-number number ]
PPPoE Configuration Examples

PPPoE Server Configuration Example
In Figure 2-2, Host A and Host B, acting as PPPoE clients, access the Internet through the Router. The
Router acts as the PPPoE server, performing local authentication and assigning IP addresses for the
users.
Network diagram
The Router provides Internet access for Host A and Host B through Ethernet 1/0. It connects to the
Internet through Serial 2/0.
2-5
Figure 2-2 Network diagram for PPPoE server configuration
# Add a PPPoE user.

[Sysname] local-user user1
[Sysname-luser-user1] password simple pass1
[Sysname-luser-user1] service-type ppp
[Sysname-luser-user1] quit
# Configure virtual-template 1 on the Router.

[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp authentication-mode chap domain system
[Sysname-Virtual-Template1] ppp chap user user1
[Sysname-Virtual-Template1] remote address pool 1
[Sysname-Virtual-Template1] ip address 1.1.1.1 255.0.0.0
[Sysname-Virtual-Template1] quit
# Configure PPPoE parameters on the Router.

[Sysname] interface ethernet 1/0
[Sysname-Ethernet1/0] pppoe-server bind virtual-template 1
[Sysname-Ethernet1/0] quit
[Sysname] domain system
[Sysname-isp-system] authentication ppp local
# Add a local IP address pool.

[Sysname-isp-system] ip pool 1 1.1.1.2 1.1.1.10
After the above configuration, Host A and Host B can access the Internet using the username user1
and password pass1 through the Router if they have PPPoE client software installed.
If you specify the authentication scheme as radius-scheme or hwtacacs-scheme by using the
authentication ppp command, you need also to perform the configuration concerning
RADIUS/HWTACACS to allow for AAA. For detailed configuration procedures, refer to AAA RADIUS
2-6
PPPoE Client Configuration Example
Router A and Router B are connected to each other through Ethernet 1/0. It is required that Router A
authenticates Router B using PAP or CHAP.
Network diagram
Figure 2-3 Network diagram for PPPoE client configuration
PPPoE Server PPPoE Client
Eth1/0 Eth1/0
Router A Router B
Configuration for adopting PAP authentication

1) Configure Router A as the PPPoE server
# Add a PPPoE user.
# Configure virtual template 1.

[RouterA-Virtual-Template1] ppp authentication-mode pap
[RouterA-Virtual-Template1] remote address 1.1.1.2
# Configure the PPPoE server.

[RouterA] interface ethernet 1/0
[RouterA-Ethernet1/0] pppoe-server bind virtual-template 1
2) Configure Router B as the PPPoE client.
[RouterB] dialer-rule 1 ip permit
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer user user2
[RouterB-Dialer1] dialer-group 1
[RouterB-Dialer1] dialer bundle 1
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] ppp pap local-user user2 password simple hello
[RouterB-Dialer1] quit
# Configure the PPPoE session.

[RouterB] interface ethernet 1/0
[RouterB-Ethernet1/0] pppoe-client dial-bundle-number 1
2-7
Configuration for adopting CHAP authentication
3) Configure Router A as the PPPoE server
# Add a PPPoE user.

[RouterA-Virtual-Template1] ppp authentication-mode chap
[RouterA-Virtual-Template1] ppp chap user user1
[RouterA-Virtual-Template1] remote address 1.1.1.2
# Configure the PPPoE server.

[RouterA-Ethernet1/0] pppoe-server bind virtual-template 1
4) Configure Router B as the PPPoE client.
[RouterB] dialer-rule 1 ip permit
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer user user2
[RouterB-Dialer1] dialer-group 1
[RouterB-Dialer1] dialer bundle 1
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] ppp chap user user2
[RouterB-Dialer1] quit
[RouterB-luser-user1] password simple hello
# Configure the PPPoE session.

[RouterB] interface ethernet 1/0
[RouterB-Ethernet1/0] pppoe-client dial-bundle-number 1
Connecting a LAN to the Internet Using an ADSL Modem
z Router A provides Internet access for Host A, Host B, and Host C. It connects to DSLAM through
an ADSL modem and a permanent PPPoE session.
z The username and password of the ADSL account are user1 and 123456.
z Router A operates as a PPPoE client, allowing the hosts in the LAN to access the Internet without
PPPoE client software.
z Router B operates as the PPPoE server. It is connected to the DSLAM through interface ATM 1/0
and performs RADIUS authentication and accounting.
2-8
Network diagram
Figure 2-4 Network diagram for connecting a LAN to the Internet through an ADSL modem
1) Configure Router A as a PPPoE client

# Configure a dialer interface.
[RouterA] dialer-rule 1 ip permit
[RouterA] interface dialer 1
[RouterA-Dialer1] dialer-group 1
[RouterA-Dialer1] dialer bundle 1
[RouterA-Dialer1] ip address ppp-negotiate
[RouterA-Dialer1] ppp pap local-user user1 password cipher 123456
[RouterA-Dialer1] quit
# Configure a PPPoE session.

[RouterA-Ethernet2/0] pppoe-client dial-bundle-number 1
[RouterA-Ethernet2/0] quit
# Configure an Internet interface for the LAN and configure the default route.
[RouterA-Ethernet1/0] ip address 192.168.1.1 255.255.255.0
[RouterA-Ethernet1/0] quit
[RouterA] ip route-static 0.0.0.0 0 dialer 1
If the IP addresses of the hosts in the LAN are private addresses, you need to configure Network
Address Translation (NAT) on Router A. For information about NAT, refer to NAT configuration in the
Security Volume.
2) Configure Router B as the PPPoE server
# Add a PPPoE user.
2-9
[RouterB-luser-user1] password simple 123456
[RouterB-luser-user1] service-type ppp
# Configure ATM 1/0 interface.

[RouterB] interface atm 1/0
[RouterB-Atm1/0] pvc 0/32
[RouterB-atm-pvc-Atm1/0-0/32] map bridge virtual-ethernet 1
[RouterB-atm-pvc-Atm1/0-0/32] quit
[RouterB-Atm1/0] quit
# Enable PPPoE server on the virtual Ethernet interface.

[RouterB] interface virtual-ethernet 1
[RouterB-Virtual-Ethernet1] pppoe-server bind virtual-template 1
[RouterB-Virtual-Ethernet1] mac-address 0022-0022-00c1
[RouterB-Virtual-Ethernet1] quit

[RouterB-Virtual-Template1] ppp authentication-mode pap domain system
[RouterB-Virtual-Template1] remote address pool 1
# Apply the RADIUS authentication scheme to the domain users.

[RouterB-isp-system] authentication ppp radius-scheme cams
# Add a local IP address pool.

[RouterB-isp-system] ip pool 1 1.1.1.2 1.1.1.10
# Configure RADIUS scheme.

[RouterB] radius scheme cams
[RouterB-radius-cams] primary authentication 10.110.91.146 1812
[RouterB-radius-cams] primary accounting 10.110.91.146 1813
[RouterB-radius-cams] key authentication expert
[RouterB-radius-cams] key accounting expert
[RouterB-radius-cams] server-type extended
[RouterB-radius-cams] user-name-format with-domain
[RouterB-radius-cams] quit
For information about RADIUS, refer to AAA RADIUS HWTACACS Configuration in the Security
Volume.
Using ADSL to Provide Backup Connection
Router is connected to Network Center through a DDN dedicated line and an ADSL connection, where
the ADSL connection provides backup for the DDN dedicated line. When the DDN dedicated line fails,
2-10
the Router initiates a PPPoE call to establish an ADSL connection to the Network Center on the
demand of data transmitting. The ADSL connection is terminated when it idled for 2 minutes.
Network diagram
Figure 2-5 Network diagram for using ADSL to provide backup connection
Configure Router:
[Router] dialer-rule 1 ip permit
[Router] interface dialer 1
[Router-Dialer1] dialer user user1
[Router-Dialer1] dialer-group 1
[Router-Dialer1] dialer bundle 1
[Router-Dialer1] ip address ppp-negotiate

[Router-Dialer1] interface ethernet 2/0
[Router-Ethernet2/0] pppoe-client dial-bundle-number 1 idle-timeout 120
# Configure the DDN interface Serial 2/0.

[Router] interface serial 2/0
[Router-Serial2/0] ip address 10.1.1.1 255.255.255.0
[Router-Serial2/0] standby interface dialer 1
[Router-Serial2/0] quit
# Configure the static routes to the peer.

[Router] ip route 0.0.0.0 0 serial 1/0 preference 60
[Router] ip route 0.0.0.0 0 dialer 1 preference 70
Accessing the Internet through an ADSL Interface
ATM 1/0 on Router is used as an ADSL interface, through which Router can access the Internet directly
without an ADSL modem.
2-11
Network diagram
Figure 2-6 Network diagram for accessing the Internet through an ADSL interface

[Router] dialer-rule 1 ip permit
[Router] interface dialer 1
[Router-Dialer1] dialer user mypppoe
[Router-Dialer1] dialer-group 1
[Router-Dialer1] dialer bundle 1
[Router-Dialer1] ip address ppp-negotiate
# Configure VE interface 1.
[Router-Dialer1] interface virtual-ethernet 1
[Router-Virtual-Ethernet1] mac 0001-0002-0003
[Router-Virtual-Ethernet1] quit
[Router]interface atm 1/0.1
[Router-atm1/0.1]pvc to_adsl_a 0/60
[Router-atm-pvc-atm1/0.1-0/60-to_adsl_a] map bridge virtual-ethernet 1
[Router-atm-pvc-atm1/0.1-0/60-to_adsl_a] quit
[Router-atm1/0.1] quit

[Router] interface virtual-ethernet 1
[Router-Virtual-Ethernet1] pppoe-client dial-bundle-number 1 idle-timeout 120
[Router-Virtual-Ethernet1] quit
# Configure a default route.

[Router]ip route-static 0.0.0.0 0.0.0.0 dialer 1
2-12
Table of Contents
1 Frame Relay Configuration·······················································································································1-1

Frame Relay Terminologies····················································································································1-1
Frame relay Protocol ·······················································································································1-1
DTE, DCE, UNI, and NNI ················································································································1-1
Virtual Circuit ···································································································································1-2
Frame Relay Protocol Parameters ··································································································1-2
Frame Relay Address Mapping·······································································································1-3
Frame Relay Configuration Task List······································································································1-4
Configuring DTE Side Frame Relay········································································································1-4
Configuring Basic DTE Side Frame Relay ······················································································1-4
Configuring Frame Relay Address Mapping ···················································································1-5
Configuring Frame Relay Local Virtual Circuit ················································································1-5
Configuring Frame Relay Switching ································································································1-6
Configuring Frame Relay Subinterface ···························································································1-7
Configuring Frame Relay over IP Network······················································································1-8
Configuring X.25 Parameters for a VC····························································································1-9
Configuring Annex G ·····················································································································1-10
Configuring DCE Side Frame Relay ·····································································································1-12
Configuring Basic DCE Side Frame Relay····················································································1-12
Configuring Frame Relay Address Mapping ·················································································1-12
Configuring Frame Relay Local Virtual Circuit ··············································································1-13
Configuring Frame Relay Switching ······························································································1-13
Configuring Frame Relay Subinterface ·························································································1-13
Configuring Frame Relay over IP Network····················································································1-13
Configuring X.25 parameters for a VC ··························································································1-13
Configuring Annex G ·····················································································································1-13
Enabling Trap········································································································································1-13
Displaying and Maintaining Frame Relay ·····························································································1-14
Frame Relay Configuration Examples ··································································································1-14
Interconnecting LANs through the Frame Relay Network·····························································1-15
Interconnecting LANs through Dedicated Line··············································································1-16
Interconnecting LANs through an Annex G DLCI ·········································································1-17
Troubleshooting Frame Relay···············································································································1-19
Frame Relay Compression ···················································································································1-19
Overview········································································································································1-20
Configuring FRF.9 Compression···································································································1-20
Configuring FRF.20 IP Header Compression ···············································································1-21
Displaying and Maintaining Frame Relay Compression ·······························································1-21
Frame Relay FRF.9 Stack Compression Configuration Example ·················································1-22
Frame Relay FRF.20 IP Compression Configuration Example·····················································1-23
2 Multilink Frame Relay Configuration ·······································································································2-1

Overview ·················································································································································2-1
Configuring Multilink Frame Relay ··········································································································2-2
i
Displaying and Maintaining Multilink Frame Relay ·················································································2-3
Multilink Frame Relay Configuration Example························································································2-3
MFR Direct Connection Configuration Example ·············································································2-3
MFR Switched Connection Configuration Example ········································································2-4
3 PPPoFR Configuration ······························································································································3-1

Overview ·················································································································································3-1
Configuring PPPoFR·······························································································································3-1
Displaying and Maintaining PPPoFR ······································································································3-2
PPPoFR Configuration Example·············································································································3-2
4 MPoFR Configuration································································································································4-1
Overview ·················································································································································4-1
Configuring MPoFR·································································································································4-1
MPoFR Configuration Example ··············································································································4-2
ii
The support for this feature depends on the specific model of the MSR series routers.
z Refer to the command manual of this module for command and parameter support, default values
and value ranges of the MSR series routers.
z All the models of the MSR series routers are centralized devices.
1 Frame Relay Configuration
When configuring frame relay, go to these sections for information you are interested in:
z Frame Relay Terminologies
z Frame Relay Configuration Task List
z Configuring DCE Side Frame Relay
z Enabling Trap
z Displaying and Maintaining Frame Relay
z Frame Relay Configuration Examples
z Troubleshooting Frame Relay
z Frame Relay Compression
Frame Relay Terminologies

This section covers these topics:
z Frame relay Protocol
z DTE, DCE, UNI, and NNI
z Virtual Circuit
z Frame Relay Protocol Parameters
z Frame Relay Address Mapping
Frame relay Protocol
Frame relay protocol is a simplified X.25 WAN protocol. It is a kind of statistical multiplexing protocol
that can establish multiple virtual circuits (VC) over a single physical cable, each of which is identified
by a data link connection identifier (DLCI). A DLCI is not of global significance. It is valid to two directly
connected interfaces only. That is, you can use the same DLCI on different physical interfaces to
identify different VCs.
A frame relay network can be a public network, a private enterprise network, or a network formed by
direct connections between data devices.
DTE, DCE, UNI, and NNI
Data Terminal Equipments (DTE) are end devices in frame relay networks. A frame relay network
provides the capability of data communications between end devices.
1-1
Data Circuit-terminating Equipments (DCE) are network devices that provide network access to DTEs.
User Network Interfaces (UNI) are interfaces used to connect DTEs and DCEs.
Network-to-Network interfaces (NNI) are interfaces used to connect frame relay networks.
Virtual Circuit
Virtual circuits fall into two types, permanent virtual circuit (PVC) and switched virtual circuit (SVC),
depending on how they are set up. Virtual circuits configured manually are called PVCs, and those
created by protocol negotiation are called SVCs, which are automatically created and deleted by the
frame relay protocol. At present, the most frequently used in frame relay is the PVC mode, that is,
manually configured virtual circuit.
In the PVC mode, the availability of the virtual circuit should be checked. The local management
interface (LMI) protocol can implement this function. It is used to maintain the PVC table of the frame
relay protocol, including advertising added PVC entry, detecting deleted PVC entry, monitoring PVC
status change, and verifying PVC link integrity. The system supports three LMI protocols: ITU-T Q.933
Appendix A, ANSI T1.617 Appendix D, and nonstandard compatible protocol. Their basic operating
mode is: DTE sends one Status Enquiry message to query the virtual circuit status at a certain interval.
After the DCE receives the message, it will immediately use the Status message to inform DTE of the
status of all the virtual circuits on the current interface.
The PVC status on DTE is completely determined by DCE, and the network determines the PVC status
on DCE. If two network devices are directly connected, the equipment administrator sets the virtual
circuit status of DCE.
Frame Relay Protocol Parameters
Table 1-1 lists the parameters of frame relay.
Table 1-1 Parameter description for frame relay protocol
Operating
Parameter description Value range Default value
mode
Request PVC status counter (N391) 1 to 255 6
Error threshold (N392) 1 to 10 3
DTE Event counter (N393) 1 to 10 4
User side polling timer (T391), the value 0 0 to 32767 10

indicates that the LMI protocol is disabled (in seconds) (in seconds)
Error threshold (N392) 1 to 10 3
Event counter (N393) 1 to 10 4
DCE
5 to 30 15
Network side polling timer (T392)
(in seconds) (in seconds)
These parameters are stipulated by Q.933 Appendix A, and their meanings are described as follows:
Meanings of parameters related to DTE operating mode:
z N391: DTE sends a Status-Enquiry message at a certain interval (determined by T391). There are
two types of Status-Enquiry messages: link integrity verification messages and link status enquiry
1-2
messages. N391 defines that the ratio of sent link status enquiry messages to sent link integrity
verification messages equals 1:N391–1.
z N392: it sets the threshold for errors among the observed events.
z N393: it sets the total of observed events.
z T391: it sets the interval for a DTE to send State-Enquiry messages.
A DTE sends a Status-Enquiry message at a certain interval to query the link status. The DCE responds
with a Status response message upon receiving the message. If the DTE does not receive any
response within a specified time, it will record this error. If the number of errors exceeds the threshold,
DTE will regard the physical channel and all virtual circuits unavailable. N392 and N393 together define
"error threshold". In other words, if the number of errors reaches N392 among the N393 Status Enquiry
messages sent by DTE, DTE will consider that the number of errors has reached the threshold and the
physical channel and all virtual circuits are unavailable.
Meanings of parameters related to DCE operating mode:
z N392 and N393: These two parameters have similar meanings to those related to DTE operating
mode. However, DCE requires that the fixed time interval for DTE sending a status-enquiry
message should be determined by T392, while DTE requires that this interval should be
determined by T391. If DCE does not receive the status-enquiry message from DTE within a
period determined by T392, an error recorder is created.
z T392: Time variable, which defines the maximum time that DCE waits for a status-enquiry
message. The time value shall be greater than the value of T391.
Frame Relay Address Mapping
Frame relay address mapping associates the protocol address of a remote device with its frame relay
address (local DLCI). By consulting the frame relay address map by protocol address, the upper layer
protocol can locate a remote device. Frame relay is used to bear the IP protocol. When sending an IP
packet, the frame relay-enabled router can obtain its next hop address after consulting the routing table,
which is inadequate for sending the packet to the correct destination across a frame relay network. To
identify the DLCI corresponding to the next hop address, the router must consult a frame relay address
map retaining the associations between remote IP addresses and next hop DLCIs.
A frame relay address map can be manually configured or maintained by Inverse Address Resolution
Protocol (InARP).
The following figure presents how LANs are interconnected across a frame relay network.
Figure 1-1 Interconnect LANs through a frame relay network
1-3
Frame Relay Configuration Task List
Complete the following tasks to configure frame relay:
Task Remarks
Configuring DTE Side Frame Relay Required
Configuring DCE Side Frame Relay Required
Configuring Frame Relay Address Mapping Required
Configuring Frame Relay Local Virtual Circuit Required
Configuring Frame Relay Switching Optional
Configuring Frame Relay Subinterface Optional
Configuring Frame Relay over IP Network Optional
Configuring X.25 Parameters for a VC Optional
Configuring Annex G Optional
Enabling Trap Optional
Configuring DTE Side Frame Relay

Configuring Basic DTE Side Frame Relay
Follow these steps to configure DTE side frame relay:

interface-number
Required
Configure the interface The default link layer protocol of an
link-protocol fr [ ietf |
encapsulation protocol as interface is PPP. When the link layer
nonstandard ]
frame relay protocol is frame relay, the default
encapsulation format is IETF.
Optional
Configure the frame relay
fr interface-type dte The default frame relay interface type
interface type as DTE
is DTE.
Optional
fr lmi type { ansi | The default frame relay LMI protocol
Configure frame relay LMI
nonstandard | q933a | type is q933a.
protocol type
bi-direction } The support of the bi-direction
keyword varies with device model.
Optional
Configure user side N391 fr lmi n391dte n391-value
The default value is 6.
Optional
Optional
1-4
Optional
Configure user side T391 timer hold seconds
The default value is 10 seconds.
Configuring Frame Relay Address Mapping
Overview
Frame relay address mapping can be configured statically or set up dynamically.

z Static configuration means the manual setup of the mapping relation between the peer IP address
and local DLCI, and is usually applied when there are few peer hosts or there is a default route.
z Dynamic setup means the dynamic setup of mapping relation between the peer IP address and
local DLCI by InARP. Dynamic setup is applied when the peer device also supports the InARP and
the network is complex.
Follow these steps to configure frame relay address mapping:

Enter interface view Required
interface-number
fr map ip { ip-address
[ ip-mask ] | default } Optional
Add a static address map entry dlci-number [ broadcast | The system has no static
[ nonstandard | ietf ] | address map entries by default.
compression { frf9 | iphc } ] *
Enable InARP to set up Optional

fr inarp [ ip [ dlci-number ] ]
dynamically address mapping InARP is enabled by default.
Configuring Frame Relay Local Virtual Circuit
Overview
When the frame relay interface type is DCE or NNI, the interface (either main interface or subinterface)
need to be manually configured with virtual circuits. When the frame relay interface type is DTE, for the
main interface, the virtual circuit can be determined by the system according to the peer device or
through manual configuration; for subinterface, it is required to manually configure virtual circuits.
A virtual circuit number is unique on a physical interface.
Follow these steps to configure frame relay local virtual circuit

interface-number
1-5
Required
Configure a virtual circuit on an
fr dlci dlci-number There is no virtual circuit on
interface
interface by default.
Configuring Frame Relay Switching
Overview
A device with frame relay switching function enabled can act as a frame relay switch. In this scenario,
the frame relay interface should be NNI or DCE and it is required to perform corresponding
configuration on the two or more interfaces used for frame relay switching before the frame relay
switching function can work.
To configure frame relay switching, you can configure static routes for frame relay switching in interface
view or configure PVC for frame relay switching in system view.
Follow these steps to configure frame relay switching:

Enable frame relay switching fr switching Required
interface-number
Required
The default frame relay interface
Set the type of an interface for type is DTE, which means the
fr interface-type { dce |
frame relay switching to NNI system disables frame relay
nni }
or DCE switching by default.
Frame relay switching is unavailable
to DTEs.
1-6
Required
Configure There is no static route configured
static routes fr dlci-switch in-dlci for frame relay switching by default.
for frame interface interface-type The arguments in-dlci and out-dlci
relay interface-number dlci used for configuring frame relay
switching in out-dlci switching must have been
interface view configured on corresponding
interface.
Configure
frame relay quit —
switching
(either by fr switch name interface
configuring interface-type
static route or interface-number dlci dlci1 Required
PVC) Configure interface interface-type
PVC for frame interface-number dlci dlci2
relay
switching in Optional
system view fr switch name Enter frame relay switching PVC
view
Optional
undo shutdown
Enable the current switching PVC
Configuring Frame Relay Subinterface
Overview
The frame relay module has two types of interfaces: main interface and subinterface. The subinterface
is of logical structure, which can be configured with protocol address and virtual circuit. One physical
interface can include multiple subinterfaces, which do not exist physically. However, for the network
layer, the subinterface and main interface make no difference and both can be configured with virtual
circuits to connect to remote devices.
The subinterface of frame relay falls into two types: point-to-point (P2P) subinterface and
point-to-multipoint (P2MP) subinterface. A P2P subinterface is used to connect a single remote device
and a P2MP subinterface is used to connect multiple remote devices. A P2MP subinterface can be
configured with multiple virtual circuits, each of which sets up an address map with its connected
remote network address to distinguish different connections. Address maps can be set up manually or
dynamically set up by InARP.
The methods to configure a virtual circuit and address map for P2P subinterfaces and P2MP
subinterfaces are different, as described below.
z P2P subinterface
Since there is only one peer address for a P2P subinterface, the peer address is determined when a
virtual circuit is configured for the subinterface. You therefore do not need to configure dynamic or static
address mapping for P2P subinterface.
z P2MP subinterface
For a P2MP subinterface, a peer address can be mapped to the local DLCI through static address
mapping or InARP which only needs to be configured on the main interface. If static address mapping is
required, it is necessary to set up static address map for each virtual circuit.
1-7
Follow these steps to configure a frame relay subinterface:

interface interface-type Required

Create a subinterface and
interface-number.subnumber The type of a frame relay
enter subinterface view
[ p2mp | p2p ] subinterface is p2mp by default.
Configure a virtual circuit on a See Configuring Frame

Required
frame relay subinterface Relay Local Virtual Circuit.
Optional
See Configuring Frame
Configure address mapping For P2MP subinterface, it is
Relay Address Mapping.
required to set up address map.
Configuring Frame Relay over IP Network
Overview
With the increasingly wide application of IP network, internetworking of frame relay networks needs to
be realized through Frame Relay over IP, which creates generic routing encapsulation (GRE) tunnel
between frame relay networks at two ends and transmits frame relay packets through the GRE tunnel,
as illustrated below:
Figure 1-2 Typical implementation diagram of Frame Relay over IP
The frame relay packets transmitted through GRE tunnel fall into three categories: FR packet and
InARP packet, both of which have IP header encapsulated, and LMI packet used to negotiate virtual
circuit status in GRE tunnel.
Follow these steps to configure frame relay over IP network:

Create a tunnel interface

For detailed information about
in system view and
tunnel interface configuration,
perform corresponding Required
refer to GRE Configuration in
configuration on the tunnel
the VPN Volume.
interface
1-8
Enable frame relay
fr switching Required
switching
Configure interface interface-type
static —
interface-number
routes for
frame relay
fr dlci-switch in-dlci interface Required
switching in
interface tunnel interface-number dlci There is no static route for frame
Configure
view out-dlci relay switching by default.
frame relay
switching
fr switch name interface Required
either by
interface-type interface-number
static Configure There is no PVC for frame relay
dlci dlci1 interface tunnel
routes or by PVC for switching by default.
interface-number dlci dlci2
PVC frame relay
switching in fr switch name Optional
system
view Optional
undo shutdown After a PVC is created, its status is
up by default.
z Before configuring frame relay over IP network, it is necessary to create and configure a tunnel
interface. After the setup of a GRE tunnel interface, you can specify the tunnel interface to be used
by frame relay switching to implement frame relay packets over IP network.
z You need to configure a static route for frame relay switching in frame relay interface view or
multilink frame relay (MFR) interface view at both ends of GRE tunnel, or configure PVC for frame
relay switching in system view. After frame relay routes have been configured, two route entries
will be added into the frame relay routing table of the router. In one route entry, the ingress
interface is a tunnel interface and the egress interface is frame relay interface. In the other route
entry, the ingress interface is a frame relay interface and the egress interface is a tunnel interface.
On the tunnel interface, a virtual circuit whose DLCI number is out-dlci will be generated. The
status of this virtual circuit determines the status of the above mentioned routes.
z The virtual circuit used for frame relay switching must be configured on the tunnel interfaces at
both ends of the GRE tunnel, and the DLCI number (out-dlci) on the tunnel interfaces must be the
same.
Configuring X.25 Parameters for a VC
Overview
As frame relay is designed to transmit data over reliable links, it invokes no transmission
acknowledgement mechanism and data transmission in a frame relay network is thus unreliable. To
make sure the call signaling messages used to dynamically establish/tear down links can be
transmitted reliably, X.25 is used. In this case, the transmission acknowledgement mechanism in X.25
ensures call signaling messages being transmitted reliably. To achieve this, you need to configure X.25
parameters for DLCIs when you enable VoFR dynamic call or configure to use X.25 to transmit FR
data.
1-9
Follow these steps to configure X.25 parameters for a VC:
Enter system view system-view ü
Required
Create an X.25
x25 template name This operation also leads you to X.25
template
template view.
Refer to LAPB and X.25
Configure X.25-related
Configuration in the Access Optional
parameters
Volume.
Configure Refer to LAPB and X.25
LAPB-related Configuration in the Access Optional
parameters Volume.
Quit to system view quit ü
Enter interface view ü
interface-number
Required
This operation also leads you to interface
Create a VC fr dlci dlci-number DLCI view.
By default, no VC is created on an
interface.
Optional
Apply the X.25
x25-template name By default, a DLCI has no X.25 template
template
applied.
Configuring Annex G
ANSI T1.617 Annex G (Annex G for short) defines the way to transmit X.25 packets through VCs. In an
Annex G implementation, the acknowledgement/retransmission and flow-control mechanism used in
X.25 are invoked to provide reliable transmission. Annex G can also be used to connect X.25 networks
through FR networks. It is a technology that can help you to migrate from X.25 network to FR network
and thus protects the investment on X.25 effectively.
Follow these steps to configure Annex G:
interface-number
Required
Encapsulate the interface with
link-protocol fr By default, an interface is
FR
encapsulated with PPP.
1-10
Required
This operation also leads you to
Create a VC fr dlci dlci-number interface DLCI view.
By default, no VC is created on
an interface.
Configure the VC interface as
annexg { dce | dte } Required
an Annex G interface
z As Annex G is not compliant with Inverse-ARP, you need to configure a static FR mapping for the
destination IP address.
z An Annex G interface is either a DCE or a DTE. For the two Annex G interfaces of a VC, you need
to configure one as the DTE and the other as the DCE.
Configuring X.25 parameters for an Annex G interface
Follow these steps to configure X.25 parameters for an Annex G interface:
Required
Create an X.25 template x25 template { name } This command also leads you
to X.25 template view.
Configure X.25 Refer to LAPB and .25 Configuration
Optional
parameters in the Access Volume.
Configure LAPB Refer to LAPB and X.25 Configuration
Optional
parameters in the Access Volume.
Quit to system view quit ü
interface-number
Required
This operation also leads you
Create a VC fr dlci dlci-number to interface DLCI view.
By default, no VC is created
on an interface.
Apply the X.25 template

x25-template { name } Required
to the DLCI
1-11
z With FR address mapping configured in FR interface view, packets destined for the destination are
transmitted through specific DLCI. With X.25 address mapping configured in X.25 template view, a
call to the specific X.25 address is launched before a packet is sent to the destination IP address.
IP packets can be transmitted correctly only when the both types of address mappings are
configured.
z The configuration performed in X.25 template view is similar to that performed in X.25 interface
view. To establish an X.25 link successfully, the configurations on the devices of both sides need
to be consistent with each other.
Configuring DCE Side Frame Relay

Configuring Basic DCE Side Frame Relay
Follow these steps to configure DCE side frame relay:

interface-number
Required
Configure interface The link layer protocol for interface
link-protocol fr encapsulation is PPP by default.
encapsulation protocol as
[ nonstandard | ietf ] When frame relay protocol is used
frame relay
for interface encapsulation, the
default operating mode is IETF.
Required
Configure the frame relay fr interface-type { dce |
interface type to DCE or NNI nni } The default frame relay interface
type is DTE.
Optional
Configure the frame relay LMI fr lmi type { ansi |
protocol type nonstandard | q933a } The default frame relay LMI protocol
type is q933a.
Optional
Configure network side N392 fr lmi n392dce n392-value
Optional
Configure network side N393 fr lmi n393dce n393-value
Optional
Configure network side T392 fr lmi t392dce t392-value
The default value is 15 seconds.
Configuring Frame Relay Address Mapping
Refer to Configuring Frame Relay Address Mapping.
1-12
Configuring Frame Relay Local Virtual Circuit
Refer to Configuring Frame Relay Local Virtual Circuit.
Configuring Frame Relay Switching
Refer to Configuring Frame Relay Switching.
Configuring Frame Relay Subinterface
Refer to Configuring Frame Relay Subinterface.
Configuring Frame Relay over IP Network
Refer to Configuring Frame Relay over IP Network.
Configuring X.25 parameters for a VC
Refer to Configuring X.25 Parameters for a VC.
Configuring Annex G
Refer to Configuring Annex G.
Enabling Trap
Frame relay with trap enabled can generate traps of level 5 (notifications) for reporting important events
on frame relay. The generated trap messages are sent to the information center of the device. You can
configure the output rules for traps on the information center. For detailed information, refer to
Information Center Configuration in the System Volume.
Follow these steps to enable trap:

Enable trap for frame Optional

snmp-agent trap enable fr
relay By default, trap is disabled for frame relay.
For detailed information about the snmp-agent trap enable fr command. Refer to the snmp-agent
trap enable command in SNMP Commands in the System Volume.
1-13
Displaying and Maintaining Frame Relay
display fr interface Available in any view

Display frame relay [ interface-type Either all the information or the
protocol status on an { interface-number | information of specified interfaces can
interface interface-number.subnumb be shown. The specified interface can
er } ] be either main interface or subinterface.
display fr map-info Available in any view

Display the mapping table [ interface interface-type Either all the information or the
of protocol address and { interface-number | information of specified interfaces can
frame relay address interface-number.subnumb be shown. The specified interface can
er } ] be either main interface or subinterface.
Display receiving/sending
display fr lmi-info Either all the information or the
statistics information of
[ interface interface-type information of specified interfaces can
frame relay LMI type
interface-number ] be shown. Only main interface can be
messages
specified.
Display frame relay data display fr statistics Either all the information or the
receiving/sending [ interface interface-type information of specified interfaces can
statistics information interface-number ] be shown. Only main interface can be
specified.
display fr pvc-info Available in any view

Display frame relay [ interface interface-type Either all the information or the
permanent virtual circuit { interface-number | information of specified interfaces can
table interface-number.subnumb be shown. The specified interface can
er } ] [ dlci-number ] be either main interface or subinterface.
Display statistics display fr inarp-info Either all the information or the
information of frame relay [ interface interface-type information of specified interfaces can
InARP messages interface-number ] be shown. Only main interface can be
specified.
Display the information of display fr dlci-switch
configured frame relay [ interface interface-type Available in any view
switching interface-number ]
Display the configuration display x25 template

of an X.25 template [ name ]
Clear all the automatically

established frame relay reset fr inarp Available in user view
address mappings
reset fr pvc interface

Clear the statistics on an
serial interface-number Available in user view
FR PVC
[ dlci dlci-number ]
Frame Relay Configuration Examples

This section provides these examples:
z Interconnecting LANs through the Frame Relay Network
z Interconnecting LANs through Dedicated Line
1-14
z Interconnecting LANs through an Annex G DLCI
Interconnecting LANs through the Frame Relay Network
Interconnect LANs through the public frame relay network. In this implementation, the routers can only
work as user equipment working in the frame relay DTE mode.
Network diagram
Figure 1-3 Network diagram for connecting LANs through a frame relay network
# Assign an IP address to interface serial 2/0.
[RouterA-Serial2/0] ip address 202.38.163.251 255.255.255.0
# Configure interface encapsulation protocol as frame relay.

[RouterA-Serial2/0] link-protocol fr
[RouterA-Serial2/0] fr interface-type dte
# If the opposite router supports InARP, configure dynamic address mapping.

[RouterA-Serial2/0] fr inarp
# Otherwise, configure static address mapping.

[RouterA-Serial2/0] fr map ip 202.38.163.252 50
[RouterA-Serial2/0] fr map ip 202.38.163.253 60
# Assign an IP address.
[RouterB-Serial2/0] ip address 202.38.163.252 255.255.255.0
# Configure interface encapsulation protocol as frame relay.

[RouterB-Serial2/0] link-protocol fr
[RouterB-Serial2/0] fr interface-type dte
1-15
[RouterB-Serial2/0] fr inarp

[RouterB-Serial2/0] fr map ip 202.38.163.251 70
[RouterC] interface serial 2/0
[RouterC-Serial2/0] ip address 202.38.163.253 255.255.255.0
# Configure the interface encapsulation protocol as frame relay.

[RouterC-Serial2/0] link-protocol fr
[RouterC-Serial2/0] fr interface-type dte

[RouterC-Serial2/0] fr inarp

[RouterC-Serial2/0] fr map ip 202.38.163.251 80
Interconnecting LANs through Dedicated Line
Two routers are directly connected through a serial interface. Router A works in the frame relay DCE
mode, and Router B works in the frame relay DTE mode.
Network diagram
Figure 1-4 Network diagram for interconnecting LANs through a dedicated line
Approach I: On main interfaces

# Configure the link layer protocol on the interface to frame relay in DCE mode.
[RouterA-Serial2/0] fr interface-type dce
# Configure a local virtual circuit.

[RouterA-Serial2/0] fr dlci 100
1-16
# Set the link layer protocol on the interface to frame relay.

Approach II: On subinterfaces

# Set the link layer protocol on the interface to frame relay and interface type to DCE.
[RouterA-Serial2/0] fr interface-type dce
# Configure the IP address of the subinterface and local virtual circuit.

[RouterA] interface serial 2/0.1 p2p
[RouterA-Serial2/0.1] ip address 202.38.163.251 255.255.255.0
[RouterA-Serial2/0.1] fr dlci 100
# Set the link layer protocol on the interface to frame relay and interface type to DTE.
# Configure IP address of the subinterface and local virtual circuit.

[RouterB] interface serial 2/0.1 p2p
[RouterB-Serial2/0.1] ip address 202.38.163.252 255.255.255.0
[RouterB-Serial2/0.1] fr dlci 100
Interconnecting LANs through an Annex G DLCI
Netwowork requirements
Two routers, Router A and Router B, are connected through their serial interfaces. Router A operates
as the DCE side; Router B operates as the DTE side.
Network diagram
Figure 1-5 Network diagram for interconnecting LANs through an Annex G DLCI
1-17
# Create an X.25 template.
[RouterA] x25 template vofr
# Configure the local X.25 address.

[RouterA-x25-vofr] x25 x121-address 10094
# Configure the X.25 address mapping to the destination IP address.

[RouterA-x25-vofr] x25 map ip 202.38.163.252 20094
[RouterA-x25-vofr] quit
# Assign an IP address to the local interface.

[RouterA–Serial2/0] ip address 202.38.163.251 255.255.255.0
# Encapsulate the interface with FR.

[RouterA–Serial2/0] link-protocol fr
[RouterA–Serial2/0] fr interface-type dce
# Create a DLCI interface.

[RouterA–Serial2/0] fr dlci 100
# Configure the DLCI interface as an Annex G interface.

[RouterA-fr-dlci-Serial2/0-100] annexg dce
# Apply the X.25 template to the DLCI interface.

[RouterA-fr-dlci-Serial2/0-100] x25-template vofr
[RouterA-fr-dlci-Serial2/0-100] quit
# Configure the FR address mapping to the destination IP address.

[RouterA–Serial2/0] fr map ip 202.38.163.252 100
# Create an X.25 template.
[RouterB] x25 template vofr
# Configure the local X.25 address.

[RouterB-x25-vofr] x25 x121-address 20094
# Configure the X.25 address mapping to the destination IP address.

[RouterB-x25-vofr] x25 map ip 202.38.163.251 10094
[RouterB-x25-vofr] quit
# Assign an IP address to the local interface.

[RouterB–Serial2/0] ip address 202.38.163.252 255.255.255.0
# Encapsulate the interface with FR.

[RouterB–Serial2/0] link-protocol fr
[RouterB–Serial2/0] fr interface-type dte
1-18
# Create an FR DLCI interface.
[RouterB–Serial2/0] fr dlci 100
# Configure the DLCI interface as an Annex G DLCI interface.

[RouterB-fr-dlci-Serial2/0-100] annexg dte
# Apply the X.25 Template to the DLCI interface.

[RouterB-fr-dlci-Serial2/0-100] x25-template vofr
[RouterB-fr-dlci-Serial2/0-100] quit
# Configure the FR address mapping to the destination IP address.

[RouterB–Serial2/0] fr map ip 202.38.163.251 100
Troubleshooting Frame Relay

Symptom 1:
The physical layer is in down status.
Solution:
z Check whether the physical line is normal.
z Check whether the remote device runs normally.
Symptom 2:
The physical layer is already up, but the link layer protocol is down.
Solution:
z Ensure that both local device and remote device have been encapsulated with frame relay
protocol.
z If two devices are directly connected, check the local device and remote device to ensure that one
end is configured as frame relay DTE interface and the other end as frame relay DCE interface.
z Ensure that the LMI protocol type configuration at the two ends is the same.
z If the above conditions are satisfied, enable the monitoring function for the frame relay LMI
messages to see whether one Status Request message corresponds to one Status Response
message. If not, it indicates the physical layer data is not received/sent correctly. Check the
physical layer. The debugging fr lmi command is used to enable the monitoring function for frame
relay LMI messages.
Symptom 3:
The link layer protocol is up, but the remote party cannot be pinged.
Solution:
z Ensure that the devices at both ends have configured (or created) correct address mapping for the
peer.
z Ensure that there is a route to the peer if the devices are not in the same subnet segment.
Frame Relay Compression

This section covers these topics:
z Overview
z Configuring FRF.9 Compression
z Configuring FRF.20 IP Header Compression
z Displaying and Maintaining Frame Relay Compression
1-19
z Frame Relay FRF.9 Stack Compression Configuration Example
Overview
Frame relay compression technique can be used to compress frame relay packets to save network
bandwidth, reduce network load and improve the data transfer efficiency on the frame relay network.
The device supports FRF.9 stac compression (referred to as FRF.9) and FRF.20 IP header
compression (IPHC), which is referred to as FRF.20.
FRF.9
FRF.9 classifies packets into two types: control packets and data packets. Control packets are used for
status negotiation between the two ends of DLCI where the compression protocol has been configured.
FRF.9 data packets cannot be switched before the negotiation succeeds. If the negotiation fails after 10
attempts to send FRF.9 control packet are made, the negotiating parties stop negotiation and the
compression configuration does not take effect.
FRF.9 compresses only data packets and InARP packets; it does not compress LMI packets.
FRF.20
FRF.20 compresses the IP header of packets transmitted over frame relay. For example, you may use
it to compress voice packets to save bandwidth, decrease load, and improve transmission efficiency on
a frame relay network.
FRF.20 classifies packets into control packets and data packets. Control packets are sent between
FRF.20-enabled interfaces to negotiate status information. The interfaces cannot exchange FRF.20
data packets before the negotiation succeeds. If the negotiation fails after 10 attempts to send control
packets are made, the interfaces stop negotiation and their compression settings do not take effect.
FRF.20 compresses only RTP packets and TCP ACK packets.
Configuring FRF.9 Compression
Frame relay main interface is a P2MP interface, while frame relay subinterface includes two types: P2P
and P2MP. Therefore, the configuration of frame relay FRF.9 compression varies by different interface
types. For a P2P subinterface, use the fr compression frf9 command to enable FRF.9 compression in
subinterface view. For a P2MP frame relay interface or subinterface, the frame relay compression is
configured when creating static address mapping.
Follow these steps to configure FRF.9 compression:

Enter frame relay interface or subinterface interface-number
—
view or interface serial
interface-number.subnumber
1-20
Optional
Configure For P2P subinterface, FRF.9
FRF.9 fr compression frf9 compression is
enable FRF.9 compression
compression disabled by
(select either default.
one according
For a P2MP interface, fr map ip { ip-address [ ip-mask ] |
to interface
type) enable FRF.9 compression default } dlci-number [ broadcast
Optional
when creating static | [ ietf | nonstandard ] ] *
address mapping compression frf9
Configuring FRF.20 IP Header Compression
The frame relay function provides IP header compression including RTP/TCP header compression.
You can enable IP header compression on interfaces or when configuring static address mapping.
Follow these steps to configure FRF.20 IP header compression:

interface-number
Optional
Eanble FRF.20
IP header fr compression iphc FRF.20 IP header
compression on compression is disabled
an interface and on interface by default.
Configure provide FRF.20 Optional
IP header fr iphc { nonstandard |
FRF.20 IP rtp-connections number1 | FRF.20 IP header
header compression
option tcp-connections number2 | compression option is not
compression tcp-include } provided by default.
(select either
method) Enable FRF.20
fr map ip { ip-address [ ip-mask ] Optional
IP header
| default } dlci-number
compression The system does not
[ broadcast ] [ ietf |
when creating a have static address
nonstandard ] compression
static address mapping by default.
iphc
mapping
Displaying and Maintaining Frame Relay Compression

display fr compress
Display statistics information
[ interface interface-type Available in any view
about FRF.9 compression
interface-number ]
Display statistics information display fr iphc [ interface
about FRF.20 IP header interface-type Available in any view
compression interface-number ]
1-21
Frame Relay FRF.9 Stack Compression Configuration Example
Router A and Router B are connected through the frame relay network and frame relay compression
function (FRF.9) is enabled between them.
Network diagram
Figure 1-6 Network diagram for frame relay compression
[RouterA-Serial2/0] fr map ip 10.110.40.2 100 compression frf9
[RouterB-Serial2/0] fr map ip 10.110.40.1 100 compression frf9
3) Verify the configuration:
# Ping Router B from Router A.
<RouterA> ping 10.110.40.2

0.00% packet loss
# Display statistics about packet compression on Router A.

<RouterA> dis fr compress
Serial2/0
1-22
-DLCI:100
enable frame-relay compression
uncompressed bytes send/receive : 595/595
compressed bytes send/receive : 159/157
1 min avg ratio send/receive : 0.000/0.000
5 min avg ratio send/receive : 0.267/0.264
Frame Relay FRF.20 IP Compression Configuration Example
Router A and Router B are interconnected through a frame relay network. Enable FRF.20 IP
compression on the two routers.
Network diagram
Figure 1-7 Network diagram for frame relay compression
[RouterA-Serial2/0] fr compression iphc
[RouterA-Serial2/0] fr iphc tcp-include
[RouterB-Serial2/0] fr compression iphc
[RouterB-Serial2/0] fr iphc tcp-include
3) Verify the configuration:
# Ping Router B from Router A.
<RouterA> ping 10.110.40.2
1-23

0.00% packet loss
# Telnet to Router A from Router B.

<RouterB> telnet 10.110.40.1
Trying 10.110.40.1
Press CTRL+K to abort
Connected to 10.110.40.1
**************************************************************************
* Copyright (c) 2004-2007 Hangzhou Tech. Co., Ltd. All rights reserved. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
**************************************************************************
# Display statistics about packet compression on Router A.

<RouterA> dis fr iphc
Serial2/0 -DLCI:111
RTP header compression information:
Compression:
Total packets: 0 , Packets compressed: 0
Link searches: 0 , Search missed : 0
Bytes saved : 0 , Bytes sent : 0
Decompression:
Errors : 0
Compression-connections: 16 , Decompression-connections: 16
Information of TCP header compression:

Compression:
Link searches: 0 , Search Missed : 1
Bytes saved : 348 , Bytes sent : 575
Decompression:
Errors : 0
Compression-connections: 16 , Decompression-connections: 16
1-24
2 Multilink Frame Relay Configuration
When performing multilink frame relay configuration, go to these sections for information you are
interested in:
z Overview
z Configuring Multilink Frame Relay
z Displaying and Maintaining Multilink Frame Relay
z Multilink Frame Relay Configuration Example
Overview
Multilink frame relay (MFR) is a cost effective bandwidth solution for frame relay users. Based on the
FRF.16 protocol of the frame relay forum, it implements the MFR function on DTE/DCE interfaces.
MFR function provides a kind of logic interface, namely MFR interface. The MFR interface is composed
of multiple frame relay physical links bound together, so as to provide high-speed and broadband links
on frame relay networks.
To maximize the bandwidth of bundled interface, it is recommended to bundle physical interfaces of the
same rate for the same MFR interface when configuring the MFR interface so as to reduce
management cost.
Bundle and bundle link
Bundle and bundle link are two basic concepts related to MFR.
One MFR interface corresponds to one bundle, which may contain multiple bundle links. One bundle
link corresponds to one physical interface. A bundle manages its bundle links. The interrelationship
between bundle and bundle link is illustrated as follows:
Figure 2-1 Illustration of bundle and bundle links
For the actual physical layer, a bundle link is visible; while for the actual data link layer, bundle is visible.
MFR interface and physical interface
An MFR interface is a kind of logic interface. Multiple physical interfaces can be bundled into one MFR
interface. One MFR interface corresponds to one bundle and one physical interface corresponds to one
bundle link. The configuration on a bundle and bundle links is actually configuration on an MFR
interface and physical interfaces.
2-1
The function and configuration of the MFR interface is the same with that on the FR interface in
common sense. Like the FR interface, the MFR interface supports DTE and DCE interface types as
well as QoS queue mechanism. After physical interfaces are bundled into an MFR interface, their
original network layer and frame relay link layer parameters become ineffective and they use the
parameter settings of the MFR interface instead.
Configuring Multilink Frame Relay

Follow these steps to configure multilink frame relay:

Optional
Enable the newly added
operations for the protocol By default, a physical interface bound to
mfr an MFR bundle acts as those defined in
state machine defined in
stateup-respond-addli FRF.16.1 standard, that is, it does not
FRF.16.1 standard
nk respond to received requests for
concerning multilink Frame
Relay link integrity establishing links when it is in protocol
up state.
interface mfr Required

Create MFR interface and { interface-number |
enter MFR interface view interface-number.subnu MFR interface or subinterface is not
mber } created by default.
Optional
By default, the bundle identifier is mfr +
frame relay bundle number. It is of local
Configure the MFR bundle mfr bundle-name
significance only.
identifier [ name ]
In spite of the default bundle identifier,
you cannot configure a bundle identifier
as a string in the form of mfr + number.
Optional
Configure MFR fragmentation mfr fragment Fragmentation is disabled on MFR
bundles by default.
Optional
Configure the size of the MFR mfr window-size The size of the MFR sliding window is
sliding window number equal to the number of physical
interfaces bundled by MFR by default.
Optional
Configure maximum fragment
mfr fragment-size bytes The maximum fragment is of 300 bytes
size for bundle link
by default.
Configure other parameters of See Frame Relay
Optional
MFR interface Configuration Task List.
Enter specified interface view —
interface-number
Required
Bundle the current interface to link-protocol fr mfr
a specified MFR interface interface-number An interface is not bundled with any
MFR interface by default.
2-2
Optional
Configure the MFR bundle
mfr link-name [ name ] The bundle link identifier is the name of
link identifier
the current interface by default.
Configure hello message Optional

sending period of MFR bundle mfr timer hello seconds The hello message sending period of
link the bundle link is 10 seconds by default.
Configure waiting time before Optional

MFR bundle link resends mfr timer ack seconds The waiting time before resending hello
hello messages message is 4 seconds by default.
Optional
The maximum fragment size is 300
Configure maximum fragment bytes. The priority of fragment size
mfr fragment-size bytes
size for bundle link configured in frame relay interface view
is higher than that in MFR interface
view.
Configure the maximum times Optional

that MFR bundle link can mfr retry number The hello message can be resent 2
resend hello messages times at the maximum by default.
Displaying and Maintaining Multilink Frame Relay

Display configuration and display interface mfr

status of an MFR interface [ interface-number ]
Display configuration and display mfr [ interface

statistics information of an MFR interface-type interface-number Available in any view
bundle and bundle links | verbose ]
Multilink Frame Relay Configuration Example

MFR Direct Connection Configuration Example
Router A and Router B are directly connected through Serial 2/0 and Serial 2/1. The frame relay
protocol is used to bundle the two serial ports to provide broader bandwidth.
Network diagram
Figure 2-2 Network diagram of MFR direct connection
2-3
# Create and configure MFR interface 4 (MFR4)
[RouterA] interface mfr 4
[Router`A-MFR4] ip address 10.140.10.1 255.255.255.0
[RouterA-MFR4] fr interface-type dte
[RouterA-MFR4] fr map ip 10.140.10.2 100
[RouterA-MFR4] quit
# Bundle Serial 2/0 and Serial 2/1 to MFR4.

[RouterA-Serial2/0] link-protocol fr mfr 4
# Create and configure MFR interface 4 (MFR4).
[RouterB] interface mfr 4
[RouterB-MFR4] ip address 10.140.10.2 255.255.255.0
[RouterB-MFR4] fr interface-type dce
[RouterB-MFR4] fr dlci 100
[RouterB-fr-dlci-MFR4-100] quit
[RouterB-MFR4] fr map ip 10.140.10.1 100
[RouterB-MFR4] quit
# Bundle Serial 2/0 and Serial 2/1 to MFR4.

[RouterB-Serial2/0] link-protocol fr mfr 4
MFR Switched Connection Configuration Example
Router A and Router C are connected through MFR to Router B where MFR switching is enabled.
Network diagram
Figure 2-3 Network diagram for MFR switching
2-4
# Configure interface MFR1.
[RouterA] interface mfr 1
[RouterA-MFR1] ip address 1.1.1.1 255.0.0.0
[RouterA-MFR1] quit
# Add Serial 2/0 and Serial 2/1 to interface MFR1.

# Enable frame relay switching.
[RouterB] fr switching

[RouterB-MFR1] quit

[RouterB-MFR2] quit

[RouterB] quit

[RouterB-Serial 2/2] li quit
2-5
# Configure static route for frame relay switching.
[RouterB] fr switch pvc1 interface mfr 1 dlci 100 interface mfr 2 dlci 200
[RouterC] interface mfr 2
[RouterC-MFR2] ip address 1.1.1.2 255.0.0.0
[RouterC-MFR2] quit

[RouterC-Serial2/0] link-protocol fr mfr 2
[RouterC-Serial2/0] quit
[RouterC-Serial2/1] link-protocol fr mfr 2
2-6
3 PPPoFR Configuration
When performing PPPoFR configuration, go to these sections for information you are interested in:
z Overview
z Configuring PPPoFR
z Displaying and Maintaining PPPoFR
z PPPoFR Configuration Example
Overview
PPP over frame relay (PPPoFR) enables routers to establish end-to-end PPP sessions on a frame
relay network, allowing frame relay stations to use PPP features such as LCP, NCP, authentication, and
MP fragmentation.
Configuring PPPoFR
Follow these steps to configure PPPoFR:

Create a virtual template

interface virtual-template
interface and the virtual —
interface-number
template interface view
Assign IP address ip address ip-address ip-mask Required
Return to system view quit Required

Enter the corresponding frame interface interface-type
—
relay interface interface-number
Configure the interface
encapsulation protocol to frame link-protocol fr Required
relay
Required (optional for DTE
Configure a frame relay DLCI fr dlci dlci-number
side)
fr map ppp dlci-number

Map frame relay DLCI to PPP interface virtual-template Required
interface-number
As for the next hop and the outbound interface, only the former is required when you configure a static
route on a virtual-template interface. If you want to specify the outbound interface as well, make sure
the physical interface bound to the virtual-template interface is valid.
3-1
Displaying and Maintaining PPPoFR
display fr map-info pppofr
Display PPPoFR MAP and
[ interface interface-type Available in any view
status
interface-number ]
PPPoFR Configuration Example

Router A and Router B connect through the frame relay network, and enable PPPoFR between them.
Network diagram
Figure 3-1 Network diagram of PPPoFR
# Create and configure virtual template interface Virtual-Template 1.

# Create PPP mapping on Serial 2/0.

[RouterA-Serial2/0] fr map ppp 16 interface virtual-template 1

[RouterB-Serial2/0] fr interface-type dce
# Create DLCI 16.

[RouterB-Serial2/0] fr dlci 16
3-2
[RouterB-fr-dlci-Serial2/0-16] quit
# Create PPP map on Serial 2/0.

[RouterB-Serial2/0] fr map ppp 16 interface virtual-template 1
3-3
4 MPoFR Configuration
When performing MPoFR configuration, go to these sections for information you are interested in:
z Overview
z Configuring MPoFR
z MPoFR Configuration Example
Overview
Multilink PPP over frame relay (MPoFR) is PPPoFR making use of MP fragments to transmit MP
fragments over frame relay stations.
In MPoFR configuration, first configure PPPoFR on two or more virtual templates (it is not necessary to
configure an IP address on virtual templates), and then perform the following configurations on these
virtual templates to bind them to another virtual template with PPP MP.
Configuring MPoFR
Follow these steps to configure MPoFR:

Create a PPP MP virtual interface virtual-template
—
template interface interface-number-mp
Optional
Configure the maximum
bandwidth available for qos max-bandwidth bandwidth For virtual template, the
the current interface default maximum
bandwidth is 64 kbps.
Assign an IP address to
ip address ip-address ip-mask Required
the current interface
4-1
Create virtual
template interface interface
and enter the virtual-template —
virtual template interface-number
interface view
Configure MP on ppp mp
virtual template virtual-template Required
interface interface-number-mp
Quit to system
quit —
view
Configure PPPoFR on Enter the
two or more virtual interface
corresponding
templates, and bind to interface-type —
frame relay
virtual template interface interface-number
interface
configured with PPP MP
Configure frame
relay as the link link-protocol fr Required
protocol
Configure a frame Required

fr dlci dlci-number
relay DLCI (optional for DTE side)
fr map ppp
dlci-number
Map frame relay
interface Required
DLCI to PPP
virtual-template
interface-number
z To ensure packet transmission quality over virtual-template (VT) interfaces, you can configure
queue-independent QoS features on a VT interface and queue-dependent QoS features on an FR
interface. For detailed information, refer to QoS Configuration in the QoS Volume.
z As for the next hop and the outbound interface, only the former is required when you configure a
static route on a virtual-template interface. If you want to specify the outbound interface as well,
make sure the physical interface bound to the virtual-template interface is valid.
z Refer to PPP Configuration in the Access Volume for information about MP-related configuration.
MPoFR Configuration Example

ATM backbone network uses FR network as the access network to support transmission of multiple
services. A single virtual circuit of an FR link can transport multiple kinds of service data.
As shown in the network diagram, the bandwidth of Router A Serial2/0 is 64kpbs. Host A sends data
service stream 1 to Host C, Host B sends data service stream 2 to Host D and there is also a voice
service stream.
4-2
The bandwidth of Router B Serial2/0 is 64kbps. Host C sends data service stream 3 to Host A, Host D
sends data service stream 4 to Host B, and there is also a voice service stream.
To ensure voice quality, it is required to fragment the data packets to reduce voice jitter caused by
transmission delay. MPoFR is adopted here, and MP is used to fragment data packets.
Network diagram
Figure 4-1 Network diagram for MPoFR implementation
This example only covers PPPoFR related configuration. You need to perform other configurations on
services and routes.
[RouterA] interface irtual-template 1
[RouterA-Virtual-Template1] ppp mp virtual-template 3

[RouterA-Virtual-Template2] ppp mp virtual-template 3

[RouterA-Virtual-Template3] ppp mp lfi
4-3
IP Routing
Module 3
IP Routing
After completing this section, you should be able to:
Describe and explain OSPF in broadcast networks and configure it in A-Series
switches and routers
Describe and explain OSPF in point to point networks and configure it in A-
Series switches and routers
Describe and explain OSPF over NMBAs and point to multipoint networks and
configure it in A-Series switches and routers
Describe and explain different OSPF area types and configure them in A-Series
switches and routers
Describe and explain eBGP and its interaction with OSPF
Configure different options of the interaction between eBGP and OSPF in A-
Series switches and routers
Agenda
Activity 3.1: OSPF network types
Activity 3.2: Multi-area OSPF
Activity 3.3: eBGP
Activity 3.4: Lab
References
in Appendix 3A:
OSPF H3C MSR Router 03 – IP Routing
BGP H3C MSR Router 03 – IP Routing
Rev. 11.21 3 –1
Activity 3.1: OSPF Network Types

Introduction
OSPF requires the establishment and maintenance of neighbor relationships to
exchange routing information
This process differs depending on the underlying Layer 2 protocol and topology
Four cases:
x Broadcast network: Ethernet LAN
x NBMA: Frame Relay – full mesh
x Point to Multi-point (p2mp): Frame Relay – partial mesh
x Point to Point (p2p): PPP
3 –2 Rev. 11.21
IP Routing

Introduction
below)
question
Question1:
What is an LSA?
Complete the following table:
LSA Type LSA Type Describes? Created by

Number Name
1
2
3
4
5
7
Rev. 11.21 3 –3
Question 2:
Describe the function of the OSPF packet types: Hello, DD, LSR, LSU, and LSAck.
Hello
DD
LSR
LSU
LSAck
Question 3:
1. What is the difference between neighbor and adjacent?
2. How do you know if two neighbors are adjacent?
Question 4:
In a broadcast network an OSPF router can be a DR (Designated Router), BDR
(Backup DR) or DROther.
Why are these roles assigned?
3. How many routers can be in each role?
4. What is the expected final state of the relation between the different roles?
DR-DROther
BDR-DROther
DROther-DROther
5. How can you influence the DR election?
3 –4 Rev. 11.21
IP Routing
Question 5:
1. What is an NBMA?
2. What layer 2 protocols do they apply to?
3. What is the primary requirement for a layer 2 network to be an NBMA?
4. What network type can be used when the NBMA primary requirement is not
met?
Question 6:
Fill the blanks in the following table.
Default Correct Peer
Layer 2 Uses
Network Network command
Protocol DR/BDR?
Type Type required
Ethernet
PPP
Frame Relay (Full mesh)
Frame Relay (Partial mesh)
Table 3.1: Network types
Question 6: IPv4 packet types: Unicast, Multicast or Broadcast?

OSPF uses, in general, multicast packets to communicate between peers. Which
network type does must use unicast packets?
Rev. 11.21 3 –5
Activity 3.2: Multi-area OSPF Review

Introduction
Multi-area OSPF
Problem: When the number of routers and/or networks in an AS is large:
x Each router must build and process a large LSDB
x The LSDB occupies a large amount of memory
x The SPF computation takes a long time and requires many CPU resources
x Network convergence is slower
Solution:
x Split the AS in a Areas
IMPORTANT
x The SPF algorithm is only used inside an area
x For inter-area routing, a mechanism similar to Distance Vector is used
Router Roles
Figure 3.2.1: OSPF Router Roles (in terms of areas)
3 –6 Rev. 11.21
IP Routing

Introduction
below)
question
Question 1: Virtual link

1. When is it necessary and why?
2. Describe its typical application.
Identify the routers that must be connected by a virtual link in Figure 3.2.1
Rev. 11.21 3 –7
Question 2: Stub area

1. What conditions must an area meet to qualify as a stub area?
2. Once the area has been configured as stub, what advantages does it have?
3. Identify the area(s) that should be configured as Stub Area(s) in Figure 3.2.1
Question 3: NSSA
What is an NSSA? Describe it and compare it to a stub area.
Identify the area(s) that should be configured as NSSA(s) in Figure 3.2.1
Question 4:
What are the four route types? Describe them.
3 –8 Rev. 11.21
IP Routing
OSPF Configuration in A-Series switches and routers

Basic Functions
To configure OSPF basic functions take the following steps:
1. Configure all layer 2 interfaces and assign them an IP address
2. Enable OSPF - optionally include a Router-ID (recommended)
3. Declare each area and in its view:
a. Declare the area type: Stub, NSSA (if necessary)
b. Configure the networks that belong to it
Virtual Link
Figure 3.2.2: Virtual Link
To configure a virtual link repeat the following steps in ABR1 and ABR2:
1. Enter the area view of the intermediate area
2. Declare the vlink-peer.
Note
To configure a virtual link, you will need to know the OSPF Router IDs of both
peers. That can be done either by explicitly including a Router ID when enabling
OSPF or by displaying the OSPF process information (display ospf brief). The first
is recommended because it is more stable.
Network Types
There are only a few cases in which you must configure the network type (Broadcast,
NBMA, Point to Multipoint or Point to Point). The most frequent is when the underlying
layer 2 interface if Frame Relay and the network is not a full mesh. In this case the
default NMBA must be changed to Point to Multipoint.
Rev. 11.21 3 –9
ASBR
To declare the AS exit routes in OSPF, three methods can be used:
1. To redistribute a default route
2. To redistribute static routes
3. To import the external protocol routes
3 –10 Rev. 11.21

IP Routing
Activity 3.3: eBGP

Introduction
BGPv4
BGP
x is an Exterior Gateway Protocol
x provides inter-AS routing
x provides route filtering for security and scalability
Routers running BGP are called BGP Speakers
When two neighboring BGP Speakers are located in
x the same AS, they are said to communicate using Internal BGP or iBGP
x different ASs, they are said to communicate using External BGP or eBGP
eBGP: External BGP

eBGP is used to exchange routing information between two autonomous systems
As BGP does not discover networks, it must lean them by other means:
x By injecting a network (using the network command)
x By redistributing a network (using the import command):
A static route
A route learned by OSFP, IS-IS, etc.
Importing BGP routes into an IGP like OSPF is, in general not recommended,
because BGP routing tables are too large.
Rev. 11.21 3 –11


Introduction
below)
question
Question1:
What is eBGP? How is it different from iBGP?
Question 2:
Describe briefly the following BGP path attributes:
Origin
AS-Path
Next-Hop
MED
Local-
Preference
3 –12 Rev. 11.21

IP Routing
Question 3:
What does route redistribution mean? What is the difference with injecting a route?
Question 4:
When configuring OSFP and BGP in an ASBR, what are the 3 main strategies you
can use in OSPF to route packets out of the AS and under which circumstances
would you apply each one of them?
Rev. 11.21 3 –13

eBGP Configuration in A-Series switches and routers

To configure eBGP in an OSPF ASBR follow these steps:
1. Enable BGP and enter its view (the AS number will be required)
2. Declare the BGP peers – in this case BGP peers will be in a different AS
3. Import or inject the direct networks
4. Import the IGP routes – in this case the OSPF routes
5. Configure OSPF’s AS exit method (see above)
3 –14 Rev. 11.21

IP Routing
Appendix 3.A: Reference manuals for Learning

Activities
OSPF
OSPF configuration
BGP
BGP configuration
Rev. 11.21 3 –15

Table of Contents
1 OSPF Configuration ··································································································································1-1

Introduction to OSPF·······························································································································1-1
Basic Concepts································································································································1-2
OSPF Area Partition ························································································································1-3
Classification of OSPF Networks ····································································································1-7
DR and BDR····································································································································1-8
OSPF Packet Formats·····················································································································1-9
Supported OSPF Features············································································································1-18
OSPF Configuration Task List ··············································································································1-20
Enabling OSPF ·····································································································································1-22
Prerequisites··································································································································1-22
Configuring OSPF Areas·······················································································································1-23
Prerequisites··································································································································1-23
Configuring a Stub Area ················································································································1-23
Configuring an NSSA Area············································································································1-24
Configuring a Virtual Link ··············································································································1-25
Configuring OSPF Network Types········································································································1-25
Prerequisites··································································································································1-26
Configuring the OSPF Network Type for an Interface as Broadcast ············································1-26
Configuring the OSPF Network Type for an Interface as NBMA ··················································1-26
Configuring the OSPF Network Type for an Interface as P2MP ···················································1-27
Configuring the OSPF Network Type for an Interface as P2P ······················································1-27
Configuring OSPF Route Control··········································································································1-27
Prerequisites··································································································································1-27
Configuring OSPF Route Summarization······················································································1-28
Configuring OSPF Inbound Route Filtering···················································································1-29
Configuring ABR Type-3 LSA Filtering··························································································1-29
Configuring an OSPF Cost for an Interface···················································································1-30
Configuring the Maximum Number of OSPF Routes ····································································1-30
Configuring the Maximum Number of Load-balanced Routes ······················································1-31
Configuring a Priority for OSPF·····································································································1-31
Configuring OSPF Route Redistribution························································································1-31
Advertising a Host Route···············································································································1-33
Configuring OSPF Network Optimization······························································································1-33
Prerequisites··································································································································1-33
Configuring OSPF Packet Timers ·································································································1-33
Specifying an LSA Transmission Delay ························································································1-34
Specifying SPF Calculation Interval ······························································································1-35
Specifying the LSA Minimum Repeat Arrival Interval····································································1-35
Specifying the LSA Generation Interval ························································································1-36
Disabling Interfaces from Sending OSPF Packets········································································1-36
i
Configuring Stub Routers ··············································································································1-37
Configuring OSPF Authentication ·································································································1-37
Adding the Interface MTU into DD Packets···················································································1-38
Configuring the Maximum Number of External LSAs in LSDB ·····················································1-38
Making External Route Selection Rules Defined in RFC1583 Compatible···································1-39
Logging Neighbor State Changes ·································································································1-39
Configuring OSPF Network Management ·····················································································1-39
Enabling Message Logging ···········································································································1-40
Enabling the Advertisement and Reception of Opaque LSAs ······················································1-40
Configuring OSPF to Give Priority to Receiving and Processing Hello Packets···························1-40
Configuring the LSU Transmit Rate ······························································································1-41
Configuring OSPF Graceful Restart······································································································1-41
Configuring the OSPF GR Restarter ·····························································································1-41
Configuring the OSPF GR Helper ·································································································1-42
Triggering OSPF Graceful Restart ································································································1-43
Displaying and Maintaining OSPF ········································································································1-44
OSPF Configuration Examples ·············································································································1-44
Configuring OSPF Basic Functions·······························································································1-45
Configuring OSPF Route Redistribution························································································1-48
Configuring OSPF to Advertise a Summary Route ·······································································1-49
Configuring an OSPF Stub Area ···································································································1-52
Configuring an OSPF NSSA Area·································································································1-55
Configuring OSPF DR Election ·····································································································1-57
Configuring OSPF Virtual Links·····································································································1-61
OSPF Graceful Restart Configuration Example············································································1-63
Configuring Route Filtering············································································································1-65
Troubleshooting OSPF Configuration ···································································································1-68
No OSPF Neighbor Relationship Established ···············································································1-68
Incorrect Routing Information ········································································································1-68
ii
1 OSPF Configuration
Open Shortest Path First (OSPF) is a link state interior gateway protocol developed by the OSPF
working group of the Internet Engineering Task Force (IETF). At present, OSPF version 2 (RFC2328) is
used.
When configuring OSPF, go to these sections for information you are interested in:
z Introduction to OSPF
z OSPF Configuration Task List
z Enabling OSPF
z Configuring OSPF Areas
z Configuring OSPF Network Types
z Configuring OSPF Route Control
z Configuring OSPF Network Optimization
z Configuring OSPF Graceful Restart
z Displaying and Maintaining OSPF
z OSPF Configuration Examples
z Troubleshooting OSPF Configuration
The term “router” in this document refers to a router in a generic sense or a Layer 3 switch.
Introduction to OSPF
Unless otherwise noted, OSPF refers to OSPFv2 throughout this document.
OSPF has the following features:

z Wide scope: Supports networks of various sizes and up to several hundred routers in an OSPF
routing domain.
z Fast convergence: Transmits updates instantly after network topology changes for routing
information synchronization in the AS.
z Loop-free: Computes routes with the shortest path first (SPF) algorithm according to collected link
states, so no route loops are generated.
z Area partition: Allows an AS to be split into different areas for ease of management and routing
information transmitted between areas is summarized to reduce network bandwidth consumption.
1-1
z Equal-cost multi-route: Supports multiple equal-cost routes to a destination.
z Routing hierarchy: Supports a four-level routing hierarchy that prioritizes routes into intra-area,
inter-area, external Type-1, and external Type-2 routes.
z Authentication: Supports interface-based packet authentication to ensure the security of packet
exchange.
z Multicast: Supports multicasting protocol packets on some types of links.
Basic Concepts
Autonomous System
A set of routers using the same routing protocol to exchange routing information constitute an
Autonomous System (AS).
OSPF route computation
OSPF route computation in an area is described as follows:

z Based on the network topology around itself, each router generates Link State Advertisements
(LSA) and sends them to other routers in update packets.
z Each OSPF router collects LSAs from other routers to compose a LSDB (Link State Database). An
LSA describes the network topology around a router, so the LSDB describes the entire network
topology of the AS.
z Each router transforms the LSDB to a weighted directed graph, which actually reflects the topology
architecture of the entire network. All the routers have the same graph.
z Each router uses the SPF algorithm to compute a Shortest Path Tree that shows the routes to the
nodes in the autonomous system. The router itself is the root of the tree.
Router ID
An OSPF process running on a router must have its own router ID,, which is a 32-bit unsigned integer,
the unique identifier of the router in the AS.
OSPF packets
OSPF uses five types of packets:

z Hello packet: Periodically sent to find and maintain neighbors, containing the values of some timers,
information about the DR, BDR and known neighbors.
z DD packet (database description packet): Describes the digest of each LSA in the LSDB,
exchanged between two routers for data synchronization.
z LSR (link state request) packet: Requests needed LSAs from the neighbor. After exchanging the
DD packets, the two routers know which LSAs of the neighbor are missing from the local LSDBs.
Then, they send an LSR packet to each other, requesting the missing LSAs. The LSA packet
contains the digest of the missing LSAs.
z LSU (link state update) packet: Transmits the needed LSAs to the neighbor.
z LSAck (link state acknowledgment) packet: Acknowledges received LSU packets. It contains the
headers of received LSAs (a packet can acknowledge multiple LSAs).
LSA types
OSPF sends routing information in LSAs, which, as defined in RFC 2328, have the following types:
z Router LSA: Type-1 LSA, originated by all routers, flooded throughout a single area only. This LSA
describes the collected states of the router's interfaces to an area.
1-2
z Network LSA: Type-2 LSA, originated for broadcast and NBMA networks by the designated router,
flooded throughout a single area only. This LSA contains the list of routers connected to the
network.
z Network Summary LSA: Type-3 LSA, originated by ABRs (Area Border Routers), and flooded
throughout the LSA's associated area. Each summary-LSA describes a route to a destination
outside the area, yet still inside the AS (an inter-area route).
z ASBR Summary LSA: Type-4 LSA, originated by ABRs and flooded throughout the LSA's
associated area. Type 4 summary-LSAs describe routes to ASBR (Autonomous System Boundary
Router).
z AS External LSA: Type-5 LSA, originated by ASBRs, and flooded throughout the AS (except stub
and NSSA areas). Each AS-external-LSA describes a route to another AS.
z NSSA LSA: Type-7 LSA, as defined in RFC 1587, originated by ASBRs in NSSAs (Not-So-Stubby
Areas) and flooded throughout a single NSSA. NSSA LSAs describe routes to other ASs.
z Opaque LSA: A proposed type of LSA, the format of which consists of a standard LSA header and
application specific information. Opaque LSAs are used by the OSPF protocol or by some
application to distribute information into the OSPF routing domain. The opaque LSA includes three
types, Type 9, Type 10 and Type 11, which are used to flood into different areas. The Type 9
opaque LSA is flooded into the local subnet, the Type 10 is flooded into the local area, and the
Type 11 is flooded throughout the whole AS.
Neighbor and Adjacency
In OSPF, the “Neighbor” and”Adjacency” are two different concepts.

Neighbor: Two routers that have interfaces to a common network. Neighbor relationships are
maintained by, and usually dynamically discovered by, OSPF's hello packets. When a router starts, it
sends a hello packet via the OSPF interface, and the router that receives the hello packet checks
parameters carried in the packet. If parameters of the two routers match, they become neighbors.
Adjacency: A relationship formed between selected neighboring routers for the purpose of exchanging
routing information. Not every pair of neighboring routers become adjacent, which depends on network
types. Only by synchronizing the LSDB via exchanging DD packets and LSAs can two routers become
adjacent.
OSPF Area Partition
Area partition
When a large number of OSPF routers are present on a network, LSDBs may become so large that a
great amount of storage space is occupied and CPU resources are exhausted by performing SPF
computation.
In addition, as the topology of a large network is prone to changes, enormous OSPF packets may be
created, reducing bandwidth utilization. Each topology change makes all routers perform route
calculation.
To solve this problem, OSPF splits an AS into multiple areas, which are identified by area ID. The
boundaries between areas are routers rather than links. A network segment (or a link) can only reside in
one area, in other words, an OSPF interface must be specified to belong to its attached area, as shown
in the figure below.
1-3
Figure 1-1 OSPF area partition
After area partition, area border routers perform route summarization to reduce the number of LSAs
advertised to other areas and minimize the effect of topology changes.
Classification of Routers
The OSPF routers fall into four types according to the position in the AS:
1) Internal Router
All interfaces on an internal router belong to one OSPF area.
2) Area Border Router (ABR)
An area border router belongs to more than two areas, one of which must be the backbone area. It
connects the backbone area to a non-backbone area. The connection between an area border router
and the backbone area can be physical or logical.
3) Backbone Router
At least one interface of a backbone router must be attached to the backbone area. Therefore, all ABRs
and internal routers in area 0 are backbone routers.
4) Autonomous System Border Router (ASBR)
The router exchanging routing information with another AS is an ASBR, which may not reside on the
boundary of the AS. It can be an internal router or area border router.
1-4
Figure 1-2 OSPF router types
Backbone area and virtual links
Each AS has a backbone area, which is responsible for distributing routing information between
none-backbone areas. Routing information between non-backbone areas must be forwarded by the
backbone area. Therefore, OSPF requires that:
z All non-backbone areas must maintain connectivity to the backbone area.
z The backbone area itself must maintain connectivity.
In practice, due to physical limitations, the requirements may not be satisfied. In this case, configuring
OSPF virtual links is a solution.
A virtual link is established between two area border routers via a non-backbone area and is configured
on both ABRs to take effect. The area that provides the non-backbone area internal route for the virtual
link is a “transit area”.
In the following figure, Area 2 has no direct physical link to the backbone area 0. Configuring a virtual
link between ABRs can connect Area 2 to the backbone area.
Figure 1-3 Virtual link application 1
Another application of virtual links is to provide redundant links. If the backbone area cannot maintain
internal connectivity due to a physical link failure, configuring a virtual link can guarantee logical
connectivity in the backbone area, as shown below.
1-5
Figure 1-4 Virtual link application 2
The virtual link between the two ABRs acts as a point-to-point connection. Therefore, you can configure
interface parameters such as hello packet interval on the virtual link as they are configured on physical
interfaces.
The two ABRs on the virtual link exchange OSPF packets with each other directly, and the OSPF
routers in between simply convey these OSPF packets as normal IP packets.
(Totally) Stub area
The ABR in a stub area does not distribute Type-5 LSAs into the area, so the routing table size and
amount of routing information in this area are reduced significantly.
You can configure the stub area as a totally stub area, where the ABR advertises neither the
destinations to other areas nor external routes.
Stub area configuration is optional, and not every area is eligible to be a stub area. In general, a stub
area resides on the border of the AS.
The ABR in a stub area generates a default route into the area.
Note the following when configuring a (totally) stub area:
z The backbone area cannot be a (totally) stub area.
z To configure an area as a stub area, the stub command must be configured on routers in the area.
z To configure an area as a totally stub area, the stub command must be configured on routers in the
area, and the ABR of the area must be configured with the stub [ no-summary ] command.
z A (totally) stub area cannot have an ASBR because AS external routes cannot be distributed into
the stub area.
z Virtual links cannot transit (totally) stub areas.
NSSA area
Similar to a stub area, an NSSA area imports no AS external LSA (Type-5 LSA) but can import Type-7
LSAs that are generated by the ASBR and distributed throughout the NSSA area. When traveling to the
NSSA ABR, Type-7 LSAs are translated into Type-5 LSAs by the ABR for advertisement to other areas.
In the following figure, the OSPF AS contains three areas: Area 1, Area 2 and Area 0. The other two
ASs employ the RIP protocol. Area 1 is an NSSA area, and the ASBR in it translates RIP routes into
Type-7 LSAs and advertises them throughout Area 1. When these LSAs travel to the NSSA ABR, the
ABR translates Type-7 LSAs to Type-5 LSAs for advertisement to Area 0 and Area 2.
1-6
On the left of the figure, RIP routes are translated into Type-5 LSAs by the ASBR of Area 2 and
distributed into the OSPF AS. However, Area 1 is an NSSA area, so these Type-5 LSAs cannot travel to
Area 1.
Like stub areas, virtual links cannot transit NSSA areas.
Figure 1-5 NSSA area
Route types
OSPF prioritize routes into four levels:

z Intra-area route
z Inter-area route
z Type-1 external route
z Type-2 external route
The intra-area and inter-area routes describe the network topology of the AS, while external routes
describe routes to destinations outside the AS.
OSPF classifies external routes into two types: Type-1 and Type-2. A Type-1 external route is an IGP
route, such as a RIP or static route, which has high credibility and whose cost is comparable with the
cost of an OSPF internal route. The cost from a router to the destination of the Type-1 external route=
the cost from the router to the corresponding ASBR+ the cost from the ASBR to the destination of the
external route.
A Type-2 external route is an EGP route, which has low credibility, so OSPF considers the cost from the
ASBR to the destination of the Type-2 external route is much greater than the cost from the ASBR to an
OSPF internal router. Therefore, the cost from the internal router to the destination of the Type-2
external route= the cost from the ASBR to the destination of the Type-2 external route. If two routes to
the same destination have the same cost, then take the cost from the router to the ASBR into
consideration.
Classification of OSPF Networks
OSPF network types
OSPF classifies networks into four types upon the link layer protocol:
z Broadcast: When the link layer protocol is Ethernet or FDDI, OSPF considers the network type
broadcast by default. On Broadcast networks, hello packets, LSU packets, and LSAck packets are
generally sent to multicast addresses 224.0.0.5 (reserved for OSPF routers) and 224.0.0.6
(reserved for OSPF DRs), while DD packets and LSR packets are unicast.
z NBMA (Non-Broadcast Multi-Access): When the link layer protocol is Frame Relay, ATM or X.25,
OSPF considers the network type as NBMA by default. Packets on these networks are sent to
unicast addresses.
1-7
z P2MP (point-to-multipoint): By default, OSPF considers no link layer protocol as P2MP, which is a
conversion from other network types such as NBMA in general. On P2MP networks, packets are
sent to multicast addresses (224.0.0.5).
z P2P (point-to-point): When the link layer protocol is PPP or HDLC, OSPF considers the network
type as P2P. On P2P networks, packets are sent to multicast addresses (224.0.0.5).
NBMA network configuration principle
Typical NBMA networks are ATM and Frame Relay networks.

You need to perform some special configuration on NBMA interfaces. Since these interfaces cannot
broadcast hello packets for neighbor location, you need to specify neighbors manually and configure
whether the neighbors have the DR election right.
An NBMA network is fully meshed, which means any two routers in the NBMA network have a direct
virtual link for communication. If direct connections are not available between some routers, the type of
interfaces associated should be configured as P2MP, or as P2P for interfaces with only one neighbor.
Differences between NBMA and P2MP networks:
z NBMA networks are fully meshed, non-broadcast and multi access. P2MP networks are not
required to be fully meshed.
z It is required to elect the DR and BDR on NBMA networks, while DR and BDR are not available on
P2MP networks.
z NBMA is the default network type, while P2MP is a conversion from other network types, such as
NBMA in general.
z On NBMA networks, packets are unicast, and neighbors are configured manually on routers. On
P2MP networks, packets are multicast.
DR and BDR
DR/BDR introduction
On broadcast or NBMA networks, any two routers exchange routing information with each other. If n
routers are present on a network, n(n-1)/2 adjacencies are required. Any change on a router in the
network generates traffic for routing information synchronization, consuming network resources. The
Designated Router is defined to solve the problem. All other routers on the network send routing
information to the DR, which is responsible for advertising link state information.
If the DR fails to work, routers on the network have to elect another DR and synchronize information
with the new DR. It is time-consuming and prone to routing calculation errors. The Backup Designated
Router (BDR) is introduced to reduce the synchronization period.
The BDR is elected along with the DR and establishes adjacencies for routing information exchange
with all other routers. When the DR fails, the BDR will become the new DR in a very short period by
avoiding adjacency establishment and DR reelection. Meanwhile, other routers elect another BDR,
which requires a relatively long period but has no influence on routing calculation.
Other routers, also known as DRothers, establish no adjacency and exchange no routing information
with each other, thus reducing the number of adjacencies on broadcast and NBMA networks.
In the following figure, real lines are Ethernet physical links, and dashed lines represent adjacencies.
With the DR and BDR in the network, only seven adjacencies are enough.
1-8
Figure 1-6 DR and BDR in a network
DR/BDR election
The DR and BDR in a network are elected by all routers rather than configured manually. The DR
priority of an interface determines its qualification for DR/BDR election. Interfaces attached to the
network and having priorities higher than ‘0” are election candidates.
The election votes are hello packets. Each router sends the DR elected by itself in a hello packet to all
the other routers. If two routers on the network declare themselves as the DR, the router with the higher
DR priority wins. If DR priorities are the same, the router with the higher router ID wins. In addition, a
router with the priority 0 cannot become the DR/BDR.
Note that:
z The DR election is available on broadcast, NBMA interfaces rather than P2P, or P2MP interfaces.
z A DR is an interface of a router and belongs to a single network segment. The router’s other
interfaces may be a BDR or DRother.
z After DR/BDR election and then a new router joins, it cannot become the DR immediately even if it
has the highest priority on the network.
z The DR may not be the router with the highest priority in a network, and the BDR may not be the
router with the second highest priority.
OSPF Packet Formats
OSPF packets are directly encapsulated into IP packets. OSPF has the IP protocol number 89. The
OSPF packet format is shown below (taking a LSU packet as an example).
Figure 1-7 OSPF packet format
OSPF packet header
OSPF packets are classified into five types that have the same packet header, as shown below.
1-9
Figure 1-8 OSPF packet header
z Version: OSPF version number, which is 2 for OSPFv2.

z Type: OSPF packet type from 1 to 5, corresponding with hello, DD, LSR, LSU and LSAck
respectively.
z Packet length: Total length of the OSPF packet in bytes, including the header.
z Router ID: ID of the advertising router.
z Area ID: ID of the area where the advertising router resides.
z Checksum: Checksum of the message.
z Autype: Authentication type from 0 to 2, corresponding with non-authentication, simple (plaintext)
authentication and MD5 authentication respectively.
z Authentication: Information determined by authentication type. It is not defined for authentication
type 0. It is difined as password information for authentication type 1, and defined as Key ID, MD5
authentication data length and sequence number for authentication type 2.
MD5 authentication data is added following an OSPF packet rather than contained in the Authentication
field.
Hello packet
A router sends hello packets periodically to neighbors to find and maintain neighbor relationships and to
elect the DR/BDR, including information about values of timers, DR, BDR and neighbors already known.
The format is shown below:
1-10
Figure 1-9 Hello packet format
0 7 15 31
Version 1 Packet length
Router ID
Area ID
Checksum AuType
Authentication
Authentication
Network mask
HelloInterval Options Rtr Pri
RouterDeadInterval
Designated router
Backup designated router
Neighbor
Neighbor
Major fields:
z Network mask: Network mask associated with the router’s sending interface. If two routers have
different network masks, they cannot become neighbors.
z HelloInterval: Interval for sending hello packets. If two routers have different intervals, they cannot
become neighbors.
z Rtr Pri: Router priority. A value of 0 means the router cannot become the DR/BDR.
z RouterDeadInterval: Time before declaring a silent router down. If two routers have different time
values, they cannot become neighbors.
z Designated router: IP address of the DR interface.
z Backup designated router: IP address of the BDR interface
z Neighbor: Router ID of the neighbor router.
DD packet
Two routers exchange database description (DD) packets describing their LSDBs for database
synchronization, contents in DD packets including the header of each LSA (uniquely representing a
LSA). The LSA header occupies small part of an LSA to reduce traffic between routers. The recipient
checks whether the LSA is available using the LSA header.
The DD packet format:
1-11
Figure 1-10 DD packet format
Major fields:
z Interface MTU: Size in bytes of the largest IP datagram that can be sent out the associated
interface, without fragmentation.
z I (Initial) The Init bit, which is set to 1 if the packet is the first packet of database description packets,
and set to 0 if not.
z M (More): The More bit, which is set to 0 if the packet is the last packet of DD packets, and set to 1
if more DD Packets are to follow.
z MS (Master/Slave): The Master/Slave bit. When set to 1, it indicates that the router is the master
during the database exchange process. Otherwise, the router is the slave.
z DD Sequence Number: Used to sequence the collection of database description packets for
ensuring reliability and intactness of DD packets between the master and slave. The initial value is
set by the master. The DD sequence number then increments until the complete database
description has been sent.
LSR packet
After exchanging DD packets, any two routers know which LSAs of the peer routers are missing from
the local LSDBs. In this case, they send LSR (link state request) packets, requesting the missing LSAs.
The packets contain the digests of the missing LSAs. The following figure shows the LSR packet format.
1-12
Figure 1-11 LSR packet format
Major fields:
z LS type: Type number of the LSA to be requested. Type 1 for example indicates the Router LSA.
z Link State ID: Determined by LSA type.
z Advertising Router: ID of the router that sent the LSA.
LSU packet
LSU (Link State Update) packets are used to send the requested LSAs to peers, and each packet
carries a collection of LSAs. The LSU packet format is shown below.
Figure 1-12 LSU packet format
...
LSAck packet
LSAack (Link State Acknowledgment) packets are used to acknowledge received LSU packets,
contents including LSA headers to describe the corresponding LSAs. Multiple LSAs can be
acknowledged in a single Link State Acknowledgment packet. The following figure gives its format.
1-13
Figure 1-13 LSAck packet format
...
LSA header format
All LSAs have the same header, as shown in the following figure.
Figure 1-14 LSA header format
Major fields:
z LS age: Time in seconds elapsed since the LSA was originated. A LSA ages in the LSDB (added
by 1 per second), but does not in transmission.
z LS type: Type of the LSA.
z Link State ID: The contents of this field depend on the LSA's type
z LS sequence number: Used by other routers to judge new and old LSAs.
z LS checksum: Checksum of the LSA except the LS age field.
z Length: Length in bytes of the LSA, including the LSA header.
Formats of LSAs
1) Router LSA
1-14
Figure 1-15 Router LSA format
0 7 15 31
LS age Options 1
Linke state ID
Advertising router
LS sequence number
LS checksum Length
0 V E B 0 # Links
Link ID
Link data
Type #TOS Metric
...
TOS 0 TOS metric
Link ID
Link data
...
Major fields:
z Link State ID: ID of the router that originated the LSA.
z V (Virtual Link): Set to 1 if the router that originated the LSA is a virtual link endpoint.
z E (External): Set to 1 if the router that originated the LSA is an ASBR.
z B (Border): Set to 1 if the router that originated the LSA is an ABR.
z # Links: Number of router links (interfaces) to the area, described in the LSA.
z Link ID: Determined by Link type.
z Link data: Determined by Link type.
z Type: Link type. A value of 1 indicates a point-to-point link to a remote router; a value of 2 indicates
a link to a transit network; a value of 3 indicates a link to a stub network; a value of 4 indicates a
virtual link.
z #TOS: Number of different TOS metrics given for this link.
z Metric: Cost of using this router link.
z TOS: IP Type of Service that this metric refers to.
z TOS metric: TOS-specific metric information.
2) Network LSA
A Network LSA is originated by the DR on a broadcast or NBMA network. The LSA describes all routers
attached to the network.
1-15
Figure 1-16 Network LSA format
Major fields:
z Link State ID: The interface address of the DR
z Network mask: The mask of the network (a broadcast or NBMA network)
z Attached router: The IDs of the routers, which are adjacent to the DR, including the DR itself
3) Summary LSA
Network summary LSAs (Type-3 LSAs) and ASBR summary LSAs (Type-4 LSAs) are originated by
ABRs. Other than the difference in the Link State ID field, the format of type 3 and 4 summary-LSAs is
identical.
Figure 1-17 Summary LSA format
Major fields:
z Link State ID: For a Type-3 LSA, it is an IP address outside the area; for a type 4 LSA, it is the
router ID of an ASBR outside the area.
z Network mask: The network mask for the type 3 LSA; set to 0.0.0.0 for the Type-4 LSA
z Metric: The metric to the destination
1-16
A Type-3 LSA can be used to advertise a default route, having the Link State ID and Network Mask set
to 0.0.0.0.
4) AS external LSA
An AS external LSA originates from an ASBR, describing routing information to a destination outside
the AS.
Figure 1-18 AS external LSA format
0 7 15 31
LS age Options 5
Linke state ID
Advertising router
LS sequence number
LS checksum Length
Network mask
E 0 Metric
Forwarding address
External route tag
E TOS TOS metric
Forwarding address
External route tag
...
Major fields:
z Link State ID: The IP address of another AS to be advertised. When describing a default route, the
Link State ID is always set to Default Destination (0.0.0.0) and the Network Mask is set to 0.0.0.0
z Network mask: The IP address mask for the advertised destination
z E (External Metric): The type of the external metric value, which is set to 1 for type 2 external routes,
and set to 0 for type 1 external routes. Refer to Route types for description about external route
types
z Metric: The metric to the destination
z Forwarding Address: Data traffic for the advertised destination will be forwarded to this address
z External Route Tag: A tag attached to each external route. This is not used by the OSPF protocol
itself. It may be used to manage external routes.
5) NSSA external LSA
An NSSA external LSA originates from the ASBR in a NSSA and is flooded in the NSSA area only. It has
the same format as the AS external LSA.
1-17
Figure 1-19 NSSA external LSA format
Supported OSPF Features
Multi-process
With multi-process support, multiple OSPF processes can run on a router simultaneously and
independently. Routing information interactions between different processes seem like interactions
between different routing protocols. Multiple OSPF processes can use the same RID.
An interface of a router can only belong to a single OSPF process.
Authentication
OSPF supports authentication on packets. Only packets that pass the authentication are received. If
hello packets cannot pass authentication, no neighbor relationship can be established.
The authentication type for interfaces attached to a single area must be identical. Authentication types
include non-authentication, plaintext authentication and MD5 ciphertext authentication. The
authentication password for interfaces attached to a network segment must be identical.
Hot Standby
For hot standby configuration, refer to HA Configuration in the System Volume.
Distributed routers support OSPF Hot Standby (HSB). OSPF backups necessary information of the
Active Main Board (AMB) into the Standby Main Board (SMB). Once the AMB fails, the SMB begins to
work to ensure the normal operation of OSPF.
OSPF backups:
z All OSPF data to the SMB to make sure OSPF recovers normal operation immediately upon the
AMB failure.
1-18
z Only the OSPF configuration information to the SMB. Once the AMB fails, OSPF will perform
Graceful Restart (GR), obtaining adjacencies from and synchronizing the Link State Database with
neighbors.
The Graceful Restart feature is mainly used for High Availability (HA) and does not interfere with any
other routers.
When a router shuts down, its neighbors will delete it from their neighbor tables and inform other routers,
resulting in SPF recalculation. If the router restarts in several seconds, it is unnecessary to perform SPF
recalculation, and reestablish adjacencies.
To avoid unnecessary SPF calculation, when a router restarts, it will inform neighboring routers the
shutdown is temporary. Then these routers will not delete the router from their neighbor tables, and
other routers have no idea about this restart.
After recovering to normal, the router obtains the Link State Database from neighboring routers via the
GR related synchronization mechanism.
OSPF Graceful Restart
For GR information, refer to GR Overview in the System Volume.
After an OSPF GR Restarter restarts, it needs to perform the following two tasks in order to
re-synchronize its LSDB with its neighbors.
z To obtain once again effective OSPF neighbor information (assume the adjacencies are not
changed).
z To obtain once again the LSDB.
After restart, the GR Restarter negotiates GR capability with its neighbors and sends an OSPF GR
signal to its GR-capable neighbors so that they will not remove their adjacencies with it and advertise
the adjacencies. The GR Restarter re-establishes neighborships and updates its own routing table and
forwarding table based on the new routing information received from neighbors and removes the stale
routes.
VPN
OSPF supports multi-instance, which can run on PEs in VPN networks.

In BGP MPLS VPN networks, multiple sites in the same VPN can use OSPF as the internal routing
protocol, but they are treated as different ASs. An OSPF route learned by a site will be forwarded to
another site as an external route, which leads to heavy OSPF routing traffic and management issues.
Configuring area IDs on PEs can differentiate VPNs. Sites in the same VPN are considered as directly
connected. PE routers then exchange OSPF routing information like on a dedicated line; thus network
management and OSPF operation efficiency are improved.
1-19
For configuration of this feature, refer to MPLS L3VPN Configuration in the MPLS Volume.
OSPF sham link
An OSPF sham link is a point-to-point link between two PE routers on the MPLS VPN backbone.
In general, BGP peers exchange routing information on the MPLS VPN backbone using the BGP
extended community attribute. OSPF running on a PE at the other end utilizes this information to
originate a Type-3 summary LSA as an inter-area route between the PE and CE.
If a router connects to a PE router in the same area and establishes an internal route (backdoor route) to
a destination, in this case, since an OSPF intraarea route has a higher priority than a backbone route,
VPN traffic will always travel on the backdoor route rather than the backbone route. To avoid this, an
unnumbered sham link can be configured between PE routers, connecting the router to another PE
router via an intraarea route with a lower cost.
For sham link configuration, refer to MPLS L3VPN Configuration in the MPLS Volume.
z RFC 1765:OSPF Database Overflow

z RFC 2328: OSPF Version 2
z RFC 3101: OSPF Not-So-Stubby Area (NSSA) Option
z RFC 3137: OSPF Stub Router Advertisement
OSPF Configuration Task List

An OSPF routing domain has different types of routers, such as intra-area routers, ABR, and ASBR.
OSPF can work normally only after being enabled on a router, regardless of the router’s type. On an
OSPF-enabled router, you can use the default values of parameters, such as the transmit interval of
OSPF packets, LSA delay timer, and SPF caculation interval, or configure them as required.
Network planning is needed before OSPF configuration on routers. The configurations for routers in an
area are performed on the area basis. Wrong configurations may cause communication failures, even
routing information block or routing loops between neighboring routers..
1-20
Complete the following tasks to configure OSPF:
Task Remarks
Enabling OSPF Required
Configuring a Stub Area

Configuring OSPF
Configuring an NSSA Area Optional
Areas
Configuring a Virtual Link
Configuring the OSPF Network Type for an Interface as
Optional
Broadcast
Configuring OSPF Configuring the OSPF Network Type for an Interface as NBMA Optional
Network Types
Configuring the OSPF Network Type for an Interface as P2MP Optional
Configuring the OSPF Network Type for an Interface as P2P Optional
Configuring OSPF Route Summarization Optional
Configuring OSPF Inbound Route Filtering Optional
Configuring ABR Type-3 LSA Filtering Optional
Configuring OSPF Configuring an OSPF Cost for an Interface Optional

Route Control Configuring the Maximum Number of OSPF Routes Optional
Configuring the Maximum Number of Load-balanced Routes Optional
Configuring a Priority for OSPF Optional
Configuring OSPF Route Redistribution Optional
Configuring OSPF Packet Timers Optional
Specifying an LSA Transmission Delay Optional

Specifying SPF Calculation Interval Optional
Specifying the LSA Minimum Repeat Arrival Interval Optional
Specifying the LSA Generation Interval Optional

Disabling Interfaces from Sending OSPF Packets Optional
Configuring Stub Routers Optional
Configuring OSPF Authentication Optional

Configuring OSPF Adding the Interface MTU into DD Packets Optional
Network
Optimization Configuring the Maximum Number of External LSAs in LSDB Optional
Making External Route Selection Rules Defined in RFC1583
Optional
Compatible
Logging Neighbor State Changes Optional
Configuring OSPF Network Management Optional
Enabling Message Logging Optional
Enabling the Advertisement and Reception of Opaque LSAs Optional

Configuring OSPF to Give Priority to Receiving and Processing
Optional
Hello Packets
Configuring the LSU Transmit Rate Optional
1-21
Task Remarks
Configuring the OSPF GR Restarter Optional
Configuring OSPF
Configuring the OSPF GR Helper Optional
Graceful Restart
Triggering OSPF Graceful Restart Optional
Enabling OSPF
You need to enable OSPF before you can perform other OSPF configuration tasks.
Prerequisites
Before configuring OSPF, you have configured IP addresses for interfaces, making neighboring nodes
accessible with each other at the network layer.
To enable OSPF on a router, you need to create an OSPF process and specify areas with which the
process is associated, and the network segments contained in each area. If an interface’s IP address
resides on a network segment of an area, the interface belongs to the area and is enabled with OSPF,
and OSPF advertises the direct route of the interface.
To run OSPF, a router must have a Router ID, which is the unique identifier of the router in the AS.
z You can specify a Router ID when creating the OSPF process. Any two routers in an AS must have
different Router IDs. In practice, the ID of a router is the IP address of one of its interfaces.
z If you specify no Router ID when creating the OSPF process, the global Router ID will be used. For
details about global Router ID, refer to IP Routing Overview in the IP Routing Volume. You are
recommended to specify a Router ID when creating the OSPF process.
The system supports OSPF multi-process and OSPF multi-instance:
z When a router runs multiple OSPF processes, you need to specify a Router ID for each process,
which takes effect locally and has no influence on packet exchange between routers. Therefore,
two routers having different process IDs can exchange packets.
z You can configure an OSPF process to run in a specified VPN instance.
Follow these steps to enable OSPF:

Enter system view System-view —
ospf [ process-id |
Enable an OSPF process and router-id router-id | Required
enter its view vpn-instance Not enabled by default.
instance-name ] *
Configure a description for Optional

description description
the OSPF process Not configured by default.
Configure an OSPF area and Required

area area-id
enter OSPF area view Not configured by default.
Configure a description for Optional

description description
the area Not configured by default.
1-22
Specify a network to enable Required
network ip-address
OSPF on the interface
wildcard-mask Not configured by default.
attached to the network
z A network segment can only belong to one area.

z It is recommended to configure a description for each OSPF process to help identify purposes of
processes and for ease of management and memorization.
z It is recommended to configure a description for each area to help identify purposes of areas and
for ease of management and memorization.
Configuring OSPF Areas

After splitting an OSPF AS into multiple areas, you can further configure some areas as stub areas or
NSSA areas as needed.
If the backbone and non-backbone areas, including the backbone itself, cannot maintain connectivity,
you can configure virtual links to solve it.
Prerequisites
Before configuring an OSPF area, you have configured:

z IP addresses for interfaces, making neighboring nodes accessible with each other at the network
layer.
z OSPF basic functions.
Configuring a Stub Area
You can configure a non-backbone area at the AS edge as a stub area by configuring the stub
command on all the routers attached to the area. In this way, Type-5 LSAs, which describe AS external
routes, will not be flooded within the stub area, reducing the routing table size. The ABR generates a
default route into the stub area so that all packets destined outside of the AS are sent through the
default route.
To further reduce the routing table size and routing information exchanged in the stub area, you can
configure it as a totally stub area by using the stub [ no-summary ] command on the ABR. In this way,
neither AS external routes nor inter-area routing information will be distributed into the area. All the
packets destined outside of the AS or area will be sent to the ABR for forwarding.
Follow these steps to configure OSPF areas:

ospf [ process-id | router-id
Enter OSPF view router-id | vpn-instance —
instance-name ] *
1-23
Enter area view area area-id Required
Configure the area as a stub Required

stub [ no-summary ]
area Not configured by default.
Specify a cost for the default Optional
route advertised to the stub default-cost cost
area Defaults to 1.
z It is required to use the stub command on routers attached to a stub area.

z Using the default-cost command only takes effect on the ABR of a stub area.
z The backbone area cannot be a (totally) stub area.
z A (totally) stub area cannot have an ASBR because AS external routes cannot be distributed into
the stub area.
z Virtual links cannot transit (totally) stub areas.
Configuring an NSSA Area
A stub area cannot redistribute routes. You can configure the area as an NSSA area to allow for route
redistribution while keeping other characteristics of a stub area.
Follow these steps to configure an NSSA area:

ospf [ process-id | router-id router-id
Enter OSPF view —
| vpn-instance instance-name ] *
Configure the area as an nssa [ default-route-advertise | Required

NSSA area no-import-route | no-summary ] * Not configured by default.
Specify a cost for the default Optional
route advertised to the NSSA default-cost cost
area Defaults to 1.
z It is required to use the nssa command on all the routers attached to an NSSA area.
z Using the default-cost command only takes effect on the ABR/ASBR of an NSSA area.
1-24
Configuring a Virtual Link
Non-backbone areas exchange routing information via the backbone area. Therefore, connectivity
between the backbone and non-backbone areas and within the backbone itself must be maintained.
If necessary physical links are not available for this connectivity maintenance, you can configure virtual
links to solve it.
Follow these steps to configure a virtual link:

instance-name ] *
vlink-peer router-id [ hello Required

seconds | retransmit seconds | You need to configure this
trans-delay seconds | dead command on both ends of a
Configure a virtual link seconds | simple [ plain | virtual link.
cipher ] password | { md5 | Note that hello and dead
hmac-md5 } key-id [ plain | intervals must be identical on
cipher ] password ] * both ends of the virtual link.
Configuring OSPF Network Types

OSPF classifies networks into four types: broadcast, NBMA, P2MP, and P2P, upon the link layer
protocol.
z Broadcast: When the link layer protocol is Ethernet or FDDI, OSPF considers the network type as
broadcast by default.
z NBMA: When the link layer protocol is Frame Relay, ATM or X.25, OSPF considers the network
type as NBMA by default.
z P2P: When the link layer protocol is PPP, LAPB, HDLC, or POS, OSPF considers the network type
as P2P by default.
You can change the network type of an interface as needed. For example:
z When an NBMA network becomes fully meshed through address mapping, namely, when any two
routers in the network have a direct virtual link in between, you can change the network type to
broadcast, without manually configuring the neighbors.
z When some routers in the broadcast network do not support multicast, you can change the network
type to NBMA.
z An NBMA network is fully meshed, which means any two routers in the NBMA network have a
direct virtual link for communication. If direct connections are not available between some routers,
the type of interfaces associated should be configured as P2MP, or as P2P for interfaces with only
one neighbor.
If two interfaces on a link are both configured as the broadcast, NBMA or P2MP type, they cannot
establish a neighbor relationship unless they are on the same network segment.
1-25
Prerequisites
Before configuring OSPF network types, you have configured:

z IP addresses for interfaces, making neighboring nodes accessible with each other at network layer.
Configuring the OSPF Network Type for an Interface as Broadcast
Follow these steps to configure the OSPF network type for an interface as broadcast:

interface-number
Required
Configure the OSPF network
ospf network-type By default, the network type of an
type for the interface as
broadcast interface depends on the link
broadcast
layer protocol.
Configure a DR priority for the Optional

ospf dr-priority priority
interface The default DR priority is 1.
Configuring the OSPF Network Type for an Interface as NBMA
After configuring the network type of an interface as NBMA, you need to make some special
configurations.
Because NBMA interfaces cannot find neighbors via broadcasting Hello packets, you need to specify
neighbors and neighbor DR priorities. (A DR priority of 0 means the router does not have the DR
election right; a DR priority greater than 0 means the router has the DR election right).
Follow these steps to configure the OSPF network type for an Interface as NBMA:

interface-number
Required
Configure the OSPF network
type for the interface as ospf network-type nbma By default, the network type of an
NBMA interface depends on the link
layer protocol.
Configure a DR priority for the Optional

ospf dr-priority priority
interface The default DR priority is 1
Exit to system view quit —
instance-name ] *
Specify a neighbor and its DR peer ip-address [ dr-priority
Required
priority dr-priority ]
1-26
The DR priority configured with the ospf dr-priority command and the one with the peer command
have the following differences:
z The former is for actual DR election.
z The latter is to indicate whether a neighbor has the election right or not. If you configure the DR
priority for a neighbor as 0, the local router will consider the neighbor has no election right, and thus
no hello packet is sent to this neighbor, reducing the number of hello packets for DR/BDR election
on networks. However, if the local router is the DR or BDR, it sends hello packets to the neighbor
with priority 0 for adjacency establishment.
Configuring the OSPF Network Type for an Interface as P2MP
Follow these steps to configure the OSPF network type for an interface as P2MP:

interface-number
Required
Configure the OSPF network By default, the network type of an
ospf network-type p2mp
type for the interface as P2MP interface depends on the link
layer protocol.
Configuring the OSPF Network Type for an Interface as P2P
Follow these steps to configure the OSPF network type for an interface as P2P:

interface-number
Required
Configure the OSPF network By default, the network type of an
ospf network-type p2p
type for the interface as P2P. interface depends on the link
layer protocol.
Configuring OSPF Route Control

This section covers how to control OSPF routing information advertisement and reception, and route
redistribution from other protocols.
Prerequisites
Before configuring this task, you have configured:
1-27
z IP addresses for interfaces
z OSPF basic functions
z Corresponding filters if routing information filtering is needed.
Configuring OSPF Route Summarization
Route summarization: An ABR or ASBR summarizes routes with the same prefix into a single route and
distribute it to other areas.
Through route summarization, routing information across areas and the size of routing tables on routers
will be reduced, improving calculation speed of routers.
Assume in an area are three internal routes 19.1.1.0/24, 19.1.2.0/24, and 19.1.3.0/24. By configuring
route summarization on the ABR, the three routes are summarized into the route 19.1.0.0/16 that is
advertised into other areas.
Configuring route summarization on an ABR
If contiguous network segments are available in the area, you can summarize them into a single
network segment. An ABR generates Type-3 LSAs on a per network segment basis for an attached
non-backbone area.
In this way, the ABR in the area distributes only the summary LSA to reduce the scale of LSDBs on
routers in other areas and the influence of topological changes.
Follow these steps to configure route summarization on an ABR:

instance-name ] *
Enter OSPF area view area area-id —
Required
abr-summary ip-address { mask
Configure ABR route The command is available on
| mask-length } [ advertise |
summarization an ABR only.
not-advertise ] [ cost cost ]
Not configured by default.
Configuring route summarization when redistributing routes into OSPF on an ASBR
If summarization for redistributed routes is not configured on an ASBR, it will advertise each
redistributed route in a separate ASE LSA. After a summary is configured on the ASBR, it advertises
only the summary route in an ASE LSA instead of more specific routes, thus reducing the number of
LSAs in the LSDBs.
If summarization for redistributed routes is configured on an ASBR, it will summarize redistributed
Type-5 LSAs that fall into the specified address range.
If in an NSSA area, it also summarizes Type-7 LSAs that fall into the specified address range. If this
feature is configured on a router working as an ABR and ASBR at the same time, the router will
summarize Type-5 LSAs translated from Type-7 LSAs.
Follow these steps to configure route summarization when redistributing routes into OSPF on an ASBR:
1-28
instance-name ]*
Required
asbr-summary ip-address { mask
Configure ASBR route The command is available on an
| mask-length } [ tag tag |
summarization ASBR only.
not-advertise | cost cost ] *
Configuring OSPF Inbound Route Filtering
Since OSPF is a link state-based interior gateway protocol, routing information is contained in LSAs.
Routes computed by OSPF can be filtered and only permitted routes are installed into the routing table.
There are two filtering methods:
z Filtering routing information by destination address through ACLs and IP address prefixes.
z Filtering routing information by next hop through the filtering criteria configured with the gateway
keyword.
Follow these steps to configure inbound route filtering:

ospf [ process-id | router-id router-id |
Enter OSPF view —
vpn-instance instance-name ] *
filter-policy { acl-number | ip-prefix Required
Configure inbound route
ip-prefix-name | gateway ip-prefix-name }
filtering Not configured by default.
import
Configuring ABR Type-3 LSA Filtering
Configure Type-3 LSA filtering on an ABR to filter Type-3 LSAs to be advertised in the area to which the
ABR is attached or the Type-3 LSAs that the ABR advertises to other areas.
Follow these steps to configure Type-3 LSA filtering on an ABR:

Enter OSPF view —
Enter area view area area-id —
Required
Configure ABR Type-3 LSA filter { acl-number | ip-prefix
filtering ip-prefix-name } { import | export } Not configured by
default.
1-29
Configuring an OSPF Cost for an Interface
You can configure an OSPF cost for an interface with one of the following two methods:
z Configure the cost value in interface view.
z Configure a bandwidth reference value for the interface, and OSPF computes the cost
automatically based on the bandwidth reference value: Interface OSPF cost= Bandwidth reference
value/Interface bandwidth. If the calculated cost is greater than 65535, the value of 65535 is used;
if the calculated cost is less than 1, the value of 1 is used.
If the cost value is not configured for an interface, OSPF computes the interface cost automatically:
Follow these steps to configure an OSPF cost for an interface:

interface-number
Optional
By default, an interface computes its
Configure an OSPF cost
ospf cost value cost according to the bandwidth.
for the interface
The cost value defaults to 1 for VLAN
interfaces.
Follow these steps to configure a bandwidth reference value:

Enter OSPF view —
Optional
Configure a bandwidth
bandwidth-reference value The value defaults to
reference value
100 Mbps.
Configuring the Maximum Number of OSPF Routes
Follow these steps to configure the maximum number of routes:

Enter OSPF view —
Optional
Configure the maximum maximum-routes { external | inter |
number of OSPF routes intra } number The default number is
128000.
1-30
Configuring the Maximum Number of Load-balanced Routes
If several routes with the same cost to the same destination are available, configuring them as
load-balanced routes can improve link utilization.
Follow these steps to configure the maximum number of load-balanced routes:

Enter OSPF view —

number of equivalent maximum load-balancing maximum The default number is
load-balanced routes 4.
Configuring a Priority for OSPF
A router may run multiple routing protocols, and it sets a priority for each protocol. When a route found
by several routing protocols, the route found by the protocol with the highest priority will be selected.
Follow these steps to configure a priority for OSPF:

instance-name ] *
Optional
The priority of OSPF internal routes
Configure a priority for preference [ ase ] [ route-policy
defaults to 10.
OSPF route-policy-name ] value
The priority of OSPF external routes
defaults to 150.
Configuring OSPF Route Redistribution
Configure route redistribution into OSPF
If the router runs OSPF and other routing protocols, you can configure OSPF to redistribute RIP, IS-IS,
BGP, static, or direct routes and advertise these routes in Type-5 LSAs or Type-7 LSAs.
By filtering redistributed routes, OSPF translates only routes not filtered out into Type-5 LSAs or Type-7
LSAs for advertisement.
Follow these steps to configure OSPF route redistribution:

Enter OSPF view —
1-31
import-route protocol [ process-id | Required
Configure OSPF to
all-processes | allow-ibgp ] [ cost cost |
redistribute routes from Not configured by
type type | tag tag | route-policy
another protocol default.
route-policy-name ] *
Configure OSPF to filter filter-policy { acl-number | ip-prefix Optional

redistributed routes before ip-prefix-name } export [ protocol Not configured by
advertisement [ process-id ] ] default.
Only active routes can be redistributed. You can use the display ip routing-table protocol command
to display route state information.
Configure OSPF to redistribute a default route
Using the import-route command cannot redistribute a default external route. To do so, you need to
use the default-route-advertise command.
Follow these steps to configure OSPF to redistribute a default external route:

Enter OSPF view —
default-route-advertise [ always | cost cost | Optional
Redistribute a default type type | route-policy route-policy-name ] *
route Not redistributed by
default-route-advertise summary cost cost default.
The default-route-advertise summary cost command is applicable only to VPN, and the default route
is redistributed in a Type-3 LSA. The PE router will advertise the default route to the CE router.
Configure the default parameters for redistributed routes
You can configure default parameters such as the cost, upper limit, tag and type for redistributed routes.
Tags are used to indicate information related to protocols. For example, when redistributing BGP routes,
OSPF uses tags to identify AS IDs.
1-32
Follow these steps to configure the default parameters for redistributed routes:

Enter OSPF view —
Optional
Configure the default By default, the default cost is
parameters for redistributed default { cost cost | limit limit | tag 1, default upper limit of
routes (cost, route number, tag | type type } * routes redistributed per time
tag and type) is 1000, default tag is 1 and
default type of redistributed
routes is Type-2.
Advertising a Host Route
Follow these steps to advertise a host route:

instance-name ] *
host-advertise ip-address Required

Advertise a host route
cost Not advertised by default.
Configuring OSPF Network Optimization

You can optimize your OSPF network in the following ways:
z Change OSPF packet timers to adjust the OSPF network convergence speed and network load.
On low speed links, you need to consider the delay time for sending LSAs on interfaces.
z Change the interval for SPF calculation to reduce resource consumption caused by frequent
network changes.
z Configure OSPF authentication to meet high security requirements of some mission-critical
networks.
z Configure OSPF network management functions, such as binding OSPF MIB with a process,
sending trap information and collecting log information.
Prerequisites
Before configuring OSPF network optimization, you have configured:

z IP addresses for interfaces;
Configuring OSPF Packet Timers
You can configure the following timers on OSPF interfaces as needed:
1-33
z Hello timer: Interval for sending hello packets. It must be identical on OSPF neighbors. The longer
the interval, the lower convergence speed and smaller network load.
z Poll timer: Interval for sending hello packets to the neighbor that is down on the NBMA network.
z Dead timer: Interval within which if the interface receives no hello packet from the neighbor, it
declares the neighbor is down.
z LSA retransmission timer: Interval within which if the interface receives no acknowledgement
packets after sending a LSA to the neighbor, it will retransmit the LSA.
Follow these steps to configure timers for OSPF packets:

interface-number
Optional
Specify the hello The hello interval on P2P, Broadcast
ospf timer hello seconds interfaces defaults to 10 seconds and
interval
defaults to 30 seconds on P2MP and NBMA
interfaces.
Specify the poll Optional

ospf timer poll seconds
interval The poll interval defaults to 120 seconds.
Optional
Specify the dead The default dead interval is 40 seconds on
ospf timer dead seconds
interval P2P, Broadcast interfaces and 120 seconds
on P2MP and NBMA interfaces.
Specify the Optional

ospf timer retransmit
retransmission The retransmission interval defaults to 5
interval
interval seconds.
z The hello and dead intervals restore to default values after you change the network type for an
interface.
z The dead interval should be at least four times the hello interval on an interface.
z The poll interval is at least four times the hello interval.
z The retransmission interval should not be so small for avoidance of unnecessary LSA
retransmissions. In general, this value is bigger than the round-trip time of a packet between two
adjacencies.
Specifying an LSA Transmission Delay
Since OSPF packets need time for travelling on links, extending LSA age time with a delay is necessery,
especially for low speed links.
Follow these steps to specify an LSA transmission delay on an interface:
1-34
interface-number
Specify an LSA transmission Optional

ospf trans-delay seconds
delay 1 second by default
Specifying SPF Calculation Interval
The LSDB changes lead to SPF calculations. When an OSPF network changes frequently, a large
amount of network resources will be occupied, reducing the working efficiency of routers. You can
adjust the SPF calculation interval for the network to reduce negative influence.
Follow these steps to configure SPF calculation interval:

Enter OSPF view —
spf-schedule-interval Optional
Specify SPF calculation
maximum-interval [ minimum-interval By default, the interval is 5
interval(s)
[ incremental-interval ] ] seconds.
With this task configured, when network changes are not frequent, SPF calculation applies at the
minimum-interval. If network changes become frequent, SPF calculation interval is incremented by
incremental-interval•2n-2 (n is the number of calculation times) each time a calculation occurs, up to the
maximum-interval.
Specifying the LSA Minimum Repeat Arrival Interval
After receiving the same LSA as the previously received LSA within the LSA minimum repeat arrival
interval, an interface discards the LSA.
Follow these steps to configure the LSA minimum repeat arrival interval:

Enter OSPF view —
Optional
Configure the LSA minimum
lsa-arrival-interval interval Defaults to 1000
repeat arrival interval
milliseconds.
1-35
The interval set with the lsa-arrival-interval command should be smaller or equal to the interval set
with the lsa-generation-interval command.
Specifying the LSA Generation Interval
With this feature configured, you can protect network resources and routers from being over consumed
due to frequent network changes.
Follow these steps to configure the LSA generation interval:

Enter OSPF view router-id | vpn-instance Required
instance-name ] *
Optional
lsa-generation-interval By default, the maximum interval
Configure the LSA is 5 seconds, the minimum
maximum-interval [ initial-interval
generation interval interval is 0 milliseconds and the
[ incremental-interval ] ]
incremental interval is 5000
milliseconds.
With this command configured, when network changes are not frequent, LSAs are generated at the
minimum-interval. If network changes become frequent, LSA generation interval is incremented by
incremental-interval•2n-2 (n is the number of generation times) each time a generation occurs, up to
the maximum-interval.
Disabling Interfaces from Sending OSPF Packets
Follow these steps to disable interfaces from sending routing information:

instance-name ] *
Disable interfaces from silent-interface { all | Optional

sending OSPF packets interface-type interface-number } Not disabled by default
1-36
z Different OSPF processes can disable the same interface from sending OSPF packets. Use of the
silent-interface command disables only the interfaces associated with the current process rather
than interfaces associated with other processes.
z After an OSPF interface is set to silent, other interfaces on the router can still advertise direct
routes of the interface in Router LSAs, but no OSPF packet can be advertised for the interface to
find a neighbor. This configuration can enhance adaptability of OSPF networking and reduce
resource consumption.
Configuring Stub Routers
A stub router is used for traffic control. It tells other OSPF routers not to use it to forward data, but they
can have a route to it.
The Router LSAs from the stub router may contain different link type values. A value of 3 means a link to
the stub network, so the cost of the link remains unchanged. A value of 1, 2 or 4 means a point-to-point
link, a link to a transit network or a virtual link. In such cases, a maximum cost value of 65535 is used.
Thus, other neighbors find the links to the stub router have such big costs, they will not send packets to
the stub router for forwarding as long as there is a route with a smaller cost.
Follow these steps to configure a router as a stub router:

Enter OSPF view —
Configure the router as a Required

stub-router
stub router Not configured by default.
A stub router has nothing to do with a stub area.
Configuring OSPF Authentication
OSPF supports packet authentication to ensure the security of packet exchange.

By supporting packet authentication, OSPF receives packets that pass the authentication only, so failed
packets cannot establish neighboring relationships.
To configure OSPF packet authentication, you need to configure the same area authentication mode on
all the routers in the area. In addition, the authentication mode and password for all interfaces attached
to the same area must be identical.
Follow these steps to configure OSPF authentication:
1-37
Enter OSPF view —
Required
Configure the authentication
authentication-mode { simple | md5 } Not configured by
mode
default.
Exit to OSPF view quit —
Exit to system view quit —
interface-number
Configure the authentication
ospf authentication-mode simple
mode (simple authentication)
[ plain | cipher ] password Either is required.
for the interface
Not configured by
Configure the authentication ospf authentication-mode { md5 | default.
mode (MD5 authentication) for hmac-md5 } key-id [ plain | cipher ]
the interface password
Adding the Interface MTU into DD Packets
Generally, when an interface sends a DD packet, it adds 0 into the Interface MTU field of the DD packet
rather than the interface MTU.
Follow these steps to add the interface MTU into DD packets:

interface-number
Optional
Enable OSPF to add the
ospf mtu-enable Not enabled by default.; that is,
interface MTU into DD packets
the interface fills in a value of 0.
Configuring the Maximum Number of External LSAs in LSDB
Follow these steps to configure the maximum number of external LSAs in the Link State Database:

Enter OSPF view —
Specify the maximum number Optional

lsdb-overflow-limit number
of external LSAs in the LSDB No specified by default
1-38
Making External Route Selection Rules Defined in RFC1583 Compatible
The selection of an external route from multiple LSAs defined in RFC2328 is different from the one
defined in RFC1583. If RFC 1583 is made compatible with RFC 2328, the routes in the backbone area
are preferred; if not, the routes in the non-backbone area are preferred to reduce the burden of the
backbone area.
Follow these steps to make them compatible:

Enter OSPF view Required
Make RFC1583 Optional

rfc1583 compatible
compatible Compatible by default
To avoid routing loops, it is recommended to configure all the routers to be either compatible or
incompatible with the external route selection rules defined in RFC 1583.
Logging Neighbor State Changes
Follow these steps to enable the logging of neighbor state changes:

Enter OSPF view —
Enable the logging of neighbor Optional

log-peer-change
state changes Enabled by default
Configuring OSPF Network Management
After trap generation is enabled for OSPF, OSPF generates traps to report important events. Traps fall
into the following levels:
z Level-3, for fault traps
z Level-4, for alarm traps
z Level-5, for normal but important traps
z Level-6, for notification traps
The generated traps are sent to the Infomraiton Center of the device. The output rules of the traps,
namely, whether to output the traps and the ouput direction, are determined according to the
Information Center configuration. (For Information Center configuration, refer to "Information Center
Configuration" in the System Volume.)
1-39
Follow these steps to configure OSPF network management:

Optional
Bind OSPF MIB to an The first OSPF process is
ospf mib-binding process-id
OSPF process bound with OSPF MIB by
default.
snmp-agent trap enable ospf

[ process-id ] [ ifauthfail | ifcfgerror |
ifrxbadpkt | ifstatechange | iftxretransmit
Enable OSPF trap | lsdbapproachoverflow | lsdboverflow | Optional
generation maxagelsa | nbrstatechange | Enabled by default
originatelsa | vifcfgerror | virifauthfail |
virifrxbadpkt | virifstatechange |
viriftxretransmit | virnbrstatechange ] *
Enabling Message Logging
Follow these steps to enable message logging:

Enter OSPF view —
Enable message Required

enable log [ config | error | state ]
logging Not enabled by default.
Enabling the Advertisement and Reception of Opaque LSAs
With this feature enabled, the OSPF router can receive and advertise Type 9, Type 10 and Type 11
opaque LSAs.
Follow these steps to enable the advertisement and reception of opaque LSAs:

Enter OSPF view —
Enable the advertisement and Optional

opaque-capability enable
reception of opaque LSAs Disabled by default
Configuring OSPF to Give Priority to Receiving and Processing Hello Packets
To ensure OSPF runs normally, a router receives and processes Hello packets and other protocol
packets at the same time. When the router has established neighbor relationships with multiple
neighboring routers and the routing table size is big, the router will need to receive and process large
1-40
numbers of packets. Configuring OSPF to give priority to receiving and processing Hello packets helps
ensure stable neighbor relationships.
Follow these steps to configure OSPF to give priority to receiving and processing Hello packets:

Configure OSPF to give Required
ospf packet-process
priority to receiving and
prioritized-treatment Not configured by default.
processing Hello packets
Configuring the LSU Transmit Rate
Sending large numbers of LSU packets for LSDB synchronization with neighbors may affect router
performance and consume large network bandwidths. Therefore, you can configure the router to send
LSU packets at intervals and limit the maximum number of LSU packets sent out an OSPF interface
each time.
You can configure the interval at which an OSPF interface sends LSU packets and the maximum
number of LSU packets the interface sends at each interval.
Follow these steps to configure the LSU transmit rate:

Enter OSPF view —
Optional
Configure the LSU transmit-pacing interval interval count By default, an OSPF
transmit rate count interface sends up to three
LSU packets every 20
milliseconds.
Configuring OSPF Graceful Restart
One device can act as both a GR Restarter and GR Helper at the same time.
Configuring the OSPF GR Restarter
You can configure the IETF standard or non IETF standard OSPF GR Restarter.
Configure the IETF standard OSPF GR Restarter
Follow these steps to configure the standard IETF OSPF GR Restarter:
1-41
ospf [ process-id | router-id Required
Enable OSPF and enter its
router-id | vpn-instance
view Disabled by default
instance-name ] *
Enable opaque LSA Required

advertisement capability Disabled by default
Enable the IETF standard Required
Graceful Restart capability for graceful-restart ietf
OSPF Disabled by default
Configure the Graceful Restart Optional

graceful-restart interval timer
interval for OSPF 120 seconds by default
Configure the non-IETF standard OSPF GR Restarter
Follow these steps to configure non-IETF standard OSPF GR Restarter:

instance-name ] *
Enable the link-local signaling Required

enable link-local-signaling
capability Disabled by default
enable Required
Enable the out-of-band
out-of-band-resynchronizati
re-synchronization capability Disabled by default
on
Enable non IETF standard Required
graceful-restart
Graceful Restart capability for
[ nonstandard ] Disabled by default
OSPF
Configure Graceful Restart Optional

graceful-restart interval timer
interval for OSPF 120 seconds by default
Configuring the OSPF GR Helper
You can configure the IETF standard or non IETF standard OSPF GR Helper.
Configuring the IETF standard OSPF GR Helper
Follow these steps to configure the IETF standard OSPF GR Helper:

instance-name ] *
1-42
Enable opaque LSA reception Required

and advertisement Not enabled by default.
Optional
Configure the neighbors for
graceful-restart help The router can server as a GR
which the router can serve as a
{ acl-number | prefix prefix-list } Helper for any OSPF neighbor
GR Helper
by default.
Configuring the non IETF standard OSPF GR Helper
Follow these steps to configure the non IETF standard OSPF GR Helper:

instance-name ] *
Enable the link-local signaling Required

enable link-local-signaling
capability Disabled by default
enable Required
Enable the out-of-band
out-of-band-resynchronizati
re-synchronization capability Disabled by default
on
Optional
Configure the neighbors for
graceful-restart help The router can server as a GR
which the router can serve as a
{ acl-number | prefix prefix-list } Helper for any OSPF neighbor
GR Helper
by default.
Triggering OSPF Graceful Restart
Performing active/standby switchover on a distributed device, or performing the following configuration

on an OSPF router will trigger OSPF Graceful Restart.
For the IETF standard GR capable routers, ensure they have the following capabilities enabled:
z Opaque LSA advertisement
z IETF standard GR
For the non IETF standard GR capable routers, ensure they have the following capabilities enabled:
z link local signaling
z out of band re-synchronization
z Non IETF standard GR
Follow these steps to trigger OSPF Graceful Restart:
reset ospf [ process-id ] Required

Trigger OSPF Graceful Restart
process graceful-restart Available in user view
1-43
Displaying and Maintaining OSPF
Display OSPF brief information display ospf [ process-id ] brief
Display OSPF statistics display ospf [ process-id ] cumulative
display ospf [ process-id ] lsdb [ brief | [ { ase |

router | network | summary | asbr | nssa |
Display Link State Database
opaque-link | opaque-area | opaque-as }
information
[ link-state-id ] ] [ originate-router
advertising-router-id | self-originate ] ]
display ospf [ process-id ] peer [ verbose |
Display OSPF neighbor
[ interface-type interface-number ]
information
[ neighbor-id ] ]
Display neighbor statistics of
display ospf [ process-id ] peer statistics
OSPF areas
Display next hop information display ospf [ process-id ] nexthop
display ospf [ process-id ] routing [ interface Available in
Display routing table
interface-type interface-number ] [ nexthop any view
information
nexthop-address ]
Display virtual link information display ospf [ process-id ] vlink
Display OSPF request queue display ospf [ process-id ] request-queue

information [ interface-type interface-number ] [ neighbor-id ]
Display OSPF retransmission display ospf [ process-id ] retrans-queue
queue information [ interface-type interface-number ] [ neighbor-id ]
Display OSPF ABR and ASBR
display ospf [ process-id ] abr-asbr
information
Display OSPF interface display ospf [ process-id ] interface [ all |
information interface-type interface-number ]
Display OSPF error information display ospf [ process-id ] error
Display OSPF ASBR display ospf [ process-id ] asbr-summary
summarization information [ ip-address { mask | mask-length } ]
reset ospf [ process-id ] counters [ neighbor
Reset OSPF counters
[ interface-type interface-number ] [ router-id ] ]
reset ospf [ process-id ] process Available in
Reset an OSPF process
[ graceful-restart ] user view
Re-enable OSPF route

reset ospf [ process-id ] redistribution
redistribution
OSPF Configuration Examples
These examples only cover commands for OSPF configuration.
1-44
Configuring OSPF Basic Functions
z As shown in the following figure, all switches run OSPF. The AS is split into three areas, in which,
Switch A and Switch B act as ABRs to forward routing information between areas.
z After configuration, all switches can learn routes to every network segment in the AS.
Network diagram
Figure 1-20 Network diagram for OSPF basic configuration
1) Configure IP addresses for interfaces (omitted)

2) Configure OSPF basic functions
# Configure Switch A.
[SwitchA] ospf
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Configure Switch B.
[SwitchB] ospf
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
# Configure Switch C
<SwitchC> system-view
1-45
[SwitchC] ospf
[SwitchC-ospf-1] area 1
[SwitchC-ospf-1-area-0.0.0.1] network 10.2.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.1] quit
[SwitchC-ospf-1] quit
# Configure Switch D
<SwitchD> system-view
[SwitchD] ospf
[SwitchD-ospf-1] area 2
[SwitchD-ospf-1-area-0.0.0.2] network 10.3.1.0 0.0.0.255
[SwitchD-ospf-1-area-0.0.0.2] quit
[SwitchD-ospf-1] quit
# Display information about neighbors on Switch A.
[SwitchA] display ospf peer verbose
OSPF Process 1 with Router ID 10.2.1.1

Neighbors
Area 0.0.0.0 interface 10.1.1.1(Vlan-interface100)'s neighbors

Router ID: 10.3.1.1 Address: 10.1.1.2 GR State: Normal
State: Full Mode: Nbr is Master Priority: 1
DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
Dead timer due in 37 sec
Neighbor is up for 06:03:59
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
Neighbors

DR: 10.2.1.1 BDR: 10.2.1.2 MTU: 0
Neighbor state change count: 5
# Display OSPF routing information on Switch A.

[SwitchA] display ospf routing

Routing Tables
1-46
Routing for Network
Destination Cost Type NextHop AdvRouter Area
10.2.1.0/24 10 Transit 10.2.1.1 10.2.1.1 0.0.0.1
10.3.1.0/24 4 Inter 10.1.1.2 10.3.1.1 0.0.0.0
10.4.1.0/24 13 Stub 10.2.1.2 10.4.1.1 0.0.0.1
10.5.1.0/24 14 Inter 10.1.1.2 10.3.1.1 0.0.0.0
10.1.1.0/24 2 Transit 10.1.1.1 10.2.1.1 0.0.0.0
Total Nets: 5
Intra Area: 3 Inter Area: 2 ASE: 0 NSSA: 0
# Display the Link State Database on Switch A.

[SwitchA] display ospf lsdb

Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.2.1.1 10.2.1.1 1069 36 80000012 0
Router 10.3.1.1 10.3.1.1 780 36 80000011 0
Network 10.1.1.1 10.2.1.1 1069 32 80000010 0
Sum-Net 10.5.1.0 10.3.1.1 780 28 80000003 12
Sum-Net 10.2.1.0 10.2.1.1 1069 28 8000000F 10
Sum-Net 10.3.1.0 10.3.1.1 780 28 80000014 2
Sum-Net 10.4.1.0 10.2.1.1 769 28 8000000F 13
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.2.1.1 10.2.1.1 769 36 80000012 0
Router 10.4.1.1 10.4.1.1 1663 48 80000012 0
Network 10.2.1.1 10.2.1.1 769 32 80000010 0
Sum-Net 10.5.1.0 10.2.1.1 769 28 80000003 14
Sum-Net 10.3.1.0 10.2.1.1 1069 28 8000000F 4
Sum-Net 10.1.1.0 10.2.1.1 1069 28 8000000F 2
Sum-Asbr 10.3.1.1 10.2.1.1 1069 28 8000000F 2
# Display OSPF routing information on Switch D.

[SwitchD] display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 22 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.3.1.0/24 10 Transit 10.3.1.2 10.3.1.1 0.0.0.2
10.4.1.0/24 25 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.5.1.0/24 10 Stub 10.5.1.1 10.5.1.1 0.0.0.2
1-47
10.1.1.0/24 12 Inter 10.3.1.1 10.3.1.1 0.0.0.2
Total Nets: 5
# On Switch D, ping the IP address 10.4.1.1 to check connectivity.

[SwitchD] ping 10.4.1.1

0.00% packet loss
Configuring OSPF Route Redistribution
z All the switches run OSPF, and the AS is divided into three areas.
z Switch A and Switch B act as ABRs to forward routes between areas.
z Switch C is configured as an ASBR to redistribute external routes (static routes). Routing
information is propagated properly in the AS.
Network diagram
Figure 1-21 Network diagram for OSPF redistributing routes from outside of an AS (on switches)
1) Configure IP addresses for interfaces (omitted).

2) Configure OSPF basic functions (Refer to Configuring OSPF Basic Functions).
3) Configure OSPF to redistribute routes.
# On Switch C, configure a static route destined for network 3.1.2.0/24.
1-48
[SwitchC] ip route-static 3.1.2.1 24 10.4.1.2
# On Switch C, configure OSPF to redistribute static routes.

[SwitchC] ospf 1
[SwitchC-ospf-1] import-route static
4) Verify the configuration.
# Display the ABR/ASBR information of Switch D.
<SwitchD> display ospf abr-asbr

Routing Table to ABR and ASBR
Type Destination Area Cost Nexthop RtType

Intra 10.3.1.1 0.0.0.2 10 10.3.1.1 ABR
Inter 10.4.1.1 0.0.0.2 22 10.3.1.1 ASBR
# Display the OSPF routing table of Switch D.

<SwitchD> display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 22 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.3.1.0/24 10 Transit 10.3.1.2 10.3.1.1 0.0.0.2
10.4.1.0/24 25 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.5.1.0/24 10 Stub 10.5.1.1 10.5.1.1 0.0.0.2
10.1.1.0/24 12 Inter 10.3.1.1 10.3.1.1 0.0.0.2
Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter
3.1.2.0/24 1 Type2 1 10.3.1.1 10.4.1.1
Total Nets: 6
Configuring OSPF to Advertise a Summary Route
z Switch A and Switch B are in AS 200, which runs OSPF.

z Switch C, Switch D, and Switch E are in AS 100, which runs OSPF.
z An eBGP connection is established between Switch B and Switch C. Switch C is configured to
redistribute OSPF routes into BGP.
z Switch B is configured to redistribute BGP routes into OSPF. Switch B is configured with route
summarization and advertises only the summary route 10.0.0.0/8 to reduce Switch A's routing table
size.
1-49
Network diagram
Figure 1-22 Network diagram for OSPF summary route advertisement (on switches)

[SwitchA] ospf
[SwitchB] ospf
# Configure Switch C.
[SwitchC] ospf
# Configure Switch D.
1-50
[SwitchD] ospf
# Configure Switch E.
<SwitchE> system-view
[SwitchE] ospf
[SwitchE-ospf-1] area 0
[SwitchE-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[SwitchE-ospf-1-area-0.0.0.0] network 10.4.1.0 0.0.0.255
[SwitchE-ospf-1-area-0.0.0.0] quit
[SwitchE-ospf-1] quit
3) Configure BGP
[SwitchB] bgp 200
[SwitchB-bgp] peer 11.1.1.2 as 100
[SwitchB-bgp] quit
[SwitchC] bgp 100
[SwitchC-bgp] peer 11.1.1.1 as 200
[SwitchC-bgp] import-route ospf
4) Configure route redistribution on Switch B.
# Configure OSPF to redistribute routes from BGP on Switch B.
[SwitchB] ospf
[SwitchB-ospf-1] import-route bgp
# Display the OSPF routing table of Switch A.

[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 O_ASE 150 1 11.2.1.1 Vlan100

10.2.1.0/24 O_ASE 150 1 11.2.1.1 Vlan100
10.3.1.0/24 O_ASE 150 1 11.2.1.1 Vlan100
10.4.1.0/24 O_ASE 150 1 11.2.1.1 Vlan100
11.2.1.0/24 Direct 0 0 11.2.1.2 Vlan100
11.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
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
5) # Configure summary route 10.0.0.0/8 on Switch B and advertise it.
[SwitchB-ospf-1] asbr-summary 10.0.0.0 8
1-51
10.0.0.0/8 O_ASE 150 2 11.2.1.1 Vlan100

11.2.1.0/24 Direct 0 0 11.2.1.2 Vlan100
11.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
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
Configuring an OSPF Stub Area
The following figure shows an AS is split into three areas, where all switches run OSPF. Switch A and
Switch B act as ABRs to forward routing information between areas. Switch D acts as the ASBR to
redistribute routes (static routes).
It is required to configure Area 1 as a Stub area, reducing LSAs to this area without affecting route
reachability.
Network diagram
Figure 1-23 Network diagram for OSPF Stub area configuration (on switches)

2) Configure OSPF basic functions (refer to Configuring OSPF Basic Functions).
3) Configure Switch D to redistribute static routes.
[SwitchD] ip route-static 3.1.2.1 24 10.5.1.2
[SwitchD] ospf
[SwitchD-ospf-1] import-route static
1-52
# Display ABR/ASBR information on Switch C.
[SwitchC] display ospf abr-asbr

Routing Table to ABR and ASBR
Type Destination Area Cost Nexthop RtType

Intra 10.2.1.1 0.0.0.1 3 10.2.1.1 ABR
Inter 10.3.1.1 0.0.0.1 5 10.2.1.1 ABR
Inter 10.5.1.1 0.0.0.1 7 10.2.1.1 ASBR
# Display OSPF routing table information on Switch C.

[SwitchC] display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 3 Transit 10.2.1.2 10.2.1.1 0.0.0.1
10.3.1.0/24 7 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
10.5.1.0/24 17 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.1.1.0/24 5 Inter 10.2.1.1 10.2.1.1 0.0.0.1
Routing for ASEs

3.1.2.0/24 1 Type2 1 10.2.1.1 10.5.1.1
Total Nets: 6
In the above output, since Switch C resides in a normal OSPF area, its routing table contains an
external route.
4) Configure Area 1 as a Stub area.

[SwitchA] ospf
[SwitchA-ospf-1-area-0.0.0.1] stub
1-53
[SwitchC] ospf
[SwitchC-ospf-1-area-0.0.0.1] stub
# Display OSPF routing information on Switch C


Routing Tables
Routing for Network

0.0.0.0/0 4 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.2.1.0/24 3 Transit 10.2.1.2 10.2.1.1 0.0.0.1
10.3.1.0/24 7 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
10.5.1.0/24 17 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.1.1.0/24 5 Inter 10.2.1.1 10.2.1.1 0.0.0.1
Total Nets: 6
When Switch C resides in the Stub area, a default route takes the place of the external route.
# Filter Type-3 LSAs out the stub area

[SwitchA] ospf
[SwitchA-ospf-1-area-0.0.0.1] stub no-summary
# Display OSPF routing information on Switch C.


Routing Tables
Routing for Network

0.0.0.0/0 4 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.2.1.0/24 3 Transit 10.2.1.2 10.4.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
1-54
Total Nets: 3
After this configuration, routing entries on the stub router are further reduced, containing only one
default external route.
Configuring an OSPF NSSA Area
The following figure shows an AS is split into three areas, where all switches run OSPF. Switch A and
Switch B act as ABRs to forward routing information between areas.
It is required to configure Area 1 as an NSSA area, and configure Router C as the ASBR to redistribute
static routes into the AS.
Network diagram
Figure 1-24 Network diagram for OSPF NSSA area configuration
1) Configure IP addresses for interfaces.

2) Configure OSPF basic functions (refer to Configuring OSPF Basic Functions )
3) Configure Area 1 as an NSSA area.
[SwitchA] ospf
[SwitchA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary
[SwitchC] ospf
1-55
[SwitchC-ospf-1-area-0.0.0.1] nssa
It is recommended to configure the nssa command with the keyword default-route-advertise

no-summary on Switch A (an ABR) to reduce the routing table size on NSSA routers. On other NSSA
routers, use the nssa command.
# Display OSPF routing information on Switch C.


Routing Tables
Routing for Network

0.0.0.0/0 65536 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.2.1.0/24 65535 Transit 10.2.1.2 10.4.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
Total Nets: 3
4) Configure Switch C to redistribute static routes.
[SwitchC] ospf
# Display OSPF routing information on Switch D.

[SwitchD-ospf-1] display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 22 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.3.1.0/24 10 Transit 10.3.1.2 10.3.1.1 0.0.0.2
10.4.1.0/24 25 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.5.1.0/24 10 Stub 10.5.1.1 10.5.1.1 0.0.0.2
10.1.1.0/24 12 Inter 10.3.1.1 10.3.1.1 0.0.0.2
Routing for ASEs

1-56
3.1.3.0/24 1 Type2 1 10.3.1.1 10.2.1.1
Total Nets: 6
You can see on Switch D an external route imported from the NSSA area.
Configuring OSPF DR Election
z In the following figure, OSPF Switches A, B, C and D reside on the same network segment.
z It is required to configure Switch A as the DR, and configure Switch C as the BDR.
Network diagram
Figure 1-25 Network diagram for OSPF DR election configuration

Switch A Switch B
DR
Vlan-int1 Vlan-int1
192.168.1.1/24 192.168.1.2/24
Vlan-int1 Vlan-int1
192.168.1.3/24 192.168.1.4/24
BDR
Switch C Switch D

[SwitchA] router id 1.1.1.1
[SwitchA] ospf
[SwitchB] router id 2.2.2.2
[SwitchB] ospf
1-57
[SwitchC] router id 3.3.3.3
[SwitchC] ospf
[SwitchD] router id 4.4.4.4
[SwitchD] ospf
# Display OSPF neighbor information on Switch A.

[SwitchA] display ospf peer verbose

Neighbors

State: 2-Way Mode: None Priority: 1
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
1-58
Switch D becomes the DR, and Switch C is the BDR.

3) Configure router priorities on interfaces
[SwitchA-Vlan-interface1] ospf dr-priority 100
[SwitchB-Vlan-interface1] ospf dr-priority 0
[SwitchC] interface vlan-interface 1
[SwitchC-Vlan-interface1] ospf dr-priority 2
[SwitchC-Vlan-interface] quit
# Display neighbor information on Switch D.

[SwitchD] display ospf peer verbose

Neighbors

State: Full Mode:Nbr is Slave Priority: 100
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
The DR and BDR have no change.
1-59
In the above output, you can find the priority configuration does not take effect immediately.
4) Restart OSPF process

# Restart the OSPF process of Switch D.
<SwitchD> reset ospf 1 process
Warning : Reset OSPF process? [Y/N]:y
# Display neighbor information on Switch D.

[SwitchD] display ospf peer verbose

Neighbors

State: Full Mode: Nbr is Slave Priority: 100
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

State: 2-Way Mode: None Priority: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

State: Full Mode: Nbr is Slave Priority: 2
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
Switch A becomes the DR, and Switch C is the BDR.
If the neighbor state is full, it means Switch D has established the adjacency with the neighbor. If the
neighbor state is 2-way, it means the two switches are neither the DR nor the BDR, and they do not
exchange LSAs.
1-60
# Display OSPF interface information.
[SwitchA] display ospf interface

Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 100 192.168.1.1 192.168.1.3
[SwitchB] display ospf interface

Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.2 Broadcast DROther 1 0 192.168.1.1 192.168.1.3
The interface state DROther means the interface is not the DR/BDR.
Configuring OSPF Virtual Links
z In the following figure, Area 2 has no direct connection to Area 0, and Area 1 acts as the Transit
Area to connect Area 2 to Area 0 via a configured virtual link between Switch B and Switch C.
z After configuration, Switch B can learn routes to Area 2.
Network diagram
Figure 1-26 Network diagram for OSPF virtual link configuration
1-61
[SwitchA] ospf 1 router-id 1.1.1.1
[SwitchB] ospf 1 router-id 2.2.2.2
[SwitchB–ospf-1-area-0.0.0.1] network 10.2.1.0 0.0.0.255
[SwitchB–ospf-1-area-0.0.0.1] quit
[SwitchC] ospf 1 router-id 3.3.3.3
[SwitchC–ospf-1-area-0.0.0.2] network 10.3.1.0 0.0.0.255
[SwitchC–ospf-1-area-0.0.0.2] quit
[SwitchD] ospf 1 router-id 4.4.4.4
# Display the OSPF routing table of Switch B.

[SwitchB] display ospf routing

Routing Tables
Routing for Network
10.2.1.0/24 2 Transit 10.2.1.1 3.3.3.3 0.0.0.1
10.1.1.0/24 2 Transit 10.1.1.2 2.2.2.2 0.0.0.0
Total Nets: 2
1-62
Since Area 0 has no direct connection to Area 2, the routing table of Switch B has no route to Area 2.
3) Configure a virtual link

[SwitchB] ospf
[SwitchB-ospf-1-area-0.0.0.1] vlink-peer 3.3.3.3
[SwitchC] ospf 1
[SwitchC-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
# Display the OSPF routing table of Switch B.

[SwitchB] display ospf routing
Routing Tables
Routing for Network

10.2.1.0/24 2 Transit 10.2.1.1 3.3.3.3 0.0.0.1
10.3.1.0/24 5 Inter 10.2.1.2 3.3.3.3 0.0.0.0
10.1.1.0/24 2 Transit 10.1.1.2 2.2.2.2 0.0.0.0
Total Nets: 3
Switch B has learned the route 10.3.1.0/24 to Area 2.
OSPF Graceful Restart Configuration Example
z Switch A, Switch B and Switch C that belong to the same autonomous system and the same OSPF
routing domain are GR capable.
z Switch A acts as the non IETF standard GR Restarter whereas Switch B and Switch C are the GR
Helpers and re-synchronize their LSDB with Switch A through OOB communication of GR.
1-63
Network diagram
Figure 1-27 Network diagram for OSPF GR configuration
[SwitchA] router id 1.1.1.1
[SwitchA] ospf 100
[SwitchA-ospf-100] enable link-local-signaling
[SwitchA-ospf-100] enable out-of-band-resynchronization
[RouterA-ospf-100] graceful-restart
[SwitchA-ospf-100-area-0.0.0.0] return
[SwitchB] acl number 2000
[SwitchB-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[SwitchB-acl-basic-2000] quit
[SwitchB] router id 2.2.2.2
[SwitchB] ospf 100
[SwitchB-ospf-100] graceful-restart help 2000
3) Configure Switch C
[SwitchC] acl number 2000
[SwitchC-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[SwitchC-acl-basic-2000] quit
[SwitchC] interface vlan-interface 100
[SwitchC-Vlan-interface100] ip address 192.1.1.3 255.255.255.0
1-64
[SwitchC-Vlan-interface100] quit
[SwitchC] router id 3.3.3.3
[SwitchC] ospf 100
[SwitchC-ospf-100] graceful-restart help 2000
# After the configurations on Switch A, Switch B and Switch C are completed and the switches are
running steadily, enable OSPF Graceful Restart event debugging and then perform OSPF GR on
Switch A.
<SwitchA> debugging ospf event graceful-restart
<SwitchA> terminal monitor
<SwitchA> terminal debugging
<SwitchA> reset ospf 100 process graceful-restart
Warning : Reset OSPF process? [Y/N]:y
%Dec 12 09:36:12:500 2006 SwitchA RM/3/RMLOG:OSPF-NBRCHANGE: Process 1, Neighbour
192.1.1.1(Vlan100) from Full to Down
OSPF 1: Intf 192.1.1.1 Rcv InterfaceDown State BackupDR -> Down.
OSPF 1 nonstandard GR Started for OSPF Router
OSPF 1 notify RM that OSPF process will enter GR.
OSPF 1 created GR wait timer, timeout interval is 40(s).
OSPF 1 created GR Interval timer,timeout interval is 120(s).
OSPF 1: Intf 192.1.1.1 Rcv InterfaceUp State Down -> Waiting.
OSPF 1: Intf 192.1.1.1 Rcv BackupSeen State Waiting -> BackupDR.
OSPF 1 created OOB Progress timer for neighbor 192.1.1.2.
OSPF 1 restarted OOB Progress timer for neighbor 192.1.1.2.
%Oct 22 09:36:12:566 2008 SwitchA RM/3/RMLOG:OSPF-NBRCHANGE: Process 1, Neighbour
192.1.1.2(Vlan100) from Loading to Full
OSPF 1 deleted OOB Progress timer for neighbor 192.1.1.2.
OSPF 1 Gr Wait Timeout timer fired.
OSPF 1 deleted GR wait timer.
OSPF 1 deleted GR Interval timer.
OSPF 1 GR Completed for OSPF Router
OSPF 1 notified RM that OSPF process left GR.
RM notified that all protocol left GR.
OSPF 1 started flushing STALE LSA after all protocol left GR.
OSPF 1: Flush Stale Area LSAs
OSPF 1: Start Flush Stale ASE + NSSA LSAs
OSPF 1: End Flush Stale ASE + NSSA LSAs
Switch A completes GR with the help of Switch B.
Configuring Route Filtering
z All the switches in the network run OSPF. The AS is divided into three areas.
1-65
z Switch A and Switch B work as ABRs.
z Configure Switch C as an ASBR to redistribute external routes (static routes), and configure a filter
policy on Switch C to filter out redistributed route 3.1.3.0/24.
z Configure a route policy on Switch A to filter route 10.5.1.0/24.
Network diagram
Figure 1-28 Network diagram for OSPF route filtering configuration

2) Configure OSPF basic functions (Refer to Configuring OSPF Basic Functions ).
3) Configure OSPF to redistribute routes.


# On Switch C, configure OSPF to redistribute static routes.

[SwitchC] ospf 1

<SwitchA> display ip routing-table
3.1.1.0/24 O_ASE 150 1 10.2.1.2 Vlan200

3.1.2.0/24 O_ASE 150 1 10.2.1.2 Vlan200
3.1.3.0/24 O_ASE 150 1 10.2.1.2 Vlan200
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan200
1-66
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan200
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.3.1.0/24 OSPF 10 4 10.1.1.2 Vlan100
10.4.1.0/24 OSPF 10 13 10.2.1.2 Vlan200
10.5.1.0/24 OSPF 10 14 10.1.1.2 Vlan100
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
4) On Switch C, filter out route 3.1.3.0/24.
# Configure the IPv4 prefix list.
[SwitchC] ip ip-prefix prefix1 index 1 deny 3.1.3.0 24
[SwitchC] ip ip-prefix prefix1 index 2 permit 3.1.1.0 24
[SwitchC] ip ip-prefix prefix1 index 3 permit 3.1.2.0 24
# Reference the prefix list to filter out route 3.1.3.0/24.

[SwitchC] ospf 1
[SwitchC-ospf-1] filter-policy ip-prefix prefix1 export static

<SwitchA> display ip routing-table
3.1.1.0/24 O_ASE 150 1 10.2.1.2 Vlan200

3.1.2.0/24 O_ASE 150 1 10.2.1.2 Vlan200
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan100
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan200
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.3.1.0/24 OSPF 10 4 10.1.1.2 Vlan100
10.4.1.0/24 OSPF 10 13 10.2.1.2 Vlan200
10.5.1.0/24 OSPF 10 14 10.1.1.2 Vlan100
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 route destined for network 3.1.3.0/24 is filtered out.

5) On Switch A, filter out the route 10.5.1.1/24.
# Configure the ACL on Switch A.
<SwitchA> system-veiw
[SwitchA] acl number 2000
[SwitchA-acl-basic-2000] rule 0 deny source 10.5.1.0 0.0.0.255
[SwitchA-acl-basic-2000] rule 1 permit source any
[SwitchA-acl-basic-2000] quit
# Use the ACL to filter route 10.5.1.0/24.

[SwitchA] ospf 1
[SwitchA-ospf-1] filter-policy 2000 import
1-67

3.1.1.0/24 O_ASE 150 1 10.2.1.2 Vlan200

3.1.2.0/24 O_ASE 150 1 10.2.1.2 Vlan200
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan100
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan200
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.3.1.0/24 OSPF 10 4 10.1.1.2 Vlan100
10.4.1.0/24 OSPF 10 13 10.2.1.2 Vlan200
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 route destined for 10.5.1.1/24 is filtered out.
Troubleshooting OSPF Configuration

No OSPF Neighbor Relationship Established
Symptom
No OSPF neighbor relationship can be established.
Analysis
If the physical link and lower layer protocols work well, check OSPF parameters configured on
interfaces. Two neighbors must have the same parameters, such as the area ID, network segment and
mask (a P2P or virtual link may have different network segments and masks).
Processing steps
1) Display OSPF neighbor information using the display ospf peer command.
2) Display OSPF interface information using the display ospf interface command.
3) Ping the neighbor router’s IP address to check connectivity.
4) Check OSPF timers. The dead interval on an interface must be at least four times the hello interval.
5) On an NBMA network, using the peer ip-address command to specify the neighbor manually is
required.
6) On an NBMA or a broadcast network, at least one connected interface must have a DR priority
higher than 0.
Incorrect Routing Information
Symptom
OSPF cannot find routes to other areas.
1-68
Analysis
The backbone area must maintain connectivity to all other areas. If a router connects to more than one
area, at least one area must be connected to the backbone. The backbone cannot be configured as a
Stub area.
In a Stub area, all routers cannot receive external routes, and all interfaces connected to the Stub area
must belong to the Stub area.
Solution
1) Use the display ospf peer command to display neighbors.

2) Use the display ospf interface command to display OSPF interface information.
3) Use the display ospf lsdb command to display the Link State Database to check its integrity.
4) Display information about area configuration using the display current-configuration
configuration ospf command. If more than two areas are configured, at least one area is
connected to the backbone.
5) In a Stub area, all routers attached are configured with the stub command. In an NSSA area, all
interface connected to which are configured with the nssa command.
6) If a virtual link is configured, use the display ospf vlink command to check the state of the virtual
link.
1-69
Table of Contents
1 BGP Configuration ····································································································································1-1

BGP Overview·········································································································································1-1
Formats of BGP Messages ·············································································································1-2
BGP Path Attributes ························································································································1-4
BGP Route Selection·······················································································································1-8
iBGP and IGP Synchronization ·····································································································1-10
Settlements for Problems in Large Scale BGP Networks ·····························································1-11
BGP GR·········································································································································1-14
MP-BGP ········································································································································1-15
BGP Configuration Task List·················································································································1-16
Configuring BGP Basic Functions·········································································································1-17
Prerequisites··································································································································1-17
Creating a BGP Connection ··········································································································1-17
Specifying the Source Interface for TCP Connections··································································1-18
Allowing Establishment of eBGP Connection to a Non Directly Connected Peer/Peer Group········1-19
Controlling Route Generation ···············································································································1-19
Prerequisites··································································································································1-19
Injecting a Local Network ··············································································································1-19
Configuring BGP Route Redistribution··························································································1-20
Enabling Default Route Redistribution into BGP···········································································1-20
Controlling Route Distribution and Reception·······················································································1-20
Prerequisites··································································································································1-20
Configuring BGP Route Summarization························································································1-21
Advertising a Default Route to a Peer or Peer Group ···································································1-21
Configuring BGP Route Distribution/Reception Filtering Policies ·················································1-22
Enabling BGP and IGP Route Synchronization ············································································1-23
Limiting Prefixes Received from a Peer/Peer Group ····································································1-23
Configuring BGP Route Dampening ·····························································································1-24
Configuring a Shortcut Route ········································································································1-24
Configuring BGP Route Attributes ········································································································1-25
Prerequisites··································································································································1-25
Specifying a Preferred Value for Routes Received·······································································1-25
Configuring Preferences for BGP Routes ·····················································································1-25
Configure the Default Local Preference ························································································1-25
Configuring the MED Attribute·······································································································1-26
Configuring the Next Hop Attribute································································································1-28
Configuring the AS-PATH Attribute ·······························································································1-29
Tuning and Optimizing BGP Networks ·································································································1-31
Prerequisites··································································································································1-31
Configuring BGP Keepalive Interval and Holdtime ·······································································1-31
Configuring the Interval for Sending the Same Update·································································1-32
Configuring BGP Soft-Reset ·········································································································1-32
i
Enabling Quick eBGP Session Reestablishment··········································································1-33
Enabling MD5 Authentication for TCP Connections ·····································································1-34
Configuring BGP Load Balancing··································································································1-34
Forbiding Session Establishment with a Peer or Peer Group ·······················································1-34
Configuring a Large Scale BGP Network······························································································1-34
Configuring BGP Peer Groups ······································································································1-35
Configuring BGP Community ········································································································1-36
Configuring a BGP Route Reflector ······························································································1-37
Configuring a BGP Confederation·································································································1-37
Configuring BGP GR·····························································································································1-38
Enabling Trap········································································································································1-39
Enabling Logging of Peer State Changes·····························································································1-39
Displaying and Maintaining BGP ··········································································································1-40
Displaying BGP ·····························································································································1-40
Resetting BGP Connections··········································································································1-41
Clearing BGP Information ·············································································································1-41
BGP Configuration Examples ···············································································································1-41
BGP Basic Configuration···············································································································1-41
BGP and IGP Synchronization Configuration ···············································································1-45
BGP Load Balancing Configuration·······························································································1-48
BGP Community Configuration ·····································································································1-50
BGP Route Reflector Configuration ······························································································1-52
BGP Confederation Configuration·································································································1-54
BGP Path Selection Configuration ································································································1-57
Troubleshooting BGP····························································································································1-61
No BGP Peer Relationship Established ························································································1-61
ii
1 BGP Configuration
The Border Gateway Protocol (BGP) is a dynamic inter-AS Exterior Gateway Protocol.
When configuring BGP, go to these sections for information you are interested in:
z BGP Overview
z BGP Configuration Task List
z Configuring BGP Basic Functions
z Controlling Route Generation
z Controlling Route Distribution and Reception
z Configuring BGP Route Attributes
z Tuning and Optimizing BGP Networks
z Configuring a Large Scale BGP Network
z Configuring BGP GR
z Enabling Trap
z Enabling Logging of Peer State Changes
z Displaying and Maintaining BGP
z BGP Configuration Examples
z Troubleshooting BGP
The term “router” in this document refers to a router in a generic sense or a Layer 3 switch, and BGP
refers to BGP-4 in this document.
BGP Overview
There are three early BGP versions, BGP-1 (RFC1105), BGP-2 (RFC1163) and BGP-3 (RFC1267).
The current version in use is BGP-4 (RFC1771), which is the defacto Internet exterior gateway protocol
used between ISPs.
The characteristics of BGP are as follows:
z Focusing on the control of route propagation and the selection of optimal routes rather than the
route discovery and calculation, which makes BGP, an exterior gateway protocol different from
interior gateway protocols such as OSPF and RIP
z Using TCP to enhance reliability
z Supporting CIDR
z Reducing bandwidth consumption by advertising only incremental updates and therefore
applicable to advertising a great amount of routing information on the Internet
z Eliminating routing loops completely by adding AS path information to BGP routes
z Providing abundant policies to implement flexible route filtering and selection
z Good scalability
1-1
A router advertising BGP messages is called a BGP speaker. It establishes peer relationships with other
BGP speakers to exchange routing information. When a BGP speaker receives a new route or a route
better than the current one from another AS, it will advertise the route to all the other BGP peers in the
local AS.
To simplify configuration, multiple peers having an identical policy can be organized as a peer group.
BGP runs on a router in one of the following two modes:
z iBGP (internal BGP)
z eBGP (external BGP)
BGP is called iBGP when it runs within an AS and is called eBGP when it runs between ASs.
Formats of BGP Messages
Header
BGP has five types of messages:

z Open
z Update
z Notification
z Keep-alive
z Route-refresh
They have the same header, as shown below:
Figure 1-1 BGP message header
z Marker: The 16-byte field is used for BGP authentication. If no authentication information is
available, the Marker must be all ones.
z Length: The 2-byte unsigned integer indicates the total length of the message.
z Type: This 1-byte unsigned integer indicates the type code of the message. The following type
codes are defined: 1–Open, 2-Update, 3-Notification, 4–Keepalive, and 5–Route-refresh. The
former four are defined in RFC1771, and the last one is defined in RFC2918.
Open
After a TCP connection is established, the first message sent by each side is an Open message for peer
relationship establishment. An Open message contains the following fields:
1-2
Figure 1-2 BGP open message format
z Version: This 1-byte unsigned integer indicates the protocol version number. The current BGP
version is 4.
z My autonomous system: This 2-byte unsigned integer indicates the Autonomous System number
of the sender.
z Hold time: When establishing a peer relationship, two parties negotiate an identical hold time. If no
Keepalive or Update is received from a peer within the hold time, the BGP connection is considered
down.
z BGP identifier: An IP address that identifies the BGP router
z Opt Parm Len (Optional Parameters Length): Length of optional parameters, which is set to 0 if no
optional parameter is available.
z Optional parameters: Used for BGP authentication, multiprotocol extensions, and so on.
Update
The Update messages are used to exchange routing information between peers. It can advertise a
feasible route or remove multiple unfeasible routes. Its format is shown below:
Figure 1-3 BGP Update message format
Unfeasible routes length 2 Octets
Withdrawn routes N Octets
Total path attribute length 2 Octets
Path attributes N Octets
NLRI N Octets
Each update message can advertise a group of feasible routes with identical attributes, and the routes
are contained in the network layer reachable information (NLRI) field. The Path Attributes field carries
attributes of these routes. Each update message can also carry multiple withdrawn routes in the
Withdrawn Routes field.
z Unfeasible routes length: The total length of the Withdrawn Routes field in bytes. A value of 0
indicates no route is withdrawn from service, and the Withdrawn Routes field is not present in this
Update message.
z Withdrawn routes: This is a variable length field that contains a list of withdrawn IP prefixes.
z Total path attribute length: Total length of the Path Attributes field in bytes. A value of 0 indicates
that no Network Layer Reachability Information field is present in this Update message.
z Path attributes: List of path attributes related to NLRI. Each path attribute is a triple <attribute type,
attribute length, attribute value> of variable length. BGP uses these attributes to avoid routing loops,
and perform routing and protocol extensions.
1-3
z NLRI (Network Layer Reachability Information): Each feasible route is represented as <length,
prefix>.
Notification
A Notification message is sent when an error is detected. The BGP connection is closed immediately
after sending it. The Notification message format is shown below:
Figure 1-4 BGP Notification message format
z Error code: Type of Notification.

z Error subcode: Specific information about the nature of the reported error.
z Data: Used to diagnose the reason for the Notification. The contents of the Data field depend upon
the Error Code and Error Subcode. Erroneous part of data is recorded. The Data field length is
variable.
Keepalive
Keepalive messages are sent between peers to maintain connectivity. Its format contains only the
message header.
Route-refresh
A route-refresh message is sent to a peer to request the resending of the specified address family
routing information. Its format is shown below:
Figure 1-5 BGP Route-refresh message format
z AFI: Address family identifier.

z Res: Reserved. Set to 0.
z SAFI: Subsequent Address Family Identifier.
BGP Path Attributes
Classification of path attributes
Path attributes fall into four categories:

z Well-known mandatory: Must be recognized by all BGP routers and must be included in every
update message. Routing information errors occur without this attribute.
z Well-known discretionary: Can be recognized by all BGP routers and optional to be included in
every update message as needed.
z Optional transitive: Transitive attribute between ASs. A BGP router not supporting this attribute can
still receive routes with this attribute and advertise them to other peers.
1-4
z Optional non-transitive: If a BGP router does not support this attribute, it will not advertise routes
with this attribute.
The usage of each BGP path attribute is described in the following table.
Table 1-1 Usage of BGP path attributes
Name Category
ORIGIN Well-known mandatory
AS_PATH Well-known mandatory
NEXT_HOP Well-known mandatory

LOCAL_PREF Well-known discretionary
ATOMIC_AGGREGATE Well-known discretionary
AGGREGATOR Optional transitive

COMMUNITY Optional transitive
MULTI_EXIT_DISC (MED) Optional non-transitive
ORIGINATOR_ID Optional non-transitive

CLUSTER_LIST Optional non-transitive
Usage of BGP path attributes
1) ORIGIN
ORIGIN is a well-known mandatory attribute, which defines the origin of routing information, that is, how
a route became a BGP route. It involves three types:
z IGP: Has the highest priority. Routes added to the BGP routing table using the network command
have the IGP attribute.
z EGP: Has the second highest priority. Routes obtained via EGP have the EGP attribute.
z incomplete: Has the lowest priority. The source of routes with this attribute is unknown, which does
not mean such routes are unreachable. The routes redistributed from other routing protocols have
the incomplete attribute.
2) AS_PATH
AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems
through which routing information carried in this Update message has passed. When a route is
advertised from the local AS to another AS, each passed AS number is added into the AS_PATH
attribute, thus the receiver can determine ASs to route the massage back. The number of the AS
closest to the receiver’s AS is leftmost, as shown below:
1-5
Figure 1-6 AS_PATH attribute
8.0.0.0
AS 10
D = 8.0.0.0 D = 8.0.0.0
(10) (10)
AS 20 AS 40
D = 8.0.0.0 D = 8.0.0.0
(20,10) (40,10)
D = 8.0.0.0
(30,20,10)
AS 30 AS 50
In general, a BGP router does not receive routes containing the local AS number to avoid routing loops.
The current implementation supports using the peer allow-as-loop command to receive routes
containing the local AS number to meet special requirements.
The AS_PATH attribute can be used for route selection and filtering. BGP gives priority to the route with
the shortest AS_PATH length if other factors are the same. As shown in the above figure, the BGP
router in AS50 gives priority to the route passing AS40 for sending data to the destination 8.0.0.0.
In some applications, you can apply a routing policy to control BGP route selection by modifying the
AS_PATH length.
By configuring an AS path filtering list, you can filter routes based on AS numbers contained in the
AS_PATH attribute.
3) NEXT_HOP
Different from IGP, the NEXT_HOP attribute may not be the IP address of a directly connected router. It
involves three types of values, as shown in Figure 1-7.
z When advertising a self-originated route to an eBGP peer, a BGP speaker sets the NEXT_HOP for
the route to the address of its sending interface.
z When sending a received route to an eBGP peer, a BGP speaker sets the NEXT_HOP for the route
to the address of the sending interface.
z When sending a route received from an eBGP peer to an iBGP peer, a BGP speaker does not
modify the NEXT_HOP attribute. If load-balancing is configured, the NEXT_HOP attribute will be
modified. For load-balancing information, refer to BGP Route Selection.
1-6
Figure 1-7 NEXT_HOP attribute
4) MED (MULTI_EXIT_DISC)
The MED attribute is exchanged between two neighboring ASs, each of which does not advertise the
attribute to any other AS.
Similar with metrics used by IGP, MED is used to determine the best route for traffic going into an AS.
When a BGP router obtains multiple routes to the same destination but with different next hops, it
considers the route with the smallest MED value the best route if other conditions are the same. As
shown below, traffic from AS10 to AS20 travels through Router B that is selected according to MED.
Figure 1-8 MED attribute
MED = 0
Router B
2.1.1.1
D = 9.0.0.0
Next_hop = 2.1.1.1 IBGP
MED = 0 9.0.0.0
EBGP
Router A IBGP Router D
EBGP
D = 9.0.0.0
Next_hop = 3.1.1.1 IBGP
MED = 100 3.1.1.1
AS 10 Router C
AS 20
MED = 100
In general, BGP compares MEDs of routes received from the same AS only.
The current implementation supports using the compare-different-as-med command to force BGP to
compare MED values of routes received from different ASs.
5) LOCAL_PREF
1-7
The LOCAL_PREF attribute is exchanged between iBGP peers only, and thus is not advertised to any
other AS. It indicates the priority of a BGP router.
LOCAL_PREF is used to determine the best route for traffic leaving the local AS. When a BGP router
obtains from several iBGP peers multiple routes to the same destination but with different next hops, it
considers the route with the highest LOCAL_PREF value as the best route. As shown below, traffic from
AS20 to AS10 travels through Router C that is selected according to LOCAL_PREF.
Figure 1-9 LOCAL_PREF attribute
Local_pref = 100
Router B
EBGP IBGP
8.0.0.0 Next_hop = 2.1.1.1
2.1.1.1 Local_pref = 100
Router A IBGP Router D

EBGP
3.1.1.1 D = 8.0.0.0
Next_hop = 3.1.1.1
IBGP Local_pref = 200
AS 10
Router C AS 20
Local_pref = 200
6) COMMUNITY
The COMMUNITY attribute is used to simplify routing policy usage and ease management and
maintenance. It identifies a collection of destination addresses having identical attributes, without
physical boundaries in between, and having nothing to do with the local AS. Well known community
attributes involve:
z Internet: By default, all routes belong to the Internet community. Routes with this attribute can be
advertised to all BGP peers.
z No_Export: After received, routes with this attribute cannot be advertised out the local AS or out the
local confederation but can be advertised to other sub-ASs in the confederation (for confederation
information, refer to Settlements for Problems in Large Scale BGP Networks).
z No_Advertise: After received, routes with this attribute cannot be advertised to other BGP peers.
z No_Export_Subconfed: After received, routes with this attribute cannot be advertised out the local
AS or other ASs in the local confederation.
BGP Route Selection
Route selection rules
The current BGP implementation supports the following route selection sequence:
z Discard routes with unreachable NEXT_HOPs first
z Select the route with the highest Preferred_value
z Select the route with the highest LOCAL_PREF
z Select the summary route
z Select the route with the shortest AS-PATH
z Select IGP, EGP, Incomplete routes in turn
z Select the route with the lowest MED value
z Select routes learned from eBGP, confederation, iBGP in turn
1-8
z Select the route with the smallest next hop cost
z Select the route with the shortest CLUSTER_LIST
z Select the route with the smallest ORIGINATOR_ID
z Select the route advertised by the router with the smallest Router ID
z Select the route with the lowest IP address
z CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector receives a route that
contains its own CLUSTER ID in the CLUSTER_LIST, the router discards the route to avoid routing
loops.
z If load balancing is configured, the system selects available routes to implement load balancing.
Route selection with BGP load balancing
The next hop of a BGP route may not be directly connected. One of the reasons is next hops in routing
information exchanged between iBGPs are not modified. In this case, the BGP router needs to find the
directly connected next hop via IGP. The matching route with the direct next hop is called the recursive
route. The process of finding a recursive route is route recursion.
Currently, the system supports BGP load balancing based on route recursion, namely, if multiple
recursive routes to the same destination are load balanced (suppose three direct next hop addresses),
BGP generates the same number of next hops to forward packets. Note that BGP load balancing based
on route recursion is always enabled by the system rather than configured using commands.
BGP differs from IGP in the implementation of load balancing in the following:
z IGP routing protocols such as RIP, OSPF compute metrics of routes, and then implement load
balancing over routes with the same metric and to the same destination. The route selection
criterion is metric.
z BGP has no route computation algorithm, so it cannot implement load balancing according to
metrics of routes. However, BGP has abundant route selection rules, through which, it selects
available routes for load balancing and adds load balancing to route selection rules.
z BGP implements load balancing only on routes that have the same AS_PATH, ORIGIN,
LOCAL_PREF and MED.
z BGP load balancing is applicable between eBGP peers, between iBGP peers and between
confederations.
z If multiple routes to the same destination are available, BGP selects a configurable number of
routes for load balancing.
1-9
Figure 1-10 Network diagram for BGP load balancing
In the above figure, Router D and Router E are iBGP peers of Router C. Router A and Router B both
advertise a route destined for the same destination to Router C. If load balancing is configured and the
two routes have the same AS_PATH attribute, ORIGIN attribute, LOCAL_PREF and MED, Router C
installs both the two routes to its route table for load balancing. After that, Router C forwards to Router D
and Router E the route that has AS_PATH unchanged but has NEXT_HOP changed to Router C; other
BGP transitive attributes are those of the best route.
BGP route advertisement rules
The current BGP implementation supports the following route advertisement rules:
z When multiple feasible routes to a destination exist, the BGP speaker advertises only the best
route to its peers.
z A BGP speaker advertises only routes used by itself.
z A BGP speaker advertises routes learned through eBGP to all BGP peers, including both eBGP
and iBGP peers.
z A BGP speaker does not advertise routes from an iBGP peer to other iBGP peers.
z A BGP speaker advertises routes learned through iBGP to eBGP peers. Note that if BGP and IGP
synchronization is disabled, those routes are advertised to eBGP peers directly. If the feature is
enabled, only after IGP advertises those routes, can BGP advertise the routes to eBGP peers.
z A BGP speaker advertises all routes to a newly connected peer.
iBGP and IGP Synchronization
Routing information synchronization between iBGP and IGP avoids giving wrong directions to routers
outside of the local AS.
If a non-BGP router works in an AS, it may discard a packet due to an unreachable destination. As
shown in Figure 1-11, Router E has learned a route of 8.0.0.0/8 from Router D via BGP. Then Router E
sends a packet to 8.0.0.0/8 through Router D, which finds from its routing table that Router B is the next
hop (configured using the peer next-hop-local command). Because Router D has learned the route to
Router B via IGP, it forwards the packet to Router C through route recursion. Router C has no idea
about the route 8.0.0.0/8, so it discards the packet.
1-10
Figure 1-11 iBGP and IGP synchronization
If synchronization is enabled in this example, only when the route 8.0.0.0/24 received from Router B is
available in its IGP routing table, can Router D advertise the route to the eBGP peer.
You can disable the synchronization feature in the following cases:
z The local AS is not a transitive AS (AS20 is a transitive AS in the above figure).
z Routers in the local AS are iBGP fully meshed.
Settlements for Problems in Large Scale BGP Networks
Route summarization
Route summarization can reduce the routing table size on a large network, and allow BGP routers to
advertise only summary routes rather than more specific routes.
Currently, the system supports both manual and automatic route summarization. Manual route
summarization allows you to determine the attribute of a summary route and whether to advertise the
route.
Route dampening
BGP route dampening is used to solve the issue of route instability such as route flaps, that is, a route
comes up and disappears in the routing table frequently.
When a route flap occurs, the routing protocol sends an update to its neighbor, and then the neighbor
needs to recalculate routes and modify the routing table. Therefore, frequent route flaps consume large
bandwidth and CPU resources and even affect network normal operation.
In most cases, BGP is used in complex networks, where route changes are very frequent. To solve the
problem caused by route flaps, BGP route dampening is used to suppress unstable routes.
BGP route dampening uses a penalty value to judge the stability of a route. The bigger the value, the
less stable the route. Each time a route flap occurs, BGP adds a penalty value (1000, which is a fixed
number and cannot be changed) to the route. When the penalty value of the route exceeds the
suppress value, the route is suppressed from being added into the routing table or being advertised to
other BGP peers.
The penalty value of the suppressed route will decrease to a half of the suppress value after a period of
time. This period is called Half-life. When the value decreases to the reusable threshold value, the route
is added into the routing table and advertised to other BGP peers.
1-11
Figure 1-12 BGP route dampening
Peer group
You can organize BGP peers with the same attributes into a group to simplify configurations on them.
When a peer joins the peer group, the peer obtains the same configuration as the peer group. If the
configuration of the peer group is changed, the configuration of group members is changed accordingly.
When a peer is added into a peer group, the peer enjoys the same route update policy as the peer
group to improve route distribution efficiency.
If an option is configured for both a peer and its peer group, the last configuration takes effect.
Community
A peer group makes peers in it enjoy the same policy, while a community makes a group of BGP routers
in several ASs enjoy the same policy. Community is a path attribute and advertised between BGP peers,
without being limited by AS.
A BGP router can modify the community attribute for a route before sending it to other peers.
Besides using well-known community attributes, you can define extended community attributes by
using a community list to define a routing policy.
Route reflector
iBGP peers should be fully meshed to maintain connectivity. If there are n routers in an AS, the number
of iBGP connections is n (n-1)/2, and therefore large amounts of network and CPU resources will be
consumed.
Using route reflectors can solve this issue. In an AS, a router acts as a route reflector, and other routers
act as clients connecting to the route reflector. The route reflector forwards routing information between
clients, and thus BGP sessions between clients need not be established.
1-12
A router that is neither a route reflector nor a client is a non-client, which has to establish BGP sessions
to the route reflector and other non-clients, as shown below.
Figure 1-13 Network diagram for route reflector
The route reflector and clients form a cluster. In some cases, you can configure more than one route
reflector in a cluster to improve network reliability and prevent single point failure, as shown in the
following figure. The configured route reflectors must have the same Cluster_ID to avoid routing loops.
Figure 1-14 Network diagram for route reflectors
When the BGP routers in an AS are fully meshed, route reflection is unnecessary because it consumes
more bandwidth resources. You can use related commands to disable route reflection in this case.
After route reflection is disabled between clients, routes can still be reflected between a client and a
non-client.
1-13
Confederation
Confederation is another method to deal with growing iBGP connections in ASs. It splits an AS into
multiple sub-ASs. In each sub-AS, iBGP peers are fully meshed, and eBGP connections are
established between sub-ASs, as shown below:
Figure 1-15 Confederation network diagram
AS 65002 AS 65003
EBGP EBGP
EBGP
IBGP
AS 100 IBGP IBGP
AS 65004
AS 200
From the perspective of a non-confederation BGP speaker, it needs not know sub-ASs in the
confederation. The ID of the confederation is the number of the AS. In the above figure, AS 200 is the
confederation ID.
The deficiency of confederation is: when changing an AS into a confederation, you need to reconfigure
your routers, and the topology will be changed.
In large-scale BGP networks, both route reflector and confederation can be used.
BGP GR
For GR (Graceful Restart) information, refer to GR Configuration in the System Volume.
1) To establish a BGP session with a peer, a BGP GR Restarter sends an OPEN message with GR
capability to the peer.
2) Upon receipt of this message, the peer is aware that the sending router is capable of Graceful
Restart, and sends an OPEN message with GR Capability to the GR Restarter to establish a GR
session. If neither party has the GR capability, the session established between them will not be
GR capable.
3) The GR session between the GR Restarter and its peer goes down when the GR Restarter restarts
BGP. The GR capable peer will mark all routes associated with the GR Restarter as stale. However,
during the configured GR Time, it still uses these routes for packet forwarding.
1-14
4) After the restart, the GR Restarter will reestablish a GR session with its peer and send a new GR
message notifying the completion of restart. Routing information is exchanged between them for
the GR Restarter to create a new routing table and forwarding table with stale routing information
removed. Then the BGP routing convergence is complete.
MP-BGP
Overview
BGP-4 supports IPv4, but does not support other network layer protocols like IPv6.
To support more network layer protocols, IETF extended BGP-4 by introducing Multiprotocol
Extensions for BGP-4 (MP-BGP) in RFC2858.
Routers supporting MP-BGP can communicate with routers not supporting MP-BGP.
MP-BGP extended attibutes
In BGP-4, the three types of attributes for IPv4, namely NLRI, NEXT_HOP and AGGREGATOR
(AGGREGATOR contains the IP address of the speaker generating the summary route) are all carried
in updates.
To support multiple network layer protocols, BGP-4 puts information about network layer into NLRI and
NEXT_HOP. MP-BGP introduced two path attributes:
z MP_REACH_NLRI: Multiprotocol Reachable NLRI, for advertising feasible routes and next hops
z MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI, for withdrawing unfeasible routes
The above two attributes are both optional non-transitive, so BGP speakers not supporting
multi-protocol ignore the two attributes and do not forward them to its peers.
Address family
MP-BGP uses address families to differentiate network layer protocols. For address family values, refer
to RFC 1700 (Assigned Numbers). Currently, the system supports multiple MP-BGP extensions,
including VPN extension and IPv6 extension. Different extensions are configured in respective address
family view.
z For information about the VPN extension application, refer to MPLS L3VPN Configuration in the
MPLS Volume.
z For information about the IPv6 extension application, refer to IPv6 BGP Configuration in the IP
Routing Volume.
z This chapter gives no detailed commands related to any specific extension application in MP-BGP
address family view.
z RFC1771: A Border Gateway Protocol 4 (BGP-4)

z RFC2858: Multiprotocol Extensions for BGP-4
z RFC3392: Capabilities Advertisement with BGP-4
1-15
z RFC2918: Route Refresh Capability for BGP-4
z RFC2439: BGP Route Flap Damping
z RFC1997: BGP Communities Attribute
z RFC2796: BGP Route Reflection
z RFC3065: Autonomous System Confederations for BGP
z draft-ietf-idr-restart-08: Graceful Restart Mechanism for BGP
BGP Configuration Task List

Complete the following tasks to configure BGP:
Task Remarks
Creating a BGP Connection Required
Specifying the Source Interface for TCP
Configuring BGP Basic Optional
Connections
Functions
Allowing Establishment of eBGP Connection to a
Optional
Non Directly Connected Peer/Peer Group
Injecting a Local Network Required to
Controlling Route choose either.
Configuring BGP Route Redistribution
Generation
Enabling Default Route Redistribution into BGP Optional
Configuring BGP Route Summarization
Advertising a Default Route to a Peer or Peer Group
Configuring BGP Route Distribution/Reception

Controlling Route Filtering Policies
Distribution and Optional
Enabling BGP and IGP Route Synchronization
Reception
Limiting Prefixes Received from a Peer/Peer Group
Configuring BGP Route Dampening
Configuring a Shortcut Route

Specifying a Preferred Value for Routes Received Optional
Configuring Preferences for BGP Routes Optional
Configuring BGP Route Configure the Default Local Preference Optional

Attributes Configuring the MED Attribute Optional
Configuring the Next Hop Attribute Optional
Configuring the AS-PATH Attribute Optional

Configuring BGP Keepalive Interval and Holdtime Optional
Configuring the Interval for Sending the Same
Optional
Update
Configuring BGP Soft-Reset Optional
Tuning and Optimizing
Enabling Quick eBGP Session Reestablishment Optional
BGP Networks
Enabling MD5 Authentication for TCP Connections Optional
Configuring BGP Load Balancing Optional
Forbiding Session Establishment with a Peer or

Optional
Peer Group
1-16
Task Remarks
Configuring BGP Peer Groups Optional
Configuring a Large Configuring BGP Community Optional

Scale BGP Network Configuring a BGP Route Reflector Optional
Configuring a BGP Confederation Optional

Configuring BGP GR Optional
Enabling Trap Optional
Enabling Logging of Peer State Changes Optional
Configuring BGP Basic Functions
This section does not differentiate between BGP and MP-BGP.
Prerequisites
The neighboring nodes are accessible to each other at the network layer.
Creating a BGP Connection
A router ID is the unique identifier of a BGP router in an AS.

z To ensure the uniqueness of a router ID and enhance network reliability, you can specify in BGP
view the IP address of a local loopback interface as the router ID.
z If no router ID is specified in BGP view, the global router ID is used. For information about global
router ID, refer to IP Routing Overview in the IP Routing Volume.
z If the global router ID is used and then it is removed, the system will select a new router ID.
z If the router ID is specified in BGP view, using the undo router-id command can make the system
select a new router ID.
Follow these steps to create a BGP connection:

Enable BGP and enter BGP —

bgp as-number
view Not enabled by default
Optional
Specify a Router ID router-id router-id By default, the global router ID
is used.
peer { group-name | Required
Specify a peer or a peer group
ip-address } as-number
and its AS number Not specified by default
as-number
1-17
Enable the default use of IPv4
unicast address family for the Optional
peers that are established default ipv4-unicast
using the peer as-number Enabled by default
command
Optional
Enable a peer peer ip-address enable
Enabled by default
peer { group-name |
Configure a description for a
ip-address } description Not configured by default.
peer/peer group
description-text
z Since a router can reside in only one AS, the router can run only one BGP process.
z You need to create a peer group before configuring it.
Specifying the Source Interface for TCP Connections
BGP uses TCP as the transport layer protocol. By default, BGP uses the output interface of the optimal
router to a peer as the source interface for establishing TCP connections to the peer. If a BGP router
has multiple links to a peer, when the source interface fails, BGP has to reestablish TCP connections,
causing network oscillation. Therefore, it is recommended to use a loopback interface as the source
interface to enhance stability of BGP connections.
Follow these steps to specify the source interface of TCP connections:

Enter BGP view bgp as-number —
Required
peer { group-name |
Specify the source interface for ip-address } By default, BGP uses the outbound
establishing TCP connections connect-interface interface of the best route to the
to a peer or peer group interface-type BGP peer/peer group as the source
interface-number interface for establishing a TCP
connection to the peer/peer group.
To establish multiple BGP connections between two routers, you need to specify on the local router the
source interface for establishing TCP connections to each peer; otherwise, the local BGP router may
fail to establish TCP connections to a peer when using the outbound interface of the best route to the
peer as the source interface.
1-18
Allowing Establishment of eBGP Connection to a Non Directly Connected Peer/Peer
Group
In general, direct physical links should be available between eBGP peers. If not, you can use the peer
ebgp-max-hop command to establish a TCP connection over multiple hops between two peers.
Follow these steps to allow establishment of eBGP connection to a non directly connected peer/peer
group:

Allow the establishment of eBGP Optional
peer { group-name | ip-address }
connection to a non directly
ebgp-max-hop [ hop-count ] Not allowed by default.
connected peer/peer group
The peer ebgp-max-hop command needs not be configured if the two eBGP peers are directly
connected.
Controlling Route Generation

Different from IGP, BGP focuses on route generation and advertisement control and optimal route
selection.
There are to ways to generate BGP routes:
z Configure BGP to advertise local networks
z Configure BGP to redistribute routes from other routing protocols, including the default route
Prerequisites
BGP connections have been created.
Injecting a Local Network
In BGP view, you can inject a local network to allow BGP to advertise it to BGP peers. The origin
attribute of routes advertised in this way is IGP. You can also reference a route policy to flexibly control
route advertisement. The network to be injected must be available in the local IP routing table.
Follow these steps to inject a local network:

1-19
network ip-address [ mask | Optional
Inject a network to the BGP
mask-length ] route-policy
routing table Not injected by default
route-policy-name
Configuring BGP Route Redistribution
BGP does not find routes by itself. Rather, it redistributes routing information in the local AS from other
routing protocols. During route redistribution, you can configure BGP to filter routing information from
specific routing protocols.
The origin attribute of routes redistributed using the import-route command is Incomplete.
Follow these steps to configure BGP route redistribution:


import-route protocol [ process-id | Required
Enable route redistribution from
all-processes ] [ med med-value |
a routing protocol into BGP Not enabled by default
route-policy route-policy-name ] *
Enabling Default Route Redistribution into BGP
Using the import-route command cannot redistribute a default route. To do so, complete the following
configuration.
Follow these steps to enable default route redistribution into BGP:


Enable route redistribution import-route protocol [ process-id | Required
from a routing protocol into all-processes ] [ med med-value |
BGP route-policy route-policy-name ] * Not redistributed by default
Enable default route Optional

default-route imported
redistribution into BGP Not enabled by default
Controlling Route Distribution and Reception

Prerequisites
1-20
Configuring BGP Route Summarization
To reduce the routing table size on medium and large BGP networks, you need to configure route
summarization on BGP routers. BGP supports two summarization modes: automatic and manual.
Manual summary routes enjoy a higher priority than automatic ones.
Configure automatic route summarization
After automatic route summarization is configured, BGP summarizes redistributed IGP subnets to
advertise only natural networks. Routes injected with the network command can not be summarized.
Follow these steps to configure automatic route summarization:

Configure automatic route Required

summary automatic
summarization Not configured by default.
Configure manual route summarization
By configuring manual route summarization, you can summarize both redistributed routes and routes
injected using the network command and determine the mask length for a summary route as needed.
Follow these steps to configure BGP manual route summarization:

aggregate ip-address { mask | mask-length }

[ as-set | attribute-policy route-policy-name | Required
Configure manual
detail-suppressed | origin-policy Not configured by
route summarization
route-policy-name | suppress-policy default.
route-policy-name ]*
Advertising a Default Route to a Peer or Peer Group
After this task is configured, the BGP router sends a default route with the next hop being itself to the
specified peer/peer group, regardless of whether the default route is available in the routing table.
Follow these steps to advertise a default route to a peer or peer group:

peer { group-name | ip-address } Required

Advertise a default route to a
default-route-advertise [ route-policy Not advertised by
peer or peer group
route-policy-name ] default
1-21
Configuring BGP Route Distribution/Reception Filtering Policies
Prerequisites
You need to configure following filters as needed.

z ACL
z IP prefix list
z Route policy
z AS-path ACL
For how to configure an ACL, refer to ACL Configuration in the Security Volume.
For how to configure an IP prefix list, route policy and AS-path ACL, refer to Route Policy Configuration
in the Routing Volume.
Configure BGP route distribution filtering policies
Follow these steps to configure BGP route distribution filtering policies:

filter-policy { acl-number | Required to choose any;

ip-prefix ip-prefix-name }
Configure the filtering of Not configured by default.;
export [ direct | isis process-id
redistributed routes
| ospf process-id | rip You can configure a filtering
process-id | static ] policy as needed;
If several filtering policies are
Reference a routing policy to peer { group-name |
configured, they are applied in
filter advertisements to a ip-address } route-policy
the following sequence:
peer/peer group route-policy-name export
z filter-policy export
Reference an ACL to filer peer { group-name | z peer filter-policy export
advertisements to a peer/peer ip-address } filter-policy
z peer as-path-acl export
group acl-number export
z peer ip-prefix export
Reference an AS path ACL to peer { group-name | z peer route-policy export
filter routing information sent to ip-address } as-path-acl
Only routes pass the first
a peer/peer group as-path-acl-number export
policy, can they go to the next,
Reference an IP prefix list to peer { group-name | and only routes passing all the
filer routing information sent to ip-address } ip-prefix configured policies, can they be
a peer/peer group ip-prefix-name export advertised.
Configure BGP route reception filtering policies
Only routes permitted by the configured filtering policies can be installed into the local BGP routing table.
Members of a peer group can have different route reception filtering policies from the peer group.
Follow these steps to configure BGP route reception filtering policies:

1-22
filter-policy { acl-number | Required to choose any;
Filter incoming routes with an
ip-prefix ip-prefix-name } No route reception filtering is
ACL or IP prefix list
import configured by default;
Reference a routing policy to peer { group-name | You can configure a filtering
filter routes from a peer/peer ip-address } route-policy policy as needed;
group route-policy-name import If several filtering policies are
configured, they are applied in
Reference an ACL to filter peer { group-name |
routing information from a ip-address } filter-policy the following sequence:
peer/peer group acl-number import z filter-policy import
z peer filter-policy import
Reference an AS path ACL to peer { group-name |
z peer as-path-acl import
filter routing information from a ip-address } as-path-acl
peer/peer group as-path-acl-number import z peer ip-prefix import
z peer route-policy import
Only routes passing the first
Reference an IP prefix list to peer { group-name | policy, can they go to the next,
filter routing information from a ip-address } ip-prefix and only routes passing all the
peer/peer group ip-prefix-name import configured policies, can they be
received.
Enabling BGP and IGP Route Synchronization
By default, when a BGP router receives an iBGP route, it only checks the reachability of the route’s next
hop before advertisement. With BGP and IGP synchronization enabled, the BGP router cannot
advertise the iBGP route to eBGP peers unless the route is also available in the IGP routing table.
Follow these steps to enable BGP and IGP synchronization:

Enable synchronization Required

synchronization
between BGP and IGP Not enabled by default
Limiting Prefixes Received from a Peer/Peer Group
Follow these steps to configure the maximum number of prefixes allowed to be received from a
peer/peer group:

1-23
Specify the maximum number of prefixes that peer { group-name |
can be received from a peer/peer group. ip-address } route-limit
If the number is reached, the router breaks down prefix-number
the BGP connection to the peer. [ percentage-value ]
Specify the maximum number of prefixes that

peer { group-name | Required to
can be received from a peer/peer group.
ip-address } route-limit choose any;
If the number is reached, the router outputs alert prefix-number alert-only No limit is
information but does not break down the BGP [ percentage-value ] configured by
connection to the peer.
default.
Specify the maximum number of prefixes that peer { group-name |
can be received from a peer/peer group. ip-address } route-limit
If the number is reached, the router breaks down prefix-number reconnect
the BGP connection to the peer and then reconnect-time
reestablishes a BGP connection to the peer. [ percentage-value ]
Configuring BGP Route Dampening
By configuring BGP route dampening, you can suppress unstable routes from being added to the local
routing table or being advertised to BGP peers.
Follow these steps to configure BGP route dampening:

dampening [ half-life-reachable
Configure BGP route half-life-unreachable reuse suppress Required
dampening ceiling | route-policy Not configured by default.
route-policy-name ] *
Configuring a Shortcut Route
An eBGP route received has a priority of 255, lower than a local route. This task allows you configure an
eBGP route as a shortcut route that has the same priority as a local route and thus has greater likehood
to become the optimal route.
Follow these steps to configure a shortcut route:

Optional
network ip-address [ mask |
Configure a shortcut route By default, an eBGP route
mask-length ] short-cut
received has a priority of 255.
1-24
Configuring BGP Route Attributes
Prerequisites
Specifying a Preferred Value for Routes Received
By default, routes received from a peer have a preferred value of 0. Among multiple routes that have the
same destination/mask and are learned from different peers, the one with the greatest preferred value
is selected as the route to the destination.
Follow these steps to specify a preferred value for routes from a peer or peer group:

Specify a preferred value for peer { group-name | Optional

routes received from a peer or ip-address } preferred-value The preferred value is 0 by
peer group value default.
Configuring Preferences for BGP Routes
A router may run multiple routing protocols, each of which has a preference specified. If they find the
same route, the route found by the routing protocol with the highest preference is selected.
This task allows you configure preferences for external, internal, local BGP routes and reference a route
policy to set preferences for matching routes as needed.
Follow these steps to configure preferences for BGP routes:

preference Optional
Configure preferences for { external-preference The default preferences of
external, internal, local BGP internal-preference external, internal, and local
routes local-preference | route-policy BGP routes are 255, 255, and
route-policy-name } 130 respectively.
Configure the Default Local Preference
The local preference is used to determine the best route for traffic leaving the local AS. When a BGP
router obtains from several iBGP peers multiple routes to the same destination but with different next
hops, it considers the route with the highest local preference as the best route.
This task allows you to specify the default local preference for routes sent to iBGP peers.
Follow these steps to specify the default local preference:
1-25
Configure the default local Optional

default local-preference value
preference 100 by default
Configuring the MED Attribute
MED is used to determine the best route for traffic going into an AS. When a BGP router obtains from
eBGP peers multiple routes to the same destination but with different next hops, it considers the route
with the smallest MED value as the best route if other conditions are the same.
Configure the default MED value
Follow these steps to configure the default MED value:

Configure the default MED Optional

default med med-value
value 0 by default
Enable the comparison of MED of routes from different ASs
Follow these steps to enable the comparison of MED of routes from different ASs:

Enable the comparison of MED Required

compare-different-as-med
of routes from different ASs Not enabled by default
Enable the comparison of MED of routes from each AS
Route learning sequence may affect optimal route selection.
1-26
Figure 1-16 Route selection based on MED
As shown in the figure above, Router D learns network 10.0.0.0 from both Router A and Router B.
Because Router B has a smaller router ID, the route learned from it is optimal.
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.0.0.0 2.2.2.2 50 0 300e
* i 3.3.3.3 50 0 200e
When Router D learns network 10.0.0.0 from Router C which has a smaller router ID than Router B, the
route from Router C becomes optimal, as shown below.
*>i 10.0.0.0 1.1.1.1 60 0 200e
* i 10.0.0.0 2.2.2.2 50 0 300e
* i 3.3.3.3 50 0 200e
However, Router C and Router B reside in the same AS, and therefore BGP will compare the MEDs of
them. Since Router C has a greater MED, network 10.0.0.0 learned from it is not optimal.
In this case, you can configure the bestroute compare-med command on Router D. After that, Router
D will put routes received from the same AS into a group. For the same group, the route with the lowest
MED is selected. Then, it compares routes from different groups. This mechanism avoids the
above-mentioned problem. The following output is the BGP routing table on Router D after the
comparison of MED of routes from each AS is enabled. Network 10.0.0.0 learned from Router C is the
optimal route.
*>i 10.0.0.0 3.3.3.3 50 0 200e
* i 10.0.0.0 2.2.2.2 50 0 300e
* i 1.1.1.1 60 0 200e
Note that, in this case, BGP load balancing cannot be implemented because load balanced routes must
have the same AS-path attribute.
Follow these steps to enable the comparison of MED of routes from each AS:

Enable the comparison of MED Optional

bestroute compare-med
of routes from each AS Not enabled by default
1-27
Enable the comparison of MED of routes from confederation peers
Follow these steps to enable the comparison of MED of routes from confederation peers:

Enable the comparison of MED Optional
of routes from confederation bestroute med-confederation
peers Not enabled by default
The MED attributes of routes from confederation peers are not compared if their AS-path attributes
contain AS numbers that don’t belong to the confederation. For example, there are three routes:
AS-path attributes of them are 65006 65009, 65007 65009 and 65008 65009, and MED values of them
are 2, 3, and 1. Because the third route contains an AS number that does not belong to the
confederation, the first route becomes the optimal route.
Configuring the Next Hop Attribute
By default, when advertising routes to an iBGP peer/peer group, a BGP router does not set itself as the
next hop. However, to ensure a BGP peer can find the correct next hop in some cases, you need to
configure the router as the next hop for routes sent to the peer.
For example, as shown in the figure below, Router A and Router B establish an eBGP neighbor
relationship, and Router B and Router C establish an iBGP neighbor relationship. When Router B
advertises a network learned from Router A to Router C, if Router C has no route to IP address
1.1.1.1/24, you need to configure Router B to set itself as the next hop (3.1.1.1/24) for the route to be
sent to Router C.
Figure 1-17 Next hop attribute configuration
If a BGP router has two peers on a common broadcast network, it does not set itself as the next hop for
routes sent to an eBGP peer by default. As shown below, Router A and Router B establish an eBGP
neighbor relationship, and Router B and Router C establish an iBGP neighbor relationship. They are on
the same broadcast network 1.1.1.0/24. When Router B sends eBGP routes to Router A, it does not set
itself as the next hop by default. However, you can configure Router B to set it as the nexthop
(1.1.1.2/24) for routes sent to Router A by using the peer next-hop-local command as needed.
1-28
Figure 1-18 Next hop attribute configuration
Note that: if you have configured BGP load balancing on a BGP router, the router will set it as the next
hop for routes sent to an iBGP peer/peer group regardless of whether the peer next-hop-local
command is configured.
Follow these steps to configure the next hop attribute:

Optional
By default, the router sets it as
Specify the router as the next the next hop for routes sent to
peer { group-name |
hop of routes sent to a an eBGP peer/peer group, but
ip-address } next-hop-local
peer/peer group does not set it as the next hop
for routes sent to an iBGP
peer/peer group.
Configuring the AS-PATH Attribute
Permit local AS number to appear in routes from a peer/peer group
In general, BGP checks whether the AS_PATH attribute of a route from a peer contains the local AS
number. If so, it discards the route to avoid routing loops.
This task allows you to permit local AS number to appear in routes from a peer/peer group and specify
the appearance times.

Permit local AS number to Optional
peer { group-name |
appear in routes from a
ip-address } allow-as-loop By default, the local AS number
peer/peer group and specify
[ number ] is not allowed.
the appearance times
Disable BGP from considering AS_PATH during best route selection
Follow these steps to disable BGP from considering AS_PATH during best route selection:
1-29
Optional
Disable BGP from considering
AS_PATH during best route bestroute as-path-neglect By default, BGP considers
selection AS_PATH during best route
selection.
Specify a fake AS number for a peer/peer group
When Router A in AS 2 is moved to AS 3, you can configure Router A to specify a fake AS number of 2
for created connections to eBGP peers/peer groups. In this way, these eBGP peers still think Router A is
in AS 2 and thus need not change their configurations. This feature ensures uninterrupted BGP
services.
Follow these steps to specify a fake AS number for a peer/peer group:

Specify a fake AS number for a peer { group-name | ip-address } Optional

peer/peer group fake-as as-number Not specified by default
This command is only applicable to an eBGP peer or peer group.
Configure AS number substitution
In MPLS L3VPN, if eBGP is used between PE and CE, sites in different geographical areas should have
different AS numbers assigned to ensure correct route advertisement. If different CEs use the same AS
number, you need to configure the corresponding PE to replace the AS number of the CE as its own AS
number. This feature is used for route advertisement only.
Figure 1-19 AS number substitution configuration
1-30
As shown in the above figure, CE 1 and CE 2 use the same AS number of 800. If AS number
substitution for CE 2 is configured on PE 2, when PE 2 receives a BGP update sent from CE 1, it
replaces AS number 800 as its own AS number 100. Similar configuration should also be made on PE
1.
Follow these steps to configure AS number substitution for a peer/peer group:

Replace the AS number of a
peer/peer group in the peer { group-name | Optional
AS_PATH attribute as the local ip-address } substitute-as Not configured by default.
AS number
Improper AS number substitution configuration may cause route loops; use this command with caution.
Remove private AS numbers from updates to a peer/peer group
Follow these steps to remove private AS numbers from updates to a peer/peer group:

Configure BGP to remove Optional
private AS numbers from the peer { group-name |
AS_PATH attribute of updates ip-address } public-as-only By default, BGP updates carry
to a peer/peer group private AS numbers.
Tuning and Optimizing BGP Networks

Prerequisites
Configuring BGP Keepalive Interval and Holdtime
After establishing a BGP connection, two routers send keepalive messages periodically to each other to
keep the connection. If a router receives no keepalive or update message from the peer within the
holdtime, it tears down the connection.
If two parties have the same timer assigned with different values, the smaller one is used by the two
parties.
Follow these steps to configure BGP keepalive interval and holdtime:
1-31
Configure the global keepalive timer keepalive keepalive
interval and holdtime hold holdtime Optional
By default, the keepalive
Configure the keepalive interval peer { group-name | interval is 60 seconds, and
and holdtime for a peer/peer ip-address } timer keepalive holdtime is 180 seconds.
group keepalive hold holdtime
z The maximum keepalive interval should be one third of the holdtime and no less than 1 second.
The holdtime is no less than 3 seconds unless it is set to 0.
z The intervals set with the peer timer command are preferred to those set with the timer command.
z If the router has established a neighbor relationship with a peer, you need to reset the BGP
connection to validate the new set timers.
Configuring the Interval for Sending the Same Update
Follow these steps to configure the interval for sending the same update to a peer/peer group:

Optional
peer { group-name |
Configure the interval for The intervals for sending the same
ip-address }
sending the same update to a update to an iBGP peer and an
route-update-interval
peer/peer group eBGP peer default to 15 seconds
interval
and 30 seconds respectively.
Configuring BGP Soft-Reset
After modifying a route selection policy, you have to reset BGP connections to make the new one take
effect, causing short time disconnection.
The current BGP implementation supports the route-refresh capability, with which, a router can
dynamically refresh its BGP routing table when the route selection policy is modified, without tearing
down BGP connections. If a BGP peer does not support route-refresh, you need to save updates from
the peer on the local router. After that, when a route selection policy is modified, the router can refresh
its BGP routing table by using such updates without tearing down BGP connections.
Configure automatic soft-reset
After route refresh is enabled for peers and then a policy is modified, the router advertises a
route-refresh message to the peers, which then resend their routing information to the router. In this way,
1-32
the router can perform dynamic route update and apply the new policy without tearing down BGP
connections.
Follow these steps to enable BGP route refresh for a peer/peer group:

Enable BGP route refresh for a peer { group-name | ip-address } Optional

peer/peer group capability-advertise route-refresh Enabled by default
Configure manual soft-reset
If a BGP peer does not support route-refresh, you need to save updates from the peer on the local
router by using the peer keep-all-routes command. When a route selection policy is modified, you can
use the refresh bgp command to refresh the BGP routing table by applying the new policy.
Following these steps to save all route updates from a peer/peer group:


Disable BGP route-refresh and Optional
multi-protocol extension
capability-advertise conventional Enabled by default
capability for a peer/peer group
Save all routes from a peer { group-name | ip-address } Optional

peer/peer group keep-all-routes Not saved by default
Return to user view return —
refresh bgp { all | ip-address | group

Perform manual soft reset on
group-name | external | internal } Required
BGP connections
{ export | import }
Enabling Quick eBGP Session Reestablishment
If the router receives no keepalive messages from a BGP peer within the holdtime, it tears down the
connection to the peer.
With quick eBGP connection reestablishment enabled, the router, when the link to a directly connected
eBGP peer is down, will reestablish a session to the eBGP peer immediately.
Follow these steps to enable quick eBGP session reestablishment:

Enable quick eBGP session Optional

ebgp-interface-sensitive
reestablishment Not enabled by default
1-33
Enabling MD5 Authentication for TCP Connections
BGP employs TCP as the transport protocol. To enhance security, you can configure BGP to perform
MD5 authentication when establishing a TCP connection. The two parties must have the same
password configured to establish TCP connections. BGP MD5 authentication is not for BGP packets,
but for TCP connections. If the authentication fails, no TCP connection can be established.
Follow these steps to enable MD5 authentication for TCP connections:

Enable MD5 authentication when peer { group-name | ip-address } Optional
establishing a TCP connection to password { cipher | simple }
the peer/peer group password Not enabled by default
Configuring BGP Load Balancing
If multiple paths to a destination exist, you can configure load balancing over such paths to improve link
utilization.
Follow these steps to configure BGP load balancing:


number of BGP routes for load balance number Load balancing is not enabled
balancing by default.
Forbiding Session Establishment with a Peer or Peer Group
Follow these steps to forbid session establishment with a peer or peer group:

Forbid session establishment peer { group-name | Optional

with a peer or peer group ip-address } ignore Not forbidden by default
Configuring a Large Scale BGP Network

In a large-scale BGP network, configuration and maintenance become difficult due to large numbers of
BGP peers. To facilitate configuraiton in this case, you can configure peer group, community, route
reflector or confederation as needed.
1-34
Peering nodes are accessible to each other at the network layer.
Configuring BGP Peer Groups
A peer group is a group of peers with the same route selection policy.
In a large scale network, many peers may use the same route selection policy. You can configure a peer
group and add these peers into this group. In this way, peers can share the same policy as the peer
group. When the policy of the group is modified, the modification also applies to peers in it, thus
simplifying configuration.
A peer group is an iBGP peer group if peers in it belong to the same AS, and is an eBGP peer group if
peers in it belong to different ASs.
Note that:
If a peer group has peers added, you cannot remove its AS number using the undo form of the
command or change its AS number.
Configure an iBGP peer group
After you create an iBGP peer group and then add a peer into it, the system creates the peer in BGP
view and specifies the local AS number for the peer.
Follow these steps to configure an iBGP peer group:

Create an iBGP peer group group group-name [ internal ] Required

Add a peer into the iBGP peer group peer ip-address group group-name Required
Configure an eBGP peer group
If peers in an eBGP group belong to the same external AS, the eBGP peer group is a pure eBGP peer
group; if not, it is a mixed eBGP peer group.
There are two approaches for configuring an eBGP peer group:
z Create the eBGP peer group, specify its AS number, and add peers into it.
z Create the eBGP peer group, and add a created peer into it or add a peer with the AS number
specified
Follow these steps to configure an eBGP peer group using the first approach:

Create an eBGP peer group group group-name external Required
1-35
Specify the AS number for the

peer group-name as-number as-number Required
group
Add a peer into the group peer ip-address group group-name Required
Follow these steps to configure an eBGP peer group using the second approach:

Create an eBGP peer group group group-name external Required

peer ip-address group group-name
Add a peer into the group Required
[ as-number as-number ]
Configuring BGP community can also help simplify routing policy management, and a community has a
much larger management scope than a peer group by controlling routing policies of multiple BGP
routers.
To guarantee the connectivity between iBGP peers, you need to make them fully meshed. But it
becomes unpractical when there are large numbers of iBGP peers. Configuring route reflectors or
confederation can solve it. In a large-scale AS, both of them can be used.
Configuring BGP Community
A BGP community is a group of destinations with the same characteristics. It has no geographical
boundaries and is independent of ASs.
You can configure a route policy to define which destinations belong to a BGP community and then
advertise the community attribute to a peer/peer group.
You can apply a route policy to filter routes advertised to/received from a peer/peer group according to
the community attribute. This way helps simplify policy configuration and management.
Fow how to configure a route policy, refer to Route Policy Configuration in the IP Routing Volume.
Follow these steps to configure BGP community:

Advertise the
community attribute to
Advertise the advertise-community
a peer/peer group Required
community
attribute to a Advertise the Not configured
peer/peer group extended community peer { group-name | ip-address } by default.
attribute to a peer/peer advertise-ext-community
group
1-36
peer { group-name | ip-address } Required

Apply a routing policy to routes advertised
route-policy route-policy-name Not configured
to a peer/peer group
export by default.
Configuring a BGP Route Reflector
If an AS has many BGP routers, you can configure them as a cluster and configure one of them as a
route reflector and others as clients to reduce iBGP connections.
To enhance network reliability and prevent single point failures, you can specify multiple route reflectors
for a cluster. The route reflectors in the cluster must have the same cluster ID specified to avoid routing
loops.
Follow these steps to configure a BGP route reflector:

Configure the router as a route Required

peer { group-name |
reflector and specify a
ip-address } reflect-client Not configured by default.
peer/peer group as its client
Enable route reflection Optional

reflect between-clients
between clients Enabled by default
Optional
Configure the cluster ID of the reflector cluster-id
route reflector cluster-id By default, a route reflector uses
its router ID as the cluster ID.
z In general, it is not required to make clients of a route reflector fully meshed. The route reflector
forwards routing information between clients. If clients are fully meshed, you can disable route
reflection between clients to reduce routing costs.
z In general, a cluster has only one route reflector, and the router ID is used to identify the cluster.
You can configure multiple route reflectors to improve network stability. In this case, you need to
specify the same cluster ID for these route reflectors using the reflector cluster-id command to
avoid routing loops.
Configuring a BGP Confederation
Configuring a BGP confederation is another way for reducing iBGP connections in an AS.
A confederation contains sub ASs. In each sub AS, iBGP peers are fully meshed. Between sub ASs,
eBGP connections are established.
If routers not compliant with RFC 3065 exist in the confederation, you can use the confederation
nonstandard command to make the local router compatible with these routers.
1-37
Configure a BGP confederation
After you split an AS into multiple sub ASs, you can configure a router in a sub AS in the following way:
1) Enable BGP and specify the AS number of the router.
2) Specify the confederation ID. From an outsider’s perspective, the sub ASs of the confederation is a
single AS, which is identified by the confederation ID.
3) If the router needs to establish eBGP connections to other sub ASs, you need to specify the
peering sub ASs in the confederation.
A confederation contains 32 sub ASs at most. The AS number of a sub AS is effective only in the
confederation.
Follow these steps to configure a BGP confederation:

Required
Configure a confederation ID confederation id as-number
Specify peering sub ASs in the confederation peer-as Required

confederation as-number-list Not configured by default.
Configure confederation compatibility
If some other routers in the confederation do not comply with RFC 3065, you need to enable
confederation compatibility to allow the router to work with those routers.

Enable compatibility with Optional

routers not compliant with RFC confederation nonstandard
3065 in the confederation Not enabled by default
Configuring BGP GR
Perform the following configuration on the GR Restarter and GR Helper respectively.
A device can act as a GR Restarter and GR Helper at the same time.
Follow these steps to configure BGP GR:
1-38
Enable BGP, and enter its view bgp as-number —
Required
Enable GR Capability for BGP graceful-restart
Disabled by default
Configure the maximum time allowed for graceful-restart timer Optional

the peer to reestablish a BGP session restart timer 150 seconds by default
Configure the maximum time to wait for graceful-restart timer Optional

the End-of-RIB marker wait-for-rib timer 180 seconds by default
z In general, the maximum time allowed for the peer (the GR restarter) to reestablish a BGP session
should be less than the Holdtime carried in the OPEN message.
z The End-Of-RIB (End of Routing-Information-Base) indicates the end of route updates.
Enabling Trap
After Trap is enabled for BGP, BGP generates Level-4 traps to report important events of it. The
generated traps are sent to the Information Center of the device. The output rules of the traps, namely,
whether to output the traps and the output direction, are determined according to the Information Center
configuration. (For Information Center configuration, refer to "Information Center Configuration" in the
System Volume.)
Follow these steps to enable Trap:

Optional
Enable Trap for BGP snmp-agent trap enable bgp
Enabled by default
Enabling Logging of Peer State Changes

Follow these steps to enable the logging of peer state changes:

1-39
Optional
Enable the globally log-peer-change
logging of Enabled by default
peer state Optional
changes for a peer or peer { group-name | ip-address }
peer group log-change Enabled by default
Displaying and Maintaining BGP

Displaying BGP

Display peer group information display bgp group [ group-name ] Available
in any
Display advertised BGP routing view
display bgp network
information
Display AS path information display bgp paths [ as-regular-expression ]
Display BGP peer/peer group display bgp peer [ ip-address { log-info | verbose }
information | group-name log-info | verbose ]
display bgp routing-table [ ip-address [ { mask |
Display BGP routing information
mask-length } [ longer-prefixes ] ] ]
Display routing information display bgp routing-table as-path-acl
matching the AS path ACL as-path-acl-number
Display BGP CIDR routing
display bgp routing-table cidr
information
Display BGP routing information display bgp routing-table community
matching the specified BGP [ aa:nn&<1-13> ] [ no-advertise | no-export |
community no-export-subconfed ] * [ whole-match ]
display bgp routing-table community-list

Display routing information
{ basic-community-list-number [ whole-match ] |
matching a BGP community list
adv-community-list-number }&<1-16>
Display BGP dampened routing
display bgp routing-table dampened
information
Display BGP dampening
display bgp routing-table dampening parameter
parameter information
Display BGP routing information
display bgp routing-table different-origin-as
originating from different ASs
display bgp routing-table flap-info

Display BGP routing flap [ regular-expression as-regular-expression |
statistics as-path-acl as-path-acl-number | ip-address
[ { mask | mask-length } [ longer-match ] ] ]
Display labeled BGP routing
display bgp routing-table label
information
display bgp routing-table peer ip-address

Display routing information to or
{ advertised-routes | received-routes }
from a peer
[ network-address [ mask | mask-length ] | statistic ]
Display routing information display bgp routing-table regular-expression
matching a regular expression as-regular-expression
1-40
Display BGP routing statistics display bgp routing-table statistic
Resetting BGP Connections

Reset all BGP connections reset bgp all
Reset the BGP connections to an AS reset bgp as-number
Reset the BGP connection to a peer reset bgp ip-address [ flap-info ]
Available in
Reset all eBGP connections reset bgp external
user view
Reset the BGP connections to a peer group reset bgp group group-name
Reset all iBGP connections reset bgp internal
Reset all IPv4 unicast BGP connections reset bgp ipv4 all
Clearing BGP Information

Clear dampened MBGP routing
reset bgp dampening [ ip-address [ mask |
information and release
mask-length ] ]
suppressed routes
Available in
reset bgp flap-info [ regexp user view
as-path-regular-expression | as-path-acl
Clear route flap information
as-path-acl-number | ip-address [ mask |
mask-length ] ]
BGP Configuration Examples

BGP Basic Configuration
In the following figure are all BGP switches. Between Switch A and Switch B is an eBGP connection.
iBGP speakers Switch B, Switch C and Switch D are fully meshed.
1-41
Network diagram
Figure 1-20 Network diagram for BGP basic configuration
AS 65008 AS 65009
Vlan-int300 Vlan-int500
9.1.3.2/24 9.1.2.1/24
Switch C
Vlan-int100
8.1.1.1/8 Vlan-int300 Vlan-int500
9.1.3.1/24 9.1.2.2/24
Vlan-int200 Vlan-int200 Vlan-int400 Vlan-int400

200.1.1.2/24 200.1.1.1/24 9.1.1.1/24 9.1.1.2/24
Switch A Switch B Switch D

2) Configure iBGP connections
[SwitchB] bgp 65009
[SwitchB-bgp] router-id 2.2.2.2
[SwitchB-bgp] peer 9.1.1.2 as-number 65009
[SwitchB-bgp] quit
[SwitchC] bgp 65009
[SwitchC-bgp] router-id 3.3.3.3
[SwitchC-bgp] peer 9.1.3.1 as-number 65009
[SwitchC-bgp] quit
[SwitchD] bgp 65009
[SwitchD-bgp] router-id 4.4.4.4
[SwitchD-bgp] peer 9.1.1.1 as-number 65009
[SwitchD-bgp] quit
3) Configure the eBGP connection
[SwitchA] bgp 65008
[SwitchA-bgp] router-id 1.1.1.1
[SwitchA-bgp] peer 200.1.1.1 as-number 65009
# Inject network 8.0.0.0/8 to the BGP routing table.

[SwitchA-bgp] network 8.0.0.0
1-42
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp] quit
# Display BGP peer information on Switch B.

[SwitchB] display bgp peer
BGP local router ID : 2.2.2.2

Local AS number : 65009
Total number of peers : 3 Peers in established state : 3
Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
9.1.1.2 4 65009 56 56 0 0 00:40:54 Established

9.1.3.2 4 65009 49 62 0 0 00:44:58 Established
200.1.1.2 4 65008 49 65 0 1 00:44:03 Established
You can find Switch B has established BGP connections to other switches.
# Display BGP routing table information on Switch A.
[SwitchA] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
*> 8.0.0.0 0.0.0.0 0 0 i
# Display BGP routing table information on Switch B.

[SwitchB] display bgp routing-table

*> 8.0.0.0 200.1.1.2 0 0 65008i
# Display the BGP routing table on Switch C.

[SwitchC] display bgp routing-table
1-43

i 8.0.0.0 200.1.1.2 0 100 0 65008i
From the above outputs, you can find Switch A has learned no route to AS65009, and Switch C has
learned network 8.0.0.0 but the next hop 200.1.1.2 is unreachable, so the route is invalid.
4) Redistribute direct routes

[SwitchB] bgp 65009
[SwitchB-bgp] import-route direct


*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009?
*> 9.1.1.2/32 200.1.1.1 0 0 65009?
*> 9.1.3.0/24 200.1.1.1 0 0 65009?
*> 9.1.3.2/32 200.1.1.1 0 0 65009?
* 200.1.1.0 200.1.1.1 0 0 65009?
* 200.1.1.2/32 200.1.1.1 0 0 65009?
# Display BGP routing table information on Switch C.


1-44
*>i 8.0.0.0 200.1.1.2 0 100 0 65008i

*>i 9.1.1.0/24 9.1.3.1 0 100 0 ?
*>i 9.1.1.2/32 9.1.3.1 0 100 0 ?
* i 9.1.3.0/24 9.1.3.1 0 100 0 ?
* i 9.1.3.2/32 9.1.3.1 0 100 0 ?
*>i 200.1.1.0 9.1.3.1 0 100 0 ?
*>i 200.1.1.2/32 9.1.3.1 0 100 0 ?
You can find the route 8.0.0.0 becomes valid with the next hop being Switch A.
# Ping 8.1.1.1 on Switch C.
[SwitchC] ping 8.1.1.1

0.00% packet loss
BGP and IGP Synchronization Configuration
As shown below, OSPF is used as the IGP protocol in AS65009, where Switch C is a non-BGP switch.
Between Switch A and Switch B is an eBGP connection.
Network diagram
Figure 1-21 Network diagram for BGP and IGP synchronization
1-45

2) Configure OSPF (omitted)
3) Configure the eBGP connection
[SwitchA] bgp 65008

[SwitchA-bgp] network 8.1.1.0 24
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp] quit
4) Configure BGP and IGP synchronization
# Configure BGP to redistribute routes from OSPF on Switch B.
[SwitchB] bgp 65009
[SwitchB-bgp] import-route ospf 1
[SwitchB-bgp] quit
# Display routing table information on Switch A.


*> 8.1.1.0/24 0.0.0.0 0 0 i

*> 9.1.1.0/24 3.1.1.1 0 0 65009?
# Configure OSPF to redistribute routes from BGP on Switch B.

[SwitchB] ospf
[SwitchB-ospf-1] import-route bgp
# Display routing table information on Switch C.

<SwitchC> display ip routing-table
1-46
8.1.1.0/24 O_ASE 150 1 9.1.1.1 Vlan300

9.1.1.0/24 Direct 0 0 9.1.1.2 Vlan300
9.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
9.1.2.0/24 Direct 0 0 9.1.2.1 Vlan400
9.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
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
5) Configure route automatic summarization
# Configure route automatic summarization on Switch B.
[SwitchB] bgp 65009
[SwitchB-bgp] summary automatic


*> 8.1.1.0/24 0.0.0.0 0 0 i

*> 9.0.0.0 3.1.1.1 0 0 65009?
# Use ping for verification.

[SwitchA] ping -a 8.1.1.1 9.1.2.1

0.00% packet loss
1-47
BGP Load Balancing Configuration
All the switches run BGP. Switch A resides in AS 65008, Switch B and Switch C in AS 65009. Between
Switch A and Switch B, Switch A and Switch C are eBGP connections, and between Switch B and
Switch C is an iBGP connection. Two routes are configured on Switch A for load balancing.
Network diagram
Figure 1-22 Network diagram for BGP load balancing configuration
Switch B AS 65009
AS 65008 Vlan-int200
200.1.1.1/24
Vlan-int100 Vlan-int200 Vlan-int400
8.1.1.1/8 200.1.1.2/24 EBGP 9.1.1.1/24
IBGP
Vlan-int400
Vlan-int300 EBGP
9.1.1.2/24
200.1.2.2/24
Switch A Vlan-int300
200.1.2.1/24
Switch C

2) Configure BGP connections
[SwitchA] bgp 65008
# Inject route 8.0.0.0/8 to BGP routing table.

[SwitchA-bgp] network 8.0.0.0 255.0.0.0
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp] network 9.1.1.0 255.255.255.0
[SwitchB-bgp] quit
[SwitchC] bgp 65009
1-48
[SwitchC-bgp] network 9.1.1.0 255.255.255.0
[SwitchC-bgp] quit
# Display the routing table on Switch A.


*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009i
* 200.1.2.1 0 0 65009i
From the above output information, you can find two valid routes to destination 9.1.1.0/24 are available:
the route with next hop 200.1.1.1 is marked with a greater-than sign (>), indicating it is the best route
(because the ID of Switch B is smaller); the route with next hop 200.1.2.1 is marked with only an
asterisk (*), indicating it is a valid route, but not the best.
3) Configure loading balancing
[SwitchA] bgp 65008
[SwitchA-bgp] balance 2
[SwitchA-bgp] quit
# Display the routing table on Switch A.


*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009i
*> 200.1.2.1 0 0 65009i
The route 9.1.1.0/24 has two next hops 200.1.1.1 and 200.1.2.1, both of which are marked with a
greater-than sign (>), indicating they are the best routes..
1-49
BGP Community Configuration
Switch B establishes eBGP connections with Switch A and C. Configure No_Export community attribute
on Switch A to make routes from AS 10 not advertised by AS 20 to any other AS.
Network diagram
Figure 1-23 Network diagram for BGP community configuration

2) Configure eBGP
[SwitchA] bgp 10
[SwitchA-bgp] network 9.1.1.0 255.255.255.0
[SwitchA-bgp] quit
[SwitchB] bgp 20
[SwitchB-bgp] quit
[SwitchC] bgp 30
[SwitchC-bgp] quit
1-50
# Display the BGP routing table on Switch B.
[SwitchB] display bgp routing-table 9.1.1.0

Paths: 1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:

From : 200.1.2.1 (1.1.1.1)
Original nexthop: 200.1.2.1
AS-path : 10
Origin : igp
Attribute value : MED 0, pref-val 0, pre 255
State : valid, external, best,
Advertised to such 1 peers:
200.1.3.2
Switch B advertised routes to Switch C in AS 30.

# Display the routing table on Switch C.

*> 9.1.1.0/24 200.1.3.1 0 0 20 10i
Switch C learned route 9.1.1.0/24 from Switch B.

3) Configure BGP community
# Configure a routing policy.
[SwitchA] route-policy comm_policy permit node 0
[SwitchA-route-policy] apply community no-export
[SwitchA-route-policy] quit
# Apply the routing policy.

[SwitchA] bgp 10
[SwitchA-bgp] peer 200.1.2.2 route-policy comm_policy export
[SwitchA-bgp] peer 200.1.2.2 advertise-community
# Display the routing table on Switch B.

1-51
From : 200.1.2.1 (1.1.1.1)
Community : No-Export
AS-path : 10
Origin : igp
Attribute value : MED 0, pref-val 0, pre 255
State : valid, external, best,
Not advertised to any peers yet
The output information shows that:

z Switch F can send route information to Switch B and Switch C through the confederation by
establishing only an eBGP connection with Switch A.
z Switch B and Switch D are in the same confederation, but belong to different sub ASs. They obtain
external route information from Switch A and generate the same BGP route entries; it seems like
that they reside in the same AS although they have no direct connection in between.
BGP Route Reflector Configuration
In the following figure, all switches run BGP.

z Between Switch A and Switch B is an eBGP connection, between Switch C and Switch B, and
between Switch C and Switch D are iBGP connections.
z Switch C is a route reflector with clients Switch B and D.
z Switch D can learn route 1.0.0.0/8 from Switch C.
Network diagram
Figure 1-24 Network diagram for BGP route reflector configuration

[SwitchA] bgp 100
1-52
[SwitchA-bgp] network 1.0.0.0
[SwitchA-bgp] quit
[SwitchB] bgp 200
[SwitchB-bgp] peer 193.1.1.1 next-hop-local
[SwitchB-bgp] quit
[SwitchC] bgp 200
[SwitchC-bgp] quit
[SwitchD] bgp 200
[SwitchD-bgp] quit
3) Configure the route reflector
[SwitchC] bgp 200
[SwitchC-bgp] peer 193.1.1.2 reflect-client
[SwitchC-bgp] peer 194.1.1.2 reflect-client
[SwitchC-bgp] quit
4) Verify the above configuration
# Display the BGP routing table on Switch B.

*> 1.0.0.0 192.1.1.1 0 0 100i
1-53
# Display the BGP routing table on Switch D.
[SwitchD] display bgp routing-table

i 1.0.0.0 193.1.1.2 0 100 0 100i
Switch D learned route 1.0.0.0/8 from Switch C.
BGP Confederation Configuration
To reduce iBGP connections in AS 200, split it into three sub-ASs, AS65001, AS65002 and AS65003.
Switches in AS65001 are fully meshed.
Network diagram
Figure 1-25 Network diagram for BGP confederation configuration
Switch F Switch B Switch C
Vlan-int200 AS 65002 AS 65003
Vlan-int100
00
t3
Switch D
-in
AS 100
an
Vl
Vlan-int400
Switch A
AS 65001
Switch E
AS 200
Device Interface IP address Device Interface IP address

Switch A Vlan-int100 200.1.1.1/24 Switch D Vlan-int200 10.1.5.1/24
Vlan-int200 10.1.1.1/24 Vlan-int400 10.1.3.2/24
Vlan-int300 10.1.2.1/24 Switch E Vlan-int200 10.1.5.2/24
Vlan-int400 10.1.3.1/24 Vlan-int500 10.1.4.2/24
Vlan-int500 10.1.4.1/24 Switch F Vlan-int100 200.1.1.2/24
Switch B Vlan-int200 10.1.1.2/24 Vlan-int600 9.1.1.1/24
Switch C Vlan-int300 10.1.2.2/24

2) Configure BGP confederation
1-54
[SwitchA] bgp 65001
[SwitchA-bgp] confederation id 200
[SwitchA-bgp] confederation peer-as 65002 65003
[SwitchA-bgp] peer 10.1.1.2 next-hop-local
[SwitchA-bgp] quit
[SwitchB] bgp 65002
[SwitchB-bgp] confederation id 200
[SwitchB-bgp] confederation peer-as 65001 65003
[SwitchB-bgp] quit
[SwitchC] bgp 65003
[SwitchC-bgp] confederation id 200
[SwitchC-bgp] confederation peer-as 65001 65002
[SwitchC-bgp] quit
3) Configure iBGP connections in AS65001.
[SwitchA] bgp 65001
[SwitchA-bgp] quit
[SwitchD] bgp 65001
[SwitchD-bgp] confederation id 200
[SwitchD-bgp] quit
# Configure Switch E.
<SwitchE> system-view
[SwitchE] bgp 65001
1-55
[SwitchE-bgp] router-id 5.5.5.5
[SwitchE-bgp] confederation id 200
[SwitchE-bgp] peer 10.1.4.1 as-number 65001
[SwitchE-bgp] peer 10.1.5.1 as-number 65001
[SwitchE-bgp] quit
4) Configure the eBGP connection between AS100 and AS200.
[SwitchA] bgp 65001
[SwitchA-bgp] quit
# Configure Switch F.
<SwitchF> system-view
[SwitchF] bgp 100
[SwitchF-bgp] router-id 6.6.6.6
[SwitchF-bgp] peer 200.1.1.1 as-number 200
[SwitchF-bgp] network 9.1.1.0 255.255.255.0
[SwitchF-bgp] quit
5) Verify above configuration
# Display the routing table on Switch B.

*>i 9.1.1.0/24 10.1.1.1 0 100 0 (65001) 100i



From : 10.1.1.1 (1.1.1.1)
Relay Nexthop : 0.0.0.0
AS-path : (65001) 100
Origin : igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State : valid, external-confed, best,
1-56

*>i 9.1.1.0/24 10.1.3.1 0 100 0 100i

[SwitchD] display bgp routing-table 9.1.1.0


From : 10.1.3.1 (1.1.1.1)
Relay Nexthop : 0.0.0.0
AS-path : 100
Origin : igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State : valid, internal, best,
BGP Path Selection Configuration
z In the figure below, all switches run BGP. Between Switch A and Switch B, and between Switch A
and Switch C are eBGP connections. Between Switch B and Switch D, and between Switch D and
Switch C are iBGP connections.
z OSPF is the IGP protocol in AS 200.
z Configure routing policies, making Switch D use the route 1.0.0.0/8 from Switch C as the optimal.
1-57
Network diagram
Figure 1-26 Network diagram for BGP path selection configuration
Device Interface IP address Device Interface IP address

Switch A Vlan-int101 1.0.0.0/8 Switch D Vlan-int400 195.1.1.1/24
Vlan-int100 192.1.1.1/24 Vlan-int300 194.1.1.1/24
Vlan-int200 193.1.1.1/24 Switch C Vlan-int400 195.1.1.2/24
Switch B Vlan-int100 192.1.1.2/24 Vlan-int200 193.1.1.2/24
Vlan-int300 194.1.1.2/24

2) Configure OSPF on Switch B, C, and D.
[SwitchB] ospf
[SwitchB-ospf] area 0
[SwitchC] ospf
[SwitchC-ospf] area 0
[SwitchD] ospf
[SwitchD-ospf] area 0
1-58
[SwitchA] bgp 100
# Inject network 1.0.0.0/8 to the BGP routing table on Switch A.

[SwitchA-bgp] network 1.0.0.0 8
[SwitchA-bgp] quit
[SwitchB] bgp 200
[SwitchB-bgp] quit
[SwitchC] bgp 200
[SwitchC-bgp] quit
[SwitchD] bgp 200
[SwitchD-bgp] quit
4) Configure attributes for route 1.0.0.0/8, making Switch D give priority to the route learned from
Switch C.
z Configure a higher MED value for the route 1.0.0.0/8 advertised from Switch A to peer 192.1.1.2.
# Define an ACL numbered 2000 to permit route 1.0.0.0/8.
[SwitchA] acl number 2000
[SwitchA-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[SwitchA-acl-basic-2000] quit
# Define two routing policies, apply_med_50, which sets the MED for route 1.0.0.0/8 to 50, and
apply_med_100, which sets the MED for route 1.0.0.0/8 to 100.
[SwitchA] route-policy apply_med_50 permit node 10
[SwitchA-route-policy] if-match acl 2000
[SwitchA-route-policy] apply cost 50
[SwitchA] route-policy apply_med_100 permit node 10
[SwitchA-route-policy] if-match acl 2000
[SwitchA-route-policy] apply cost 100
# Apply routing policy apply_med_50 to the route advertised to peer 193.1.1.2 (Switch C), and
apply_med_100 to the route advertised to peer 192.1.1.2 (Switch B).
[SwitchA] bgp 100
1-59
[SwitchA-bgp] peer 193.1.1.2 route-policy apply_med_50 export
[SwitchA-bgp] peer 192.1.1.2 route-policy apply_med_100 export
[SwitchA-bgp] quit


*>i 1.0.0.0 193.1.1.1 50 100 0 100i

* i 192.1.1.1 100 100 0 100i
You can find route 1.0.0.0/8 is the optimal.

z Configure different local preferences on Switch B and C for route 1.0.0.0/8, making Switch D give
priority to the route from Switch C.
# Define an ACL numbered 2000 on Router C, permitting route 1.0.0.0/8.
[SwitchC] acl number 2000
[SwitchC-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[SwitchC-acl-basic-2000] quit
# Configure a routing policy named localpref on Switch C, setting the local preference of route 1.0.0.0/8
to 200 (the default is 100).
[SwitchC] route-policy localpref permit node 10
[SwitchC-route-policy] if-match acl 2000
[SwitchC-route-policy] apply local-preference 200
[SwitchC-route-policy] quit
# Apply routing policy localpref to routes from peer 193.1.1.1.

[SwitchC] bgp 200
[SwitchC-bgp] peer 193.1.1.1 route-policy localpref import
[SwitchC-bgp] quit
# Display the routing table on Switch D.


*>i 1.0.0.0 193.1.1.1 0 200 0 100i
1-60
* i 192.1.1.1 0 100 0 100i
You can find route 1.0.0.0/8 from Switch D to Switch C is the optimal.
Troubleshooting BGP
No BGP Peer Relationship Established
Symptom
Display BGP peer information using the display bgp peer command. The state of the connection to a
peer cannot become established.
Analysis
To become BGP peers, any two routers need to establish a TCP session using port 179 and exchange
open messages successfully.
Solution
1) Use the display current-configuration command to verify the peer’s AS number.

2) Use the display bgp peer command to verify the peer’s IP address.
3) If the loopback interface is used, check whether the peer connect-interface command is
configured.
4) If the peer is a non-direct eBGP peer, check whether the peer ebgp-max-hop command is
configured.
5) Check whether a route to the peer is available in the routing table.
6) Use the ping command to check connectivity.
7) Use the display tcp status command to check the TCP connection.
8) Check whether an ACL disabling TCP port 179 is configured.
1-61
To learn more about HP networking, visit
www.hp.com/networking
© 2011 Hewlett-Packard Development Company, L.P. The information contained herein is
subject to change without notice. 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.

Implementing HP A-Series Networks Book 1

Uploaded by

Copyright:

Available Formats

Implementing HP A-Series Networks Book 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing HP A-Series Networks Book 1

Uploaded by

Copyright:

Available Formats

Implementing HP A-Series Networks

Rev. 11.21 - Course #: 00324573

Rev. 11.21 - Course #: 00324573

Module 1: VLANs and IP Gateway Features

Module 2: WAN Links

Welcome to Implementing HP A-Series Networks

Rev. 11.21 Introduction – 1

Topic Product Volume

Table 1.0.1: References by Topic

Activity 1.1: VLAN Types

Figure 1.1: Ingress Port and VLAN ID

A-Series VLAN Types

PVID (Port VLAN ID)

Learner Activity: Look-up and discuss

Question 1: Port-based VLANs / Port link-types

Access Trunk Hybrid

Question 2: Port-based VLANs / Port link-types

Table 1.1.2: Access Link-type Frame Processing

Table 1.1.3: Trunk Link-type Frame Processing

Table 1.1.4: Hybrid Link-type Frame Processing

Question 3: Hybrid Port Link-type usage

Figure 1.2: Two-tier LAN

Question 4: VLAN Types

Table 1.1.5: Frame fields and VLAN Types

Configuring VLAN Types in A-Series Switches

VLAN Match Precedence

1 –10 Rev. 11.21

Activity 1.2: Special VLANs and Local Proxy ARP

Isolate-user-VLAN and SuperVLAN

Rev. 11.21 1 –11

Learner Activity: Look-up and discuss

Question 1: Isolate-user-VLAN and SuperVLAN (2)

Table 1.2.1: Special VLAN and OSI Layer

Figure 2.1: Diagram 1 Figure 2.2: Diagram 2

1 –12 Rev. 11.21

Question 2: Local-Proxy ARP

2. Describe how Local-proxy ARP can re-establish that communication.

Rev. 11.21 1 –13

Configuring A-Series Switches

1 –14 Rev. 11.21

Activity 1.3: Configuring MSTP and VRRP

 Multiple Spanning Trees per Region - Called “STP

 Each instance has a different root

 VLANs mapped to Instances

 Provides IP Gateway redundancy

Rev. 11.21 1 –15

Learner Activity: Group Analysis

Figure 1.3.1: Two tier redundant LAN

VLAN % of Total Traffic

Table 1.3.1: Traffic Load Distribution

 The CIST (Instance 0 is reserved for the management VLAN)

1 –16 Rev. 11.21

2. How should VLANs be mapped to spanning instances for optimal load

Table 1.3.2: VLAN to Instance Mapping

Table 1.3.3: Instance Root Bridge Mapping

4. How many Virtual Routers should be created?

Table 1.3.4: VRRP Master and Backup Router Mapping

Rev. 11.21 1 –17

Configuring the MSTP/VRRP solution in A-Series Switches

Multiple Spanning Trees per Region - Called “STP

Each instance has a different root

VLANs mapped to Instances

Provides IP Gateway redundancy

The CIST (Instance 0 is reserved for the management VLAN)