20080928-3com MSR Series Routers Operation Manual-6W100 PDF

3Com MSR Series Routers
Operation Manual
Manual Version: 6W100

www.3com.com
3Com Corporation
350 Campus Drive, Marlborough,
MA, USA 01752 3064
Copyright 2008, 3Com Corporation. All rights reserved. No part of this documentation may be reproduced in
any form or by any means or used to make any derivative work (such as translation, transformation, or
adaptation) without written permission from 3Com Corporation.
3Com Corporation reserves the right to revise this documentation and to make changes in content from time to
time without obligation on the part of 3Com Corporation to provide notification of such revision or change.
3Com Corporation provides this documentation without warranty, term, or condition of any kind, either implied
or expressed, including, but not limited to, the implied warranties, terms or conditions of merchantability,
satisfactory quality, and fitness for a particular purpose. 3Com may make improvements or changes in the
product(s) and/or the program(s) described in this documentation at any time.
If there is any software on removable media described in this documentation, it is furnished under a license
agreement included with the product as a separate document, in the hard copy documentation, or on the
removable media in a directory file named LICENSE.TXT or !LICENSE.TXT. If you are unable to locate a copy,
please contact 3Com and a copy will be provided to you.
UNITED STATES GOVERNMENT LEGEND

If you are a United States government agency, then this documentation and the software described herein are
provided to you subject to the following:
All technical data and computer software are commercial in nature and developed solely at private expense.
Software is delivered as Commercial Computer Software as defined in DFARS 252.227-7014 (June 1995) or
as a commercial item as defined in FAR 2.101(a) and as such is provided with only such rights as are
provided in 3Coms standard commercial license for the Software. Technical data is provided with limited rights
only as provided in DFAR 252.227-7015 (Nov 1995) or FAR 52.227-14 (June 1987), whichever is applicable.
You agree not to remove or deface any portion of any legend provided on any licensed program or
documentation contained in, or delivered to you in conjunction with, this User Guide.
Unless otherwise indicated, 3Com registered trademarks are registered in the United States and may or may
not be registered in other countries.
3Com and the 3Com logo are registered trademarks of 3Com Corporation.
All other company and product names may be trademarks of the respective companies with which they are
associated.
ENVIRONMENTAL STATEMENT
It is the policy of 3Com Corporation to be environmentally-friendly in all operations. To uphold our policy, we
are committed to:
Establishing environmental performance standards that comply with national legislation and regulations.
Conserving energy, materials and natural resources in all operations.
Reducing the waste generated by all operations. Ensuring that all waste conforms to recognized environmental
standards. Maximizing the recyclable and reusable content of all products.
Ensuring that all products can be recycled, reused and disposed of safely.
Ensuring that all products are labelled according to recognized environmental standards.
Improving our environmental record on a continual basis.
End of Life Statement

3Com processes allow for the recovery, reclamation and safe disposal of all end-of-life electronic components.
Regulated Materials Statement

3Com products do not contain any hazardous or ozone-depleting material.
Environmental Statement about the Documentation

The documentation for this product is printed on paper that comes from sustainable, managed forests; it is fully
biodegradable and recyclable, and is completely chlorine-free. The varnish is environmentally-friendly, and the
inks are vegetable-based with a low heavy-metal content.
About This Manual
Organization
3Com MSR Series Routers Operation Manual is organized as follows:
Chapter Contents
Configuration of interfaces and link layer protocols supported on the
1 Access Volume
router.
Configuration of IP-related features such as IP address, ARP, DNS,
2 IP Services Volume DHCP, IP performance, IP Unicast Routing, ACL, IPv6 Basics, NAT-PT
and IPv6 over IPv4 Tunnel.
Configuration of routing protocols such as static route, RIP, RIPng, OSPF,
3 IP Routing Volume
OSPFv3, IS-IS, BGP, BGP4+ and routing policy.
Configuration of IP multicast protocols such as IGMP, PIM, MSDP,
4 IP Multicast Volume
multicast policy and MLD.
5 MPLS Volume Configuration of MPLS related protocols such as MPLS, MPLS TE.
Configuration of VPN related protocols such as GRE, MPLS L3VPN,
6 VPN Volume
MPLS L2VPN.
Configuration of QoS related protocols and features supported on the
router, such as traffic classification, policing, and shaping, QoS policy,
7 QoS Volume
congestion management, priority mapping, congestion avoidance, MPLS
QoS, DAR and Frame Relay QoS.
Configuration of security protocols such as AAA, user management,
8 Security Volume
firewall, NAT, IPSec, IKE, RADIUS, HWTACACS and PORTAL.
Configuration of system-related protocols and features such as basic
system configuration, user login, file system management, system
9 System Volume
maintenance, NTP, SNMP, RMON, backup center, VRRP, NQA and MAC
address table management.
10 IPX Volume Configuration of IPX protocol supported on the router.
Configuration of VoIP-related protocols and features such as H.323, SIP,
11 Voice Volume
FoIP, and dial policy.
12 OAA Volume Configuration of OAP module, ACFP, ACSEI.
Configuration of WLAN-related protocols and features such as WLAN
13 WLAN Volume Service, WLAN Security, WLAN RRM, WLAN IDS, WLAN Qos, and Layer
2 Software Forwarding.
Conventions
The manual uses the following conventions:
Command conventions
Convention Description
Boldface The keywords of a command line are in Boldface.
italic Command arguments are in italic.

[] Items (keywords or arguments) in square brackets [ ] are optional.
Alternative items are grouped in braces and separated by vertical bars.
{ x | y | ... }
One is selected.
Optional alternative items are grouped in square brackets and
[ x | y | ... ]
separated by vertical bars. One or none is selected.
Alternative items are grouped in braces and separated by vertical bars.
{ x | y | ... } *
A minimum of one or a maximum of all can be selected.
Optional alternative items are grouped in square brackets and
[ x | y | ... ] *
separated by vertical bars. Many or none can be selected.
The argument(s) before the ampersand (&) sign can be entered 1 to n
&<1-n>
times.
# A line starting with the # sign is comments.
GUI conventions
Window names, button names, field names, and menu items are in
Boldface
Boldface. For example, the New User window appears; click OK.
Multi-level menus are separated by angle brackets. For example, File >
>
Create > Folder.
Symbols
Means reader be extremely careful. Improper operation may cause
bodily injury.
Means reader be careful. Improper operation may cause data loss or
damage to equipment.
Means an action or information that needs special attention to ensure
successful configuration or good performance.
Means a complementary description.
Means techniques helpful for you to make configuration with ease.

Related Documentation
In addition to this manual, each 3COM MSR Series Routers documentation set includes the following:
Manual Description
3COM MSR Series
It is shows the basic information of MSR series routers.
Routers User Manual
3COM MSR Series
Routers Interface Card It covers the pinouts, function, interface attributes, panels and LEDs of
and Interface Module all interface cards and modules available with the router.
Manual
It gives the user a detailed description of the operating commands. It is
3Com MSR Series organized into the parts of getting started, system management,
Routers Command interface, link layer protocol, network protocol, routing protocol,
Manual multicast protocol, security, VPN, reliability, QoS, dial-up and VoIP, as
well as a command index.
This guide describes the MSR 20-1X Series Routers and how to install
3Com MSR 20-1X Series
hardware, configure and boot software, and maintain software and
Routers Installation
hardware. This guide also provides troubleshooting and support
Manual
information for your router.
This guide describes the MSR 20 Series Routers and how to install
3Com MSR 20 Series
Manual
3Com MSR 30 Series
Manual
3Com MSR 50 Series
Manual
3Com MSR 20-1x Series
It provides guidelines to Web-based configuration on the MSR 20-1x
Routers Web-Based
Series Routers.
Configuration Manual
3Com MSR 20/30/50
Series Routers It provides guidelines to Web-based configuration on the MSR 20/30/50
Web-Based Series Routers.
Configuration Manual
Obtaining Documentation
You can access the most up-to-date 3Com product documentation on the World Wide Web at this URL:
http://www.3com.com.
Volume Introduction
Softwares on MSR series routers fall into two versions: basic and standard. You can find lists of features
supported on the two versions and the corresponding volumes of protocols or features you are
interested in through feature indexes for these two versions respectively.
z Access Volume: Configuration of interfaces and link layer protocols supported on the router
z IP Services Volume: Configuration of IP-related features such as IP address, ARP, DNS, DHCP, IP
performance, IP Unicast Routing, ACL, IPv6 Basics, NAT-PT and IPv6 over IPv4 Tunnel
z IP Routing Volume: Configuration of routing protocols such as static route, RIP, RIPng, OSPF,
OSPFv3, IS-IS, BGP, BGP4+ and routing policy
z IP Multicast Volume: Configuration of IP multicast protocols such as IGMP, PIM, MSDP, multicast
policy and MLD
z MPLS&VPN Volume: Configuration of MPLS and VPN related protocols such as MPLS, MPLS TE,
GRE, MPLS L3VPN, MPLS L2VPN.
z QoS Volume: Configuration of QoS related protocols and features supported on the router, such as
traffic classification, policing, and shaping, QoS policy, congestion management, priority mapping,
congestion avoidance, MPLS QoS, DAR and Frame Relay QoS
z Security Volume: Configuration of security protocols such as AAA, user management, firewall,
NAT, IPSec, IKE, RADIUS, HWTACACS and PORTAL
z System Volume: Configuration of system-related protocols and features such as basic system
configuration, user login, file system management, system maintenance, NTP, SNMP, RMON,
backup center, VRRP, NQA and MAC address table management
z IPX Volume: Configuration of IPX protocol supported on the router
z Voice Volume: Configuration of VoIP-related protocols and features such as H.323, SIP, FoIP, and
dial policy
z OAA Volume: Configuration of OAP module, ACFP, ACSEI.
z WLAN Volume: Configuration of WLAN-related protocols and features such as WLAN Service,
WLAN Security, WLAN RRM, WLAN IDS, WLAN Qos, and Layer 2 Software Forwarding.
1
Feature Description
Overview
MSR Series Routers can be divided into four series: MSR 20, MSR 30 , MSR 50 ,MSR 20-1X, which are
positioned in ascending order. MSR 20, MSR 30, MSR 20-1X series can be used as the edge access
equipment of large networks or carrier networks, and the core of branches or small businesses; MSR
50 series can be used as the core of large and medium-sized enterprise networks as well as the
edge/aggregation access equipment of large networks or carrier networks.
Functional Modules Index

Table 1-1 Functional modules index
Functional
Feature
module
ATM and DSL
POS Interface Ethernet Interface WAN Interface
interface
ATM DCC DLSw Frame Relay
GVRP HDLC LAPB and X.25 Link Aggregation
Access Volume
MODEM Port Mirroring PPP Bridging
ISDN MSTP VLAN Port Isolation
Dynamic router
Logical interface CPOS WLAN Interface
backup
ARP DHCP DNS IP Accounting
IP Unicast
IP Addressing IP Performance UDP Helper
Policy-Routing
IP Services URPF Fast Forwarding IPv6 Basics NAT-PT
Volume
IPv6 Unicast
Dual Stack Tunneling Terminal Access
Policy Routing
IP Terminal Virtual Fragment
sFlow
Access Reassembly
IP Routing
BGP IS-IS OSPF
Overview
IP Routing
RIP Routing Policy Static Routing IPv6 BGP
Volume
IPv6 Static
IPv6 IS-IS IPv6 OSPFv3 IPv6 RIPng
Routing
Multicast Multicast Routing
IGMP MSDP
Overview and Forwarding
IPv6 Multicast
IP Multicast PIM Routing and MLD IPv6 PIM
Volume Forwarding
Multicast VPN IGMP Snooping MLD Snooping MBGP
IPv6 MBGP
1
Functional
Feature
module
MPLS&VPN MPLS Basics MPLS TE MPLS L2VPN MPLS L3VPN

Volume DVPN GRE L2TP
QoS Volume QoS
MAC
802.1x AAA Firewall
Authentication
Security NAT PKI PORTAL Rsh

Volume ACL IPSec SSH2.0 SSL
IP Source
Port Security
Guard
Device
GR Backup Center VRRP
Management
Automatic
NQA NTP RMON
Configuration
System
System File System Basic System
SNMP Maintaining and
Volume Management Configuration
Debugging
MAC Address
Information
User Interface Table NetStream
Center
Management
PoE Track HTTP CWMP (TR-069)
IPX Volume IPX

Voice Overview VoIP Dial Plan E1 and T1
Voice Volume Fax over IP H.323 SIP VoFR
Voice RADIUS Call Services

OAA Volume OAP Module ACFP ACSEI
WLAN Service WLAN Security WLAN RRM WLAN IDS
WLAN Volume Layer 2 Software
WLAN QoS
Forwarding
Feature Description
In the PDF version of this manual, you can click the hyperlink in the Operation Manual and Command
Manual to access the operation and command manual you are interested in. Press <Alt + > to return
to [ Feature Description ].
2
Access Volume
Table 1-2 Features in access volume
Operation and command

Feature Feature description
manual
ATM and DSL Interface
Configuration Introduction to interfaces such as ATM/DSL,
ATM&DSL
IMA-E1/T1, ATM E3/T3, ATM OC-3c/STM-1,
Interface ATM and DSL Interface ADSL and G.SHDSL
Commands
z Configuring a CPOS Interface
CPOS Interface Configuration
CPOS z Configuring an E1 Channel
CPOS Interface Commands
z Configuring a T1 Channel
POS Interface Configuration
POS Interface POS configuration and introduction
POS Interface Commands
Ethernet Ethernet Interface Configuration Combo, layer 2 and layer 3 Ethernet interface
Interface Ethernet Interface Commands introduction
Introduction to WAN interfaces such as

WAN WAN Interface Configuration Synchronous/asynchronous serial interface,
Interface WAN Interface Commands AUX, AM, ISDN BRI, E1-F, T1-F, CE1/PRI,
CT1/PRI, CE3 and CT3
z Configuration of ATM, ATM subinterface
ATM Configuration and PVC and VP monitoring and
ATM management
ATM Commands z Introduction to IPoA, PPPoA, IPoEoA and
PPPoEoA supported on an ATM interface
Dial control center, a routing technology
through which routers can interconnect with
DCC Configuration each other through public switching network
DCC (PSTN and ISDN).
DCC Commands
z DCC basic configuration
z Configuration of DCC specific functions
DLSw configuration z Configuring DLSw in Ethernet
DLSw
DLSw Commands z Configuring DLSw in SDLC
z FR DCE/DTE configuration
z FR compression configuration
Frame Relay Configuration
Frame Relay z Multilink FR configuration
Frame Relay Commands
z PPPoFR configuration
z MPoFR configuration
GVRP Configuration z GVRP function configuration
GVRP
GVRP Commands z GARP timer configuration
HDLC Configuration
HDLC HDLC configuration
HDLC Commands
z LAPB configuration
LAPB and LAPB and X.25 Configuration z X.25 configuration
X.25 LAPB and X.25 Commands z XOT configuration
z X2T configuration
z Link aggregation classification
Link Link Aggregation Configuration z Load sharing mode in a link aggregation
Aggregation Link Aggregation Commands group
z Link aggregation configuration
3
manual
MODEM Configuration
MODEM MODEM management configuration
MODEM Commands
Port Mirroring Configuration
Port Mirroring Local port mirroring configuration
Port Mirroring Commands
z PPP configuration
PPP Configuration z MP configuration
PPP z PPP link efficiency mechanism
PPP Commands configuration
z PPPoE configuration
Bridging Configuration
Bridging Isolation group configuration
Bridging Commands
ISDN Configuration
ISDN ISDN configuration
ISDN Commands
z Root bridge configuration
z Leaf node configuration
MSTP Configuration z Performing mCheck
MSTP
MSTP Commands z Digest snooping configuration
z No Agreement Check configuration
z Protection functions configuration
z Basic VLAN attributes configuration
VLAN Configuration z Configuration for VLAN interface basic
VLAN attributes
VLAN Commands z Port-based VLAN configuration
z Voice VLAN configuration
Port Isolation Configuration
Port Isolation Isolation group configuration
Port Isolation Commands
Dynamic Route Backup

Configuration z Dynamic Route Backup Configuration
Dynamic
Route Backup z Dynamic Route Backup Configuration
Dynamic Route Backup Example
Commands
z Dialer Interface
z Loopback Interface
z Null Interface
Logical Logical Interface Configuration z Sub-interface
Interface Logical Interface Commands z Configuring MP-group Interfaces
z Configuring MFR Interface
z VT and VA Interface
z Configuring VE
z WLAN-Radio Interface
z WLAN-ESS Interface
WLAN WLAN Interface Configuration
z WLAN-DBSS Interface
Interface WLAN Interface Commands
z WLAN-BSS Interface
z WLAN-Ethernet Interface
Return to Functional Modules Index
4
IP Services Volume
Table 1-3 Features in IP services volume

manual
Address resolution protocol, mainly used for
resolution from IP address to Ethernet MAC
address.
ARP Configuration
ARP z ARP configuration
ARP Commands
z Gratuitous ARP configuration
z ARP source suppression configuration
z Proxy ARP configuration
IP Terminal Access
Configuration IP terminal access allows a terminal to access a
IP Terminal
remote Unix/Linux server, which is also known as a
Access IP Terminal Access front-end processor (FEP) through a router.
Commands
Dynamic host configuration protocol, implements
dynamic configuration for information such as IP
address.
DHCP Configuration z DHCP server configuration
DHCP
DHCP Commands z DHCP relay configuration
z DHCP client configuration
z DHCP Snooping configuration
z BOOTP client configuration
DNS is a distributed database that applies to
TCP/IP application programs. It functions to resolve
DNS Configuration
DNS between hostnames and IP addresses.
DNS Commands
z Static DNS configuration
z Dynamic DNS configuration
IP Accounting IP accounting counts inbound and outbound IP
IP Accounting Configuration packets on the router.
IP Accounting Commands z IP accounting configuration
IP Addressing
Configuration z IP address configuration
IP Addressing
z Assigning an IP address to an interface
IP Addressing Commands
In a specific network, IP parameters need to be

IP Performance adjusted to optimize the network performance.
Configuration z Enabling receiving and forwarding directed
IP Performance
IP Performance broadcasts
Commands z Configuration of TCP timer, buffersize, packet
size and ICMP error packets
IP Unicast Policy-Routing
Configuration Policy routing, selects routes according to policies
IP Unicast defined by the user.
Policy-Routing IP Unicast Policy-Routing
Commands z Policy routing configuration
UDP Helper functions to relay UDP broadcast

UDP Helper Configuration packets to the specified server after converting
UDP Helper them to unicast packets.
UDP Helper Commands
z UDP Helper configuration
URPF Configuration Unicast reverse path finding, used to prevent the

URPF network attack based on source address spoofing.
URPF Commands
z URPF configuration
5
manual
Fast Forwarding Fast forwarding employs cache and
Fast Configuration data-flow-based technology to handle packet
Forwarding Fast Forwarding forwarding.
Commands z Fast forwarding configuration
Internet protocol version 6 (IPv6) was designed by
the Internet Engineering Task Force (IETF) as the
successor to Internet protocol version 4 (IPv4).
z Configuring basic IPv6 functions
IPv6 Basics Configuration
IPv6 Basics z IPv6 NDP configuration
IPv6 Basics Commands
z PMTU discovery configuration
z TCP6 configuration
z IPv6 FIB forwarding configuration
z IPv6 DNS configuration
IPv4 networks and IPv6 networks will co-exist to
communicate with each other for a long period of
NAT-PT Configuration time. The network address translation protocol
NAT-PT translation (NAT-PT) realizes translation between
NAT-PT Commands IPv4 and IPv6 addresses to meet the
communication requirement.
z NAT-PT configuration
A network node that supports both IPv4 and IPv6 is
called a dual stack node. A dual stack node
Dual Stack Configuration configured with an IPv4 and an IPv6 addresses can
Dual Stack have both IPv4 and IPv6 packets transmitted.
Dual Stack Commands
z Dual stack configuration
z Transition technology from IPv4 to IPv6
Tunneling is an encapsulation technology, which
utilizes one network transport protocol to
encapsulate packets of another network transport
protocol and transfer them over the network.
z Manual/automatic IPv4-compatible IPv6 Tunnel
Tunneling Configuration
Tunneling z 6to4 tunnel configuration
Tunneling Commands z ISATAP tunnel configuration
z IPv4 over IPv4 tunnel configuration
z 6PE configuration
IPv6 Unicast Policy
IPv6 Unicast Routing Configuration
IPv6 Unicast Policy Routing configuration
Policy Routing IPv6 Unicast Policy
Routing Commands
Terminal Access z Introduction to Terminal Access
Terminal Configuration z TTY Terminal Access Configuration
Access Terminal Access z Telnet Terminal Access Configuration
Commands z RTC Terminal Access Configuration
sFlow Configuration Sampled Flow (sFlow) is a traffic monitoring

sFlow technology mainly used to collect and analyze
sFlow Commands traffic statistics.
6
manual
To prevent each service module from processing
Virtual Fragment packet fragments that do not arrive in order, you
Virtual Reassembly Configuration can enable the virtual fragment reassembly feature,
Fragment which can virtually reassemble the fragments of a
Reassembly Virtual Fragment datagram through fragment check, sequencing and
Reassembly Commands caching, ensuring fragments arriving at each
service module is in order.
IP Routing Volume
Table 1-4 Features in IP routing volume

manual
IP routing overview
IP Routing IP Routing Overview z IP routing overview
Overview IP Routing Table Commands z IP routing and routing table
z Routing through a routing table
A dynamic inter-AS route discovery protocol
BGP Configuration z Configuring BGP basic functions
BGP
BGP Commands z Configuring BGP routing attributes
z Configuring a large scale BGP network
An interior gateway protocol (IGP) used within an
Autonomous System. It adopts the Shortest Path
IS-IS Configuration
ISIS First (SPF) algorithm for route calculation.
IS-IS Commands
z Configuring ISIS basic functions
z Configuring ISIS routing information control
An interior gateway protocol based on link state
z Configuring OSPF Basic Functions
OSPF Configuration z Configuring OSPF Area Parameters
OSPF
OSPF Commands z Configuring OSPF Network Types
z Configuring OSPF Routing Information
Management
A simple Interior Gateway Protocol mainly used
RIP Configuration in small-sized networks
RIP
RIP Commands z Configuring RIP basic functions
z Configuring RIP advanced functions
Routing policy, used to change the route that
Routing Routing Policy Configuration network traffic passes.
Policy Routing Policy Commands z Defining Filtering Lists
z Configuring a Routing Policy
A special route that is manually configured by the
network administrator. The proper configuration
and usage of static routes can improve a
Static Static Routing Configuration
networks performance and ensure bandwidth for
Routing Static Routing Commands important network applications.
z Configuring a static route
z Application
7
manual
BGP4+ puts IPv6 network layer information into
the attributes of Network Layer Reachable
IPv6 BGP Configuration Information (NLRI) and NEXT_HOP.
IPv6 BGP
IPv6 BGP Commands z Configuring BGP4+ basic functions
z Controlling route distribution and reception
z Configuring BGP4+ route attributes
Supports multiple network protocols, including
IPv6 and supports two Type-Length-Values
(TLVs) and a new Network Layer Protocol
IPv6 IS-IS Configuration
IPv6 ISIS Identifier (NLPID)
IPv6 IS-IS Commands
z Configuring IPv6-IS-IS basic functions
z Configuring IPv6-IS-IS routing information
control
OSPF protocol supporting IPv6
IPv6 IPv6 OSPFv3 Configuration z Configuring OSPFv3 basic functions

OSPFv3 IPv6 OSPFv3 Commands z Configuring OSPFv3 area parameters
z Configuring OSPFv3 routing information
management
An extension of RIP-2 for IPv4
IPv6 RIPng Configuration
IPv6 RIPng z Configuring RIPng basic functions
IPv6 RIPng Commands
z Configuring RIPng advanced functions
IPv6 Static Routing Special routes that are manually configured by

IPv6 Static Configuration network administrators work well in simple
Routing networks.
IPv6 Static Routing Commands
z Configuring IPv6 static routes
IP Multicast Volume
Table 1-5 Features in IP multicast volume
Feature Operation and command manual Feature description

Multicast overview. Layer 2 multicast is not
supported.
Multicast z Multicast models
Multicast Overview
Overview z Framework of multicast
z Multicast packets forwarding
mechanism
Multicast Routing and Forwarding Policies used for filtering the routing
Multicast Configuration information used in the RPF check
Routing and
Forwarding Multicast Routing and Forwarding z Multicast policy overview
Commands z Configuring a multicast policy
Internet Group Management Protocol
IGMP IGMP Snooping Configuration Snooping is a multicast constraining
Snooping IGMP Snooping Commands mechanism that runs on Layer 2 devices to
manage and control multicast groups.
8
Internet group management protocol, a
protocol in the TCP/IP suite responsible for
IGMP Configuration
IGMP management of IP multicast members.
IGMP Commands
z Configuring basic functions of IGMP
z Adjusting IGMP performance
Multicast source protocol, an interdomain
multicast solution based on
interconnection between multiple PIM-SM
MSDP Configuration domains.
MSDP
MSDP Commands z Configuring basic functions of MSDP
z Configuring an MSDP peer connection
z Configuring SA messages
Protocol independent multicast, provides
IP multicast forwarding by leveraging
unicast routes generated by any unicast
PIM Configuration routing protocols.
PIM
PIM Commands z Configuring PIM-DM
z Configuring PIM-SM
z Configuring PIM-SSM
z Configuring PIM Common Information
IPv6 IPv6 Multicast Routing and
Multicast Forwarding Configuration
Overview of IPv6 multicast
Routing and IPv6 Multicast Routing and
Forwarding Forwarding Commands
Multicast Listener Discovery Snooping is
MLD MLD Snooping Configuration an IPv6 multicast constraining mechanism
Snooping MLD Snooping Commands that runs on Layer 2 devices to manage
and control IPv6 multicast groups.
Used by an IPv6 router to discover the
presence of multicast listeners on
MLD Configuration
MLD directly-attached subnets.
MLD Commands
z Configuring Basic Functions of MLD
z Adjusting MLD Performance
Protocol independent multicast for IPv6
z Configuring IPv6 PIM-DM
IPv6 PIM Configuration z Configuring IPv6 PIM-SM
IPv6 PIM
IPv6 PIM Commands z Configuring IPv6 PIM-SSM
z Configuring IPv6 PIM Common
Information
z Multicast VPN Overview
Multicast Multicast VPN Configuration
z How MD-VPN Works
VPN Multicast VPN Commands
z Configuring MD-VPN
BGP-4 is capable of carrying routing
MBGP Configuration information for IPv4 only. IETF defined
MBGP multiprotocol BGP extensions to carry
MBGP Commands routing information for multiple network
layer protocols.
IPv6 MBGP Configuration
IPv6 MBGP MBGP for IPv6
IPv6 MBGP Commands
9
MPLS&VPN Volume
Table 1-6 Features in MPLS&VPN volume

manual
z MPLS configuration basics
z LDP overview
MPLS z Configuring MPLS basic capability
Basics MPLS Basics Configuration z Configuring PHP
Configuratio MPLS Basics Commands z Configuring a static LSP
n z Configuring MPLS LDP
z Configuring LDP instances
z Configuring MPLS TTL processing
z MPLS TE overview
z Configuring MPLS TE basic capabilities
z Creating MPLS TE tunnel over static CR-LSP
z Configuring MPLS TE tunnel with dynamic
signaling protocol
z Configuring RSVP-TE advanced features
MPLS TE Configuration z Tuning CR-LSP setup
MPLS TE
MPLS TE Commands z Tuning MPLS TE tunnel setup
z Configuring traffic forwarding
z Configuring traffic forwarding tuning
parameters
z Configuring automatic bandwidth adjustment
z Configuring CR-LSP backup
z Configuring FRR
Supports multiple link-layer protocols to provide
L2VPN services based on different media on an
MPLS network.
MPLS MPLS L2VPN Configuration z Configuring MPLS L2VPN
L2VPN MPLS L2VPN Commands z Configuring CCC MPLS L2VPN
z Configuring SVC MPLS L2VPN
z Configuring Martini MPLS L2VPN
z Configuring Kompella MPLS L2VPN
MPLS VPN is a L3VPN technology based on PE
in a VPN solution for carriers.
z Configuring VPN instances
z Configuring basic BGP/MPLS VPN
MPLS MPLS L3VPN Configuration z Configuring Inter-Provider VPN
L3VPN MPLS L3VPN Commands z Configuring Multi-Role Host
z Configuring HoVPN
z Configuring OSPF Sham Link
z Configuring multi-VPN-instance CE
z Configuring BGP AS number substitution
DVPN overview and DVPN configuration
z Configuring AAA
DVPN Configuration z Configuring the VAM Server
DVPN z Configuring the VAM Client
DVPN Commands
z Configuring an IPSec Profile
z Configuring the DVPN Tunnel Parameters
z Configuring a DVPN Route
10
manual
A protocol designed for performing
encapsulation of one network layer protocol over
GRE Configuration another network layer protocol.
GRE
GRE Commands z GER overview
z Configuring a GRE over IPv4 tunnel
z Configuring a GRE over IPv6 tunnel
Defines an encapsulation mechanism for
transporting multiprotocol packets over Layer 2
L2TP Configuration
L2TP (L2) point-to-point links
L2TP Commands
z LAC configuration
z LNS configuration
QoS Volume
Table 1-7 Features in QoS volume

manual
Quality of service, evaluates the service
performance for those network core
requirements during packet transmission
process, such as: delay, jitter and packet loss
ratio.
Peak rate and hardware queues are not
supported.
QoS Configuration
QoS z Traffic classification, policing, and shaping
QoS Commands z QoS policy configuration
z Congestion management
z Priority mapping
z Congestion avoidance
z MPLS QoS configuration
z DAR configuration
z Frame Relay QoS configuration
Security Volume
Table 1-8 Features in security volume

manual
802.1x is a port-based access control protocol.
It authenticates and controls accessing devices
802.1x Configuration at the level of port.
802.1x
802.1x Commands z 802.1 basic configuration
z 802.1x advanced configuration
z Guest VLAN configuration
11
manual
Authentication, authorization and accounting
(AAA) provide a uniform framework used for
AAA RADIUS HWTACACS configuring these three security functions to
AAA Configuration
RADIUS implement the network security management.
HWTACACS AAA RADIUS HWTACACS z AAA configuration
Commands
z RADIUS configuration
z HWTACACS configuration
Firewall can prevent unauthorized or
unauthenticated users on the Internet from
Firewall(ACL ASPF PAM)
accessing a protected network while allowing
Firewall(ACL Configuration
the users on the internal network to access web
ASPF PAM) Firewall(ACL ASPF PAM) sites on the Internet and transceive E-mails.
Commands
z Configuring a Packet Filter Firewall
z Configuring an ASPF
MAC address authentication controls user
MAC MAC Authentication network access based on port and MAC
Authenticatio Configuration address.
n MAC Authentication Commands z MAC authentication basic configuration
z MAC authentication advanced configuration
Public key infrastructure (PKI) is a system
which uses public key technology and digital
certificate to protect system security and
authenticate digital certificate users.
PKI Configuration z Generating an RSA pair for PKI
PKI
PKI Commands z Configuring PKI certificate registration
z Submitting a PKI certificate request
z Configuring PKI certificate validation
z Configuring access control policy of
certificate attribute
Portal authentication
Portal Configuration z Portal authentication basic configuration
PORTAL
Portal Commands z Portal authentication advanced
configuration
Rsh Configuration Users can use the Rsh command to execute

Rsh commands on the host of the client end.
Rsh Commands
z Rsh configuration
By filtering packets on a per-port basis, IP
IP Source IP Source Guard Configuration source guard prevents illegal packets from
Guard IP Source Guard Commands traveling through, thus improving the network
security.
Network Address Translation (NAT) is to
translate the IP address in IP data packet
header into another IP address, which is mainly
used to implement private network accessing
external network in practice.
NAT Configuration z Configuring EASY IP
NAT Configuring static NAT
NAT Commands z
z Configuring Many-to-many NAT

z Configuring many-to-one NAPT
z Configuring Internal Server
z Configuring NAT Log
z Configuring Connection Limit
12
manual
Access control list, to implement traffic
identification function
Traffic template is not supported.
z Time-Based ACL
ACL Configuration z Basic IPv4 ACL configuration
ACL
ACL Commands z Advanced IPv4 ACL configuration
z Ethernet frame header ACL configuration
z User-defined ACL configuration
z Basic IPv6 ACL configuration
z Advanced IPv6 ACL configuration
Layer 3 tunnel encryption protocol defined by
IETF, which provides security for IP data
packets transmitted on the Internet.
z Configuring an IPSec proposal
z Configuring an IPSec policy
z Configuring an IPSec policy template
IPSec Configuration z Applying an IPSec policy
IPSec
IPSec Commands z Configuring an encryption card IPSec policy
z Configuring encryption engine
z Configuring fast forwarding for encryption
card
z Configuring an IKE proposal
z Configuring an IKE peer
z Configuring IKE keepalive timer
Security shell. When routers are connected by
remote users across insecure networks, secure
shell (SSH) can provide them authentication
SSH2.0 Configuration and security.
SSH2.0
SSH2.0 Commands z Configuring the SSH server
z Configuring the SSH client
z Configuring the device as an SSH client
Secure sockets layer
SSL Configuration
SSL z Configuring SSL server policy
SSL Commands
z Configuring SSL client policy
Port security is a MAC address-based security
Port Security Configuration mechanism for network access controlling. It is
Port Security
Port Security Commands an extension to the existing 802.1x
authentication and MAC authentication.
System Volume
Table 1-9 Features in system volume

manual
Perfect restart. When routing protocol is restarted,
the forwarding service will not be terminated.
GR GR Overview
z Supports only FIB6, ISIS and BGP
protocol-level GR
13
manual
Module in charge of backup, providing backup for
the device interface.
Backup Backup Center Configuration
Center z Introduction to backup center settings
Backup Center Commands
z Configuring Main/backup Mode
z Configuring Loading Sharing
Virtual routing redundancy protocol, with which the
VRRP Configuration system can still provide highly reliable default links
VRRP without changing configurations when a device
VRRP Commands fails.
z IPv6 based VRRP configuration
Through the device management function, users
Device Management can view the current working state of devices,
Device Configuration configure operation parameters, and perform daily
Management Device Management device maintenance and management.
Commands Validity check of BootROM is not supported.
z Configuring device management
Detects the availability and the response time of
DHCP, FTP, HTTP, and SNMP services and
provides test results
NQA Configuration
NQA z Configuring NQA Tests
NQA Commands
z Configuring Optional Parameters for NQA
Tests
z Enhanced Ping functions
NetStream provides the packet statistics function.
z Configuring NetStream Statistics
NetStream Configuration z Configuring NetStream Aggregation Statistics
NetStream
NetStream Commands z Configuring Attributes of NetStream UDP
Packets
z Configuring NetStream Statistics Aging
Network time protocol, used for time
synchronization between distributed time server
and the client.
NTP Configuration z Configuring the operation modes of NTP

NTP z Configuring the local clock as a reference
NTP Commands source
z Configuring optional parameters of NTP
z Configuring access-control rights
z Configuring NTP authentication
Remote monitoring, making SNMP monitor
RMON Configuration remote network devices more effectively and
RMON proactively.
RMON Commands
z RMON configuration
Simple network management protocol, a frame
using TCP/IP protocol suite to manage devices on
SNMP Configuration
SNMP the Internet
SNMP Commands
z Configuring SNMP basic functions
z Configuring Trap
14
manual
Manages storage devices and store files in these
File Management devices.
File Configuration
Management z File system management
File Management Commands z Configuring FTP
z Configuring TFTP
For the protocols and features supported on the
System System Maintenance and device, the system provides corresponding
Maintenance Debugging Configuration debugging functions to help users diagnose and
and System Maintenance and locate errors
Debugging Debugging Commands z Configuring system debugging
z Configuring ping and tracert
Basic System Configuration
Basic System Operation
z Basic system configuration
Configuration Basic System Configuration
Commands
Information Center Acting as the system information hub, information
Information Configuration center classifies and manages system
Center Information Center information.
Commands z Configuring the information center
User interface view is a feature that allows you to
manage asynchronous serial interfaces that work
in flow mode. By operating under user interface
view, you can centralize the management of
various configurations.
z Configuring asynchronous interface attributes
z Configuring terminal attributes
User Interface Configuration z Configuring modem attributes
User Interface z Configuring the auto-execute command
User Interface Commands
z Configuring user privilege level
z Configuring access restriction to VTY user
interfaces
z Configuring supported protocols on VTY user
interfaces
z Configuring redirection function on the
asynchronous serial interface
z Configuring authentication mode at login
A device maintains a MAC address table for frame
MAC Address Table forwarding. Each entry in this table indicates the
MAC Address Management Configuration MAC address of a connected device, to which
Table interface this device is connected and to which
Management MAC Address Table
Management Commands VLAN the interface belongs.
z Configuring the MAC address table
POE Configuration
POE Introduction to PoE
POE Commands
Automatic
Automatic Configuration Introduction to Automatic Configuration
Configuration
15
manual
The Hypertext Transfer Protocol (HTTP) is used
for transferring web page information across the
Internet. It is an application-level protocol in the
HTTP Configuration
HTTP TCP/IP protocol suite.
HTTP Commands
The HTTP Security (HTTPS) refers to the HTTP
protocol that supports the Security Socket Layer
(SSL) protocol.
Track Configuration
Track Track overview and configuration
Track Commands
CPE WAN Management Protocol is a technology

specification initiated and developed by the Digital
Subscribers Line (DSL) Forum. CWMP is
CWMP (TR-069) numbered TR-069 by the forum, therefore also
CWMP Configuration called TR-069 protocol. It defines the general
(TR-069)
CWMP (TR-069) Commands frame, message format, management method,
and data model for the management and
configuration of home network devices in the
next-generation network.
Telnet Configuration
Telnet Telnet Commands
Commands
IPX Volume
Table 1-10 Features in IPX volume

IPX is a connectionless protocol. Such
functions as confirmation of forwarding
success and connection control are
provided by the protocol at the layer
IPX Configuration above IPX.
IPX
IPX Commands z Configuring IPX basic functions
z Configuring IPX routing
z Configuring IPX SAP
z Configuring the IPX Forwarding
Feature
16
Voice Volume
Table 1-11 Features in voice volume

Introduction to Voice
z Basic VoIP call flow
z Configuring VoIP features
Voice
Voice Overview z Voice subscriber line
Overview
z Voice entity
z Protocol
z Dial plan
The application of VoIP on routers makes it
possible for an IP network to carry voice
VoIP Configuration
VoIP services.
VoIP Commands
z Configuring voice subscriber line
z Configuring voice entity
A dial program can help voice gateways to
manage numbers in a unified way and create
a management policy for all numbers, making
Dial Plan Configuration
Dial Plan number management more convenient and
Dial Plan Commands reasonable.
z Dial plan process
z Dial plan configuration
E1/T1 voice implements VoIP on E1/T1 line,
allowing the router to provide more channels
of voice communication, greatly improving
E1 and T1 Configuration router utilization and broadening service
E1 and T1 range.
E1 and T1 Commands
z E1/T1 interface
z E1/T1 voice functions
z E1/T1 configuration
Implements sending and receiving of fax over
Fax over IP Configuration the Internet
Fax over IP
Fax over IP Commands z Introduction to FoIP
z FoIP configuration
GK (gate keeper) configuration for H.323
voice gateway, combining the voice gateway
H.323 Configuration with GK, thus implementing the VoIP function.
H.323
H.323 Commands z Introduction
z H.323 architecture
z H.323 gateway configuration
Session initiation protocol, an application layer
protocol used for initiating, modifying and
stopping a multimedia session
SIP Configuration
SIP z Introduction to SIP
SIP Commands
z Introduction to SIP configuration tasks
z Basic SIP UA configuration
z Advanced SIP UA configuration
17
Voice over frame relay enables a router to
transmit voice and voice-band data over a
frame relay network.
VoFR Configuration
VoFR z Configuring VoFR Entity
VoFR Commands
z Configuring VoFR Voice Bandwidth
z Configuring Dynamic Mode
z Configuring FRF.11 Trunk Mode
Voice Voice RADIUS Configuration
Voice RADIUS configuration
RADIUS Voice RADIUS Commands
z Configuring Call Waiting
z Configuring Call Hold
z Configuring Call Forwarding
z Configuring Call Transfer
Call Services Configuration
Call Services z Configuring Hunt Group
Call Services Commands
z Configuring Incoming Call Barring
z Configuring Outgoing Call Barring
z Configuring FEATURE Service
z Configuring a Number Priority Peer
OAA Volume
Table 1-12 Features in OAA volume

OAP Module Configuration
OAP Module OAP Module Overview
OAP Module Commands
ACFP Configuration
ACFP Introduction to ACFP and configuration
ACFP Commands
ACSEI Configuration ACSEI server configuration and ACSEI
ACSEI
ACSEI Commands client configuration
18
WLAN Volume
Table 1-13 Features in WLAN volume

Using the WLAN solution, network
operators and enterprises can provide
wireless LAN services to their customers.
These services include:
WLAN WLAN Service Configuration z WLAN client connectivity to

Service conventional 802.3 LANs.
WLAN Service Commands
z Secured WLAN access with different
authentication and encryption
methods.
z Seamless roaming of WLAN clients in
the mobility domain.
The wireless security capabilities
WLAN WLAN Security Configuration incorporated in 802.11 are inadequate for
Security WLAN Security Commands protecting networks containing sensitive
information.
WLAN radio resource management
(RRM) provides a scalable radio
frequency (RF) management solution
WLAN RRM Configuration along with intelligent control for rapid
WLAN RRM adaptation to RF environment changes. It
WLAN RRM Commands takes a distributed approach in learning
the surrounding environment and a
unified approach in resource assignment
and control.
802.11 networks are susceptible to a wide
array of threats such as unauthorized
access points and clients, ad-hoc
WLAN IDS Configuration networks, denial of service attacks.
WLAN IDS Rogue devices are a serious threat to
WLAN IDS Commands enterprise security. WLAN Intrusion
Detection System (IDS) is used for the
early detection of malicious user attacks
and intrusion through a wireless network.
An 802.11 network offers
contention-based wireless access. To
WLAN QoS Configuration provide applications with QoS services,
WLAN QoS IEEE developed 802.11e for the
WLAN QoS Commands
802.11-based WLAN architecture.
General Layer 2 forwarding is

implemented by hardware; while Layer 2
software forwarding is implemented by
Layer 2 Software Forwarding software. When stations, or stations and
Layer 2 Configuration PCs are in the same VLAN, packet
Software
Layer 2 Software Forwarding forwarding is implemented through Layer
Forwarding
Commands 2 software forwarding; while when they
are not in the same VLAN, packet
forwarding is implemented through Layer
3 forwarding.
19
Table of Contents
1 ATM and DSL Interface Configuration1-1

ATM and DSL Interface1-1
IMA 1-3
Overview1-3
Configuring an IMA Group1-3
IMA-E1/T1 Interface Configuration 1-4
Overview1-4
Configuring an ATM E1/T1 Interface1-5
ATM IMA-E1/T1 Interface Configuration Example 1-6
Troubleshooting ATM IMA-E1/T1 Interfaces 1-7
ATM E3/T3 Interface Configuration 1-7
Overview1-7
Configuring an ATM E3/T3 Interface1-7
ATM OC-3c/STM-1 Interface Configuration1-8
Overview1-8
Configuring an ATM OC-3c/STM-1 Interface 1-8
ADSL Interface Configuration 1-8
Overview1-9
Configuring an ADSL Interface1-10
Upgrading ADSL2+ Card Software 1-10
G.SHDSL Interface Configuration1-11
Overview1-11
Configuring a G.SHDSL Interface 1-12
Displaying and Maintaining ATM and DSL Interfaces 1-13
Troubleshooting 1-13
Troubleshooting ATM Interfaces 1-13
Troubleshooting DSL Interfaces1-14
i
The support for this feature depends on the specific model of the MSR series routers.
Description on ATM and DSL interface support of the MSR series routers:
Interface MSR 20-1X MSR 20 MSR 30 MSR 50

IMA-E1/T1 No No Yes Yes
ATM E3/T3 No No Yes Yes
ATM OC-3c/STM-1 No No Yes Yes

ATM ADSL Yes Yes Yes Yes
No (MSR20-13
ATM G.SHDSL No Yes Yes
supports)
z Refer to MSR 20/30/50 Series Routers Interface Module and Interface Board Manual for interface
support.
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 ATM and DSL Interface Configuration
When configuring an ATM/DSL interface, go to these sections for information you are interested in:
z ATM and DSL Interface
z IMA
z IMA-E1/T1 Interface Configuration
z ATM E3/T3 Interface Configuration
z ATM OC-3c/STM-1 Interface Configuration
z ADSL Interface Configuration
z G.SHDSL Interface Configuration
z Displaying and Maintaining ATM and DSL Interfaces
z Troubleshooting
ATM and DSL Interface

This section covers these topics:
z ATM and DSL
z ATM interfaces available for the low-end and mid-range routers
z ATM interface features
1-1
ATM and DSL
Asynchronous Transfer Mode (ATM) is a backbone network technology for transmission of audio, video,
and data. By virtue of its flexibility and support to multimedia services, ATM is regarded as a core
technology for implementing broadband communications.
Digital Subscriber Line (DSL) is a technology providing high-speed data transmission over the copper
wire. It includes Asymmetric Digital Subscriber Line (ADSL), High-bit-rate Digital Subscriber Line
(HDSL), Very High-rate Digital Subscriber Line (VDSL), single-pair high-speed DSL defined in ITU-T
Standard G.991.2 (G.SHDSL), and Symmetric Digital Subscriber Line (SDSL). These DSL technologies
are different in signal transmission speed and distance and uplink/downlink rate symmetric mode (that
is, whether uplink and downlink rates are the same).
The ATM physical layer lies at the bottom of the ATM reference model. Though it is concerned with
transmission media, its functionality does not rely on the transmission mechanism and speed of a
specific medium. Rather, it primarily delivers valid cells and the associated timing signals between the
upper layer and transmission medium. The speeds of physical access media are defined in
international standards such as ATM OC-3c/STM-1, ATM E3/T3, and IMA-E1/T1. Most DSL
applications are ATM-based, combining the advantages of ATM with the low transmission cost feature
of DSL. So far, DSL technologies have been widely adopted for broadband access.
ATM interfaces available for the low-end and mid-range routers
So far, the low-end and mid-range routers can provide the following ATM interfaces:
z IMA-E1/T1
z ATM E3/T3
z ATM 25.6 Mbps
z ATM OC-3c/STM-1 based on SONET/SDH
z ATM ADSL based on the ADSL technology
z ATM G.SHDSL based on the G.SHDSL technology
These interfaces support IPoA, IPoEoA, PPPoA, and PPPoEoA. For more information about them,
refer to ATM Configuration in the Access Volume.
The interfaces are available depending on your device model.
ATM interface features
The ATM interfaces support:

z Nonreal-time variable bit rate (nrt_VBR)
z Real-time variable bit rate (rt_VBR)
z Constant bit rate (CBR)
z Unspecified bit rate (UBR)
z Permanent virtual circuit (PVC)
z Per-VC traffic shaping
z User-to-network Interface (UNI)
z RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5
z RFC1577 Classical IP and ARP over ATM
1-2
z F5 end to end loopback OAM
z ATM adaptation layer 5 (AAL5)
IMA
Overview
Inverse Multiplexing for ATM (IMA) technology distributes an ATM cell stream to multiple low-speed
links and reassembles the cells into the original stream at the far end. When the ATM cell stream is
distributed, a round robin mechanism is invoked. That is, each of the low-speed links is fed with the
ATM cells in a specific order. The ATM cells sent in each round forms an IMA frame. In addition, the IMA
interface sends ICP cells (IMA control protocol cells) periodically to identify the IMA frames and for the
receiving end to reassemble the distributed ATM cells received. Before reassembling the ATM cells
received of an IMA frame, the receiving end adjusts the differential delay of the link and eliminates the
cell delay variation (CDV) using the ICP cells received. As the IMA frames are aligned on the sending
end before they are distributed to the low-speed links, the differential delays among the low-speed links
can be detected on the receiving end according to the time when the cells transmitted along the
low-speed links arrive. IMA requires that cells be sent continuously. If no ATM cells are to be sent
between two successive ICP cells, filler cells are inserted, which are simply dropped on the receiving
end.
Figure 1-1 An IMA implementation
IMA is achieved through IMA groups. An IMA group is a logical link formed by one or multiple links. It
has a bandwidth approximately the sum of those of the links that form it. IMA provides you a cheap way
to transmit high-speed ATM cell streams over low-speed links while allowing for great flexibility.
Configuring an IMA Group
Follow these steps to configure an IMA group:
To do Use the command Remarks
Enter system view system-view
Enter ATM E1/T1 interface atm

Required
interface view interface-number
1-3
Required
Add the current interface If the IMA group identified by the
ima ima-group group-number group-number argument does not
to an IMA group
exist, this command creates the IMA
group first.
Quit to system view quit
Enter IMA group interface interface ima-group

Required
view group-interfacenumber
Required
Assign an IP address to ip address ip-address
the IMA group interface address-mask By default, an IMA group interface
has no IP address.
Set the number of the cells frame-length { 32 | 64 | 128 | Optional

an IMA frame contains 256 } 128 by default
Optional
Set the clock mode for the ima-clock { ctc [ link-number
IMA group number ] | itc } Common transmit clock configuration
(ctc) by default
ima-standard { alternate-v10 Optional
Set the standard to be
| normal | standard-v10 |
adopted by the IMA group normal by default.
standard-v11 }
Set the minimum number Optional

min-active-links number
of links required 1 by default
Set the maximum Optional
differential-delay
differential delay allowed
milliseconds 25 ms by default
between the links
Optional
By default, link test is disabled.
Enable IMA link test on a If the link is not specified, this
ima-test [ link-number
link and specify the test command enables IMA link test on
number ] [ pattern-id id ]
pattern the link that is first to be added to the
IMA group. The default test pattern is
0xAA.
IMA-E1/T1 Interface Configuration

z Overview
z Configuring an ATM E1/T1 Interface
z ATM IMA-E1/T1 Interface Configuration Example
z Troubleshooting ATM IMA-E1/T1 Interfaces
Overview
The configuration of IMA-E1/T1 includes two parts: physical level parameters of ATM E1/T1 interfaces
and IMA features. If no IMA group is configured for transmitting ATM cell streams, the cells are
distributed directly over E1/T1 links. You can, however, assign multiple IMA-E1/T1 interfaces to an IMA
group to form a higher-speed IMA interface link for ATM cell transmission.
1-4
For both IMA groups and the E1/T1 links outside the groups, you can create PVCs, specify service
types, and configure the related parameters. For more information (including the configuration of
PVCs), refer to ATM Configuration in the Access Volume.
Configuring an ATM E1/T1 Interface
Follow these steps to configure an ATM E1/T1 interface:
To do... Use the command... Remarks

Enter ATM E1/T1 interface interface atm

Required
view interface-number
Optional
Set the clock mode clock { master | slave }
The default is slave.
On an E1 frame-format { crc4-adm | Optional

interface no-crc4-adm } The default is CRC4 ADM.
Set the
framing format Optional
On a T1 frame-format { esf-adm |
interface sf-adm } The default is ESF ADM.
On an E1 Optional
code { ami | hdb3 }
interface The default is HDB3.
Set the line
coding format Optional
On an T1
code { ami | b8zs }
interface The default is B8ZS.
Optional
Enable scrambling scramble
Enabled by default
Optional
Set the cable length cable { long | short } The default is long, allowing
automatic cable length
adaption.
loopback { cell | local | Optional

Set the loopback mode
payload | remote } Disabled by default
Configure an IMA group See Configuring an IMA Group. Required
E1 configurations are supported on the IMA (E1) interface module and T1 configurations on the IMA
(T1) interface module.
The line coding formats for IMA-E1 interfaces and IMA-T1 interfaces are fixed to high density bipolar of
order 3 (HDB3) and bipolar with 8-zero substitution (B8ZS). They are not configurable.
1-5
ATM IMA-E1/T1 Interface Configuration Example
Network requirements
As shown in Figure 1-2, on the IMA-8E1 interface module of the router, create two IMA groups, each of
which is assigned two links; create two PVCs, setting their peer IP address to 10.10.10.10/24; and
configure them to support pseudo broadcast.
Network diagram
Figure 1-2 Network diagram for IMA-E1 interface configuration
Configuration procedure
# Assign two links to IMA group 1.

<Sysname> system-view
[Sysname] interface atm 1/0
[Sysname-Atm1/0] undo ip address
[Sysname-Atm1/0] ima ima-group 1
[Sysname-Atm1/0] interface atm 1/2
[Sysname-Atm1/2] quit
# Assign another two links to IMA group 2.

[Sysname-Atm1/3] interface atm 1/4
# Create PVCs and assign IP addresses for the IMA groups.

[Sysname] interface ima-group 1/1
[Sysname-Ima-group1/1] ip address 10.110.110.1 255.255.255.0
[Sysname-Ima-group1/1] pvc aaa 1/42
[Sysname-atm-pvc-Ima-group1/1-1/42-aaa] map ip 10.10.10.10 broadcast
[Sysname-atm-pvc-Ima-group1/1-1/42-aaa] quit
[Sysname-atm-pvc-Ima-group1/1] quit
[Sysname] interface ima-group 1/2
[Sysname-Ima-group1/2] ip address 10.110.120.1 255.255.255.0
[Sysname-Ima-group1/2] pvc bbb 1/92
[Sysname-atm-pvc-Ima-group1/2-1/92-bbb] map ip 10.10.10.10 broadcast
1-6
Troubleshooting ATM IMA-E1/T1 Interfaces
You can start troubleshooting an ATM interface by testing network connectivity using the ping
command or the extended ping command. In an extended ping command, you can specify some
options in the IP header. For more information on the use of the ping command, refer to System
Maintaining and Debugging Configuration in the System Volume.
If the interface cannot be pinged, check whether:
z The interface is down.
z The AAL5 encapsulation type of the PVC is incorrect.
ATM E3/T3 Interface Configuration

z Overview
z Configuring an ATM E3/T3 Interface
Overview
This section covers only the physical configurations of the ATM E3/T3 interface. For more information
about how to configure ATM (including PVCs), refer to ATM Configuration in the Access Volume.
Configuring an ATM E3/T3 Interface
Follow these steps to configure an ATM E3/T3 interface:

Enter ATM E3/T3 interface interface atm
Required
Optional
frame-format Optional
On an ATM
{ g751-adm | g751-plcp |
E3 interface The default is the G.751 PLCP format.
Set the g832-adm }
framing format frame-format { cbit-adm
On an ATM Optional
| cbit-plcp | m23-adm |
T3 interface The default is the C-bit PLCP format.
m23-plcp }
Optional
Set the cable length cable { long | short }
The default is short haul.
Optional
Configure scrambling scramble
Enabled by default

payload | remote } Disabled by default
1-7
E3 configurations are supported on the ATM(E3) interface module and T3 configurations on the
ATM(T3) interface module.
ATM OC-3c/STM-1 Interface Configuration

z Overview
z Configuring an ATM OC-3c/STM-1 Interface
Overview
This section covers only the physical configurations of the interface. For more information about how to
configure ATM (including PVCs), refer to ATM Configuration in the Access Volume.
Configuring an ATM OC-3c/STM-1 Interface
Follow these steps to configure an ATM OC-3c/STM-1 interface:

Enter ATM OC-3c/STM-1 interface atm
Required
Optional
Optional
Set the framing format frame-format { sdh | sonet } The default is the SDH STM-1
format.
Optional
Enable scrambling scramble
Enabled by default

remote } Disabled by default
Set the SD (signal Optional
degradation) threshold and
threshold { sd | sf } value By default, the SD threshold is
the SF (signal failure)
threshold 10e-6 and the SF threshold is 10e-3.
ADSL Interface Configuration

z Overview
z Configuring an ADSL Interface
z Upgrading ADSL2+ Card Software
1-8
Overview
ADSL Technologies
Asymmetric Digital Subscriber Line (ADSL) is an asymmetric transmission technology that implements
high-speed data transmission over twisted-pair copper wire by using unused high frequency ranges in
the regular telephone line with different modulation method. Normally, in the uplink band of 26 kHz to
138 kHz, ADSL can provide transmission rates up to 640 kbps (uplink) and in the downlink band of 138
kHz to 1.104 MHz, it provides transmission rates up to 8 Mbps (downlink).
Some latest ADSL technologies, however, can provide faster transmission rates by improving
modulation rate, coding gain, initialization state machine, by reducing frame head overhead, and by
using enhanced signal processing methods. For example, given the same bands, ADSL2 can provide
uplink transmission rates up to 1024 kbps and downlink transmission rates up to 12 Mbps. By
expanding the downlink band from 1.104 MHz to 2.208 MHz, ADSL2+ can even provide a downlink rate
as fast as 24 Mbps.
The transmission speed of ADSL is susceptible to transmission distance and line quality. While
increased transmission distance means decreased line quality and transmission rate, decreased
transmission distance means the contrary. When setting up a link, ADSL can automatically tune the
speed taking into consideration actual line conditions such as distance and noise.
Two types of ADSL modules/cards are available: ADSL over POTS and ADSL over ISDN (ADSL-I).
Typical network topology for ADSL routers
The following figure shows a typical network topology for routers with ADSL interfaces, where:
z DSLAM at the central office end works as the central office (CO) equipment.
z The router works as the customer premises equipment (CPE).
Figure 1-3 Typical network topology for an ADSL router
Splitter
Line ADSL ADSL Eth
DSLAM Phone ADSL Router

Hub
Phone Server Host A Host B
Line activation and deactivation
Before transmitting services, the CPE must activate the line. This is done through handshake training
and information exchange between the CO equipment and the CPE.
A typical activation process may last 30 seconds, beginning with line negotiation until the line comes up.
During this process, the two parties examine line distance and conditions against the line configuration
template (which defines the ADSL criteria, channel mode, uplink and downlink speeds, and noise
tolerance) and attempts to reach an agreement. If the activation succeeds, a communication
connection is set up between the two parties. When negotiating connection parameters during the line
1-9
activation, the CO equipment plays a master role to provide and decide values for most parameters,
while the CPE a slave role to accept them.
Contrary to activation, deactivation tears down the communication connection between the two parties.
The router tests the performance of the line regularly. Once it finds out that the line performance is
deteriorating, it automatically deactivates, retrains, and reactivates the line.
As ADSL transmission speed depends on distance and line quality heavily, make sure regular twisted
pairs are used and the cables are well connected when connecting ADSL interfaces.
This section covers only the physical configurations of the ADSL interface. For more information about
how to configure ATM (including PVCs), refer to ATM Configuration in the Access Volume.
Configuring an ADSL Interface
Follow these steps to configure an ADSL interface:

interface atm
Enter ATM interface view Required
interface-number
Optional
Activate the ADSL interface activate
The interface is active by default.
adsl standard { auto | Optional
Configure the ADSL interface
g9923 | g9925 | gdmt |
standard The default is auto sensing.
glite | t1413 }
Set the transmit power adsl tx-attenuation Optional

attenuation value attenuation 0 by default
To have the adsl standard command take effect, you need to re-activate the interface either by
performing the shutdown and undo shutdown commands or the activate and undo activate
commands.
Upgrading ADSL2+ Card Software
The upgradable software includes Boot ROM and card software. You first need to load the new
software by FTP or some other means to the flash memory or the CF card on your device. Before
performing an upgrade, you need to shut down the interface with the shutdown command if the
interface is up. After completing the upgrade, you need to bring the interface up with the undo
shutdown command.
Follow these steps to upgrade ADSL2+ card software:
1-10
interface atm
interface-number
Optional
Shut down the interface shutdown Skip this step if the interface is already
down.
Quit to user view quit

Required
Only distributed devices support the slot
bootrom update file slot-no-list option.
file-url slot slot-no-list
Upgrade software [ subslot The subslot subslot-no-list option is not
subslot-no-list ] [ all | available if the device does not support
part ] sub-card-level maintenance.
The highest slot number and the highest
sub-slot number vary with device models.
interface atm
Enter ATM interface view
interface-number
Bring the interface up undo shutdown Required
When executing the bootrom update file command, do not use the all option unless absolutely
necessary; use the part option instead. If you use the all option, you will find it hard to roll back to the
old version once the upgrade fails.
G.SHDSL Interface Configuration

z Overview
z Configuring a G.SHDSL Interface
Overview
G. single-pair high-speed digital subscriber line (G.SHDSL) is a symmetric transmission technology that
implements high-speed data transmission over the twisted-pair copper wire by making use of the
unused high frequency ranges with different modulation methods. So far, two types of G.SHDSL are
supported: two-wire and four-wire. Two-wire G.SHDSL can provide transmission rates up to 2.312
Mbps while four-wire G.SHDSL can provide transmission rates up to 4.624 Mbps.
The transmission speed of G.SHDSL is susceptible to transmission distance and line quality. While
increased transmission distance means decreased line quality and transmission rate, decreased
1-11
transmission distance means the contrary. When setting up a link, G. SHDSL can automatically tune the
speed taking into consideration the actual line conditions such as distance and noise.
For the networking topology for the routers with G.SHDSL interfaces, refer to that for the routers with
ADSL interfaces. But note that G.SHDSL interface requires no splitter.
For a typical network topology for routers with G.SHDSL interfaces, see Figure 1-3. You should note
that unlike ADSL, G.SHDSL does not use the splitter.
This section covers only the physical configurations of the G.SHDSL interface. For information about
configuring ATM (including PVCs), refer to ATM Configuration in the Access Volume.
Configuring a G.SHDSL Interface
Follow these steps to configure a G.SHDSL interface:

interface atm
interface-number
Activate the G.SHDSL Optional

activate
interface The interface is active by default.
Set the G.SHDSL Optional

shdsl annex { a | b }
interface standard Annex B is adopted by default.
shdsl wire { 2 | Optional

4-auto-enhanced | 4-enhanced mode by default
Set the wiring mode
4-enhanced | This command is available only if the
4-standard } interface supports four-wire G.SHDSL.
Set the interface operating shdsl mode { co | Optional

mode cpe } CPE by default
Optional
The default is auto-negotiation mode for the
shdsl rate { auto | two-wire G.SHDSL interface and 2.312
Set the single-pair rate
rate } Mbps for the single-pair interface rate of the
four-wire G.SHDSL interface (four-wire
G.SHDSL interface rate is 4.624 Mbps).
shdsl snr-margin
[ current Optional
Set a target margin to the
current-margin-value ] By default, current-margin-value is set to 2,
SNR
[ snext and snext-margin-value is set to 0.
snext-margin-value ]
shdsl psd Optional

Set the PSD mode { asymmetry |
symmetry } The default is symmetry.
Shut down the idle G.SHDSL interfaces to prevent their lines from consuming system resources.
1-12
Displaying and Maintaining ATM and DSL Interfaces
Display the configuration and
display interface atm
state of a specified or all ATM Available in any view
[ interface-number ]
or DSL interfaces
display dsl configuration

Display the actual configuration
interface atm Available in any view
of a DSL line
interface-number
Display the state information of display dsl status interface
Available in any view
a DSL line atm interface-number
Display DSL version
display dsl version interface
information and available Available in any view
atm interface-number
capabilities
display interface ima-group
state about a specified or all Available in any view
[ group-interfacenumber ]
IMA group interfaces
Clear the statistics about all
reset atm interface [ atm
PVCs on the specified ATM Available in user view
interface-number ]
interface
For those physical interfaces that are not connected to cables, shut down them using the shutdown
command to avoid anomalies resulted from interference.
Troubleshooting
z Troubleshooting ATM Interfaces
z Troubleshooting DSL Interfaces
Troubleshooting ATM Interfaces
When diagnosing ATM interface problems, first test the interface with the ping command or the
extended ping command.
The ping command can test network connectivity. Extended ping command can be used to specify
some options in the IP header in addition to that function. For more information about the ping
command, see System Maintaining and Debugging Configuration in the System Volume.
If the interface cannot be pinged, check whether:
z The interface is down, which causes missing of its route in the routing table.
z The AAL5 encapsulation of PVC is incorrect (for 155 Mbps ATM interfaces only).
1-13
Troubleshooting DSL Interfaces
Improper line operation is one of the faults that you may encounter in DSL applications. Such a fault is
likely to occur on whichever devices or nodes in the hierarchical broadband network architecture. It is
probably caused by the CPE device, copper wire, splitter, DSL port on DSLAM, or even the broadband
access server. For this reason, you should segment the network to locate the problem. Generally,
DSLAM provides you with abundant fault isolation methods and a complete guide, which are however,
beyond the scope of this manual.
On the CPE, you may do the following when the problem occurs:
1) Read the LEDs for the DSL interface card
When the DSL line is training, the LINK LED blinks. After the activation succeeds, the LINK LED which
should otherwise be OFF lights and stays ON. The Activity LED blinks when data is being transmitted
on the line.
2) Display the DSL state information with the display dsl status command
The State of driver/chipsets field provides information on interface and transceiver states.
Common interface states include Activating, Active, Startupping, Deactive, and Test Mode.
Common transceiver states include Idle, Data Mode, HandShaking, and Training.
3) Perform the debugging physical command to view details about activation, such as sending of
the activate command, activation timeout, training process, and activation success.
4) If line activation attempts always fail, check that the line is securely connected and functioning
normally.
5) If bit error rate is high or interference happens too often, reset the interface with the
shutdown/undo shutdown command or reboot the device and reconnect the line. If the problem
is still there, make an overall line condition and environment check.
1-14
Table of Contents
1 CPOS Interface Configuration1-1

Overview 1-1
SONET/SDH1-1
SDH Frame Structure 1-2
Terms1-2
Multiplexing E1/T1 Channels to Form STM-1 1-3
Calculating E1/T1 Channel Sequence Numbers1-3
Overhead Byte1-4
CPOS Interface Application Scenario 1-5
Configuring a CPOS Interface 1-6
Configuring an E1 Channel1-7
Configuring a T1 Channel 1-8
Displaying and Maintaining CPOS Interfaces1-9
CPOS Interface Configuration Example 1-9
Network Requirements 1-9
Network Diagram1-10
Configuration Procedure1-10
Troubleshooting CPOS Interfaces 1-11
Interface Physical Status is UP, Link Protocol Status is DOWN, and Loopback is Detected 1-11
i
1 CPOS Interface Configuration
When configuring CPOS interfaces, go to these sections for information you are interested in:
z Overview
z Configuring a CPOS Interface
z Configuring an E1 Channel
z Configuring a T1 Channel
z Displaying and Maintaining CPOS Interfaces
z Displaying and Maintaining CPOS Interfaces
z CPOS Interface Configuration Example
z Troubleshooting CPOS Interfaces
Overview
z SONET/SDH
z SDH Frame Structure
z Terms
z Multiplexing E1/T1 Channels to Form STM-1
z Calculating E1/T1 Channel Sequence Numbers
z Overhead Byte
z CPOS Interface Application Scenario
SONET/SDH
Synchronous Optical Network (SONET), a synchronous transmission system defined by ANSI, is an

international standard transmission protocol. It adopts optical transmission where transmission rates
form a sequence of STM-1 (155 Mbps), STM-4c (622 Mbps) and STM-16c/STM-16 (2.5 Gbps), each
four times the immediate lower level. Because signals are synchronous, SDH can multiplex multiple
signals conveniently.
Synchronous digital hierarchy (SDH), defined by CCITT (todays ITU-T), uses a SONET rate subset.
1-1
SDH Frame Structure
In SDH, adoption of synchronous multiplexing and flexible mapping allows you to add/drop low-speed
tributary signals from SDH signal without large amount of multiplexing/demultiplexing devices. This
reduces signal attenuation and device investment.
Low-speed tributary signals are called channels when they are multiplexed to form SDH signals. CPOS,
the channelized POS interface, makes full use of SDH to provide precise bandwidth division, reduce
the number of low-speed physical interfaces on devices, enhance their redistribution capacity, and
improve the access capacity of dedicated lines.
To understand these features, you should first know the frame structure of SDH signal STM-N.
Low-speed tributary signals should distribute in one frame regularly and evenly for the convenience of
adding/dropping them in high-speed signal. ITU-T specifies that STM-N frames adopt the structure of
rectangle blocks in bytes, as illustrated in the following figure:
Figure 1-1 STM-N frame structure
9 x 270 x N (bytes)
1 Regenerator
2 section
3 overhead
4 AU-PTR
5 Payload
6 Multiplex
7 section
8 overhead
9
9xN 261 x N
STM-N is a rectangle-block frame structure of 9 rows x 270 x N columns, where the N in STM-N equals
the N columns. N takes the value 1, 4, 16, and so on, indicating the number of STM-1 signals that form
SDH signal.
The STM-N frame structure consists of three parts: section overhead (SOH), which includes
regenerator section overhead (RSOH) and multiplex section overhead (MSOH); administration unit
pointer (AU-PTR); and payload. AU-PTR is the pointer that indicates the location of the first byte of
payload in an STM-N frame so that the receiving end can correctly extract payload.
Terms
z Multiplex unit: A basic SDH multiplex unit includes multiple containers (C-n), virtual containers
(VC-n), tributary units (TU-n), tributary unit groups (TUG-n), administrative units (AU-n) and
administrative unit groups (AUG-n), where n is the hierarchical sequence number of unit level.
z Container: Information structure unit that carries service signals at different rates. G.709 defines
the criteria for five standard containers: C-11, C-12, C-2, C-3 and C-4.
z Virtual container (VC): Information structure unit supporting channel layer connection of SDH. It
terminates an SDH channel. VC is divided into lower-order and higher-order VCs. VC-4 and VC-3
in AU-3 are higher-order virtual containers.
1-2
z Tributary unit (TU) and tributary unit group (TUG): TU is the information structure that provides
adaptation between higher-order and lower-order channel layers. TUG is a set of one or more TUs
whose location is fixed in higher-order VC payload.
z Administrative unit (AU) and administrative unit group (AUG): AU is the information structure that
provides adaptation between higher-order channel layer and multiplex section layer. AUG is a set
of one or more AUs that have fixed location in the payload of STM-N.
Multiplexing E1/T1 Channels to Form STM-1
In SDH multiplexing recommended by G.709, there is more than one path for a valid payload to be
multiplexed to form STM-N. The following figure illustrates the multiplexing process from E1 and T1 to
STM-1.
Figure 1-2 Process of multiplexing E1 channels to form STM-1
Figure 1-3 Process of multiplexing T1 channels to form STM-1
In actual applications, different countries and regions may adopt different multiplexing structures. To
ensure interoperability, the multiplex mode command is provided on CPOS interfaces. This allows
you to select the AU-3 or AU-4 multiplexing structure.
Calculating E1/T1 Channel Sequence Numbers
Since CPOS interfaces adopt the byte interleaved multiplexing mode, the lower-order VCs are not
arranged in order in a higher-order VC. To understand how TU numbers are calculated, see the
following example where E1 channels are multiplexed to form STM-1 through the AU-4.
As shown in Figure 1-2, when the AU-4 path is used, the multiplexing structure for 2 Mbps is 3-7-3. The
formula for calculating the TU-12 sequence numbers of different locations in the same VC-4 is as
follows:
1-3
Sequence number of TU-12 = TUG-3 number + (TUG-2 number 1) x 3 + (TU-12 Number 1) x 21
The two TU-12s are adjacent to each other, if they have the same TUG-3 number and TUG-2 number
but different TU-12 numbers with a discrepancy of 1.
The numbers in the aforementioned formula refer to the location numbers in a VC-4 frame. TUG-3 can
be numbered in the range 1 to 3; TUG-2 in the range 1 to 7 and TU-12 in the range 1 to 3. TU-12
numbers indicate the order in which the 63 TU-12s in a VC-4 frame are multiplexed, that is, E1 channel
numbers.
Figure 1-4 Order of TUG-3s, TUG-2s, and TU-12s in a VC-4 frame
TU-12 1
1 1
VC-4 TUG-3 TUG-2 TU-12 2
TU-12 3
TU-12 1
2
TUG-2 TU-12 2
.
TU-12 3
2
.
TUG-3
. TU-12 1
7
TUG-2 TU-12 2
3
TUG-3 TU-12 3
You can calculate TU-12 numbers in the same way when the AU-3 path is used.
When 63 E1 channels or 84 T1 channels are configured on a CPOS interface, you can reference E1 or
T1 channels by referencing the numbers in the range 1 to 63 or 1 to 84. When connecting your device
to channelized STM-1 interfaces on devices of other vendors, you should consider the possible
numbering differences due to different channel referencing approaches.
Overhead Byte
SDH provides layered monitoring and management of precise division.

It provides monitoring at section and channel levels, where sections are subdivided into regenerator
and multiplex sections, and channels are subdivided into higher-order and lower-order paths. These
monitoring functions are implemented using overhead bytes.
SDH provides a variety of overhead bytes, but only those involved in CPOS configuration are
discussed in this section. For more information about overhead bytes, refer to related books.
z SOH
1-4
Section overhead (SOH) consists of regenerator section overhead (RSOH) and multiplex section
overhead (MSOH).
The regeneration section trace message J0 is included in RSOH to send the section access point
identifier repeatedly. Based on the identifier, the receiver can make sure that it is in continuous
connection with the sender. This byte can be any character in the network of the same operator. If
networks of two operators are involved, however, the sending and receiving devices at network borders
must use the same J0 byte. With the J0 byte, operators can detect and troubleshoot faults in advance
or use less time to recover networks.
z POH
The payload of STM-N frame includes path overhead (POH), which monitors low-speed tributary
signals.
SOH monitors the section layer, while POH monitors the path layer. POH is divided into higher-order
path overhead and lower-order path overhead.
Higher-order path overhead monitors paths at the VC-4/VC-3 level.
Similar to the J0 byte, the higher-order VC-N path trace byte J1 is included in the higher-order path
overhead to send the higher-order path access point identifier repeatedly. Based on the identifier, the
receiving end of the path can make sure that it is in continuous connection with the specified sending
end. The J1 byte at the receiving and transmission ends should be matched.
The path signal label byte C2 is also included in the higher-order path overhead to indicate the
multiplexing structure of VC frames and the property of payload, for instance, whether the path is
carrying services, what type of services are carried, and how they are mapped. The sender and
receiver must use the same C2 byte.
CPOS Interface Application Scenario
CPOS is used to enhance the capability of a device in low-speed access redistribution. In aggregating
multiple E1/T1 channels, STM-1 CPOS is especially suitable.
At present, some government agencies and enterprises use low-end and mid-range devices to access
transmission networks through E1/T1 leased lines. Users who require bandwidth between E1 and T3
(44 Mbps), data centers for example, lease multiple E1/T1 lines.
The bandwidth of all these users is aggregated to one or more channelized POS interfaces through a
transmission network, and then connected to a high-end device where the low-end devices are
uniquely identified by timeslots.
In actual applications, the connection between these low-end devices and the channelized POS
interfaces likely involves more than one transmission network and as such, may require relay. This is
similar to the scenario where low-end devices are connected to a high-end device through one or
multiple E1/T1 leased lines.
1-5
Figure 1-5 Network diagram for a CPOS application
Transmission
network
Router A
N2M
E1
Access network
N64K N64K
N64K
Configuring a CPOS Interface

Follow these steps to configure a CPOS interface:

Enter CPOS interface view controller cpos cpos-number Required
Optional
Set the framing format frame-format { sdh | sonet }
The default is SDH.
Optional
Optional
Set the loopback mode loopback { local | remote }
Disabled by default
Optional
Configure the AUG multiplexing
multiplex mode { au-3 | au-4 } Available only in SDH framing.
mode
The default is AU-4.
Optional
Configuring the SOH and flag { j0 j0-string | j1 j1-string |
higher-order path overhead c2 c2-value | s1 s1-value | s1s0 The default value and value
bytes s1s0-value } range of each parameter in this
command vary by device.
Optional
Shut down the CPOS interface shutdown By default, a CPOS interface is
up.
1-6
Optional
Set the signal degrade (SD)
threshold and the signal fail threshold { sd | sf } value The SD threshold defaults to
(SF) threshold 10e-6. The SF threshold
defaults to 10e-3.
Configure E1 or T1 channel See Configuring an E1 Channel
Optional
attributes or Configuring a T1 Channel.
z E1 configuration is supported on the CPOS(E) interface module while T1 configuration is

supported on the T1 CPOS (T) interface module.
z For physical interfaces that are not connected to cables, shut down them with the shutdown
command to avoid anomalies resulting from interference.
z As the shutdown command can disable an interface, use it with caution.
Configuring an E1 Channel
Follow these steps to configure an E1 channel:


e1 e1-number set Optional
Set the E1 framing format frame-format { crc4 |
no-crc4 } The default is no-CRC4.
e1 e1-number set clock Optional

Set the clock mode for E1
{ master | slave } The default is slave.
e1 e1-number set loopback Optional

Set the loopback mode for E1
{ local | payload | remote } Disabled by default
e1 e1-number set flag c2

Optional
c2-value
Set the overhead bytes for E1 By default, C2 is set to 0x02
e1 e1-number set flag j2 { sdh
and J2 is cyclic null.
| sonet } j2-string
Configure E1 Required
to operate in
e1 e1-number unframed The default is channelized
unframed
mode mode.
Configure the
E1 operating Optional
mode (in Configure E1
undo e1 e1-number unframed The default is channelized
either to operate in
channelized mode
approach)
mode and set Required
timeslot e1 e1-number channel-set
bundling set-number timeslot-list range Timeslot bundling is disabled
by default.
1-7
Shut down the specified E1 Optional

e1 e1-number shutdown
channel By default, an E1 channel is up.
E1 configuration is supported on the CPOS (E) interface module.
Configuring a T1 Channel
Follow these steps to configure a T1 channel:

t1 t1-number set frame-format Optional

Set the T1 framing format
{ esf | sf } The default is ESF.
t1 t1-number set clock Optional

Set the clock mode for T1
{ master | slave } The default is slave.
Set the loopback mode for t1 t1-number set loopback Optional

T1 { local | payload | remote } Disabled by default
t1 t1-number set flag c2

Optional
Set the overhead bytes for c2-value
T1 By default, C2 is set to 0x02 and
t1 t1-number set flag j2 { sdh |
J2 is cyclic null.
sonet } j2-string
Configure T1 to
operate in Required
t1 t1-number unframed
unframed The default is channelized mode.
Configure mode
the T1
operating Optional
mode (in undo t1 t1-number unframed
Configure T1 to The default is channelized mode.
either operate in
approach) channelized Required
t1 t1-number channel-set
mode set-number timeslot-list range Timeslot bundling is disabled by
[ speed { 56k | 64k } ] default.
Shut down the specified T1 Optional

t1 t1-number shutdown
channel By default, a T1 channel is up.
T1 configuration is supported on the CPOS (T) interface module.
1-8
Displaying and Maintaining CPOS Interfaces
Display information about
display controller cpos
channels on a specified or all Available in any view
[ cpos-number ]
CPOS interfaces
Display information about a
specified E1 channel on a Available in any view
cpos-number e1 e1-number
CPOS interface
specified T1 channel on a Available in any view
cpos-number t1 t1-number
CPOS interface
Display information about a display interface serial
serial interface formed by interface-number/channel-num Available in any view
E1/T1 channels ber:set-number
Shut down the CPOS physical Available in CPOS interface
shutdown
interface view
Bring the CPOS physical Available in CPOS interface
undo shutdown
interface up view
Available in CPOS interface
Shut down an E1 channel e1 e1-number shutdown
view
Bring an E1 channel up undo e1 e1-number shutdown
view
Shut down a T1 channel t1 t1-number shutdown
view
Bring a T1 channel up undo t1 t1-number shutdown
view
Clear the controller counter of a reset counters controller cpos
Available in user view
CPOS interface interface-number
CPOS Interface Configuration Example

Network Requirements
Branch nodes Router B through Router H are attached to the central node Router A. Each branch node
is uplinked to Router A through an E1 link aggregated through a CPOS interface. After expanding
Router B, you should add one more E1 link because an E1 link cannot satisfy the requirements. Bind
the two E1 links through an MP-group interface.
1-9
Network Diagram
Figure 1-6 Network diagram for CPOS interface configuration
Router H
E1
Router A
SDH
CPOS2/0
E1
Router B
Configuration Procedure
# Configure Router A.
The following part only provides the procedure for CPOS interface and E1 interface configuration.
Configuration procedure for the other services is not provided.
# Configure the clock mode of CPOS 1/0 and its channelized E1 interfaces E1 1 and E1 2 as master.
<RouterA> system-view
[RouterA] controller cpos 2/0
[RouterA-Cpos2/0] clock master
[RouterA-Cpos2/0] e1 1 unframed
[RouterA-Cpos2/0] e1 1 set clock master
[RouterA-Cpos2/0] e1 2 unframed
[RouterA-Cpos2/0] e1 2 set clock master
# Create MP-group 1 and assign an IP address for it.

[RouterA] interface mp-group 1
[RouterA-Mp-group1] ip address 10.1.1.1 30
[RouterA-Mp-group1] quit
# Configure Serial 2/0/1:0.

[RouterA] interface serial2/0/1:0
[RouterA-Serial2/0/1:0] ppp mp mp-group 1
[RouterA-Serial2/0/1:0] quit
[RouterA] interface serial2/0/2:0
[RouterA-Serial2/0/2:0] ppp mp mp-group 1
[RouterA-Serial2/0/2:0] quit
# Configure Router B.
The configuration on Router B is similar to that of other branch nodes.
<RouterB> system-view
[RouterB] controller e1 2/0/1
[RouterB-E2/0/1] using e1
[RouterB-E2/0/1] quit
[RouterB] controller e1 2/0/2
1-10
[RouterB-E2/0/2] using e1
[RouterB-E2/0/2] quit
# Create MP-group 1 and assign an IP address for it.

[RouterB] interface mp-group 1
[RouterB-Mp-group1] quit
# Configure Serial 2/0/1:0 and Serial2/0/2:0.

[RouterB] interface serial2/0/1:0
[RouterB-Serial2/0/1:0] ppp mp mp-group 1
[RouterB-Serial2/0/1:0] quit
[RouterB] interface serial2/0/2:0
[RouterB-Serial2/0/2:0] ppp mp mp-group 1
[RouterB-Serial2/0/2:0] quit
You can use the display interface serial 2/0/1:0 command, the display interface mp-group 1
command, and the display ppp mp command to display the connection status, and use the ping
command to check whether the network is reachable.
Troubleshooting CPOS Interfaces

Interface Physical Status is UP, Link Protocol Status is DOWN, and Loopback is
Detected
Symptom:
Connect the CPOS interface of a device to that of another vendor through SDH, bundle E1 channels on
the interface to form a serial interface and encapsulate it with PPP.
Use the display interface serial command to check information on interface status. It shows that the
physical state of the interface is UP, but the link protocol is DOWN; and loopback, though not
configured, is detected on some interfaces.
Solution:
The fault is very likely caused if the multiplex unit configurations on the SDH transmission device
mismatch the E1 channel numbers on the CPOS interface on your device. This can result in timeslot
inconsistency at the two ends of transmission and as such, PPP negotiation failures and LCP
anomalies.
Besides, if an idle timeslot on a loopback serial interface on the transmission device is used in
transmission, the information that loopback is detected is displayed. Use the debugging ppp lcp error
command to check loopback information.
Follow these steps to solve the problem:
z Use the display controller cpos e1 command to view the multiplexing paths of the E1 channels
or calculate the multiplexing path as shown in Calculating E1/T1 Channel Sequence Numbers.
z Check the configurations on the transmission devices against the calculating result in the last step
to make sure the same E1 multiplexing path is configured.
1-11
Table of Contents
1 POS Interface Configuration 1-1

Overview 1-1
SONET/SDH1-1
POS 1-1
Configuring a POS Interface 1-2
Configuring a POS Interface 1-2
Switching the Interface Type 1-3
Displaying and Maintaining POS Interfaces1-3
POS Interface Configuration Example 1-4
Directly Connecting Routers Through POS Interfaces1-4
Connecting Routers Through POS Interfaces Across Frame Relay1-5
Troubleshooting POS Interfaces1-6
i
Description on feature support of the MSR series routers:
Feature MSR 20-1X MSR 20 MSR 30 MSR 50

Switching the
No No No No
interface type
1 POS Interface Configuration
When configuring POS interfaces, go to these sections for information you are interested in:
z Overview
z Configuring a POS Interface
z Displaying and Maintaining POS Interfaces
z POS Interface Configuration Example
z Troubleshooting POS Interfaces
Overview
z SONET/SDH
z POS
SONET/SDH
Synchronous Optical Network (SONET), a synchronous transmission system defined by ANSI, is an

international standard transmission protocol. It adopts optical transmission where transmission rates
form a sequence of STM-1 (155 Mbps), STM-4c (622 Mbps) and STM-16c/STM-16 (2.5 Gbps), each
four times the immediate lower level. Because signals are synchronous, SDH can multiplex multiple
signals conveniently.
Synchronous digital hierarchy (SDH), defined by CCITT (ITU-T at present), uses a SONET rate subset.
POS
Packet over SONET/SDH (POS) is a technology popular in WAN and MAN. It can support packet data
such as IP packets.
1-1
POS maps length-variable packets directly to SONET synchronous payloads and uses the SONET
physical layer transmission standard. It offers high-speed, reliable, and point-to-point data connectivity.
The POS interface on your device supports PPP, Frame Relay, and HDLC at the data link layer and IP
at the network layer. Its transmission rate can vary with devices.
Configuring a POS Interface

Before you configure the link layer and network layer protocols on a POS interface, you must configure
its physical parameters. In addition, to have the interface participate in backup, configure the backup
parameters; to set up firewall on the interface, configure packet filtering rules.
Configuring a POS Interface
Follow these steps to configure a POS interface:

interface pos
Enter POS interface view Required
interface-number
Optional
Optional
Set the CRC length crc { 16 | 32 }
The default is 32 bits.
Optional
Set the loopback mode loopback { local | remote }
Disabled by default
Optional
flag c2 flag-value
The default is hexadecimal 16 for C2.
Optional
Configure the overhead By default, SDH framing applies.
byte
flag { j0 | j1 } { sdh | sonet } In SDH framing, the defaults are null for
flag-value both J0 and J1.
In SONET framing, the defaults are
0x01 for J0 and null for J1.
frame-format { sdh | Optional

Set the framing format
sonet } The default is SDH.
Optional
Configure scrambling scramble
Enabled by default.
link-protocol { ppp | fr Optional
Set the link type [ nonstandard | ietf | mfr
interface-number ] | hdlc } The default is PPP.
Optional
Set the interface MTU mtu mtu MTU range and the default value vary
with device.
Optional
Set the SD/SF threshold
threshold { sd | sf } value The SD threshold defaults to 10e-6.
for the interface
The SF threshold defaults to 10e-3.
1-2
Configure the rate of the Optional

speed speed-value
interface The default varies by device.
Shut down the POS Optional

shutdown
interface By default, a POS interface is up.
For physical interfaces that are not connected to cables, shut down them with the shutdown command
to avoid anomalies resulting from interference. As the shutdown command can disable an interface,
use it with caution.
Switching the Interface Type
When you use super sub-cards in different circumstances, you can switch the interface type as
required.
Support for this command depends on the device model.
Follow these steps to switch the type of an interface:

Enter POS interface
Enter interface pos interface-number
view Required
interface
view Enter Layer-3 GE interface GigabitEthernet Use either command
Switch the interface type port-type switch interface-type Required
Displaying and Maintaining POS Interfaces

Display status and
display interface pos
configuration information about Available in any view
one or all POS interfaces
Display IP-related
display ip interface pos
configurations and statistics for Available in any view
interface-number
1-3
Display IPv6-related
display ipv6 interface pos
configurations and statistics for Available in any view
POS Interface Configuration Example

Directly Connecting Routers Through POS Interfaces
Use a pair of single mode optic fibers (respectively for receiving and sending data) to connect the POS
interfaces on Router A and Router B.
Encapsulate the interfaces with PPP.
Network diagram
Figure 1-1 Network diagram for connecting two POS interfaces through fiber
1) Configure Router A
# Configure interface POS 1/0, setting its physical parameters to defaults.
[RouterA] interface pos 1/0
[RouterA-Pos1/0] ip address 10.110.1.10 255.255.255.0
[RouterA-Pos1/0] link-protocol ppp
[RouterA-Pos1/0] mtu 1500
[RouterA-Pos1/0] shutdown
[RouterA-Pos1/0] undo shutdown
2) Configure Router B
# Configure interface POS 1/0.
[RouterB] interface pos 1/0
# Set the clock mode to master and other physical parameters to defaults.
[RouterB-Pos1/0] clock master
[RouterB-Pos1/0] ip address 10.110.1.11 255.255.255.0
[RouterB-Pos1/0] link-protocol ppp
[RouterB-Pos1/0] mtu 1500
[RouterB-Pos1/0] shutdown
[RouterB-Pos1/0] undo shutdown
You can check the interface connectivity between the POS interfaces with the display interface pos
command and test network connectivity with the ping command.
1-4
Connecting Routers Through POS Interfaces Across Frame Relay
Connect routers to a public Frame Relay network through POS interfaces. The routers are premise
equipment that work as DTE side of Frame Relay.
Router A uses Frame Relay sub-interfaces to connect Router B and Router C in different network
segments.
Network diagram
Figure 1-2 Network diagram for POS interface connection across Frame Relay
# Configure POS interface 1/0.
[RouterA-Pos1/0] clock slave
# Configure Frame Relay encapsulation on the interface.

[RouterA-Pos1/0] link-protocol fr
[RouterA-Pos1/0] fr interface-type dte
[RouterA-Pos1/0] quit
# Create sub-interface 1 on the interface.

[RouterA] interface pos 1/0.1
[RouterA-Pos1/0.1] ip address 10.10.10.1 255.255.255.0
[RouterA-Pos1/0.1] fr map ip 10.10.10.2 50
[RouterA-Pos1/0.1] mtu 1500
[RouterA-Pos1/0.1] quit
# Create sub-interface 2 on the interface.

[RouterA] interface pos 1/0.2
[RouterA-Pos1/0.2] ip address 20.10.10.1 255.255.255.0
[RouterA-Pos1/0.2] fr map ip 20.10.10.2 60
[RouterA-Pos1/0.2] mtu 1500
[RouterA-Pos1/0.2] quit
1-5
# Configure interface POS 1/0.
[RouterB-Pos1/0] clock slave
# Configure Frame Relay encapsulation on the interface.

[RouterB-Pos1/0] link-protocol fr
[RouterB-Pos1/0] fr interface-type dte
[RouterB-Pos1/0] ip address 10.10.10.2 255.255.255.0
[RouterB-Pos1/0] fr map ip 10.10.10.1 70
[RouterB-Pos1/0] mtu 1500
Follow the same way to configure Router C.

You can check interface connectivity with the display interface pos command and test network
connectivity with the ping command.
Troubleshooting POS Interfaces

Symptom 1:
The physical state of POS interface is down.
Solution:
z Check that the transmitting and receiving fibers-optic are correctly connected to the POS interface.
If you connect the two ends of a fiber-optic to the transmitting end and the receiving end of the
same POS interface, you can see the message loopback detected on the screen when executing
the display interface command even if you have not enabled loopback.
z If the two routers are directly connected back to back, check that the internal clock is enabled on
either of the two POS interfaces. POS interfaces use line clock by default; but when two routers are
directly connected, one side must use the internal clock.
Symptom 2: The physical layer is up but the link is down.
Solution:
Check that:
z The configurations of clock, scrambling and other physical parameters are consistent on the
connected two POS interfaces.
z The same link layer protocol is configured on two sides.
z Both ends are assigned IP addresses.
Symptom 3:
A great amount of IP packets are dropped.
Solution:
Check that:
z The correct clock mode is configured on the POS interface. If not, enormous amount of CRC errors
can be generated.
z Check that the MTU configuration is appropriate.
1-6
Table of Contents
1 Ethernet Interface Configuration 1-2

Ethernet Interface Overview 1-2
General Ethernet Interface Configuration 1-2
Combo Port Configuration 1-2
Configuring LAN/WAN Mode for a 10 GE Interface 1-4
Basic Ethernet Interface/Subinterface Configuration 1-5
Configuring Flow Control on an Ethernet Interface 1-6
Configuring the Suppression Time of Physical-Link-State Change on an Ethernet Interface 1-7
Configuring Loopback Testing on an Ethernet Interface1-7
Configuring the Operating Mode of an Ethernet Interface 1-8
Configuring a Layer 2 Ethernet Interface/Subinterface1-9
Layer 2 Ethernet Interface/Subinterface Configuration Task List 1-9
Configuring a Port Group1-10
Configuring an Auto-negotiation Transmission Rate1-10
Configuring Storm Suppression 1-11
Setting the Interval for Collecting Ethernet Interface Statistics 1-14
Enabling Forwarding of Jumbo Frames 1-14
Enabling Loopback Detection on an Ethernet Interface1-15
Configuring the Cable Type for an Ethernet Interface1-16
Testing the Cable on an Ethernet Interface1-17
Testing an Ethernet Interface 1-17
Resetting an Ethernet Interface/Subinterface 1-18
Configuring the Storm Constrain Function on an Ethernet Interface 1-18
Configuring a Layer 3 Ethernet Interface/Subinterface1-20
Layer 3 Ethernet Interface/Subinterface Configuration Task List 1-20
Setting the MTU for an Ethernet Interface/Subinterface 1-20
Configuring Link Layer State Change Suppression on an Ethernet Interface 1-20
Displaying and Maintaining an Ethernet Interface/Subinterface1-21
i

Layer 2 Ethernet subinterface No No No No
Single Combo port Yes Yes Yes Yes
Double Combo port No No Yes Yes
10GE interface No No No No
Flow control on an Ethernet interface Yes Yes Yes Yes
Configuring the suppression time of
physical-link-state change on an Ethernet No No No No
interface
Loopback testing on an Ethernet interface Yes Yes Yes Yes
Configuring the operation mode of an Ethernet
Yes Yes Yes Yes
interface
Port group Yes Yes Yes Yes
Storm suppression Yes Yes Yes Yes
Setting the interval for collecting Ethernet
Yes Yes Yes Yes
interface statistics
Enabling forwarding of jumbo frames No No No No
Enabling loopback detection on an Ethernet
Yes Yes Yes Yes
interface
Testing the cable on an Ethernet interface Yes Yes Yes Yes
Testing an Ethernet interface No No No No

Resetting an Ethernet interface No No No No
Configuring storm constrain on an Ethernet
No No No No
interface
1-1
1 Ethernet Interface Configuration
When configuring Ethernet interfaces, go to these sections for information you are interested in:
z Ethernet Interface Overview
z General Ethernet Interface Configuration
z Configuring a Layer 2 Ethernet Interface/Subinterface
z Configuring a Layer 3 Ethernet Interface/Subinterface
z Displaying and Maintaining an Ethernet Interface/Subinterface
Ethernet Interface Overview

Five types of Ethernet interfaces may be available on your device:
z Layer 2 Ethernet interfaces. They are physical interfaces operating on the data link layer for
forwarding Layer 2 protocol packets.
z Layer 3 Ethernet interfaces. They are physical interfaces operating on the network layer for routing
Layer 3 protocol packets. You can assign an IP address to a Layer 3 Ethernet interface.
z Layer 2/Layer 3 Ethernet interfaces. They are physical interfaces that can operate on both the data
link layer and the network layer. When operating on the data link layer, a Layer 2/Layer 3 Ethernet
interface acts as a Layer 2 Ethernet interface; when operating on the network layer, a Layer
2/Layer 3 Ethernet interface acts as a Layer 3 Ethernet interface.
z Layer 2 Ethernet subinterfaces. They are logical interfaces operating on the data link layer. They
are mainly used for inter-VLAN packet forwarding on firewall cards. The link type of a Layer 2
Ethernet subinterface is access, which cannot be changed. You can add a Layer 2 subinterface to
a VLAN in addition to performing the configurations described in this chapter on the subinterface.
For the related configuration, refer to VLAN Configuration in the Access Volume. You may create
Layer 2 Ethernet subinterfaces depending on the device.
z Layer 3 Ethernet subinterfaces. They are logical interfaces operating on the network layer. You can
assign an IP address to a Layer 3 Ethernet subinterface. A Layer 3 Ethernet subinterface only
sends and receives packets for a particular VLAN. By creating subinterfaces on a Layer 3 Ethernet
interface, you can enable the interface to carry packets for multiple VLANs.
General Ethernet Interface Configuration

This section describes the attributes and configurations common to Layer 2 and Layer 3 Ethernet
interfaces. For specific attributes, refer to related sections hereinafter.
Combo Port Configuration
The support for this feature varies with device models.
1-2
Introduction to Combo port
A Combo port can operate as either an optical port or an electrical port. Inside the device there is only
one forwarding interface. For a Combo port, the electrical port and the corresponding optical port are
TX-SFP multiplexed. You can specify a Combo port to operate as an electrical port or an optical port.
That is, a Combo port cannot operate as both an electrical port and an optical port simultaneously.
When one is enabled, the other is automatically disabled.
For ease of management, a Combo port can be categorized into one of the following two types:
z Single Combo port: the two Ethernet interfaces on the device panel correspond to only one
interface view, in which state switchover on the two interfaces can be realized. A single Combo port
can be a Layer 2 Ethernet interface or a Layer 3 Ethernet interface.
z Double Combo port: the two Ethernet interfaces on the device panel correspond to two interface
views. State switchover can be realized in users own interface view. A double Combo port can only
be a Layer 2 Ethernet interface.
Configuring Combo port state
Follow these steps to configure the state of a single Combo port:

interface interface-type
Enter Ethernet interface view
interface-number
Optional
Specify the state of a Combo combo enable { copper |
port fiber } By default, a Combo port
operates as an electrical port.
Follow these steps to configure the state of a double Combo port:

interface-number
Optional
By default, of the two ports in a Combo
Enable a specified double port, the one with a smaller port ID is
undo shutdown
Combo port enabled. It varies with devices as to
whether the enabled port is an optical
port or an electrical port.
In case of a double Combo port, only one interface (either the optical port or the electrical port) is active
at a time. That is, once the optical port is active, the electrical port will be inactive automatically, and vice
versa.
1-3
Configuring LAN/WAN Mode for a 10 GE Interface
The support for this command varies with device models.
Introduction to LAN/WAN mode
According to its physical characteristics, a 10 GigabitEthernet (10 GE) interface can operate in LAN or
WAN mode.
z LAN mode. 10 GE interfaces operating in LAN mode transfer Ethernet packets and are used to
connect Ethernets.
z WAN mode: 10 GE interfaces operating in WAN mode transfer Synchronous Digital Hierarchy
(SDH) packets and are used to connect SDH networks. They only support point-to-point packet
transfer.
A 10 GE interface operating in WAN mode encapsulates Ethernet packets as SDH frames, while a 10G
packet over SDH (POS) interface encapsulates PPP packets as SDH frames. Because the SDH frame
format of Ethernet packets is different from that of PPP packets, a 10 GE interface operating in WAN
mode cannot communicate with a 10G POS interface.
Introduction to J0/J1 overhead byte
SDH frames have diversified overhead bytes, which accomplish the operation and maintenance
functions such as hierarchical management of the transport network. J0 and J1 are used to provide
internetworking support between different countries, regions, or devices of different manufacturers.
The regenerator section trace byte J0 is usually set to a section access point identifier. The sending end
keeps connected with the receiving end by sending this byte repeatedly.
The path trace byte J1, usually set to a high-order path access point identifier, functions in a similar way
to keep connected with the receiving end of the path.
To ensure smooth communication, the J0 and J1 bytes should be matched respectively at the sending
and receiving ends. For details about SDH and SDH overhead bytes, refer to related documents.
Configure a 10 GE interface to operate in LAN/WAN mode
Follow these steps to configure a 10 GE interface to operate in LAN/WAN mode:

interface
Enter ten-GigabitEthernet
ten-gigabitethernet
interface view
interface-number
1-4
Optional
Configure a 10 GE interface to
port-mode { lan | wan } By default, a 10 GE interface
operate in LAN/WAN mode
operates in LAN mode.
Configure a value for J0/J1 Optional
bytes when the 10 GE
flag { j0 | j1 } sdh flag-value By default, the value of the J0/J1
interface operates in WAN
mode bytes is 0.
The flag command is applicable to 10 GE interfaces operating in WAN mode only.
Basic Ethernet Interface/Subinterface Configuration
Configuring an Ethernet interface
Three types of duplex modes are available to Ethernet interfaces:

z Full-duplex mode (full). Interfaces operating in this mode can send and receive packets
simultaneously.
z Half-duplex mode (half). Interfaces operating in this mode can either send or receive packets at a
given time.
z Auto-negotiation mode (auto). Interfaces operating in this mode determine their duplex mode
through auto-negotiation.
Similarly, if you configure the transmission rate for an Ethernet interface by using the speed command
with the auto keyword specified, the transmission rate is determined through auto-negotiation too. For a
100MB or Gigabit Layer 2 Ethernet interface, you can specify the transmission rate by its
auto-negotiation capacity. For details, refer to Configuring an Auto-negotiation Transmission Rate.
Follow these steps to configure an Ethernet interface:

interface-number
Optional
By default, the description of an
Set the description string description text interface is the interface name followed
by the interface string, Ethernet1/0
Interface for example.
Optional
Set the duplex mode duplex { auto | full | half }
auto by default.
Optional
speed { 10 | 100 | 1000 |
Set the transmission rate The default value of this command
auto }
varies with your device models.
1-5
Optional
By default, an Ethernet interface is in
Shut down the Ethernet
shutdown up state.
interface
To bring up an Ethernet interface, use
the undo shutdown command.
Support for keywords of the speed command by a Combo port varies with your device models.
Configuring an Ethernet subinterface
Follow these steps to configure an Ethernet subinterface:

Required
Create an Ethernet interface interface-type
subinterface interface-number.subnumber This command also leads you
to Ethernet subinterface view.
Optional
Set the description string of the By default, the description
description text string is interface index +
Ethernet subinterface
interface. For example,
Ethernet1/0.1 Interface.
Optional
Shut down the Ethernet
shutdown By default, an Ethernet
subinterface
subinterface is in up state.
Configuring Flow Control on an Ethernet Interface
When flow control is enabled on both sides, if traffic congestion occurs at the ingress interface, it will
send a Pause frame notifying the egress interface to temporarily suspend the sending of packets. The
egress interface is expected to stop sending any new packet when it receives the Pause frame. In this
way, flow control helps to avoid dropping of packets. Note that this will be possible only after flow control
is enabled on both the ingress and egress interfaces.
Follow these steps to enable flow control on an Ethernet interface:
1-6
interface-number
Required
Enable flow control flow-control
Disabled by default
Configuring the Suppression Time of Physical-Link-State Change on an Ethernet

Interface
An Ethernet interface operates in one of the two physical link states: up or down. During the
suppression time, physical-link-state changes will not be propagated to the system. Only after the
suppression time has elapsed will the system be notified of the physical-link-state changes by the
physical layer. This functionality reduces the extra overhead occurred due to frequent
physical-link-state changes within a short period of time.
Follow these steps to configure the suppression time of physical-link-state changes on an Ethernet
interface:

interface-number
Required
Configure the up/down The default suppression time of
suppression time of link-delay delay-time physical-link-state changes on
physical-link-state changes an Ethernet interface varies
with device models.
Configuring Loopback Testing on an Ethernet Interface
You can enable loopback testing to check whether the Ethernet interface functions properly. Note that
no data packets can be forwarded during the testing. Loopback testing falls into the following two
categories:
1-7
z Internal loopback testing, which is performed within switching chips to test the functions related to
the Ethernet interfaces.
z External loopback testing, which is used to test the hardware functions of an Ethernet interface. To
perform external loopback testing on an Ethernet interface, you need to install a loopback plug on
the Ethernet interface. In this case, packets sent from the interface are received by the same
interface.
Follow these steps to enable Ethernet interface loopback testing:

interface-number
Optional
Disabled by default.
Enable loopback testing loopback { external | internal } The support for the external
and the internal keywords
varies with device models.
z As for the internal loopback test and external loopback test, if an interface is down, only the former
is available on it; if the interface is shut down, both are unavailable.
z The speed, duplex, mdi, and shutdown commands are not applicable during loopback testing.
z With the loopback testing enabled, the Ethernet interface operates in full duplex mode. With the
loopback testing disabled, the original configurations will be restored.
Configuring the Operating Mode of an Ethernet Interface
According to the layer at which the device processes received data packets, Ethernet interfaces can
operate in bridge or route mode. For a device, some interfaces can operate only in bridge mode, some
can operate only in route mode, and others can operate in either bridge mode or route mode. This
command is only applicable to Ethernet interfaces whose operating mode can be changed.
Follow these steps to change the operating mode of an Ethernet interface:

interface-number
1-8
Change the operating mode of port link-mode { bridge |
Required
an Ethernet interface route }
After you change the operating mode of an Ethernet interface, all the settings of the Ethernet interface
are restored to their defaults.
Configuring a Layer 2 Ethernet Interface/Subinterface

Layer 2 Ethernet Interface/Subinterface Configuration Task List
Complete these tasks to configure an Ethernet interface operating in bridge mode:
Task Remarks
Optional
Configuring a Port Group
Applicable to Layer 2 Ethernet interfaces
Optional
Configuring an Auto-negotiation Transmission
Rate Applicable to 100MB or Gigabit Layer Ethernet
interfaces
Optional
Configuring Storm Suppression Applicable to Layer 2 Ethernet interfaces and
Ethernet subinterfaces
Setting the Interval for Collecting Ethernet Optional

Interface Statistics Applicable to Layer 2 Ethernet interfaces
Optional
Enabling Forwarding of Jumbo Frames
Enabling Loopback Detection on an Ethernet Optional

Interface Applicable to Layer 2 Ethernet interfaces
Configuring the Cable Type for an Ethernet Optional

Interface Applicable to Layer 2 Ethernet interfaces
Optional
Testing the Cable on an Ethernet Interface
Optional
Testing an Ethernet Interface
Optional
Resetting an Ethernet Interface/Subinterface Applicable to Layer 2 Ethernet interfaces and
Ethernet subinterfaces
Configuring the Storm Constrain Function on an Optional

Ethernet Interface Applicable to Layer 2 Ethernet interfaces
1-9
Configuring a Port Group
The support for this function varies with device models.
For certain functions, devices allow you to configure in different ways: you can either configure one
interface or multiple interfaces at a time. In port group view, the configuration you perform applies to all
ports in the port group.
A port group can be manually created. That is, you can add multiple Ethernet interfaces to a port group
manually.
You can configure the ports in a port group in batch. But you cannot display or save the configuration of
a port group itself. However, you can use the display current-configuration or display this command
to view the current configuration of each member port in a port group.
Follow these steps to enter port group view:

Enter manual port group port-group manual

Enter port view port-group-name
group view Enter aggregation port port-group aggregation

group view agg-id
Follow these steps to configure a manual port group:

Create a manual port group and enter port-group manual

Required
manual port group view port-group-name
Add Ethernet interfaces to the manual port
group-member interface-list Required
group
Configuring an Auto-negotiation Transmission Rate
Usually, the transmission rate on an Ethernet port is determined through negotiation with the peer end,
which can be any rate within the capacity range and therefore is beyond your control. With
auto-negotiation rate configured, you can enable the Ethernet interface to negotiate only part of the
transmission rates within its capacity.
1-10
Figure 1-1 An application diagram of auto-negotiation transmission rate
As shown in Figure 1-1, the network card transmission rate of the server group (Server 1, Server 2, and
Server 3) is 1000 Mbps, and the transmission rate at which the server group is connected to the
interface of an external network (GigabitEthernet1/4) is 1000 Mbps too. If you do not specify an
auto-negotiation transmission rate, the transmission rate on the interface through negotiation with the
servers is 1000 Mbps, which may cause congestion on the egress interface. To solve the problem, you
can specify the auto-negotiation transmission rate on GigabitEthernet 1/1, GigabitEthernet 1/2, and
GigabitEthernet 1/3 to 100 Mbps.
Follow these steps to configure an auto-negotiation transmission rate:

interface-number
Optional
Configure the auto-negotiation The default value of this
speed auto [ 10 | 100 | 1000 ] *
transmission rate range command varies with your
device models.
z This function is available for auto-negotiation-capable 100MB or Gigabit Ethernet interfaces only.
For a Combo port, only the electrical port supports this function.
z If you repeatedly use the speed and the speed auto commands to configure the transmission rate
on an interface, only the latest configuration takes effect.
Configuring Storm Suppression
You can use the following commands to suppress the broadcast, multicast, and unknown unicast traffic:
z In global configuration mode, the suppression ratio indicates the maximum broadcast, multicast or
unknown unicast traffic of the whole system that is allowed to pass. When the sum of broadcast,
multicast, or unknown unicast traffic over all interfaces of the system exceeds the threshold, the
system will discard the extra packets so that the broadcast, multicast, or unknown unicast traffic
ratio can drop below the limit to ensure that the network functions properly.
1-11
z In interface configuration mode, the suppression ratio indicates the maximum broadcast, multicast
or unknown unicast traffic that is allowed to pass through an interface. When the broadcast,
multicast, or unknown unicast traffic over the interface exceeds the threshold, the system will
discard the extra packets so that the broadcast, multicast or unknown unicast traffic ratio can drop
below the limit to ensure that the network functions properly.
z The support for this function varies with device models.

z Different device models support different configuration modes. Some support global configuration
mode, or interface configuration mode, and some support both.
z If a suppression ratio is set in global configuration mode or in interface configuration mode, the
suppression ratio which first satisfies the condition takes effect.
z The storm suppression ratio settings configured for an Ethernet interface may get invalid if you
enable the storm constrain for the interface. For information about the storm constrain function, see
Configuring the Storm Constrain Function on an Ethernet Interface.
Follow these steps to set the storm suppression ratios globally:

Optional
Set the broadcast storm broadcast-suppression By default, all broadcast traffic is
suppression ratio globally ratio allowed to pass through an interface,
that is, broadcast traffic is not
suppressed.
Optional
Set the multicast storm multicast-suppression By default, all multicast traffic is
suppression ratio globally ratio allowed to pass through an interface,
that is, multicast traffic is not
suppressed.
Optional
Set the unknown unicast By default, all unknown unicast traffic
storm suppression ratio unicast-suppression ratio is allowed to pass through an interface,
globally that is, unknown unicast traffic is not
suppressed.
Follow these steps to set storm suppression ratios for one or multiple Ethernet interfaces:

Enter Use either command.
Enter Ethernet interface interface-type
Ethernet If configured in Ethernet interface view,
interface interface-number
interface this feature takes effect on the current
view
view or port port only; if configured in port group
group view Enter port port-group manual view, this feature takes effect on all
group view port-group-name ports in the port group.
1-12
Optional
By default, all broadcast traffic is
allowed to pass through an interface,
Set the broadcast storm broadcast-suppression
that is, broadcast traffic is not
suppression ratio { ratio | pps max-pps }
suppressed.
The support for the pps argument
varies with devices.
Optional
By default, all multicast traffic is
allowed to pass through an interface,
Set the multicast storm multicast-suppression
that is, multicast traffic is not
suppression ratio { ratio | pps max-pps }
suppressed.
Optional
By default, all unknown unicast traffic
is allowed to pass through an interface,
Set the unknown unicast unicast-suppression
that is, unknown unicast traffic is not
storm suppression ratio { ratio | pps max-pps }
suppressed.
If you set storm suppression ratios in Ethernet interface view or port group view repeatedly for an
Ethernet interface that belongs to a port group, only the latest settings take effect.
Follow these steps to set storm suppression ratios for an Ethernet subinterface:

Enter Ethernet
interface-number.subnum
subinterface view
ber
Optional
Set the broadcast
broadcast-suppression By default, all broadcast traffic is allowed to
storm suppression
ratio pass through a subinterface, that is, broadcast
ratio
traffic is not suppressed.
Optional
Set the multicast
multicast-suppression By default, all multicast traffic is allowed to
storm suppression
ratio pass through a subinterface, that is, multicast
ratio
traffic is not suppressed.
Optional
Set the unknown
unicast-suppression By default, all unknown unicast traffic is
unicast storm
ratio allowed to pass through a subinterface, that is,
suppression ratio
unknown unicast traffic is not suppressed.
1-13
Setting the Interval for Collecting Ethernet Interface Statistics
Follow these steps to configure the interval for collecting interface statistics:

Optional
Configure Global
flow-interval interval The default interval for collecting
the interval configuration
interface statistics varies with devices.
for
collecting Configuration interface interface-type Optional
interface on an interface-number
statistics Ethernet The default interval for collecting
interface flow-interval interval interface statistics varies with devices.
z If you execute this command in system view, you will configure an interval for all ports to collect
statistics.
z If you execute this command in Ethernet interface view, you will configure an interval for the current
interface to collect statistics.
z A device only supports either configurations in system view or configurations in Ethernet interface
view, depending on the device model.
Enabling Forwarding of Jumbo Frames
Due to tremendous amount of traffic occurring on an Ethernet interface, it is likely that some frames
greater than the standard Ethernet frame size are received. Such frames (called jumbo frames) will be
dropped. With forwarding of jumbo frames enabled, upon receiving jumbo frames with a size greater
than the standard Ethernet frame size and yet within the specified parameter range, the Ethernet
interface will forward such frames to its upper layer protocol for processing.
In global configuration mode (system view) or interface configuration mode (Ethernet interface
view/port-group view), you can set the length of jumbo frames that can pass through the Ethernet
interface.
1-14
z If you execute the command in system view, the configurations take effect on all Ethernet
interfaces.
z If you execute the command in Ethernet interface view, the configurations take effect only on the
current interface.
z If you execute the command in port-group view, the configurations take effect on all ports in the port
group.
Different models of device support different configuration modes. A device can only support either
global configuration mode or interface configuration mode.
Follow these steps to enable the forwarding of jumbo frames:

In system view jumboframe enable [ value ] Use any command.
port-group manual By default, the device allows

In port-group port-group-name jumbo frames with the specified
Enable the view length to pass through all Layer
forwarding of jumboframe enable [ value ] 2 Ethernet interfaces. The
jumbo length of jumbo frames that are
frames interface interface-type allowed to pass varies with
In Ethernet interface-number device models.
interface view The support for the value
jumboframe enable [ value ] argument varies with devices.
If you set the value argument for ports of a port group in Ethernet interface view or port-group view for
multiple times, the latest configuration takes effect.
Enabling Loopback Detection on an Ethernet Interface
If a port receives a packet that it sent out, a loop occurs. Loops may cause broadcast storms. The
purpose of loopback detection is to detect loops on an interface.
When loopback detection is enabled on an Ethernet interface, the device periodically checks whether
the ports have any external loopback. If it detects a loopback on a port, the device will set that port to be
under loopback detection mode.
1-15
z If loops are detected on an access port, the port will be blocked. Meanwhile, trap messages will be
sent to the terminal, and the corresponding MAC address forwarding entries will be removed.
z If loops are detected on a trunk port or a hybrid port, trap messages are sent to the terminal. If the
loopback detection control function is also enabled on the port, the port will be blocked, trap
messages will be sent to the terminal, and the corresponding MAC address forwarding entries will
be removed.
Follow these steps to configure loopback detection:

Enable global loopback Required

loopback-detection enable
detection Disabled by default
Configure the interval for port loopback-detection Optional

loopback detection interval-time time 30 seconds by default
interface-number
Enable loopback detection on a Required

loopback-detection enable
port Disabled by default
Enable loopback detection Optional
loopback-detection control
control on a trunk port or a
enable Disabled by default
hybrid port
Optional
Enable loopback detection in all
loopback-detection per-vlan Enabled only in the default
the VLANs to which trunk or
enable VLAN(s) with trunk port or
hybrid ports belong
hybrid ports
z Loopback detection on a given port is enabled only after the loopback-detection enable
command has been configured in both system view and the interface view of the port.
z Loopback detection on all ports will be disabled after the configuration of the undo
loopback-detection enable command under system view.
Configuring the Cable Type for an Ethernet Interface
The optical interface of combo ports does not support this function.
Two types of Ethernet cables can be used to connect Ethernet devices: crossover cable and
straight-through cable. To accommodate these two types of cables, an Ethernet interface on a device
can operate in one of the following three Medium Dependent Interface (MDI) modes:
z Across mode, where the Ethernet interface only accepts crossover cables.
1-16
z Normal mode, where the Ethernet interface only accepts straight-through cables.
z Auto mode, where the Ethernet interface accepts both straight-through cables and crossover
cables.
Normally, the auto mode is recommended. The other two modes are useful only when the device
cannot determine the cable type.
Follow these steps to configure the cable type for an Ethernet interface:

interface-number
Optional
Configure the cable type the Defaults to auto. That is, the
mdi { across | auto | normal } Ethernet interface
Ethernet interface can identify
automatically detects the type
of the cable in use.
Testing the Cable on an Ethernet Interface
z The optical interface of a Combo port does not support this feature. The support of other Ethernet
interfaces for this feature depends on the device model.
z A link in the up state goes down and then up automatically if you perform the operation described in
this section on one of the Ethernet interfaces forming the link.
Follow these steps to test the current operating state of the cable connected to an Ethernet interface:

interface-number
Test the cable connected to the
virtual-cable-test Required
Ethernet interface once
Testing an Ethernet Interface
Follow these steps to test an Ethernet interface:
1-17
interface-number
Test the current Ethernet
port test Required
interface once
Resetting an Ethernet Interface/Subinterface
Follow these steps to reset an Ethernet interface/subinterface:

reset port interface-type
Reset an Ethernet
{ interface-number | Required
interface/subinterface
interface-number.subnumber }
Configuring the Storm Constrain Function on an Ethernet Interface
The storm constrain function suppresses packet storm in an Ethernet. With this function enabled on an
interface, the system detects the unicast traffic, multicast traffic, or broadcast traffic passing through the
interface periodically and takes corresponding actions (that is, blocking or shutting down the interface
and sending trap messages and logs) if the traffic detected exceeds the threshold.
Although the storm suppression function and the storm constrain function can all be used to control
specific type of traffic, they conflict with each other. So, do not configure both for an Ethernet interface at
the same time. For example, with unicast storm suppression ratio set on an Ethernet interface, do not
enable the storm constrain function for unicast traffic on the interface. Refer to Configuring Storm
Suppression for information about the storm suppression function.
1-18
With the storm constrain function enabled on an Ethernet interface, you can specify the system to act as
follows when the traffic detected exceeds the threshold.
z Blocking the interface. In this case, the interface is blocked and thus stops forwarding the traffic of
this type till the traffic detected is lower than the threshold. Note that an interface blocked by the
storm constrain function can still forward other types of traffic and monitor the blocked traffic.
z Shutting down the interface. In this case, the interface is shut down and stops forwarding all types
of traffics. Interfaces shut down by the storm constrain function can only be brought up by using the
undo shutdown command or disabling the storm constrain function.
Follow these steps to configure the storm constrain function on an Ethernet interface:

Set the interval for generating storm-constrain interval Optional

traffic statistics seconds 10 seconds by default
interface-number
Enable the storm constrain storm-constrain { broadcast |
function and set the lower multicast | unicast } pps Required
threshold and the upper max-pps-values Disabled by default
threshold min-pps-values
Set the action to be taken when Optional
storm-constrain control
the traffic exceeds the upper
{ block | shutdown } Disabled by default
threshold
Optional
Specify to send trap messages By default, the system sends
when the traffic detected trap messages when the traffic
exceeds the upper threshold or detected exceeds the upper
storm-constrain enable trap
drops down below the lower threshold or drops down below
threshold from a point higher the lower threshold from a point
than the upper threshold higher than the upper
threshold.
Optional
Specify to send log when the
traffic detected exceeds the By default, the system sends
upper threshold or drops down log when the traffic detected
storm-constrain enable log exceeds the upper threshold or
below the lower threshold from
a point higher than the upper drops down below the lower
threshold threshold from a point higher
than the upper threshold.
z For network stability consideration, configure the interval for generating traffic statistics to a value
that is not shorter than the default.
z The storm constrain function is applicable to unicast packets, multicast packets, and broadcast
packets; and you can specify the upper and lower threshold for any of the three types of packets.
1-19
Configuring a Layer 3 Ethernet Interface/Subinterface
Layer 3 Ethernet Interface/Subinterface Configuration Task List
Complete these tasks to configure Layer 3 Ethernet interfaces/subinterfaces:
Task Remarks
Setting the MTU for an Ethernet Optional

Interface/Subinterface Applicable to Layer 3 Ethernet interfaces and subinterfaces
Configuring Link Layer State Change Optional

Suppression on an Ethernet Interface Applicable to Layer 3 Ethernet interfaces
Setting the MTU for an Ethernet Interface/Subinterface
The value of Maximum Transmission Unit (MTU) affects the fragmentation and re-assembly of IP
packets.
Follow these steps to set the MTU for an Ethernet interface/subinterface:

Enter Ethernet interface interface interface-type
view/Ethernet subinterface { interface-number |
view interface-number.subnumber }
Optional
Set the MTU mtu size
1500 bytes by default
Limited to the QoS queue length (for example, the default length of an FIFO queue is 75), too small an
MTU will result in too many fragments, which will be discarded from the QoS queue. In this case, you
can increase MTU or QoS queue length properly. In Ethernet interface view, you can use the qos fifo
queue-length command to change the QoS queue length. For detailed configurations, see QoS
Configuration in the QoS Volume.
Configuring Link Layer State Change Suppression on an Ethernet Interface
An Ethernet interface operating in Layer 3 mode has two link layer states: up and down. During the
suppression time, link-layer-state changes will not be propagated to the system. Only after the
suppression time has elapsed will the system be notified of the link-layer-state changes by the link layer.
This functionality reduces the extra overhead occurred due to frequent link-layer-state changes within a
short period of time.
Follow these steps to configure the suppression time of link-layer-state changes on an Ethernet
interface:
1-20
interface-number
Configure the suppression time Optional
of link-layer-state changes on timer hold seconds
an Ethernet Interface 10 seconds by default
You can increase the polling interval to reduce network instability due to time delay or heavy
congestion.
Displaying and Maintaining an Ethernet Interface/Subinterface

Display the current state of an display interface [ interface-type
Available in any
interface/subinterface and the [ interface-number |
view
related information interface-number.subnumber ] ]
display brief interface
[ interface-type [ interface-number |
Display the summary of a Available in any
interface-number.subnumber ] ] [ |
interface/subinterface view
{ begin | exclude | include }
regular-expression ]
Display the statistics on the packets
display counters { inbound | Available in any
passing through a specific type of
outbound } interface [ interface-type ] view
interfaces
Display the statistics on the rate of
the packets passing through the
display counters rate { inbound | Available in any
interfaces that are of a specific type
outbound } interface [ interface-type ] view
and are in the up state in the latest
sampling interval
reset counters interface

Clear the statistics of a Available in user
[ interface-type [ interface-number |
interface-number.subnumber ] ]
Display the Combo ports and the
Available in any
corresponding optical/electrical display port combo
view
ports
Display the current ports that are of Available in any
display port { hybrid | trunk }
a specified type view
Display the information about a
display port-group manual [ all | Available in any
manual port group or all the port
name port-group-name ] view
groups
Display the information about the Available in any
display loopback-detection
loopback function view
1-21
The support for the display counters, display counters rate, display port combo, and display
port-group manual commands varies with device models.
1-22
Table of Contents
1 WAN Interface Configuration 1-1

Asynchronous Serial Interface 1-2
Overview1-2
Configuring an Asynchronous Serial Interface1-2
AUX Interface1-3
Overview1-3
Configuring an AUX Interface1-3
USB Interface1-4
Overview1-4
Configuring a USB Interface1-4
Synchronous Serial Interface1-5
Overview1-5
Configuring a Synchronous Serial Interface1-5
AM Interface1-7
Overview1-7
Configuring an AM Interface1-7
ISDN BRI Interface1-8
Overview1-8
Configuring an ISDN BRI Interface 1-9
CE1/PRI Interface 1-10
Overview1-10
Configuring a CE1/PRI Interface (in E1 Mode) 1-10
Configuring a CE1/PRI Interface (in CE1 Mode)1-11
Configuring a CE1/PRI Interface (in PRI Mode)1-12
Configuring Other CE1/PRI Interface Parameters 1-12
Configuring Error Packets Diffusion Restraint1-13
Displaying and Maintaining CE1/PRI Interfaces 1-14
CT1/PRI Interface 1-14
Overview1-14
Configuring a CT1/PRI Interface in CT1 Mode 1-15
Configuring a CT1/PRI Interface operating as a PRI interface 1-15
Configuring Other CT1/PRI Interface Parameters 1-16
Starting/Terminating a BERT Test on CT1/PRI Interface 1-17
Configuring Error Packets Diffusion Restraint1-18
Displaying and Maintaining CT1/PRI Interfaces1-19
E1-F Interface 1-19
Overview1-19
Configuring an E1-F Interface (in Framed Mode) 1-19
Configuring an E1-F Interface (in Unframed Mode) 1-20
Configuring Other E1-F Interface Parameters 1-20
Displaying and Maintaining E1-F Interfaces1-21
T1-F Interface1-21
Overview1-21
i
Configuring a T1-F Interface 1-21
Starting/Terminating a BERT Test on T1-F Interface1-23
Displaying and Maintaining T1-F Interfaces 1-23
CE3 Interface 1-23
Overview1-23
Configuring a CE3 Interface in E3 Mode1-24
Configuring a CE3 Interface operating in CE3 Mode 1-24
Configuring Other CE3 Interface Parameters 1-25
Displaying and Maintaining CE3 Interfaces1-26
CT3 Interface 1-27
Overview1-27
Configuring a CT3 Interface in T3 Mode 1-27
Configuring a CT3 Interface in CT3 Mode1-28
Configuring Other CT3 Interface Parameters1-29
Displaying and Maintaining CT3 Interfaces1-30
ii

Error packets
No No Yes Yes
diffusion restraint
z The MSR30-11 model does not support USB interfaces.
z CE3 and CT3 interfaces do not support subrate configuration.
1 WAN Interface Configuration
In terms of line type, wide area networks (WANs) fall into these types: X.25, Frame Relay (FR), ATM,
and ISDN. To interface to these networks, routers are designed with the asynchronous serial interface,
synchronous serial interface, ATM interface, ISDN BRI interface, CE1/PRI interface, and so on.
When configuring WAN interfaces, go to the following sections for information you are interested in:
z Asynchronous Serial Interface
z AUX Interface
z USB Interface
z Synchronous Serial Interface
z AM Interface
z ISDN BRI Interface
z CE1/PRI Interface
z CT1/PRI Interface
z E1-F Interface
z T1-F Interface
z CE3 Interface
z CT3 Interface
1-1
Refer to ATM and DSL Interface Configuration in the Access Volume for information about ATM
interface.
Asynchronous Serial Interface

Overview
The following two types of asynchronous serial interfaces are available:

z Synchronous/asynchronous serial interface operating in asynchronous mode, whose interface
index begins with Serial.
z Dedicated asynchronous serial interface, whose interface index begins with Async.
An asynchronous serial interface can operate in the flow mode or protocol mode. It can operate as a
dialup interface when having a modem or an ISDN terminal adapter (TA) attached to it. You can
encapsulate an asynchronous serial interface with PPP on the data link layer to provide support for
network layer protocols such as IP and IPX.
Configuring an Asynchronous Serial Interface
Follow these steps to configure an asynchronous serial interface:

interface async
interface-number
Enter asynchronous
or
serial interface view
interface serial
interface-number
Required
By default, an asynchronous/synchronous
Configure the interface to serial interface operates as a synchronous
operate as an serial interface.
physical-mode async
asynchronous serial This command is not available on AM
interface interfaces.
Skip this step if the interface is an Async
interface.
Optional
Set the link layer protocol link-protocol ppp
The default is PPP.
async mode { flow | Optional

Set the operating mode
protocol } The default is the protocol mode.
Optional
Enabled by default.
Enable level detection detect dsr-dtr
This command is not available to AM
interfaces.
1-2
Optional
Enable local loopback loopback
Optional
The default is 1500 bytes.
Optional
Set the polling interval timer hold seconds
The default is 10 seconds.
Eliminate the pulses with Optional

eliminate-pulse
a width less than 3.472 us Enabled by default
Optional
Set the MRU for an
The default MRU is 1700 bytes.
interface operating in the phy-mru mrusize
flow mode This command is not available to AM
interfaces.
Shut down the Optional

asynchronous serial shutdown An asynchronous serial interface is
interface enabled by default.
z You can use the speed command to configure the baud rate for an asynchronous serial interface.
For details, refer to User Interface Configuration in the System Volume.
z Refer to the corresponding volumes for information about the configuration concerning PPP, DCC,
IP addressing, firewall, and backup center.
AUX Interface
Overview
The AUX interface is fixed on your device. It can work as a regular asynchronous serial interface at
speeds up to 115200 bps. With this interface, you can perform functions such as remote device
configuration and line backup.
Configuring an AUX Interface
Follow these steps to configure an AUX interface:

interface aux
Enter AUX interface view
interface-number
async mode { flow | Required

Set the operating mode
protocol } The default is the flow mode.
Optional
Enabled by default.
1-3
Optional
Optional
The default is PPP.
Optional
Shut down the AUX Optional

shutdown
interface An AUX interface is enabled by default.
To perform other AUX interface configurations (such as baud rate, stop bit, parity, and flow control), use
the corresponding commands in user-interface view. Refer to User Interface Configuration in the
System Volume for related information.
USB Interface
Overview
USB interface operates in the protocol mode. The link layer protocol can be PPP and the network layer
protocol can be IP or IPX.
Configuring a USB Interface
Follow these steps to configure a USB interface:
To do Use the command... Remarks

interface usb
Enter USB interface view
interface-number
Optional
The default is PPP.
Optional
Optional
Optional
Shut down the USB interface shutdown
A USB interface is enabled by default
1-4
In certain cases, configurations concerning PPP, DCC, IP address, firewall, and backup center are
required for a USB interface. Refer to corresponding modules for related information.
Synchronous Serial Interface

Overview
A synchronous serial interface has the following features:

z Work in either DTE or DCE mode. Usually, it serves as DTE to accept the clock provided by DCE.
z Be connected to various types of cables, such as V.24, V.35, X.21, RS449, and RS530. Your
device can automatically detect the type of connected cable and select electrical properties. In
most cases, you do not need to manually configure them.
z Support link layer protocols such as PPP, FR, link access procedure, balanced (LAPB), and X.25.
z Support network layer protocols IP and IPX.
z Provide information about the connected cable type, operating mode (DTE or DCE) and so on with
the display interface serial command.
Configuring a Synchronous Serial Interface
Follow these steps to configure a synchronous serial interface:

Enter synchronous serial interface serial

Optional
Configure the interface to By default, an
operate as a synchronous physical-mode sync asynchronous/synchronous serial
serial interface interface operates as a synchronous
serial interface.
link-protocol { fr | hdlc | Optional

Set the link layer protocol
lapb | ppp | sdlc | x25 } The default is PPP.
Optional
Set the digital signal coding
code { nrz | nrzi } The default is non-return-to-zero
format
(NRZ).
Optional
baudrate baudrate The default is 64,000 bps.
Set the baud rate virtualbaudrate These commands are available to
virtualbaudrate synchronous/asynchronous serial
interface operating in asynchronous
mode only.
1-5
Optional
The default is DCEclk for DCE side,
clock { dteclk1 |
Set the DTE-side operating and DTEclk1 for DTE side.
dteclk2 | dteclk3 |
clock When the interface is functioning as
dteclk4 | dteclkauto }
DCE, you do not need to make the
configuration.
Set transmit-clock or receive invert { transmit-clock | Optional

clock inversion receive-clock } Clock inversion is disabled by default.
Optional
Optional
Set the CRC mode crc { 16 | 32 | none }
The default is 16-bit CRC.
Optional
Enabled by default.
Enable data carrier detection Optional

detect dcd
(DCD) Enabled by default.
Optional
Optional
Configure the polling interval timer hold seconds
Optional
Set line idle-mark to 0xFF idle-mark
The default is 0x7E.
Optional
Enable RTS signal reverse reverse-rts
Optional
Shut down the synchronous
shutdown A synchronous serial interface is
serial interface
enabled by default.
z To set the baud rate for a synchronous/asynchronous serial interface operating in asynchronous
mode, use the speed command in user-interface view. Refer to User Interface Configuration in the
System Volume for related information.
z Refer to corresponding volumes for information about other synchronous serial interface
configurations, such as PPP/X.25/FR, DCC, IP addressing, firewall, and backup center in addition.
You may need to configure parameters of PPP/X.25/FR, DCC, IP addressing, firewall, and backup
center in addition.
1-6
AM Interface
Overview
Analog modem (AM) interfaces bring services provided by asynchronous serial interfaces and analog
modems together. Most of the configuration commands used on asynchronous serial interfaces and
modems can be directly used on AM interfaces. When configuring an AM interface, you can treat it as a
special asynchronous serial interface.
AM interfaces provide dial-in and dial-out services for analog dial-up users.
Theoretically, if the peer (usually an ISP) uses a digital modem, the AM interface can establish
connection with V.90 Modem standard to provide downstream rates up to 56 kbps and upstream rates
up to 33.6 kbps. If the peer (usually a common user) uses an analog modem (or an AM interface), the
AM interface can establish connection with V.34 Modem standard to provide rates (both downstream
and upstream) up to 33.6 kbps.
The real rate of an AM interface, however, may deviate somewhat depending on line quality, PBX
performance, connection protocol, and other elements.
Configuring an AM Interface
Follow these steps to configure an AM interface:

interface analogmodem
Enter AM interface view
number
Optional
Set the area code country-code area-name
united-states by default
Set asynchronous interface See Configuring an
Optional
properties Asynchronous Serial Interface
To set the baud rate for an AM interface, use the speed command in user-interface view. Refer to User
Interface Configuration in the System Volume for related information.
The configuration of AM interface is similar to that of asynchronous interface and modem, except that
an AM interface does not support the modem auto-answer and the baudrate commands. (Refer to
Modem Configuration in the Access Volume for information about modem configuration.)
You may need to configure parameters concerning PPP, DCC, IP addressing, firewall and backup
center. For their configuration, refer to the related volumes.
1-7
ISDN BRI Interface
Overview
Technical background
Integrated services digital network (ISDN) is a technology rising in 1970s. It provides all-digital
terminal-to-terminal services and fulfills the full digitized delivery of the services integrating voice, data,
graphics and video.
ISDN is different from the conventional PSTN network. In a conventional PSTN network, user
information is transferred as analog signals over analog user loop to exchanges where these analog
signals are converted into digital signals. These digital signals traverse the switched network and
transmission network and are converted into the analog signals again upon their reach at the
destination. ISDN makes it possible to implement digital transmission on a user loop and fulfills the
end-to-end digitization. As a standardized digital interface, ISDN BRI interface can be used to forward
digital and analog information. The standardization efforts that ITU-T made in provisioning the ISDN
services make the implementation of ISDN become possible. The provisions of the recommendations
I.430, Q.921, and Q.931 allow all the devices meeting ITU-T ISDN provisions of unbarring ISDN
network access.
The following is the provision standardizing the ISDN user-network interface.
ITU-T I.411 provides the referential ISDN user-network interface configuration as shown in the
following figure on the basis of function group (a set of functions required for accessing an ISDN
network) and reference point (a concept used to differentiate function groups).
Figure 1-1 Referential ISDN user-network interface configuration
Function groups include:

z Network terminal 1 (NT1) implements the functionality of the first layer in the OSI reference model,
such as subscriber-line transmission, loop test, D-channel competition.
z Network terminal 2 (NT2), also known as intelligent network terminal, implements the functionality
of layers 1 through 3.
z Category-1 terminal equipment (TE1), also known as ISDN standard terminal, is user equipment
compliant with the ISDN interface provisions. Digital phone-set is such an example.
z Category-2 terminal equipment (TE2), also known as non-ISDN standard terminal equipment,
refers to the user equipment incompliant with the ISDN interface provisions.
z Terminal adapter (TA) implements the adaptation function so that TE2 can access a standard
ISDN interface.
Reference points include:
1-8
z R reference point between a non-ISDN equipment and TA.
z S reference point between a user terminal and NT2.
z T reference point between NT1 and NT2.
z U reference point between NT1 and line terminal.
Preparing for making configuration
Before making configuration, you should:

z Verify the type of the interface provided by your telecom service provider, whether it is ISDN BRI U
or ISDN BRI S/T. Despite that ITU-T I.411 has provided an ISDN user-network interface reference
model, there are some arguments in the position of the user-network dividing point. For this reason,
some nations adopt the U interface while some others adopt the S/T interface depending on their
needs. Therefore, you must make sure the interface type provided by your service provider before
making a router purchase decision.
z Request for digital service. As ISDN can provide integrated services including both digital and
voice, you must request for an ISDN line allowing digital call service so that your router can make
digital communications.
z Select connection type, which can be a point-to-point connection or a point-to-multipoint
connection (optional). As ISDN supports semipermanent connection, you can adopt the ISDN
leased line in the event that you adopt ISDN only for connecting two fixed points. Otherwise, you
must select a point-to-multipoint connection.
z Request for the delivery of Calling Line Identification (CLI) function (optional). With it, you can
implement calling ID filtering on your ISDN line to reject some users from accessing the local router
and hence enhance the network security.
Configuring an ISDN BRI Interface
Follow these steps to configure an ISDN BRI interface:

Enter ISDN BRI interface view interface bri number
Configure the interface Optional

description text
description Interface name interface by default.
Enable external loopback on
loopback { b1 | b2 | both } Disabled by default.
the ISDN BRI interface
Set the MTU for the BRI Optional

mtu size
interface 1500 bytes by default.
Optional
Shut down the BRI interface shutdown A BRI interface is enabled by
default.
ISDN BRI interfaces are used for dialup purpose. For details on ISBN BRI interface configuration, refer
to DCC Configuration in the Access Volume.
1-9
CE1/PRI Interface
Overview
In 1960s, the time division multiplexing (TDM) technology gained increasingly wide application in the
data communications system along with the introduction of pulse code modulation (PCM) technology.
So far, there exist two TDM systems in the data communications system. One is the ITU-T
recommended E1 system, which is widely adopted in Europe and P.R. China. The other is the ANSI
recommended T1 system, which is widely used in North American and Japan. (The system that Japan
adopts is actually called J1. It is regarded as a T1 system due to high similarity between them.)
A CE1/PRI interface can work in either E1 mode (also called non-channelized mode) and CE1/PRI
mode (that is, channelized mode).
A CE1/PRI interface in E1 mode equals an interface of 2048 Mbps data bandwidth, on which, no
timeslots are divided. Its logic features are the same like those of a synchronous serial interface. It
supports the link layer protocols such as PPP, FR, LAPB and X.25 and the network protocols such as IP
and IPX.
A CE1/PRI interface in CE1/PRI mode is physically divided into 32 timeslots numbered 0 to 31. Among
them, timeslot 0 is used for transmitting synchronizing information. This interface can be used as either
a CE1 interface or a PRI interface.
z When this interface is used as a CE1 interface, all the timeslots except timeslot 0 can be randomly
divided into multiple channel sets and each set can be used as an interface upon timeslot bundling.
Its logic features are the same as those of a synchronous serial interface. It supports link layer
protocols such as PPP, HDLC, FR, LAPB and X.25, and network protocols such as IP.
z When the interface is used as a PRI interface, timeslot 16 will be used as a D channel to transmit
signaling. Therefore, rather than selecting among all the timeslots, you are only allowed to make a
random B channel selection among the timeslot sets except timeslots 0 and 16. The selected set of
timeslots can be bundled together with timeslot 16 to form a PRI set that can be used as an
interface. The logic features of this interface are the same as those of an ISDN PRI interface. It
supports link layer protocols such as PPP, HDLC, FR, LAPB, and X.25, and network protocols
such as IP.
Configuring a CE1/PRI Interface (in E1 Mode)
Follow these steps to configure a CE1/PRI interface in E1 mode:

Enter CE1/PRI interface view controller e1 number

Required
Set the interface to operate in
using e1 The default operating mode is
E1 mode
CE1/PRI mode.
See Configuring Other
Set other interface parameters Optional
CE1/PRI Interface Parameters
After you set the CE1/PRI interface to operate in E1 mode, the system automatically creates a serial
interface numbered serial interface-number:0. This interface is logically equivalent to a synchronous
serial interface where you can make other configurations such as:
1-10
z Parameters of data link protocol such as PPP, FR, LAPB, or X.25
z IP addressing
z Backup center parameters if the interface is used as a primary or secondary interface for backup
z NAT and packet filtering if a firewall is to be set up
For their configuration, refer to the concerned parts of this manual.
Configuring a CE1/PRI Interface (in CE1 Mode)
Follow these steps to configure a CE1/PRI interface in CE1 mode:

Optional
using ce1 The default operating mode is
CE1/PRI mode
CE1/PRI mode.
Bundle timeslots on the channel-set set-number
Required
interface into a channel set timeslot-list list
A CE1/PRI interface in CE1/PRI mode can be used as a CE1 interface where a serial interface is
created upon creation of a channel set. You may bundle timeslots on a CE1/PRI interface into up to 31
channel sets.
For each channel set, the system automatically creates a serial interface numbered serial
interface-number:set-number. This interface is logically equivalent to a synchronous serial interface
where you can make other configurations about:
z Data link protocol such as PPP, FR, LAPB, or X.25
z IP addressing
The timeslots on a CE1/PRI interface can be bundled into either channel sets or a PRI set, but not the
both, at a time.
1-11
Configuring a CE1/PRI Interface (in PRI Mode)
Follow these steps to configure a CE1/PRI interface in PRI mode:


Optional
CE1/PRI mode
CE1/PRI mode.
Required
Bundle timeslots on the If no timeslot range is specified,
pri-set [ timeslot-list list ] all timeslots except timeslot 0
interface into a PRI set
form a 30B + D ISDN PRI
interface.
A CE1/PRI interface in CE1/PRI mode can be used as a PRI interface where only one PRI set can be
created.
For the PRI set, the system automatically creates a serial interface numbered serial
interface-numbe:15. This interface is logically equivalent to an ISDN PRI interface where you can make
other configurations about:
z DCC
z PPP and PPP authentication
z IP addressing
z Backup center parameters if the interface is to be used as a primary or secondary interface for
backup
z Firewall
The timeslots on a CE1/PRI interface can be bundled into either channel sets or a PRI set, but not both
at a time.
Configuring Other CE1/PRI Interface Parameters
Follow these steps to configure other CE1/PRI interface parameters:

Enter CE1/PRI interface
controller e1 number
view
1-12
Optional
Configure the interface
description text The default description is Interface name
description
interface.
Optional
Set the line code format code { ami | hdb3 } The default is high density bipolar 3
(HDB3).
Configure to perform AIS Optional
(alarm indication signal) detect-ais
test By default, AIS test is performed.
Optional
Set the cable type cable { long | short }
The default cable setting is long mode.
Optional
The default is slave, that is, line clock.
frame-format { crc4 | Optional

Optional
Set the line idle code type idlecode { 7e | ff }
Set the type of interframe Optional

itf type { 7e | ff }
filling tag The default is 0x7E.
Set the number of Optional

itf number number
interframe filling tags The default is 4.
loopback { local | Optional

payload | remote } Loopback is disabled by default.
Shut down the CE1/PRI Optional

shutdown
interface The interface is enabled by default.
interface serial
Enter the view of the interface-number:set-nu
synchronous serial mber
Required
interface created on the or
CE1/PRI interface interface serial
interface-number:15
Optional
By default, 16-bit CRC is adopted.
Configuring Error Packets Diffusion Restraint
The support of this feature varies with device models.
1-13
Error packet diffusion refers to the situation when one timeslot receives a certain error packet, all the
other timeslots are affected and also receive error packets.
You can restrain error packet diffusion by configuring three parameters: detect-timer, renew-timer,
threshold, which function in the following way:
If, during the time specified by detect-timer, the ratio of error packets on an interface is greater than that
specified by threshold, the interface is regarded as faulty and is shut down. After waiting for some time
specified by renew-timer, the interface is re-enabled.
Follow these steps to configure error packets diffusion restraint:

Enable error packets diffusion error-diffusion restraint enable Required

Optional
Configure the parameters of error-diffusion restraint config By default, the value of
error packets diffusion detect-timer renew-timer detect-timer is 30 seconds, of
restraint threshold renew-timer is 600 seconds;
the threshold is 20%
Restart the channel that is error-diffusion restraint
shut down for the sake of error restart-channel serial Optional
packets restraint interface-number:set-number
Displaying and Maintaining CE1/PRI Interfaces

Display the operating state of a display controller e1
CE1/PRI interface [ interface-number ]
Display the operating state of a display interface serial
channel set or PRI set interface-number:set-number
Clear the controller counter for reset counters controller e1
a CE1/PRI interface interface-number
CT1/PRI Interface
Overview
A CT1/PRI interface can operate only in channelized mode. It can be used in the following two ways:
z When it is working as a CT1 interface, all the timeslots (numbered 1 to 24) can be randomly divided
into groups. Each of these groups can form one channel set for which the system automatically
creates an interface logically equivalent to a synchronous serial interface. This interface supports
link layer protocols such as PPP, HDLC, FR, LAPB, and X.25, and network protocols such as IP
and IPX.
z When it is working as a PRI interface, timeslot 24 is used as a D channel for signaling transmission.
Therefore, only a group of timeslots except timeslot 24 can be chosen as the B channel. This
timeslot group is bundled together with timeslot 24 to form a PRI set. This PRI set will work as an
interface logically equivalent to an ISDN PRI interface where you can configure PPP, HDLC, FR,
LAPB, or X.25 at the data link layer, IP at the network layer, DCC, and other configurations.
1-14
The timeslots on a CT1/PRI interface can be bundled into either channel sets or a PRI set at a time.
Configuring a CT1/PRI Interface in CT1 Mode
Follow these steps to configure a CT1/PRI interface in CT1 mode:

Enter CT1/PRI interface view controller t1 number
Required
channel-set set-number Up to 24 channel sets can be
Bundle timeslots on the
timeslot-list list [ speed { 56k | bundled.
interface into a channel set
64k } ] The default timeslot speed is 64
kbps.
CT1/PRI Interface Parameters
For each channel set, the system automatically creates a serial interface numbered serial
number:set-number. This interface is logically equivalent to a synchronous serial interface where you
can make other configurations about:
z Data link protocol such as PPP, FR, LAPB, or X.25
z IP addressing
For their configuration, refer to related parts of this manual.
Configuring a CT1/PRI Interface operating as a PRI interface
Follow these steps to configure a CT1/PI interface operating as a PRI mode:

Required
pri-set [ timeslot-list list ] Only one PRI set can be
interface into a PRI set
created at a time.
CT1/PRI Interface Parameters
For the PRI set, the system automatically creates a serial interface numbered serial number:23. This
interface is logically equivalent to an ISDN PRI interface where you can make other configurations
about:
1-15
z DCC
z PPP and PPP authentication
z IP addressing
z Backup center parameters if the interface is to be used as a primary or secondary interface for
backup
z Firewall
For their configuration, refer to related parts of this manual.
Configuring Other CT1/PRI Interface Parameters
Follow these steps to configure other CT1/PRI interface parameters:

Optional
description text The default description is
description
Interface name interface.
Optional
Set the line code format code { ami | b8zs } 1
The default is B8ZS .
cable long { 0db | -7.5db |

Optional
Set the cable length and -15db | -22.5db }
attenuation The long 0db keyword applies
cable short { 133ft | 266ft |
by default.
399ft | 533ft | 655ft }
Optional
Set the clock mode clock { master | slave } The default is slave, that is, line
clock.
Optional
Set the framing format frame-format { sf | esf }
The default is ESF.
data-coding { normal | Optional

Enable user data inversion
inverted } Disable user data inversion.
Optional
Set the line idle code type idlecode { 7e | ff }
Set the type of interframe filling Optional

itf type { 7e | ff }
tag The default is 0x7E.
Set the number of interframe Optional

itf number number
filling tags The default is 4.
1-16
Optional
3
For LOS alarm
The threshold of
pulse-detection defaults to 176
and the threshold of
alarm-threshold { ais { level-1 pulse-recovery defaults to 22.
| level-2 } | lfa { level-1 | level-2 That is, if the number of the
Set alarm thresholds | level-3 | level-4 } | los pulses detected during the total
{ pulse-detection | length of 176 pulse detection
pulse-recovery } value } intervals is smaller than 22, the
pulse-recovery threshold, a
LOS alarm occurs.
4
Both AIS alarm threshold and
5
LFA alarm threshold default to
level-1.
Set the behavior of the Optional

interface on the FDL in ESF fdl { ansi | att | both | none } The default is none, meaning
framing that FDL is forbidden.
loopback { local | payload | Optional

Enable loopback
remote } Disabled by default.
sendloopcode
{ fdl-ansi-llb-down |
fdl-ansi-llb-up |
fdl-ansi-plb-down | Optional
Send remote loopback control
fdl-ansi-plb-up | No remote loopback control
code
fdl-att-plb-down | code is sent by default.
fdl-att-plb-up |
inband-llb-down |
inband-llb-up }
Optional
Shut down the CT1/PRI
shutdown A CT1/PRI interface is enabled
interface
by default.
interface serial
Enter the view of the interface-number:set-number
synchronous serial interface
or Required
created on the CT1/PRI
interface interface serial
interface-number:23
Optional
Set the CRC mode crc { 16 | 32 | none } By default, 16-bit CRC is
adopted.
Note:
1. B8ZS = Bipolar 8-zero substitution; 2. ESF = Extended super frame; 3. LOS = Loss of signal; 4.
AIS = Alarm indication signal; 5. LFA = Loss of frame align
Starting/Terminating a BERT Test on CT1/PRI Interface
Bit error rate test (BERT) is operating as follows:

The local end sends out a pattern, which is to be looped over somewhere on the line and back to the
local end. The local end then checks the received pattern for the bit error rate, and by so doing helps
1-17
you determine whether the condition of the line is good. To this end, you must configure loopback to
allow the transmitted pattern to loop back from somewhere on the line, for example, from the far-end
interface by placing the interface in far-end loopback.
You may view the state and result of the BERT test with the display controller t1 command.
Follow these steps to start/terminate a BERT test on a CT1/PRI interface:

Required
bert pattern { 2^20 | 2^15 }
Start a BERT test By default, no BERT test is
time minutes [ unframed ]
performed.
Configuring Error Packets Diffusion Restraint
The support of this feature varies with device models.
Error packet diffusion refers to the situation when one timeslot receives a certain error packet, all the
other timeslots are affected and also receive error packets.
You can restrain error packet diffusion by configuring three parameters: detect-timer, renew-timer, and
threshold, which function in the following way:
If, during the time specified by detect-timer, the ratio of error packets on an interface is greater than that
specified by threshold, the interface is regarded as faulty and is shut down. After waiting for some time
specified by renew-timer, the interface is re-enabled.
Follow these steps to configure error packets diffusion restraint:

Enable error packets diffusion error-diffusion restraint enable Required
Optional
Configure the parameters of error-diffusion restraint config By default, the values are 30
error packets diffusion detect-timer renew-timer seconds for detect-timer, 600
restraint threshold seconds for renew-timer and
20% for the threshold.
Restart the channel that is error-diffusion restraint
shut down for the sake of error restart-channel serial Optional
packets restraint interface-number:set-number
1-18
Displaying and Maintaining CT1/PRI Interfaces

Display the operating state of a display controller t1
CT1/PRI interface [ interface-number ]
channel set or PRI set interface-number:set-number
Clear the controller counter for reset counters controller t1
a CE1/PRI interface interface-number
E1-F Interface
Overview
E1-F interfaces, fractional E1 interfaces, are simplified CE1/PRI interfaces. They are a cost-effective
alternative to CE1/PRI interfaces where E1 access does not need multiple channel sets or ISDN PRI.
Compared with a CE1/PRI interface, an E1-F interface delivers these features:
z In framed mode, it can only bind timeslots into one channel set, while a CE1/PRI interface can
group and bundle timeslots randomly into multiple channel sets.
z It does not support PRI mode.
An E1-F interface can work in both framed (the default) and unframed modes.
When the E1-F interface is working in unframed mode, it is a non-timeslot interface with 2048 kbps of
data bandwidth. It is logically equivalent to a synchronous serial interface where you may configure
PPP, HDLC, FR, LAPB or X.25 at the link layer and IP at the network layer.
When the E1-F interface is working in framed mode, it is physically divided into 32 timeslots numbered
0 through 31. Except timeslot 0 used for transmitting synchronization information, all other timeslots
can randomly form one channel set. The rate of the interface is thus n 64 kbps and its logical features
are the same as those of a synchronous serial interface where you can configure PPP, FR, LAPB and
X.25 at the data link layer and IP or IPX at the network layer.
Configuring an E1-F Interface (in Framed Mode)
Follow these steps to configure an E1-F interface in framed mode:

interface serial
Enter E1-F interface view
interface-number
Set the interface to operate in Optional

undo fe1 unframed
framed mode The default is framed mode.
Optional
fe1 timeslot-list range If no timeslot range is specified, all
interface
timeslots are bundled by default.
See Configuring Other E1-F
Interface Parameters
1-19
Configuring an E1-F Interface (in Unframed Mode)
Follow these steps to configure an E1-F interface in unframed mode:

interface serial
Enter E1-F interface view
interface-number
Set the interface to operate in Required

fe1 unframed
unframed mode The default is framed mode.
See Configuring Other E1-F
Configuring Other E1-F Interface Parameters
Follow these steps to configure other E1-F interface parameters:

Enter E1-F interface view interface serial serial-number
Optional
description
Optional
Set the line code format fe1 code { ami | hdb3 }
The default is HDB3.
Optional
Set the clock mode fe1 clock { master | slave } The default is slave, that is, line
clock.
Optional
Set the cable type fe1 cable { long | short } The long keyword applies by
default.
Optional
Configure the CRC mode fe1 crc { 16 | 32 | none }
16-bit CRC by default.
Optional
Configure to perform AIS test fe1 detect-ais By default, AIS test is
performed.
fe1 frame-format { crc4 | Optional

Optional
Set the line idle code type fe1 idlecode { 7e | ff }
Set the interframe filling tag Optional

fe1 itf type { 7e | ff }
type The default is 0x7E.
Set the number of interframe Optional

fe1 itf number number
filling tags The default is 4.
1-20
Optional
fe1 loopback { local | payload
Set the loopback mode Loopback is disabled by
| remote }
default.
Optional
Shut down the E1-F interface shutdown An E1-F interface is enabled by
default.
Displaying and Maintaining E1-F Interfaces

display fe1 [ serial
state of a specified or all E1-F Available in any view
interface-number ]
interfaces
Display the operating state of display interface serial
an E1-F interface interface-number
T1-F Interface
Overview
T1-F interfaces, fractional T1 interfaces, are simplified CT1/PRI interfaces. They are a cost-effective
alternative to CT1/PRI interfaces where T1 access does not need multiple channel sets or ISDN PRI.
Compared with a CT1/PRI interface, a T1-F interface delivers these features:
z In framed mode, it can bind timeslots into only one channel set, while a CT1/PRI interface can
group and bundle timeslots randomly into multiple channel sets.
z It does not support PRI mode.
A T1 line is multiplexed from 24 channels. That is, a T1 primary group frame DS1 (digital signal level-1)
comprises 24 DS0 (64 kbps) timeslots and 1 framing bit for synchronization, with each timeslot being 8
bits. Each primary group frame thus has 193 bits (24 8+1). As DS1 can transmit 8000 frames per
second, its transmission speed is 1544 kbps (193 8 kbps).
A T1-F interface can only work in framed mode. Timeslots 1 through 24 on it can randomly form a
channel set. The rate of the interface is thus n 64 kbps or n 56 kbps and its logical features are the
same as those of a synchronous serial interface where you can configure PPP, FR, LAPB and X.25 at
the data link layer and IP at the network layer.
Configuring a T1-F Interface
Follow these steps to configure a T1-F interface:

Enter T1-F
interface serial interface-number
interface view
1-21
Configure the Optional

interface description text The default description is Interface
description name interface.
Required
If no timeslot range is specified, all
Bundle timeslots on timeslots are bundled into one channel
ft1 timeslot-list range [ speed
the interface into a set.
{ 56k | 64k } ]
channel set The default timeslot speed is 64 kbps,
and the default T1-F interface speed is
1536 kbps.
Optional
Set the cable length ft1 cable { long decibel | short
and attenuation length } The long 0db keyword applies by
default.
Set the line code Optional

ft1 code { ami | b8zs }
format The default is B8ZS.
Optional
Set the clock mode ft1 clock { master | slave }
The default is slave, that is, line clock.
Enable user data ft1 data-coding { inverted | Optional

inversion normal } Disabled by default.
Set the behavior of Optional
the interface on the ft1 fdl { ansi | att | both | none }
FDL in ESF framing FDL is disabled by default.
Optional
16-bit CRC by default
Set the frame Optional

ft1 frame-format { esf | sf }
format The default is esf.
Optional
For LOS alarm
The threshold of pulse-detection
ft1 alarm-threshold { ais { level-1 defaults to 176 and the threshold of
| level-2 } | lfa { level-1 | level-2 | pulse-recovery defaults to 22. That is, if
Set alarm the number of the pulses detected
level-3 | level-4 } | los
thresholds during the total length of 176 pulse
{ pulse-detection |
pulse-recovery } value } detection intervals is smaller than 22,
the pulse-recovery threshold, a LOS
alarm occurs.
Both AIS alarm threshold and LFA
alarm threshold default to level-1.
Set the type of line Optional

ft1 idlecode { 7e | ff }
idle code The default is 0x7E.
Set the type of Optional

ft1 itf type { 7e | ff }
interframe filling tag The default is 0x7E.
Set the number of Optional

interframe filling ft1 itf number number
tags The default is 4.
Set the loopback ft1 loopback { local | remote | Optional

mode payload } Loopback is disabled by default.
1-22
ft1 sendloopcode
{ fdl-ansi-llb-down |
Send remote fdl-ansi-llb-up | Optional
control loopback fdl-ansi-plb-down | No remote control code is sent by
code fdl-ansi-plb-up | fdl-att-plb-down default.
| fdl-att-plb-up | inband-llb-down
| inband-llb-up }
Shut down the T1-F Optional

shutdown
interface A T1-F interface is enabled by default.
Starting/Terminating a BERT Test on T1-F Interface
BERT is operating as follows:

The local end sends out a pattern, which is to be looped over somewhere on the line and back to the
local end. The local end then checks the received pattern for the bit error rate, and by so doing helps
you determine whether the condition of the line is good. To this end, you must configure loopback to
allow the transmitted pattern to loop back from somewhere on the line, for example, from the far-end
interface by placing the interface in far-end loopback.
You may view the state and result of the BERT test with the display ft1 serial command.
Follow these steps to start/terminate a BERT test on a T1-F interface:

interface serial
Enter T1-F interface view
interface-number
Required
ft1 bert pattern { 2^20 | 2^15 }
Start a BERT test By default, no BERT test is
time minutes [ unframed ]
performed.
Displaying and Maintaining T1-F Interfaces

Display information about a display ft1 [ serial
specified or all T1-F interfaces serial-number ]
specified T1-F interface serial-number
CE3 Interface
Overview
Like E1, E3 also belongs to the digital carrier system of ITU-T. It transmits data at 34.368 Mbps and
adopts HDB3 as the line code format.
A CE3 interface can work in either E3 or CE3 (the default) mode.
1-23
z A CE3 interface in E3 mode equals an interface with 34.368 Mbps data bandwidth, on which, no
timeslots are divided.
z A CE3 interface in CE3 mode can demultiplex 16 channels of E1 signals in compliance with ITU-T
G.751 and G.742. Each E1 line can be divided into 32 timeslots numbered 0 to 31, of which
timeslots 1 through 31 can be randomly bundled into N 64 kbps logical channels. (Timeslot 0 for
framing signal transmission must not participate in bundling operation.) Therefore, CE3 can be
channelized into E1 lines or CE1 lines.
When an E1 line is working in unframed (E1) mode, the system automatically creates a serial interface
numbered serial number/line-number:0 for it. This interface operates at 2048 kbps and is logically
equivalent to a synchronous serial interface where you can make other configurations.
When the E1 line is working in framed (CE1) mode, you can bundle timeslots on it. The system
automatically creates a serial interface numbered serial number/line-number:set-number for it. This
interface operates at N 64 kbps and is logically equivalent to a synchronous serial interface where
you can make other configurations.
CE3 interfaces support link layer protocols PPP, HDLC, FR, LAPB, and X.25 and network protocols IP.
Configuring a CE3 Interface in E3 Mode
Follow these steps to configure a CE3 interface operating in E3 mode:

Enter CE3 interface view controller e3 interface-number
Required
Configure the interface to
using e3 The default operating mode is
operate in E3 mode
CE3 mode.
Optional
fe3 { dsu-mode { 0 | 1 } | By default, DSU mode 1 (the
operate in FE3 mode and set
subrate number } Kentrox mode) is adopted, and
the DSU mode or the subrate
the subrate is 34010 kbps.
See Configuring Other CE3
Depending on the networking requirements, you probably need to configure the CE3 interface with
parameters about PPP, FR, IP addressing, and so on. For details, refer to the relevant sections in this
manual.
Configuring a CE3 Interface operating in CE3 Mode
Follow these steps to configure a CE3 interface in CE3 mode:

controller e3
Enter CE3 interface view
interface-number
Optional
Set the interface to operate in CE3
mode
CE3 mode.
1-24
Set the operating Required
Set the mode to unframed e1 line-number unframed
operating (E1) mode The default is CE1 mode.
mode of an E1
line on the Set the operating undo e1 line-number Optional
CE3 interface mode to framed unframed The default is framed mode.
to unframed (CE1) mode and
mode or bundle timeslots e1 line-number Required
framed mode on the CE1 channel-set set-number No channel sets are created by
interface timeslot-list list default.
CE3 Interface Parameters
Depending on the networking requirements, you probably need to configure the CE3 interface with
manual.
Configuring Other CE3 Interface Parameters
Follow these steps to configure other CE3 interface parameters:

Enter CE3 interface view controller e3 interface-number
Optional
Configure the interface The default description
description text
description is Interface name
interface.
Configure to perform BERT test bert pattern { 2^7 | 2^11 | 2^15 | qrss }
on the CE3 interface time number [ unframed ] Optional
Configure to perform BERT test e1 line-number bert pattern { 2^11 | By default, no BERT
on an E1 channel created on 2^15 | 2^20 | 2^23 | qrss } time test is performed.
the CE3 interface number [ unframed ]
Optional
For the CE3
clock { master | slave } The default is slave,
interface
Set the clock that is, line clock.
mode Optional
e1 line-number set clock { master |
For an E1 line The default is slave,
slave }
that is, line clock.
Optional
Set the national bit national-bit { 0 | 1 }
The default is 1.
Set CRC check for serial Optional

interfaces formed on the CE3 crc { 16 | 32 | none} The default is 16-bit
interface CRC.
For the CE3

loopback { local | payload | remote } Optional
Enable interface
loopback Loopback is disabled
e1 line-number set loopback { local | by default.
For an E1 line
payload | remote }
1-25
Set E1 framing format on an E1 e1 line-number set frame-format Optional

line { crc4 | no-crc4 } The default is no-CRC.
interface serial number/line-number:0

Enter synchronous serial
or
interface view of an interface Required
formed by a CE3 interface interface serial
number/line-number:set-number
Optional
Set the CRC mode crc { 16 | 32 | none } By default, 16-bit CRC
is adopted.
Displaying and Maintaining CE3 Interfaces
An interface is disabled when being shut down. So perform operations of this type with caution.

Display the state information of display controller e3
a CE3 interface [ interface-number ]
display interface serial
state of a serial interface Available in any view
interface-number
formed on a CE3 interface
Clear the controller counter of a reset counters controller e3
CE3 interface interface-number
Perform the command in CE3
Shut down a CE3 interface shutdown
interface view.
Bring up a CE3 interface undo shutdown
interface view.
Shut down an E1 line e1 line-number shutdown
interface view.
undo e1 line-number Perform the command in CE3

Bring up an E1 line
shutdown interface view.
1-26
z Shutting down/bringing up a CE3 interface also shuts down/brings up the E1 lines demultiplexed
from the CE3 interface, the serial interfaces formed by the E1 lines, and the serial interfaces
created on E1 lines by means of timeslot bundling.
z Shutting down/bringing up an E1 line also shuts down/brings up the serial interface formed by it
and the serial interface created on it by means of timeslot bundling.
z To shut down/bring up only a serial interface formed by E3 or E1 lines, or by timeslot bundling on
an E1 line, perform the shutdown/undo shutdown command in the view of the corresponding
serial interface.
CT3 Interface
Overview
Both T3 and T1 belong to the T-carrier system promoted by ANSI. T3 uses the digital signal level DS-3
and operates at 44.736 Mbps.
CT3 interfaces support two operating modes: T3 (unchannelized) and CT3 (channelized).
z In T3 mode, a CT3 interface equals a synchronous serial interface with 44.736 Mbps of data
bandwidth, on which, no timeslots are divided.
z In CT3 mode, a CT3 interface can be demultiplexed into 28 channels of T1 signals. Each T1 line
can be divided into 24 timeslots numbered 1 through 24. Different from E1, each line on a T1
interface can operate at either 64 kbps or 56 kbps. Therefore, the number of logical lines that can
be created on a CT3 interface in CT3 mode is either M 1.536 Mbps (where M ranges from 1 to 28)
or N 56 kbps or N x 64 kbps (where N ranges from 1 to 300).
When a T1 line is working in unframed (T1) mode, the system automatically creates a serial interface
numbered serial number/line-number:0 for it. This interface operates at 1544 kbps and is logically
equivalent to a synchronous serial interface where you can make other configurations.
When the T1 line is working in framed (CT1) mode, you can bundle timeslots on it. The system
automatically creates a serial interface numbered serial number/line-number:set-number for it. This
interface operates at N 64 kbps or N 56 kbps and is logically equivalent to a synchronous serial
interface where you can make other configurations.
Configuring a CT3 Interface in T3 Mode
Follow these steps to configure a CT3 interface in CT3 mode:

Enter CT3 interface view controller t3 interface-number
Required
using t3 The default operating mode is
operate in T3 mode
CT3 mode.
1-27
Configure the interface to Optional

operate in the FT3 mode and ft3 { dsu-mode { 0 | 1 | 2 | 3 | 4 } By default, DSU mode 0 (the
set the DSU mode or the | subrate number } digital link mode) is adopted,
subrate and the subrate is 44210 kbps.
See Configuring Other CT3
Serial interfaces formed on CT3 interfaces support PPP, HDLC, FR, LAPB, and X.25 at the data link
layer, and IP at the network layer. Depending on the networking requirements, you probably need to
configure the CT3 interface with parameters about PPP, FR, IP addressing, and so on. For details, refer
to the relevant sections in this manual.
Configuring a CT3 Interface in CT3 Mode
Follow these steps to configure a CT3 interface in CT3 mode:

controller t3
Enter CT3 interface view
interface-number
Optional
using ct3 The default operating mode is
CT3 mode
CT3 mode.
Set the
operating mode Required
t1 line-number unframed
to unframed (T1) The default is CT1 mode.
Set the mode
operating
mode of a T1 undo t1 line-number Optional
line on the Set the unframed The default is framed mode.
CT3 interface operating mode
to unframed to framed (CT1) Required
mode or mode and t1 line-number
No channel sets are created by
framed mode bundle timeslots channel-set set-number
on the CT1 default.
timeslot-list range
interface [ speed { 56k | 64k } ] The default timeslot speed is 64
kbps.
CT3 Interface Parameters
Depending on the networking requirements, you probably need to configure the CT3 interface with
manual.
1-28
Configuring Other CT3 Interface Parameters
Follow these steps to configure other CT3 interface parameters:

Enter CT3 interface view controller t3 interface-number

Optional
description
For the Optional

CT3 clock { master | slave } The default is slave, that is, line
interface clock.
Set the clock
mode Optional
For a T1 t1 line-number set clock { master
line | slave } The default is slave, that is, line
clock.
Optional
Set the cable length cable feet The default is 14.9 meters (49
feet).
On the CT3 loopback { local | payload |
Set the interface remote } Optional
loopback Loopback is disabled by
mode On a T1 t1 line-number set loopback default.
line { local | payload | remote }
On the CT3 Optional

frame-format { c-bit | m23 }
interface The default is C-bit.
Set the
framing format Optional
On a T1 t1 line-number set frame-format
line { esf | sf } The default is ESF.
On the CT3 alarm { detect | generate { ais |

Configure Optional
interface febe | idle | rai } }
alarm signal
detection/sen Alarm detection is enabled by
On a T1 t1 line-number alarm { detect | default.
ding
line generate { ais | rai } }
On the CT3 bert pattern { 2^7 | 2^11 | 2^15 |

interface qrss } time number [ unframed ] Optional
Start a BERT
test BERT test is disabled by
t1 line-number bert pattern default.
On a T1
{ 2^11 | 2^15 | 2^20 | 2^23 | qrss }
line
time number [ unframed ]
feac detect
feac generate loopback Optional
Configure FEAC channel
{ ds3-line | ds3-payload } FEAC channel signal detection
signal detection/sending on
the CT3 interface feac generate { ds3-los | ds3-ais is enabled by default but no
| ds3-oof | ds3-idle | FEAC signals are sent.
ds3-eqptfail }
mdl { data { eic string | fic string | | Optional

Configure MDL message gen-no string | lic string | pfi string By default, MDL message
detection/sending on the | port-no string | unit string } | detection and sending are
CT3 interface detect | generate { idle-signal | disabled and the default MDL
path | test-signal } } message information applies.
1-29
t1 line-number sendloopcode
Place a T1 line on the { fdl-ansi-line-up |
far-end CT3 interface in a fdl-ansi-payload-up | Optional
loopback fdl-att-payload-up |
inband-line-up }
Optional
By default, FDL is disabled.
Set the FDL format for a T1 t1 line-number set fdl { ansi | att | This operation only applies to
channel both | none } T1 channels formed on CT3
interfaces, operating in
channelized mode, and with the
T1 frame format being ESF.
interface serial
Enter synchronous serial number/line-number:0
interface view of an interface or Required
formed by a CT3 interfaces interface serial
number/line-number:set-number
Optional
Set the CRC mode crc { 16 | 32 | none } By default, 16-bit CRC is
adopted.
Note:
FEAC = Far end and control signal; MDL = Maintenance data link; PPR = Periodical performance
report
Displaying and Maintaining CT3 Interfaces
An interface is disabled when being shut down. So perform operations of this type with caution.

Display the state information of display controller t3
CT3 interface [ interface-number ]
display interface serial
state of a serial interface Available in any view
interface-number
formed on a CT3 interface
Clear the controller counter of a reset counters controller t3
CT3 interface interface-number
Display the state of a T1 line t1 line-number show Available in CT3 interface view.
Shut down a CT3 interface shutdown Available in CT3 interface view.
Bring up a CT3 interface undo shutdown Available in CT3 interface view.
Shut down a T1 line t1 line-number shutdown Available in CT3 interface view.
1-30
undo t1 line-number
Bring up a T1 line Available in CT3 interface view.
shutdown
Note that:
z Shutting down/bringing up a CT3 interface also shuts down/brings up the T1 lines demultiplexed
from the CT3 interface, the serial interfaces formed by the T1 lines, and the serial interfaces
created on T1 lines by means of timeslot bundling.
z Shutting down/bringing up a T1 line also shuts down/brings up the serial interface formed by it and
the serial interface created on it by means of timeslot bundling.
z To shut down/bring up only a serial interface formed by T3 or T1 lines, or by timeslot bundling on a
T1 line, perform the shutdown/undo shutdown command in the view of the corresponding serial
interface.
1-31
Table of Contents
1 ATM Configuration 1-1

Introduction to ATM Technology 1-1
ATM Overview 1-1
ATM Architecture1-2
Overview of IPoA, IPoEoA, PPPoA and PPPoEoA Applications1-3
IPoA 1-3
IPoEoA 1-3
PPPoA 1-3
PPPoEoA1-3
ATM OAM 1-3
ATM Configuration Task list1-4
Configuring an ATM Interface 1-4
Configuring an ATM Subinterface1-5
Configuring an ATM Subinterface 1-5
Checking Existence of PVCs When Determining the Protocol State of an ATM P2P Subinterface
1-5
Configuring a PVC 1-6
Configuring PVC Parameters 1-6
Assigning a Transmission Priority to an ATM PVC 1-7
Configuring PVC Service Mapping1-7
Configuring an ATM Class 1-8
Configuring VP Policing 1-10
Configuring Applications Carried by ATM 1-10
Configuring IPoA 1-10
Configuring IPoEoA 1-11
Configuring PPPoA1-11
Configuring PPPoEoA 1-12
Displaying and Maintaining ATM 1-14
ATM Configuration Examples 1-14
IPoA Configuration Example 1-14
IPoEoA Configuration Example1-16
PPPoA Configuration Example 1-17
PPPoEoA Server Configuration Example 1-19
PPPoEoA Client Configuration Example1-20
ATM PVC Transmit Priority Configuration Example1-22
Troubleshooting ATM1-23
Link State Error in IPoA Application 1-23
Link Report Error in PPPoA Application 1-24
Ping Failure 1-24
ATM Interface State Error 1-24
PVC State is Down while ATM Interface State is Up 1-25
Ping Failure after PPPoA Configuration 1-25
Packet Loss and CRC Errors and Changes of Interface State 1-25
i
1 ATM Configuration
When configuring ATM, go to these sections for information you are interested in:
z Introduction to ATM Technology
z Overview of IPoA, IPoEoA, PPPoA and PPPoEoA Applications
z Overview of IPoA, IPoEoA, PPPoA and PPPoEoA Applications
z Configuring an ATM Interface
z Configuring an ATM Subinterface
z Configuring a PVC
z Configuring an ATM Class
z Configuring VP Policing
z Configuring Applications Carried by ATM
z Displaying and Maintaining ATM
z ATM Configuration Examples
z Troubleshooting ATM
Introduction to ATM Technology

ATM Overview
Asynchronous Transfer Mode (ATM) is a technology based on packet transmission mode while
incorporating the high speed of circuit transmission mode. It can satisfy the need of various
communication services. ATM was specified as a broadband ISDN transmission and switching mode
by ITU-T in June 1992. Due to its flexibility and support for multimedia services, it is regarded as the
core technology to implement broadband communications.
As defined by ITU-T, data is encapsulated in cells in ATM. Each ATM cell is 53 bytes in length, among
which 5 bytes is the cell header and the remaining 48 bytes are payloads. The major function of the cell
header is to identify virtual connection, with limited functions on flow control, congestion control and
error control.
ATM is connection-oriented and ATM connections are logical connections, or virtual connections (VCs).
Each VC is identified by a pair of virtual path identifier (VPI) and virtual channel identifier (VCI). A
VPI/VCI pair only identifies the connection established between two ATM nodes. When a connection is
released, all the VPI/VCI pairs involved are released for other connections.
ATM interfaces support permanent virtual circuits (PVCs).
1-1
ATM Architecture
ATM has a three-dimensional architecture. It consists of three planes: user plane, control plane, and
management plane. Both the user plane and the control plane are divided into four layers, namely,
physical layer, ATM layer, ATM Adaptation Layer (AAL), and upper layer, each of which are further
divided into sub-layers.
z The control plane takes the charge of establishing and tearing down connections using signaling
protocols.
z The management plane consists of layer management and plane management. The former takes
charge of managing the layers in each plane and has a layered structure corresponding to other
planes. The latter is responsible for system management and communications between different
planes.
The following figure illustrates the relationships between layers and planes in ATM.
Figure 1-1 ATM architecture
Management plane
Control plane User plane

Plane management
Upper layer Upper layer

Hierarchic al management
protocol protocol
ATM adaptation layer
ATM layer
Physical layer
The functions of the four ATM layers are as follows:

z The physical layer mainly provides transmission channels for ATM cells. At this layer, cells passed
from the ATM layer become continuous bit stream after transmission overheads are added to them.
In addition, continuous bit streams received from the physical media are restored to cells on this,
which are then passed to the ATM layer.
z The ATM layer, residing over the physical layer, implements cell-based communication with peer
layers by invoking the services provided by the physical layer. It is independent of physical media
and the implementation of the physical layer, as well as the types of the services being carried.
Data passed to this layer takes the form of 48-byte payloads, known as segmentation and
reassembly protocol data units (SAR-PDUs); and data passed from this layer to the physical layer
is 53-byte cells, with the 48-byte payload being encapsulated in a 5-byte header. Other functions of
the ATM layer include VPI/VCI transmission, cell multiplexing/demultiplexing, and generic flow
control.
z ATM Adaptation Layer (AAL) provides interfaces between high-level protocols and the ATM Layer.
It is responsible for forwarding the information between ATM layer and upper layer protocols. At
present, four types of AAL are available: AAL1, AAL2, AAL3/4, and AAL5, each of which supports
specific services provided in an ATM network. Most ATM equipment vendors adopt AAL5 for data
communication services.
z ATM upper layer protocols take charge of WAN interconnection, voice interconnection, Layer 3
interconnection, encapsulation, LAN emulation, multi-protocol over ATM, and traditional IP.
1-2
Overview of IPoA, IPoEoA, PPPoA and PPPoEoA Applications
ATM interfaces support the IPoA, IPoEoA, PPPoA and PPPoEoA applications.
IPoA
IP over ATM (IPoA) enables ATM to carry IP packets. In an IPoA implementation, ATM serves as the
data link layer protocol for IP hosts on a network. To enable the IP hosts in a network of this type to
communicate with one another, IP packets between need to be processed in the corresponding way.
IPoA makes full use of the advantage of ATM. It provides high speed point-to-point connections and
improves the bandwidth of the IP network. It also provides excellent network performance and perfect
QoS services.
IPoEoA
The architecture of IPoE over ATM (IPoEoA) contains three layers: IP layer (the uppermost layer), IP
over Ethernet (IPoE) layer, and IPoEoA layer (the bottom layer).
IPoEoA is suitable in cases where Ethernet packets are to be forwarded through ATM interfaces. For
example, if you use ATM PVC as the high-speed links between devices and remote access servers,
IPoEoA is required on ATM interfaces of the access servers to carry Ethernet packets.
As for IPoEoA,
z A virtual Ethernet (VE) interface can have multiple PVCs associated to it.
z PVCs associated to the same VE interface are interconnected at layer 2.
PPPoA
PPP over ATM (PPPoA) enables ATM to carry PPP protocol packets. With PPPoA, PPP packets, in
which IP packets or other protocols packets can be encapsulated, are encapsulated in ATM cells. In
this way, ATM may be simply viewed as the carrier of PPP packets. As the communication process of
PPPoA is managed by PPP, PPPoA also features the flexibility and comprehensive applications of PPP.
To transmit PPP packets through ATM, a virtual template (VT) interface is required. For information
about VT interfaces, refer to Logical Interface Configuration in the Access Volume.
PPPoEoA
PPPoE over ATM (PPPoEoA) enables ATM to carry PPPoE (PPP over Ethernet) protocol packets. With
PPPoEoA, Ethernet packets are encapsulated in ATM cells, through which you can use a PVC to
simulate all the functions of Ethernet. To allow ATM to carry Ethernet frames, the interface
management module provides a new type of virtual Ethernet (VE) interface. This type of VE interface
has Ethernet characteristics and can be dynamically created through configuration commands. The
following is the protocol stack adopted by the VE interface.
z ATM PVC (the bottom layer),
z Ethernet (the link layer)
z Network layer and other upper layers (the same as those for common Ethernet interfaces)
For more information about VE interface, refer to Logic Interface Configuration in the Access Volume.
ATM OAM
Normally, OAM has the following two meanings.
1-3
z Operation And Maintenance (ITU-T I.610 02/99)
z Operation Administration and Maintenance (LUCENT APC User Manual, 03/99)
OAM provides a way to detect/locate problems and monitor performance in a network without
interrupting the current services. By inserting OAM cells (which have the same structure as normal
ATM cells) in cell stream, you can obtain specific information about the entire network.
OAM is implemented on an ATM connection as follows:
Each side of the connection sends OAM cells to its peer periodically. On receiving an OAM cell, the
receiver returns the OAM cell to the sender. Each side checks the OAM cells received to see if the OAM
cells are those previously sent by itself. An ATM connection is considered normal if the round trip time
of an ATM OAM cell is within a specific period. If a specific number of successive ATM OAM cells do not
return within the period, the ATM connection is considered abnormal.
ATM Configuration Task list

Complete these tasks to configure ATM:
Task Remarks
Configuring an ATM Interface Required
Configuring an ATM Subinterface
Configuring an ATM
Checking Existence of PVCs When Determining Required
Subinterface
the Protocol State of an ATM P2P Subinterface
Configuring PVC Parameters Optional
Configuring a PVC Assigning a Transmission Priority to an ATM PVC Optional
Configuring PVC Service Mapping Optional
Configuring an ATM Class Optional
Configuring VP Policing Optional

Configuring IPoA Optional
Configuring Applications Configuring IPoEoA Optional

Carried by ATM Configuring PPPoA Optional
Configuring PPPoEoA Optional
Configuring an ATM Interface

Depending on the actual networking environment and system requirements, you may need to modify
certain parameters of an ATM interface. Note that although these parameters apply to the ATM main
interface and subinterfaces at the same time, they must be modified in ATM main interface view, except
for the mtu command, which can be executed on a subinterface.
For more information about ATM interface configuration, refer to ATM and DSL Interface Configuration
in the Access Volume.
1-4
Follow these steps to configure an ATM subinterface:

Required
interface atm
Create an ATM subinterface By default, the type of a
interface-number.subnumb
and enter its view subinterface is point-to-multipoint
er [ p2mp | p2p ]
(p2mp).
Set the MTU for the ATM Optional

mtu mtu-number
subinterface 1500 bytes by default
Optional
Set the maximum number of
tx-bd-limit value The range of the value argument
BDs allowed
varies with device models.
Optional
Shut down the ATM interface shutdown
By default, an ATM interface is up.
z When an ATM subinterface is created, the two keywords p2mp and p2p are available. The format
of the command is interface atm interface-number.subnumber [ p2mp | p2p ].
z When entering the view of an existing ATM subinterface, you cannot use the two keywords. The
format of the command becomes interface atm interface-number.subnumber.
Checking Existence of PVCs When Determining the Protocol State of an ATM P2P
Subinterface
Follow these steps to check existence of PVCs when determining the protocol state of an ATM P2P
subinterface:

Create an ATM interface atm Required

subinterface and enter its interface-number.subnum By default, the subinterface is configured
view ber p2p as point-to-multipoint (p2mp).
Check existence of PVCs Required

when determining the By default, the protocol state of the ATM
atm-link check
protocol state of the ATM P2P subinterface is consistent with the
P2P subinterface state of the physical interface.
1-5
Configuring a PVC
Configuring PVC Parameters
Follow these steps to configure PVC parameters:
Use the
To do... Remarks
command
interface atm
Enter ATM interface view or ATM { interface-number |

subinterface view interface-number.sub
number }
pvc { pvc-name Required

Create a PVC and enter PVC view
[ vpi/vci ] | vpi/vci } By default, no PVC is created.
Optional
Set the AAL5 encapsulation protocol type encapsulation
for the specified PVC aal5-encap By default, aal5snap
encapsulation is adopted.
Optional
By default, OAM F5 Loopback
oam frequency
cell transmission is disabled.
Start transmission and retransmission frequency [ up
However, if an OAM F5
detection of operations, administration, up-count down
Loopback cell is received, it
and maintenance (OAM) F5 Loopback down-count
should be responded.
cells retry-frequency
retry-frequency ] By default, up-count is 3,
down-count is 5 and
retry-frequency is 1 second.
Optional
By default, AIS/RDI alarm cell
detection is enabled, which
means the PVC goes down
Set the parameters for alarm indication oam ais-rdi up when the number of AIS/RDI
signal (AIS)/ remote defect indication up-count down alarm cells received reaches
(RDI) alarm cell detection down-count down-count and goes up if no
AIS/RDI alarm cell is received
in a period specified by the
up-count argument (in
seconds).
service cbr
Set the PVCs service type
output-pcr [ cdvt
to constant bit rate (CBR)
cdvt-value ]
Optional
Set the PVCs service type By default, the service type of
to unspecified bit rate service ubr a PVC is UBR.
Set the (UBR), and set the output-pcr
PVC The CDVT is 500s by default.
rate-related parameters
service type You can use these four
and the Set the PVCs service type commands to set the service
service vbr-nrt
rate-related to variable bit rate-non real type and the parameters
output-pcr output-scr
parameters time (VBR-NRT), and set concerning transmission rate.
output-mbs
the rate-related parameters Note that a newly configured
service type overwrites the
Set the PVCs service type existing one.
service vbr-rt
to variable bit rate-real time
output-pcr output-scr
(VBR-RT), and set the
output-mbs
rate-related parameters
1-6
Assigning a Transmission Priority to an ATM PVC
You can assign transmission priorities to ATM PVCs associated with the UBR, VBR-T, or VBR-NRT
service. At the time of bandwidth allocation, the PVC with higher priority has priority over other PVCs.
Follow these steps to assign a transmission priority to an ATM PVC:

Enter ATM interface interface atm { interface-number

view | interface-number.subnumber }
Create a PVC and
pvc { pvc-name [ vpi/vci ] | vpi/vci }
enter PVC view
Optional
Assign a transmission By default, the priority value is 0 for
transmit-priority value
priority to the ATM PVC the UBR service, 5 for the VBR-NRT
service and 8 for the VBR-RT.
Configuring PVC Service Mapping
PVC service mapping allows different PVCs from the same PVC-Group to carry IP packets of different
priorities.
Follow these steps to configure PVC service mapping:

interface atm { interface-number |
Create PVC, and enter its
view
Quit to ATM interface view quit
Required
Create a PVC group and pvc-group { pvc-name [ vpi/vci ] | Make sure that the PVC
enter PVC group view vpi/vci } specified by the pvc-name or
vpi/vci argument already exists.
Add a PVC to the
pvc { pvc-name [ vpi/vci ] | vpi/vci } Optional
PVC-Group
Set the priority of the IP ip-precedence { pvc-name [ vpi/vci ]
Optional
packets carried on PVC | vpi/vci } { min [ max ] | default }
z A primary PVC refers to the one based on which a PVC-group is created on an ATM interface.
z A secondary PVC refers to a PVC created in a PVC-group.
1-7
Configuring an ATM Class
An ATM class facilitates ATM configuration. Configurations of PVC MAP, encapsulation type, OAM
loopback, and service category can be implemented via an ATM-Class. First create an ATM class and
set the parameters needed, and then call the ATM class in PVC view or ATM interface view.
Follow these steps to configure an ATM class:

Create an ATM class and enter
atm class atm-class-name Required
ATM class view
Optional
Specify ATM AAL5 encapsulation
encapsulation aal5-encap By default, aal5snap
type for the PVC
encapsulation is adopted.
Optional
By default, OAM F5 Loopback
oam frequency frequency cell transmission is disabled.
Start transmission of OAM F5 [ up up-count down However, if an OAM F5
Loopback cells or retransmission down-count Loopback cell is received, it
check of OAM F5 Loopback retry-frequency should be responded.
retry-frequency ] By default, up-count is 3,
down-count is 5 and
retry-frequency is 1 second.
Set the PVCs service
type to constant bit service cbr output-pcr
rate (CBR)
type to unspecified
bit rate (UBR), and service ubr output-pcr Optional
Set the set the rate-related By default, the service type of a
PVCs parameters PVC is UBR.
service Set the PVCs service You can use these four
type and type to variable bit commands to set the service
rate-relate rate-non real time service vbr-nrt output-pcr type and the parameters
d (VBR-NRT), and set output-scr output-mbs concerning transmission rate.
parameter the rate-related Note that a newly configured
s parameters service type overwrites the
existing one.
type to variable bit
rate-real time service vbr-rt output-pcr
(VBR-RT), and set output-scr output-mbs
the rate-related
parameters
1-8
Required
By default, mapping is not
configured. When a mapping is
configured, pseudo-broadcast
is not supported by default.
Configure IPoA and Before configuring InARP,
Configure enable inverse map ip inarp [ minutes ] make sure the aal5snap
the service address resolution [ broadcast ] encapsulation is used. Though
type (use (InARP) for the PVC InARP is also supported when
different using aal5mux or aal5nlpid
commands encapsulation, the system will
according prompt a message indicating a
to service failure when this ATM is
types) configured and used on PVC.
Establish PPPoA map ppp virtual-template
Required
mapping for the PVC vt-number
Establish IPoEoA or map bridge
PPPoEoA mapping virtual-ethernet Required
for the PVC interface-number
interface atm
Enter ATM Enter ATM interface { interface-number |
Required
interface view interface-number.subnumb
view or er }
PVC view pvc { pvc-name [ vpi/vci ] |
Enter PVC view Required
vpi/vci }
Enable the ATM class on the
atm-class atm-class-name Required
interface or PVC
When configuring a PVC, note that:

z The priorities of the same configurations performed to a PVC descend in this order: the
configuration directly performed to the PVC, the configuration performed to the ATM class applied
to the PVC, and the configuration performed to the ATM class applied to the ATM interface.
z For different configurations that conflict with each other, their priorities descend in this order: the
configuration directly performed to the PVC, the configuration performed to the ATM class applied
to the PVC, and the configuration performed to the ATM class applied to the ATM interface.
z All the configurations that are directly performed to the PVC, performed to the ATM class applied to
the PVC, and performed to the ATM class applied to the ATM interface take effect if they do not
conflict.
z For different configurations performed to a PVC, the ATM class applied to the PVC, and the ATM
class applied to the ATM interface, if the configurations conflict with each other, those applied first
take effect, and the conflict prompt appears when the rest are performed.
z When an ATM class is applied to a PVC, no message is prompted no matter whether or not the
ATM class is successfully applied.
z Error messages appear when configurations performed to a PVC are invalid.
1-9
Configuring VP Policing
VP policing is used to set the sustainable rate of a virtual path identifier (VPI). When applying VP
policing, the parameters of PVC are still valid. Only when the parameters of PVC and VP policing are
satisfied, will the packets be transmitted or received. In calculating the traffic, the LLC/SNAP, MUX and
NLPID headers are included, but the ATM cell header is not included.
Follow these steps to set the parameters of VP policing:

Enter ATM interface view interface atm interface-number
Set the parameters of VP policing pvp limit vpi output-scr Required
Configuring Applications Carried by ATM

Although ATM can carry multiple protocols, a specific encapsulation type may not support ATM
applications (such as IPoA, IPoEoA, PPPoA, and PPPoEoA), as listed in the following table.
Table 1-1 Support for ATM applications
ATM application aal5snap aal5mux aal5nlpid

IPoA Supported Supported Supported
IPoEoA Supported Supported Not supported
PPPoA Supported Supported Not supported
PPPoEoA Supported Supported Not supported
z As for the service vbr-nrt command, due to the hardware limitation, the command cannot be
executed successfully if the output-scr argument is within the range 64 to 70 and the output-mbs
argument is within the range 475 to 512.
z With aal5snap adopted, two or more protocols are supported. But for aal5nlpid, you cannot enable
InARP on a PVC for an IPoA application.
Configuring IPoA
Follow these steps to configure IPoA:

interface atm { interface-number |
Create a PVC, and enter
PVC view
1-10
Required
By default, no mapping is
configured. If a mapping is
configured, pseudo-broadcast is
Configure an IPoA
map ip { ip-address [ ip-mask ] | not supported by default.
mapping for the PVC, and
default | inarp [ minutes ] } Before configuring InARP, make
enable the PVC to carry IP
[ broadcast ] sure that aal5snap
packets
encapsulation is used. InARP is
not supported when aal5mux or
aal5nlpid encapsulations is
adopted.
If you execute the map ip command with the broadcast keyword, which specifies pseudo broadcast,
any broadcast packets received by the port on which the PVC is created will be duplicated to the PVC.
Therefore, to propagate broadcast/multicast packets on an ATM PVC, you must specify the broadcast
keyword.
Configuring IPoEoA
Follow these steps to configure IPoEoA on PVC:

Required
Create a virtual Ethernet (VE) interface virtual-ethernet The IP address has to be
interface interface-number configured on a VE interface (It
is invalid to configure the IP
address on the ATM interface).
interface atm
Enter ATM interface view { interface-number |
pvc { pvc-name [ vpi/vci ] |
Create PVC and enter its view Required
vpi/vci }
Configure IPoEoA mapping on map bridge virtual-ethernet
Required
the PVC interface-number
Configuring PPPoA
When two routers are connected using DSL interfaces through a dial-up connection, configure them as
PPPoA server and client respectively. The two are different in that, with the PPPoA server, you should
configure an address pool to allocate an IP address for the remote node; with the PPPoA client, you
should configure address negotiation to accept the IP address allocated by the server end. For relevant
information, refer to PPP Configuration in the Access Volume.
1-11
The following configurations enable the PVC to carry PPP and configure a PPP mapping for the PVC.
Follow these steps to configure PPPoA:

Required
You must configure
PPP authentication and
interface virtual-template IP address on the VT
Create a VT interface
vt-number interface (the IP
address is invalid if
configured on the ATM
interface).
Set the PPP authentication mode and
IP address; with the PPPoE server,
an address pool should be configured
to allocate an IP address for the Refer to PPP Configuration in
Required
remote end; with the PPPoE client, the Access Volume.
address negotiation should be
configured to accept the IP address
allocated by the server end
interface atm
Enter ATM interface view { interface-number |
Create PVC, and enter PVC view Required
vpi/vci }
Configure PPPoA mapping for the map ppp virtual-template
Required
PVC vt-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 is valid.
Configuring PPPoEoA
PPPoE adopts the Client/Server model. It encapsulates PPP packets into Ethernet frames and
provides point-to-point connection on Ethernet. The following configurations enable the PVC to carry
PPPoE and configure a PPPoE mapping for the PVC.
Follow these steps to configure PPPoEoA:

1-12
Required
You must configure PPP
interface virtual-template authentication and an IP
Create a VT interface address on the VT interface
vt-number
(the IP address is invalid if
configured on the ATM
interface).
Set the PPP authentication mode
and IP address; with the PPPoE
server, an address pool should be
configured to allocate IP address for Refer to PPP Configuration
Required
the peer end; with the PPPoE client, in the Access Volume.
address negotiation should be
configured to accept the IP address
allocated by the server end.
interface virtual-ethernet
Create a VE interface Required
interface-number
Configure PPPoE parameters on
VE interface (the configuration Refer to PPP Configuration
Required
differs when with a PPPoE server in the Access Volume.
and when with a PPPoE client)
interface atm
{ interface-number |
interface-number.subnum
ber }
Create PVC, and enter PVC view Required
vpi/vci }
Required
map bridge The interface-number
Create PPPoEoA mapping for PVC virtual-ethernet argument refers to the VE
interface-number interface created in the above
steps.
the physical interface bound to the virtual-template is valid.
1-13
Displaying and Maintaining ATM
Display the relevant information display atm interface [ atm
of ATM interface interface-number ]
display atm pvc-info [ interface
Display the relevant information
interface-type interface-number [ pvc Available in any view
of the PVC
{ pvc-name [ vpi/vci ] | vpi/vci } ] ]
display atm map-info [ interface
Display the information of the
interface-type interface-number [ pvc Available in any view
PVC mapping
display atm pvc-group [ interface
Display PVC-Group information interface-type interface-number [ pvc Available in any view
Display the relevant information
display atm class [ atm-class-name ] Available in any view
of the ATM-Class
Send OAM cells on the
specified PVC on the interface
oamping interface atm
to test connectivity of the link Available in ATM
interface-number pvc { pvc-name | vpi
depending on whether interface view
/vci } [ number timeout ]
response is returned before the
specified timeout time
Available in ATM
Shut down an ATM interface shut down
interface view
ATM Configuration Examples
In the following examples, the network device, the digital subscriber line access multiplexer (DSLAM)
and its configuration command sequence are MA 5100 multi-business access device and the
corresponding command sequence under its configuration environment. The ADSL router is
configured according to the actual selected devices in the actual networking environment. For complete
details about configuration commands, please refer to the corresponding command manuals. With
regard to practical networking, the network devices might be different from the assumed devices in
terms of networking capacity and configuration command format. This situation is subject to exist
without notice.
IPoA Configuration Example
As shown in Figure 1-2, Router A, B and C are connected to the ATM network for intercommunication.
The requirements are:
The IP addresses of their ATM interfaces of the three routers are 202.38.160.1/24, 202.38.160.2/24,
and 202.38.160.3/24 respectively;
1-14
In the ATM network, the VPI/VCI of router A is 0/40 and 0/41, connecting to router B and router C
respectively. The VPI/VCI of router B is 0/50 and 0/51, connecting to router A and C respectively. The
VPI/VCI of router C is 0/60 and 0/61, connected with router A and B respectively;
All the PVCs on ATM interfaces of the three routers work in IPoA application mode.
Network diagram
Figure 1-2 Network diagram for IPoA configuration
# Enter the ATM interface, and configure an IP address for it.
[RouterA] interface atm 1/0
[RouterA-Atm1/0] ip address 202.38.160.1 255.255.255.0
# Establish a PVC, running IP.

[RouterA-Atm1/0] pvc to_b 0/40
[RouterA-atm-pvc-Atm1/0-0/40-to_b] map ip 202.38.160.2
[RouterA-atm-pvc-Atm1/0-0/40-to_b] quit
[RouterA-Atm1/0] pvc to_c 0/41
[RouterA-atm-pvc-Atm1/0-0/41-to_c] map ip 202.38.160.3
[RouterB] interface atm 1/0
[RouterB-Atm1/0] ip address 202.38.160.2 255.255.255.0
# Establish a PVC, running IP.

[RouterB-Atm1/0] pvc to_a 0/50
[RouterB-atm-pvc-Atm1/0-0/50-to_a] map ip 202.38.160.1
[RouterB-atm-pvc-Atm1/0-0/50-to_a] quit
[RouterB-Atm1/0] pvc to_c 0/51
[RouterB-atm-pvc-Atm1/0-0/51-to_c] map ip 202.38.160.3
3) Configure Router C
1-15
<RouterC> system-view
[RouterC] interface atm 1/0
[RouterC-Atm1/0] ip address 202.38.160.3 255.255.255.0
# Establish a PVC and specify it to carry IP.

[RouterC-Atm1/0] pvc to_a 0/60
[RouterC-atm-pvc-Atm1/0-0/60-to_a] map ip 202.38.160.1
[RouterC-atm-pvc-Atm1/0-0/60-to_a] quit
[RouterC-Atm1/0] pvc to_b 0/61
[RouterC-atm-pvc-Atm1/0-0/61-to_b] map ip 202.38.160.2
IPoEoA Configuration Example
As shown in Figure 1-3, each of the hosts in the two Ethernets is respectively connected to the ATM
network through an ADSL Router, and they communicate with router C via DSLAM. The requirements
are:
The IP address of the VE interface of Router C is 202.38.160.1;
The VPI/VCI value of two PVCs connecting route C and DSLAM are 0/60 and 0/61, pointing to Router
A and Router B respectively.
Both the WAN port of Router C and the DSL interfaces of the ADSL Routers adopt IPoEoA.
Network diagram
Figure 1-3 Network diagram for IPoEoA configuration
ADSL Router A
Host A
Router A VE1
DSLAM 202.38.160.1/24
Host B
Router C
ATM1/0.1
VPI/VCI:
To Router A:0/60
Router B To Router B:0/61
Host C
ADSL Router B
Host D
Configure Router C:
# Create a VE interface and configure an IP address for it.
[RouterC] interface virtual-ethernet 1
[RouterC-Virtual-Ethernet1] ip address 202.38.160.1 255.255.255.0
[RouterC-Virtual-Ethernet1] quit
1-16
# Create a PVC and specify it to support IPoE.
[RouterC] interface atm 1/0.1
[RouterC-Atm1/0.1] pvc to_adsl_a 0/60
[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] map bridge virtual-ethernet 1
[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] quit
[RouterC-Atm1/0.1] pvc to_adsl_b 0/61
[RouterC-atm-pvc-Atm1/0.1-0/61-to_adsl_b] map bridge virtual-ethernet 1
PPPoA Configuration Example
As shown in Figure 1-4, two hosts dial into the ATM network each through an ADSL Router, and
communicate with Router C through DSLAM. The requirements are:
z To create VT for multi-user on Router C, and configure PPP mapping on VT.
The VPI/VCI value of two PVCs connecting Route C and DSLAM are 0/60 and 0/61, pointing to ADSL
Router A and ADSL Router B respectively.
z Both the WAN port of Router C and the DSL interfaces of the two ADSL routers adopt PPPoA. The
authentication mode of ADSL Router is PAP. The IP addresses of the two ADSL Routers are
assigned by Router C.
Network diagram
Figure 1-4 Network diagram for PPPoA configuration

ADSL Router A
ATM1/0.1
Host A Router A VPI/VCI:
To Router A:0/60
To Router B:0/61
Router C
VT10
DSLAM 202.38.160.1/24
Router B VT11
202.38.161.1/24
Host B ADSL Router B
1) Configure Router C (PPPoA Server)

# Create users for PPP authentication, and establish a local IP address pool.
[RouterC] local-user user1
[RouterC-luser-user1] service-type ppp
[RouterC-luser-user1] password simple pwd1
[RouterC-luser-user1] quit
1-17
[RouterC] domain system
[RouterC-isp-system] authentication ppp local
[RouterC-isp-system] ip pool 1 202.38.162.1 202.38.162.100
[RouterC-isp-system] quit
# Create a VT interface, configure PAP authentication and an IP address, and allocate an IP address
for the remote end from the IP address pool.
[RouterC] interface virtual-template 10
[RouterC-Virtual-Template10] ip address 202.38.160.1 255.255.255.0
[RouterC-Virtual-Template10] ppp authentication-mode pap
[RouterC-Virtual-Template10] remote address pool 1
[RouterC-Virtual-Template10] quit
[RouterC-Virtual-Template11] remote address pool 1
# Create a PVC, and specify it to carry PPP.

[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] map ppp virtual-template 10
[RouterC-atm-pvc-Atm1/0.1-0/61-to_adsl_b] map ppp virtual-template 11
2) Configure ADSL Router A (PPPoA Client)
# Create a VT interface, and configure PAP authentication and IP address negotiation.
[RouterA] interface Virtual-Template 0
[RouterA-Virtual-Template0] ppp pap local-user user1 password simple pwd1
[RouterA-Virtual-Template0] ip address ppp-negotiate
[RouterA-Virtual-Template0] quit
# Create a PVC, and specify it to run PPP.

[RouterA-Atm1/0] pvc pppoa 0/37
[RouterA-atm-pvc-Atm1/0-0/37-pppoa] map ppp virtual-template 0
The configuration of ADSL Router B is similar to that of Router A.
If the client cancels the IP address it has received through address negotiation, or the client is
configured with a fixed IP address, the communication between the server and the client will fail. In this
case, you need to shut down the ATM interface first, and delete the IP address pool on the server.
1-18
PPPoEoA Server Configuration Example
As shown in Figure 1-5, each host inside Ethernet dials into ATM network through an ADSL router, and
communicates with the router through DSLAM. The requirements are:
The IP addresses of the VT interface of router C are 202.38.160.1 and 202.38.161.1.
The VPI/VCI addresses of two PVCs connecting router C with DSLAM are 0/60 and 0/61, pointing to
ADSL Router A and ADSL Router B respectively.
Both the WAN port of router C and the DSL interface of ADSL Router adopt PPPoEoA. Each host within
the two Ethernets uses pre-installed PPPoE Client program to make interactive PAP authentication with
routers, and obtains an IP address from the router.
Network diagram
Figure 1-5 Network diagram for PPPoEoA server configuration
ADSL Router
Host A
ATM1/0.1
Router A VPI/VCI:
To Router A:0/60
Host B To Router B:0/61
Router C
VT10
DSLAM
Router B 202.38.160.1/24
VT11
Host C 202.38.161.1/24
ADSL Router
Host D
Configure Router C:
# Configure the users in the domain to use the PPP authentication scheme, and create a local IP
address pool.
[RouterC]domain system
[RouterC-isp-system] ip pool 1 202.38.162.1 202.38.162.100
[RouterC-isp-system] quit
1-19
# Create the VT interface to encapsulate the PPP protocol and configure PAP authentication
parameters.
# Create the VE interface to encapsulate the PPP protocol.

[RouterC-Virtual-Ethernet1] pppoe-server bind virtual-template 10
[RouterC-Virtual-Ethernet2] pppoe-server bind virtual-template 11
# Establish a PVC and specify it to carry PPPoE.

[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] map bridge virtual-ethernet 1
[RouterC-atm-pvc-Atm1/0.1-0/61-to_adsl_b] map bridge virtual-ethernet 2
For details about configuring a RADIUS scheme, refer to AAA RADIUS HWTACACS Configuration in
the Security Volume.
PPPoEoA Client Configuration Example
As shown in Figure 1-6, the Ethernet interface IP address of Router A serves as the gateway of all PCs
in LAN. Router A is directly connected to the ADSL accessing end of public network via the ADSL card
to serve as the client of PPPoEoA (ATM1/0 is the port number of the ADSL card). The Server, PPPoEoA
authentication server of public network, is used to authenticate user information via CHAP.
1-20
Network diagram
Figure 1-6 Network diagram for ADSL PPPoEoA Client
1) Configure Router A:
# Configure user name and password:
[RouterA] local-user Sysname
[RouterA-luser-Sysname] password simple hello
[RouterA-luser-Sysname] service-type ppp
[RouterA-luser-Sysname] quit
# Configure dialing access control list:

[RouterA] dialer-rule 10 ip permit
# Create dialer port and configure the dial-up and PPP authentication:
[RouterA] interface dialer0
[RouterA-Dialer0] link-protocol ppp
[RouterA-Dialer0] ppp chap password hello
[RouterA-Dialer0] ppp chap user user1
[RouterA-Dialer0] ip address ppp-negotiate
[RouterA-Dialer0] dialer user ABC
[RouterA-Dialer0] dialer-group 10
[RouterA-Dialer0] dialer bundle 12
[RouterA-Dialer0] quit
# Create a VE interface:
[RouterA] interface virtual-ethernet 2
[RouterA-Virtual-Ethernet2] quit
# Configure the ATM interface of ADSL card:

[RouterA] interface atm1/0
[RouterA-Atm1/0] pvc 0/32
[RouterA-atm-pvc-Atm1/0-0/32] map bridge virtual-ethernet 2
[RouterA-atm-pvc-Atm1/0-0/32] quit
# Configure a VE port:
[RouterA] interface virtual-ethernet 2
[RouterA-Virtual-Ethernet2] pppoe-client dial-bundle-number 12
1-21
# Configure the default route:
[RouterA] ip route-static 0.0.0.0 0.0.0.0 Dialer 0
2) If the PPPoEoA Server is of the same type of router, its PPPoEoA can be configured as follow:
# Configure user features.
[Sysname] local-user user1
[Sysname-luser-user1] password simple hello
[Sysname-luser-user1] service-type ppp
# Create a virtual-template, set the authentication mode to CHAP, and configure the IP address.
[Sysname] interface Virtual-Template 0
[Sysname-Virtual-Template0] ppp authentication-mode chap
[Sysname-Virtual-Template0] ppp chap user Sysname
[Sysname-Virtual-Template0] ip address 10.1.1.1 255.255.0.0
[Sysname-Virtual-Template0] remote address pool 80
[Sysname-Virtual-Template0] quit
# Configure the users in the domain to use the local authentication scheme, and create a local IP
address pool.
[Sysname] domain system
[Sysname-isp-system] scheme local
[Sysname-isp-system] ip pool 80 10.1.1.2 10.1.1.100
# Configure a VE interface.
[Sysname] interface virtual-ethernet 1
# Enable PPPoE Server on the VT specified on the virtual Ethernet interface.

[Sysname-Virtual-Ethernet1] pppoe-server bind virtual-template 0
[Sysname-Virtual-Ethernet1] mac-address 0022-0022-00C1
[Sysname-Virtual-Ethernet1] quit
# Configure ATM interface 1/0.

[Sysname] interface atm1/0
[Sysname-Atm1/0] pvc 0/32
[Sysname-atm-pvc-Atm1/0-0/32] map bridge virtual-ethernet 1
After the above-mentioned configuration, the link layer is able to work normally, and the PCs can
communicate with the server via the ATM upper layer protocols.
ATM PVC Transmit Priority Configuration Example
As shown in Figure 1-7, you need to create PVC 1 and PVC 2 on the same ATM 155 Mbps interface,
each assigned 100 Mbps of bandwidth and associated with the UBR service. Set the transmission
priority of PVC 1 to 1 and that of PVC 2 to 3.
Let Router A distribute equal amount of traffic to Router B on two PVCs and observe the statistics about
received/sent/dropped packets.
1-22
Network diagram
Figure 1-7 Network diagram for ATM PVC priority configuration
Configure Router A:
# Configure the ATM interface.
[RouterA-Atm1/0] ip address 202.38.160.1 255.255.255.0
# Create two PVCs and assign them different transmission priority values.
[RouterA-Atm1/0] pvc 1 0/33
[RouterA-atm-pvc-Atm1/0-0/33-1] map ip 202.38.160.2
[RouterA-atm-pvc-Atm1/0-0/33-1] service ubr 100000
[RouterA-atm-pvc-Atm1/0-0/33-1] transmit-priority 1
[RouterA-atm-pvc-Atm1/0-0/33-1] quit
[RouterA-Atm1/0] pvc 2 0/32
[RouterA-atm-pvc-Atm1/0-0/32-2] map ip 202.38.160.3
[RouterA-atm-pvc-Atm1/0-0/32-2] service ubr 100000
[RouterA-atm-pvc-Atm1/0-0/33-1] transmit-priority 3
After two equal traffics that exceed the ATM bandwidth are sent to Router B, you can use the display
atm pvc-info interface atm 1/0/0 pvc command on Router B to view statistical results for each PVC
(you can make several tests and observe the average statistical value). You can see that the PVC with
higher priority receives more packets than that with lower priority. In other words, the PVC with the
higher priority takes preference in getting bandwidth and other PVCs (if there are many and with
different priority values), regardless of their priority values, are treated equally in terms of bandwidth
allocation.
Troubleshooting ATM
Link State Error in IPoA Application
Symptom:
When IPoA is used, the link state is down.
Solution:
Make sure that the optical fiber is plugged in correctly.

Make sure that the local IP address has been configured.
Make sure that the PVC is successful created and communication between cards is normal.
1-23
Link Report Error in PPPoA Application
Symptom:
When PPPoA is used, the link does not report UP.
Solution:
Refer to Link State Error in IPoA Application.
Ping Failure
Symptom:
The physical layer of the interfaces and the line protocol are both UP, but when tested with the ping
command, the two ends are mutually unreachable.
Solution:
z If IPOA is used, make sure that the IP protocol address mapping is configured correctly. If the
interfaces of two routers are connected back-to-back, the local PVC mapped to the remote IP must
have the same VPI/VCI value as the remote PVC mapped to the local IP. In addition, the IP
addresses of the two ends must also be in the same network segment.
z If two routers are connected back-to-back, make sure that at least one of interfaces uses internal
transmission clock (master). Or, if the routers are connected to the ATM network, the transmission
clock should be set to line clock.
z Check the ATM interfaces of the two sides to make sure that they are of the same type, for
example, both are multimode fiber interfaces or both are single mode fiber interfaces, or both are
multimode fiber interfaces but connected using single mode. If a multimode fiber interface and a
single mode fiber interface are directly connected, they can communicate in most cases, but
sometimes with frequent packet dropping and CRC errors.
z If the two ends are PPPoA, make sure that their IP addresses (should be in the same network
segment) and authentication parameters are correctly configured.
z If, according to the ping command, small packets can pass but big packets cannot, make sure that
the mtu configurations of the two router interfaces are the same.
ATM Interface State Error
Symptom:
The interface state of ATM is DOWN.
Solution:
Make sure that the optical fibers are correctly plugged to ATM interface. There should be two optical
fibers, one for receiving information and one for sending information. The two are not exchangeable. If
they are wrongly plugged, the interface state of ATM cannot be UP.
If two routers are connected back-to-back, check if neither of the two ATM interfaces enables internal
transmission clock. By default, routers use line clock. If two routers are connected back-to-back, one of
them should be configured as internal transmission lock with the clock master command.
1-24
PVC State is Down while ATM Interface State is Up
Symptom:
The interface state of ATM is UP, but the PVC state is DOWN.
Solution:
Check if this fault results from enabling OAM F5 Loopback cell transmission and retransmission
detection. When two ATM devices are connected, the VPI/VCI value of the PVCs on the two devices
must be the same. Provided that OAM F5 cell transmission and retransmission detection is enabled,
and the VPI/VCI value of the remote node (connected directly with the local node) is not the same as
the local node, the local PVC state cannot change into UP.
Ping Failure after PPPoA Configuration
Symptom:
The PVC state is UP, but after applications like IPoA are configured, the remote node cannot be
successfully pinged.
Solution:
Make sure that the remote node supports the same application as configured on the local node. For
example, if the local node uses PPPoA, the remote node should also use PPPoA.
If the remote node supports the same application configured on the local node, make sure that the two
sides use the same type of AAL5 encapsulation protocol. For example, if one side uses SNAP whereas
the other uses MUX, they cannot communicate. You can enable the packet debugging function of ATM
to get some clues.
Packet Loss and CRC Errors and Changes of Interface State
Symptom:
Two routers are connected back-to-back, and a ping between them is successful, but sometimes there
are large amount of packets lost and frequent CRC errors, or the interface state alternates between UP
and DOWN.
Solution:
Check the ATM interfaces of the two nodes to see if their types are the same, namely, both are
multimode fiber interface or both are single mode fiber interface. If their types are different, you should
change one of them. In most cases, when a multimode fiber interface and a single mode fiber interface
are directly connected, they can communicate, but sometimes with the above-mentioned faults.
1-25
Table of Contents
1 DCC Configuration 1-1

Introduction to DCC1-1
Overview1-1
Approaches to DCC1-2
DCC Features1-4
Preparing for DCC Configuration 1-5
DCC Configuration 1-5
DCC Configuration Task List1-5
Configuring C-DCC1-7
Configuring RS-DCC 1-14
Configuring MP for DCC1-17
Configuring PPP Callback 1-18
Configuring ISDN Caller Identification Callback1-22
Configuring Advanced DCC Functions1-24
Configuring DCC Timers and Buffer Queue Length1-26
Configuring Traffic Statistics Interval1-27
Displaying and Maintaining DCC 1-27
DCC Configuration Examples 1-27
C-DCC Application 1-28
RS-DCC Application 1-30
DCC Application on ISDN1-34
RS-DCC Application with MP 1-38
Router-to-Router Callback with DCC (PPP Approach) 1-41
Router-to-Router Callback with DCC (ISDN Approach)1-43
Router-to-PC Callback with DCC 1-44
NT Server-to-Router Callback with DCC1-47
Circular Dial String Backup and Internet Access with DCC 1-48
Troubleshooting Cases1-54
i
1 DCC Configuration
When configuring DCC, go to these sections for information you are interested in:
z Introduction to DCC
z DCC Configuration
z Displaying and Maintaining DCC
z DCC Configuration Examples
z Troubleshooting
Introduction to DCC
z Overview
z Approaches to DCC
z DCC Features
z Preparing for DCC Configuration
Overview
Dial Control Center (DCC) is a routing technology adopted when routers interconnect through a public
switched network like a Public Switched Telephone Network (PSTN) or an Integrated Services Digital
Network (ISDN). It can provide the dial-on-demand service where any two routers dial to set up
connection when data needs transferring instead of setting up connection before that. When the link
becomes idle, DCC automatically disconnects it.
Under certain circumstances, connections between routers are instantly established whenever there is
data to be transferred, so data transfer is time-independent, bursty, and small-sized. DCC is a flexible,
economical and efficient solution for such applications. In DCC, backup mechanisms are available to
guarantee communications. In case a primary line fails, DCC switch traffic over to a secondary line to
ensure ongoing services.
At present, Frame Relay (FR) is widely applied. Usually, users access Frame Relay networks through
leased lines. To reduce the cost and speed up accesses, Frame Relay over ISDN (FRoI) technology
can be used instead. Meanwhile, ISDN can act as a backup to FR access.
1-1
Approaches to DCC
Two approaches are available to DCC: circular DCC (C-DCC) and resource-shared DCC (RS-DCC).
They are suitable for different applications. In practice, the two parties in a call do not necessarily adopt
the same approach.
DCC Terms
z Physical interface: An interface that physically exists. Examples are serial, BRI, and asynchronous
interfaces.
z Dialer interface: Logical interface created for configuring DCC parameters. A physical interface can
inherit the DCC configurations after it is assigned to a dialer interface.
z Dial interface: Any interface used for dialup connection. It can be a dialer interface, a physical
interface assigned to a dialer interface, or a physical interface directly configured with DCC
parameters.
C-DCC
1) Features of C-DCC
z A logical dial (dialer) interface can contain multiple physical interfaces, but a physical interface can
be assigned only to one dialer interface. That is, a physical interface can only provide one type of
dial service.
z You may assign a physical interface to a dialer interface to inherit DCC parameters by assigning it
to a dialer circular group, or directly configure DCC parameters on the physical interface.
z All the physical interfaces in a dialer circular group inherit the attributes of the same dialer interface.
z You may associate a dialer interface with multiple call destination addresses by configuring the
dialer route command or with a single call destination address by configuring the dialer number
command.
C-DCC is powerful and has broad applications. However, it lacks flexibility and extensibility.
For example, on an ISDN BRI interface, all the B channels inherit its configuration in the C-DCC
approach. The static binding between call destination address settings and physical interface
configurations will restrict the use of C-DCC, as dialer routes are becoming increasingly complicated as
a result of network growth and support to more protocols.
2) Association of physical interfaces and dialer interfaces in C-DCC
1-2
Figure 1-1 Association between physical interfaces and dialer interfaces
As shown in the above figure, a physical interface can be assigned to only one dialer interface, but each
dialer interface can contain multiple physical interfaces and be mapped to multiple destination
addresses. In addition, a physical interface does not necessarily belong to any dialer interface. You may
directly map it to one or multiple destination addresses.
In the figure, physical interfaces Serial 2/1, BRI 1/1 and Serial 2/2 are assigned to Dialer2, where
mappings between dial strings and destination addresses are configured.
RS-DCC
1) Different from C-DCC, RS-DCC separates logical configuration from physical configuration. Thus,
it is simpler and more flexible. RS-DCC delivers these features:
z Physical interface configuration and logical configuration for calls are separate. They are
associated dynamically when triggered by calls. This allows a physical interface to provide services
for different dial applications.
z Associations between dialer interfaces and call destination address are one-to-one. You may
configure them with the dialer number command.
z Each dialer interface can contain multiple physical interfaces, and each physical interface can be
assigned to multiple dialer interfaces.
z Dial attributes, such as dialer interface, dialer bundle, and physical interface, are described by an
RS-DCC set. All the calls destined to the same network use the same RS-DCC set.
z RS-DCC parameters cannot be directly configured on physical interfaces. A physical interface can
participate in RS-DCC only after it is assigned to a dialer interface.
2) Association of physical interfaces, dialer bundles and dialer interfaces in RS-DCC
1-3
Figure 1-2 Association of physical interfaces, dialer bundles and dialer interfaces
As shown in the above figure, a physical interface can be assigned to multiple dialer bundles and serve
for multiple dialer interfaces, but each dialer interface can use only one dialer bundle and configured
with one dial string. The physical interfaces in a dialer bundle can be assigned different priorities.
In the figure, interface Dialer2 uses Dialer bundle 2 that contains physical interfaces BRI 1/0, BRI 1/1
and Serial 2/1. Suppose BRI 1/0 is assigned the priority of 100, BRI 1/1 the priority of 50, and Serial 2/1
the priority of 75. Since BRI 1/0 has a higher priority over BRI 1/1 and Serial 2/1, it will be preferred first
when Dialer2 wants to place a call.
DCC Features

z Basic DCC features
z Callback through DCC
Basic DCC features
The following are basic DCC features:

z Support a wide range of dial interfaces, such as synchronous/asynchronous serial interface, AUX
port, ISDN BRI or PRI interface, and AM interface to accommodate to different networking
requirements.
z Support link layer protocols such as PPP and FR on dial interfaces (physical or dialer).
z Support IP on dial interfaces.
z Support dynamic routing protocols such as RIP and OSPF on dial interfaces.
z Provide flexible dial interface backup
z Allow you to manage different modems at the user interface.
Callback through DCC
In callback, the called party originates a return call to the calling party. The calling party is the client, and
the called party is the server. The callback client originates a call first, and the callback server decides
whether to originate a return call. If a callback is needed, the server will immediately disconnect and
originate a return call.
1-4
DCC callback brings these benefits:
z Enhance security: When placing a return call, the server dials the calling number configured at the
local end. This prevents the insecurity resulted from user name and password compromise.
z Change the charge bearer. This is useful for saving cost in the case that the call rates in two
directions are different.
z Consolidate call charge bills to facilitate settlement.
At present, PPP callback and ISDN caller identification callback features are available. The PPP
callback conforms to RFC1570 specifications and can be used where both client and server own fixed
network addresses, or the client accepts dynamic network address assignment.
Preparing for DCC Configuration
When preparing for DCC configuration, you need to do the following:

z Identifying the topology of DCC application
z Making basic configuration
z Configuring DCC parameters
Identifying the topology of DCC application
You need to identify:

z Which routers will provide DCC and how they are related to each other.
z Which interfaces on the routers will provide DCC, and which roles they will be playing.
z Which transmission medium will be used, PSTN or ISDN.
Making basic configuration
Before configuring DCC on an interface, do the following:

z Identify interface type (synchronous/asynchronous serial, ISDN BRI or PRI, AM, or AUX) and
configure physical interface parameters.
z On the dial interface enable PPP, HDLC, FR, X.25, or some other link layer protocol encapsulation.
z Configure the network protocol, IP for example.
z Configure the routing protocol, RIP or OSPF for example.
z Select a DCC approach, C-DCC or RS-DCC.
Configuring DCC parameters
Configure DCC parameters depending on the DCC approach you selected for basic DCC dial functions.
Based on that, you may configure advanced functions such as MP, PPP callback, ISDN caller
identification callback, ISDN leased line, and auto-dial. You can also tune the attribute values of DCC
dial interfaces depending on link conditions.
DCC Configuration
DCC Configuration Task List
Complete these tasks to configure DCC:
Task Remarks
Configuring Basic Parameters for DCC Required
Configuring C-DCC Required
1-5
Task Remarks
Configuring RS-DCC
Optional
Configuring MP for DCC
Configuring PPP Callback Optional
Configuring ISDN Caller Identification Callback Optional

Configuring Advanced DCC Functions Optional
Configuring DCC Timers and Buffer Queue Length Optional
Configuring Traffic Statistics Interval Optional
Configuring Basic Parameters for DCC
Regardless of which DCC approach is used, C-DCC or RS-DCC, you must perform the tasks described
in this section.
Complete these tasks to configure basic parameters for DCC:
Task Remarks
Optional
Configuring physical interfaces Skip this task when configuring on ISDN
BRI or PRI interfaces.
Configuring link layer/network/routing protocol on the
Required
dial interface
Associating a DCC dial ACL with the dial interface Required
Configuring physical interfaces
For a synchronous/asynchronous serial interface, you must set its operating mode depending on the
connected modem. If the connected modem is asynchronous, set the interface to operate in
asynchronous mode and then enable modem dial on the corresponding user interface. If the connected
modem is synchronous, set the interface to operate in synchronous mode.
For detailed configurations, refer to WAN Interface Configuration and Modem Configuration in the
Access Volume.
Configuring link layer/network/routing protocol on the dial interface
In dial interface (physical or dialer) view, configure link layer protocol encapsulation with the
link-protocol command and assign the dial interface an IP address with the ip address command.
In system view, perform other configurations.
When PPP encapsulation is configured, you may configure PAP or CHAP authentication in addition.
Moreover, consider the following when configuring PPP related commands:
z In C-DCC approach, make the configuration on dialer interfaces.
z In RS-DCC approach, make the configuration on dialer interfaces and preferably the same
configuration on physical dial interfaces on the calling side to guarantee the reliability of PPP link
parameters negotiation; on the called side, make the configuration on physical dial interfaces.
For detailed configurations, refer to the Access Volume, the IP Services Volume, and the IP Routing
Volume.
1-6
Associating a DCC dial ACL with the dial interface
You may configure a dial ACL to filter traffic that traverses a dial interface. Packets fall into two
categories, depending on whether they are in compliance with the permit or deny statements in the dial
ACL.
z Packets that match a permit statement or that do not match any deny statements. When receiving
such a packet, DCC either sends it out if a link is present and resets the idle-timeout timer or
originates a new call to set up a link if no link is present.
z Packets that do not match any permit statements or that match a deny statement. When receiving
such a packet, DCC either sends it out without resetting the idle-timeout timer if a link is present, or
drops it without originating calls for link setup if no link is present.
For DCC to send packets normally, you must configure a dial access control list (ACL) and associate it
with the concerned dial interface (physical or dialer) by using the dialer-group command. You may
either configure a dial ACL directly using the dialer-rule command or reference an existing ACL.
Follow these steps to associate a dial ACL with the dial interface:

dialer-rule group-number
Configure a dial ACL for a dialer access
{ protocol-name { deny | permit } |
group, specifying the conditions triggering Required
acl { acl-number | name
DCC calls
acl-name } }
Enter dial interface (physical or dialer) interface interface-type

Associate the dial interface with the dial
ACL by associating the interface with the dialer-group group-number Required
corresponding dialer access group
Make sure that the group-number arguments in the dialer-rule and dialer-group commands take the
same value.
Configuring C-DCC
In C-DCC approach, you can configure DCC parameters for a physical interface in either of the
following two ways:
z Directly configure DCC parameters on the physical interface. This is applicable only to one-to-one
calls or one-to-many calls.
z Bind the interface to a dialer interface by assigning it to the dialer circular group associated with the
dialer interface. Thus, the interface can inherit the DCC parameters configured on the dialer
interface. This is applicable to many-to-one and many-to-many calls in addition to one-to-many and
one-to-one calls.
A dialer circular group associates a dialer interface with a group of physical interfaces. All physical
interfaces in the group inherit the DCC configurations on the dialer interface. If the dialer interface is
1-7
associated with multiple destinations, any physical interface in the group can call any of these
destinations.
Depending on your network topology and dial needs, for example, to allow one or multiple interfaces to
both place and receive calls, you may use any combinations of the following C-DCC configuration
approaches:
z Configuring an interface to place calls to a remote end
z Configuring an interface to receive calls from a remote end
z Configuring an interface to place calls to multiple remote ends
z Configuring an interface to receive calls from multiple remote ends
z Configuring multiple interfaces to place calls to one or multiple remote ends
z Configuring multiple interfaces to receive calls from one or multiple remote ends
In the C-DCC implementation of DCC, the two dial parties can configure the password authentication
protocol (PAP) or the challenge-handshake authentication protocol (CHAP) authentication. You are
recommended to configure authentication to ensure security of dialing IDs. When doing that, note the
following:
z If one party has configured authentication, the other party must do that as well.
z At the sending side, if DCC is enabled on physical interfaces, directly configure PAP or CHAP
authentication on the physical interfaces. If DCC is enabled on a dialer circular group, configure
PAP or CHAP authentication on the dialer interface corresponding to the dialer circular group.
z At the receiving end, you are recommended to make the configuration on both physical and dialer
interfaces. This is because after a physical interface receives a call, it negotiates PPP and
authenticates the dialer prior to handing the call over to the upper layer DCC module
Configuring an interface to place calls to a remote end
As shown in the following figure, an interface at the local end places calls to a single remote end (the
components in inverse color represent the routers irrelevant to the networking):
Figure 1-3 Network diagram for an interface to place calls to a remote end
if1
Local end if0 Remote end
(Single (Single
interface) interface)
In this scenario, for Interface0 (if0) to place DCC calls to a single remote interface if1, you may configure
a dial string with the dialer number or dialer route command. As calls are to be placed from a single
interface, you can configure DCC by configuring a dialer circular group. In addition, you may configure
PAP or CHAP authentication.
After completing the basic DCC configurations, follow these steps to configure an interface to place
calls to a remote end:
1-8
Enter dial interface
interface interface-type interface-number
(physical or dialer) view
Required
Enable C-DCC dialer enable-circular
Disabled by default
dialer number dial-number

Required
Configure a dial string for dialer route protocol next-hop-address [ mask
calling a remote end network-mask-length ] [ user hostname | Use either
broadcast ] * dial-number [ autodial | interface command.
interface-type interface-number ] *
Configuring an interface to receive calls from a remote end
As shown in the following figure, an interface at the local end receives calls from a single remote end
(the components in inverse color represent the routers irrelevant to the networking):
Figure 1-4 Network diagram for an interface to receive calls from a remote end
Local end if1 Remote end

if0
(Single (Single
interface) interface)
In this scenario, for interface0 (if0) at the local end to receive DCC calls from a remote interface if1, you
can configure DCC by configuring a dialer circular group. In addition, you may configure authentication,
PAP or CHAP.
After completing the basic DCC configurations, follow these steps to configure an interface to receive
calls from a single remote end:

Enter dial interface interface interface-type

(physical or dialer) view interface-number
Required
Disabled by default
Optional
dialer route protocol
Configure the interface to next-hop-address [ mask If the dialer route ip next-hop-address
receive calls from a network-mask-length ] user hostname command is configured at
remote end [ user hostname | the called end, the called party will use the
broadcast ] * specified next hop address and hostname
to authenticate the calling party.
1-9
Configuring an interface to place calls to multiple remote ends
As shown in the following figure, an interface at the local end places calls to multiple remote ends (the
components in inverse color represent the routers irrelevant to the networking):
Figure 1-5 Network diagram for an interface to place calls to multiple remote ends
Remote end A
if1
(Single/Multiple
interfaces)
if0
Local end if2 Remote end B
(Single (Single/Multiple
interface) interfaces)
if3
Remote end C
(Single/Multiple
interfaces)
In this scenario, a single local interface interface0 (if0) places DCC calls to multiple remote interfaces
including if1 and if2. As multiple remote ends are involved, you must use the dialer route command to
configure the dialer strings and destination addresses. As only one originating interface is involved, you
may configure DCC parameters for the interface by configuring a dialer circular group. In addition, you
may configure PAP or CHAP authentication.
After completing the basic DCC configurations, follow these steps to configure an interface to place
calls to multiple remote ends:

Enter dial interface (physical interface interface-type

or dialer) view interface-number
Required
Disabled by default
Repeat this step to configure dialer route protocol next-hop-address
the dial strings and [ mask network-mask-length ] [ user
destination addresses for the hostname | broadcast ] * dial-number Required
interface to place calls to [ autodial | interface interface-type
multiple remote ends interface-number ] *
Configuring an interface to receive calls from multiple remote ends
As shown in the following figure, an interface at the local end receives calls from multiple remote ends
(the components in inverse color represent the routers irrelevant to the networking):
1-10
Figure 1-6 Network diagram for an interface to receive calls from multiple remote ends
Remote end A
(Single/Multiple
if1 interfaces)
if0 if2
Local end Remote end B
(Single (Single/Multiple
interface) interfaces)
if3
Remote end C
if4
(Single/Multiple
interfaces)
In this scenario, a single local interface interface0 (if0) receives DCC calls from multiple remote
interfaces including if1 and if4. As only one interface is involved at the local end, you may configure
DCC parameters for the interface by configuring a dialer circular group. In addition, you may configure
PAP or CHAP authentication.
After completing the basic DCC configurations, follow these steps to configure an interface to receive
calls from multiple remote ends:


Required
Disabled by default
dialer route protocol Optional

next-hop-address If the dialer route ip next-hop-address
receive calls from a remote
[ mask user hostname command is configured at
end (if multiple remote
network-mask-length ] a called end, the called party will use the
ends are involved, repeat
[ user hostname | specified next hop address and hostname
this step)
broadcast ] * to authenticate the calling party.
Configuring multiple interfaces to place calls to one or multiple remote ends
As shown in the following figure, multiple interfaces at the local end place calls to one or multiple remote
ends (the components in inverse color represent the routers irrelevant to the networking):
1-11
Figure 1-7 Multiple interfaces place calls to one or multiple remote ends
Remote end A
if1
(Single/Multiple
interfaces)
if0
if2 Remote end B
Local end if1
(Single/Multiple
(Single
interfaces)
interface) if2
if3
Remote end C
(Single/Multiple
interfaces)
In this scenario, interfaces if0, if1, and if2 at the locate end place DCC calls to interfaces if1, if2 and if3
at the remote end. If only one remote end is involved, use the dialer number dial-number command to
configure a dial string. If multiple remote ends are involved, use the dialer route command to configure
the dial strings and destination addresses. As multiple interfaces are involved at the local end, configure
DCC parameters for them by configuring dialer circular groups. In addition, you may configure PAP or
CHAP authentication.
When placing calls, the physical interfaces in a dialer circular group use the IP address of the
associated dialer interface instead of its own. An ISDN BRI or PRI interface itself can be regarded as a
dialer circular group for its B channels. At the same time, it can be assigned to other dialer circular
groups.
After completing the basic DCC configurations, follow these steps to configure multiple interfaces to
place calls to one or multiple remote ends:

Create and enter dialer
interface dialer number
interface view
Required

Configure the dial string and next-hop-address [ mask Required
destination address for calling a network-mask-length ] [ user If only one remote end is
remote end (repeat this step if hostname | broadcast ] * involved, you may use the
multiple remote ends are dial-number [ autodial | dialer number dial-number
involved) interface interface-type command instead.
interface-number ] *
Exit to system view quit
Enter physical interface view
interface-number
Required
Assign the physical interface to The number argument in this
the dialer circular group command must take the same
dialer circular-group number
corresponding to the dialer value assigned to the number
interface argument in the interface
dialer number command.
1-12
Assign a priority to the physical Optional
interface in the dialer circular dialer priority priority
group The default priority is 1.
Configuring multiple interfaces to receive calls from one or multiple remote ends
As shown in the following figure, multiple interfaces at the local end receive calls from one or multiple
remote ends (the components in inverse color represent the routers irrelevant to the networking):
Figure 1-8 Multiple interfaces receive calls from one or multiple remote ends
In this scenario, interfaces if0, if1, and if2 at the local end receive DCC calls from multiple remote
interfaces including if1, if2 and if4. As multiple interfaces are involved at the local end, configure DCC
parameters for them by configuring a dialer circular group. In addition, you may configure PAP or CHAP
authentication.
After completing the basic DCC configurations, follow these steps to configure multiple interfaces to
receive calls to one or multiple remote ends:


interface view
Required
Optional
Configure the interface to dialer route protocol If the dialer route ip
receive calls from a remote next-hop-address [ mask next-hop-address user hostname
end (if multiple remote ends network-mask-length ] command is configured at a called
are involved, repeat this [ user hostname | end, the called party will use the
step) broadcast ] * specified next hop address and
hostname to authenticate the calling
party.
Enter physical interface interface interface-type

1-13
Required
Assign the physical
interface to the dialer The number argument in this
dialer circular-group command must take the same value
circular group
number assigned to the number argument in
corresponding to the dialer
interface the interface dialer number
command.
Assign a priority to the Optional
physical interface in the dialer priority priority
dialer circular group The default priority is 1.
Configuring RS-DCC
In RS-DCC approach, physical interface configuration is separated from logical configuration for calls
and they can be combined dynamically for each call.
When configuring RS-DCC for on-demand dial, you need to configure RS-DCC sets. Each RS-DCC set
is an attribute collection containing a dialer interface, dialer interface attributes, and a dialer bundle as
follows:
z For each dialer interface, you can define only one dial string. As this dial string has its own dial
attribute set, all calls placed using this dial string use the same DCC attribute parameters (such as
dial rate).
z Each dialer interface can use only one dialer bundle. Each dialer bundle may contain multiple
physical interfaces with different priorities while each of these interfaces can belong to multiple
dialer bundles. For an ISDN BRI or PRI interface, you can set the number of B channels to be used
by configuring the dialer bundle command.
z All calls destined to the same network segment use the same RS-DCC set.
Due to the separation between physical configuration and logical configuration, RS-DCC can
accommodate more network topologies and DCC dial demands. For example, it allows multiple
interface groups to call multiple remote ends.
Figure 1-9 Multiple interfaces call multiple remote ends in RS-DCC approach
Physical interface
groups Remote end A
if1
(Single/Multiple
Call remote interfaces)
end A Local end
Dialer0
(Multiple
interfaces)
Call remote if2 Remote end B
Dialer1
end B (Single/Multiple
interfaces)
Call remote
end C Dialer2 if3
Remote end C
(Single/Multiple
interfaces)
In this scenario, a dialer interface is configured only for calling one remote end. On-demand dial in this
case is implemented by assigning a physical interface to dialer bundles associated with different dialer
interfaces.
1-14
If RS-DCC sets are used to configure RS-DCC parameters, you only need to configure link layer
encapsulation and dialer bundle numbers on physical interfaces.
Before configuring RS-DCC, be aware of the following:
z In RS-DCC, a RS-DCC set is unable to apply the attribute information in it, PPP authentication for
example, to the physical interfaces in a dialer bundle. In other words, the physical interfaces do not
inherit the authentication attribute in the RS-DCC set. Therefore, authentication information must
be configured on call receiving physical interfaces.
z Authentication is mandatory in RS-DCC. You must configure authentication (dialer user and PPP
authentication) on both dialer interfaces and their physical interfaces. This is because RS-DCC
needs to conduct PPP negotiation on the physical interface and sends the agreed-upon remote
username to DCC. Based on this remote username, DCC decides which dialer interface address is
used and then informs PPP. PPP then uses the configuration of the dialer interface to start IP
control protocol (IPCP) negotiation.
Complete these tasks to configure RS-DCC for on-demand calling:
Task Remarks
Enabling RS-DCC Required
Configuring a dial string for the dialer interface Required

Assigning physical interfaces to the dialer bundle Required
Configuring dial authentication for RS-DCC Required
Enabling RS-DCC
Follow these steps to enable RS-DCC:

interface view
Set the remote username dialer user username Required
Create a dialer bundle for the
dialer bundle number Required
dialer interface
Configuring a dial string for the dialer interface
In the RS-DCC approach to on-demand dial, the attributes of physical interfaces vary by dial string.
Therefore, DCC parameters should be configured on dialer interfaces and dial strings can be
configured only with the dialer number command. Furthermore, for each dialer interface, you can
configure only one dial string.
Follow these steps to configure a dial string for the dialer interface:

Enter dialer interface view interface dialer number
1-15
Configure a dial string for
dialer number dial-number Required
calling a remote end
Assigning physical interfaces to the dialer bundle
A dialer bundle is a collection of physical interfaces with different priorities. When placing a call, DCC
selects a physical interface from the bundle in priority order.
Follow these steps to assign physical interfaces to the dialer bundle:


Required
Physical interfaces do not belong to
Assign the interface to dialer bundle-member number any dialer bundle by default.
the dialer bundle [ priority priority ] After a physical interface is assigned
without priority to a dialer bundle, it
takes the default priority of 1.
Configuring dial authentication for RS-DCC
In RS-DCC, associations between physical interfaces and dialer interfaces are rather flexible. To allow
a called party to discriminate calling parties, you must configure authentication, either PAP or CHAP.
Follow these steps to configure dialup authentication for RS-DCC:

Configure the remote username dialer user username Required
Configure PPP encapsulation and PPP See PPP Configuration in the
Required
authentication (PAP or CHAP) Access Volume.
z You are recommended to configure either PAP or CHAP authentication on both physical and dialer
interfaces at both sending and receiving ends.
z When PPP encapsulation is enabled on a dialer interface, you must configure a remote username
with the dialer user command for the dialer interface. When DCC decides which dialer interface is
used for receiving a call, it compares the remote username gained through PPP negotiation
against those assigned to dialer interfaces for a match.
1-16
Configuring MP for DCC

z Implementing DCC with MP
z Configuration procedure
Implementing DCC with MP
In DCC applications, you may configure load thresholds for links.

If you set a link load threshold in the range 1 to 99, MP tunes allocated bandwidth according to actual
traffic percentage as follows:
z When the percentage of traffic on a link to bandwidth exceeds the defined traffic threshold, the
system automatically brings up the second link, and assigns them to one MP bundle. When the
percentage of traffic on these two links to bandwidth exceeds the defined traffic threshold, the
system brings up the third link, and assigns it to the MP bundle, so on and so forth. This ensures
appropriate traffic distribution on DCC links.
z On the contrary, when the percentage of the traffic on N (which is an integer greater than 2) links to
the bandwidth of N 1 links decreases under the defined traffic threshold, the system automatically
shuts down a link, so on and so forth. This ensures the efficient use of DCC links.
If you set the link load threshold to zero, DCC brings up all available links when triggered by auto-dial or
packets instead of looking at traffic size before doing that. In addition, it does not tear down links that
has been established for timeout.
To implement MP with DCC, you must use dialer interfaces. The following is how MP operates after you
configure the ppp mp and dialer threshold commands on a dialer interface:
1) When the ratio of traffic to bandwidth on a physical interface (or a B channel) assigned to the dialer
interface exceeds the load threshold, DCC brings up another physical interface in the dialer
interface, and assigns these links to an MP bundle. If the physical interfaces are ISDN BRI or PRI
interfaces, DCC uses idle B channels on them to form an MP bundle.
2) When the number of bundled links reaches the upper threshold specified by the max-bind-num
argument, DCC stops to bring up new links.
Some dial applications may require multiple links to carry service. To this end, you may configure the
ppp mp min-bind command, allowing DCC to bring up multiple links when triggered to ensure
minimum bandwidth. The following is how MP operates in this case:
1) DCC brings up the first link.
2) When the first link comes up, DCC checks whether the number of links in the MP bundle reaches
the lower limit specified by the min-bind-num argument. If not, the router brings up the second link.
This process continues until the number of links in the MP bundle reaches the lower limit.
Note that when MP is used with DCC, the commands dialer threshold, ppp mp max-bind, and ppp
mp min-bind must be configured in dialer interface view. When configuring other PPP commands,
observe the following:
z In the C-DCC approach, configure in dialer interface view.
z In the RS-DCC approach, configure in dialer interface view at the calling end and in physical dial
interface view at the called end. At the calling end, however, you are recommended to configure
the same PPP parameters on physical dial interfaces as well to ensure reliable PPP link
negotiation.
1-17
When the three commands, ppp mp min-bind, dialer threshold, and ppp mp max-bind, are
configured, DCC brings up links as follows:
1) Bring up a minimum number of links depending on the setting of the ppp mp min-bind command.
2) If traffic size still exceeds the link load threshold set by the dialer threshold command, bring up the
next idle link. This process continues until the number of links reaches the upper limit set by the
ppp mp max-bind command or traffic size decreases below the specified link load threshold.
Follow these steps to configure MP for DCC:

Required
Enable MP ppp mp
Required
dialer threshold
Set link load thresholds traffic-percentage [ in-out | If the traffic-percentage argument is set
in | out ] to 0, DCC will bring up all available links
when triggered.
Set upper limit of links in ppp mp max-bind Optional

an MP bundle max-bind-num The default is 16.
Optional
Set lower limit of links in an ppp mp min-bind
MP bundle min-bind-num The default is 0; DCC brings up links
depending on traffic size.
z Configure PPP commands on both dialer and physical interfaces to ensure reliable PPP link
negotiation.
z The dialer threshold 0 command voids the dialer timer idle command. DCC will bring up all
available links when triggered.
z Similar to the dialer threshold 0 command, the ppp mp min-bind command voids the dialer
timer idle command. When it is configured, DCC does not look at traffic size to bring up links for
MP bundling or tear down links that have been brought up.
z You need to configure the dialer threshold command only at the calling end.
Configuring PPP Callback
PPP callback adopts the client/server model where the calling party is the callback client and the called
party is the callback server. The client first originates a call, and the server decides whether to originate
a return call. If a return call is needed, the callback server disconnects and then originates a return call
according to the information such as username or callback number.
1-18
z Configure PPP callback after completing the basic configuration of C-DCC or RS-DCC.
z PPP callback implementation requires authentication. You are recommended to configure PAP or
CHAP authentication on both physical and dialer interfaces on both callback client and server.
z With dynamic route backup configured on an interface, only the dynamic route backup groups are
used for dial. In this case, the interface does not accept incoming calls or outgoing calls. So, do not
configure dynamic route backup groups for interfaces with callback configured.
Two approaches are available to configuring PPP callback with DCC:

z Configuring PPP callback in the C-DCC implementation
z Configuring PPP callback in the RS-DCC implementation
Configuring PPP callback in the C-DCC implementation
Configuring PPP callback in C-DCC involves configuring PPP callback client and server.
1) Configure PPP callback client in the C-DCC implementation
As a callback client, your router can place calls to the remote end (which can be a router or Windows NT
server with the PPP callback server function), and receive return calls from the remote end.
Follow these steps to configure PPP callback client in the C-DCC implementation:

interface dialer
Enter dialer interface view
interface-number
Enable PPP encapsulation link-protocol ppp Required
See PPP Configuration in the
Configure authentication
Access Volume for related Required
parameters
information.
Required
Enable PPP callback client ppp callback client
Disabled by default
Optional
Not configured by default.
Configure the dial string for a
ppp callback ntstring Configure this command if a
Windows NT Server to call
dial-number Windows NT Server requires
back
PPP callback clients to send
callback numbers.
Set the interval between two Optional

dialer timer enable seconds
calls 15 seconds is recommended.
2) Configure PPP callback server in the C-DCC implementation

As a callback server, your router can place return calls according to network addresses configured with
the dialer route command (PPP authentication must be configured in this case), or according to dial
strings configured with the service-type ppp command. You need to select either approach with the
dialer callback-center command.
1-19
You need to configure callback client usernames with the dialer route command, so that the callback
server can authenticate whether a callback client is valid when receiving a call from it.
Follow these steps to configure PPP callback server in the C-DCC implementation:

Required
Enable PPP callback server ppp callback server Disabled by
default.
dialer callback-center [ user |
Configure the PPP callback reference Required
dial-number ] *

next-hop-address [ mask
network-mask-length ] user
Add a callback client username Required
hostname [ broadcast ] [ dial-number
[ autodial | interface interface-type
interface-number ] * ]
If the dial-number local-user user-name

keyword is configured, service-type ppp
Configure create and enter local [ callback-nocheck |
either user view to configure a callback-number callback-number |
command callback user and the call-number call-number
depending on dial string for callback [ subcall-number ] ]
the keyword Required
configured dialer route protocol
with the dialer next-hop-address [ mask
If the user keyword is
callback-cent network-mask-length ] user
er command configured, configure a
hostname [ broadcast ] dial-number
dial string for callback
[ autodial | interface interface-type
z If the network address used by a callback client is dynamically assigned, configuring the dialer
route command to associate the callback dial string with the network address for the client may
result in callback failure. In this case, you should use the service-type ppp command instead to
associate the dial string with the client username for callback.
z To leave enough time for a server to call back, the interval between two calls on the client need to
be at least 10 seconds longer than that of the server. It is recommended that the interval on the
server be set to 5 seconds (the default) and that on the client be set to 15 seconds.
Configuring PPP callback in the RS-DCC implementation
Configuring PPP callback in RS-DCC involves configuring PPP callback client and configuring PPP
callback server.
1) Configure PPP callback client in the RS-DCC implementation
1-20
As a callback client, your router can place calls to the remote end (which can be a router or Windows NT
server with the PPP callback server function), and receive return calls from the remote end.
Configuring PPP callback client in RS-DCC is the same as that in C-DCC except that the dial string is
configured with the dialer number command in RS-DCC.
Follow these steps to configure PPP callback client in the RS-DCC implementation:

Enable PPP encapsulation link-protocol ppp Required
See PPP&PPPoE
Configure authentication
Configuration in the Access Required
parameters
Volume for related information.
Required
Enable PPP callback client ppp callback client
Disabled by default
Configure the dial string for a
ppp callback ntstring
Windows NT Server to place Required
dial-number
return calls

2) Configure PPP callback server in the RS-DCC implementation

Configuring PPP callback server in RS-DCC is the same as that in C-DCC except that the callback
reference can only be dial-number in RS-DCC and dial strings for callback must be configured with the
service-type ppp command.
Follow these steps to configure PPP callback server in the RS implementation:

Required
Enable PPP callback server ppp callback server
Configure the PPP callback dialer callback-center
Required
reference dial-number
Create and enter local user
local-user user-name Required
view
Required
service-type ppp
[ callback-nocheck | When placing a return call,
Configure a dial string for DCC identifies which dial string
callback-number
callback to be used according to the
callback-number | call-number
call-number [:subcall-number ] ] remote username obtained
through PPP negotiation.
1-21
To leave enough time for a server to call back, the interval between two calls on the client need to be at
least 10 seconds longer than that of the server. It is recommended that the interval on the server be set
to 5 seconds (the default) and that on the client be set to 15 seconds.
Configuring ISDN Caller Identification Callback
In an ISDN environment, implementing DCC callback through ISDN caller identification function does
not require authentication configuration.
z Features of ISDN caller Identification callback
z Configuring ISDN caller identification callback with C-DCC
z Configuring ISDN caller identification callback with RS-DCC
Features of ISDN caller Identification callback
1) In the applications of ISDN caller Identification callback, the callback server can process an
incoming call in three ways, depending on the result of matching the dial-in number against
numbers configured in dialer call-in commands at the local end:
z Deny the incoming call, if one or multiple dialer call-in commands exist, but no match is found.
z Accept the incoming call, if the call-in number matches a dialer call-in command without the
callback keyword or if no dialer call-in command exists.
z Call back, if the call-in number matches a dialer call-in command with the callback keyword.
2) Dial-in numbers are matched against numbers configured in dialer call-in commands starting with
the right-most character. In addition, asterisks (*) are used as wildcards to match any character. If a
dial-in number matches multiple dialer call-in commands, the best match is selected in the
following order:
z The one with the fewest asterisks (*).
z The one that is found first.
3) At the server end, identify the dialer call-in commands matching incoming calls
z In C-DCC, upon receipt of an incoming call, the server compares the incoming number against the
dialer call-in commands configured on the physical dial interface or its corresponding dialer
interface for a match.
z In RS-DCC, upon receipt of an incoming call, the server compares the incoming number against
the dialer call-in commands configured on the involved dialer interface for a match.
Configuring ISDN caller identification callback with C-DCC
Configuring ISDN caller identification callback with C-DCC involves configuring the server end and the
client end.
1-22
1) Configure the client of ISDN caller identification callback
Follow these steps to configure the client of ISDN caller identification callback:


dialer route protocol Required
Configure a destination network-mask-length ] [ user Repeat this step to configure
address and dial string hostname | broadcast ] * destination addresses and dial
dial-number [ autodial | interface strings for calling multiple
interface-type interface-number ] * remote ends.
Set the interval between Optional

two calls 15 seconds is recommended.
2) Configure the server of ISDN caller identification callback

Follow these steps to configure the server of ISDN caller identification callback:

Enter dial interface (physical or
dialer) view
Configure the local end to place
ISDN return calls for the dialer call-in remote-number callback Required
specified ISDN calling number
dialer route protocol next-hop-address [ mask

Configure one or multiple
network-mask-length ] [ user hostname |
destination addresses and dial Required
broadcast ] * dial-number [ autodial | interface
strings
interface-type interface-number ] *
Use this command instead of
the dialer route command if
dialer number dial-number Optional
only one remote destination
address is involved
z To make a successful callback for an incoming number, ensure that the dial string configured in the
dialer route or dialer number command on the dial interface at the server end is exactly the same
as the incoming number.
1-23
Configuring ISDN caller identification callback with RS-DCC
Configuring ISDN caller identification callback with RS-DCC involves configuring the server end and the
client end.
1) Configure the client of ISDN caller identification callback
Follow these steps to configure the client of ISDN caller identification callback:

interface dialer
Enter dialer interface view
interface-number
Configure a dial string for
calling a remote end

2) Configure the server of ISDN caller identification callback

Follow these steps to configure the server of ISDN caller identification callback:

Enter dialer interface view interface dialer interface-number
Configure the local end to place ISDN
return calls for the specified ISDN dialer call-in remote-number callback Required
calling number
Configure a dial string for calling a
remote end
z The number configured in the dialer number command on the dialer interface is not required to be
same as the incoming number.
Configuring Advanced DCC Functions
Configuring advanced DCC functions involves:

z Configuring ISDN leased line
z Configuring auto-dial
z Configuring circular dial string backup
1-24
Configuring ISDN leased line
ISDN leased line can be configured with C-DCC but not RS-DCC. This function is fulfilled through
establishing semi-permanent ISDN MP connections. Such application requires that a leased line has
been established on the PBX of your telecom service provider and has been connected to the remote
device.
After completing C-DCC configurations, follow these steps to configure ISDN leased line:


Specify a B channel for Required

ISDN leased line dialer isdn-leased number No B channel is configured for ISDN
connection leased line connection by default.
ISDN BRI interfaces support both 64 kbps and 128 kbps leased lines. For more information, refer to
ISDN Configuration in the Access Volume.
Configuring auto-dial
Auto-dial can be used with C-DCC but not RS-DCC. With auto-dial enabled, DCC automatically dials
the remote end of connection upon each device startup without requiring a triggering packet. If the
connection cannot be established, it will retry at certain intervals. The connection thus established does
not disconnect due to timeout of the idle-timeout timer as it would in the traffic-triggered dial approach.
Its configuration thus voids the dialer timer idle command.
Follow these steps to configure auto-dial:

Enter dial interface (physical or interface interface-type

dialer) view interface-number
Configure one or multiple network-mask-length ] [ user Required
destination addresses and dial hostname | broadcast ] *
strings that can be auto-dialed dial-number autodial Auto-dial is disabled by default.
[ interface interface-type
interface-number ]
Optional
Set the auto-dial interval dialer timer autodial seconds
Configuring circular dial string backup
In C-DCC, you may configure multiple dialer route commands for the dial strings used to call a
destination address. These dial strings are backups to each other. If DCC fails to call the remote end
with a dial string, it will select the dialer route command with the next dial string for another try.
Follow these steps to configure dial string circular backup:
1-25
Enter dial interface (physical or
dialer) view
dialer route protocol next-hop-address

Repeat this step to associate [ mask network-mask-length ] [ user
multiple dial strings with the hostname | broadcast ] * dial-number Required
same next-hop-address [ autodial | interface interface-type
Configuring DCC Timers and Buffer Queue Length
C-DCC and RS-DCC are available with some optional parameters. You may configure them
appropriately to improve on-demand dial efficiency.
z DCC timers and buffer queue length
z Configuration procedure
DCC timers and buffer queue length
z Link idle-timeout timer

A link idle-timeout timer starts upon setup of a link. When the timer expires, DCC disconnects the link.
z Holddown timer
A holddown timer starts upon disconnection of a link. The call attempt to bring up this link can be made
only after the timer expires. This is to prevent a remote PBX from being overloaded.
z Compete-idle timer
If all the channels are unavailable when DCC originates a new call, contention occurs.
Normally, an idle-timeout timer starts upon setup of a link. If a call to another destination address is
placed at the same time, contention occurs. In this case, DCC starts a compete-idle timer to replace the
idle-timeout timer for the link. When the idle time of the link reaches the setting of this compete-idle timer,
the link disconnects.
z Wait-carrier timer
Sometimes, the time that DCC waits for a connection to be established may vary call by call. To handle
this situation, you may use a wait-carrier timer. A wait-carrier timer starts when a call is placed. If the
connection is not established upon expiration of the timer, DCC terminates the call.
z Buffer queue length
If no connection is available when a dial interface without a buffer queue receives a packet, it will drop
the packet. Configured with a buffer queue, the dial interface will buffer the packet until a connection is
available for packet sending.
1-26
Follow these steps to configure DCC timers and buffer queue length on a dial interface:


Set the link idle-timeout Optional

dialer timer idle seconds
timer The default is 120 seconds.
Optional
Set the holddown timer dialer timer enable seconds
dialer timer compete Optional

Set the compete-idle timer
seconds The default is 20 seconds.
dialer timer wait-carrier Optional

Set the wait-carrier timer
seconds The default is 60 seconds.
Set the buffer queue Optional

dialer queue-length packets
length Packets are not buffered by default.
Configuring Traffic Statistics Interval
Follow these steps to configure traffic statistics interval for DCC:

Set the traffic statistics interval Optional

dialer flow-interval interval
for DCC The default is 20 seconds.
Displaying and Maintaining DCC

Display information about a display dialer [ interface
specified or all dial interfaces interface-type interface-number ]
display interface dialer [ number ] Available in any view
dialer interface
dialer disconnect [ interface
Tear down a dialup link Available in any view
interface-type interface-number ]
DCC Configuration Examples

This section provides these examples:
z C-DCC Application
z RS-DCC Application
z DCC Application on ISDN
1-27
z RS-DCC Application with MP
z Router-to-Router Callback with DCC (PPP Approach)
z Router-to-Router Callback with DCC (ISDN Approach)
z Router-to-PC Callback with DCC
z NT Server-to-Router Callback with DCC
z Circular Dial String Backup and Internet Access with DCC
C-DCC Application
On a network segment are located three routers: Router A with the IP address of 100.1.1.1/24, Router B
with the IP address of 100.1.1.2/24, and Router C with the IP address of 100.1.1.3/24.
Configure C-DCC to allow Router A to call Router B and Router C from multiple interfaces while
disabling Router B and Router C from calling each other.
Network diagram
Figure 1-10 Network diagram for a C-DCC application
# Configure a dial access control rule for dialer access group 1.
# Assign an IP address to interface Dialer0, associate dialer access group 1 with the interface, enable
C-DCC, and configure dial strings for calling Router B and Router C.
[RouterA] interface dialer 0
[RouterA-Dialer0] dialer enable-circular
[RouterA-Dialer0] ip address 100.1.1.1 255.255.255.0
[RouterA-Dialer0] dialer route ip 100.1.1.2 8810052
[RouterA-Dialer0] dialer route ip 100.1.1.3 8810063
# Set interface Serial 2/0 to work in asynchronous protocol mode and assign it to dialer circular group 0.
1-28
[RouterA] interface serial 2/0
[RouterA-Serial2/0] physical-mode async
[RouterA-Serial2/0] async mode protocol
[RouterA-Serial2/0] dialer circular-group 0
[RouterA-Serial2/0] quit
# Set interface Serial 2/1 to work in asynchronous protocol mode and assign it to dialer circular group 0.
[RouterA-Serial2/1] dialer circular-group 0
# Enable modem dialup on user interfaces to be used.

[RouterA] user-interface tty1
[RouterA-ui-tty1] modem both
[RouterA-ui-tty1] quit
2) Configure Router B.
[RouterB] dialer-rule 1 ip permit
# Set interface Serial 2/0 to work in asynchronous protocol mode.

[RouterB] interface serial 2/0
[RouterB-Serial2/0] physical-mode async
[RouterB-Serial2/0] async mode protocol
# Assign an IP address to interface Serial 2/0, associate dialer access group 1 with the interface, enable
C-DCC, and configure two dial strings for calling Router A.
[RouterB-Serial2/0] ip address 100.1.1.2 255.255.255.0
[RouterB-Serial2/0] dialer enable-circular
[RouterB-Serial2/0] dialer-group 1
[RouterB-Serial2/0] dialer route ip 100.1.1.1 8810048
[RouterB-Serial2/0] dialer route ip 100.1.1.1 8810049
[RouterB-Serial2/0] quit
# Enable modem dialup on the user interface to be used.

[RouterB] user-interface tty1
[RouterB-ui-tty1] modem both
[RouterC] dialer-rule 1 ip permit
# Set interface Serial 2/0 to work in asynchronous protocol mode.

[RouterC] interface serial 2/0
[RouterC-Serial2/0] physical-mode async
[RouterC-Serial2/0] async mode protocol
1-29
# Assign an IP address to interface Serial 2/0, associate dialer access group 1 with the interface, enable
C-DCC, and configure two dial strings for calling Router A.
[RouterC-Serial2/0] ip address 100.1.1.3 255.255.255.0
[RouterC-Serial2/0] dialer enable-circular
[RouterC-Serial2/0] dialer-group 1
[RouterC-Serial2/0] dialer route ip 100.1.1.1 8810048
[RouterC-Serial2/0] dialer route ip 100.1.1.1 8810049
[RouterC-Serial2/0] quit
# Enable modem dialup on the user interface to be used.

[RouterC] user-interface tty1
[RouterC-ui-tty1] modem both
RS-DCC Application
As shown in the following diagram,

z On Router A, interface Dialer0 is assigned an IP address 100.1.1.1/24 and Dialer1 an IP address
122.1.1.1/24.
z On Router B, interface Dialer0 is assigned an IP address 100.1.1.2/24.
z On Router C, interface Dialer0 is assigned an IP address 122.1.1.2/24.
The Dialer0 interfaces on Router A and Router B are located on the same network segment, so are the
Dialer1 interface on Router A and the Dialer0 interface on Router C.
Configure RS-DCC to allow Router A to call Router B and Router C from multiple interfaces while
disabling Router B and Router C from calling each other.
Network diagram
Figure 1-11 Network diagram for an RS-DCC application
Router B
S2/0
Modem 8810048 8810052 Modem Dialer0

100.1.1.2/24
Dialer0
100.1.1.1/24
S2/0
Router A PSTN
S2/1
Dialer1
122.1.1.1/24
Modem 8810049 8810063 Modem Router C

S2/0
Dialer0
122.1.1.2/24
1-30
# Configure a dial access control rule for dialer access group 1; create local user accounts userb and
userc for Router B and Router C and configure PPP authentication for them.
[RouterA] local-user userb
[RouterA-luser-userb] password simple userb
[RouterA-luser-userb] service-type ppp
[RouterA-luser-userb] quit
[RouterA] local-user userc
[RouterA-luser-userc] password simple userc
[RouterA-luser-userc] service-type ppp
[RouterA-luser-userc] quit
# Assign an IP address to interface Dialer0, enable RS-DCC, and configure the remote username
allowed to call in.
[RouterA-Dialer0] dialer user userb
# Configure information for PPP authentication and the dial strings on interface Dialer0. (Assume that
PAP is adopted at the local end.)
[RouterA-Dialer0] ppp authentication-mode pap
[RouterA-Dialer0] ppp pap local-user usera password simple usera
[RouterA-Dialer0] dialer number 8810052
# Assign an IP address to interface Dial1, enable RS-DCC, and configure the remote username allowed
to call in.
[RouterA-Dialer1] dialer user userc
# Configure information for PPP authentication and the dial strings on interface Dialer1. (Assume that
PAP is adopted at the local end.)
# Set interface Serial 2/0 to work in asynchronous protocol mode, configure information for PPP
authentication, and assign the interface to dialer bundle 1 and dialer bundle 2.
1-31
[RouterA-Serial2/0] dialer bundle-member 1
[RouterA-Serial2/0] link-protocol ppp
[RouterA-Serial2/0] ppp authentication-mode pap
[RouterA-Serial2/0] ppp pap local-user usera password simple usera
# Set interface Serial 2/1 to operate in asynchronous protocol mode, configure information for PPP
authentication, and assign the interface to dialer bundle 1 and dialer bundle 2.
# Configure user interfaces to be used and enable modem dialup on them.

[RouterA-ui-tty1] quit
# Configure a dial access control rule for dialer access group 2; create a local user account usera for
Router A and configure PPP authentication for it.
[RouterB] local-user usera
[RouterB-luser-usera] password simple usera
[RouterB-luser-usera] service-type ppp
[RouterB-luser-usera] quit
allowed to call in and the dial string for placing calls.
[RouterB] interface dialer 0
[RouterB-Dialer0] ip address 100.1.1.2 255.255.255.0
[RouterB-Dialer0] dialer user usera
[RouterB-Dialer0] dialer bundle 1
[RouterB-Dialer0] dialer number 8810048
# Configure information for PPP authentication. (Assume that PAP is adopted at the local end.)
[RouterB-Dialer0] dialer-group 2
[RouterB-Dialer0] ppp authentication-mode pap
[RouterB-Dialer0] ppp pap local-user userb password simple userb
[RouterB-Dialer0] quit
1-32
authentication, and assign the interface to dialer bundle 1.
[RouterB-Serial2/0] dialer bundle-member 1
[RouterB-Serial2/0] link-protocol ppp
[RouterB-Serial2/0] ppp authentication-mode pap
[RouterB-Serial2/0] ppp pap local-user userb password simple userb
# Configure the user-interface to be used and enable modem dialup on it.

# Configure a dial access control rule for dialer access group 1; create a local user account usera and
configure PPP authentication for it.
[RouterC] local-user usera
[RouterC-luser-usera] password simple usera
[RouterC-luser-usera] service-type ppp
[RouterC-luser-usera] quit
allowed to call in and the dial string for placing calls.
[RouterC] interface dialer 0
[RouterC-Dialer0] ip address 122.1.1.2 255.255.255.0
[RouterC-Dialer0] dialer user usera
[RouterC-Dialer0] dialer bundle 1
[RouterC-Dialer0] dialer number 8810049
# Configure information for PPP authentication. (Assume that PAP is adopted at the local end.)
[RouterC-Dialer0] dialer-group 1
[RouterC-Dialer0] ppp authentication-mode pap
[RouterC-Dialer0] ppp pap local-user userc password simple userc
[RouterC-Dialer0] quit
authentication, and assign the interface to dialer bundle 1.
[RouterC-Serial2/0] physical-mode async
[RouterC-Serial2/0] async mode protocol
[RouterC-Serial2/0] dialer bundle-member 1
[RouterC-Serial2/0] link-protocol ppp
[RouterC-Serial2/0] ppp authentication-mode pap
[RouterC-Serial2/0] ppp pap local-user userc password simple userc
# Configure the user-interface to be used and enable modem dialup on it.
1-33
[RouterC] user-interface tty1
[RouterC-ui-tty1] modem both
DCC Application on ISDN
Figure 1-12 presents a scenario for C-DCC implementation, where:

z On Router A, interface BRI 1/0 is assigned an IP address 100.1.1.1/24.
z On Router B, interface BRI 1/0 is assigned an IP address 100.1.1.2/24.
z On Router C, interface BRI 1/0 is assigned an IP address 100.1.1.3/24.
The BRI 1/0 interfaces on these three routers are located on the same network segment.
Figure 1-13 presents a scenario for RS-DCC implementation, where:
z On Router A, interface Dialer0 is assigned an IP address 100.1.1.1/24 and Dialer1 an IP address
122.1.1.1/24.
z On Router B, interface Dialer0 is assigned an IP address 100.1.1.2/24.
z On Router C, interface Dialer0 is assigned an IP address 122.1.1.2/24.
The Dialer0 interfaces on Router A and Router B are located on the same network segment, so are the
Dialer1 interface on Router A and the Dialer0 interface on Router C.
Make configuration to allow Router A to call Router B and Router C from multiple interfaces while
disabling Router B and Router C from calling each other in both C-DCC and RS-DCC approaches.
Network diagram
Figure 1-12 Network diagram for C-DCC application on ISDN
1-34
Figure 1-13 Network diagram for RS-DCC application on ISDN
Solution 1: Use C-DCC to set up connection via ISDN BRI or PRI and configure DCC parameters on
physical interfaces.
# Assign an IP address to interface BRI 1/0, enable C-DCC, and configure the dial strings for calling
Router B and Router C.
[RouterA] interface bri 1/0
[RouterA-Bri1/0] ip address 100.1.1.1 255.255.255.0
[RouterA-Bri1/0] dialer enable-circular
[RouterA-Bri1/0] dialer-group 1
[RouterA-Bri1/0] dialer route ip 100.1.1.2 8810052
# Assign an IP address to interface BRI 1/0, enable C-DCC, and configure the dial string for calling
Router A.
[RouterB] interface bri 1/0
[RouterB-Bri1/0] ip address 100.1.1.2 255.255.255.0
[RouterB-Bri1/0] dialer enable-circular
[RouterB-Bri1/0] dialer-group 2
[RouterB-Bri1/0] dialer route ip 100.1.1.1 8810048
1-35
# Assign an IP address to interface BRI 1/0, enable C-DCC, and configure the dial string for calling
Router A.
[RouterC] interface bri 1/0
[RouterC-Bri1/0] ip address 100.1.1.3 255.255.255.0
[RouterC-Bri1/0] dialer enable-circular
[RouterC-Bri1/0] dialer-group 1
[RouterC-Bri1/0] dialer route ip 100.1.1.1 8810048
Solution 2: Use RS-DCC to set up connection via ISDN BRI or PRI and configure DCC parameters on
dialer interfaces.
# Configure a dial access control rule for dialer access group 1; create local user accounts userb and
userc for Router B and Router C and configure PPP authentication for them.
[RouterA] local-user userc
[RouterA-luser-userc] password simple userc
[RouterA-luser-userc] service-type ppp
[RouterA-luser-userc] quit
allowed to call in.
# Configure information for PPP authentication and the dial strings on interface Dialer0.
# Assign an IP address to interface Dial1, enable RS-DCC, and configure the remote username allowed
to call in.
[RouterA-Dialer1] dialer user userc
1-36
# Set information for PPP authentication on interface BRI 1/0 and assign the interface to dialer bundle 1
and dialer bundle 2.
[RouterA-Bri1/0] dialer bundle-member 1
[RouterA-Bri1/0] link-protocol ppp
[RouterA-Bri1/0] ppp authentication-mode pap
[RouterA-Bri1/0] ppp pap local-user usera password simple usera
allowed to call in.
# Configure information for PPP authentication and the dial string on interface Dialer0.
# Configure PPP authentication on interface BRI 1/0 and assign it to dialer bundle 1.
[RouterB-Bri1/0] dialer bundle-member 1
[RouterB-Bri1/0] link-protocol ppp
[RouterB-Bri1/0] ppp authentication-mode pap
[RouterB-Bri1/0] ppp pap local-user usera password simple usera
[RouterC] local-user usera
[RouterC-luser-usera] password simple usera
[RouterC-luser-usera] service-type ppp
[RouterC-luser-usera] quit
1-37
allowed to call in.
[RouterC] interface dialer 0
[RouterC-Dialer0] ip address 122.1.1.2 255.255.255.0
[RouterC-Dialer0] dialer user usera
[RouterC-Dialer0] dialer bundle 1
[RouterC-Dialer0] dialer-group 1
[RouterC-Dialer0] dialer number 8810048
[RouterC-Dialer0] ppp authentication-mode pap
[RouterC-Dialer0] ppp pap local-user userc password simple userc
[RouterC-Dialer0] quit
# Configure information for PPP authentication on interface BRI 1/0 and assign the interface to dialer
bundle 1.
[RouterC-Bri1/0] dialer bundle-member 1
[RouterC-Bri1/0] link-protocol ppp
[RouterC-Bri1/0] ppp authentication-mode pap
[RouterC-Bri1/0] ppp pap local-user usera password simple usera
RS-DCC Application with MP
Figure 1-14 presents a scenario where:

z Two ISDN BRI interfaces on Router A and an ISDN PRI interface on Router B are connected
across ISDN.
z Interface Dialer0 on Router A is assigned an IP address 100.1.1.1/24, and interface Dialer0 on
Router B is assigned an IP address 100.1.1.2/24.
Use RS-DCC on Router A to call Router B and C-DCC on Router B to call Router A. In addition,
implement traffic distribution for the two interfaces on Router A by setting traffic thresholds and
maximum bandwidth.
1-38
Network diagram
Figure 1-14 Network for a DCC application with MP
# Configure a dial access control rule for dialer access group 1; create a local user account userb for
Router B and configure PPP authentication for it; and set traffic statistics interval to three seconds for
DCC.
[RouterA] dialer flow-interval 3
# Assign an IP address to interface Dialer0, enable RS-DCC, and configure MP.

[RouterA-Dialer0] ppp mp
[RouterA-Dialer0] dialer threshold 50
# Configure information for PPP authentication, the remote user allowed to call in and the dial strings on
interface Dialer0.
# Configure PPP authentication on BRI 1/1 and assign it to dialer bundle 1.

[RouterA-Bri1/1] ppp mp
1-39
# Configure PPP authentication on BRI 1/0 and assign it to dialer bundle 1.

[RouterA-Bri1/0] interface bri 1/0
[RouterA-Bri1/0] ppp mp
Router A and configure PPP authentication for it; and set traffic statistics interval to three seconds for
DCC.
[RouterB] dialer flow-interval 3
# Assign an IP address to interface Dialer0; enable C-DCC; and configure the dial strings, MP, and
information for PPP authentication.
[RouterB-Dialer0] dialer enable-circular
[RouterB-Dialer0] dialer route ip 100.1.1.1 8810048
[RouterB-Dialer0] dialer route ip 100.1.1.1 8810049
[RouterB-Dialer0] ppp mp
# Configure CE1/PRI interface E1 2/0 and set it to work in PRI mode.

[RouterB] controller e1 2/0
[RouterB-E1 2/0] pri-set
[RouterB-E1-2/0] quit
# Enable C-DCC on interface Serial 2/0:15 created on interface E1 2/0 and assign the serial interface to
interface Dialer 0.
[RouterB] interface serial 2/0:15
[RouterB-Serial2/0:15] dialer enable-circular
[RouterB-Serial2/0:15] dialer circular-group 0
1-40
Router-to-Router Callback with DCC (PPP Approach)

z Router A and Router B are interconnected via serial interfaces across PSTN.
z Interface Serial 2/0 on Router A is assigned the IP address of 100.1.1.1/24 and interface Serial 2/0
on Router B is assigned the IP address of 100.1.1.2/24.
Implement PPP callback between Router A and Router B, specifying Router A as the callback client and
Router B as the callback server.
Network diagram
Figure 1-15 Network for DCC in router-to-router callback
Solution 1: Use C-DCC to implement PPP callback, allowing the callback server to make callback
decision based on usernames configured in the dialer route commands.
# Assign an IP address to interface Serial 2/0, configure its physical layer and C-DCC parameters.
[RouterA-Serial2/0] ip address 100.1.1.1 255.255.255.0
[RouterA-Serial2/0] dialer enable-circular
[RouterA-Serial2/0] dialer-group 1
[RouterA-Serial2/0] dialer route ip 100.1.1.2 8810052
# Specify interface Serial 2/0 as the callback client.

[RouterA-Serial2/0] ppp callback client
[RouterA-Serial2/0] dialer timer enable 15
# Configure the user interface to be used and enable modem dialup on it.
1-41
# Configure a dial access control rule for dialer access group 2; and create a local user account usera
for Router A and configure PPP authentication for it.
# Specify the local end as the callback server, and set the callback reference to user. In this case, DCC
identifies the dial string for callback according to the username configured in the dialer route
command.
[RouterB-Serial2/0] dialer callback-center user
[RouterB-Serial2/0] dialer route ip 100.1.1.1 user usera 8810048
[RouterB-Serial2/0] ppp callback server
Solution 2: Use C-DCC to implement PPP callback, allowing the callback server to identify the dial
string for callback by comparing the remote username received in PPP authentication against the local
user database for a match.
1-42
# Specify interface Serial 2/0 as the callback client.
[RouterA-Serial2/0] ppp callback client
[RouterA-Serial2/0] dialer timer enable 15
Router A and configure PPP authentication for it; and configure the dial string for callback.
[RouterB-luser-usera] service-type ppp callback-number 8810048
# Assign an IP address to interface Serial 2/0, and configure physical and C-DCC parameters.
[RouterB-Serial2/0] dialer route ip 100.1.1.1 user usera 8810048
# Specify the local end as the callback server, and set the callback reference to dial number. In this case,
DCC identifies the dial string for callback by comparing the remote username obtained through PPP
authentication against the local user database for a match.
[RouterB-Serial2/0] dialer callback-center dial-number
[RouterB-Serial2/0] ppp callback server
Router-to-Router Callback with DCC (ISDN Approach)

z Router A and Router B are interconnected via ISDN BRI interfaces across an ISDN network.
z Interface BRI 1/0 on Router A is assigned the IP address of 100.1.1.1/24 and interface BRI 1/0 on
Router B is assigned the IP address of 100.1.1.2/24.
1-43
Configure ISDN caller identification callback with C-DCC between Router A and Router B, specifying
Router A as the callback client and Router B as the callback server.
Network diagram
Figure 1-16 Network diagram for ISDN caller identification callback with DCC
# Assign an IP address to interface BRI 1/0, and configure C-DCC parameters and the dial string for
placing calls to Router B.
[RouterA-Bri1/0] dialer timer enable 15
# Assign an IP address to interface BRI 1/0, and configure C-DCC parameters and the dial string for
placing calls to Router A.
[RouterB-Bri1/0] dialer route ip 100.1.1.1 8810048
# Enable the local end to place return calls for ISDN calling number 8810048.
[RouterB-Bri1/0] dialer call-in 8810048 callback
Router-to-PC Callback with DCC

z PC and Router are interconnected through modems across a PSTN network.
z Interface Serial 2/0 on Router is assigned the IP address of 100.1.1.1/24.
1-44
z PC accepts the address assigned by Router.
Configure PPP callback with C-DCC between Router and PC, specifying PC as the callback client and
Router as the callback server to make return calls according to dialer routes.
Network diagram
Figure 1-17 Network diagram for router-to-PC callback with DCC
1) Configure PC (installed with Windows 2000 for example)

Do the following to create a dialup connection with callback capability enabled:
# Place the modem connected to PC in auto answer mode.
# Select [Start/Programs/Accessories/Communications/Network and Dial-up Connections]. In the
[Network and Dial-up Connections] window, right-click on the Make New Connection icon; and in the
popup menu select the New Connectionoption. The [Network Connection Wizard] window appears.
Click <Next>.
# In the [Network Connection Type] dialog, select the Dial-up to the Internet option, and click <Next>.
The [Internet Connection Wizard] dialog appears. Select to set up the Internet connection manually.
Click <Next>.
# In the [Setting up your Internet connection] dialog box, select the I connect through a phone line
and a modem option. Click <Next> to set Internet account connection information.
# Type in the phone number for dialing to the callback server. Click <Next>.
# Type in the username and password that you want to use for PPP authentication when connecting to
the server. Click <Next>.
# Assign a name to your new connection and follow the instruction to complete the connection setup.
# In the [Network and Dial-up Connections] window, right-click on the connection just created, and in the
popup menu select the Properties option.
# In the properties setting dialog, select the [Networking] tab. In the Type of dial-up server I am calling
drop-down list, select PPP: Windows 95/98/NT4/2000, Internet. Click <Settings> to do the following:
z Select the Enable LCP extensions check box.
z Unselect the Enable software compression check box.
z Unselect the Negotiate multi-link for single link connections check box.
Click <OK>.
# Turn to the [ Network and Dial-up Connections] window. Click on the connection icon you just created.
Then, from the menu bar, select [Advanced/Dial-up Preferences]. In the [Dial-up Preferences] dialog,
select the [Callback] tab and do one of the following:
1-45
z Select the No callback option. After the PPP authentication is passed in a call, this option prevents
the callback server from disconnecting the current connection and calling back. Instead, the server
will maintain the current connection and allow the client to access the LAN or the Internet.
z Select the Ask me during dialing when the server offers option. The callback server will use the
callback number you input to place return calls.
z Select the Always call me back at the number(s) below option. The callback server will place
return calls always at the number or numbers already set.
2) Configure Router
# Configure a dial access control rule for dialer access group 1; create a local user account userpc for
PC and configure PPP authentication for the account.
<Router> system-view
[Router] dialer-rule 1 ip permit
[Router] local-user userpc
[Router-luser-userc] password simple userpc
[Router-luser-userc] service-type ppp
[Router-luser-userc] quit
# Assign an IP address to interface Serial 2/0, and configure physical layer parameters.
[Router] interface serial 2/0
[Router-Serial2/0] ip address 100.1.1.1 255.255.255.0
[Router-Serial2/0] physical-mode async
[Router-Serial2/0] async mode protocol
# Configure PPP encapsulation and other PPP parameters on the interface.

[Router-Serial2/0] link-protocol ppp
[Router-Serial2/0] ppp authentication-mode pap
[Router-Serial2/0] ppp pap local-user Sysname password simple Sysname
# Configure the interface to assign an IP address to the remote end.

[Router-Serial2/0] remote address 100.1.1.2
# Specify interface Serial 2/0 as the PPP callback server, and set the callback reference to user mode.
In this case, DCC uses the dial string corresponding to the username configured in the dialer route
command to place return calls.
[Router-Serial2/0] ppp callback server
[Router-Serial2/0] dialer callback-center user
# Enable C-DCC on interface Serial 2/0 and configure C-DCC parameters.

[Router-Serial2/0] dialer enable-circular
[Router-Serial2/0] dialer-group 1
[Router-Serial2/0] dialer route ip 100.1.1.2 user userpc 8810052
[Router-Serial2/0] quit
[Router] user-interface tty1
[Router-ui-tty1] modem both
1-46
NT Server-to-Router Callback with DCC

z Router and NT Server are interconnected via modems across a PSTN network.
z NT Server is assigned the IP address of 100.1.1.254/24.
z Router accepts the address assigned by NT Server.
Configure PPP callback with C-DCC between Router and PC, specifying Router as the callback client
and NT Server as the callback server to make return calls according to dialer routes.
Network diagram
Figure 1-18 Network diagram for NT server-to-router callback with DCC
1) Configure Router
# Configure a dial access control rule for dialer access group 1; create a local user account usernt for
NT Server and configure PPP authentication for the account.
[Router] local-user usernt
[Router-luser-userc] password simple usernt
[Router-luser-userc] service-type ppp
[Router-luser-userc] quit
# Configure physical layer parameters for interface Serial 2/0.

# Configure PPP encapsulation and other PPP parameters.

[Router-Serial2/0] ppp authentication-mode pap
[Router-Serial2/0] ppp pap local-user Router password simple Router
# Configure the interface to obtain IP address through PPP negotiation.

[Router-Serial2/0] ip address ppp-negotiate
# Configure the interface as the PPP callback client.

[Router-Serial2/0] ppp callback client
[Router-Serial2/0] dialer timer enable 15
# Enable C-DCC and configure C-DCC parameters on the interface.

1-47
[Router-Serial2/0] dialer route ip 100.1.1.254 8810052
[Router] user-interface tty1
2) Configure NT Server
Note that for Microsoft Windows users, the server must be Windows 2000 and a higher version such as
Windows XP. For the purpose of this example, Windows 2000 is adopted.
Do the following to create a dialup connection with callback capability enabled:
# Right-click on the My Network Places icon and from the popup menu select the Properties option.
The [Network and Dial-up Connections] window appears.
# Right-click on the Make New Connection icon; and from the popup menu select the New
Connectionoption. The [Network Connection Wizard] window appears. Click <Next>.
# In the [Network Connection Type] dialog, select the Accept incoming connections option, and click
<Next> to set the device for incoming connections. Click <Next>. The [Incoming Virtual Private
Connection] window appears.
# Select the Allow virtual private connections option if the server is connected to the Internet to provide
Internet access requests for the client. If otherwise, select the Do not allow virtual private
connections. Then click <Next>.
# In the [Allowed Users] dialog, click <Add>. In the popup [New User] dialog add the username and
password for the PPP callback client and click <OK>. An icon for the new user account appears in the
box in the [Allowed Users] dialog.
# Select the new user and click <Properties>. The properties setting dialog appears.
# Under the [Callback] tab, do one of the following:
z Select the Do not allow callback option. After the PPP authentication is passed in a call, this
option prevents the callback server from disconnecting the current connection and calling back.
Instead, the server will maintain the current connection and allow the client to access the LAN or
the Internet.
z Select the Allow the caller to set the callback number option. After the PPP authentication is
passed in a call, the server will disconnect and then call back the client at the number configured in
the ppp callback ntstring dial-number command. This option is almost the same as the last option
except that the charges are paid by the server end rather than the client end.
z Select the Always use the following callback number option to set a callback number.
Click <OK>. The [Networking Components] dialog box appears.
# Set the Networking components (use the default). Click <Next>.
# Assign a name to your connection and Click <Finish> to complete the creation.
Circular Dial String Backup and Internet Access with DCC

z Router A and Router B are connected across a PSTN network.
z Router B works as an access server and is configured with an IP address of 100.1.1.254/24. It uses
the address range of 100.1.1.1/24 to 100.1.1.16/24 for address assignment. The PSTN dial strings
1-48
available on it are 8810048 through 8810055, allowing the router to provide services to 16 online
users.
z Router A accepts the IP address assigned by Router B.
Configure Router A on the dialup side to implement cyclic dial string backup with dialer routes.
Configure Router B on the access side to use asynchronous serial interfaces to provide DCC dialup
access and adopt PAP to authentication the dialup side.
Figure 1-20 presents another scenario where Router C and Router D are connected across an ISDN
network. The configurations of Router C and Router D are the same as those of Router A and Router B,
except that Router D uses an ISDN dial string 8810048, rather than PSTN dial strings, to provide
services.
Configure Router C and Router D to implement DCC with one dial string and use CHAP for
authentication.
Network diagram
Figure 1-19 Network diagram for dial string backup/access service with DCC (PSTN)
Figure 1-20 Network diagram for dial string backup/access service with DCC (ISDN)
1-49
Solution 1: Configure circular dial string backup on Router A on dialup side. On Router B, configure
C-DCC, allowing the router to set up connections on eight asynchronous serial interfaces; configure
C-DCC parameters on a dialer interface.
# Configure a dial access control rule for dialer access group 1; create a local user account userb for
Router B and configure PPP authentication for the account.
# Configure physical layer parameters for interface Serial 2/0 and enable PPP address negotiation.
[RouterA-Serial2/0] ip address ppp-negotiate
# Configure PPP encapsulation and authentication on the interface.

[RouterA-Serial2/0] ppp pap local-user user1 password simple user1
# On the interface, enable C-DCC, and configure C-DCC parameters and the dial strings for reaching
Router B.
...
# Configure a dial access control rule for dialer access group 2; create local user accounts user1
through user16 and configure PPP authentication for the accounts.
[RouterB] local-user user1
[RouterB-luser-user1] password simple user1
[RouterB-luser-user1] service-type ppp
[RouterB-luser-user1] quit
1-50
...
# Assign an IP address to interface Dialer0 and configure it to assign IP addresses for PPP users.
[RouterB-Dialer0] link-protocol ppp
[RouterB-Dialer0] remote address pool 1
# Enable C-DCC and configure C-DCC parameters on the interface.

# Configure physical and link layer parameters for interface Async 1/0.
[RouterB] interface async 1/0
[RouterB-Async1/0] async mode protocol
[RouterB-Async1/0] dialer circular-group 0
[RouterB-Async1/0] link-protocol ppp
[RouterB-Async1/0] ppp authentication-mode pap
[RouterB-Async1/0] ppp pap local-user userb password simple userb
[RouterB-Async1/0] quit
Repeat this step to configure physical and link layer parameters for interfaces Async 1/1 through Async
1/7.
# Configure user interfaces TTY 1 through TTY 7 for interfaces Async 1/0 through Async 1/7 and enable
modem dialup on them.
[RouterB-ui-tty1] quit
...
[RouterB-ui-tty8] quit
# Configure the address for address assignment.

[RouterB] domain system
[RouterB-isp-system] ip pool 1 100.1.1.1 100.1.1.16
[RouterB-isp-system] quit
3) Configure user PC
# Set the answering mode of the modem connected to the user PC (installed with Windows 2000 for
example) to auto answer.
1-51
[Network and Dial-up Connections] window, create a new connection.
[Network and Dial-up Connections] window, right-click on the Make New Connection icon; and in the
popup menu select the New Connectionoption. The [Network Connection Wizard] window appears.
Click <Next>.
# In the [Network Connection Type] dialog, select the Dial-up to the Internet option, and click <Next>.
The [Internet Connection Wizard] dialog appears. Select to set up the Internet connection manually.
Click <Next>.
# In the [Setting up your Internet connection] dialog box, select the I connect through a phone line
and a modem option. Click <Next> to set Internet account connection information.
# Type in the phone number for dialing to the callback server. Click <Next>.
# Type in the username (user16 for example) and password (user16 for example) that you want to use
for PPP authentication when connecting to the server. Click <Next>.
# Assign a name to your new connection and follow the instruction to complete the connection setup.
# In the [Network and Dial-up Connections] window, right-click on the connection just created, and in the
popup menu select the Properties option.
# In the properties setting dialog, select the [Networking] tab. In the Type of dial-up server I am calling
drop-down list, select PPP: Windows 95/98/NT4/2000, Internet. Click <Settings> to do the following:
z Select the Enable LCP extensions check box.
z Unselect the Enable software compression check box.
z Unselect the Negotiate multi-link for single link connections check box.
Click <OK>.
# Turn to the [ Network and Dial-up Connections] window. Click on the connection icon you just created.
Then, from the menu bar, select [Advanced/Dial-up Preferences]. In the [Dial-up Preferences] dialog,
select the No callback option under the [Callback] tab.
Double-click the created connection to dial.
Solution 2: On Router C on the dialup side configure a single dial string. On Router D on the access side,
use C-DCC approach to set up connection with Router C through an ISDN PRI interface; configure
DCC parameters on a dialer interface.
# Configure a dial access control rule for dialer access group 1; create a local user account userd for
Router D and configure PPP authentication for the account.
[RouterC] local-user userd
[RouterC-luser-userd] password simple user1
[RouterC-luser-userd] service-type ppp
[RouterC-luser-userd] quit
# Configure physical layer parameters for interface BRI 1/0 and enable PPP address negotiation.
[RouterC-Bri1/0] ip address ppp-negotiate
# Configure PPP encapsulation and PPP CHAP authentication on the interface.
1-52
[RouterC-Bri1/0] link-protocol ppp
[RouterC-Bri1/0] ppp authentication-mode chap
[RouterC-Bri1/0] ppp chap user user1
# On the interface enable C-DCC, and configure C-DCC parameters and the dial string for reaching
Router D.
[RouterC-Bri1/0] dialer route ip 100.1.1.254 8810048
5) Configure Router D
# Configure a dial access control rule for dialer access group 2; create local user accounts user1
through user16 and configure PPP CHAP authentication for the accounts.
<RouterD> system-view
[RouterD] dialer-rule 2 ip permit
[RouterD] local-user user1
[RouterD-luser-user1] password simple user1
[RouterD-luser-user1] service-type ppp
[RouterD-luser-user1] quit
...
# Set CE1/PRI interface E1 2/0 to work in PRI mode.

[RouterD] controller e1 2/0
[RouterD-E1 2/0] pri-set
[RouterD-E1 2/0] quit
# Enable C-DCC on interface Serial 2/0:15. (This interface is automatically created on CE1/PRI
interface E1 2/0.)
[RouterD-E1 2/0] interface serial 2/0:15
[RouterD-Serial2/0:15] dialer enable-circular
[RouterD-Serial2/0:15] dialer-group 2
# Assign an IP address to the serial interface.

[RouterD-Serial2/0:15] ip address 100.1.1.254 255.255.255.0
# Configure PPP encapsulation and other PPP parameters on the serial interface.
[RouterD-Serial2/0:15] link-protocol ppp
[RouterD-Serial2/0:15] ppp authentication-mode chap
[RouterD-Serial2/0:15] ppp chap user userd
[RouterD-Serial2/0:15] remote address pool 1
[RouterD-Serial2/0:15] quit
# Configure an IP address pool for assigning addresses to PPP users.
1-53
[RouterD] domain system
[RouterD-isp-system] ip pool 1 100.1.1.1 100.1.1.16
[RouterD-isp-system] quit
Troubleshooting
z Troubleshooting Cases
Troubleshooting Cases
Symptom 1:
DCC dialup connection cannot be set up because the modem does not dial when the router forwards
data.
Solution:
Check that:
z The modem and phone cable connections are correct, and the modem initialization process is
correct.
z The dial interface, if it is synchronous/asynchronous, is set to work in asynchronous protocol mode.
z DCC is enabled on the dial interface.
z A dialer route or dialer number command is available for the packets.
Symptom 2:
The remote end cannot be pinged after the modem is connected.
Solution:
Check that:
z The same link layer encapsulation is adopted at the two ends, and correct PPP parameters are
configured for authentication. You may use the debugging ppp all command to verify that.
z Correct IP address is assigned to the dial interface (physical or dialer).
z DCC is enabled on the dial interface.
z The correct dialer-group and dialer-rule commands are configured and associated to ensure that
the packets can pass.
z Use the debugging dialer event and debugging dialer packet commands to locate the problem.
1-54
Table of Contents
1 DLSw Configuration 1-1

DLSw Overview1-1
Introduction1-1
Differences Between DLSw v1.0 and DLSw v2.0 1-2
Protocols and Standards 1-3
Configuring DLSw in an Ethernet Environment 1-4
Creating DLSw Peers 1-4
Mapping a Bridge Set to DLSw 1-5
Adding an Ethernet Interface to a Bridge Set1-5
Setting DLSw Timers1-5
Configuring LLC2 Parameters1-6
Configuring the Multicast Function of DLSw v2.0 1-7
Configuring the Maximum Number of DLSw v2.0 Explorer Retries 1-7
Applying an ACL in DLSw 1-8
Configuring DLSw in an SDLC Environment 1-8
Configuring DLSw1-8
Configuring an SDLC Interface 1-9
Enabling DLSw Forwarding on an SDLC Interface 1-9
Configuring SDLC Roles 1-10
Configuring an SDLC Address for a Secondary Station 1-10
Configuring an SDLC Peer1-11
Configuring an SDLC XID 1-11
Configuring an SDLC Virtual MAC Address 1-12
Configuring the Properties of a Synchronous Serial Interface 1-12
Configuring Optional SDLC Parameters 1-13
Configuring Local Reachable MAC or SAP Addresses 1-14
Configuring Remote Reachability Information 1-15
Displaying and Debugging DLSw 1-15
DLSw Configuration Examples 1-16
Configuring LAN-to-LAN DLSw 1-16
Configuring SDLC-to-SDLC DLSw1-17
Configuring DLSw for SDLC-LAN Remote Media Translation 1-18
Configuring DLSw with VLAN Support 1-19
DLSw v2.0 Configuration Examples1-21
Troubleshooting DLSw1-22
Unable to Establish a TCP Connection 1-22
Unable to Establish a DLSw Circuit1-23
i
1 DLSw Configuration
DLSw Overview
When configuring DLSw, go to the following sections for information you are interested in:
z DLSw Overview
z Configuring DLSw in an Ethernet Environment
z Configuring DLSw in an SDLC Environment
z Configuring Local Reachable MAC or SAP Addresses
z Configuring Remote Reachability Information
z Displaying and Debugging DLSw
z DLSw Configuration Examples
z Troubleshooting DLSw
Introduction
Data Link Switching (DLSw) was jointly developed by Advanced Peer-to-Peer Networking (APPN)
Implementers Workshop (AIW) and the Data-Link Switching Related Interest Group (DLSw RIG) for
transmitting Systems Network Architecture (SNA) traffic over a TCP/IP network. SNA was developed by
IBM in respect to the OSI reference model. The DLSw technique is a solution for cross-WAN
transmission of SNA traffic.
The DLSw mechanism is shown in the following figure:
Figure 1-1 DLSw mechanism
1) The router that runs DLSw converts logical link control type 2 (LLC2) frames from the local SNA
device into Switch-to-Switch Protocol (SSP) frames that can be encapsulated in TCP packets,
2) The SSP frames are forwarded across the WAN over a TCP connection to the remote router, and
3) The remote router converts the SSP frames back into LLC2 frames and sends them to the peer
SNA device.
1-1
As a result, the remote SNA device appears to be on the same network with the local SNA device.
Different from transparent bridging, DLSw does not forward LLC2 frames transparently to the peer.
Instead, it converts the LLC2 frames into SSP frames for data encapsulation in TCP packets. The local
termination mechanism of DLSw eliminates the requirement for link layer acknowledgments and
keepalive messages to flow across a WAN. It also solves the data link control timeout problem.
DLSw also enables transmission of synchronous data link control (SDLC) traffic across a TCP/IP WAN
by first converting SDLC frames to LLC2 frames, and then transporting them to the remote end system
through SSP. Thus, DLSw can be used for interconnection between LAN and SDLC media.
Currently, two DLSw versions are available: version 1.0 and version 2.0. DLSw v1.0 is implemented
based on RFC 1795, while DLSw v2.0 is implemented based on RFC 2166 and is intended to improve
product maintainability and to reduce network cost. In addition, DLSw v2.0 provides enhancements by
means of UDP explorer frames sent in multicast and unicast modes. When the peer is also running
DLSw v2.0, the two ends can use UDP packets to explore reachability, and a TCP connection is
established only when data transmission is required.
z SDLC is an IBM data link layer protocol, for use in IBM SNA networks.
z For more information on LLC, refer to IEEE 802.2 standard.
Differences Between DLSw v1.0 and DLSw v2.0
Problems with DLSw v1.0
z TCP connection
In DLSw v1.0, immediately after a pair of peers is configured, the local peer attempts to establish a TCP
connection with the remote peer (by first establishing two TCP connections and bringing down one of
them after capabilities exchange), regardless whether a connection is needed. All packets, including
explorer frames, circuit setup requests and data packets, are transmitted over the TCP connection. This
wastes network resources.
z Excessive broadcasts
Although a local acknowledgement mechanism is provided in DLSw v1.0, explorer frames may flood
the WAN over the established TCP connections if the reachability table of DLSw contains a small
number of entries or no entries.
z Low maintainability
When a circuit is disconnected, DLSw v1.0 uses two types of messages to notify the peer but cannot tell
the disconnection cause. This adds to difficulty in locating the reason for an abnormal circuit
disconnection.
Enhancements in DLSw v2.0
DLSw v2.0 provides enhancements to address the above-mentioned problems while it remains
compatible with DLSw v1.0.
The components on a DLSw network are defined as follows:
1-2
Figure 1-2 DLSw v2.0 network
In Figure 1-2, the origin station is the end station that originates communication, the target station is the
end station that accepts communication, the origin DLSw router is a DLSw-enabled router connected to
the origin station, and the target DLSw router is a DLSw-enabled router connected to the target station.
In this document, an origin DLSw v2.0 router is a DLSw v2.0capable router.
z Using UDP packets to explore peer addresses
To prevent unnecessary TCP connection setups, DLSw v2.0 sends explorer frames by using UDP
packets instead of over TCP connection, unless a TCP connection is present. These UDP packets can
be sent in two ways: multicast and unicast (depending on the specific situation). Using UDP packets
reduces, to some degree, the TCP connections required, and thereby saves network resources.
z Setting up a single TCP connection when required
A TCP connection is set up after the origin and target DLSw v2.0 routers get reachability information
using UDP packets and when both the origin and target stations want to set up a circuit between them.
A DLSw circuit establishment process is simplified into two stages: first, establishment of a single TCP
connection; then, capabilities exchange. If capabilities negotiation fails, the source-end DLSw v2.0
router sends a reject packet to the peer and then the TCP connection is taken down.
As a TCP connection is established only when a circuit is required between two end systems, the
overheads of establishing and maintaining TCP connections are reduced, resulting in better system
resource utilization.
In case the origin and target DLSw routers use different versions of DLSw, for backward compatibility,
the one uses DLSw v2.0 works as a DLSw v1.0 router and follows RFC 1795 when setting up a TCP
connection with its peer.
z Enhanced maintainability
To enable a DLSw router to notify its peer about the reason for dropping a connection, DLSw v2.0
defines five generic circuit halt reason codes: unknown error, received DISC from end-station, detected
DLC error with end-station, circuit-level protocol error, and operator-initiated. The halt reason codes are
sent to the peer in SSP messages.
Protocols and Standards
DLSw is documented in:
1-3
z RFC 1795: Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages,
DLSw Standard Version 1.0.
z RFC 2166: APPN Implementer's Workshop Closed Pages Document DLSw V2.0 Enhancements.
Configuring DLSw in an Ethernet Environment

Follow these steps to configure DLSw in an Ethernet environment:

Enable bridging bridge enable Required
Enable a bridge set bridge bridge-set enable Required
Optional
Enable DLSw dlsw enable
Enabled by default
Create a local DLSw peer Refer to Creating DLSw Peers Required
Map a bridge set to DLSw Refer to Mapping a Bridge Set to DLSw Required
Add an Ethernet interface to the Refer to Adding an Ethernet Interface to a
Required
bridge set Bridge Set
Set DLSw timers Refer to Setting DLSw Timers Optional
Configure LLC2 parameters Refer to Configuring LLC2 Parameters Optional
Configure the multicast function Refer to Configuring the Multicast Function

Optional
of DLSw v2.0 of DLSw v2.0
Configure the maximal
Refer to Configuring the Maximum Number
attempts of sending an explorer Optional
of DLSw v2.0 Explorer Retries
frame in DLSw v2.0
Apply an ACL in DLSw so that
DLSw handles only Ethernet Refer to Applying an ACL in DLSw Optional
frames that match the ACL
Configure local reachable MAC Refer to Configuring Local Reachable MAC
Optional
or SAP addresses or SAP Addresses
Configure the remote
Refer to Configuring Remote Reachability
reachability information for the Optional
Information
router
For more information on bridge and bridge set configuration, refer to Bridge Configuration in the Access
Volume.
Creating DLSw Peers
Establishing a TCP connection is the first step in establishing a DLSw circuit. To establish a TCP
connection, you need to specify the IP addresses of both end systems across the TCP connection.
Before the local router can initiate or accept a TCP connection request, you need to configure a local
DLSw peer specifying the IP address of the local end of the TCP connection. A router can only have one
local peer.
After a local peer is created, a remote DLSw peer should be created to establish a TCP connection. The
following command specifies the IP address of the remote router with which a TCP connection is to be
established. After the configuration, the router will keep attempting to establish a TCP connection with
1-4
the remote router. A router can have multiple remote peers. A local DLSw peer must be created before
you can create a remote DLSw peer for it.
Follow these steps to create DLSw peers:

dlsw local ip-address [ init-window Required

init-window-size | keepalive keepalive-interval The IP address specifies
Create a local
| max-frame max-frame-size | max-window with ip-address must be a
DLSw peer
max-window-size | permit-dynamic | reachable IP address of the
vendor-id vendor-id ] * local host.
dlsw remote ip-address [ backup Required

backup-address | keepalive keepalive-interval The IP address specified
Create a remote
| linger minutes | max-frame max-frame-size | with ip-address must be a
DLSw peer
max-queue max-queue-length | priority reachable IP address of the
priority ] * remote DLSw router.
Deleting a local DLSw peer will delete all its remote DLSw peers at the same time.
Mapping a Bridge Set to DLSw
DLSw was developed based on the bridging technology. Bridging between different Ethernet interfaces
is possible if these interfaces are configured in the same bridge set. To enable forwarding frames of a
bridge set to a remote end system over a TCP connection, use the dlsw bridge-set command to map
the bridge set to DLSw. This command can be used repeatedly to map multiple bridge sets to DLSw.
Follow these steps to map a bridge set connected to DLSw:

Required
By default, no bridge set is mapped to DLSw.
Map a bridge set to dlsw bridge-set
DLSw bridge-set This command should be used in conjunction with
the bridge bridge-set enable command, with the
same bridge-set value in both commands.
Adding an Ethernet Interface to a Bridge Set
By adding an Ethernet interface to a bridge set and mapping the bridge set to DLSw, you can enable
transmission of LLC2 frames on the Ethernet interface to a remote end system over a TCP connection.
For details about bridge set configuration, refer to Bridge Configuration in the Access Volume.
Setting DLSw Timers
You can configure the timers used in creating DLSw circuits as per your actual needs.
1-5
Follow these steps to set DLSw timers:

Required
Defaults:
dlsw timer { cache | connected z cache: 120 seconds
Configure DLSw | explorer | explorer-wait | z connected: 300 seconds
timer parameters local-pending | z explorer: 30 seconds
remote-pending } seconds
z explorer-wait: 30 seconds
z local-pending: 30 seconds
z remote-pending: 30 seconds
Note that the timer values should be modified only when necessary.
Configuring LLC2 Parameters
SNA was designed to transmit LLC2 frames over Ethernet. By means of LLC2 related commands, you
can modify some LLC2 parameters.
Follow these steps to configure LLC2 parameters:

Enter interface view
interface-number
Configure the maximum number of Required
information frames the router can receive llc2 max-ack length
before it must send an acknowledgement 3 by default
Configure the maximum number of

consecutive information frames the router Optional
llc2 receive-window length
can send before receiving an 7 by default
acknowledgement from the peer
Optional
Configure the length of LLC2 output queue llc2 max-send-queue length
50 by default
Optional
Configure the modulus value of LLC2 llc2 modulo { 8 | 128 }
128 by default
Configure the number of LLC2 llc2 max-transmission Optional

transmission retries retries 3 by default
Optional
Configure the maximum LLC2 PDU llc2 max-pdu length
1,493 bytes by default
Configure the LLC2 local acknowledgment llc2 timer ack-delay Optional

delay time mseconds 100 ms by default
Configure LLC2 acknowledgment waiting Optional

llc2 timer ack mseconds
time 200 ms by default
Configure LLC2 busy-station polling Optional

llc2 timer busy mseconds
interval 300 ms by default
1-6
Optional
Configure the LLC2 P/F waiting time llc2 timer poll mseconds
5,000 ms by default
Optional
Configure the LLC2 REJ status time llc2 timer reject mseconds
500 ms by default
Optional
Configure the LLC2 POLL timer llc2 timer detect mseconds
30,000 ms by default
Configuring the Multicast Function of DLSw v2.0
Before configuring the multicast function of DLSw v2.0, you first need to configure the multicast function
of the router and the local DLSw peer. DLSw v2.0 multicast must be enabled before the origin DLSw
v2.0 router can multicast SOCKET messages (with explorer frames encapsulated) to a specific
multicast address, so that all target DLSw v2.0 routers listening to the multicast address can receive the
SOCKET messages and get the explorer frames.
Follow these steps to configure the multicast function of DLSw v2.0:

dlsw multicast [ multicast-ip-address ] Required
Enable the multicast function of
DLSw v2.0 Disabled by default
interface-number
z By default, the DLSw multicast function is disabled on devices running DLSw v2.0. To enable this
function, use the dlsw multicast command.
z Before you can enable the DLSw multicast function, you need to configure the outbound multicast
interface specified with interface interface-type interface-number in the above-mentioned
command on the same interface as the local DLSw peer.
z Before the DLSw multicast can be enabled, you need to carry out the related multicast command
first.
Configuring the Maximum Number of DLSw v2.0 Explorer Retries
Each time the origin DLSw v2.0 router sends an explorer frame in a UDP multicast, it starts an explorer
timer. If no response is received before the explorer timer times out, the router sends another explorer
frame and resets the explorer timer. This process continues until a response is received or the
maximum number of explorer transmission retries is reached.
Follow these steps to configure the maximum number of explorer transmission retries:

1-7
Set the maximum number of dlsw max-transmission Optional

explorer transmission retries retries 5 by default
Applying an ACL in DLSw
Follow these steps to apply an ACL in DLSw:

acl number acl-number

[ match-order { auto | config } ]
Required
Create a MAC-based rule [ rule-id ] { deny | permit }
Layer 2 ACL [ fragment | logging | source No Layer 2 ACL is configured
{ sour-addr sour-wildcard | any } | by default.
time-range time-name | vpn-instance
vpn-instance-name ] *
Return to system view quit
dlsw ethernet-frame-filter Required

Apply a MAC-based acl-number inbound By default, no ACL is applied.
ACL on inbound and/or ACLs for inbound and
outbound traffic dlsw ethernet-frame-filter
outbound traffic can be
acl-number outbound
configured at the same time.
For details about creating a Layer 2 ACL, refer to ACL Configuration in the Security Volume.
Configuring DLSw in an SDLC Environment

Configuring DLSw
Follow these steps to configure DLSw:

Optional
Enable DLSw dlsw enable
Enabled by default
Create a local DLSw peer Refer to Creating DLSw Peers Required
Configure an SDLC interface Refer to Configuring an SDLC Interface Required

Enable DLSw forwarding on an Refer to Enabling DLSw Forwarding on an
Required
SDLC interface SDLC Interface
Configure SDLC roles Refer to Configuring SDLC Roles Required
Configure an SDLC address for Refer to Configuring an SDLC Address for a
Required
a secondary station Secondary Station
Configure an SDLC peer Refer to Configuring an SDLC Peer Required
Optional (required
Configure the XID of SDLC Refer to Configuring an SDLC XID
for PU2.0 devices)
1-8
Configure an SDLC virtual Refer to Configuring an SDLC Virtual MAC
Optional
MAC address Address
Configure the properties of a Refer to Configuring the Properties of a
Optional
synchronous serial interface Synchronous Serial Interface
Configure optional SDLC Refer to Configuring Optional SDLC
Optional
parameters Parameters
Configure the multicast function Refer to Configuring the Multicast Function
Optional
of DLSw v2.0 of DLSw v2.0
Configure the maximal number Refer to Configuring the Maximum Number
Optional
of DLSw v2.0 explorer retries of DLSw v2.0 Explorer Retries
Configure local reachable MAC Refer to Configuring Local Reachable MAC
Optional
or SAP addresses or SAP Addresses
Configure the remote Refer to Configuring Remote Reachability
Optional
reachability information Information
Configuring an SDLC Interface
The SDLC is a link layer protocol relative to the SNA. Its working principle is similar to that of HDLC. In
order to make DLSw work normally, you need to configure an SDLC interface by specifying SDLC as
the link layer protocol on the synchronous serial interface.
Follow these steps to configure an SDLC interface:

interface-number
Configure SDLC encapsulation Required

link-protocol sdlc
on the interface PPP encapsulation by default
Note that the SDLC link layer protocol cannot underlie the IP protocol, so all the IP-related
configurations on the interface must be removed before you configure SDLC encapsulation. For
example, you need to delete the IP address of the interface.
Enabling DLSw Forwarding on an SDLC Interface
With DLSw forwarding enabled on the SDLC interface, all local SNA devices connected to the interface
will be able to communicate with the remote device through DLSw.
Follow these steps to enable DLSw forwarding on an SDLC interface:

interface-number
Enable DLSw forwarding on the Required

sdlc enable dlsw
interface Disabled by default
1-9
Configuring SDLC Roles
In contrast with HDLC, SDLC is an unbalanced link layer protocol. That is, the end systems across a
TCP connection are not equal in the positions: one is primary and the other is secondary. The primary
station, whose role is primary, plays a dominant role and controls the whole connection process. The
secondary station, whose role is secondary, is controlled by the primary station. Therefore, we need to
configure a role for an SDLC interface.
In the SDLC role configuration, the role of an interface should be determined by the role of the SDLC
device to which this router is connected:
z If the SDLC device connected with the local router has a role of primary, the local interface should
be configured to have a role of secondary;
z If the SDLC device connected with the local router has a role of secondary, the local interface
should be configured to have a role of primary.
Generally, an IBM mainframe has a role of primary, while a terminal device such as a UNIX host or an
Auto Teller Machine (ATM) has a role of secondary.
Follow these steps to configure an SDLC role:

interface-number
sdlc status { primary | Required

Configure an SDLC role
secondary } By default, no SDLC role is configured.
Configuring an SDLC Address for a Secondary Station
The SDLC protocol allows multiple virtual circuits to run on an SDLC physical link, with one end
connected to the primary station and the other end to a secondary station. In order to distinguish
different virtual circuits, you need to specify an SDLC address for each virtual circuit. SDLC is an
unbalanced protocol, a primary station can be connected with multiple secondary devices through a
multi-user system or an SDLC switch, while the secondary devices cannot be connected with one
another. Therefore, the communication between the primary station and each secondary station can be
guaranteed as long as each secondary device is identified with an SDLC address.
The following command is used to specify an SDLC address for a virtual circuit, which is unique on a
physical interface. The configured SDLC address on a synchronous serial interface is actually the
address of the secondary SDLC station. On the serial interface of the DLSw router connected with the
primary SDLC station, you need to configure the address of each secondary SDLC station that
communicates with the primary station. On the serial interface of the DLSw router connected with a
secondary SDLC station, you need to configure the address of each secondary SDLC station
connected with the serial interface.
An SDLC address ranges from 0x01 to 0xFE. The SDLC address of a router is valid on only one
physical interface. That is, the SDLC addresses configured on different interfaces may be the identical.
Follow these steps to configure an SDLC address:
1-10
interface-number
Required
Configure the address of an
sdlc controller sdlc-address By default, no secondary SDLC
secondary SDLC station
station address is configured.
Configuring an SDLC Peer
The following command is used to specify the MAC address of the corresponding peer end for an SDLC
virtual circuit so as to provide the destination MAC address for SDLC-to-LLC2 frame conversion. In
DLSw configuration, a peer should be configured for each SDLC address. The MAC address of the peer
should be the MAC address of the remote SNA device (physical address in the Ethernet or Token Ring
format), or the compound MAC address derived from SDLC virtual MAC address of the peer end and
the SDLC address of the local end.
Follow these steps to configure the SDLC peer:

Configure MAC address
dlsw reverse
conversion between Ethernet Optional
mac-address
and token ring formats
interface-number
sdlc mac-map remote Required

Configure an SDLC peer
mac-addr sdlc-addr By default, no SDLC peer is configured.
When specifying an SDLC peer MAC address for an SDLC virtual circuit, pay attention to the following
situations:
z If the remote SNA device uses a token ring address, use its token ring address directly;
z If the remote SNA device uses an Ethernet address, convert the Ethernet address to a token ring
address, for example, convert 00e0.fc03.a548 to 0007.3fc0.5a12, by using the dlsw reverse
command;
z If the remote SNA device uses an SDLC link, specify a compound MAC address, in which the first
five bytes are from the virtual MAC address configured in the sdlc mac-map local command on
the remote router, and the last byte is the SDLC address of the local router.
Configuring an SDLC XID
An XID is used to identify a device in an SNA system. When configuring an SDLC connection, pay
attention to the types of the connected SNA devices. Generally, there are two types of devices in an
1-11
SNA system: PU2.0 and PU2.1. An XID has been configured on PU2.1 devices, so they can announce
their identity by exchanging the XID. A PU2.0 device does not come with an XID. Therefore, an XID is
not required on a PU2.1 device, but it is required on a PU2.0 device.
Follow these steps to configure an SDLC XID:

interface-number
Optional
sdlc xid sdlc-address
Configure an SDLC XID By default, no SDLC XID is configured on
xid-number
a synchronous serial interface.
Configuring an SDLC Virtual MAC Address
Initially designed for LLC2 protocols, DLSw establishes mappings with virtual circuits through MAC
addresses. Therefore, a MAC address must be specified for an SDLC virtual circuit so that SDLC
frames can be forwarded. Use the following command to assign the current interface a virtual MAC
address, which will serve as the source MAC address during the conversion of SDLC frames to LLC2
frames.
Follow these steps to configure an SDLC virtual MAC address:

interface-number
Configure an SDLC virtual sdlc mac-map local Optional

MAC address mac-address No virtual MAC address by default
Note that the sixth byte of the MAC address should be set to 0x00. The system will combine the first five
bytes of this virtual MAC address with the SDLC address into a new MAC address, which will serve as
the source MAC address in SDLC-to-LLC2 frame format conversion.
Configuring the Properties of a Synchronous Serial Interface
In practice, there are many types of SNA devices which differ from one another significantly. The
following commands are used to tune some commonly used parameters to ensure the compatibility
among different devices.
z Configure the encoding scheme of the synchronous serial interface
There are two encoding schemes, NRZI and NRZ, for synchronous serial interface. The NRZ encoding
scheme is generally used for synchronous serial interfaces of routers. The serial interfaces of some
1-12
SNA devices, however, use the NRZI encoding scheme. Therefore, the encoding scheme of routers
should be changed according to the encoding schemes used on the connected devices.
z Configure the idle-time encoding scheme of the synchronous serial interface
While most SDLC devices use 0x7E (flags) to indicate idle space between frames, some other SDLC
devices use 0xFF (marks) for this indication. For compatibility with different types of devices, you can
configure the router to send either flags (default) or marks to indicate its idle state.
Follow these steps to configure the properties of the synchronous serial interface:

interface-number
Configure the baud rate of the Optional

baudrate baudrate
synchronous serial interface 9,600 bps by default
Configure the synchronous serial Optional

code { nrz | nrzi }
interface to use NRZI encoding NRZ encoding by default
Configure the synchronous serial Optional

interface to send 0xFF (marks) idle-mark
during idle state 0x7E by default
Generally it is not required to change the idle-time encoding scheme of a synchronous serial interface,
except when the synchronous serial interface is connected to an AS/400 device.
Configuring Optional SDLC Parameters
Follow these steps to configure optional SDLC parameters:

interface-number
Configure the length of the Optional

sdlc max-send-queue length
SDLC output queue 50 by default
Configure the maximum
number of consecutive frames Optional
the device can send before sdlc window length
receiving an acknowledgement 7 by default
from the peer
Configure the modulus value of Optional

sdlc modulo { 8 | 128 }
SDLC 8 by default
1-13
Optional
265 bytes by default
The maximum PDU size of
Configure the maximum SDLC some PU2.0 devices is 265
sdlc max-pdu number bytes, while that of an IBM
PDU size
AS/400 is 521 bytes. Typically,
this maximum PDU size should
be configured to be the same
as on the peer SDLC device.
Configure the maximum Optional
number of SDLC transmission sdlc max-transmission retries
retries 20 by default
Configure the local and remote sdlc sap-map local lsap

SAP addresses for sdlc-addr Optional
SDLC-to-LLC2 frame sdlc sap-map remote dsap 0x04 by default.
conversion sdlc-addr
Optional
Enable SDLC simultaneous Alternate mode by default
sdlc simultaneous
mode Generally, this configuration is
not required.
Configure the SDLC polling Optional

sdlc timer poll mseconds
interval 1,000 ms by default.
Configure the amount of time
the primary SDLC station waits Optional
sdlc timer ack mseconds
for an acknowledgment from 3,000 ms by default
the receiving secondary station
Configure the amount of time a
secondary SDLC station waits Optional
sdlc timer lifetime mseconds
for an acknowledgment from 500 ms by default
the receiving primary station
A SAP address refers to the address of one or more applications running on a computer or network
device.
Configuring Local Reachable MAC or SAP Addresses

To reduce the exploring time before the routers send information frames when network topology is
stable, you can manually configure the local reachable MAC addresses or SAP addresses.
Follow these steps to configure the local reachable MAC addresses or SAP addresses:
1-14
Required
Specify a local dlsw reachable { mac-address
reachable MAC address mac-address [ mask mask ] | No local reachable MAC or
or SAP address mac-exclusivity | saps saps-list } SAP addresses are configured
by default.
Configuring Remote Reachability Information

To reduce the exploring time before the routers send information frames when network topology is
stable, you can manually configure the reachability information of the remote end for the router.
Follow these steps to configure the remote reachability information:

Configure the dlsw reachable-cache Required

reachability information mac-address remote No remote reachability information is
of the remote end ip-address configured by default.
Displaying and Debugging DLSw

Display the capabilities exchange display dlsw information
information [ ip-address | local ]
Display the information of a virtual display dlsw circuits [circuit-Id ]
circuit or all virtual circuits [ verbose ]
Display the information of a remote
display dlsw remote [ ip-address ] Available in any view
peer or all remote peers
Display the reachability information
display dlsw reachable-cache Available in any view
list of DLSw
Display LLC2 statistics information display llc2 [ circuit circuit-id ] Available in any view
Reset the TCP connection(s)
between the DLSw router and a reset dlsw tcp [ ip-address ] Available in user view
remote peer or all remote peers
Clear the information of a virtual
reset dlsw circuits [ circuit-id ] Available in user view
circuit or all virtual circuits
Clear the reachability information list
reset dlsw reachable-cache Available in user view
of DLSw
1-15
DLSw Configuration Examples
Configuring LAN-to-LAN DLSw
As illustrated in Figure 1-3, DLSw works in a LAN-LAN environment. Configure DLSw on Router A and
Router B to enable communication between an IBM host with an SNA host over the Internet.
Network diagram
Figure 1-3 Network diagram for LAN-to-LAN DLSw configuration
# Configure interface parameters on Router A to ensure that the local DLSw peer 1.1.1.1 and remote
peer 2.2.2.2 are pingable to each other (specific configuration steps omitted).
# Configure DLSw on Router A.
[RouterA] bridge enable
[RouterA] bridge 5 enable
[RouterA] dlsw local 1.1.1.1
[RouterA] dlsw remote 2.2.2.2
[RouterA] dlsw bridge-set 5
[RouterA] interface ethernet 1/0
[RouterA-Ethernet1/0] bridge-set 5
2) Configure Router B:
# Configure interface parameters on Router B to ensure that the local DLSw peer 2.2.2.2 and remote
# Configure DLSw on Router B.
[RouterB] bridge enable
[RouterB] bridge 7 enable
[RouterB] dlsw local 2.2.2.2
[RouterB] dlsw remote 1.1.1.1
[RouterB] dlsw bridge-set 7
[RouterB] interface ethernet 1/0
1-16
[RouterB-Ethernet1/0] bridge-set 7
After this configuration, the two SNA LANs across the Internet are interconnected.
Configuring SDLC-to-SDLC DLSw
As illustrated in Figure 1-4, DLSw works in an SDLC-to-SDLC environment. Configure DLSw on Router
A and Router B to enable communication between the two SDLC LANs over the Internet.
Network diagram
Figure 1-4 Network diagram for SDLC-to-SDLC DLSw configuration
Configure interface parameters on Router A to ensure that the local DLSw peer 1.1.1.1 and remote peer
2.2.2.2 are pingable to each other (specific configuration steps omitted).
[RouterA-Serial2/0] link-protocol sdlc
[RouterA-Serial2/0] sdlc enable dlsw
[RouterA-Serial2/0] sdlc status secondary
[RouterA-Serial2/0] sdlc controller c1
[RouterA-Serial2/0] sdlc mac-map remote 0000-2222-00c1 c1
[RouterA-Serial2/0] sdlc mac-map local 0000-1111-0000
[RouterA-Serial2/0] baudrate 9600
[RouterA-Serial2/0] code nrzi
Configure interface parameters on Router B to ensure that the local DLSw peer 2.2.2.2 and remote peer
1.1.1.1 are pingable to each other (specific configuration steps omitted)
1-17
[RouterB-Serial2/0] link-protocol sdlc
[RouterB-Serial2/0] sdlc enable dlsw
[RouterB-Serial2/0] sdlc status primary
[RouterB-Serial2/0] sdlc controller c1
[RouterB-Serial2/0] sdlc mac-map remote 0000-1111-00c1 c1
[RouterB-Serial2/0] sdlc mac-map local 0000-2222-0000
[RouterB-Serial2/0] baudrate 9600
[RouterB-Serial2/0] code nrzi
After this step, the SDLC LANs across the WAN are interconnected.
Configuring DLSw for SDLC-LAN Remote Media Translation
As shown in Figure 1-5, Host A and Host B are PU2.0 nodes (ATM), and Host C is a PU2.1 node (OS2).
Configure DLSw on Router A and Router B, using NRZ encoding on the port connected with the
multiplexer and NRZI encoding on the port connected with Host C, so that the IBM host can
communicate with all the SNA PCs over the Internet.
Network diagram
Figure 1-5 Network diagram for SDLC-LAN configuration
1-18
[RouterB-Serial2/0] sdlc xid c1 03e00001
[RouterB-Serial2/0] sdlc mac-map remote 0014-cc00-54af c1
[RouterB-Serial2/0] sdlc xid c2 03e00002
[RouterB-Serial2/1] code nrzi
# If the local and remote networks are stable, you can configure the following commands to save the
polling process.
[RouterB] dlsw reachable mac-exclusivity
[RouterB] dlsw reachable-cache 0014-cc00-54af remote 1.1.1.1
Note that in the configuration on router B, the MAC address in the sdlc mac-map remote and dlsw
reachable-cache commands is the MAC address of the Ethernet card of the AS/400 device, which is
connected to Router A. As an Ethernet MAC address appears in the reverse bit order of a Token-Ring
MAC address, bit order reversal is required in MAC address configuration (for example, a MAC address
0028-3300-2af5 appears to be 0014-cc00-54af after bit order reversal). If the peer end is Token-Ring,
bit order reversal is not required.
Configuring DLSw with VLAN Support
As shown in Figure 1-6, Ethernet 1/1 of the Ethernet switch is connected with an IBM host, Ethernet 1/0
of the switch is connected with Router A, and Ethernet 1/1 of Router B is connected with an SNA host.
1-19
Perform the following configuration so that the IBM host can communicate with the SNA host over the
Internet:
z Add Ethernet 1/1 to VLAN 2, and configure Ethernet 1/0 as a trunk port, allowing VLAN 2 of
Ethernet 1/1 to pass.
z Configure a sub-interface Ethernet 1/1.1 on Ethernet 1/1 of Router A and add this sub-interface to
VLAN 2.
Configure DLSw on Router A and Router B.
Network diagram
Figure 1-6 Network diagram for DLSw configuration with VLAN support
[RouterA-Ethernet1/0] ip address 1.1.1.1 255.255.255.0
[RouterA-Ethernet1/0] quit
[RouterA] rip
[RouterA-rip-1] network 1.0.0.0
[RouterA-rip-1] quit
# Configure DLSw on Router A

[RouterA] interface ethernet 1/1.1
[RouterA-Ethernet1/1.1] bridge-set 1
1-20
[RouterB] dlsw bridge-set 1
[RouterB-Ethernet1/1] ip address 2.2.2.2 255.255.255.0
[RouterB-Ethernet1/1] quit
[RouterB] rip
[RouterB-rip-1] network 2.0.0.0
[RouterB-rip-1] quit
3) Configure LSW
# Create VLAN 2, and assign Ethernet 1/1 to it.
<LSW> system-view
[LSW] vlan 2
[LSW-vlan2] port ethernet 1/1
[LSW-vlan2] quit
# Set Ethernet 1/0 to trunk mode and allow VLAN 2 to pass.

[LSW] interface ethernet1/0
[LSW-Ethernet1/0] port link-type trunk
[LSW-Ethernet1/0] port trunk permit vlan 2
DLSw v2.0 Configuration Examples
As shown in Figure 1-7, Router A is DLSw v2.0 capable, connected with an IBM host, Router B and
Router C are DLSw v1.0 or DLSw v2.0 capable, respectively connected with PC1 and PC2, and CISCO
is a DLSw-capable router of Cisco, connected with PC3. All the DLSw routers listen to the multicast
address 224.0.10.0. Enable the IBM host to communicate with all SNA hosts.
Network diagram
Figure 1-7 Network diagram for DLSw v2.0 configuration
1-21
1) Configure Router A.
# Configure bridge set 1.
# Add Ethernet 1/1 to bridge set 1.

# Enable multicast.
[RouterA] multicast routing-enable
[RouterA-Ethernet1/0] pim dm
[RouterA-Ethernet1/0] igmp enable
[RouterA-Ethernet1/0] igmp static-group 224.0.10.0
# Configure local DLSw peers, configure the permit-dynamic keyword to allow a remote peer that is
not preconfigured to initiate a TCP connection for dynamic remote peer creation.
[RouterA] dlsw local 1.1.1.1 permit-dynamic
# Enable DLSw multicast, set the maximum number of explorer retries and specify a local bridge set.
[RouterA] dlsw multicast interface ethernet 1/0
[RouterA] dlsw max-transmission 3
2) Configure Router B and Router C
Before configuring Router B and Router C, first make sure of which DLSw version they support. If they
are DLSw v2.0 capable, the configuration is similar as on Router A; if they are DLSw v1.0 capable,
remove the multicast and explorer frame retransmission part from the configuration.
For the configuration on the Cisco router, refer to Cisco documentation.
Troubleshooting DLSw
Proper communication of the DLSw needs sound cooperation between the involved SNA devices and
DLSw-capable routers. A fault in the cooperation between any two nodes may cause connection failure.
Unable to Establish a TCP Connection
Symptom
A TCP connection cannot be established and the status information given by the display dlsw remote
command is DISCONNECT.
Analysis
TCP connection establishment is the first step in successful DLSw connection. Failure in establishing a
TCP connection is usually caused by problems between the two routers, normally incorrect IP routing
configuration.
1-22
Solution
Check whether the IP address of the remote peer is reachable by using the ping command carrying the
source address. Alternatively, use the display ip routing-table command to check whether there is a
route to the network segment. After both sides have established a correct route, the TCP connection
can be created.
Unable to Establish a DLSw Circuit
Symptom
A DLSw circuit cannot be correctly established. The display dlsw circuit command shows that the
virtual circuit cannot come into the CONNECTED state.
Analysis
Many reasons can cause circuit establishment failure.

z A TCP connection with the peer end must be successfully established first.
z If a TCP connection can be successfully established but circuit establishment fails, the problem is
usually cause by abnormal cooperation between the router and the SNA device, most likely from
some incorrect SDLC configuration.
Solution
1) First enable the SDLC debugging, and check whether the SDLC interface can receive/forward
frames normally by executing the display interface command. If the interface cannot
receive/forward frames correctly, possible causes are incorrect encoding scheme, baud rate or
clock configuration on the interface. Modify the interface configuration parameters of the router or
adjust the configuration parameters of the SDLC device.
2) If frames can be received and forwarded correctly, examine whether the configuration of the PU
type is correct. Use the sdlc xid command to configure the XID and change the configuration of the
PU type.
3) If the PU type is correct, use the display dlsw circuit verbose command to check whether the
virtual circuit can enter the CIRCUIT_EST state. If not, the MAC address of the SDLC peer is not
correctly configured. Use the sdlc mac-map remote command to modify the configuration
parameters.
4) If the circuit can reach the CIRCUIT_EST state, but cannot reach the CONNECTED state, this
means that the configuration of the SDLC on the router does not match that of the SNA devices.
Check the configuration of the SDLC devices on both sides and the configuration of the router. For
example, check whether the XID of the SNA device is properly configured (PU2.1), and whether
the XID of the router is properly configured (PU2.0). If all these configurations are correct, check
whether the SDLC line on the primary SDLC device side (such as the AS/400 or S390) is activated.
Sometimes the SDLC line needs to be activated manually.
1-23
Table of Contents
1 Frame Relay Configuration1-1

Frame Relay Terminologies1-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 Mapping1-3
Frame Relay Configuration Task List1-4
Configuring DTE Side Frame Relay1-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 Network1-8
Configuring X.25 Parameters for a VC1-9
Configuring Annex G 1-10
Configuring DCE Side Frame Relay 1-12
Configuring Basic DCE Side Frame Relay1-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 Network1-13
Configuring X.25 parameters for a VC 1-13
Configuring Annex G 1-13
Enabling Trap1-13
Displaying and Maintaining Frame Relay 1-14
Frame Relay Configuration Examples 1-14
Interconnecting LANs through the Frame Relay Network1-15
Interconnecting LANs through Dedicated Line1-16
Interconnecting LANs through an Annex G DLCI 1-17
Troubleshooting Frame Relay1-19
Frame Relay Compression 1-19
Overview1-20
Configuring FRF.9 Compression1-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 Example1-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 Example2-3
MFR Direct Connection Configuration Example 2-3
MFR Switched Connection Configuration Example 2-4
3 PPPoFR Configuration 3-1

Overview 3-1
Configuring PPPoFR3-1
Displaying and Maintaining PPPoFR 3-2
PPPoFR Configuration Example3-2
4 MPoFR Configuration4-1
Overview 4-1
Configuring MPoFR4-1
MPoFR Configuration Example 4-2
ii
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

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:N3911.
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:
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.
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.
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.
# 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
# Assign an IP address.
# 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
3) Configure Router C:
# 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.
# 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.

[RouterASerial2/0] ip address 202.38.163.251 255.255.255.0
# Encapsulate the interface with FR.

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

[RouterASerial2/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.

[RouterASerial2/0] fr map ip 202.38.163.252 100
[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.

[RouterBSerial2/0] ip address 202.38.163.252 255.255.255.0
# Encapsulate the interface with FR.

[RouterBSerial2/0] link-protocol fr
[RouterBSerial2/0] fr interface-type dte
1-18
# Create an FR DLCI interface.
[RouterBSerial2/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.

[RouterBSerial2/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

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
PING 10.110.40.2: 56 data bytes, press CTRL_C to break
Reply from 10.110.40.2: bytes=56 Sequence=1 ttl=255 time=13 ms
--- 10.110.40.2 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 12/12/13 ms
# 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/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
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
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
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.
[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ip address 10.1.1.2 255.0.0.0
# Configure Serial 2/0.

# Create PPP mapping on Serial 2/0.

[RouterA-Serial2/0] fr map ppp 16 interface virtual-template 1
[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ip address 10.1.1.1 255.0.0.0
[RouterB-Virtual-Template1] quit

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

[RouterB-Serial2/0] fr dlci 16
3-2
# 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
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
[RouterA-Virtual-Template3] qos max-bandwidth 64
# Map specified DLCI to PPP virtual template on the interface.

[RouterB] interface Virtual-Template 1
[RouterB-Virtual-Template1] ppp mp virtual-template 3

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

[RouterB-Virtual-Template3] ppp mp lfi
[RouterB-Virtual-Template3] qos max-bandwidth 64
# Map specified DLCI to PPP virtual template on the interface.

4-4
Table of Contents
1 GVRP Configuration 1-1

Introduction to GVRP 1-1
GARP1-1
GVRP1-3
Configuring GVRP1-4
Configuring GVRP Functions 1-4
Configuring GARP Timers 1-5
Displaying and Maintaining GVRP1-6
GVRP Configuration Examples1-6
GVRP Configuration Example I1-6
GVRP Configuration Example II1-8
GVRP Configuration Example III1-9
i
1 GVRP Configuration
The GARP VLAN Registration Protocol (GVRP) is a GARP application. It functions based on the
operating mechanism of GARP to maintain and propagate dynamic VLAN registration information for
the GVRP devices on the network.
When configuring GVRP, go to these sections for information you are interested in:
z Introduction to GVRP
z Configuring GVRP
z Displaying and Maintaining GVRP
z GVRP Configuration Examples
Introduction to GVRP
GARP
The Generic Attribute Registration Protocol (GARP) provides a mechanism that allows participants in a
GARP application to distribute, propagate, and register with other participants in a LAN the attributes
specific to the GARP application, such as the VLAN or multicast address attribute.
GARP itself does not exist on a device as an entity. GARP-compliant participants are known as GARP
applications. One example is GVRP. When a GARP participant is present on a port on your device, the
port is regarded as a GARP participant.
GARP messages and timers
1) GARP messages
A GARP participant exchanges information with other GARP participants by sending the following three
types of messages:
z Join messages to register with other entities its attributes, the attributes received from other GARP
application entities, and the attributes manually configured on it.
z Leave messages to have its attributes deregistered on other devices. A GARP participant also
sends Leave messages when it receives Leave messages from other GARP participants or when
attributes are manually deregistered on it.
z LeaveAll messages to deregister all the attributes so that all GARP participants can re-register all
attributes with each other. A LeaveAll message is sent upon expiration of a LeaveAll timer, which
starts upon the startup of a GARP application entity.
1-1
Join messages, Leave messages, and LeaveAll message make sure the reregistration and
deregistration of GARP attributes are performed in an orderly way.
Through message exchange, all attribute information that needs registration propagates to all GARP
participants on the LAN.
2) GARP timers
GARP uses the following four timers to set the interval for sending GARP messages:
z Hold timer When a GARP application entity receives the first registration request, it starts a hold
timer and collects succeeding requests. When the timer expires, the entity sends all these
requests in one Join message. This helps you save bandwidth.
z Join timer A GARP participant sends each Join message at most twice for reliability sake and
uses a join timer to set the sending interval. If the first Join message has not been acknowledged
before the Join timer expires, the GARP participant sends the second Join message.
z Leave timer Starts upon receipt of a Leave message sent for deregistering some attribute
information. If no Join message has been received before this timer expires, the GARP participant
removes the attribute information as requested.
z LeaveAll timer Starts when a GARP participant starts. When this timer expires, the entity sends
a LeaveAll message so that other participants can re-register its attribute information. Then, a
LeaveAll timer starts again.
z The settings of GARP timers apply to all GARP applications, such as GVRP, on a LAN.
z Unlike other three timers, which are set on a port basis, the LeaveAll timer is set in system view
and takes effect globally.
z A GARP participant may send LeaveAll messages at the interval set by its LeaveAll timer or the
LeaveAll timer on another device on the network, whichever is smaller. This is because each time
a device on the network receives a LeaveAll message it resets its LeaveAll timer.
Operating mechanism of GARP
The GARP mechanism allows the configuration of a GARP participant to propagate throughout a LAN
quickly. In GARP, a GARP participant registers or deregisters its attributes with other participants by
making or withdrawing declarations of attributes and at the same time, based on received declarations
or withdrawals, handles attributes of other participants. When a port receives an attribute declaration, it
registers the attribute; when a port receives an attribute withdrawal, it deregisters the attribute.
GARP participants send protocol data units (PDU) with a particular multicast MAC address as
destination. Based on this address, a device can identify to which GVRP application (GVRP for
example) a GARP PDU should be delivered.
GARP message format
The following figure illustrates the GARP message format.
1-2
Figure 1-1 GARP message format
Table 1-1 describes the GARP message fields.
Table 1-1 Description on the GARP message fields
Field Description Value

Protocol ID Protocol identifier for GARP 1
One or multiple messages, each containing
Message
an attribute type and an attribute list
Defined by the concerned GARP 0x01 for GVRP, indicating the
Attribute Type
application VLAN ID attribute
Attribute List Contains one or multiple attributes
Consists of an Attribute Length, an
Attribute
Attribute Event, and an Attribute Value
Number of octets occupied by an attribute,
Attribute Length 2 to 255 (in bytes)
inclusive of the attribute length field
0: LeaveAll event
1: JoinEmpty event
2: JoinIn event
Attribute Event Event described by the attribute
3: LeaveEmpty event
4: LeaveIn event
5: Empty event
VLAN ID for GVRP
Attribute Value Attribute value If the Attribute Event is LeaveAll,
Attribute Value is omitted.
End Mark Indicates the end of a GARP PDU 0x00
GVRP
GVRP enables a device to propagate local VLAN registration information to other participant devices
and dynamically update the VLAN registration information from other devices to its local database
1-3
about active VLAN members and through which port they can be reached. It thus ensures that all
GVRP participants on a bridged LAN maintain the same VLAN registration information. The VLAN
registration information propagated by GVRP includes both manually configured local static entries and
dynamic entries from other devices.
GVRP provides the following three registration types on a port:
z Normal Enables the port to dynamically register and deregister VLANs, and to propagate both
dynamic and static VLAN information.
z Fixed Disables the port to dynamically register and deregister VLANs or propagate information
about dynamic VLANs, but allows the port to propagate information about static VLANs. A trunk
port with fixed registration type thus allows only manually configured VLANs to pass through even
though it is configured to carry all VLANs.
z Forbidden Disables the port to dynamically register and deregister VLANs and to propagate
VLAN information except information about VLAN 1. A trunk port with forbidden registration type
thus allows only VLAN 1 to pass through even though it is configured to carry all VLANs.
GVRP is described in IEEE 802.1Q.
Configuring GVRP
GVRP can only be configured on trunk ports.
Configuring GVRP includes Configuring GVRP Functions and Configuring GARP Timers.
Configuring GVRP Functions
Follow these steps to configure GVRP functions on a trunk port:

Required
Enable GVRP globally gvrp
Globally disabled by default
Enter Ethernet or Required
Enter interface interface-type
Layer 2 aggregate Perform either of the commands.
Ethernet interface-number
interface view
interface view Depending on the view you
or port-group accessed, the subsequent
Enter port-group port-group manual
view configuration takes effect on a
view port-group-name
port or all ports in a port-group.
Required
Enable GVRP on the port gvrp
Disabled by default
gvrp registration Optional

Configure the GVRP registration
{ fixed | forbidden |
mode on the port The default is normal.
normal }
1-4
z GVRP is mutually exclusive with service loopback.
z In an MSTP network, GVRP can run on only the CIST. In addition, blocked ports on the CIST
cannot receive/send GVRP packets.
z If both GVRP and remote port mirroring are used, GVRP may register the remote probe VLAN to
unexpected ports, resulting in undesired duplicates to be received by the monitor port. For more
information about port mirroring, refer to Port Mirroring Configuration in the Access Volume.
z Enabling GVRP on a Layer 2 aggregate interface enables both the aggregate interface and all
selected member ports in the corresponding link aggregation group to participate in dynamic VLAN
registration and deregistration. In addition, the GVRP configuration made on a link aggregation
member port can take effect only after the port is removed from the group. For more information
about link aggregation, refer to Link Aggregation Configuration in the Access Volume.
z On a GVRP-enabled trunk port, you need to configure the port trunk permit vlan all command on
the port to ensure that the traffic of all dynamically registered VLANs can pass through the port.
Configuring GARP Timers
Follow these steps to configure GARP timers:

Configure the GARP LeaveAll garp timer leaveall Optional

timer timer-value The default is 1000 centiseconds.
Enter Enter Ethernet or Required

Ethernet Layer 2 interface interface-type Perform either of the commands.
interface aggregate interface-number
interface view Depending on the view you
view or accessed, the subsequent
port-group Enter port-group port-group manual configuration takes effect on a port
view view port-group-name or all ports in a port-group.
Optional
Configure the hold timer, join garp timer { hold | join | The default is 10 centiseconds for
timer, and leave timer leave } timer-value the hold timer, 20 centiseconds for
the join timer, and 60 centiseconds
for the leave timer.
When configuring GARP timers, note that their values are dependent on each other and must be a
multiple of five centiseconds. If the value range for a timer is not desired, you may change it by tuning
the value of another related timer as shown in the following table:
Table 1-2 Dependencies of GARP timers
Timer Lower limit Upper limit

Hold 10 centiseconds Not greater than half of the join timer setting
Not less than two times the hold timer
Join Less than half of the leave timer setting
setting
1-5
Timer Lower limit Upper limit
Greater than two times the join timer
Leave Less than the LeaveAll timer setting
setting
LeaveAll Greater than the leave timer setting 32765 centiseconds
The GVRP configuration made on a link aggregation member port can take effect only after the port is
removed from the group. For more information about link aggregation, refer to Link Aggregation
Configuration in the Access Volume.
Displaying and Maintaining GVRP

display garp statistics
Display statistics about GARP Available in any view
[ interface interface-list ]
Display GARP timers for display garp timer [ interface
specified or all ports interface-list ]
Display the local VLAN display gvrp local-vlan
information maintained by interface interface-type Available in any view
GVRP interface-number
display gvrp state interface
Display the current GVRP state interface-type interface-number Available in any view
vlan vlan-id
display gvrp statistics
Display statistics about GVRP Available in any view
Display the global GVRP state display gvrp status Available in any view
Display the information about display gvrp vlan-operation
dynamic VLAN operations interface interface-type Available in any view
performed on a port interface-number
reset garp statistics
Clear the GARP statistics Available in user view
GVRP Configuration Examples

GVRP Configuration Example I
Configure GVRP for dynamic VLAN information registration and update among devices, adopting the
normal registration mode on ports.
1-6
Network diagram
Figure 1-2 Network diagram for GVRP configuration
1) Configure Device A
# Enable GVRP globally.
<DeviceA> system-view
[DeviceA] gvrp
# Configure port Ethernet 1/0 as a trunk port, allowing all VLANs to pass through.
[DeviceA] interface ethernet 1/0
[DeviceA-Ethernet1/0] port link-type trunk
[DeviceA-Ethernet1/0] port trunk permit vlan all
# Enable GVRP on Ethernet 1/0, the trunk port.

[DeviceA-Ethernet1/0] gvrp
[DeviceA-Ethernet1/0] quit
# Create VLAN 2 (a static VLAN).

[DeviceA] vlan 2
2) Configure Device B
<DeviceB> system-view
[DeviceB] gvrp
[DeviceB] interface ethernet 1/1
[DeviceB-Ethernet1/1] port link-type trunk
[DeviceB-Ethernet1/1] port trunk permit vlan all
# Enable GVRP on Ethernet 1/1, the trunk port.

[DeviceB-Ethernet1/1] gvrp
[DeviceB-Ethernet1/1] quit

[DeviceB] vlan 3
3) Verify the configuration
# Display dynamic VLAN information on Device A.
[DeviceA] display vlan dynamic
Now, the following dynamic VLAN exist(s):
3
# Display dynamic VLAN information on Device B.

[DeviceB] display vlan dynamic
1-7
2
GVRP Configuration Example II
Configure GVRP for dynamic VLAN information registration and update among devices. Specify fixed
GVRP registration on Device A and normal GVRP registration on Device B.
Network diagram
[DeviceA] gvrp
# Enable GVRP on Ethernet 1/0.

# Set the GVRP registration type to fixed on the port.

[DeviceA-Ethernet1/0] gvrp registration fixed

[DeviceA] vlan 2
[DeviceB] gvrp

1-8
[Sysname] vlan 3
No dynamic vlans exist!

2
GVRP Configuration Example III
To prevent dynamic VLAN information registration and update among devices, set the GVRP
registration mode to forbidden on Device A and normal on Device B.
Network diagram
[DeviceA] gvrp

# Set the GVRP registration type to forbidden on the port.

[DeviceA-Ethernet1/0] gvrp registration forbidden

[DeviceA] vlan 2
[DeviceB] gvrp
1-9


[DeviceB] vlan 3

1-10
Table of Contents
1 HDLC Configuration 1-1

Introduction to HDLC1-1
HDLC Overview1-1
HDLC Frame Format and Frame Type 1-1
Configuring HDLC 1-2
Configuring HDLC Compression1-2
Introduction to HDLC Compression1-2
Configuring HDLC Compression 1-2
Displaying and Maintaining HDLC Compression 1-3
HDLC Configuration Example1-3
i

STAC-LZS
No No No No
compression
STAC
Yes Yes Yes Yes
compression
1 HDLC Configuration
When configuring HDLC, go to these sections for information you are interested in:
z Introduction to HDLC
z Configuring HDLC
z Configuring HDLC Compression
Introduction to HDLC
HDLC Overview
High-level Data Link Control (HDLC) is a bit-oriented link layer protocol. Its most prominent feature is
that it can transmit any type of bit stream transparently.
z HDLC supports point-to-point link only and does not support point-to-multipoint link.
z HDLC supports neither IP address negotiation nor authentication. It uses keepalive messages to
check link status.
z HDLC can only be encapsulated on a synchronous link. A synchronous /asynchronous interface
can also apply HDLC provided that it works in synchronous mode. Currently, this protocol is
applied on the Serial interface and POS interface that work in synchronous mode.
HDLC Frame Format and Frame Type
There are three types of HDLC frames: information frame (I frame), supervision frame (S frame), and
unnumbered frame (U frame).
z Information frame is responsible for transmitting useful data or information.
z Supervision frame is responsible for error control and flow control.
1-1
z Unnumbered frame is responsible for the link establishment, teardown, and so on.
An HDLC frame is composed of flag field, address field, control field, information field, and checksum
field.
z The flag field, 0111110, marks the beginning and end of an HDLC frame. Each frame begins with
an F and ends with an F. The F between two neighboring frames functions both as the end of the
frame in the front and as the beginning of the following frame.
z The address field is eight bits; it identifies the source or destination where the frame is sent or
received.
z The control field is eight bits; it identifies the control type and defines the frame type (control or
data).
z The information field can be an arbitrary binary bit set. The minimum length can be zero and the
maximum length is decided by the FCS field or the buffer size of the communicating node.
Generally, the maximum length is between 1000 and 2000 bits.
z The checksum field can use a 16-bit CRC to check the content of a frame.
Configuring HDLC
Follow these steps to configure the HDLC protocol:

interface-number
Required
Enable HDLC on the interface link-protocol hdlc PPP is encapsulated by
default.
Optional
Set the polling interval timer hold seconds The polling interval is 10
seconds by default.
Configuring HDLC Compression

Introduction to HDLC Compression
The STAC-LZ compression is used to compress the payload of packets on an HDLC link. Since it does
not rely on history packet information, therefore it can achieve a smaller compression ratio. Note that
the STAC-LZ compression is used to increase data transmission efficiency on low-speed links, thus
saving network bandwidth and reducing network load.
Configuring HDLC Compression
Follow these steps to configure HDLC compression:
interface-number
1-2
Required
Enable HDLC on the interface link-protocol hdlc
PPP by default
Required
Enable HDLC compression hdlc compression stac By default, HDLC links do not
support compression.
Displaying and Maintaining HDLC Compression

Display the HDLC display hdlc compression stac [ interface
compression statistics interface-type interface-number ]
Clear the HDLC reset hdlc compression stac [ interface
compression statistics interface-type interface-number ]
HDLC Configuration Example

z Router A and Router B are connected through their POS ports with HDLC enabled.
z POS 0/0 of Router A borrows the IP address of the local loopback interface. The IP address of the
loopback interface is with a 32-bit mask.
z Router A learns the routing information of Router B through static routes. Router A can reach the
network segment 12.1.2.0/24.
Network diagram
Figure 1-1 Network diagram for HDLC IP address borrowing configuration
[RouterA] interface loopback 1
[RouterA-LoopBack1] ip address 12.1.1.2 32
[RouterA-LoopBack1] quit
[RouterA-Pos0/0] link-protocol hdlc
[RouterA-Pos0/0] ip address unnumbered interface loopback 1
1-3
[RouterB-Pos0/0] link-protocol hdlc
[RouterB-Pos0/0] ip address 12.1.1.2 24
3) Configure a static route on Router A:
[RouterA] ip route-static 12.1.1.0 24 Pos 0/0
[RouterA] ip route-static 12.1.2.0 24 12.1.1.1
# Execute the display ip routing-table command on Router A to view the routing table.
[RouterA] display ip routing-table
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
12.1.1.0/24 Static 60 0 12.1.1.2 POS0/0

12.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
12.1.2.0/24 Static 60 0 12.1.1.1 POS0/0
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
1-4
Table of Contents
1 X.25 and LAPB Configuration 1-1

Introduction to X.25 and LAPB Protocols1-1
Overview1-1
X.25 Fundamental 1-2
LAPB Overview 1-3
X.25 Switching1-3
Configuring LAPB1-4
Configuring X.25 1-4
Configuring an X.25 Interface1-4
Configuring X.25 Interface Supplementary Parameters1-8
Configuring X.25 Datagram Transmission 1-10
Configuring Additional Parameters for X.25 Datagram Transmission 1-12
Configuring an X.25 Subinterface 1-17
Configuring X.25 Switching 1-17
Configuring X.25 Load Sharing 1-18
Configuring X.25 Closed User Group1-21
X.25 PAD Remote Access Service 1-23
Introduction to X.25 PAD 1-23
Configuring X.25 PAD 1-24
Configuring X.25 over TCP (XOT) 1-24
Introduction to XOT Protocol 1-24
Configuring X.25 over FR 1-27
Introduction to X.25 over FR 1-27
Configuring SVC Application of X.25 over FR1-28
Configuring PVC Application of X.25 over FR1-29
Configuring X2T 1-29
Introduction1-29
Displaying and Maintaining LAPB and X.25 1-31
LAPB Configuration Example 1-32
X.25 Configuration Examples 1-33
Direct Connection of Two Routers Connecting through Serial Interfaces (One Address Mapping)
1-33
Direct Connection of Two routers Connecting through Serial Interfaces (Two Address Mappings)
1-34
Connecting the Router to X.25 Public Packet Network1-36
Configuring VC Range1-37
Transmitting IP Datagrams through X.25 PVCs1-38
X.25 Subinterface Configuration Example 1-40
SVC Application of XOT 1-41
PVC Application of XOT 1-43
SVC Application of X.25 over FR 1-44
i
PVC Application of X.25 over FR 1-46
X.25 Load Sharing Application 1-48
Implementing X.25 Load Sharing Function for IP Datagram Transmission 1-50
TCP/IP Header Compression Protocol Application1-52
X.25 PAD Configuration Example 1-53
X2T Configuration Examples 1-55
X2T SVC Configuration Example 1-55
X2T PVC Configuration Example 1-56
Troubleshooting LAPB Configuration1-56
LAPB (or X.25) of Two Sides Always Being Down 1-56
Failed to Ping the Other Side with X.25 on Both Sides Being Up1-57
Troubleshooting X.25 Configuration 1-57
X.25 of Two Sides Always Being Down with LAPB of two sides Being Up1-57
Failed to Ping the Other Side with X.25 on Both Sides Being Up1-57
Continuous Resets and Clears of the VC Established1-58
PVC Setup Request Rejected 1-58
Troubleshooting X.25 PAD1-58
Failed to Ping through the XOT SVC Configured1-58
Failed to Ping through the XOT PVC Configured1-59
ii
1 X.25 and LAPB Configuration
When configuring LAPB and X.25, go to these sections for information you are interested in:
z Introduction to X.25 and LAPB Protocols
z Configuring LAPB
z Configuring X.25
z X.25 PAD Remote Access Service
z Configuring X.25 over TCP (XOT)
z Configuring X.25 over FR
z Configuring X2T
z Displaying and Maintaining LAPB and X.25
z LAPB Configuration Example
z X.25 Configuration Examples
z X2T Configuration Examples
z Troubleshooting LAPB Configuration
z Troubleshooting X.25 Configuration
Introduction to X.25 and LAPB Protocols

Overview
The X.25 protocol specifies the interface standards between data terminal equipment (DTE) and data
circuit-terminating equipment (DCE). In 1974, CCITT issued the first draft of X.25, which was written
based on the experience and recommendations from Telnet and Tymnet in USA and Datapac
packet-switched networks in Canada. It then underwent several revisions and was enriched by many
optional service functions and facilities.
X.25 allows two DTEs to communicate with each other over a telephone network. The following is how
a communication goes on:
One DTE contacts the other to setup a connection. The other DTE can either accept or refuse the
connection as required. Once the connection is established, the devices at both ends can transmit
information in full duplex mode, and either end can disconnect the connection at any time.
X.25 is the protocol for point-to-point interaction between DTE and DCE. DTE usually refers to the host
or terminal at the user side, and DCE usually refers to a device like the synchronous modem. DTE is
connected with DCE directly, DCE is connected to a port of packet switching exchange (PSE), and
1-1
some connections are established between the packet switching exchanges, thus forming the paths
between different DTEs. In an X.25 network, the relation of entities is shown in the following diagram.
Figure 1-1 X.25 network model
DTE Data terminal equipment

DCE Data circuit-terminating equipment
PSE Packet switching equipment
PSN Packet switching network
X.25 Fundamental
Virtual circuit
Virtual circuits (VC) are logical links established by X.25 between DTEs. They are different from
physical links in circuit switching networks.
VCs fall into two categories: Permanent Virtual Circuit (PVC) and Switched Virtual Circuit (SVC). PVC
is suitable for constant and stable data transmission, while SVC is suitable for sporadic and bursty data
transmission.
VCs are uniquely identified by VC ID. Each packet sent by a DTE carries a VC ID with it, which enables
the packet to be forwarded properly between the DCEs in the switched network and finally reach the
destination.
X25 transmission model
As shown in Figure 1-2, X.25 transmission model contains three layers, corresponding to the lowest
three layers of the OSI (Open System Interconnection) reference model.
Figure 1-2 DTE/DCE interfaces
OSI reference model X.25
7
6
5
4
Packet layer
3 X.25 packet layer X.25 packet layer
interface
Data link
2 X.25 data link layer X.25 data link layer
interface
Physical layer
1 X.25 physical layer X.25 physical layer
interface
DTE DCE
z X.25 physical layer defines the physical/electric specifications between DTE and DCE.
1-2
z X.25 data link layer defines the format and specifications of the frames exchanged between DTE
and DCE, that is, LAPB (Link Access Procedure, Balanced).
z X.25 packet layer defines the packet format and rules for Layer 3 packet switching.
A Layer 2 link established between a DTE and DCE can multiplex X.25 Layer 3 entities to form
multiple virtual circuits.
Figure 1-3 shows the data forms in different X.25 layers.
Figure 1-3 X.25 packet and LAPB frame
LAPB Overview
X.25 data link layer protocol
X.25 link layer specifies the frame switching process between DTE and DCE. From the perspective of
layering, the link layer is just like a bridge interconnecting the packet layer interface of DTE and that of
DCE. Through this bridge, packets can be transmitted continuously between the packet layer of DTE
and that of DCE. The link layer has the following main functions:
z Transmit the data effectively between DTE and DCE
z Ensure the synchronization of information between the receiver and sender
z Detect and correct errors in the transmission
z Identify and report the procedure errors to the higher layer protocols
z Inform the packet layer of the link layer state
Implementation
As specified in international standards, LAPB is used as the data link layer protocol of X.25. It adopts
the frame structure of High-level Data Link Control (HDLC) and is a subset of HDLC. It requires for
setting up a link by making use of the Set Asynchronous Balanced Mode (SABM) command. A two-way
link can be established after either site sends an SABM command and the other replies with a UA
response.
Although defined for X.25, as an independent link layer protocol, LAPB can directly carry non-X.25
upper layer protocols. Therefore, you can set the link layer protocol of a serial interface as LAPB for
local data transmission.
X.25 Switching
You can use a device that supports X.25 switching as a small-sized X.25 packet switch to protect the
investment in X.25. The following figure describes the relation between LAPB, X.25 and X.25 switching.
1-3
Figure 1-4 Relation between LAPB, X.25 and X.25 switching
Normally, in an X.25 network, a device can be a DTE or a DCE. But in terms of X.25 switching, a device
operates as a PSE.
Configuring LAPB
Follow these steps to configure LAPB:

interface-number
Required
Configure link layer link-protocol lapb [ dce | By default, the link layer protocol is PPP.
protocol as LAPB dte ] [ ip | multi-protocol ] When LAPB is configured, the interface
works as DTE with upper layer as IP.
Optional
Configure the modulo lapb modulo { 8 | 128 }
Defaults to 8
Configure LAPB Optional

lapb window-size k-value
window parameter K Defaults to 7
Optional
Configure LAPB
lapb max-frame n1-value The default N1 is calculated according to
parameter N1
the MTU, upper layer and modulus value.
Configure LAPB Optional

lapb retry n2-value
parameter N2 Defaults to 10
Optional
Configure the system By default:
lapb timer { t1 t1-value | t2
timers T1, T2 and T3 in z T1 is 3000 milliseconds
t2-value | t3 t3-value }
LAPB
z T2 is 1500 milliseconds
z T3 is 0 second
Configuring X.25
Configuring an X.25 Interface
X.121 address
If the device is used for X.25 switching, this task can be skipped. If it is connected to X.25 public packet
network, you must set an X.121 address for the connected X.25 interface according to the
requirements of the ISP. As defined in ITU-T recommendation X.121, an X.121 address is a string of 1
to 15 numbers.
1-4
X.25 operating mode
Layer 3 of X.25 supported by your device can work in either DTE mode or DCE mode. The format of
the datagram is alternative, either IETF or nonstandard.
Note that an X.25 public packet switching network requires the device to access the network as DTE
and to be encapsulated with the IETF format generally. Therefore, the operating mode of X.25 should
be DTE and the encapsulation format should be IETF. When two routers are connected back to back
through serial interfaces, ensure that they are using the same encapsulation format and are
respectively working as the DTE and DCE.
X.25 virtual circuit range
The X.25 protocol can create multiple logical virtual connections over a physical link between DTE and
DCE. These virtual connections are called Virtual Circuits (VCs) or Logic-Channels (LCs). Up to 4095
virtual circuits can be established by X.25, and their numbers range from 1 to 4095. The number used
to differentiate each virtual circuit (or logic channel) is called Logic Channel Identifier (LCI) or Virtual
Circuit Number (VCN).
Strictly speaking, VC and LC are different. However, at the user end, they are generally not
distinguished strictly.
An important part of X.25 operation is how to manage the total 4,095 virtual circuits. All the virtual circuit
numbers are divided into four ranges (listed here in ascending order):
z A-Permanent virtual circuits (PVCs) range
z B-Incoming-only channel range
z C-Two-way channel range
z D-Outgoing-only channel range
The numbers of the virtual circuits established by an X.25 call must be set in the ranges of B, C and D.
The permanent virtual circuits must be set in the A range.
According to ITU-T Recommendation X.25, the idle channel allocation rules in initiating calls are as
follows:
z Only the DCE can initiate a call using a channel in the incoming-only channel range.
z Only the DTE can initiate a call using a channel in the outgoing-only channel range.
z Both the DCE and the DTE can initiate a call using a channel in the two-way channel range.
z DCE always uses the lowest available logic channel.
z DTE always uses the highest available logic channel.
Thus, we can avoid the case that one side of the communication occupies all the channels, and
minimize the possibility of call collision.
In X.25 protocol, six parameters are employed to define the four ranges, as shown in the following
figure.
1-5
Figure 1-5 X.25 channel delimitation
1
PVC range
LIC
Incoming-only
channel range
HIC
unused
LTC
Two-way
channel range
HTC
Unused
LOC
Outgoing-only
channel range
HOC
Unused
4095
For the meanings of these six parameters, refer to the following table.
Table 1-1 Description of X.25 channel range delimitation parameters
Parameter Description
LIC Lowest Incoming-only Channel
HIC Highest Incoming-only Channel
LTC Lowest Two-way Channel
HTC Highest Two-way Channel
LOC Lowest Outgoing-only Channel
HOC Highest Outgoing-only Channel
Each range (except PVC range) is defined by two parameters respectively working as the upper limit
and lower limit. The parameters are in the range of 1 to 4095 (including 1 and 4095), but they are
regarded correct only if they satisfy the following conditions:
z In strict ascending order, i.e. 1 lic hic< ltc htc < loc hoc 4095.
z If the upper limit (or lower limit) of a range is 0, then the lower limit (or upper limit) shall also be 0,
(which indicates this range is disabled from use).
Finally, the following should be noted:
z At the two sides (i.e. DTE and DCE) of a physical connection, these six parameters of X.25 must
be equal in a symmetric way, as different settings at the two sides are very likely to result in an
improper procedure and hence result in transmission failures.
z Take the default of each parameter into consideration.
z The new configuration cannot take effect immediately on a connection in use unless you reset the
interface using the commands shutdown and undo shutdown.
X.25 packet numbering modulo
The implementation of X.25 supports both modulo 8 and modulo 128 in packet numbering, with modulo
8 being the default.
The X.25 protocol requires DTE and DCE have the same packet sequence numbering mode. The new
configuration is not effective unless you reset the interface using the shutdown command and undo
shutdown command.
1-6
Besides, the packet sequence numbering mode of X.25 layer 3 is different from the frame sequence
numbering mode of LAPB (X.25 layer 2). When modulo 128 numbering mode is employed in the
DTE/DCE interface with high throughput rate, for LAPB, only the efficiency of local DTE/DCE interface
is affected, that is, point-to-point efficiency increases. While for X.25 layer 3, the efficiency of
end-to-end is affected, that is, the efficiency between the two DTE increases.
Traffic control parameters
X.25 protocol is a reliable transport protocol with powerful traffic control capability due to the window
size and maximum packet size. However, it cannot perform traffic control effectively and correctly
unless correctly configured. Any inappropriate configuration will cause CLEAR and RESET events of
X.25. As most public X.25 packet networks use the default window size and maximum packet size
specified in ITU-T X.25 Recommendation, the device also adopts the same default values. Therefore,
you need not set the two parameters unless requested by the access service providers.
After the default window size and the default maximum packet size are set, the SVC, which can be
established only via calling, will use these default values if related parameters are not negotiated in the
call process. (Parameter negotiation will be described in the later sections). The PVC, which can be
established directly without calling, will also use these default values if no window size or packet size
option is appended when it is specified. (Refer to the later sections for PVC configuration).
An X.25 sender will fragment the oversize data packets at the upper layer based on the maximum
packet size, and mark the final fragment packet (M bit not set). After the packets reach the receiver,
X.25 will reassemble the fragment packets, and determine whether a piece of complete upper layer
packet is received based on the M bit flag. Therefore, too small value of the maximum packet size will
consume too much router resources on message fragmenting and reassembling, thus lowering
efficiency.
Note that:
z The maximum packet size < 8*MTU < N1 of LAPB
z Reset interface using the shutdown and undo shutdown commands to make new configuration
take effect
Follow these steps to configure an X.25 interface:

interface-number
Required
Configure the link
link-protocol x25 [ dce |dte ] The default link layer protocol is PPP by
layer protocol as
[ ietf | nonstandard ] default. With X.25 enabled, the default
X.25
operation mode is DTE IETF.
Optional
Set an X.121 If the device is used for the purpose of X.25
x25 x121-address switching, this task can be skipped. If it is
address for the
x.121-address connected to X.25 public packet network,
interface
you must set an X.121 address for the
connected X.25 interface.
1-7
x25 vc-range { bi-channel ltc Optional

htc [ out-channel loc hoc ] | By default, lower and upper limits of
Set X.25 VC range in-channel lic hic [ bi-channel two-way channel are 1 and 1024
ltc htc ] [ out-channel loc hoc ] respectively, of incoming-only channel are
| out-channel loc hoc } both 0, of outgoing-only channel are both 0.
Optional
Set the modulo x25 modulo { 8 | 128 }
Defaults to 8
Set the sizes of VC x25 window-size Optional

input window and input-window-size By default, input-window-size is 2 and
output window output-window-size output-window-size is 2.
Set the maximum Optional
sizes for input and x25 packet-size input-packet
output packets on output-packet By default, input-packet is 128 bytes and
the interface output-packet is 128 bytes.
Configuring X.25 Interface Supplementary Parameters
It is necessary to configure certain supplementary X.25 parameters in some special network

environments. The section is related to these supplementary parameters.
X.25 layer 3 delay timer
X.25 protocol defines a series of timers to facilitate its procedure. After X.25 sends a control message,
if it does not receive the response before the timeout of the corresponding timer, X.25 protocol will take
corresponding measures to handle this abnormal event. The names and corresponding procedures of
these timers are shown in the following table.
Table 1-2 X.25 Layer 3 timer
Timer name
Procedure name
DTE side DCE side
Restart T20 T10
Call T21 T11
Reset T22 T12
Clear T23 T13
Register T28
T28 is Registration request sending" timer that is only defined on DTE for dynamically requesting the
network for optional services or stopping these services. Its default value is 300 seconds, which cannot
be changed.
Attributes related to X.25 address
To establish an SVC with a call, X.25 address is needed, which adopts the address format specified in
ITU-T Recommendation X.121. An X.121 address is a string of 0 to 15 digits. Some attributes related to
X.121 address are as follows:
1) Alias of interface
1-8
When an X.25 call is forwarded across multiple networks, different networks will likely make some
modifications on the called address as needed, such as adding or deleting the prefix. In such cases, the
destination address of a call that reaches X.25 interface may be inconsistent with X.121 address of the
destination interface (because the destination address of this call is modified within the network); still
the interface should accept this call. For this purpose, one or more alias names must be specified for
this interface.
To meet the requirements of different networks, X.25 defines nine match types and their relevant alias
string formats, as shown in the following table.
Table 1-3 Alias match modes and meanings
Matching mode Description Example

Free matching, the alias string is in 1234 will match 561234, 1234567 and
free
the form of 1234 956123478, but will not match 12354.
Extended free matching, in which 1234 .. will match 678123459, but will
free-ext the alias string is in the form not match 68123459, 67812345 and
of 1234.. 6781234591.
Left-most matching mode, in which $1234 will match 1234567 and
left the alias string is in the form of 12346790, but will not match 3123478
$1234 and 123784.
Extended left-most matching $1234 will match 1234679 and
left-ext mode, in which the alias string is in 1234872, but will not match 123468 and
the form of $1234 12346890.
Rightmost matching mode, in
1234$ will match 791234 and 6901234,
right which the alias string is in the form
but will not match 7912345 and 6212534.
of 1234$
Extended rightmost matching .1234$ will match 79001234 and
right-ext mode, the alias string is in the form 86901234, but will not match 7912345
of .1234$ and 506212534.
Strict matching mode, in which the
strict $1234$ can only match 1234.
alias string is in the form of $1234$
Whole matching mode, in which the .. will match all the valid X.121
whole
alias string is in the form of ........ addresses of 8 digits in length.
Extended whole matching mode, in "* will match all the valid X.121
whole-ext
which the alias string can only be * addresses.
2) Attributes related to the address code block in calling or called packets

As defined in the X.25 protocol, a call packet must carry the information set of both the calling DTE
address (source address) and the called DTE address (destination address). This address information
set is called the address code block. While in call accept packet, some networks require that both (the
calling DTE address and the called DTE address) be carried, some networks require that only one of
the two be carried, while some others require that neither should be carried. To adapt the difference
between various networks, you can select as required.
3) Default upper layer protocol that X.25 bears
An X.25 call request packet includes a CUD (Call User Data) field that indicates the upper layer
protocol type carried over X.25 protocol. When receiving an X.25 call, the device will check the CUD
field in the packet. If receiving a call carrying an unidentifiable CUD field, the router will deny it. However,
1-9
an upper layer protocol can be specified as the default protocol on the X.25. When X.25 receives a call
with an unrecognizable CUD, it will treat it as the customized default upper layer protocol.
Follow these steps to configure X.25 interface supplementary parameters:

interface
Enter interface view interface-type
interface-number
Optional
x25 timer tx0 By default, the value for DTE
Set the restart timer delay value
seconds is 180 seconds, and the
value for DCE is 60 seconds.
Optional
Set the call request timer for DTE or the call x25 timer tx1 By default, the value for DTE
indication timer for DCE seconds is 200 seconds, and the
value for DCE is 180
seconds.
Optional
Set the reset request timer for DTE or the x25 timer tx2 By default, the value for DTE
reset indication timer for DCE seconds is 180 seconds, and the
Optional
Set the clearing request timer for DCE or the x25 timer tx3 By default, the value for DTE
clearing request timer for DTE seconds is 180 seconds, and the
x25 alias-policy Optional

Specify an alias for the
match-type
interface Not specified by default
alias-string
Carry no X.121 address of Optional
x25 ignore
the called DTE in each call
called-address Carried by default
packet
Carry no X.121 address of Optional
x25 ignore
Configuring the calling DTE in each call
calling-address Carried by default
the attributes packet
related to
X.25 address Carry the address of the Optional
x25 response
called DTE in each
called-address Not carried by default
call-acceptance packet
Carry the address of the Optional
x25 response
calling DTE in each
calling-address Not carried by default
call-acceptance packet
Specify the default upper x25 default-protocol Optional

layer protocol protocol-type Not specified by default
Configuring X.25 Datagram Transmission
In the most frequently used X.25 service, data is transmitted between two hosts using the X.25 protocol
through X.25 packet switching network. As shown in the following figure, LAN 1 and LAN 2 are far apart,
1-10
and the large and distributed X.25 packet switching network can be used to realize information
exchange between them.
Figure 1-6 Interconnecting LANs via X.25
LAN 1 and LAN 2 communicate with each other by sending the datagrams carrying Internet Protocol
(IP) addresses. However, X.25 uses the X.121 address. Therefore, to solve the problem, the mapping
between IP address and X.121 address needs to be established. In other words, to enable X.25 to
transmit data remotely, correctly establishing the address mapping is very significant. This section will
deal with how to establish address mapping.
Create protocol to X.121 address mapping
An X.25 interface has its own X.121 address and internetworking protocol (such as IP protocol)
address. When X.25 initiates a call through this interface, the source address (calling DTE address) in
the call request packet is the X.121 address of this interface.
Then, how can the router target the destination of the call? In other words, how can the router
determine the X.121 address for the IP address destination? For this purpose, the router will look up the
protocol-address-to-X.121 address mappings that have been configured on the router. A direct call
destination has its own protocol address and X.121 address. In this case, a destination
protocol-address-to-X.121 address mapping must be created on the source. Through the mapping,
X.25 can find the destination X.121 address according to the destination protocol address to initiate a
call successfully. This is why the address mapping shall be established for X.25.
Such a mapping should be created for every destination.
Creating PVC
A PVC can be created for the data transmission featuring large but stable traffic size and requiring the
service quality of leased line. A PVC does not need any call process and will always exist once set up.
Before creating a PVC, it is unnecessary to create an address mapping, because an address mapping
is created implicitly when a PVC is created.
Follow these steps to configure X.25 datagram transmission:

interface-number
1-11
Create a mapping of the x25 map protocol-type Required
destination protocol protocol-address x121-address
address to X.121 address x.121-address [ option ] Not created by default
x25 vc-range { bi-channel ltc htc

[ out-channel loc hoc ] | in-channel
Specify the VC range lic hic [ bi-channel ltc htc ] Required for PVC creation
[ out-channel loc hoc ] | out-channel
loc hoc }
x25 pvc pvc-number protocol-type Required
Create a PVC protocol-address x121-address
x.121-address [ option ] Not created by default
z Since the default two-way channel range: LTC=1, HTC=1024 does not support PVC configuration,
you need to specify a VC range using the x25 vc-range command to create a PVC.
z If a PVC has no related parameters configured, its traffic control parameters are the same as that
of its X.25 interface that is set by the x25 packet-size and x25 window-size commands.
Configuring Additional Parameters for X.25 Datagram Transmission
X.25 allows the addition of some characteristics, including a series of optional user facilities provisioned
in ITU-T Recommendation X.25, for the sake of improving performance and broadening application
ranges.
This section describes how to configure such additional features, including the options in the
commands x25 map and x25 pvc. Select and configure these additional features according to X.25
network structure, and the services provided by service provider.
Complete the following tasks to configure additional parameters for X.25 datagram transmission:
Task Remarks
Enter system view
Set the maximum SVC idle interval Optional
Set the maximum number of SVCs that can be associated to the same
Optional
address mapping
Configure packet pre-acknowledgement Optional
Configure X.25 user facility Optional
Set the queue length for all the VCs on an interface Optional
Enable the sending of broadcast packets through X.25 Optional
Restrict the use of address mapping Optional
1-12
Set the maximum SVC idle interval
For the sake of cost saving, you can specify an SVC idle time upon the expiration of which the SVC will
be disconnected. Enabling this feature will not affect the data transmission, as a new SVC can be set
up again if there are new packets waiting for transmission.
Follow these steps to set the maximum SVC idle interval:

interface-number
Optional
Set the maximum idle interval
x25 timer idle minutes Defaults to 0 minute, no SVC
for all the SVCs on the interface
cleared automatically in this case.
x25 map protocol-type Optional

Set the maximum idle interval protocol-address No mapping created by default, if
for an SVC associated with an x121-address created, the value defaults to 0
address mapping x.121-address idle-timer minute, no SVC cleared
minutes automatically in this case.
Set the maximum number of SVCs that can be associated to the same address mapping
You can specify the maximum number of SVCs allowed to set up for the same address mapping. Be
default, an X.25 address mapping can only be associated with one VC. In case of busy traffic and slow
line speed, you can increase this number properly to reduce data loss. Up to eight SVCs can be
associated with an X.25 address mapping.
Follow these steps to set the maximum number of SVCs that can be associated to the same address
mapping:

interface-number
Set the maximum number of SVCs that
can be associated for all the address x25 vc-per-map count
mappings on the X.25 interface Optional
The count defaults
Set the maximum number of SVCs that x25 map protocol-type to 1.
can be associated to an address protocol-address x121-address
mapping x.121-address vc-per-map count
Configure packet pre-acknowledgement
According to X.25 protocol, only after the input-window becomes full (i.e., the number of received
packets is equal to the value of window-size input-window-size) will the receiving end send an
acknowledgement. However, in some X.25 networks, the delays may be long, resulting in low efficiency
of sending and receiving. X.25 allows you to specify an input-window size. Each time the number of
received packets reaches the value, the router will send an acknowledgment to the peer, thus to
improve the receiving and sending efficiency. The value is called receive-threshold, which ranges
from 0 to input-window-size. If it is set to 1, every packet will be acknowledged. If it is set to
1-13
input-window-size, the acknowledgment will be sent only after the receiving window is full. In
applications requiring a high response speed, this function is especially important.
Follow these steps to configure packet pre-acknowledgement:

interface-number
Optional
Set the packet
x25 receive-threshold count Defaults to 0, no pre-ack
acknowledgment value
available in this case
For information about input window size, refer to Traffic control parameters.
Configure X.25 user facility
X.25 stipulates various user facilities and you can select and configure them. These configurations can
be modified in two ways:
z X.25 interface-based configuration (by using the x25 call-facility command)
z address-mapping-based configuration (by using the x25 map command)
The configuration based on X.25 interface will be effective in every call originating from this X.25
interface, while the configuration based on address mapping will be effective only in the calls originating
from this address mapping.
1) X.25 interface based configuration
Follow these steps to configure X.25 user facility on X.25 interface basis:

Define ROA (Recognized x25 roa-list roa-name Optional

operating Agency) list roa-id&<1-10> Not defined by default
interface-number
Specify CUG (Closed User x25 call-facility Optional

Group) number closed-user-group number Not specified by default
Perform max packet x25 call-facility packet-size Optional

negotiation while initiating a call input-packet output-packet Not configured by default
x25 call-facility window-size Optional

Perform window size
input-window-size
negotiation while initiating a call Not configured by default
output-window-size
Request reverse charging x25 call-facility Optional

when initiating a call reverse-charge-request Not configured by default
Receive calls with reverse Optional

x25 reverse-charge-accept
charging requests Not configured by default
Request throughput-level x25 call-facility threshold in Optional

negotiation while initiating a call out Not configured by default
1-14
Carry transmission delay x25 call-facility send-delay Optional

request while initiating a call milliseconds Not configured by default
Specify ROA (Recognized Optional

x25 call-facility roa-list name
operating Agency) Not configured by default
Follow these steps to configure X.25 user facility on address mapping basis:

Optional
Define ROA (Recognized
x25 roa-list roa-name roa-id&<1-10> Not defined by
operating Agency) list
default
Enter interface view interface interface-type interface-number
x25 map protocol-type protocol-address Optional

Specify CUG (Closed User
x121-address x.121-address Not specified by
Group) number
closed-user-group number default
Perform max packet x25 map protocol-type protocol-address Optional

negotiation while initiating a x121-address x.121-address packet-size Not configured by
call input-packet output-packet default
Perform window size x25 map protocol-type protocol-address Optional

negotiation while initiating a x121-address x.121-address window-size Not configured by
call input-window-size output-window-size default

Request reverse charging
x121-address x.121-address Not configured by
when initiating a call
reverse-charge-request default

Receive calls with reverse
x121-address x.121-address Not configured by
charging requests
reverse-charge-accept default
Request throughput-level x25 map protocol-type protocol-address Optional

negotiation while initiating a x121-address x.121-address threshold in Not configured by
call out default

Carry transmission delay
x121-address x.121-address send-delay Not configured by
request while initiating a call
milliseconds default
Optional
Specify ROA (Recognized x25 map protocol-type protocol-address
operating Agency) x121-address x.121-address roa-list name Not configured by
default
For CUG configuration, refer to Configuring X.25 Closed User Group.
Set the queue length for all the VCs on an interface
You can specify the sending and receiving queue lengths of VC for X.25 to adapt to different network
environments. The default queue length can contain 200 packets, but you can increase the number for
the sake of preventing accidental packet loss in case of large traffic size or low X.25 network
transmission rate.
1-15
Follow these steps to set the queue length for all the VCs on an interface:

interface-number
Set the queue length of X.25 Optional

x25 queue-length queue-size
VC Defaults to 200
Enable the sending of broadcast packets through X.25
Generally, internetworking protocols will need to send some broadcast datagrams for specific purposes.
On the broadcasting physical networks (such as Ethernet), such requirements are naturally supported.
However, for non-broadcasting networks like X.25, how can realize the broadcasting?
You can determine whether to copy and send a broadcast to a destination. This is very important. For
instance, you must enable X.25 to send broadcast datagrams so that broadcast-based application
layer routing protocols can exchange route information on an X.25 network.
You can enable a VC to send broadcasting datagrams, regardless whether it is an SVC or PVC.
Follow these steps to enable the sending of broadcast packets through X.25:

Enable to send broadcasting packets
x25 map protocol-type protocol-address
to the peer of the SVC associated
x121-address x.121-address broadcast
with this address mapping
Required
x25 pvc pvc-number protocol-type
Enable to send broadcasting packets
protocol-address x121-address
to the peer of this PVC
x.121-address broadcast
Restrict the use of address mapping
Before a destination is called, this destination must be found in the address mapping table. Before a call
is received, the source of this call must also be found in the address mapping table. However, in some
cases, some address mappings are used for outgoing calls only, while others are used for incoming
calls only.
Follow these steps to restrict the use of an address mapping:


Disable initiating calls using an x25 map protocol-type protocol-address
Required
address mapping x121-address x.121-address no-callout
Disable accepting calls using x25 map protocol-type protocol-address
Required
an address map x121-address x.121-address no-callin
1-16
Configuring an X.25 Subinterface
X.25 subinterface is virtual interface that has its protocol address and VC. On a physical interface, you
can create multiple subinterfaces to implement the interconnections of multiple networks through a
physical interface. All subinterfaces under master interface share an X.121 address with the master
interface. X.25 subinterfaces fit into point-to-point subinterfaces and point-to-multipoint subinterfaces.
Point-point subinterface is used to connect a single remote end, while point-to-multipoint subinterface
is used to connect multiple ones, which must be on the same network segment.
Follow these steps to configure an X.25 subinterface:

Enter interface view interface serial interface-number
Configure X.25 protocol link-protocol x25 Required
interface serial interface-number.subnumber Required

Create an X.25 subinterface
[ p2mp | p2p ] P2MP by default
When the link layer protocol of an interface is LAPB, HDLC, or PPP, no subinterface can be created on
it.
Configuring X.25 Switching
X.25 switching function
A packet network consists of many interconnecting nodes based on a specific topology. A packet is sent
from source to destination via a large number of nodes, of which each node needs to have packet
switching capability.
Simply speaking, X.25 packet switching means that, after receiving a packet from an X.25 port or
Annex G DLCI, a switch will select a certain X.25 port or Annex G DLCI to send the packet according to
the related destination information contained in the packet. Introducing X.25 switching enables the
system to implement packet switching function at packet layer. The device can act as a packet switch.
Figure 1-7 Network diagram for X.25 switching
Follow these steps to configure X.25 switching:
1-17
Required
Enable X.25 switching x25 switching
Disabled by default

[ out-channel loc hoc ] | in-channel lic hic
[ bi-channel ltc htc ] [ out-channel loc hoc ] |
Add a PVC Required
out-channel loc hoc }
Add
switching x25 switch pvc pvc-number1 interface
route interface-type interface-number [ dlci
dlci-number ] pvc pvc-number2 [ option ]
x25 switch svc [ -number ] x.121-address

[ sub-dest destination-address | sub-source
Add an SVC Required
source-address ] * interface interface-type
interface-number [ dlci dlci-number ]
Enabling/Disabling X.25 switching only affects call establishment, and does not affect the established
links.
The switching routes can be configured after x.25 switching is enabled. If you disable the switching
(using undo x25 switching command) after configuring some switching routes, then
z All static SVC routes will be invisible in the related display command, while PVC routes will be
visible in related display command.
z If you execute the x25 switching command again without restart, SVC routes will be restored and
visible upon using the display command.
z At this time, if you execute the save command and restart, all SVC and PVC routes will be lost.
Since the default two-way channel range: LTC=1, HTC=1024 does not support PVC configuration, you
need to specify a VC range using the x25 vc-range command to create a PVC.
Configuring X.25 Load Sharing
Overview of X.25 load sharing
Using the hunt group feature in X.25 protocol, network providers can provide the load sharing function
on X.25 packet switching network. X.25 load sharing can implement the load sharing between different
DTEs or between different links in the same DTE, to ensure that link overload will not occur when a
large number of users access the same address.
X.25 load sharing is provided by DCE. To implement load sharing on X.25 network, you need to
configure a set of DTE/DCE interfaces (synchronous serial interface or XOT channel) as a hunt group
on the remote DCE, and to assign an X.121 address to this hunt group. When accessing the DTE in
hunt group, other devices in the network need to call the hunt group address. After receiving call
request packet, the remote DCE will select a line from hunt group and send incoming call packet based
1-18
on different channel selection policies (round-robin or vc-number). Different calls will be distributed on
various lines in hunt group to implement load sharing.
Note that X.25 hunt group selects different transmission lines only during VC call establishment. Once
the whole VC completes the establishment and enters data transfer phase, X.25 hunt group will not
function any longer and data transfer will be processed based on the normal VC. Since PVC is in data
transfer phase after establishment and experiences no call establishment and call clearing processes,
X.25 load sharing can function only on SVC, and not on PVC.
In an X.25 hunt group, the position of all DTEs is identical, and they have the same X.121 address.
DTEs inside hunt group can call other DTEs outside hunt group according to the normal mode. When
accessing hunt group, the devices outside hunt group can not know which device they are accessing,
and the line selection is controlled by the DCE configured with hunt group.
The DTE address in hunt group can either be the same as the hunt group address, or different from that.
X.25 hunt group supports the substitution between the source address and the destination address.
You can use the destination address substitution function to hide the DTE address inside hunt group,
and the DTE outside hunt group only knows the hunt group address, to strengthen the network security
inside hunt group. You can use the source address substitution function to hide the DTE address
outside hunt group, because the DTE inside hunt group cannot know the source address of a call
connection but the substituted address, thus protecting users privacy.
Figure 1-8 X.25 network load sharing
As shown in the above figure, server A and server B, which be configured with a hunt group HG 1,
provide users with the same service. Server A and server B addresses are 9999, and the hunt group
address is 8888. Enabling the destination address substitution function on Router A means that the
address 8888 is replaced by the address 9999. When a user transacts a service, the user terminal will
send a call to the destination address 8888. Such calls from any terminal are directed towards the
address 9999, which is transmitted to server A or server B via Router A. The load sharing between
server A and server B is implemented to lower the pressure on a single server.
X.25 hunt group supports two call channel selection policies: round-robin mode and vc-number mode.
However, a hunt group only uses one policy.
z The round-robin mode uses a cyclic selection method to select next interface or XOT channel
inside hunt group for each call. For example, in the above figure, if the hunt group HG 1 uses the
round-robin mode, the call will be sent in turn to server A or server B.
z The vc-number mode selects the interface with the maximum idle logic channels inside hunt group
for each call. For example, in the above figure, if the hunt group HG 1 uses the vc-number mode,
1-19
the remaining logic channels of the lines between server A and DCE are 500, while those of the
lines between server B and DCE are 300. Thus, the first 200 calls will be sent to server A, and the
subsequent calls will be sent in turn to server A or server B.
X.25 hunt group supports synchronous serial interface and XOT channel, and can select the available
lines between them indistinctively. However, since XOT channel cannot calculate the number of logic
channels, it will not be added to the hunt group that uses the vc-number selection policy.
X.25 network load sharing is configured on DCE device. In most cases, your device is used as DTE
device in X.25 network. The network providers provide the load sharing function on packet switch. In
this way, no special configuration is required on the device. For the specific configuration procedure,
refer to the previous chapters. When it is used as DCE device in X.25 network, it provides load sharing
function for DTE device. At this time, X.25 load sharing needs to be configured on it.
You need not configure the hunt group address, and only need to set the destination address as the
hunt group address on the source DTE.
Follow these steps to configure X.25 load sharing:

Required
Not enabled by default
Create an X.25 hunt group and x25 hunt-group hunt-group-name
Required
enter its view { round-robin | vc-number }
Add an interface or Annex G channel interface interface-type
DLCI to the hunt group interface-number [ dlci dlci-number ]
Required
Add an XOT channel to the
channel xot ip-address
hunt group
x25 switch svc x.121-address

Create an X.25 switching route [ sub-dest destination-address | Required
to the hunt group sub-source source-address ] * Not created by default.
hunt-group hunt-group-name
z A hunt group can contain up to 10 synchronous serial interfaces, Annex G DLCIs, or XOT
channels.
z XOT channels cannot be added to hunt groups adopting vc-number channel selection policies.
1-20
Configuring X.25 Closed User Group
Overview
Closed User Group (CUG) is a call restriction service provided by X.25 among all its optional services.
It governs call receiving and initiating capabilities of users (DTEs), allowing users in the same CUG to
call each other while forbidding users in different CUGs to do so. This allows a private data
communication subnet to form over public X.25 data communications networks for an organization.
One user may belong to multiple CUGs. When the user calls another user in a CUG, the CUG number
is included in its capability negotiation message. The user may also be set not to belong to any CUG, in
which case the capability message does not carry CUG information.
When used as data communication equipment (DCE), CUG function is shown in the following figure.
Figure 1-9 CUG function implementation
Call 1: DTE originates a call, but outgoing capability is barred, so the call is removed by DCE with CUG
enabled.
Call 2: DCE receives a call request and requests a connection with DTE. CUG function is enabled on
DCE and the incoming capability is barred, so the call is removed by DCE.
z CUG function
You must enable CUG function first before configuring it, which by default is not enabled.
After CUG function is enabled, all calls, including those with or without CUG facilities are suppressed.
You can also define some suppression policies for CUG to process calls in different ways.
Two types of CUG suppression policies are available. One is to suppress all incoming calls, where the
system removes the CUG facilities of all incoming calls with CUG facilities. The other is to suppress the
incoming calls matching the mapping specified as preference rule, where the system removes the CUG
facilities only of those incoming calls matching the mapping specified as preference rule, but lets other
incoming calls with CUG facilities pass through. The details are:
z Incoming suppression policy, in which the system lets the incoming calls without CUG facilities
pass through, but suppresses the incoming calls with CUG facilities but without access
configuration configured by the CUG mapping rule.
z Outgoing suppression policy, in which the system lets the outgoing calls without CUG facilities
pass through, but suppresses the outgoing calls with CUG facilities but without access
configuration configured by the CUG mapping rule.
1-21
z All suppression policy, in which the systems removes CUG facilities (if any) and make call
processing for all incoming calls. This policy is ineffective to outgoing calls.
z Preference mapping suppressing policy, in which the system removes CUG facilities and make
call processing for the incoming calls with CUG facilities and with preference mapping rule, but lets
the incoming calls without preference mapping rule pass through. This policy is ineffective to
outgoing calls.
You can only configure the CUG function on an X.25 interface working as DCE, that is, you must
specify the serial interface as DCE when specifying the X.25 protocol on it.
z CUG mapping and suppression rule

CUG mapping refers to CUG number conversation from local end (DTE) to network end (X.25) during
CUG call processing. For example, when processing the call from the DTE with CUG 10 to DTE with
CUG 20, the system first searches the mapping table for this mapping entry: if the table has this entry,
it forwards the packets, if not, it denies the forwarding.
You can define suppression rules in configuring CUG mapping, including three types:
z Outgoing call restriction
z Incoming call restriction
z Specifying as preference rule
Specifying as preference rule depends on CUG suppression policy. That is, if the suppression policy is
configured as only suppressing the CUG of preference mapping, then the system removes the CUG
facilities in the incoming call packet of this mapping and makes call processing.
You must configure CUG function on X.25 DCE interface, that is, you must specify it as DCE end in
encapsulating X.25 protocol on serial interface.
Follow these steps to configure CUG:

x25 cug-service [ incoming-access | Required
Enable CUG function and
outgoing-access | suppress { all |
configure suppression policy Disabled by default
preferential } ] *
x25 local-cug local-cug-number Required

Configure a local CUG to
network-cug network-cug-number
network CUG mapping and Not configured by
[ no-incoming | no-outgoing |
define suppression rule default
preferential ]*
1-22
The x25 cug-service and x25 local-cug commands are supported only on the X.25 DCE interface,
that is, you need to specify the interface as DCE when encapsulating X.25 protocol on the serial
interface.
X.25 PAD Remote Access Service

Introduction to X.25 PAD
Packet Assembly/Disassembly (PAD) is an X.25 specific concept.

Traditionally, only X.25 terminals could connect to an X.25 network. These terminals must be packet
terminals that support X.25 procedures in terms of hardware and software. However, many terminals in
common use are non-X.25 terminals. They either have no intelligence available with packet terminals
or have intelligence but do not support X.25 procedures. Examples of such terminals are keyboards,
monitors, and printers. To allow these devices to communicate on X.25 networks, X.25 PAD was
developed.
X.25 PAD provides a mechanism to connect non-X.25 terminals to an X.25 network. As shown in the
figure below, a PAD facility is placed between non-X.25 terminals and an X.25 network, allowing them
to communicate with other terminals across the X.25 network.
Figure 1-10 Interfacing function of PAD
X.25 PAD functions to provide:

z X.25 procedures support for connectivity and communication with X.25 networks
z Non-X.25 procedures support for connectivity with non-X.25 terminals.
z Capabilities allowing non-X.25 terminals to set up calls, transmit data, and clear calls.
z Capabilities allowing non-X.25 terminals to observe and modify interface parameters to
accommodate to different terminals.
X.25 PAD facilities are thus regarded procedures translators or network servers, helping different
terminals access X.25 networks.
The system implements X.29 and X.3 protocols in the X.25 PAD protocol suite. In addition, it
implements X.29-based Telnet. This allows you to telnet to a remote router through X.25 PAD when
IP-based Telnet is not preferred for security sake, as shown in the figure below.
Figure 1-11 Log onto a remote router through X.25 PAD
1-23
Configuring X.25 PAD
Place an X.25 PAD call to log onto a remote device
If two routers on an X.25 network support X.25 PAD, you can use the pad command to place an X.25
PAD call on one router (the client) to log onto the other router (the server). If authentication is
configured, the server will authenticate the client before allowing it to log in.
After logging onto the server, you can access the configuration interface on the server.
You can nest a pad command within another pad command or a telnet command. By nesting
commands, you can do the following on your router:
z Place an X.25 PAD call to log onto another router; and from that router, place another X.25 PAD
call to log onto a third router, and so on.
z Telnet to another router; and from that router, place an X.25 call to log onto a third router, and so
on.
z Place an X.25 PAD call to log onto another router; and from that router, telnet to a third router, and
so on.
To ensure transmission, limit nesting operations within three.
Logout operations are done in the reverse direction. You can execute the quit command multiple times
to log out the currently logged-in router and all the in-between routers one by one.
Set the delay waiting for the response to an Invite Clear message
The server end of X.25 PAD may send an Invite Clear message to the client, for example, after
receiving an exit request from client or in order to release the link. At the same time, a timer is started.
If no response is received upon expiration of the timer, the server will clear the link.
Follow these steps to configure X.25 PAD:

Set the delay waiting for the Optional
x29 timer inviteclear-time
response to an Invite Clear
seconds Defaults to 5 seconds
message
Exit to user view quit
Place an X.25 PAD call to the
pad x.121-address Required
specified X.121 address
Configuring X.25 over TCP (XOT)

Introduction to XOT Protocol
X.25 over TCP (XOT) carries X.25 packets over TCP to interconnect two X.25 networks across an IP
network. The following figure presents an XOT application environment.
1-24
Figure 1-12 Typical XOT application
At present, since IP network is used widely, it is necessary, in practice, to carry X.25 data and
implement the interconnection between X.25 networks via IP network. The traditional X.25 protocol
belongs to layer 3 (network layer) of OSI 7-layer model, and it can obtain the reliable data transmission
link via LAPB protocol. Since TCP has such mechanisms as error retransmission and window flow
control to ensure the reliability of the link, it can be used by X.25 protocol. XOT establishes a TCP
tunnel connection between X.25 networks at both ends, and X.25 packet, as the data of application
layer, is carried over TCP, i.e. TCP serves as link layer" of X.25. Router B, Router C and IP network in
the middle can be looked upon as a big X.25 switch, and the data sent by Router A is directly switched
to Router D via this switch.
XOT characteristics conform to the RFC1613 standard, which features as follows:
z Supporting SVC application. The routers at both ends can dynamically establish an SVC by
sending call packet, and this SVC will be automatically cleared when no data is transmitted.
z Supporting PVC application. After being configured with a PVC, the routers at both ends directly
enter the data transmission status without establishing a call. Moreover, this PVC will not be
dynamically deleted when no data is transmitted.
z Supporting Keepalive attribute of TCP. If Keepalive is not configured, TCP connection will still not
be cleared or cleared after a long time even if the connection is interrupted. However, after
Keepalive is configured, TCP will timely detect the availability of the link. If TCP does not receive
the response from the peer for many times, it will initiatively clear its connection.
XOT implementation principle (taking SVC as an example):
As shown in the above figure, when transmitting data, Router A first sends a call request packet to
establish VC. After receiving this call packet and judging it as XOT application, Router B will establish a
TCP connection with Router C, then add XOT header to X.25 call packet and encapsulate it into TCP,
finally transmit it to Router C. After deleting TCP and XOT header, Router C transfers the call request
packet to Router D via X.25 local switching. After receiving it, Router D will give out call
acknowledgement until the link is completely established to transmit data. The whole process for
establishment and application of TCP connection is transparent for Router A and Router D that do not
care whether data is forwarded via IP network or X.25 network.
Configure XOT
Follow these steps to configure XOT:
1-25
Required due to X.25
Enable X.25 switching x25 switching extension
ip address ip-address { mask |
mask-length } Required
Specify an IP address for Make sure the IP
or
the IP side interface network operates
ip address unnumbered interface normally
[ sub-dest destination-address |
Required
sub-source source-address ] * xot
ip-address&<1-6> [ xot-option ]
Configure Required
SVC XOT
route x25 switch svc [ -number ] x.121-address Use this command to
[ sub-dest destination-address | specify the local
sub-source source-address ] * interface switching interface that
Configure interface-type interface-number forwards received
XOT route packets for SVC
to route application
packet from
X.25 via IP interface interface-type interface-number
network
[ out-channel loc hoc ] | in-channel lic hic
Configure
[ bi-channel ltc htc ] [ out-channel loc hoc ]
PVC XOT
| out-channel loc hoc }
route in Required
interface x25 xot pvc pvc-number1 ip-address
view interface interface-type interface-number
pvc pvc-number2 [ xot-option | packet-size
input-packet output-packet | window-size
input-window-size output-window-size ] *
Configure XOT optional
Refer to Configure XOT optional attributes. Optional
attribute
z In SVC mode, X.25 routes are required.

z Since the default two-way channel range: LTC=1, HTC=1024 does not support PVC configuration,
you need to specify a VC range using the x25 vc-range command to create a PVC.
z For IP address configuration, refer to IP Addressing Commands in the IP Services Volume.
Configure XOT optional attributes
After TCP link is established, TCP will also not be cleared easily even if the link is interrupted. However,
after the Keepalive attribute is configured, the router will periodically send the detection packet to check
1-26
the availability of the link. If it has not received the acknowledgement after sending packets for many
times, the router will deem the link fault and will initiatively clear TCP connection.
Follow these steps to configure XOT optional attributes:

Configure the SVC
[ sub-dest destination-address | sub-source
Keepalive and source Optional
source-address ] * xot ip-address&<1-6>
attributes
[ xot-option ]
Configure the PVC x25 xot pvc pvc-number1 ip-address interface

Keepalive and source interface-type interface-number pvc pvc-number2
attributes [ xot-option | packet-size input-packet Optional
output-packet | window-size input-window-size
output-window-size ] *
Table 1-4 Options of the xot-option argument
Option Indicates
Keepalive timer for the XOT connection, in the range 1 to 3600
timer seconds seconds. Upon its timeout the router begins to send keepalive packets
to test availability of the connection
The maximum number of Keepalive packet sending attempts, in the
retry times range 3 to 3600. When the number of keepalive packet sending
attempts exceeds the limit, the XOT connection is disconnected
source interface-type
Interface where the XOT connection is initiated
interface-number
Configuring X.25 over FR
Introduction to X.25 over FR
X.25 over FR carries X.25 packets over FR to interconnect two X.25 networks across an FR network,
as shown in the following figure.
1-27
Figure 1-13 X.25 Over FR network diagram
Configuring SVC Application of X.25 over FR
X.25 over FR is an extension to X.25 switching, so you need enable X.25 switch first.
Follow these steps to configure SVC application of X.25 over FR:
Required
interface-number
Specify the link layer protocol link-protocol fr [ ietf | Required

as FR nonstandard ] PPP by default
fr interface-type { dce | dte | Required

Specify the FR interface type
nni } DTE by default
Configure an FR DLCI and
fr dlci dlci-number Required
enter its view
Configure the FR DLCI as
Annex G DLCI
x25 switch svc [ -number ] Required

x.121-address [ sub-dest After receiving a packet on the
destination-address | SVC, the packet is forwarded
Configure the SVC route
sub-source source-address ] * via a local interface. Use this
interface interface-type command to configure the local
interface-number forward interface.
x25 switch svc [ -number ]
x.121-address [ sub-dest
destination-address |
Configure the X.25 over FR
sub-source source-address ] * Required
SVC route
interface-number dlci
dlci-number
1-28
Configuring PVC Application of X.25 over FR
X.25 over FR is an extension to X.25 switching, so you need enable X.25 switch first.
Follow these steps to configure PVC application of X.25 over FR, use the following commands:
Required
Create an X.25 template x25 template { name } Required
[ out-channel loc hoc ] | in-channel lic
Specify the VC range Required
hic [ bi-channel ltc htc ] [ out-channel
loc hoc ] | out-channel loc hoc }
x25 switch pvc pvc-number1

Configure a PVC route under interface interface-type
Required
the X.25 template interface-number [ dlci dlci-number ]
pvc pvc-number2 [ option ]
interface-number
Configure the link layer protocol Required

link-protocol fr [ ietf | nonstandard ]
as FR PPP by default
Required
Configure the FR interface type fr interface-type { dce | dte | nni }
DTE by default
Configure an FR DLCI and

fr dlci dlci-number Required
enter its view
Configure the FR DLCI as
Annex G DLCI
Apply the X.25 Template to the
x25-template name Required
Annex G DLCI
interface-number
Configure the link layer protocol link-protocol x25 [ dce |dte ] [ ietf | Required
as X.25 nonstandard ] PPP by default
x25 switch pvc pvc-number1

Configure a PVC route Required
interface-number [ dlci dlci-number ]
pvc pvc-number2 [ option ]
Configuring X2T
Introduction
X.25 to TCP switch (X2T) connects X.25 to TCP/IP networks, allowing the access between X.25 and IP
hosts.
1-29
Figure 1-14 Network diagram for X2T
The X.25 terminal has an X.121 address to the IP host. Whenever the router receives an X.25 call
request packet, it checks the destination address of X.121 in the packet and looks up in the X2T routing
table for a match. If there is a matching route, the router will set up a TCP connection with the host at
the destination IP address of the X2T route. After that, the router will extract the pure data from the X.25
packet and send them to the IP host through the TCP connection.
The IP host can go through the IP address on the interface of the IP network to access the X.25 host.
Whenever the router receives a TCP connection request, it checks the destination IP address and TCP
port number of the TCP connection and looks up in the X2T routing table for a match. If there is a match,
the router will set up an X.25 SVC destined to the host at the associated destination X.121 address of
the X2T route. After that, the router will extract the pure data from the TCP packet and send them to the
X.25 host through the X.25 SVC. If the router sets up a PVC connection with X.25 host, it transmits the
data directly to X.25 host through X.25 PVC.
Follow these steps to configure X2T:

Enable X.25 switching x25 switching Required
Required
Configure X.25 interface Refer to Configuring an X.25 Interface. Unnecessary to specify
an X.121 address for
the interface
Configure IP interface Refer to the IP Services volume. Required
Configure an X.25-to-IP X2T translate x25 x.121-address ip
Required
forwarding route ip-address port port-number
1-30
Configure a PVC translate ip ip-address port
forwarding route port-number pvc interface-type Required
for PVC link interface-number pvc-number
Configure
translate ip ip-address port
an Required
port-number x25 x.121-address
IP-to-X.25
X2T Configure an
forwarding SVC route and a x25 switch svc [ -number ]
route forwarding route x.121-address [ sub-dest
for SVC link destination-address ] [ sub-source
Required
source-address ] * interface
interface-type interface-number [ dlci
dlci-number ]
z Number of X2T mapping entries varies by device. The maximum number of entries is 100 by
default, including both entries configured using the translate ip and translate x25 commands.
z When specifying a port number using the translate ip command, for an IP address using one port,
specify port 102, for an IP address using multiple ports, specify port numbers from 1024 to 5000
instead of well known port numbers such as 21, 23 to avoid network failures.
Displaying and Maintaining LAPB and X.25

display interface [ interface-type
Display interface information
interface-number ]
display x25 alias-policy [ interface
Display X.25 alias table
Display X.25 address mapping
display x25 map
table
display x25 cug { local-cug
Display CUG configuration [ local-cug-number ] | network-cug
[ network-cug-number ] }
Display X.25 PAD (Packet Available in any
Assembler/Disassembler) display x25 pad [ pad-id ] view
connection information
display x25 switch-table svc { dynamic |
Display X.25 switching table
static }
Display X.25 PVC switching
display x25 switch-table pvc
table
Display X.25 virtual circuit display x25 vc [ lci-number ]
Display X.25 XOT VCs display x25 xot
Display X2T dynamic switching
display x25 x2t switch-table
table
1-31
Display X.25 hunt group display x25 hunt-group-info Available in any
information [ hunt-group-name ] view
reset x25 { counters interface interface-type
Clear X.25 interface statistics
interface-number | vc interface interface-type
or VC
interface-number [ vc-number ] }
Available in user
reset xot local local-ip-address local-port
Clear (reset) an XOT link view
remote remote-ip-address remote-port
Clear the LAPB statistic
reset lapb statistics
information
LAPB Configuration Example

Two routers are directly connected back to back via serial interfaces encapsulated with LAPB that can
transmit IP datagrams directly.
Network diagram
Figure 1-15 Direct connection of two routers via serial interfaces (LAPB)
# Enter interface view.
# Assign an IP address for the interface.

# Configure the link layer protocol of the interface as LAPB, and specify it to work in DTE mode.
[RouterA -Serial2/0] link-protocol lapb dte
# Configure other LAPB parameters (If the link is sound enough and a higher rate is desired, you can
increase the traffic control parameters modulo to 128, k to 127, but the connected parties must always
keep the configured parameters in consistency.
[RouterA-Serial2/0] lapb modulo 128
[RouterA-Serial2/0] lapb window-size 127
[RouterA-Serial2/0] shutdown
[RouterA-Serial2/0] undo shutdown
1-32

# Configure the link layer protocol of the interface as LAPB, and specify it to work in DCE mode.
[RouterB-Serial2/0] link-protocol lapb dce
# Configure other LAPB parameters (If the link is sound enough and a higher rate is desired, you can
increase the traffic control parameters modulo to 128, k to 127, but the connected parties must always
keep the configured parameters in consistency.
[RouterB-Serial2/0] lapb modulo 128
[RouterB-Serial2/0] lapb window-size 127
[RouterB-Serial2/0] shutdown
[RouterB-Serial2/0] undo shutdown
Note that the IP addresses of the two connected interfaces must be in the same network segment. If
they are not on the same network segment, you need to configure a static route in between and make
sure the traffic control parameters of both sides are the same.
X.25 Configuration Examples

Direct Connection of Two Routers Connecting through Serial Interfaces (One
Address Mapping)
As shown in the following figure, two routers are directly connected; IP packets can be transmitted
between serial interfaces over X.25 link layer protocol. Only one IP to X.121 mapping is available on
Router A.
Network diagram
Figure 1-16 Direct connection of two routers through serial interfaces (X.25)
# Enter interface view

# Configure the link layer protocol of the interface as X.25, and configure the interface to operate in
DTE mode.
[RouterA-Serial2/0] link-protocol x25 dte
1-33
# Assign an X.121 address to the interface.
[RouterA-Serial2/0] x25 x121-address 20112451
# Configure the address mapping to the peer.

[RouterA-Serial2/0] x25 map ip 202.38.60.2 x121-address 20112452
# Configure the maximum packet size allowed and the window size.
[RouterA-Serial2/0] x25 packet-size 1024 1024
[RouterA-Serial2/0] x25 window-size 5 5
# Assign an IP address to the interface.

# Configure the link layer protocol of the interface as X.25, and specify it to operate in DCE mode.
[RouterB-Serial2/0] link-protocol x25 dce
#Assign an X.121 address for the interface.

[RouterB-Serial2/0] x25 x121-address 20112452
# Configure address mapping to the peer.

[RouterB-Serial2/0] x25 map ip 202.38.60.1 x121-address 20112451
[RouterB-Serial2/0] x25 packet-size 1024 1024
[RouterB-Serial2/0] x25 window-size 5 5
Note that, since IP to X.121 mapping is available, IP addresses of both ends can be on different
network segments and no static route is needed.
Direct Connection of Two routers Connecting through Serial Interfaces (Two

Address Mappings)
As shown in the following figure, two routers are connected directly; IP packets can be transmitted
between serial interfaces over X.25 link layer protocol. Two IP to X.121 mappings are available on
Router A.
1-34
Network diagram
Figure 1-17 Direct connection of two routers via serial interfaces (X.25)

# Configure the link layer protocol as X.25 and the interface to operate in DTE mode.
# Assign an X.121 address for the interface.

# Configure address mappings to the peer.

# Assign an IP address to the interface.

#Configure the link layer protocol of the interface as X.25 and specify the interface to operate in DCE
mode.

# Configure address mapping to the peer.

# Configure the maximum paket size allowed and the window size.
1-35
# Since the peer (Router A) has two IP addresses corresponding to the X.121 address at the
local end (Router B) and the local IP address is not in the first mapping, two VCs will be
created when connection being established, so you need to specify the maximum number of VCs
in the mapping as 2.
[RouterB-Serial2/0] x25 vc-per-map 2
Connecting the Router to X.25 Public Packet Network
As shown in the following figure, Routers A, Router B, and Router C are connected to the same X.25
network. The requirements are:
z The IP addresses of the interfaces Serial 2/0 of the three routers are 168.173.24.1/24,
168.173.24.2/24 and 168.173.24.3/24.
z The X.121 addresses assigned to the three routers are 30561001, 30561002, and 30561003.
z The standard window size supported by the packet network: both receiving window and sending
window are 5.
z The standard maximum packet size: both the maximum receiving packet size and the maximum
sending packet size are 512.
z Channel range: permanent virtual circuit range, incoming-only channel range and outgoing-only
channel range are disabled, and two-way channel range is [1, 32].
Network diagram
Figure 1-18 Connecting the router to X.25 public packet network
[RouterA] interface Serial 2/0
# Access the public packet network, and configure the router to operate in DTE mode.
1-36
[RouterA-Serial2/0] x25 vc-range bi-channel 1 32
[RouterB] interface Serial 2/0
# Access public packet network, and configurethe router to operate in DTE mode.
[RouterB-Serial2/0] link-protocol x25 dte
[RouterB-Serial2/0] x25 vc-range bi-channel 1 32
[RouterC] interface Serial 2/0
# Access public packet network, configure the router to operate in DTE mode.
[RouterC-Serial2/0] link-protocol x25 dte
[RouterC-Serial2/0] x25 x121-address 30561003
[RouterC-Serial2/0] x25 window-size 5 5
[RouterC-Serial2/0] x25 packet-size 512 512
[RouterC-Serial2/0] x25 vc-range bi-channel 1 32
[RouterC-Serial2/0] x25 map ip 168.173.24.1 x121-address 30561001
Configuring VC Range
The link layer protocol of the router interface Serial 2/0 is X.25, and VC ranges as follows: PVC range [1,
8], incoming-only channel range [9, 16], two-way channel range [17, 1024], and outgoing-only channel
range is disabled.
[Router-Serial2/0] link-protocol x25
[Router-Serial2/0] x25 vc-range in-channel 9 16 bi-channel 17 1024
1-37
[Router-Serial2/0] shutdown
[Router-Serial2/0] undo shutdown
Transmitting IP Datagrams through X.25 PVCs
z In the following diagram, the PVC range that the packet network allows is [1, 8]. The PVC numbers
assigned to RouterA and RouterB are 3 and 4.
z The IP addresses of LAN 1 and LAN 2 are 202.38.165.0/24 and 196.25.231.0/24.
z It is required to exchange route information between LAN 1 and LAN 2 using RIP, so that Host A
and Host B can exchange information without any static route.
Network diagram
Figure 1-19 Carry IP datagrams over X.25 PVC
X.25 network
PVC 3 PVC 4
S2/0 S2/0
192.149.13.1/24 192.149.13.2/24
X121 address: 1004358901 X121 address: 1004358902
Router A Router B
Eth1/0 Eth1/0
202.38.165.1/24 196.25.231.1/24
LAN 1 LAN 2
Host A Host B
# Configure interface Ethernet 1/0.
# Configure interface Serial 2/0.

[RouterA-Serial2/0] link-protocol x25
[RouterA-Serial2/0] x25 pvc 3 ip 192.149.13.2 x121-address 1004358902 broadcast packet-size
512 512 window-size 5 5
1-38
# Enable RIP.
[RouterA] rip

[RouterB-Serial2/0] link-protocol x25
[RouterB-Serial2/0] x25 pvc 4 ip 192.149.13.1 x121-address 1004358901 broadcast packet-size
512 512 window-size 5 5
# Enable RIP.
[RouterB] rip
As you go through the above configuration procedure, you may be probably puzzled due to different
PVC numbers (that is, 3 and 4 in this scenario) on Router A and Router B. You should distinguish
between VC and logic-channel. Virtual circuit refers to the end-to-end logic link between the calling
DTE and the called DTE, while logic channel refers to the logic link between two directly connected
devices (either between DTE and DCE, or between the ports of two packet switching exchanges). A
virtual circuit consists of several logic channels, and each logic channel has a separate number. Hence,
a VC between Router A and Router B can be the one shown in the following figure (suppose this VC
passes four packet switches in the network).
Figure 1-20 One VC consisting of several logic-channels
Therefore, the PVC 3 and PVC 4 mentioned in the example actually refer to the numbers of the
logic-channels between the routers and the PBXs directly connected. The two sides of the PVC can
1-39
identify the same PVC by using their logic-channel numbers, however, without the likelihood of causing
any mistake. This is why no strict distinction is made between "virtual circuit" and "logic channel".
X.25 Subinterface Configuration Example
In the following figure, Router A is configured with two subinterfaces, which are connected with Router
B and Router C. Router D operates as an X.25 switch. It is desired that Router A can communicate with
Router B and Router C respectively.
Network diagram
Figure 1-21 X.25 subinterface configuration
# Configure subinterface Serial 2/0.1, and X.25 mapping to Router B.

[RouterA-Serial2/0] interface serial 2/0.1
[RouterA-Serial2/0.1] x25 map ip 10.1.1.1 x121-address 200
# Configure subinterface serial 2/0.2, and X.25 mapping to Router C..

[RouterA-Serial2/0.1] interface serial 2/0.2
[RouterA-Serial2/0.2] x25 map ip 20.1.1.1 x121-address 300
1-40
4) Configure Router D as an X.25 switch
[RouterD] interface serial 2/0
[RouterD-Serial2/0] link-protocol x25 dce
[RouterD-Serial2/0] quit
# Configure SVC switching routes,

[RouterD] x25 switching
[RouterD] x25 switch svc 100 interface serial 2/0
SVC Application of XOT
Router B and Router C are connected through Ethernet interfaces. Set up a TCP connection between
them to deliver data between Serial 2/0 of Router A and Serial 2/0 of Router D. Configure SVCs and
XOT.
Network diagram
Figure 1-22 Network diagram for XOT SVC
# Configure basic X.25.
1-41
[RouterA-Serial2/0] link-protocol x25 dte ietf
[RouterD-Serial2/0] link-protocol x25 dte ietf
[RouterD-Serial2/0] x25 x121-address 2
[RouterD-Serial2/0] x25 map ip 1.1.1.1 x121-address 1
[RouterD-Serial2/0] ip address 1.1.1.2 255.0.0.0
# Enable X.25 switching.
[RouterB] x25 switching
# Configure local X.25 switching, specifying packets to X.121 address 1 to pass through Serial 2/0.
[RouterB] x25 switch svc 1 interface serial 2/0
# Configure XOT switching, specifying an X.25 switching route to XOT channel.

[RouterB] x25 switch svc 2 xot 10.1.1.2

[RouterB-Serial2/0] link-protocol x25 dce ietf

[RouterC] x25 switching
# Configure local X.25 switching, specifying packets to X.121 address 2 to pass through Serial 2/0.
[RouterC] x25 switch svc 2 interface serial 2/0
# Configure XOT switching, specifying an X.25 switching route to XOT channel.

[RouterC] x25 switch svc 1 xot 10.1.1.1

[RouterC-Serial2/0] link-protocol x25 dce ietf

[RouterC] interface ethernet 1/0
1-42
[RouterC-Ethernet1/0] ip address 10.1.1.2 255.0.0.0
PVC Application of XOT
Router B and Router C are connected through Ethernet interfaces. Set up a TCP connection between
them to deliver data between Serial 2/0 of RouterA and Serial 2/0 of Router D. Configure PVCs and
XOT.
Network diagram
Figure 1-23 Network diagram for XOT PVC application
Router B Router C
XOT
Eth1/0 Eth1/0
S2/0 10.1.1.1/8 10.1.1.2/8 S2/0
PVC 1 PVC 2
S2/0 S2/0
1.1.1.1/8 1.1.1.2/8
X121 address:1111 X121 address:2222
Router A Router D
[RouterA-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterA-Serial2/0] x25 pvc 1 ip 1.1.1.2 x121-address 2222
[RouterD-Serial2/0] link-protocol x25 dte ietf
[RouterD-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterD-Serial2/0] x25 pvc 2 ip 1.1.1.1 x121-address 1111
# Enable x.25 switching.
1-43
# Configure Serial 2/0 and XOT route.
[RouterB-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterB-Serial2/0] x25 xot pvc 1 10.1.1.2 interface serial 2/0 pvc 2
# Configure Ethernet 1/0.

# Configure Serial 2/0 and XOT route.

[RouterC-Serial2/0] link-protocol x25 dce ietf
[RouterC-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterC-Serial2/0] x25 xot pvc 2 10.1.1.1 interface serial 2/0 pvc 1
# Configure Ethernet 1/0.

SVC Application of X.25 over FR
In the following figure, Router A is connected to Router B, Router C to Router D through X.25. Router B
is connected to Router C through FR. Configure FR Annex G DLCI 100 on the two routers to
interconnect the two X.25 networks, enabling Host A and Host B to communicate with each other.
Network diagram
Figure 1-24 Network diagram for X.25 over FR SVC configuration
# Configure X.25 basic functions.
1-44
[RouterD-Serial2/0] link-protocol x25 dte
[RouterD-Serial2/0] x25 map ip 1.1.1.1 x121-address 1
# Configure Serial 2/0 as X.25 interface.

# Configure Serial 2/1 as FR interface.

# Configure the FR Annex G DLCI.

[RouterB-fr-dlci-Serial2/1-100] annexg dce
# Configure X.25 local switching.

# Configure X.25 over FR switching.

[RouterB] x25 switch svc 2 interface serial 2/1 dlci 100
# Configure Serial 2/0 as X.25 interface.

[RouterC-Serial2/0] link-protocol x25 dce
# Configure Serial 2/1 as FR interface.


[RouterC-Serial2/1] fr dlci 100
[RouterC-fr-dlci-Serial2/1-100] annexg dte
1-45
# Configure X.25 local switching.
[RouterC] x25 switch svc 2 interface serial 2/0
# Configure X.25 over FR switching.

[RouterC] x25 switch svc 1 interface serial 2/1 dlci 100
PVC Application of X.25 over FR
In the following figure, Router A is connected to Router B, Router C to Router D through X.25. Router B
is connected to Router C through FR. Configure FR Annex G DLCI 100 on the two routers to
interconnect the two X.25 networks, enabling Host A and Host B to communicate with each other.
Network diagram
Figure 1-25 Network diagram for X.25 over FR SVC configuration

Router A Router B Router C Router D
S2/0 S2/1 S2/0
S2/0 S2/1 S2/0

Eth1/0 1.1.1.1/24 1.1.1.2/24
Eth1/0
X121 address:1 X121 address:2
Host A
Host B
[RouterA-Serial2/0] x25 pvc 1 ip 1.1.1.2 x121-address 2
[RouterD-Serial2/0] link-protocol x25 dte
[RouterD-Serial2/0] x25 vc-range bi-channel 10 20
[RouterD-Serial2/0] x25 pvc 1 ip 1.1.1.1 x121-address 1
1-46
# Configure the PVC switching route on X.25 interface Serial 2/0.

[RouterB-Serial2/0] x25 switch pvc 1 interface serial 2/1 dlci 100 pvc 1
# Configure X.25 template.

[RouterB] x25 template switch
[RouterB-x25-switch] x25 vc-range bi-channel 10 20
# Configure the PVC switching route for the template.

[RouterB-x25-switch] x25 switch pvc 1 interface serial 2/0 pvc 1
# Configure FR interface Serial 2/1.


[RouterB-fr-dlci-Serial2/1-100] annexg dce
# Apply the X.25 template to the FR Annex G DLCI.

[RouterB-fr-dlci-Serial2/1-100] x25-template switch
# Configure the PVC switching route on the X.25 interface Serial 2/0.
[RouterC-Serial2/0] link-protocol x25 dce
[RouterC-Serial2/0] x25 vc-range bi-channel 10 20
[RouterC-Serial2/0] x25 switch pvc 1 interface serial 2/1 dlci 100 pvc 1
# Configure X.25 template.

[RouterC] x25 template switch
[RouterC-x25-switch] x25 vc-range bi-channel 10 20
# Configure the PVC switching route for the template.

[RouterC-x25-switch] x25 switch pvc 1 interface serial 2/0 pvc 1
# Configure FR interface Serial 2/1.


1-47
# Apply the X.25 template to the FR Annex G DLCI.
[RouterC-fr-dlci-Serial2/1-100] x25-template switch
X.25 Load Sharing Application
You need to configure hunt group on Router A used as X.25 switch, and enable destination address
and source address substitution function, so that the calls from X.25 terminal can be sent to Router B,
Router C and Router E via the load sharing function. As X.25 switch, Router D that connects with
Router A and Router E is used to implement XOT function. As DTEs in hunt group, Router B, Router C
and Router E provide the same service for X.25 terminal. Router B and A use X.25, Router C and A use
FR. Apply Annex G on DLCI to make the two routers communicate to each other.
Network diagram
Figure 1-26 Network diagram for typical X.25 hunt group configuration
# Configure the link layer protocol of the interface Serial 2/0 as X.25, and configure it to operate in DCE
mode.
[RouterA-Serial2/0] link-protocol x25 dce
# In the same way as listed above, configure the link layer protocol of the interface Serial 2/2, Serial 2/3,
and Serial 2/4 as X.25 and configure them to operate in DCE mode.
# Configure Serial 2/1 as an FR DCE.
1-48
# Configure an FR Annex G DLCI.
[RouterA-fr-dlci-Serial2/1-100] annexg dce


[RouterA] x25 switching
# Create X.25 hunt group hg1.

[RouterA] x25 hunt-group hg1 round-robin
# Add interfaces Serial 2/2, Serial 2/1, and XOT channel to the hunt group.
[RouterA-hg-hg1] channel interface serial 2/2
[RouterA-hg-hg1] channel interface serial 2/1 dlci 100
[RouterA-hg-hg1] channel xot 10.1.1.2
[RouterA-hg-hg1] quit
# Configure X.25 switching route forwarded towards the hunt group hg1, and enable destination
address and source address substitution, substituting 3333 and 8888 for source and destination
addresses of packets destined to hunt group address 2222.
[RouterA] x25 switch svc 2222 sub-dest 8888 sub-source 3333 hunt-group hg1
# Configure X.25 switching route forwarded to X.25 terminal.

[RouterA] x25 switch svc 1111 interface serial 2/3
# Configure the link layer protocol of interface Serial 2/0 as X.25, and configure it to operate in DTE
mode.
[RouterC] x25 template vofr
[RouterC-x25-vofr] x25 x121-address 8888
[RouterC-x25-vofr] quit
# Enable FR on Serial 2/0.

# Configure FR Annex G DLCI.

1-49
# Apply the X.25 template to the DLCI.
[RouterC-fr-dlci-Serial2/0-100] x25-template vofr
4) Configure Router E.
# Configure the link layer protocol on Serial 2/0 as X.25 and configure it to operate in DTE mode.
<RouterE> system-view
[RouterE] interface serial 2/0
[RouterE-Serial2/0] link-protocol x25 dte
[RouterE-Serial2/0] x25 x121-address 8888
5) Configure Router D.
[RouterD] x25 switching
# Configure the link layer protocol of the interface Serial 2/0 as X.25, and configure it to operate in DCE
mode.
# Assign an IP address for the interface Ethernet 1/0

[RouterD] interface ethernet 1/0
[RouterD-Ethernet1/0] ip address 10.1.1.2 255.255.255.0
[RouterD-Ethernet1/0] quit
# Configure an X.25 switching route to an XOT channel

[RouterD] x25 switch svc 3333 xot 10.1.1.1
# Configure an X.25 switching route to Router E

Implementing X.25 Load Sharing Function for IP Datagram Transmission
IP networks in different regions are connected via X.25 packet switching network to carry data over
X.25 network. Meanwhile, the network providers provide X.25 network load sharing function, and a
user can perform the relative settings in conjunction with it on local terminal to implement the line load
sharing when different clients access the server.
1-50
Network diagram
Figure 1-27 Transmit IP data over X.25 hunt group
In this example, since the network providers have configured load sharing on the packet switch, you
only need to configure X.25 switching.
Note that there have been two lines connected to the same peer on Router C, so you must configure a
virtual IP address and two static routes on the interface Serial 2/1 to cheat the router. In this way,
Router C will deem that there are two routes towards the network segment 10.1.1.0, to implement the
load sharing.

[RouterA-Serial2/0] x25 vc-per-map 2
# Configure a static route to Router C.


1-51
[RouterB-Serial2/0] x25 vc-per-map 2
# Configure a static route to Router C.

[RouterB] ip route-static 10.3.1.0 24 1.1.1.3


# Configure static routes to Router A and Router B.

[RouterC] ip route-static 10.1.1.0 24 1.1.1.1
TCP/IP Header Compression Protocol Application
As shown in the following figure, two routers are connected directly.
1-52
Network diagram
Figure 1-28 Network diagram for TCP/IP header compression protocol application
1) Configure RouterA
# Configure the link layer protocol of Serial 2/0 as X.25, and configure the interface to operate in DTE
mode.
[RouterA-serial2/0] link-protocol x25 dte ietf
# Assign an x121 address for the interface.

[RouterA-serial2/0] x25 x121-address 1001

[RouterA-serial2/0] ip address 16.16.16.1 255.255.0.0
# Enable TCP/IP header compression.

[RouterA-serial1/0] x25 map compressedtcp 16.16.16.2 x121-address 1002
# Configure the link layer protocol of Serial 2/0 as X.25, and configure the interface to operate in DCE
mode.
[RouterB-serial2/0] link-protocol x25 dce ietf

[RouterB-serial2/0] x25 x121-address 1002

[RouterB-serial2/0] ip address 16.16.16.2 255.255.0.0
# Enable TCP/IP header compression.

[RouterB-serial2/0] x25 map compressedtcp 16.16.16.1 x121-address 1001
X.25 PAD Configuration Example
As shown in the following figure, Router A is connected to Router B through an X.25 network. It is
required that Router B could place X.25 PAD calls to log onto Router A and then configure Router A.
1-53
Network diagram
Figure 1-29 Network diagram for X.25 PAD configuration
# Add a PAD user.
[RouterA] local-user pad1
[RouterA-luser-pad1] password simple pad1
[RouterA-luser-pad1] service-type pad
[RouterA-luser-pad1] quit
# Access a user-interface, and on it configure authentication mode and protocol type.

[RouterA] user-interface vty 0 4
[RouterA-ui-vty0-4] authentication-mode scheme
[RouterA-ui-vty0-4] protocol inbound pad
[RouterA-ui-vty0-4] quit
# Configure domain user X.25 to use the local authentication scheme.

[RouterA] domain x25
[RouterA-isp-x25] authentication ppp local
[RouterA-isp-x25] quit
# Configure the link layer protocol of the interface Serial 2/0 as X.25. Configure the interface to operate
in DTE mode.

# Configure the link layer protocol of the interface Serial 2/0 as X.25. Configure the interface to operate
in DCE mode.

[RouterB] quit
# Place an X.25 PAD call to Router A.

<RouterB> pad 1
1-54
Trying 1...Open
Username:pad1
Password:pad1
X2T Configuration Examples

X2T SVC Configuration Example
The router connects X.25 and IP networks together. In this connection, the X.25 terminal
communicates with the router through SVC and the X2T technology applied on the router enables the
communication between X.25 terminal and IP host.
Network diagram
Figure 1-30 Network diagram for X2T SVC

[Router] x25 switching

[Router-Serial2/0] link-protocol x25 dce
[Router-Serial2/0] x25 x121-address 1111

[Router] interface ethernet 1/0
[Router-Ethernet1/0] ip address 10.1.1.1 255.255.255.0
[Router-Ethernet1/0] quit
# Configure an X.25 route.

[Router] x25 switch svc 2222 interface serial 2/0
# Configure an X2T route.

[Router] translate ip 10.1.1.1 port 102 x25 2222
[Router] translate x25 1111 ip 10.1.1.2 port 102
1-55
X2T PVC Configuration Example
The router connects X.25 and IP networks together. In this connection, the X.25 terminal
communicates with the router through PVC and the X2T technology applied on the router enables the
communication between IP host and X.25 terminal.
Network diagram
Figure 1-31 Network diagram for X2T PVC

[Router] x25 switching

[Router-Serial2/0] link-protocol x25 dce
[Router-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024

# Configure an X2T route.

[Router] translate ip 10.1.1.1 port 102 pvc serial2/0 1
Troubleshooting LAPB Configuration

LAPB (or X.25) of Two Sides Always Being Down
Symptom
Link layer protocol LAPB (or X.25) of two sides is always down.
Analysis
A possible reason is that the two sides are working in the same mode (DTE or DCE).
Troubleshooting
Enable the debugging on both sides. If one side sends SABM frames and the other sends FRMR
frames cyclically, the two sides are working in the same mode (DTE or DCE). Change the working
mode of one side to solve it.
1-56
Failed to Ping the Other Side with X.25 on Both Sides Being Up
Symptom
Despite X.25 is up on both sides, the other side can not be pinged.
Analysis
The maximum length of frames set at one side is too small.
Troubleshooting
Enable the debugging on both sides. If one side discards incoming frames without delivering them to
the upper layer, it indicates the maximum length of frames set for this side is too small. Change the
frame length configuration of this side.
Troubleshooting X.25 Configuration

Assume that the layer 2 LAPB of X.25 is up.
X.25 of Two Sides Always Being Down with LAPB of two sides Being Up
Symptom
X.25 of two sides is always down although LAPB of two sides is up.
Analysis
A possible reason is that the two sides are working in the same mode (DTE or DCE).
Troubleshooting
Change the working mode of one side.
Failed to Ping the Other Side with X.25 on Both Sides Being Up
Symptom
Despite X.25 is up on both sides, the other side can not be pinged.
Analysis
The following are possible causes:

z The local X.121 address is not configured.
z The address mapping of the two sides is not configured on the local end.
z The peers X.121 address is not configured.
z The address mapping of the two sides is not configured on the remote end.
z The channel range is not correct.
z Some wrong user facilities are carried.
Troubleshooting
z If addresses are not correct, change them to the correct ones.

z For the last two causes, you need contact the network administration to get the correct channel
range and user facilities.
1-57
Continuous Resets and Clears of the VC Established
Symptom
The virtual circuit can be set up, but is frequently reset or cleared during data transmission.
Analysis
The symptom may be caused by erroneous flow control parameter settings.
Troubleshooting
z If the two sides are connected directly, verify the output window and input window of the local
match the input window and output window of the remote.
z If both sides are connected to the public packet network, consult the network administration for the
correct flow control parameters.
PVC Setup Request Rejected
Symptom
The request to set permanent virtual circuits (PVCs) is rejected.
Analysis
A possible reason is that the PVC range is disabled.
Troubleshooting
If the assigned PVC number is in the disabled PVC channel range, X.25 will surely reject the PVC setup
request. In this case, enable the permanent virtual circuit channel range.
Troubleshooting X.25 PAD
Symptom: Failed to log onto a remote device after placing an X.25 PAD call to the remote device. The
system prompted the destination address was unreachable.
Solution:
Check that:
z The two ends of the X.25 PAD call are connected through an X.25 network and the physical
connection is normal. The serial interfaces used for connection are encapsulated with X.25 and
both of them support X.25 PAD. One end is DCE, the other is DTE, both using the same
encapsulation type (IETF or nonstandard).
z The destination X.121 address is correct. It must be the one assigned to the intended serial
interface at server end.
z Check that X.25 switching is disabled, or a route is available to the server end when X.25 switching
is enabled. In the former case, the default route is used to route the call. In the second case, at
least one route must be configured for routing the call.
Failed to Ping through the XOT SVC Configured
Symptom
After configuring SVC application of XOT, unable to ping through.
1-58
Analysis
The physical status and protocol status of the interface are not up, or the SVC/XOT configuration is not
correct.
Troubleshooting
Perform the following procedure to remove the fault.

z First verify the physical connection status and protocol status of the interface are UP.
z If the interface status is DOWN, check whether the physical connections and lower layer
configurations are correct.
z If the interface configuration is correct, check whether SVC is configured properly.
z If the SVC configuration is also correct, check whether XOT is configured properly.
Failed to Ping through the XOT PVC Configured
Symptom
After configuring PVC application of XOT, unable to ping through.
Analysis
The physical status and protocol status of the interface are not up, or the PVC/XOT configuration is not
correct.
Troubleshooting
z First check whether the physical connection status and protocol status of the interface are UP.
z If the interface status is DOWN, check whether the physical connections and lower layer
configurations are correct.
z If the interface configuration is correct, check whether the PVC is configured properly.
z If the PVC configuration is also correct, check whether XOT is configured properly.
1-59
Table of Contents
1 Link Aggregation Configuration 1-1

Overview 1-1
Basic Concepts of Link Aggregation 1-1
Link Aggregation Modes1-3
Load Sharing Mode of an Aggregation Group 1-5
Configuring a Static Aggregation Group 1-5
Configuring a Layer-2 Static Aggregation Group 1-6
Configuring a Layer-3 Static Aggregation Group 1-6
Configuring a Dynamic LACP Aggregation Group1-7
Configuring a Layer-2 Dynamic LACP Aggregation Group1-7
Configuring a Layer-3 Dynamic LACP Aggregation Group1-7
Configuring an Aggregate Interface 1-9
Configuring the Description of an Aggregate Interface 1-9
Configuring the MTU of a Layer-3 Aggregate Interface/Subinterface1-9
Enabling LinkUp/LinkDown Trap Generation for an Aggregate Interface 1-10
Shutting Down an Aggregate Interface 1-10
Displaying and Maintaining Link Aggregation1-11
Link Aggregation Configuration Example1-11
Network Diagram1-11
i

Manual aggregation No No Yes Yes
Static LACP aggregation No No Yes Yes
Service loopback group No No No No
1 Link Aggregation Configuration
When configuring link aggregation, go to these sections for information you are interested in:
z Overview
z Configuring a Static Aggregation Group
z Configuring a Dynamic LACP Aggregation Group
z Configuring an Aggregate Interface
z Displaying and Maintaining Link Aggregation
z Link Aggregation Configuration Example
Overview
Link aggregation aggregates multiple physical Ethernet ports into one logical link, also called an
aggregation group.
It allows you to increase bandwidth by distributing traffic across the member ports in the aggregation
group. In addition, it provides reliable connectivity because these member ports can dynamically back
up each other.
Basic Concepts of Link Aggregation
Aggregate interface
An aggregate interface is a logical Layer-2 or Layer-3 aggregate interface.
Aggregation group
An aggregation group is a collection of Ethernet interfaces. When you create an aggregate interface, an
aggregation group is created automatically depending on the type of the aggregate interface:
1-1
z If the aggregate interface is a Layer 2 interface, a Layer-2 aggregation group is created. You can
assign only Layer-2 Ethernet interfaces to the group.
z If the aggregate interface is a Layer-3 interface, a Layer-3 aggregation group is created. You can
assign only Layer-3 Ethernet interfaces to the group.
States of the member ports in an aggregation group
A member port in an aggregation group can be in one of the following two states:
z Selected: a selected port can forward user traffic.
z Unselected: an unselected port cannot forward user traffic.
The rate of an aggregate interface is the sum of the selected member ports rates. The duplex mode of
an aggregate interface is consistent with that of the selected member ports. Note that all selected
member ports use the same duplex mode.
For how to determine a member ports state, refer to Static aggregation mode and Dynamic LACP
aggregation mode.
LACP protocol
The Link Aggregation Control Protocol (LACP) is defined in IEEE 802.3ad. It uses link aggregation
control protocol data units (LACPDUs) for information exchange between LACP-enabled devices.
LACP is automatically enabled on interfaces in a dynamic aggregation group. For information about
dynamic aggregation groups, refer to Dynamic LACP aggregation mode. An LACP-enabled interface
sends LACPDUs to notify the remote system (the partner) of its system LACP priority, system MAC
address, LACP port priority, port number, and operational key. Upon receiving an LACPDU, the partner
compares the received information with the information received on other interfaces to determine the
interfaces that can operate as selected interfaces. This allows the two systems to reach an agreement
on which link aggregation member ports should be placed in selected state.
Operational key
When aggregating ports, link aggregation control automatically assigns each port an operational key
based on some configurations of the port, including its rate, duplex mode, and class-two configurations
listed in Table 1-1.
In the same aggregation group, member ports different in the above-mentioned configurations are
assigned different operational keys. A member port different from the aggregate interface in the
above-mentioned configurations cannot be a selected port.
In an aggregation group, all selected ports are assigned the same operational key.
Table 1-1 Class-two configurations
Type Considerations
Whether a port has joined an isolation group, and the isolation group that the port
Port isolation
belongs to
QinQ enable state (enable/disable), outer VLAN tags to be added, inner-to-outer
QinQ VLAN priority mappings, inner-to-outer VLAN tag mappings, inner VLAN ID
substitution mappings
BPDU tunnel STP BPDU tunnel enable state (enable/disable)
Permitted VLAN IDs, default VLAN, link type (trunk, hybrid, or access),
VLAN
subnet-based VLAN configuration, protocol-based VLAN configuration, tag mode
Port attributes Rate, duplex mode, and state (up/down)
1-2
Type Considerations
MAC address learning capability, MAC address learning limit, forwarding of frames
MAC address
with unknown destination MAC addresses after the upper limit of the MAC address
learning
table is reached
Link Aggregation Modes
Depending on the link aggregation procedure, link aggregation operates in one of the following two
modes:
z Static aggregation mode
z Dynamic LACP aggregation mode
Support for aggregation modes depends on your device model.
Static aggregation mode
LACP is disabled on the member ports in a static aggregation group. In a static aggregation group, the
system sets a port to selected or unselected state by the following rules:
z Select a port as the reference port from the ports that are in up state and with the same class-two
configurations as the corresponding aggregate interface. These ports are selected in the order of
full duplex/high speed, full duplex/low speed, half duplex/high speed, and half duplex/low speed,
with full duplex/high speed being the most preferred. If two ports with the same duplex mode/speed
pair are present, the one with the lower port number wins out.
z Consider the ports in up state with the same speed, duplex mode, link state and class-two
configurations as the reference port as candidate selected ports, and set all others in the
unselected state.
z Static aggregation limits the number of selected ports in an aggregation group. When the number
of the candidate selected ports is under the limit, all the candidate selected ports become selected
ports. When the limit is exceeded, set the candidate selected ports with smaller port numbers in the
selected state and those with greater port numbers in the unselected state.
z If all the member ports are down, set their states to unselected.
z Set the ports that cannot aggregate with the reference port to the unselected state, for example, as
a result of the inter-board aggregation restriction.
In addition, a port that joins the aggregation group after the limit on the number of selected ports has
been reached will not be placed in the selected state even if it should be in normal cases. This is to
prevent the ongoing traffic on the current selected ports from being interrupted. You should avoid the
situation however, as this may cause the selected/unselected state of a port to change after a reboot.
1-3
z The maximum number of selected ports allowed in an aggregation group depends on your device
model.
z To have a member port in a static link aggregation group becomes selected, you must manually
configure the port to ensure that it is identical with the reference port in rate, duplex mode, link state,
and class-two configurations.
z When the state of a port in an aggregation group changes, the system does not deaggregate the
aggregation group. Instead, the system re-sets the selected/unselected state of each member port.
Dynamic LACP aggregation mode
LACP is enabled on member ports in a dynamic LACP aggregation group.

In a dynamic LACP aggregation group,
z A selected port can receive and transmit LACPDUs.
z An unselected port can receive and send LACPDUs only if it is up and with the same configurations
as those on the aggregate interface.
In a dynamic LACP aggregation group, the system sets the ports to selected or unselected state in the
following steps:
1) The local system (the actor) negotiates with the remote system (the partner) to determine port state
based on the port IDs on the end with the preferred system ID. The following is the detailed
negotiation procedure:
z Compare the system ID (comprising the system LACP priority and the system MAC address) of the
actor with that of the partner. The system with the lower LACP priority wins out. If they are the same,
compare the system MAC addresses. The system with the smaller MAC address wins out.
z Compare the port IDs of the ports on the system with the smaller system ID. A port ID comprises a
port LACP priority and a port number. First compare the port LACP priorities. The port with the
lower LACP priority wins out. If two ports are with the same LACP priority, compare their port
numbers. The port with the smaller port ID is selected as the reference port.
z If a port (in up state) and its peer port are with the same speed/duplex pair, link state and class-two
configuration as the reference port, consider the port as a candidate selected port; otherwise set
the port to the unselected state.
z The number of selected ports that an aggregation group can contain is limited. When the number of
candidate selected ports is under the limit, all the candidate selected ports are set to selected state.
When the limit is exceeded, the system selects the candidate selected ports with smaller port IDs
as the selected ports, and set other candidate selected ports to unselected state. At the same time,
the peer device, being aware of the changes, changes the state of its ports accordingly.
2) Set the ports that cannot aggregate with the reference port to the unselected state, for example, as
the result of the inter-board aggregation restriction.
1-4
z The maximum number of selected ports allowed in an aggregation group depends on your device
model.
z In an aggregation group, the port to be a selected port must be the same as the reference port in
rate, duplex mode, link state, and class-two configurations. To keep these configurations
consistent, you should configure the port manually.
z When the state of a port in an aggregation group changes, the system does not deaggregate the
aggregation group. Instead, the system re-sets the selected/unselected state of each member port.
Load Sharing Mode of an Aggregation Group
A link aggregation groups operates in load sharing aggregation mode or non-load sharing mode.
The system sets the load sharing mode of an aggregation group as follows:
z When hardware resources are available, a link aggregation group with at least two selected ports
operates in load sharing mode. The load sharing mode of a link aggregation group with only one
selected port depends on your device model.
z After hardware resources become depleted, all new link aggregation groups operate in non-load
sharing mode.
z After you remove all ports but one selected port from a load-sharing aggregation group, whether
the group continues to perform load sharing depends on your device model.
z A load-sharing aggregation group contains at least one selected port while a non-load-sharing
aggregation group can only have one selected port at most.
z The maximum number of load-sharing aggregation groups allowed depends on your device model.
z The load sharing implementation approach depends on your device model.
z After hardware resources become depleted, all new link aggregation groups operate in non-load
sharing mode. They will not perform load sharing even after resources become available again due
to removal of aggregation groups. To set such a non-load-sharing group to a load-sharing one, you
must reconfigure its aggregate interface.
Configuring a Static Aggregation Group

Based on the type of Ethernet interfaces to be aggregated, you can create a Layer-2 or Layer-3 static
aggregation group.
1-5
Configuring a Layer-2 Static Aggregation Group
Follow these steps to configure a Layer-2 static aggregation group:

Required
Create a Layer-2 aggregate
interface When you create a Layer-2 aggregate
interface and enter the
bridge-aggregation interface, a Layer-2 static aggregation
Layer-2 aggregate interface
interface-number group numbered the same is created
view
automatically.
Enter Layer-2 Ethernet interface interface-type Required
Repeat the two steps to assign multiple
Assign the Ethernet interface port link-aggregation Ethernet interfaces to the aggregation
to the aggregation group group number group.
Configuring a Layer-3 Static Aggregation Group
Follow these steps to configure a Layer-3 static aggregation group:

Required
interface
Create a Layer-3 When you create a Layer-3 aggregate
route-aggregation
aggregate interface interface, a Layer-3 static aggregation group
interface-number
numbered the same is created automatically.
Enter Layer-3 Ethernet interface interface-type
interface view interface-number Required
Assign the Ethernet Repeat the two steps to assign multiple
port link-aggregation Ethernet interfaces to the aggregation group.
interface to the
group number
aggregation group
Note that:
z The following ports cannot be assigned to an aggregation group: fabric ports, RRPP-enabled ports,
interfaces configured as DHCP or BOOTP clients, VRRP-enabled interfaces, MAC address
authentication-enabled ports, port security-enabled ports, portal-enabled ports, packet
filtering-enabled ports, Ethernet frame filtering-enabled ports, IP source guard-enabled ports, and
802.1x-enabled ports.
z You are discouraged to assign reflector ports of port mirroring to an aggregation group. For more
information about reflector ports, refer to Port Mirroring Configuration in the Access Volume.
z You may assign to an aggregation group monitor ports of port mirroring, ports configured with static
MAC addresses, or ports configured with MAC address learning limit depending on your device
model.
z Removing a Layer-2 aggregate interface also removes the corresponding aggregation group. At
the same time, the member ports of the aggregation group, if any, leave the aggregation group.
1-6
z To guarantee a successful static aggregation, ensure that the ports at the two ends of each link to
be aggregated are consistent in the selected/unselected state.
Configuring a Dynamic LACP Aggregation Group
Support for this feature depends on your dive model.
Based on the type of Ethernet interfaces to be aggregated, you can create a Layer-2 or Layer-3
dynamic aggregation group.
Configuring a Layer-2 Dynamic LACP Aggregation Group
Follow these steps to configure a Layer-2 dynamic LACP aggregation group:

Optional
By default, the system LACP priority is 32768.
Set the system LACP lacp system-priority
priority system-priority Changing the system LACP priority may affect
the selected/unselected state of the ports in
the dynamic aggregation group.
Create a Layer-2 Required

interface
aggregate interface and When you create a Layer-2 aggregate
bridge-aggregation
enter the Layer-2 interface, a Layer-2 static aggregation group
interface-number
aggregate interface view numbered the same is created automatically.
Configure the Required
aggregation group to link-aggregation
work in dynamic LACP mode dynamic By default, an aggregation group works in
aggregation mode static aggregation mode.

interface
Enter Layer-2 Ethernet
interface-type
interface view Required
interface-number
Assign the Ethernet port Ethernet interfaces to the aggregation group.
interface to the link-aggregation
aggregation group group number
Optional
By default, the LACP priority of a port is
Assign the port a LACP lacp port-priority 32768.
priority port-priority Changing the LACP priority of a port may
affect the selected/unselected state of the
ports in the dynamic aggregation group.
Configuring a Layer-3 Dynamic LACP Aggregation Group
Follow these steps to configure a Layer-3 dynamic LACP aggregation group:
1-7
Optional
By default, the system LACP priority is
Set the system LACP lacp system-priority 32768.
priority system-priority Changing the system LACP priority may
affect the selected/unselected state of the
ports in the dynamic aggregation group.
Required
Create a Layer-3
interface When you create a Layer-3 aggregate
aggregate interface and
route-aggregation interface, a Layer-3 static aggregation
enter the Layer-3
interface-number group numbered the same is created
aggregate interface view
automatically.
aggregation group to link-aggregation mode
work in dynamic LACP dynamic By default, an aggregation group works in
aggregation mode static aggregation mode.

Enter Layer-3 Ethernet interface interface-type
interface view interface-number Required
Assign the Ethernet Ethernet interfaces to the aggregation
port link-aggregation
interface to the group.
group number
aggregation group
Optional
By default, the LACP priority of a port is
Assign the port a LACP lacp port-priority 32768.
priority port-priority Changing the LACP priority of a port may
affect the selected/unselected state of ports
in the dynamic aggregation group.
Note that:
z The following ports cannot be assigned to an aggregation group: fabric ports, RRPP-enabled ports,
interfaces configured as DHCP or BOOTP clients, VRRP-enabled interfaces, MAC address
authentication-enabled ports, port security-enabled ports, portal-enabled ports, packet
filtering-enabled ports, Ethernet frame filtering-enabled ports, IP source guard-enabled ports, and
802.1x-enabled ports.
z You are discouraged to assign reflector ports of port mirroring to an aggregation group. For more
information about reflector ports, refer to Port Mirroring Configuration in the Access Volume.
z You may assign to an aggregation group monitor ports of port mirroring, ports configured with static
MAC addresses, or ports configured with MAC address learning limit depending on your device
model.
z Removing a dynamic aggregate interface also removes the corresponding aggregation group. At
the same time, the member ports of the aggregation group, if any, leave the aggregation group.
z To guarantee a successful dynamic aggregation, ensure that the peer ports of the ports
aggregated at one end are also aggregated. The two ends can automatically negotiate the selected
state of the ports.
1-8
When a load-sharing aggregation group becomes a non-load-sharing aggregation group because of
insufficient load sharing resources, one of the following problems may occur: the number of selected
ports of the actor is inconsistent with that of the partner, which may result in incorrect traffic forwarding;
the peer port of a selected port is an unselected one, which may result in upper-layer protocol and traffic
forwarding anomalies. You should fully consider the situation when making configuration.
Configuring an Aggregate Interface

You can perform the following configurations for an aggregate interface:
z Configuring the Description of an Aggregate Interface
z Configuring the MTU of a Layer-3 Aggregate Interface/Subinterface
z Enabling LinkUp/LinkDown Trap Generation for an Aggregate Interface
z Shutting Down an Aggregate Interface
Configuring the Description of an Aggregate Interface
Follow these steps to configure the description of an aggregate interface:

Enter Enter Layer-2 aggregate interface bridge-aggregation

aggrega interface view interface-number
te Enter Layer-3 aggregate interface route-aggregation
interfac interface/subinterface { interface-number |
e view view interface-number.subnumber }
Optional
By default, the description
Configure the description of the of an interface is
description text interface-name interface,
aggregate interface
such as
Bridge-Aggregation1
Interface.
Configuring the MTU of a Layer-3 Aggregate Interface/Subinterface
Follow these steps to configure the MTU of a Layer-3 aggregate interface/subinterface:

interface route-aggregation
Enter Layer-3 aggregate
1-9
Configure the MTU of the Optional

mtu size
interface 1500 bytes by default
Enabling LinkUp/LinkDown Trap Generation for an Aggregate Interface
Follow these steps to enable linkUp/linkDown trap generation for an aggregate interface:

Enter Layer-2 aggregate interface bridge-aggregation
Enter interface view interface-number
aggregate
interface route-aggregation
interface Enter Layer-3 aggregate
view { interface-number |
Enable linkUp/linkDown trap generation Optional

enable snmp trap updown
for the aggregate interface Enabled by default
Shutting Down an Aggregate Interface
Shutting down or bringing up an aggregate interface affects the selected state of the ports in the
corresponding aggregation group. Note that an aggregate subinterface does not have an associated
aggregation group. When an aggregate interface is shut down, all selected ports in its aggregation
group become unselected; when the aggregate interface is brought up, the selected state of the ports in
the corresponding aggregation group is re-calculated.
Follow these steps to shut down an aggregate interface:

Enter Layer-2
interface bridge-aggregation
aggregate interface
Enter interface-number
view
aggregate
Enter Layer-3
interface interface route-aggregation
view aggregate
interface/subinterface
view
Required
Shut down the aggregate interface shutdown By default, aggregate
interfaces are up.
You can use the undo shutdown command to bring up an aggregate interface.
1-10
Displaying and Maintaining Link Aggregation
Display the local system ID display lacp system-id Available in any view
display link-aggregation
Display link aggregation details of member-port [ interface-type
ports interface-number [ to interface-type
interface-number ] ]
Display the summary information
display link-aggregation summary Available in any view
of all aggregation groups
display link-aggregation verbose

Display detailed information of [ { bridge-aggregation |
aggregation groups route-aggregation }
[ interface-number ] ]
reset lacp statistics [ interface
Clear the LACP statistics of ports interface-type interface-number [ to Available in user view
interface-type interface-number ] ]
Link Aggregation Configuration Example

Aggregate Ethernet 1/1 through 1/3 of Device A into an aggregate interface to connect to Device B, thus
balancing incoming/outgoing traffic across the member ports.
Network Diagram
Figure 1-1 Network diagram for link aggregation

Eth1/1
Eth1/2
Eth1/3
Eth1/1
Eth1/2
Eth1/3
This configuration example only provides the configuration procedure on Device A. You must perform
the same configuration on Device B for link aggregation to work.
1-11
Configuring a Layer-2 aggregation group if the interfaces in the diagram are Layer-2 Ethernet
interfaces
1) Approach 1: Static aggregation mode

# Create Layer-2 aggregate interface Bridge-aggregation 1.
[DeviceA] interface bridge-aggregation 1
[DeviceA-Bridge-Aggregation1] quit
# Assign Layer-2 Ethernet interfaces Ethernet 1/1 through Ethernet 1/3 to aggregation group 1.
[DeviceA-Ethernet1/1] port link-aggregation group 1
[DeviceA-Ethernet1/1] interface ethernet 1/2
2) Approach 2: Dynamic LACP aggregation mode
# Create a Layer-2 aggregate interface Bridge-Aggregation 1 and configure the interface to work in
dynamic LACP aggregation mode.
[DeviceA] interface bridge-aggregation 1
[DeviceA-Bridge-Aggregation1] link-aggregation mode dynamic
[DeviceA-Bridge-Aggregation1] quit
Configuring a Layer-3 aggregation group if the interfaces in the diagram are Layer-3 Ethernet
interfaces
1) Approach 1: Static aggregation mode

# Create Layer-3 aggregate interface Route-aggregation 1.
[DeviceA] interface route-aggregation 1
[DeviceA-Route-Aggregation1] quit
2) Approach 2: Dynamic LACP aggregation mode
1-12
# Create a Layer-3 aggregate interface Route-Aggregation 1 and configure the interface to work in
dynamic LACP aggregation mode.
[DeviceA] interface route-aggregation 1
[DeviceA-Route-Aggregation1] link-aggregation mode dynamic
[DeviceA-Route-Aggregation1] quit
1-13
Table of Contents
1 Modem Management Configuration 1-1

Overview 1-1
Modem Management Configuration1-1
Setting the Modem Answer Mode 1-2
Issuing an AT Command to a Modem1-3
Modem Management Configuration Example 1-3
Troubleshooting 1-4
i
1 Modem Management Configuration
When configuring a modem, go to these sections for information you are interested in:
z Overview
z Modem Management Configuration
z Modem Management Configuration Example
z Troubleshooting
Overview
Modem is a network device that is widely used. It is important for a device to properly manage and
control the use of modem in a network. However, there are many modem manufacturers and various
modem models. Even though all of them support the AT command set and are compliant with the
industry standard, each type of modem differs somewhat on the implementations and command
details.
The device provides the following functions for managing a modem.
1) Intercommunicate with the equipment from other vendors. The asynchronous serial interfaces of
the participating parties are working in flow mode interconnected via modems.
2) Provide rich debugging information for modem maintenance and monitoring.
Modem Management Configuration

Follow these steps to manage your modem:
user-interface { first-num1
Enter user interface view [ last-num1 ] | { aux | console | tty |
vty } first-num2 [ last-num2 ] }
Required
Enable modem call-in/call-out modem { both | call-in | call-out } Modem call-in and
call-out are denied by
default.
1-1
Set the maximum interval
allowed between picking up the Optional
handset and dialing when a modem timer answer
user tries to establish a 60 seconds by default.
connection
Refer to Setting the Modem Answer Optional

Set modem answer mode
Mode. Not recommended.
Configure modem through AT Refer to Issuing an AT Command to a

Optional
commands Modem.
Optional
Enable modem callback service modem-callback
Setting the Modem Answer Mode
Set the modem answer mode according to the actual answer mode of the modem. When the modem is
in auto-answer mode (A modem is in auto-answer mode if its AA LED lights), you can use the modem
auto-answer command to prevent the device from issuing answer instructions. If the modem is in
non-auto answer mode, you can use the undo modem auto-answer command to enable the device to
issue answer instructions upon the reaching of incoming calls.
If the modem answer mode configured is not consistent with the actual answer mode of the modem, the
modem may operate improperly. So, do not perform the operation unless absolutely needed.
Follow these steps to set modem answer mode:
Enter user interface view [ last-num1 ] | { aux | console | tty |
vty } first-num2 [ last-num2 ] }
Configure the modem to Required

work in auto-answer modem auto-answer Non-auto answer mode by
mode default.
1-2
Issuing an AT Command to a Modem
Follow these steps to issue an AT command to a modem:
Enter interface interface-type

Required
Configure the modem This command is applicable to
by issuing an AT sendat at-string asynchronous serial interfaces (including
command to it synchronous/asynchronous operating in
the asynchronous mode), AUX
interfaces, and AM interfaces.
Modem Management Configuration Example

A device is connected to a Cisco router through its Serial 2/0 interface and two modems. A connection
between the two devices is established through DCC dialup when data is to be transmitted between
them. (For more information about DCC dialup, refer to DCC Configuration in the Access Volume.)
Network diagram
Figure 1-1 Network diagram for managing a modem through a router
1) Configure Router:
[Router-Serial2/0] dialer timer enable 5
[Router-Serial2/0] dialer number 666666
[Router] user-interface tty 1
For information about DCC commands, refer to DCC Commands in the Access Volume.
1-3
2) Configuring the Cisco router
For details, refer to Cisco documentation.
Troubleshooting
Symptom:
Modem is in abnormal status (for example, the dial tone or busy tone keeps humming).
Solution:
z Execute the shutdown command and undo shutdown command on the device physical interface
connected to the modem to check whether the modem has been restored to normal status.
z If the modem is still in abnormal status, you can re-power the modem.
1-4
Table of Contents
1 Port Mirroring Configuration 1-1

Introduction to Port Mirroring 1-2
Classification of Port Mirroring 1-2
Implementing Port Mirroring 1-2
Configuring Local Port Mirroring 1-5
Configuring Remote Port Mirroring 1-6
Configuration Prerequisites 1-6
Configuring a Remote Source Mirroring Group (on Source Device)1-6
Configuring a Remote Destination Mirroring Group (on Destination Device) 1-10
Displaying and Maintaining Port Mirroring 1-12
Port Mirroring Configuration Examples 1-12
Local Port Mirroring Configuration Example1-12
Remote Port Mirroring Configuration Example (Reflector Port Fixed) 1-13
Remote Port Mirroring Configuration Example (Reflector Port Configurable) 1-15
Remote Port Mirroring Configuration Example (with Egress Port)1-17
i

Yes Yes Yes
Yes
You create You create You create
Create a local mirroring You create
up to five up to five up to five
group up to 10 local
Configure local local local
mirroring
local port mirroring mirroring mirroring
groups
mirroring groups groups groups
Configure mirroring ports Yes Yes Yes Yes
Configure monitor ports Yes Yes Yes Yes

Create a remote source
NO NO NO NO
Configure mirroring group
remote port Configure a remote
mirroring destination mirroring NO NO NO NO
group
z Only switching ports support port mirroring.
z The mirroring ports cannot be located on a different board from the monitor port.
z MSR series routers do not support configuring a CPOS interface as a mirroring port.
z MSR series routers support configuring an aggregate port as a monitor port.
z On the switching modules of SIC-4FSW, DSIC-9FSW, and MSR20-21 main control boards, port
mirroring does not support inter-VLAN mirroring. Before configuring a mirroring group, make sure
that all ports in the mirroring group are in the same VLAN. After mirroring group configuration, if a
port is removed from the VLAN, the mirroring function may fail. In this case, you should remove the
mirroring group and configure a new one.
z The fixed Layer-2 switching ports of SIC-4FSW, DSIC-9FSW, and MSR20-21 only support the
both keyword and the outbound keyword for the mirroring-group mirroring-port command. To
monitor inbound traffic, you must specify the both keyword.
1 Port Mirroring Configuration
When configuring port mirroring, go to these sections for information you are interested in:
z Introduction to Port Mirroring
z Configuring Local Port Mirroring
1-1
z Configuring Remote Port Mirroring
z Displaying and Maintaining Port Mirroring
z Port Mirroring Configuration Examples
Introduction to Port Mirroring

Port mirroring is to copy the packets passing through a port (called a mirroring port) to another port
(called the monitor port) connected with a monitoring device for packet analysis.
You can select to port-mirror inbound, outbound, or bidirectional traffic on a port as needed.
Classification of Port Mirroring
Port mirroring can be local or remote.

z In local port mirroring, the mirroring port or ports and the monitor port are located on the same
device.
z In remote port mirroring, the mirroring port or ports and the monitor port can be located on the
same device or different devices. Currently, remote port mirroring can be implemented only at
Layer 2.
As a monitor port can monitor multiple ports, it may receive multiple duplicates of a packet in some
cases. Suppose that port P 1 is monitoring bidirectional traffic on ports P 2 and P 3 on the same device.
If a packet travels from P 2 to P 3, two duplicates of the packet will be received on P 1.
z Support for these two types of port mirroring depends on your device model.
z The packets mirrored to the monitor port may be VLAN tagged depending on your device model.
Implementing Port Mirroring
Port mirroring is implemented through port mirroring groups. There are three types of mirroring groups:
local, remote source, and remote destination.
Support for port mirroring groups and the allowed maximum number of mirroring groups of each type
vary with devices.
The following subsections describe how local port mirroring and remote port mirroring are
implemented.
1-2
Local port mirroring
In local port mirroring, all packets passing through a port can be mirrored. Local port mirroring is
implemented through a local mirroring group.
As shown in Figure 1-1, packets on the mirroring port are mirrored to the monitor port for the data
monitoring device to analyze.
Figure 1-1 Local port mirroring implementation
The mirroring ports in a local mirroring group can be located on different boards on the same device,
depending on your device model.
Remote port mirroring
Remote port mirroring can mirror all packets but protocol packets.
Remote port mirroring is implemented through the cooperation of a remote source mirroring group and
a remote destination mirroring group as shown in Figure 1-2 and Figure 1-3.
1-3
Figure 1-2 Remote port mirroring implementation (with a reflector port)
Figure 1-3 Remote port mirroring implementation (with an egress port)
Remote mirroring involves the following device roles:

z Source device
The source device is the device where the mirroring ports are located. On it, you must create a remote
source mirroring group to hold the mirroring ports.
The source device copies the packets passing through the mirroring ports, broadcasts the packets in
the remote probe VLAN for remote mirroring, and transmits the packets to the next device, which could
be an intermediate device (if any) or the destination device.
z Intermediate device
Intermediate devices are devices located in between the source device and the destination device.
An intermediate device forwards mirrored packets to the next intermediate device (if any) or the
destination device.
You must ensure that the source device and the destination device can communicate at Layer 2 in the
remote probe VLAN.
z Destination device
The destination device is the device where the monitor port is located. On it, you must create the
remote destination mirroring group.
1-4
When receiving a packet, the destination device compares the VLAN ID carried in the packet with the
ID of the probe VLAN configured in the remote destination mirroring group. If they are the same, the
device forwards the packet to the monitoring device through the monitor port.
z For the mirrored packets to be forwarded to the monitor port, ensure that the same probe VLAN is
configured in the remote source and destination mirroring groups.
z If you will monitor both the received packets and sent packets of a port in a mirroring group, you
must perform some special configurations on the intermediate devices. The configurations on an
intermediate device vary by device model.
Configuring Local Port Mirroring

Configuring local port mirroring is to configure local mirroring groups.
A local mirroring group comprises one or multiple mirroring ports and one monitor port. These ports
must not have been assigned to any other mirroring group.
Follow these steps to configure a local mirroring group:

Create a local mirroring group mirroring-group groupid local Required

mirroring-group groupid Required
In system view mirroring-port mirroring-port-list Use either approach.
{ both | inbound | outbound }
In system view, you can
interface interface-type assign a list of ports to the
interface-number mirroring group at a time.
Or In interface view, you can
controller cpos assign only the current port to
Configure interface-number the mirroring group. To
mirroring monitor multiple ports, repeat
ports [ mirroring-group groupid ] the step.
In interface view mirroring-port { both | inbound The inbound, outbound, and
| outbound } both keywords are available
depending on the device
model.
You can assign a CPOS
quit interface to a mirroring group
as a mirroring port depending
on your device model.
mirroring-group groupid
In system view
monitor-port monitor-port-id
Configure
the interface interface-type Required
monitor interface-number Use either approach.
port In interface view
[ mirroring-group groupid ]
monitor-port
1-5
z Depending on the device model, you can assign these types of ports to a local mirroring group as
mirroring ports: Layer 2 Ethernet, Layer 3 Ethernet, POS, CPOS, serial, and MP-group.
z Depending on the device model, you can configure these types of ports as the monitor port: Layer
2 Ethernet, Layer 3 Ethernet, and tunnel.
z To ensure operation of your device, do not enable STP, MSTP, or RSTP on the monitor port.
z On some types of devices, you can configure a member port in link aggregation as the monitor
port.
Configuring Remote Port Mirroring
Support for this feature depends on the device model.
Configuring remote port mirroring is to configure remote mirroring groups. When doing that, configure
the remote source mirroring group on the source device and the cooperating remote destination
mirroring group on the destination device.
If GVRP is enabled, GVRP may register the remote probe VLAN to unexpected ports, resulting in
undesired duplicates. For information on GVRP, refer to GVRP Configuration in the Access Volume.
Configuration Prerequisites
Create a static VLAN for the probe VLAN on the source and destination device. To ensure correct
packet handling, ensure that the VLANs you created on the two devices use the same ID and function
only for remote port mirroring.
Configuring a Remote Source Mirroring Group (on Source Device)
A remote source mirroring group comprises the following:

z One or multiple mirroring ports.
z A remote probe VLAN.
z A reflector or egress port, depending on the device model. In addition, you do not need to configure
the reflector port on devices that use a fixed port as the reflector port.
After you assign a port to a mirroring group either as a mirroring port or as a monitor port, you cannot
assign it to any other mirroring group. The same is true of probe VLANs.
1-6
The configuration procedure differs depending on the support of your device for the reflector port and
the egress port. Follow one of the procedures described in the following subsections depending on your
device model.
Configuring a remote source mirroring group with the reflector port fixed
Follow these steps to configure a remote source mirroring group with the reflector port fixed:

Create a remote source mirroring-group groupid
Required
mirroring group remote-source
In system view mirroring-port mirroring-port-list
Required
Use either approach.
interface-number
assign a list of ports to the
In interface [ mirroring-group groupid ] mirroring group at a time.
Configure view mirroring-port { both | inbound | In interface view, you can
mirroring outbound } assign only the current
ports interface to the mirroring
quit group. To monitor multiple
interface interface-type ports, repeat the step.
interface-number The inbound, outbound,
In interface and both keywords are
mirroring-group groupid available depending on
view
reflector-port the device model.
quit
Configure the remote probe mirroring-group groupid
Required
VLAN remote-probe vlan rprobe-vlan-id
z The mirroring ports can be Layer 2 Ethernet ports or Layer 3 Ethernet interfaces depending on the
device model.
z To ensure device performance, do not assign mirroring ports to the remote probe VLAN.
z To remove the VLAN configured as a remote probe VLAN, you must remove the remote probe
VLAN with the undo mirroring-group remote-probe vlan command first. Removing the probe
VLAN can invalidate the remote source mirroring group.
Configuring a remote source mirroring group with the reflector port configurable
Follow these steps to configure a remote port mirroring group with the reflector port configurable:
1-7
Required
Configure In interface view, you can
mirroring mirroring-port { both | inbound | assign only the current
ports interface to the mirroring
In interface outbound }
group. To monitor multiple
view
ports, repeat the step.
The inbound, outbound,
quit and both keywords are
available depending on the
device model.
In system view
reflector-port reflector-port-id
Configure interface interface-type

interface-number Required
the reflector
port In interface Use either approach.
view
reflector-port
quit
Configure the remote probe mirroring-group groupid
Required
VLAN remote-probe vlan rprobe-vlan-id
When configuring the mirroring ports, note that:

z The mirroring ports and the reflector port must be located on the same device.
z The mirroring ports can be Layer 2 Ethernet ports or Layer 3 Ethernet interfaces, depending on the
device model.
z To ensure device performance, do not assign the mirroring ports to the remote probe VLAN.
1-8
When configuring the reflector port, note that:
z The port must not be a mirroring port in the mirroring group or a monitor port for traffic mirroring.
z The port must be an access port that belongs to the default VLAN. The port can be a member port
in link aggregation depends on the device model.
z Do not configure QinQ, port loopback, and service loop on the port.
z On some device models, you can configure a port as a reflector port only when the port is
operating with the default duplex mode, port rate, and MDI setting. In addition, you cannot change
these settings after the port is configured as a reflector port.
z To ensure operation of the device, do not connect a cable to the port, and disable these functions
on the port: STP, MSTP, RSTP, 802.1x, IGMP Snooping, static ARP, and MAC address learning.
To remove the VLAN configured as a remote probe VLAN, you must remove the remote probe VLAN
with undo mirroring-group remote-probe vlan command first. Removing the probe VLAN can
invalidate the remote source mirroring group.
Configuring a remote source mirroring group with an egress port
Follow these steps to configure a remote port mirroring group with an egress port:

Required
Configure In interface view, you can
mirroring mirroring-port { both | inbound | assign only the current
ports outbound } interface to the mirroring
In interface
group. To monitor multiple
view
ports, repeat the step.
The inbound, outbound,
quit and both keywords are
available depending on the
device model.
1-9
In system view monitor-egress
monitor-egress-port-id
Configure interface interface-type Required
the egress interface-number
port Use either approach.
In interface
view
monitor-egress
quit
Configure the probe VLAN Required
remote-probe vlan rprobe-vlan-id
When configuring the mirroring ports, note that:

z The mirroring ports and the egress port must be located on the same device.
z The mirroring ports can be Layer 2 Ethernet ports or Layer 3 Ethernet interfaces, depending on the
device model.
z To ensure device performance, do not assign the mirroring ports to the remote probe VLAN.
When configuring the egress port, note that:

z The port must not be a mirroring port in the mirroring group.
z The port can be a member port in link aggregation depends on the device model.
z To ensure operation of the device, disable these functions on the port: STP, MSTP, RSTP, 802.1x,
IGMP Snooping, static ARP, and MAC address learning.
To remove the VLAN configured as a remote probe VLAN, you must remove the remote probe VLAN
with undo mirroring-group remote-probe vlan command first. Removing the probe VLAN can
invalidate the remote source mirroring group.
Configuring a Remote Destination Mirroring Group (on Destination Device)
A remote destination mirroring group comprises a remote probe VLAN and a monitor port.
1-10
Follow these steps to configure a remote destination port mirroring group:

Create a remote destination mirroring-group groupid

Required
mirroring group remote-destination
Configure the remote probe mirroring-group groupid remote-probe
Required
VLAN vlan rprobe-vlan-id
mirroring-group groupid monitor-port
In system view
monitor-port-id
Configure Required
the monitor interface interface-type interface-number
Use either
port In interface view [ mirroring-group groupid ] monitor-port approach.
quit
Enter the interface view of the
monitor port
For an access Required
port access vlan rprobe-vlan-id
port Use one of the
Assign the
port to the For a trunk port port trunk permit vlan rprobe-vlan-id commands
probe VLAN depending on the
For a hybrid port hybrid vlan rprobe-vlan-id { tagged | link type of the
port untagged } monitor port.
When configuring the probe VLAN, use the following guidelines:

z A VLAN can be the remote probe VLAN of only one port mirroring group.
z To remove the VLAN configured as the remote probe VLAN, you must remove the remote probe
VLAN with undo mirroring-group remote-probe vlan command first. Removing the probe VLAN
can invalidate the remote source mirroring group.
When configuring the monitor port, use the following guidelines:

z The port can belong to only the current mirroring group.
z The port can be a Layer 2 or Layer 3 Ethernet port depending on your device model.
z Disable these functions on the port: STP, MSTP, and RSTP.
z The port can be a member port in link aggregation depends on the device model.
1-11
Displaying and Maintaining Port Mirroring
display mirroring-group { groupid | all |
Display the configuration of port
local | remote-destination | Available in any view
mirroring groups
remote-source }
Port Mirroring Configuration Examples

Local Port Mirroring Configuration Example
On a network shown in Figure 1-4,

z Department 1 is connected to port Ethernet 1/1 of Device C through Device A.
z Department 2 is connected to port Ethernet 1/2 of Device C through Device B.
z The Server is connected to port Ethernet 1/3 of Device C.
To monitor the bidirectional traffic of Department 1 and Department 2 on the Server, configure a local
port mirroring group on Device C as follows:
z Configure port Ethernet 1/1 and Ethernet 1/2 as mirroring ports.
z Configure port Ethernet 1/3 as the monitor port.
Network diagram
Figure 1-4 Network diagram for local port mirroring configuration
1) Configure Device C
# Enter system view.
<DeviceC> system-view
# Create a local mirroring group.

[DeviceC] mirroring-group 1 local
# Configure ports Ethernet 1/1 and Ethernet 1/2 as mirroring ports and port Ethernet 1/3 as the monitor
port in the mirroring group.
[DeviceC] mirroring-group 1 mirroring-port ethernet 1/1 ethernet 1/2 both
1-12
[DeviceC] mirroring-group 1 monitor-port ethernet 1/3
# Display the configuration of all port mirroring groups.

[DeviceC] display mirroring-group all
mirroring-group 1:
type: local
status: active
mirroring port:
Ethernet1/1 both
Ethernet1/2 both
monitor port: Ethernet1/3
After finishing the configuration, you can monitor all the packets received and sent by Department 1 and
Department 2 on the Server.
Remote Port Mirroring Configuration Example (Reflector Port Fixed)
On a network shown in Figure 1-5,

z Department 1 is connected to port Ethernet 1/1 of Device A.
z The trunk port Ethernet 1/3 on Device A connects to the trunk port Ethernet 1/1 on Device B.
z The trunk port Ethernet 1/2 on Device B connects to the trunk port Ethernet 1/1 on Device C.
z The Server is connected to port Ethernet 1/2 of Device C.
To monitor the inbound/outbound packets of Department 1 and Department 2 on the Server, configure
a pair of remote source/destination mirroring groups as follows:
z On Device A, create a remote source mirroring group. For the mirroring group, configure VLAN 2
as the remote probe VLAN and ports Ethernet 1/1 and Ethernet 1/2 as mirroring ports.
z Configure port Ethernet 1/3 of Device A, ports Ethernet 1/1 and Ethernet 1/2 of Device B, and port
Ethernet 1/1 of Switch C as trunk ports that permit the packets of VLAN 2 to pass through.
z Create a remote destination mirroring group on Device C. Configure VLAN 2 as the remote probe
VLAN and port Ethernet 1/2, to which the server is connected, as the monitor port.
Network diagram
Figure 1-5 Network diagram for remote port mirroring configuration
Source device Intermediate device Destination device

Device A Device B Device C
Eth1/3 Eth1/1 Eth1/2 Eth1/1
Eth1/1 Eth1/2 Eth1/2
Department 1 Department 2
Server
1-13
1) Configure Device A (the source device)

# Create a remote source port mirroring group.

[DeviceA] mirroring-group 1 remote-source
# Create VLAN 2.
[DeviceA] vlan 2
[DeviceA-vlan2] quit
# Configure VLAN 2 as the remote probe VLAN and ports Ethernet 1/1 and Ethernet 1/2 as mirroring
ports in the mirroring group.
[DeviceA] mirroring-group 1 remote-probe vlan 2
[DeviceA] mirroring-group 1 mirroring-port ethernet 1/1 ethernet 1/2 both
# Configure port Ethernet 1/3 as a trunk port that permits the packets of VLAN 2 to pass through.
[DeviceA-Ethernet1/3] port trunk permit vlan 2
2) Configure Device B (the intermediate device)
[DeviceB-Ethernet1/1] port trunk permit vlan 2
[DeviceB-Ethernet1/1] interface ethernet 1/2
3) Configure Device C (the destination device)
[DeviceC] interface ethernet 1/1
[DeviceC-Ethernet1/1] port link-type trunk
[DeviceC-Ethernet1/1] port trunk permit vlan 2
[DeviceC-Ethernet1/1] quit
# Create a remote destination mirroring group.

[DeviceC] mirroring-group 1 remote-destination
# Create VLAN 2.
[DeviceC] vlan 2
[DeviceC-vlan2] quit
1-14
# Configure VLAN 2 as the remote probe VLAN and port Ethernet 1/2 as the monitor port in the
mirroring group.
[DeviceC] mirroring-group 1 remote-probe vlan 2
[DeviceC-Ethernet1/2] mirroring-group 1 monitor-port
[DeviceC-Ethernet1/2] port access vlan 2
Remote Port Mirroring Configuration Example (Reflector Port Configurable)
On the network shown in Figure 1-6,

z The trunk port Ethernet 1/3 on Device A connects to the trunk port Ethernet 1/1 on Device B.
z The Server connects to port Ethernet 1/2 on Device C.
remote port mirroring as follows:
z On Device A, create a remote source mirroring group. For the mirroring group, configure VLAN 2
as the remote probe VLAN, ports Ethernet 1/1 and Ethernet 1/2 as mirroring ports, and port
Ethernet 1/0 as the reflector port.
z Configure port Ethernet 1/3 on Device A, ports Ethernet 1/1 and Ethernet 1/2 on Device B, and port
Ethernet 1/1 on Device C as trunk ports that permit the packets of VLAN 2 to pass through.
Network diagram

Source device Intermediate device Destination device
Reflector port Device A Device B Device C
Eth1/0
Eth1/3 Eth1/1 Eth1/2 Eth1/1
Department 1 Department 2
Server

1-15
# Create a remote source mirroring group.
# Create VLAN 2.
[DeviceA] vlan 2
# Configure VLAN 2 as the remote probe VLAN, ports Ethernet 1/1 and Ethernet1/2 as mirroring ports,
and port Ethernet 1/0 as the reflector port in the mirroring group.
[DeviceA] mirroring-group 1 reflector-port Ethernet ethernet 1/0

# Create VLAN 2.
[DeviceC] vlan 2
# Configure VLAN 2 as the remote probe VLAN of the mirroring group. Assign port Ethernet 1/2 to the
mirroring group as the monitor port.
1-16
Remote Port Mirroring Configuration Example (with Egress Port)
On the network shown in Figure 1-7,

z The trunk port Ethernet 1/3 on Device A connects to the trunk port Ethernet1/1 on Device B.
z The Server connects to port Ethernet 1/2 on Device C.
remote port mirroring as follows:
z On Device A, create a remote source mirroring group, use VLAN 2 as the remote probe VLAN,
configure ports Ethernet 1/1 and Ethernet 1/2 as mirroring ports, and configure port Ethernet 1/3 as
the egress port.
z Configure port Ethernet1/3 on Device A, ports Ethernet 1/1 and Ethernet 1/2 on Device B, and port
Ethernet 1/1 on Device C as trunk ports and configure them to permit the packets of VLAN 2 to
pass through.
Network diagram

# Create a remote source mirroring group.

1-17
# Create VLAN 2.
[DeviceA] vlan 2
# Configure VLAN 2 as the remote probe VLAN of the mirroring group. Configure ports Ethernet 1/1
and Ethernet 1/2 as mirroring ports and port Ethernet 1/3 as the egress port in the mirroring group.
[DeviceA] mirroring-group 1 monitor-egress ethernet 1/3

# Create VLAN 2.
[DeviceC] vlan 2
# Configure VLAN 2 as the remote probe VLAN of the mirroring group. Assign port Ethernet 1/2 to the
mirroring group as the monitor port.
1-18
1-19
Table of Contents
1 PPP and MP Configuration 1-1

Introduction to PPP and MP1-1
PPP1-1
MP 1-4
Configuring PPP1-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 Negotiation1-8
Enabling PPP Link Quality Control1-11
Enabling the Generating of PPP Accounting Statistics 1-12
Configuring MP 1-12
Configuring MP Using a VT Interface1-12
Configuring an MP through an MP-group1-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 EAD1-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 Example1-22
MP Binding Mode Configuration Examples1-24
L2TP-Based EAD Configuration Example 1-32
Network Diagram1-33
Troubleshooting PPP Configuration1-34
2 PPPoE Configuration 2-1

Introduction to PPPoE2-1
Configuring a PPPoE Server 2-2
Configuring a PPPoE Client2-3
Introduction2-3
Resetting/Terminating a PPPoE Session2-4
Displaying and Maintaining PPPoE 2-5
PPPoE Configuration Examples 2-5
PPPoE Server Configuration Example2-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
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
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
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
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
[RouterA] local-user user2
[RouterA-luser-user2] service-type ppp
[RouterA-luser-user2] password simple pass2
[RouterA-luser-user2] quit
[RouterA-Serial2/0] ppp authentication-mode pap domain system
[RouterA-Serial2/0] ip address 200.1.1.1 16
[RouterA] domain system
[RouterA-isp-system] authentication ppp local
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-luser-user1] password simple hello
[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
[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
# 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.

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

# Add interfaces Serial 2/0:1 and Serial 2/0/:2 to the MP channel, taking Serial 2/0:1 as an example.
[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
1-23
# Create a user account for Router A.
[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.

# 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
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

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

[RouterA] interface serial2/0
[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

# Configure the users in the domain to use local authentication scheme.

[RouterB-isp-system] authentication ppp local
# 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
1-26

0.00% packet loss
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
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
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

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
# 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] 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-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
Set the maximum number of Optional
pppoe-server max-sessions
PPPoE sessions allowed with
remote-mac number 100 by default
regard to a peer MAC address
2-2
PPPoE sessions allowed with pppoe-server max-sessions Optional
regard to the local MAC local-mac number 100 by default
address
Optional
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-Ethernet1/0] pppoe-server bind virtual-template 1
2) Configure Router B as the PPPoE client.
[RouterB-Dialer1] dialer user user2
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] ppp pap local-user user2 password simple hello
# Configure the PPPoE session.

[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-Dialer1] dialer user user2
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] ppp chap user user2
[RouterB-luser-user1] password simple hello
# Configure the PPPoE session.

[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-Dialer1] ip address ppp-negotiate
[RouterA-Dialer1] ppp pap local-user user1 password cipher 123456
# Configure a PPPoE session.

[RouterA-Ethernet2/0] pppoe-client dial-bundle-number 1
# Configure an Internet interface for the LAN and configure the default route.
[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
# 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] 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-Serial2/0] standby interface dialer 1
# 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-Dialer1] dialer user mypppoe
[Router-Dialer1] dialer bundle 1
# 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 Bridging Configuration 1-1

Bridging Overview 1-1
Introduction to Bridging1-1
Major Functionalities of Bridges 1-2
Bridging Configuration Task List 1-6
Configuring Basic Bridging Functionalities1-6
Configuring Bridge Table Entries 1-7
Configuring Bridge Routing1-8
Configuring VLAN ID Transparent Transmission1-9
Displaying and Maintaining Bridging Configurations 1-10
Transparent Bridging Configuration Examples 1-10
Transparent Bridging over ATM 1-10
Transparent Bridging over PPP1-11
Transparent Bridging over MP 1-12
Transparent Bridging over FR 1-13
Transparent Bridging over X.25 1-14
Transparent Bridging over HDLC 1-15
Bridging with FR Sub-Interface Support1-15
Bridge Routing1-17
Bridging over Dialer Interface1-18
VLAN ID Transparent Transmission Configuration Example 1-19
i
z The MSR series routers do not support inter-VLAN transparent bridging.
z The MSR series routers support VLAN ID transparent transmission across Ethernet.
1 Bridging Configuration
When configuring bridging functionalities, go to the following sections for the information you are
interested in:
z Bridging Overview
z Bridging Configuration Task List
z Configuring Basic Bridging Functionalities
z Configuring Bridge Table Entries
z Configuring Bridge Routing
z Configuring VLAN ID Transparent Transmission
z Displaying and Maintaining Bridging Configurations
z Transparent Bridging Configuration Examples
Presently the devices support only transparent bridging, so this document provides information about
transparent bridging only.
Bridging Overview
Introduction to Bridging
A bridge is a store-and-forward device that connects and transfers traffic between local area network
(LAN) segments at the data-link layer. In some small-sized networks, especially those with dispersed
distribution of users, the use of bridges can reduce the network maintenance costs, without requiring
the end users to perform special configurations on the devices.
In applications, there are four major kinds of bridging technologies: transparent bridging, source-route
bridging (SRB), translational bridging, and source-route translational bridging (SR/TLB).
1-1
Transparent bridging is used to bridge LAN segments of the same physical media type, primarily in
Ethernet environments. Typically, a transparent bridging device keeps a bridge table, which contains
mappings between destination MAC addresses and outbound interfaces.
Presently the devices support the following transparent bridging features:
z Bridging over Ethernet
z Bridging over point-to-point (PPP) and high-level data link control (HDLC) links
z Bridging over X.25 links
z Bridging over frame relay (FR) links
z Inter-VLAN transparent bridging
z Routing and bridging are simultaneously supported
Major Functionalities of Bridges
Obtaining the bridge table
A bridge relies on its bridge table to forward data. A bridge table consists of two parts: MAC address list
and interface list. Once connected to a physical LAN segment, a bridge listens to all Ethernet frames on
the segments. When it receives an Ethernet frame, it extracts the source MAC address of the frame and
creates a mapping entry between this MAC address and the interface on which the Ethernet frame was
received.
As shown in Figure 1-1, Hosts A, B, C and D are attached to two LAN segments. Host A is connected
with bridge interface 1, while Host B is connected with bridge interface 2. When Host A sends an
Ethernet frame to Host B, both bridge interface 1 and Host B receive this frame.
Figure 1-1 Host A sends an Ethernet frame to Host B on LAN segment 1
MAC address: 00e0.fcbb.bbbb
MAC address: 00e0.fcaa.aaaa
Host A Host B
Source address Destination address

00e0.fcaa.aaaa 00e0. fcbb.bbbb
LAN segment 1
Bridge interface 1
Bridge
Bridge interface 2
LAN segment 2
Host C Host D
MAC address: 00e0.fccc.cccc MAC address: 00e0.fcdd.dddd
As the bridge receives the Ethernet frame on bridge interface 1, it determines that Host A is attached to
bridge interface 1 and creates a mapping between the MAC address of Host A and bridge interface 1 in
its bridge table, as shown in Figure 1-2.
1-2
Figure 1-2 The bridge determines that Host A is attached to interface 1
When Host B responds to Host B, the bridge also hears the Ethernet frame from Host B. As the frame is
received on bridge interface 1, the bridge determines that Host B is also attached to bridge interface 1,
and creates a mapping between the MAC address of Host B and bridge interface 1 in its bridge table, as
shown in Figure 1-3.
Figure 1-3 The bridge determines that Host B is also attached to interface 1
Finally, the bridge obtains all the MAC-interface mappings (assume that all hosts are in use), as shown
in Figure 1-4.
1-3
Figure 1-4 The final bridge table
MAC address: 00e0.fcaa.aaaa MAC address: 00e0.fcbb.bbbb
Host A Host B
Bridge table LAN segment 1

MAC address Interface Bridge interface 1
00e0.fcaa.aaaa 1
Bridge
00e0.fcbb.bbbb 1
00e0.fccc.cccc 2 Bridge interface 2
00e0.fcdd.dddd 2
LAN segment 2
Host C Host D
MAC address: 00e0.fccc.cccc MAC address: 00e0.fcdd.dddd
Forwarding and filtering
The bridge makes data forwarding or filtering decisions based on the following scenarios:
z When Host A sends an Ethernet frame to Host C, the bridge searches its bridge table and finds out
that Host C is attached to bridge interface 2, and forwards the Ethernet frame out of bridge
interface 2, as shown in Figure 1-5.
Figure 1-5 Forwarding
z When Host A sends an Ethernet frame to Host B, as Host B is on the same LAN segment as Host
A, the bridge filters the Ethernet frame instead of forwarding it, as shown in Figure 1-6.
1-4
Figure 1-6 Filtering
z When Host A sends an Ethernet frame to Host C, if the bridge does not find a MAC-to-interface
mapping about Host C in its bridge table, the bridge forwards the Ethernet frame to all interfaces
except the interface on which the frame was received, as shown in Figure 1-7.
Figure 1-7 The proper MAC-to-interface mapping is not found in the bridge table
When a bridge receives a broadcast or multicast frame, it forwards the frame to all interfaces other than
the receiving interface.
1-5
Bridging Configuration Task List
Complete these tasks to configure bridging:
Tasks Remarks
Configuring Basic Bridging Functionalities Required
Configuring Bridge Table Entries Optional
Configuring Bridge Routing Optional
Configuring Basic Bridging Functionalities
z When configuring transparent bridging over ATM, you need to enable transmission and receiving
of bridged frames on the PVC.
z When configuring transparent bridging over PPP, you need to configure PPP on the corresponding
interface as the link layer protocol for interface encapsulation.
z When configuring transparent bridging over multilink PPP (MP), you need to configure PPP on the
corresponding interface as the link layer protocol for interface encapsulation, create a virtual
template interface and associate the physical interface with the virtual template interface.
z When configuring transparent bridging over FR, you need to configure FR on the corresponding
interface as the link layer protocol for interface encapsulation, configure the FR interface type
(optional, DTE by default) and configure a virtual circuit. When establishing transparent bridging
over FR, you need to configure mappings between bridge addresses and data link connection
identifier (DLCI) addresses.
z When configuring transparent bridging over X.25, you need to configure X.25 on the corresponding
interface as the link layer protocol for interface encapsulation and configure the work mode and
datagram format of the interface. When establishing transparent bridging over X.25, you need to
configure mappings between bridge addresses and X.25 addresses defined in X.121.
z When configuring transparent bridging HDLC, you need to configure HDLC as the link layer
protocol for interface encapsulation.
z When configuring inter-VLAN transparent bridging, you need to configure the encapsulation format
of the Ethernet sub-interfaces and the corresponding VLAN IDs. When establishing inter-VLAN
transparent bridging, you need to add the configured Ethernet sub-interfaces into a bridge set.
Follow these steps to configure basic bridging functionalities:

Required
Enable bridging bridge enable
Disabled by default
Required
Enable a bridge set bridge bridge-set enable No bridge set is enabled by
default.
1-6
interface-number
Add the current Required

interface into a bridge bridge-set bridge-set An interface is not in any bridge
set set by default.
Configure an Required for transparent bridging
fr map bridge dlci broadcast
FR-to-bridging mapping over FR
Configure an X.25 to x25 map bridge x121-address Required for transparent bridging
bridging mapping x.121-address broadcast over X.25
interface atm { interface-number | Required for transparent bridging
interface-number.subnumber } over ATM
Enable bridged traffic pvc { pvc-name [ vpi/vci ] | vpi/vci } If you configure both the map
over a PVC bridge virtual-ethernet and map
bridge-group commands, only
map bridge-group broadcast the map bridge virtual-ethernet
takes effect.
For more information about ATM configuration, refer to ATM Configuration and ATM Commands in the
Access Volume.
Configuring Bridge Table Entries

Typically, a bridge dynamically creates and maintains a bridge table based on the correlations between
the MAC addresses it has learned and the corresponding interfaces. The administrator, however, can
manually configure some bridge table entries, which will never get aged out.
The aging time of a dynamic bridge table entry refers to the lifetime of the entry before it is deleted from
the table. When the aging timer of a dynamic table entry expires, the system deletes the entry from the
table.
Follow these steps to configure a bridge table:

Enable dynamic address Optional

bridge bridge-set learning
learning Enabled by default
bridge bridge-set
mac-address mac-address Optional
Configure a static bridge table
{ deny | permit } [ dlsw | No static table entry is
entry
interface interface-type configured by default.
interface-number ]
Configure aging time of Optional

bridge aging-time seconds
dynamic bridge table entries 300 seconds by default
Shut down the bridge-template Optional

shutdown
interface Enabled by default
1-7
Configuring Bridge Routing
Bridge routing provides a forwarding capability that combines bridging and routing. When data of a
given protocol is exchanged between bridge interfaces, bridging occurs; when data of a given protocol
is exchanged between a bridge set and a non-bridge-set network, the protocol can be routed. Before
the built-in routing and bridging functionalities are activated, all protocol data can only be bridged. With
the built-in routing and bridging functionalities activated, datagrams of the specified protocol can be
either bridged or routed, and switching between bridging and routing can be implemented flexibly
through configuration commands.
A bridge-template interface is a virtual route-selecting interface, on which various network layer
properties can be configured. By configuring a bridge-template interface, you can connect the
corresponding bridge set to a routed network. A bridge set can have only one bridge-template interface.
The number of a bridge-template interface is the number of the bridge set it represents.
By default, if a bridge set contains Ethernet interfaces, its bridge-template interface will use the MAC
address of a random Ethernet interface. If the bridge set contains no Ethernet interfaces, its
bridge-template interface will use the system default MAC address, of which the first 5 bytes depend on
the device model and the last byte is the number of the bridge set.
If bridge sets by the same bridge set number are enabled on two or more devices, and a
bridge-template interface is created for each of these bridge sets while no Ethernet interfaces have
been added into these bridge sets, these bridge-template interfaces will use exactly the same default
MAC address. This will cause MAC address conflict. To avoid this situation, you can configure different
MAC addresses for different bridge-template interfaces.
Follow these steps to configure bridge routing:

Required
Enable bridge routing bridge routing-enable
Disabled by default
Create a bridge-template interface Required

interface and enter bridge-template No bridge-template interface
bridge-template interface view bridge-set configured by default
Optional
By default:
z If some Ethernet interfaces have
joined the bridge set corresponding
to the bridge-template interface, the
Configure a MAC address for mac-address bridge-template interface borrows
the bridge-template interface mac-address the MAC address of a random
Ethernet interface in the bridge set.
z If no Ethernet interface has joined
the bridge set corresponding to the
bridge-template interface, the
bridge-template interface uses the
system default MAC address.
1-8
Configure Optional
Configure bridge bridge-set
routing or By default, routing of all network layer
routing routing { ip | ipx }
bridging of the protocols is disabled.
specified
network layer bridge bridge-set Optional
protocol(s) on Configure
bridging { ip | ipx | By default, bridging of all network layer
a bridge set bridging
others } protocols is enabled.
Configuring VLAN ID Transparent Transmission

When trunk interfaces at both ends are connected over Ethernet, devices with VLAN ID transparent
transmission configured in Ethernet will leave the VLAN ID of packets transmitted intact. This is similar
to connecting trunk interfaces of two devices, and thus avoids dropping the VLAN IDs if VLAN ID
transmission is not supported while packets are being transmitted.
Follow these steps to configure VLAN ID transparent-transmission:

Required
Enable bridging bridge enable
Disabled by default
Required
Enable a bridge-set bridge bridge-set enable
Disabled by default
interface-number
Required
Add the interface to the
bridge-set bridge-set No interface is added to any
bridge-set
bridge-set by default.
Configure VLAN ID Required
bridge vlanid-transparent-transmit
transparent
enable Disabled by default
transmission
z It is not recommend to configure VLAN ID transparent transmission on a sub-interface.

z This function is not applicable to DLSw.
z Before configuring VLAN ID transparent transmission on an interface, you must add the interface to
a bridge-set.
1-9
Displaying and Maintaining Bridging Configurations
display bridge information [ bridge-set Available in any
View bridge set information
bridge-set ] view
View the statistics information
display interface bridge-template Available in any
of a virtual bridge-template
[interface-number] view
interface
display bridge address-table [ bridge-set
bridge-set | dlsw | interface interface-type Available in any
View bridge table information
interface-number | mac mac-address] view
[ dynamic | static ]
display bridge traffic [ bridge-set
View the statistics information Available in any
bridge-set | dlsw | interface interface-type
of bridged traffic view
interface-number ]
reset bridge address-table [ bridge-set
Available in user
Clear bridge table entries bridge-set | dlsw | interface interface-type
view
interface-number ]
reset bridge traffic [ bridge-set bridge-set
Clear the statistics information Available in user
| dlsw | interface interface-type
of bridged traffic view
interface-number ]
Transparent Bridging Configuration Examples

Transparent Bridging over ATM
As shown in Figure 1-8, two LAN segments LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected through their respective ATM interfaces. Configure the two
routers to enable transparent bridging over ATM between the two LAN segments.
Network diagram
Figure 1-8 Network diagram for transparent bridging over ATM configuration
[RouterA-Ethernet1/0] interface atm 5/0
1-10
[RouterA-Atm5/0] pvc 32/50
[RouterA-atm-pvc-Atm5/0-32/50] map bridge-group broadcast
[RouterA-atm-pvc-Atm5/0-32/50] quit
[RouterA-Atm5/0] bridge-set 1
[RouterB ]bridge 1 enable
[RouterB-Ethernet1/0] interface atm 5/0
[RouterB-Atm5/0] pvc 32/50
[RouterB-atm-pvc-Atm5/0-32/50] map bridge-group broadcast
[RouterB-atm-pvc-Atm5/0-32/50] quit
[RouterB-Atm5/0] bridge-set 1
Transparent Bridging over PPP
respectively, which are interconnected over PPP. Configure the two routers to enable transparent
bridging over PPP between the two LAN segments.
Network diagram
Figure 1-9 Network diagram for transparent bridging over PPP configuration
[RouterA-Serial2/0] bridge-set 1
1-11
[RouterB-Serial2/0] bridge-set 1
Transparent Bridging over MP
respectively, which are interconnected over MP. Configure the two routers to enable transparent
bridging over MP between the two LAN segments.
Network diagram
Figure 1-10 Network diagram for transparent bridging over MP configuration
[RouterA-Virtual-Template1] bridge-set 1
[RouterB-Virtual-Template1] bridge-set 1
1-12
Transparent Bridging over FR
respectively, which are interconnected over FR. Configure the two routers to enable transparent
bridging over FR between the two LAN segments.
Network diagram
Figure 1-11 Network diagram for transparent bridging over FR configuration
[RouterA-Serial2/0] fr map bridge 50 broadcast
1-13
[RouterB-Serial2/0] fr map bridge 50 broadcast
Transparent Bridging over X.25
respectively, which are interconnected over X.25. Configure the two routers to enable transparent
bridging over X.25 between the two LAN segments.
Network diagram
Figure 1-12 Network diagram for transparent bridging over X.25 configuration
[RouterA-Serial2/0] link-protocol x25 dce
[RouterA-Serial2/0] x25 map bridge x121-address 200 broadcast
[RouterB-Serial2/0] link-protocol x25
[RouterB-Serial2/0] x25 map bridge x121-address 100 broadcast
1-14
Transparent Bridging over HDLC
respectively, which are interconnected over an HDLC link. Configure the two routers to enable
transparent bridging over HDLC between the two LAN segments.
Network diagram
Figure 1-13 Network diagram for transparent bridging over HDLC configuration
[RouterA-Serial2/0] link-protocol hdlc
[RouterB-Serial2/0] link-protocol hdlc
Bridging with FR Sub-Interface Support
As shown in Figure 1-13, Router A and Router B are interconnected through an FR link. Enable bridging
on the FR sub-interfaces Serial 2/0.1 and Serial 2/0.2 so that traffic between Host A and Host B can be
bridged through bridge set 1 and traffic between Host C and Host D can be bridged through bridge set
2.
1-15
In this example, Router B is a DCE device.
Network diagram
Figure 1-14 Network diagram for bridging with FR sub-interface support

Host A Host B
Eth1/0 Eth1/0
S2/0 S2/0
Router A Router B
Eth1/1 Eth1/1
Host C Host D
[RouterA] interface serial 2/0.1
[RouterA-Serial2/0.1] fr map bridge 50 broadcast
[RouterA-Serial2/0.1] bridge-set 1
[RouterA-Serial2/0.1] quit
[RouterA] interface serial 2/0.2
[RouterA-Serial2/0.2] fr map bridge 60 broadcast
[RouterA-Serial2/0.2] bridge-set 2
1-16
[RouterB] interface serial 2/0.1
[RouterB-Serial2/0.1] fr map bridge 50 broadcast
[RouterB-Serial2/0.1] bridge-set 1
[RouterB-Serial2/0.1] quit
[RouterB] interface serial 2/0.2
[RouterB-Serial2/0.2] fr map bridge 60 broadcast
[RouterB-Serial2/0.2] bridge-set 2
In this example, the sub-interfaces can also be configured as point-to-point (P2P) FR sub-interfaces. In
this case, it is not necessary to use the fr map command on the point-to-point FR sub-interfaces;
however, you need to configure the same DLCI on both the DCE and DTE sides by using the fr dlci
command. This is an alternative method of configuring bridging over FR. For detailed configuration,
refer to Frame Relay Configuration in the Access Volume.
Bridge Routing
As shown in Figure 1-14, three host PCs are attached to Ethernet 1/0, Ethernet 1/1 and Ethernet 1/2 of
a router respectively. Ethernet 1/0 and Ethernet 1/1 belong to the same bridge set. Configure bridge
routing so that traffic passing each interface in the bridge set can be routed.
Network diagram
Figure 1-15 Network diagram for bridge routing configuration
Bridge-Template 1
1.1.1.1/16
Eth1/ 0 Eth1/2
2.1.1.1/ 16
Eth1/1
Bridge set 1
1-17
[Router] bridge enable
[Router] bridge routing-enable
[Router] bridge 1 enable
[Router] bridge 1 routing ip
[Router-Ethernet1/0] bridge-set 1
[Router-Ethernet1/1] bridge-set 1
[Router] interface bridge-template 1
[Router-Bridge-template1] ip address 1.1.1.1 255.255.0.0
[Router-Bridge-template1] quit
Bridging over Dialer Interface
As shown Figure 1-15, Router A and Router B are interconnected through an ISDN link. Configure the
two routers to enable transparent bridging over dialer interfaces between the two LAN segments.
Network diagram
Figure 1-16 Network diagram for bridging over dialer interface configuration
LAN 1
LAN 2
# Enable bridging globally.
# Configure a dialup access control list.

[RouterA] dialer-rule 1 bridge permit
# Configure dialing on the ISDN BRI interface BRI 2/0.

[RouterA] interface bri2/0
[RouterA-Bri2/0] dialer circular-group 2
1-18
[RouterA-Bri2/0] quit
# Add Dialer 2 to bridge set 1.

[RouterA] interface dialer2
[RouterA-Dialer2] bridge-set 1
[RouterA-Dialer2] dialer enable-circular

[RouterA] interface ethernet1/0
# Enable bridging globally.
# Configure a dialup access control list.

[RouterB] dialer-rule 1 bridge permit
# Configure dialing on the ISDN BRI interface BRI 2/0.

[RouterB] interface bri2/0
[RouterB-Bri2/0] dialer circular-group 2
[RouterB-Bri2/0] quit
# Add Dialer 2 to bridge set 1.

[RouterB] interface dialer2
[RouteBr-Dialer2] link-protocol ppp
[RouterB-Dialer2] bridge-set 1

[RouterB] interface ethernet1/0
VLAN ID Transparent Transmission Configuration Example
As shown in Figure 1-16, Office area A and office area B are connected to Switch A and Switch B
respectively and then interconnected through routers. The trunk interfaces of Switch A and Switch B are
assigned to the same VLAN. If Ethernet sub-interface Ethernet 1/0 and ATM 5/0 of both Router A and
1-19
Router B are configured with VLAN ID transparent transmission, the two office areas can communicate
with each other within the same VLAN.
Network diagram
Figure 1-17 Network diagram for VLAN ID transparent transmission configuration
Office
Office Switch A Switch B
area B
area A
Eth1/0 Eth1/0
TRUNK TRUNK
Eth1/0 Eth1/0
ATM5/0 ATM5/0
Router A Router B
# Enable the bridging function.
# Add Ethernet 1/0 to bridge set 2 and enable VLAN ID transparent transmission on Ethernet 1/0. Add
ATM 5/0 to bridge-set 2 and enable VLAN ID transparent transmission.
[RouterA-Ethernet1/0] vlan-type dot1q vid 2
[RouterA-Ethernet1/0] bridge vlanid-transparent-transmit enable
[RouterA] interface atm2/0
[RouterA-Atm5/0] bridge-set 2
[RouterA-Atm5/0] bridge vlanid-transparent-transmit enable
[RouterA-Atm5/0] pvc to_r2 1/100
[RouterA-Atm5/0-1/100-to_r2] map bridge-group broadcast
# Enable the bridging function.
# Add Ethernet 1/0 to bridge set 2 and enable VLAN ID transparent transmission on Ethernet 1/0. Add
ATM 5/0 to bridge-set 2 and enable VLAN ID transparent transmission.
[RouterB-Ethernet1/0] vlan-type dot1q vid 2
1-20
[RouterB-Ethernet1/0] bridge vlanid-transparent-transmit enable
[RouterB] interface atm2/0
[RouterB-Atm5/0] bridge-set 2
[RouterB-Atm5/0] bridge vlanid-transparent-transmit enable
[RouterB-Atm5/0] pvc to_r1 1/100
[RouterB-Atm5/0-1/100-to_r1] map bridge-group broadcast
1-21
Table of Contents
1 ISDN Configuration1-1
Introduction to ISDN1-1
Configuring ISDN 1-2
Configuring ISDN BRI1-2
Configuring ISDN PRI1-3
Configuring the Negotiation Parameters of ISDN Layer 3 Protocol 1-4
Configuring the SPID of the ISDN NI Protocol 1-9
Setting the Called Number or Sub-Address to Be Checked During a Digital Incoming Call1-9
Configuring to Send Calling Number during an Outgoing Call1-10
Setting the Local Management ISDN B Channel 1-10
Configuring ISDN B Channel Selection Mode1-11
Configuring the Sliding Window Size on the PRI Interface 1-11
Configuring Statistics about ISDN Message Receiving/Sending 1-12
Configuring to Check the Calling Number When an Incoming Call Comes 1-12
Configuring Progress-to-Alerting Conversion1-12
Configuring TEI Treatment on the BRI Interface1-13
Configuring an ISDN BRI Leased Line1-13
Configuring Permanent Link Function at ISDN BRI Link Layer1-13
Specifying an ISDN BRI Interface to be in Permanent Active State on Physical Layer1-14
Enabling Remote Powering on an ISDN BRI Interface 1-15
Enabling the Trap Function 1-15
Displaying and Maintaining ISDN 1-16
ISDN Configuration Examples 1-16
Connecting Routers through ISDN PRI Lines 1-16
Connecting Routers through ISDN BRI Lines Running NI 1-17
Using ISDN BRI Leased Lines to Implement MP Bundling1-18
Configuring ISDN 128K Leased Lines1-20
Interoperating with DMS100 Switches 1-22
i

Specify the BRI interface to be in permanent
NO NO NO NO
active state on physical layer
Enabling remote powering on an ISDN BRI
YES YES YES YES
interface
1 ISDN Configuration
When configuring ISDN, go to these sections for information you are interested in:
z Introduction to ISDN
z Configuring ISDN
z Displaying and Maintaining ISDN
z ISDN Configuration
z Troubleshooting
Introduction to ISDN
Derived from Integrated Digital Network (IDN), Integrated Services Digital Network (ISDN), provides
end-to-end digital connectivity and supports an extensive range of services, covering both voice and
non-voice services.
ISDN furnishes a finite set of standard multi-purpose usernetwork interfaces (UNIs). In ITU-T I.412
recommendation, two types of UNIs are specified: basic rate interface (BRI) with bandwidth of 2B + D
and primary rate interface (PRI) with Bandwidth of 30B + D or 23B + D. Where,
z B channel is a user channel, used to transmit such user information as voice and data with a
transmission rate of 64 kbps.
z D channel is a control channel, which transmits the public channel signaling. These signals are
used to control the calls on the B channel of the same interface. The rate of D channel is 16 kbps
(BRI) or 64 kbps (PRI). The ITU-T Q.921 is a data link layer protocol of D channel. It defines the
rule for Layer 2 information interchange via D channel from the user to a network interface and
supports the access of a Layer-3 entity. The ITU-T Q.931 is a network layer protocol of D channel.
It provides a measure for creating, maintaining and terminating network connection between
communication application entities. Call control (CC) is a further encapsulation of Q.931, which
1-1
forwards the message from the network side to CC for CC to perform information interchange with
higher layer applications such as DCC.
Figure 1-1 ISDN D channel protocol stack
CC
Layer 3
Q. 931
Layer 2 Q. 921 LAPD
Layer 1 BRI PRI
The ISDN protocol proposed by ITU-T provides different services in different areas, forming the ISDN
protocols that are suitable for different regions, such as NTT (Nippon Telegraph and Telephone
Corporation) in Japan, ETSI (European Telecommunications Standards Institute) in Europe, NI
(National ISDN), AT&T 5ESS, and ANSI (American National Standard Institute) in North America.
Besides the default DSS1 ISDN protocol, the router supports the basic calling function of NTT, ETSI,
ATT, ANSI, NI, NI2, and Q.SIG protocols, but does not support the supplementary functions of these
protocols. Additionally, both DSS1 & Q.SIG support network side operation.
NI protocol used in North America is only applied to BRI interfaces. The ISDN network uses service
profile identification (SPID) as the ID of different services, and the switch provides the corresponding
service to the terminal user according to the SPID. Each B channel corresponds to a SPID. The user
can proceed with normal calling and disconnection process only after having employed the SPID to
perform the SPID handshake interaction. Therefore, after the Q.921 establishes link successfully and
before the Q.931 calling processing starts, the user needs to obtain SPID to interact with the switch to
perform the Layer 3 (Q.931) initialization, and then the user can start normal calling and disconnect
process, otherwise, the calling will fail.
By far, there are three ways to obtain the SPID on one BRI interface over the ISDN in North America.
z Manually input the SPID consisting of 9 to 20 digits.
z 14-digit SPID (Generic SPID Format). The former 10 digits are input by the user, and the latter 4
digits can only be 0101.
z Allocate by Stored Program Control Switching System (SPCS) through automated SPID selection
regulation.
The former two ways to obtain SPID are regarded as static configuration methods, and the third one is
taken as dynamic negotiation method. If the user does not specify a SPID in static method, the system
will adopt dynamic method by default.
Configuring ISDN
Configuring ISDN BRI
Follow these steps to configure ISDN BRI:

1-2
Enter specified ISDN BRI interface interface-type

Optional
By default, a BRI interface
Configure the BRI interface to operates in point-to-multipoint
operate in the point-to-point isdn link-mode p2p mode, in which a BRI interface
mode operating on the network side
can have multiple end devices
attached to it.
Optional
Set ISDN protocol type isdn protocol-type protocol The ISDN protocol on the BRI
interface is DSS1 protocol by
default.
Optional
Shut down the BRI interface shutdown By default, an ISDN BRI
interface is up.
Configure the negotiation Refer to Configuring the
parameters of ISDN Layer 3 Negotiation Parameters of Optional
protocol ISDN Layer 3 Protocol
Configure the SPID parameters Refer to Configuring the SPID
Optional
about ISDN NI protocol of the ISDN NI Protocol
Refer to Setting the Called

Configure the called number
Number or Sub-Address to Be
and subaddress to be checked Optional
Checked During a Digital
during an incoming call
Incoming Call
Refer to Configuring to Send
Configure to send calling
Calling Number during an Optional
number during an outgoing call
Outgoing Call
Set the local management Refer to Setting the Local
Optional
ISDN B channel Management ISDN B Channel
Configure ISDN B channel Refer to Configuring ISDN B
Optional
selection mode Channel Selection Mode
Refer to Configuring Statistics
Configure statistics about ISDN
about ISDN Message Optional
message receiving/sending
Receiving/Sending
Refer to Configuring to Check
Configure the allowed incoming
the Calling Number When an Optional
calling number
Incoming Call Comes
Configure TEI treatment on the Refer to Configuring TEI
Optional
BRI interface Treatment on the BRI Interface
Refer to Configuring an ISDN
Configure ISDN BRI leased line Optional
BRI Leased Line
Refer to Configuring
Configure permanent link
Permanent Link Function at Optional
function on ISDN BRI link layer
ISDN BRI Link Layer
Configuring ISDN PRI
Follow these steps to configure ISDN PRI:
1-3
Enter specified ISDN PRI interface interface-type

Optional
Set ISDN protocol type isdn protocol-type protocol The ISDN protocol on the
PRI interface is DSS1
protocol by default.
Configure the negotiation Refer to Configuring the Negotiation
parameters of ISDN Layer 3 Parameters of ISDN Layer 3 Optional
protocol Protocol
Configure the called number Refer to Setting the Called Number
and subaddress to be checked or Sub-Address to Be Checked Optional
during an incoming call During a Digital Incoming Call
Configure to send calling Refer to Configuring to Send Calling
Optional
number during an outgoing call Number during an Outgoing Call
Set the local management Refer to Setting the Local
Optional
ISDN B channel Management ISDN B Channel
Configure ISDN B channel Refer to Configuring ISDN B
Optional
selection mode Channel Selection Mode
Configure ISDN PRI sliding Refer to Configuring the Sliding
Optional
window size Window Size on the PRI Interface
Configure statistics about ISDN Refer to Configuring Statistics about
Optional
message receiving/sending ISDN Message Receiving/Sending
Refer to Configuring to Check the
Configure the allowed incoming
Calling Number When an Incoming Optional
calling number
Call Comes
Configuring the Negotiation Parameters of ISDN Layer 3 Protocol
Follow these steps to configure the negotiation parameters of ISDN Layer-3 protocol:

interface
Enter specified interface view interface-type
interface-number
Optional
Set the length of the call The call reference length is two bytes
isdn crlength
reference adopted when the for CE1 PRI and CT1 PRI interfaces
call-reference-length
ISDN interface initiates a call and one byte for BRI interfaces by
default.
1-4
Optional
Configure the router to switch By default, in the event that the router is
the ISDN protocol state to communicating with an ISDN switch,
ACTIVE to start the data and the ISDN protocol must wait for the
isdn ignore
voice service communications CONNECT ACK in response to the
connect-ack
after sending a CONNECT CONNECT message before it can
message without having to wait switch to the ACTIVE state to start the
for a CONNECT ACK message data and voice service
communications.
Configure to disable ISDN to Optional

carry the HLC information By default, HLC information element is
isdn ignore hlc
element in SETUP messages carried in SETUP messages when
when placing voice calls placing voice call.
Configure to disable ISDN to Optional

carry the LLC information By default, LLC information element is
isdn ignore llc
element in SETUP messages carried in SETUP messages when
when placing voice calls placing voice call.
Optional
As for the data exchange performed
between a router and an ISDN switch,
the default is as follows.
For an incoming call, the router checks
the received Setup messages for the
Configure the ISDN protocol to isdn ignore Sending Complete Information Element
ignore the processing on the sending-complete to determine whether or not the number
Sending Complete Information [ incoming | is received completely. If a Setup
Element outgoing ] message does contain the Sending
Complete Information Element, the
number is not received completely.
For outgoing calls, a Setup message
containing the Sending Complete
Information Element indicates that the
number is sent completely.
Optional
By default, configure the duration of an
ISDN L3 timer as (in seconds):
T301 defaults to 240
T302 defaults to 15
T303 defaults to 4
isdn l3-timer T304 defaults to 30
Configure the time-interval of
timer-name
ISDN Layer 3 T305 defaults to 30
time-interval
T308 defaults to 4
T309 defaults to 90
T310 defaults to 40
T313 defaults to 4
T316 defaults to 120
T322 defaults to 4
isdn Optional
Set the type and code scheme
number-property By default, the system selects ISDN
of calling or called numbers in
number-property number type and code scheme
incoming or outgoing ISDN
[ calling | called ] [ in | depending on upper layer service. For
calls
out ] detailed information, refer to Table 1-1.
1-5
Set the called number of ISDN
interface to send in overlap Optional
mode. In this mode, the digits of
isdn overlap-sending In full-sending mode, all the digits of
each called number will be sent
[digits ] each called number will be collected
separately and the number of
the digits sent each time can be and sent at a time by default.
set by the user.
Table 1-1 Types and code schemes of ISDN numbers
Field (Bit) value

Protocol Type Code scheme Definition
8 7 6 5 4 3 2 1
0 0 0 User-specified
0 1 0 National network identification
0 1 1 International network identification

ANSI 0 0 0 0 Unknown/user-specified
0 0 0 1 Carrier identification code
Data network identification code (ITU-T
0 0 1 1
Recommendation X.121)
0 0 0 Unknown
0 0 1 International number
0 1 0 National number
1 0 0 Subscriber number
AT&T
0 0 0 0 Unknown
ISDN/telephony numbering loan (Recommendation
0 0 0 1
E.164/E.163)
1 0 0 1 Private numbering plan
1-6
Field (Bit) value
8 7 6 5 4 3 2 1
0 0 0 Unknown
0 1 1 Network specific number
1 1 0 Abbreviated number
1 1 1 Reserved for extension
DSS1 0 0 0 0 Unknown
ISDN/telephony numbering plan (Recommendation
0 0 0 1
E.164)
0 0 1 1 Data numbering plan (Recommendation X.121)
0 1 0 0 Telex numbering plan (Recommendation F.69)
1 0 0 0 National standard numbering plan

1 1 1 1 Reserved for extension
0 0 0 Unknown
1 1 0 Abbreviated number
1 1 1 Reserved for extension
ETSI 0 0 0 0 Unknown
0 0 0 1
E.164)
0 0 1 1 Data numbering plan (Recommendation X.121)
0 1 0 0 Telex numbering plan (Recommendation F.69)

1 0 0 0 National standard numbering plan
1 1 1 1 Reserved for extension
1-7
Field (Bit) value
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 Unknown number in Unknown numbering plan
International number in ISDN numbering plan (Rec.
0 0 1 0 0 0 1
E.164)
National number in ISDN numbering plan (Rec.
0 1 0 0 0 0 1
NI E.164)
0 1 1 1 0 0 1 Network specific number in private numbering plan
Local (directory) number in ISDN numbering plan
1 0 0 0 0 0 1
(Rec. E.164)
1 1 0 1 0 0 1 Abbreviated number in private numbering plan

0 0 0 Unknown
NTT
0 0 0 0 Unknown
0 0 0 1
E.164)

0 0 0 0 0 0 0 Unknown number in Unknown numbering plan
Unknown number in ISDN/Telephony numbering
0 0 0 0 0 0 1
plan (ITU-T Rec.E.164/E.163)
International number in ISDN/Telephony numbering
0 0 1 0 0 0 1
National number in ISDN/Telephony numbering
0 1 0 0 0 0 1
QSIG Subscriber number in ISDN/Telephony numbering
0 1 1 0 0 0 1
0 0 0 1 0 0 1 Unknown number in private numbering plan
0 0 1 1 0 0 1 Level 2 regional number in private numbering plan
0 1 1 1 0 0 1 PISN specific number in private numbering plan

The undefined bits in all the protocols are reserved for other purposes.
1-8
Configuring the SPID of the ISDN NI Protocol
You may configure SPID on the BRI interfaces that are running the ISDN NI protocol.
Follow these steps to configure the SPID parameters of the ISDN NI protocol:

interface
Enter specified interface view interface-type
interface-number
Set the SPID value of B1 on the
BRI interface adopting NI Required
protocol. isdn spid1 spid [ ldn ] SPID is obtained via
Set the SPID
types on the Set the SPID value of B2 on the isdn spid2 spid [ ldn ] dynamic negotiation
BRI interface BRI interface adopting NI by default.
adopting NI protocol.
protocol as
Optional
NIT, static and
dynamic. Enable the SPID negotiation on A BRI interface does
When isdn spid not originate a SPID
the BRI interface adopting NI
configuring, auto_trigger negotiation request
protocol.
only one of unless triggered by a
them can be call by default.
available
once. On the BRI interface adopting NI
NIT does not apply on
protocol, set the processing
isdn spid nit BRI interfaces by
mode of SPID to NIT, i.e.,
default.
non-initializing terminal mode.
SPID needs to support
isdn spid service
speech and data
Set the service type supported by SPID [ audio | data |
services
speech ]
simultaneously.
Optional
Set the time-interval of timer TSPID on the BRI isdn spid timer The time-interval of
interface adopting NI protocol. seconds timer TSPID is 30
seconds by default.
Set the number of times of resending message on isdn spid resend Optional
the BRI interface adopting NI protocol. times Once by default
Setting the Called Number or Sub-Address to Be Checked During a Digital Incoming

Call
If a called number or subaddress is specified, the system will deny an incoming digital call if the calling
party sends a wrong called number or subaddress or does not send at all.
Follow these steps to configure the called number or sub-address to be checked during a digital
incoming call:
1-9
interface-number
Optional
No called number or
Set the called number or isdn check-called-number sub-address is configured by
sub-address to be checked called-party-number default. When configuring this
during a digital incoming call [ :subaddress ] command, the called number
and subaddress are separated
with string space: space.
Configuring to Send Calling Number during an Outgoing Call
The purpose for setting this command is to reduce cost in some networks that charge the calling side by
providing advantageous accounting numbers for users.
Follow these steps to configure to send the calling number during an outgoing call:

Enter specifies interface view
interface-number
Configure to send the calling isdn calling Optional

number during an outgoing call calling-number Calling number is not sent by default.
Setting the Local Management ISDN B Channel
Configured with the isdn bch-local-manage command, the router operates in local B-channel
management mode to select available B channels for calls. Despite this, the connected exchange has
higher priority in B channel selection. If the B channel the router selected for a call is different from the
one indicated by the exchange, the one indicated by the exchange is used for communication.
Configured with the isdn bch-local-manage exclusive command, the router operates in exclusive
local B-channel management mode. In this mode, the B channel selected by the router must be
adopted for communication. In the Channel ID information element of the call Setup message sent for a
call, the router indicates that the B channel is mandatory and unchangeable. If the connected exchange
indicates a B channel different from the one selected by the router, call failure occurs.
Follow these steps to set the local management ISDN B channel:

Enter specified interface interface-type

1-10
Local ISDN B channel management is not
configured and the remote end is responsible
for B channel management by default.
Set the local Exclusive local management mode for ISDN B
isdn bch-local-manage channels is applied to network side for the
management ISDN
[ exclusive ] device. If the device serves as user side
B channel
connected with ISDN switch, and the B channel
indicated by the exchange is inconsistent with
the one required by the local end, call failure
occurs.
Configuring ISDN B Channel Selection Mode
Follow these steps to configure ISDN B channel selection mode:

Enter specified interface interface interface-type

interview interface-number
Optional
ISDN B channel ascending selection
Configure ISDN B mode is adopted by default. When the
channel ascending or isdn bch-select-way switch manages B channel, this command
descending selection { ascending | descending } takes no effect. (For more information
mode about configuring local management
ISDN B channel, refer to Setting the Local
Management ISDN B Channel).
Configuring the Sliding Window Size on the PRI Interface
Follow these steps to configure the size of the sliding window on the PRI interface:

interface-number
Configure the sliding window Optional

isdn pri-slipwnd-size
size on the PRI interface or The sliding window on the PRI
{ window-size | default }
restore the default. interface defaults to 7.
1-11
Configuring Statistics about ISDN Message Receiving/Sending
Follow these steps to configure the statistics about ISDN message receiving/sending:

interface-number
Set ISDN to start the statistics of
isdn statistics start Required
Set ISDN to stop the statistics of
isdn statistics stop Required
Display ISDN statistics isdn statistics display [ flow ] Required
Set ISDN to continue the statistics of
isdn statistics continue Optional
information received by ISDN
Clear ISDN statistics isdn statistics clear Optional
Configuring to Check the Calling Number When an Incoming Call Comes
Follow these steps to configure to check the calling number when an incoming call comes:

interface-number
Configure to check the calling Required

isdn caller-number
number when an incoming call Execute this command to configure
caller-number
comes limited incoming calls.
Configuring Progress-to-Alerting Conversion
When ISDN is processing voice calls, Alerting messages are used as ring indications as defined in the
standard protocol. However, some devices use Progress messages as ring indications. In this case,
you need to convert the received Progress messages into Alerting messages. You can use the related
command to determine whether to perform the conversion. The conversion is needed when the current
device is connected to a device using Progress messages as ring indications. Otherwise, the
conversion is unnecessary. The conversion is enabled by default.
Follow these steps to configure Progress-to-Alerting conversion:

Enter the specified interface view
interface-number
1-12
Configure the ISDN interface to Optional
isdn message-conversion
convert received Progress
progress-to-alerting enable Enabled by default
messages into Alerting messages
Configuring TEI Treatment on the BRI Interface
Follow these steps to configure TEI treatment on the BRI interface:

Enter specified BRI interface interface bri

Request the switch for a new Optional

TEI each time a B channel on isdn two-tei All B channels on the BRI interface
the BRI interface places a call. use the same TEI by default.
Configuring an ISDN BRI Leased Line
ISDN leased lines are implemented by establishing MP semi-permanent connections. This requires
that the PBXes of your telecommunication service provider provide leased lines and are connected to
the remote devices.
Follow these steps to configure an ISDN BRI leased line:

Enter specified BRI interface bri

Configure the B channel for No B channel on the ISDN BRI
dialer isdn-leased { 128k |
ISDN leased line interface is configured for leased line
number }
connection. connection by default.
z Before configuring an ISDN BRI leased line, make sure that C-DCC is enabled.
z For information about C-DCC configuration, refer to DCC Configuration in the Access Volume.
Configuring Permanent Link Function at ISDN BRI Link Layer
With the isdn q921-permanent command executed, the BRI interface sets up a data link connection
automatically and maintain the connection even when no calls are received from the network layer. If
the two-tei mode is also configured on the interface, two such connections will be present.
You may need to configure permanent Q.921 link mode where the ISDN NI protocol is adopted to
ensure the success of every call attempt.
1-13
Follow these steps to configure Q.921 permanent link mode for an ISDN BRI interface:

Enter specified BRI interface interface interface-type

Required
Set the Q.921 link on the BRI dialer isdn-leased { 128k | The Q.921 links on BRI
interface in permanent state number } interfaces are not in permanent
state by default.
On PRI interfaces, Q.921 layer negotiates to enter multi-framing state immediately after the user side
and the network side are connected correctly. On BRI interfaces, however, the Q.921 layer transits to
the multi-framing state only after a call is placed and the Q.921 link that has been set up will be torn
down if no Layer 3 call is received before the T.325 timer expires.
Specifying an ISDN BRI Interface to be in Permanent Active State on Physical Layer
On a BRI interface operating on the network side, the T325 timer is triggered when the link is torn down
on data link layer and deactivating requests are sent from data link layer to physical layer when the
timer expires. Deactivating request causes BRI interface to turn to active mode on physical layer and
thus helps reduce power consumption. To make a BRI interface remain in the active state on physical
layer even if no link exists on the data link layer, you can perform the operations listed in the following
table, through which you can disable activating request sending.
Follow these steps to specify an ISDN BRI interface to be in permanent active state on physical layer:

Enter specified BRI interface interface interface-type

Specify the BRI interface to be Optional

in permanent active state on permanent-active A BRI interface is not in permanent
physical layer active state on physical layer
1-14
z This function is only applicable to BRI interfaces operating in the network side mode. (Currently,
only BSV board can operate on network side.)
z This function is different from the permanent link function. The former maintains the active state of
BRI interfaces on physical layer and is only applicable to BRI interfaces operating on the network
side. It cannot activate the BRI interfaces that are in inactive state on physical layer. The latter,
however, enables BRI interfaces to enter Q.921 multi-framing state immediately after the user side
and the network side are connected correctly. It is only applicable to BRI interfaces operating on
the user side. If you enable the permanent link function while no Q.921 link is established, the
system attempts to establish Q.921 links.
Enabling Remote Powering on an ISDN BRI Interface
Follow these steps to enable remote powering on an ISDN BRI interface:

Enter specified BRI interface interface-type

Optional
Enable remote powering on
power-source The remote powering function is disabled
the interface
on an ISDN BRI interface by default.

z This function is available to BSV interfaces operating in the network side mode. For example, you
can enable this function on a BSV interface operating in the network side mode to provide power
supply to the ISDN digital phone sets attached to the interface. (Currently, only BSV board can
operate in the network side mode.)
Enabling the Trap Function
A frame relay module with the trap function enabled can generate traps of the notifications level to
report its important events. The generated traps will be sent to the information center of the device. By
setting parameters for the information center, you can determine the output criteria for traps, that is, you
can determine whether traps can be output and the output destinations. For how to configure
parameters for the information center, refer to Information Center Configuration in the System Volume.
Follow these steps to enable the trap function:
1-15
Enable the trap function for the Optional

snmp-agent trap enable isdn
frame relay module Enabled by default
For detailed information about the snmp-agent trap enable isdn command, refer to the snmp-agent
trap enable isdn command in SNMP Commands in the System Volume.
Displaying and Maintaining ISDN

Display the active calling display isdn active-channel
information on an ISDN [ interface interface-type Available in any view
interface interface-number ]
Display the current status of an display isdn call-info [ interface
ISDN interface interface-type interface-number ]
Display the history record of an display isdn call-record [ interface
ISDN call interface-type interface-number ]
Display the system parameters
display isdn parameters { protocol |
of ISDN protocol Layer 2 and
interface interface-type Available in any view
Layer 3 running on the
interface-number ]
interface.
Display the information of SPID
display isdn spid interface
on the BRI interface adopting Available in any view
NI protocol
Available in ISDN
Shut down a BRI interface shut down
interface view
Available in ISDN
Bring up a BRI interface undo shut down
interface view
ISDN Configuration Examples

Connecting Routers through ISDN PRI Lines
As shown in the figure below, Router A is connected to Router B through ISDN PRI lines.
1-16
Network diagram
Figure 1-2 Network diagram for ISDN configuration
# Create an ISDN PRI interface.
[RouterA] controller e1 1/0
[RouterA-E1 1/0] pri-set
[RouterA-E1 1/0] quit
# Configure an ISDN PRI interface.

[RouterA-Serial1/0:15] ip address 202.38.154.1 255.255.0.0
[RouterA-Serial1/0:15] isdn protocol-type dss1
[RouterA-Serial1/0:15] dialer enable-circular
[RouterA-Serial1/0:15] dialer route ip 202.38.154.2 8810154
[RouterA-Serial1/0:15] dialer-group 1
Follow the same procedures to configure Router B.
Connecting Routers through ISDN BRI Lines Running NI
As shown in the following figure, Router A is connected to Router B through NI protocol of ISDN BRI
lines.
1-17
Network diagram
Figure 1-3 Network diagram for ISDN NI protocol configuration
# Configure the dialing parameters on ISDN BRI interface.
# Configure ISDN NI protocol parameters to make the B channel of BRI interface support static SPID
value, and set the negotiation message to be resent twice when there is no reply.
[RouterA-Bri2/0] isdn protocol-type ni
[RouterA-Bri2/0] isdn spid1 12345
[RouterA-Bri2/0] isdn spid2 23456
[RouterA-Bri2/0] isdn spid resend 2
Follow the same procedures to configure Router B.
Using ISDN BRI Leased Lines to Implement MP Bundling
As shown in the following figure, Router A is connected to Router B through two BRI leased lines, which
are used for MP bundling.
1-18
Network diagram
Figure 1-4 Using ISDN BRI leased lines to implement MP bundling
[RouterA-Bri2/0] ppp mp virtual-template 5
[RouterA-Bri2/0] dialer isdn-leased 0
[RouterA-Bri2/0] dialer isdn-leased 1
[RouterB] interface bri2/0
[RouterB-Bri2/0] ppp mp virtual-template 5
[RouterB-Bri2/0] dialer isdn-leased 0
[RouterB-Bri2/0] dialer isdn-leased 1
z At present, only virtual-template is used as the template for MP binding using ISDN leased line.
z As leased lines do not require dialing, you do not need to configure dial numbers.
z The system accepts MP bundles formed by multiple ISDN leased lines, which can be 64K, 128K,
or both. For detailed information, refer to the three ways to configure MP bundles discussed in
PPP/PPPoE Configuration in the Access Volume.
1-19
Configuring ISDN 128K Leased Lines
Router A and Router B are connected by connecting their ISDN BRI interfaces through a 128K leased
line.
Network diagram
Figure 1-5 Network diagram for ISDN 128K leased line connection
[RouterA-Bri2/0] dialer isdn-leased 128k
[RouterB-Bri2/0] dialer isdn-leased 128k
You do not need to configure a dial number because setup of leased line connection does not involve
dialing process.
After you configure a lease line successfully, you can dial through. To view the interface states, execute
the following commands:
<RouterA> display interface bri 2/0
Bri2/0 current state :UP
Line protocol current state :UP (spoofing)
Description : Bri2/0 Interface
The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
1-20
baudrate is 128000 bit/s, Timeslot(s) Used: 1, 2
Internet Address is 100.1.1.1/24
Encapsulation is ISDN

Output queue : (Protocol queue : Size/Length/Discards) 0/500/0
Last 300 seconds input rate 0.00 bytes/sec, 0.00 packets/sec
Last 300 seconds output rate 0.00 bytes/sec, 0.00 packets/sec
Input: 0 packets, 0 bytes
0 broadcasts, 0 multicasts
2 errors, 0 runts, 0 giants,
2 CRC, 0 align errors, 0 overruns,
0 dribbles, 0 aborts, 0 no buffers
0 frame errors
Output:0 packets, 0 bytes
0 errors, 0 underruns, 0 collisions
0 deferred
<RouterA> display interface bri 2/0:1

Bri2/0:1 current state :UP
Description : Bri2/0:1 Interface
baudrate is 128000 bit/s, Timeslot(s) Used: 1, 2
LCP opened, IPCP opened, OSICP opened
0 frame errors
0 deferred
<RouterA> display interface bri 2/0:2

Bri2/0:2 current state :DOWN
Description : Bri2/0:2 Interface
baudrate is 64000 bit/s, Timeslot(s) Used: NULL
1-21
LCP initial
0 frame errors
0 deferred
As you can see, the state of interface Bri 2/0:1 is up, its speed is 128 kbps, and channels (timeslots
used) B1 and B2 are in use; the state of Bri 2/0:2 is down, and the field of timeslots used is NULL.
Interoperating with DMS100 Switches
Router D is connected to a DMS100 switch of the carrier, using the access number of 8810148. The
ISDN lines on interface BRI 1/0 are allocated two SPIDs and LDNs; they are:
spid1 = 31427583620101, LDN1 = 1234567
spid2 = 31427583870101, LDN2 = 7654321
In addition, the username and password for dialing are user and hello respectively.
Router D needs to place an MP call on interface Bri 2/0 to obtain an address from the carrier for
accessing the Internet.
Network diagram
Figure 1-6 Interoperate with the DMS 100
# Enable IP packet-triggered dial.

# Encapsulate interface BRI 2/0 with MP.

[Router] interface bri 2/0
1-22
[Router-Bri2/0] link-protocol ppp
[Router-Bri2/0] ppp mp
# Enable C-DCC.
[Router-Bri2/0] dialer enable-circular
[Router-Bri2/0] dialer-group 1
[Router-Bri2/0] dialer circular-group 1
# Configure ISDN parameters.

[Router-Bri2/0] isdn protocol-type ni
[Router-Bri2/0] isdn two-tei
[Router-Bri2/0] isdn number-property 0
[Router-Bri2/0] isdn spid1 31427583620101 1234567
[Router-Bri2/0] isdn spid2 31427583870101 7654321
[Router-Bri2/0] isdn spid service data
[Router-Bri2/0] isdn spid service speech
[Router-Bri2/0] quit

[Router-Dialer1] link-protocol ppp
[Router-Dialer1] ppp pap local-user user password simple hello
[Router-Dialer1] dialer threshold 0 in-out
[Router-Dialer1] ppp mp
[Router-Dialer1] dialer enable-circular
[Router-Dialer1] dialer number 8810148
[Router-Dialer1] quit
# Configure the static route to segment 65.0.0.0 where the network access server is located.
[Router] ip route-static 65.0.0.0 255.0.0.0 Dialer 1 preference 60
To interoperate with the DMS 100, you must configure two commands: isdn two-tei and isdn
number-property 0. The isdn two-tei command allows each call on the BRI interface to use a unique
TEI. The isdn number-property 0 command sets the numbering plan and numbering type in the
called-party information element in ISDN Q.931 SETUP messages to unknown.
In addition, if the carrier allocates an LDN, you must configure it.
The dialer threshold 0 in-out command configured on interface dialer 1 allows the system to bring up
another B channel automatically after bringing up a BRI link. This can be done without presence of a
flow control mechanism and the links that have been brought up will not be disconnected automatically.
Troubleshooting
Symptom:
Two routers are interconnected via ISDN PRI line and they cannot ping through each other.
Solution:
z Execute the display isdn call-info command. If there is no prompt in the system, it indicates there
is no ISDN PRI interface. Thus it is necessary to configure corresponding interfaces. For specified
1-23
configuration method, refer to the contents about configuration of CE1/PRI interface and CT1/PRI
interface in Interface module. If ISDN is not in multi-frame operation status on a PRI interface, or if
ISDN is not in TEI configured status on a BRI interface, it may be not physically connected well.
z If the Q.921 debugging has been enabled, and ISDN on PRI is in multi-frame creation mode and
that on BRI is in TEI configured mode, check whether dial-up configuration is correct. If the
maintaining information Q921 send data fail (L1 return failure). is output, it indicates that physical
layer has not been activated. In this case, execute the shutdown or undo shutdown command to
disable or re-enable corresponding interfaces.
z Check whether the dial-up configuration is correct. If dial-up is correctly configured and the
maintaining information Q921 send data fail (L1 return failure). is not output, the ISDN line may
be not connected well.
1-24
Table of Contents
1 MSTP Configuration 1-1

MSTP Overview 1-1
Introduction to STP1-1
How STP works 1-3
Introduction to MSTP1-10
Configuration Task List 1-16
Configuring the Root Bridge1-17
Configuring an MST Region 1-17
Specifying the Root Bridge or a Secondary Root Bridge 1-18
Configuring the Work Mode of an MSTP Device 1-20
Configuring the Priority of the Current Device1-20
Configuring the Maximum Hops of an MST Region1-21
Configuring the Network Diameter of a Switched Network 1-22
Configuring Timers of MSTP 1-22
Configuring the Timeout Factor1-24
Configuring the Maximum Port Rate 1-24
Configuring Ports as Edge Ports 1-25
Setting the Type of a Connected Link to P2P 1-26
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets1-27
Enabling the Output of Port State Transition Information1-28
Enabling the MSTP Feature 1-29
Configuring Leaf Nodes 1-29
Configuring an MST Region 1-29
Configuring the Work Mode of MSTP1-29
Configuring the Timeout Factor1-30
Configuring the Maximum Transmission Rate of Ports1-30
Configuring Ports as Edge Ports 1-30
Configuring Path Costs of Ports 1-30
Configuring Port Priority 1-32
Setting the Type of a Connected Link to P2P 1-32
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets1-33
Enabling Output of Port State Transition Information1-33
Enabling the MSTP Feature 1-33
Performing mCheck 1-33
Configuration Example 1-34
Configuring the VLAN Ignore Feature1-34
Configuring Digest Snooping 1-35
i
Configuring No Agreement Check 1-37
Configuring Protection Functions1-40
Configuration prerequisites 1-40
Enabling BPDU Guard1-40
Enabling Root Guard 1-41
Enabling Loop Guard1-41
Enabling TC-BPDU Attack Guard 1-42
Displaying and Maintaining MSTP 1-43
MSTP Configuration Example1-43
ii
Enabling the output of YES YES YES YES

port state transition Disabled by Disabled by Disabled by Disabled by
information default default default default
VLAN Ignore NO NO NO NO
Digest snooping YES YES YES YES
No Agreement Check NO NO NO NO
Protection functions YES YES YES YES
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 the VLAN Ignore Feature
z Configuring Digest Snooping
z Configuring No Agreement Check
z Configuring Protection Functions
z Displaying and Maintaining MSTP
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
1-1
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
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 local The port through which the
For a device device and responsible for forwarding designated bridge forwards
BPDUs to the local device BPDUs to this device
The port through which the
The device responsible for forwarding
For a LAN designated bridge forwards
BPDUs to this LAN segment
BPDUs to this LAN segment
As shown in Figure 1-1, 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.
1-2
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
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 shortest 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 can be maintained on a device.
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.
1-3
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
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:
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
1 configuration BPDU 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
1-4
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.
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 the
3 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.
1-5
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}
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
Device Comparison process
after 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, AP1: {0, 0, 0, AP1}
Device A
AP2} is superior to the received configuration BPDU, and AP2: {0, 0, 0, AP2}
therefore discards the received 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.
1-6
BPDU of port
after comparison
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 {2, 0,
2, CP2}. Device B finds that the configuration BPDU of the BP2: {1, 0, 1, BP2}
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 ports,
Device B 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 port {0, 0, 0, AP1}
configuration BPDU for BP2 {0, 5, 1, BP2}. Designated port
z Device B compares the calculated configuration BPDU {0, 5, BP2:
1, BP2} with the configuration BPDU of BP2. If the calculated {0, 5, 1, BP2}
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-7
BPDU of port
after comparison
z Port CP1 receives the configuration BPDU of Device A {0, 0,
0, AP2}. Device C finds that the received configuration BPDU
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
CP2}, and therefore updates the configuration BPDU of CP2.
After comparison:
z The configuration BPDU of CP1 is elected as the optimum Root port CP1:
configuration BPDU, so CP1 is identified as the 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
configuration BPDU {0, 10, 2, CP2} with the configuration CP2:
BPDU of CP2, and CP2 becomes the designated port, and the {0, 10, 2, CP2}
configuration BPDU of this port will be replaced with the
calculated configuration BPDU.
z Then, port CP2 receives the updated configuration BPDU of
Device C Device B {0, 5, 1, BP2}. Because the received configuration
BPDU is superior to its own configuration BPDU, Device C CP1: {0, 0, 0, AP2}
launches a BPDU update process.
z At the same time, port CP1 receives periodic configuration CP2: {0, 5, 1, BP2}
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 Blocked port CP2:
of CP2 is elected as the optimum BPDU, and CP2 is elected
as the root port, the messages of which will not be changed. {0, 0, 0, AP2}
z After comparison between the configuration BPDU of CP1 Root port CP2:
and the calculated designated port configuration BPDU, port {0, 5, 1, BP2}
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-8
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-9
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.
z MSTP divides a switched network into multiple regions, each containing multiple spanning trees
that are independent of one another.
1-10
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-11
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-12
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 assumes the same role on the CIST and on MSTIs. Namely,
if a boundary port is the master port on the CIST, it is also the master port on all MSTIs within this region.
Currently, the device is not capable of recognizing boundary ports. When the device interworks with a
third partys device that supports boundary port recognition, the third partys device may malfunction in
recognizing a boundary port.
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.
1-13
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.
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).
1-14
Table 1-6 Ports states supported by different port roles
Role (right) Root port/master

Designated port Alternate port Backup port
State (below) 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.
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.
MSTP is documented in:
1-15
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
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 the VLAN Ignore Feature Optional
1-16
Task Remarks
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 interface view do not take effect on the aggregation
member ports; 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 interface, the system performs MSTP calculation
on the Layer-2 aggregate interface but not on the aggregation member ports. The MSTP enable
state and forwarding state of each selected port in an aggregation group must be consistent with
those of the corresponding Layer-2 aggregate interface.
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.
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
name
MAC address by default.
Optional
instance instance-id vlan vlan-list
Configure the Use either command.
VLAN-to-MSTI mapping All VLANs in an MST region
table are mapped to MSTI 0 by
vlan-mapping modulo modulo
default.
1-17
Configure the MSTP Optional
revision level of the MST revision-level level
region 0 by default
Activate MST region

active region-configuration Required
configuration manually
Display all the
configuration information of check region-configuration Optional
the MST region
Display the currently
The display command can
effective MST region display stp region-configuration
be executed in any view.
configuration information
Two or more 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.
The configuration of MST regionrelated 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 regionrelated
configurations; instead, such configurations will take effect only after you:
z activate the MST regionrelated 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:
1-18
stp [ instance instance-id ] root Required
Specify the current device as
primary [ bridge-diameter
the root bridge of a specific By default, a device does not
bridge-number ] [ hello-time
spanning tree 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 ] root Required

Specify the current device
secondary [ bridge-diameter By default, a device does not
as a secondary root bridge
bridge-number ] [ hello-time function as a secondary root
of a specific spanning tree
centi-seconds ] bridge.
Note that:
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.
1-19
# 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 others 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.
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:

1-20
Configure the priority of the stp [ instance instance-id ] Optional

current device in a specified MSTI priority priority 32768 by default
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
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.
When a device becomes the root bridge of the CIST or MSTI of an MST region, the maximum hop in the
configuration BPDUs generated by this device defines the network diameter of the spanning tree. 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
1-21
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
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.
1-22
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.
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.
1-23
# 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.
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:
1-24
Enter Ethernet or interface Required
Layer-2 aggregate interface-type Use either command.
Enter interface view interface-number
interface view Configurations made in interface
or port group view will take effect on the current
view Enter port group port-group manual port only; configurations made in
view port-group-name port group view will take effect on all
Configure the maximum rate of the stp transmit-limit Optional

port(s) packet-number 10 by default
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 Ethernet 1/0 to 5.

[Sysname-Ethernet1/0] 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. Therefore, if you specify a port as an edge port, 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):


Layer-2 aggregate Use either command.
interface-number
Configurations made in
interface view interface view will take effect on
or port group the current port only;
view Enter port group port-group manual
configurations made in port
group view will take effect on all
1-25
Required
Configure the port(s) as edge port(s) stp edged-port enable All Ethernet ports are non-edge
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.
# Configure Ethernet1/0 to be an edge port.

[Sysname-Ethernet1/0] 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:

Enter Ethernet Required
or Layer-2 interface interface-type Use either command.
Enter aggregate interface-number
interface view Configurations made in
interface view interface view will take effect
or port group on the current port only;
view Enter port port-group manual configurations made in port
group view port-group-name group view will take effect on
all ports in the port group.
Optional
Setting the type of a connected stp point-to-point { auto | The default setting is auto;
link to P2P force-false | force-true } namely the port automatically
detects whether its link is
point-to-point.
1-26
z A Layer-2 aggregate interface 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 Ethernet 1/0 as connecting to a point-to-point link.

[Sysname-Ethernet1/0] stp point-to-point force-true
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:

Enter Layer-2 interface interface-type Use either command.
interface aggregate interface-number
interface view Configurations made in interface
view or view will take effect on the current
port group port only; configurations made in
port group view will take effect on
Configure the mode the port Optional
stp compliance { auto |
uses to recognize/send MSTP
dot1s | legacy } auto by default
packets
1-27
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 Ethernet 1/0 to receive and send standard-format MSTP packets.

[Sysname-Ethernet1/0] stp compliance dot1s
Enabling the Output of Port State Transition Information
Whether this function is enabled by default depends on the specific device model.
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:

Optional
Enable output of port state
stp port-log { all | instance Whether this function is
transition information of all
instance-id } enabled by default depends on
MSTIs or a particular MSTI
the specific device model.
1-28
Enabling the MSTP Feature
Follow these steps to enable the MSTP feature:

Required
Enable the MSTP feature for the Whether a device is MSTP-enabled
stp enable
device by default depends on the specific
device model.
interface view interface view Configurations made in interface
view port only; configurations made in
Enter port port-group manual
port group view will take effect on all
group view port-group-name
Optional
Enable the MSTP feature for the By default, MSTP is enabled for all
stp enable
port(s) ports after it is enabled for the device
globally.
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 devices CPU resources.
# Enable MSTP for the device and disable MSTP for port Ethernet 1/0.
[Sysname] stp enable
[Sysname-Ethernet1/0] 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.
1-29
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 standard used by
the default path costs for ports { dot1d-1998 | dot1t | legacy } the device depends on the
of the device specific device model.
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
1-30
Link speed Duplex state 802.1D-1998 802.1t Private standard
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 interface, 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:

interface view interface view Configurations made in interface
view port only; configurations made in
Enter port port-group manual
port group view will take effect on all
group view port-group-name
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.
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.
1-31
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:

Enter Enter Ethernet Required

interface
interface or Layer-2 Use either command.
interface-type
view or aggregate
interface-number Configurations made in interface view will
port interface view
take effect on the current port only;
group Enter port port-group manual configurations made in port group view will
view group view port-group-name take effect on all ports in the port group.
stp [ instance Optional

Configure a priority for the
instance-id ] port
port(s) 128 for all Ethernet ports by default.
priority 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.
# Set the priority of port Ethernet 1/0 to 16 in MSTI 1.

[Sysname-Ethernet1/0] 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.
1-32
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.
Performing mCheck globally
Follow these steps to perform global mCheck:
Perform mCheck stp mcheck Required
Performing mCheck in interface view
Follow these steps to perform mCheck in interface view:

Enter Ethernet or Layer-2 interface interface-type

aggregate interface view interface-number
1-33
Perform mCheck stp mcheck Required
Configuration Example
# Perform mCheck on port Ethernet 1/0.

1) Method 1: Perform mCheck globally.
[Sysname] stp mcheck
2) Method 2: Perform mCheck in interface view.
[Sysname-Ethernet1/0] stp mcheck
Configuring the VLAN Ignore Feature
This feature support varies by device.
Traffic on a VLAN in a complex network may be blocked by the spanning tree.

Figure 1-6 VLAN connectivity blocked by MSTP
As shown above, port A on Device A allows the traffic of VLAN 1 to pass through, and port C allows the
traffic of VLAN2 to pass through; port B on Device B allows the traffic of VLAN 1 to pass through, and
port D allows the traffic of VLAN 2 to pass through. Device A and Device B run MSTP, Device A is the
root bridge, and port A and port C on it are designated ports. Port B on Device B is the root port, and port
D is the blocked port. Traffic on VLAN 2 is blocked.
Enabling the VLAN Ignore feature for a VLAN can make ports of the VLAN forward packets normally
rather than comply with the calculated result of MSTP.
Follow these steps to configure VLAN Ignore:

Required
Enable VLAN Ignore for
stp ignored vlan vlan-list The maximum number of VLAN Ignore
the specified VLAN(s)
enabled VLANs varies by device.
1-34
Display VLAN Ignore
display stp ignored-vlan Available in any view
enabled VLANs
z Device A and Device B are directly connected;

z Ethernet 1/1 on Device A and Ethernet 1/2 on Device B allow the traffic of VLAN 1 to pass through.
Ethernet 1/3 on Device A and Ethernet 1/4 on Device B allow the traffic of VLAN 2 to pass through.
z Device A is the root bridge, and both Device A and Device B run MSTP. Ethernet 1/4 on Device B
is blocked, causing traffic block on VLAN 2.
z Configure VLAN Ignore to make the blocked port forward packets.
Network diagram
Figure 1-7 VLAN Ignore configuration
1) Enable VLAN Ignore on Device B

# Enable VLAN Ignore on VLAN 2.
[DeviceB] stp ignored vlan 2
# Display the VLAN Ignore enabled VLAN.
[DeviceB] display stp ignored-vlan
STP-Ignored VLAN: 2
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.
1-35
Enabling the Digest Snooping feature on the port connecting the local device to another vendors device
in the same MST region can make the two devices communicate with other.
Associated devices of different vendors are interconnected and run MSTP.
Follow these steps to configure Digest Snooping:

aggregate interface-number
Enter interface interface view Configurations made in
view or port interface view will take effect on
group view the 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 vendors 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.
1-36
z Device A and Device B connect to a third-partys 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.
Network diagram
Figure 1-8 Digest Snooping configuration
1) Enable Digest Snooping on Device A.

# Enable Digest Snooping on Ethernet 1/0.
[DeviceA-Ethernet1/0] stp config-digest-snooping
# Enable global Digest Snooping.

[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 devices 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-9 and Figure 1-10 show the rapid state transition mechanism on MSTP and RSTP designated
ports.
1-37
Figure 1-9 Rapid state transition of an MSTP designated port
Figure 1-10 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 devices 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.
Follow these steps to configure No Agreement Check:
1-38

interface view Configurations made in
interface or interface view will take effect
port group on the current port only;
view Enter port port-group manual configurations made in port
group view port-group-name group view will take effect on
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-partys device that has different MSTP implementation. Both switches
are in the same region.
z Another vendors device is the regional root bridge, and Device A is the downstream device.
Network diagram
Figure 1-11 No Agreement Check configuration

Third-party device
Eth1/1
Eth1/0
Root port
Designated port
Device A
# Enable No Agreement Check on Ethernet 1/0 of Device A.

[DeviceA-Ethernet1/0] stp no-agreement-check
1-39
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
z Support for the BPDU guard, root guard and loop guard functions depends on the device model.
z Among loop guard, root guard and edge port settings, only one function can take effect on the
same port at the same time.
Configuration prerequisites
MSTP has been correctly configured on the device.
Enabling BPDU Guard
z Support for this feature depends on the device model.

z We recommend that you enable BPDU guard if your device supports this function.
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.
Follow these steps to enable BPDU guard:

Enable the BPDU guard Required

stp bpdu-protection
function for the device Disabled by default
1-40
Enabling Root Guard
z Support for this feature depends on the specific device model.

z We recommend that you enable root guard if your device supports this function.
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.
Follow these steps to enable root guard:

interface-number
interface view interface view will take effect on
or port group the current port only;
view Enter port group view
port-group manual
port-group-name
group view will take effect on all
Enable the root guard function for the Required

stp root-protection
port(s) Disabled by default
Enabling Loop Guard
z Support for this feature depends on the specific device model.

z We recommend that you enable loop guard if your device supports this function.
1-41
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 guardenabled 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.
Follow these steps to enable loop guard:

interface-number
interface view interface view will take effect
or port group on the current port only;
group view will take effect on
Enable the loop guard function for Required

stp loop-protection
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:

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

View information about abnormally Available in any
display stp abnormal-port
blocked ports view
View information about ports blocked by Available in any
display stp down-port
STP protection actions view
View the information On a centralized display stp [ instance instance-id ] Available in any
of port role device history view
calculation history
for the specified On a distributed display stp [ instance instance-id ] Available in any
MSTI or all MSTIs device history [ slot slot-number ] view
View the statistics of On a centralized display stp [ instance instance-id ] Available in any
TC/TCN BPDUs device tc view
sent and received
by all ports in the On a distributed display stp [ instance instance-id ] Available in any
specified MSTI or all device tc [ slot slot-number ] view
MSTIs
On a centralized display stp [ instance instance-id ] Available in any
View the status device [ interface interface-list ] [ brief ] view
information and
statistics information display stp [ instance instance-id ]
On a distributed Available in any
of MSTP [ interface interface-list | slot
device view
slot-number ] [ brief ]
View the MST region configuration Available in any
display stp region-configuration
information that has taken effect view
View the root bridge information of all Available in any
display stp root
MSTIs view
View the list of VLANs with VLAN Ignore Available in any
display stp ignored-vlan
enabled view
Available in user
Clear the statistics information of MSTP reset stp [ interface interface-list ]
view
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
1-43
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-12 Network diagram for MSTP configuration
Permit: beside each link in the figure is followed by the VLANs the packets of which are permitted to
pass this link.
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.
1-44
[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] 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
# 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] stp region-configuration
1-45
[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
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
1-46
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-47
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-7
Assigning a Trunk Port to a VLAN1-8
Assigning a Hybrid Port to a VLAN 1-9
MAC-Based VLAN Configuration1-10
Introduction to MAC-Based VLAN1-10
Approaches to Creating MAC Address-to-VLAN Mappings1-10
Configuring a MAC Address-Based VLAN 1-11
Protocol-Based VLAN Configuration1-11
Introduction to Protocol-Based VLAN1-11
Configuring a Protocol-Based VLAN 1-12
IP Subnet-Based VLAN Configuration 1-13
Introduction1-13
Configuring an IP Subnet-Based VLAN 1-14
Displaying and Maintaining VLAN1-15
VLAN Configuration Example 1-16
2 Super VLAN Configuration 2-1

Overview 2-1
Configuring a Super VLAN2-1
Displaying and Maintaining Super VLAN 2-2
Super VLAN Configuration Example2-2
3 Isolate-User-VLAN Configuration 3-1

Overview 3-1
Configuring Isolate-User-VLAN3-2
Displaying and Maintaining Isolate-User-VLAN3-3
Isolate-User-VLAN Configuration Example3-3
4 Voice VLAN Configuration4-1

Overview 4-1
Voice VLAN Mode 4-2
Security Mode and Normal Mode for the Voice VLAN 4-3
Configuring Voice VLAN 4-3
Configuring a Port to Operate in Automatic Voice VLAN Mode4-3
Configuring a Port to Operate in Manual Voice VLAN Mode 4-4
i
Displaying and Maintaining Voice VLAN4-5
Voice VLAN Configuration Examples 4-6
Automatic Voice VLAN Mode Configuration Example 4-6
Manual Voice VLAN Mode Configuration Example4-7
ii

MAC-based VLAN NO NO NO NO
Protocol-based
NO NO NO NO
VLAN
IP subnet-based
NO NO NO NO
VLAN
Super VLAN NO NO NO NO
Isolate-user-vlan NO NO NO NO
Voice VLAN YES YES YES YES
z The MSR series routers support Layer-2 Ethernet subinterfaces.
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.
1-1
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) 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.
1-2
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 with a value of 0x8100 indicates that the frame is VLAN-tagged.
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.
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.
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:
1-3
Optional
vlan { vlan-id1 [ to vlan-id2 ] |
Create VLANs Using this command can create multiple
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 broadcast Optional

broadcast-suppression
suppression for the Broadcast traffic is not suppressed by
ratio
VLAN default.

description of the description text VLAN ID is used by default, for example,
current VLAN VLAN 0001.
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 cannot be removed with the undo
vlan command. To do that, remove the remote mirroring VLAN configuration from it first.
z Support for the broadcast-suppression command depends on the device model.
z You can configure broadcast suppression to limit the size of broadcast traffic permitted to pass
through a VLAN. When the broadcast traffic exceeds the upper threshold, the exceeding broadcast
traffic will be dropped.
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.
1-4
Follow these steps to configure basic settings of a VLAN interface:
Create a VLAN Required

interface vlan-interface
interface and enter If the VLAN interface already exists, you
vlan-interface-id
VLAN interface view enter its view directly.
Optional
Assign an IP address ip address ip-address
to the VLAN interface { mask | mask-length } [ sub ] No IP address is assigned to any VLAN

description of the description text VLAN interface name is used by default, for
VLAN interface 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
Bring up the VLAN
undo shutdown goes down if all ports in the VLAN go down.
interface
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.
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 a hybrid port allows traffic of multiple VLANs to pass
through untagged while a trunk port allows only traffic of the default VLAN to pass through untagged.
1-5
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.
z Do not set the voice VLAN as the default VLAN of a port in automatic voice VLAN 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 outbound

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

VLAN ID is the same as
Tag the frame the default VLAN ID. Remove the default VLAN tag and
Access with the default
z Drop the frame if its VLAN send the frame.
VLAN tag.
ID is different from the
default VLAN ID.
z Remove the tag and send the
frame if the frame carries the
Check whether default VLAN tag.
Trunk the default VLAN z Send the frame without
is carried on the removing the tag if its VLAN is
port: z Receive the frame if its carried on the port but is
VLAN is carried on the different from the default one.
z If yes, tag the port.
frame with the z Drop the frame if its VLAN Send the frame if its VLAN is
default VLAN is not carried on the port. carried on the port. The frame is
tag. sent with the VLAN tag removed
Hybrid z If not, drop the or intact depending on your
frame. configuration with the port hybrid
vlan command. This is true of the
default VLAN.
1-6
Assigning an Access Port to a VLAN
You can assign an access port to a VLAN in VLAN view, Ethernet 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.
Assign one or multiple Required
access ports to the current port interface-list
VLAN By default, all ports belong to VLAN 1.
2) In Ethernet interface or port group view

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

Enter Ethernet interface interface-type Required
interface view interface-number Use either command.
Enter Layer-2 interface z In Ethernet interface view, the
aggregate bridge-aggregation subsequent configurations apply
Enter interface view interface-number to the current port
interface z In port group view, the
view or port subsequent configurations apply
group view to all ports in the port group.
Enter port port-group manual z In Layer-2 aggregate interface
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 vlan-id By default, all access ports belong to
port(s) to a VLAN
VLAN 1.
1-7
z Before assigning an access port to a VLAN, create the VLAN first.
z The link type of Layer 2 Ethernet subinterfaces is fixed to access. You can assign them to a VLAN
in either of the two approaches above. Support for Layer 2 Ethernet subinterfaces depends on the
device model.
z After you configure a command on a Layer-2 aggregate interface, the system starts applying the
configuration to the aggregate interface and its aggregation member ports. If the system fails to do
that on the aggregate interface, it stops applying the configuration to the aggregation member ports.
If it fails to do that on an aggregation member port, it simply skips the port and moves to the next
port.
Assigning a Trunk Port to a VLAN
A trunk port can carry multiple VLANs. You can assign it to a VLAN in Ethernet interface view or port
group view.
Follow these steps to assign a trunk port to one or multiple VLANs:

Enter Required
Ethernet Use either command.
interface-number
interface view
z In Ethernet interface view, the
Enter Layer-2 interface subsequent configurations apply
Enter aggregate bridge-aggregation to the current port
interface view interface view interface-number z In port group view, the
or port group subsequent configurations apply
view to all ports in the port group.
z In Layer-2 aggregate interface
Enter port port-group manual view, the subsequent
group view port-group-name configurations apply to the
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.
Optional
Configure the default VLAN of port trunk pvid vlan
the trunk port(s) vlan-id VLAN 1 is the default VLAN by
default.
1-8
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.
port.
Assigning a Hybrid Port to a VLAN
A hybrid port can carry multiple VLANs. You can assign it to a VLAN in Ethernet interface view or port
group view.
Follow these steps to assign a hybrid port to one or multiple VLANs:


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

the hybrid port vlan-id VLAN 1 is the default by default.
1-9
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.
port.
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.
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-toVLAN 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.
1-10
Configuring a MAC Address-Based VLAN
z Support for this feature depends on your device model.

z MAC-based VLANs are available only on hybrid ports.
Follow these steps to configure a MAC-based VLAN:

Required
mac-vlan mac-address mac-addr
Associate MAC addresses Support for the mask keyword
[ mask mac-mask ] vlan vlan-id
with a VLAN in this command depends on
[ priority priority ]
the device model.
Enter Use either command.
Enter Ethernet In Ethernet interface view, the
interface-number
Ethernet interface view subsequent configurations
interface apply only to the current port;
view or in port group view, the
port 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.
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.
Protocol-Based VLAN Configuration

Introduction to Protocol-Based VLAN
z Support for protocol-based VLANs depends on the device model.

z Protocol-based VLANs are only applicable on hybrid ports.
1-11
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:

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 | raw | snap } | mode
Create a protocol template for
{ ethernetii etype etype-id | llc Required
the VLAN
{ dsap dsap-id [ ssap ssap-id ] |
ssap ssap-id } | snap etype
etype-id } }
Exit VLAN view quit Required
Enter Layer-2 z In Ethernet interface view,
interface bridge-aggregation
aggregate the subsequent
interface-number
interface view configurations apply to the
current port
Enter
z In port group view, the
interface
subsequent configurations
view or port
apply to all ports in the port
group view
group.
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
1-12
Configure the port(s) to
permit the packets of the
port hybrid vlan vlan-id-list
specified protocol-based Required
untagged
VLANs to pass through
untagged
Associate the hybrid port(s) port hybrid protocol-vlan vlan
with the specified vlan-id { protocol-index [ to Required
protocol-based VLAN protocol-end ] | all }
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.
port.
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.
1-13
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
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.
Enter Layer-2 interface z In Ethernet interface view,
aggregate bridge-aggregation the subsequent
interface view interface-number configurations apply to the
current port
Enter interface z In port group view, the
view or port subsequent configurations
group view apply to all ports in the port
group.
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
1-14
After you configure a command on a Layer-2 aggregate interface, the system starts applying the
configuration to the aggregate interface and its aggregation member ports. If the system fails to do that
on the aggregate interface, it stops applying the configuration to the aggregation member ports. If it fails
to do that on an aggregation member port, it simply skips the port and moves to the next port.
Displaying and Maintaining VLAN

To do... Use the command Remarks
display vlan [ vlan-id1 [ to vlan-id2 ] |
all | dynamic | interface
Display VLAN information interface-type Available in any view
interface-number.subnumber |
reserved | static ]
Display VLAN interface display interface vlan-interface
information [ vlan-interface-id ]
display mac-vlan { all | dynamic |
Display MAC address-to-VLAN
mac-address mac-addr [ 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
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
VLAN information and IP display ip-subnet-vlan interface
subnet indexes of specified { interface-list | all }
ports
reset counters interface

Clear statistics on a port Available in user view
[ interface-type [ interface-number ] ]
The reset counters interface command can be used to clear statistics on a VLAN interface. For more
information, refer to Ethernet Interface Commands in the Access Volume.
1-15
VLAN Configuration Example
z Device A connects to Device B through a trunk port Ethernet 1/0;

z The default VLAN ID of Ethernet 1/0 is 100;
z Ethernet 1/0 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
# Create VLAN 2, VLAN 6 through VLAN 50, and VLAN 100.
[DeviceA] vlan 2
[DeviceA] vlan 100
[DeviceA-vlan100] vlan 6 to 50
Please wait... Done.
# Enter Ethernet 1/0 interface view.

[DeviceA] interface Ethernet 1/0
# Configure Ethernet 1/0 as a trunk port and configure its default VLAN ID as 100.
[DeviceA-Ethernet1/0] port trunk pvid vlan 100
# Configure Ethernet 1/0 to deny the packets of VLAN 1 (by default, the packets of VLAN 1 are
permitted to pass through on all the ports).
[DeviceA-Ethernet1/0] undo port trunk permit vlan 1
# Configure Ethernet 1/0 to permit packets from VLAN 2, VLAN 6 through VLAN 50, and VLAN 100 to
pass through.
[DeviceA-Ethernet1/0] port trunk permit vlan 2 6 to 50 100
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 Ethernet 1/0 of Device A to verify the above configurations.
<DeviceA> display interface ethernet 1/0
Ethernet1/0 current state: UP
1-16
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0000-5600-0000
Description: Ethernet1/0 Interface
Loopback is not set
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 1500
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
Input (normal): 0 packets, 0 bytes
Input: 0 input errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 frame, 0 overruns, 0 aborts
0 ignored, 0 parity errors
Output (total): 0 packets, 0 bytes
0 broadcasts, 0 multicasts, 0 pauses
Output (normal): 0 packets, 0 bytes
0 broadcasts, 0 multicasts, 0 pauses
Output: 0 output errors, 0 underruns, 0 buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, 0 no carrier
The output above shows that:

z The port (Ethernet 1/0) 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
Support for super VLAN depends on the device model.
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
2-1
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 does not exist, this command
vlan-interface-id
creates the VLAN interface
first.
Required
Configure the IP address of the ip address ip-address { mask | By default, the IP address of a
VLAN interface mask-length } [ sub ] 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, dynamic routing, and NAT 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 Ethernet 1/1 and Ethernet 1/2 to VLAN 2, Ethernet 1/3 and Ethernet 1/4 to VLAN 3, and
Ethernet 1/5 and Ethernet 1/6 to VLAN 5.
2-2
z The sub-VLANs are isolated at Layer 2 but connected at Layer 3.
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] 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 Ethernet 1/1 and Ethernet 1/2 to it.
[Sysname] vlan 2
[Sysname-vlan2] port ethernet 1/1 ethernet 1/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
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: not configured
Description: VLAN 0010
Tagged Ports: none
Untagged Ports: none
VLAN ID: 2
VLAN Type: static
It is a Sub VLAN.
Tagged Ports: none
Untagged Ports:
Ethernet1/1 Ethernet1/2
VLAN ID: 3
VLAN Type: static
It is a Sub VLAN.
Tagged Ports: none
Untagged Ports:
VLAN ID: 5
VLAN Type: static
It is a Sub VLAN.
Tagged Ports: none
Untagged Ports:
<Sysname>
2-4
3 Isolate-User-VLAN Configuration
When configuring 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
Support for isolate-user-VLAN depends on the device model.
Overview
The 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.
z The isolate-user-VLAN is mainly used for upstream data exchange. An isolate-user-VLAN can
have multiple secondary VLANs associated with it. The upstream device is aware of only the
isolate-user-VLAN but not the secondary VLANs. In this way, network configurations are simplified
and VLAN resources are saved.
z Secondary VLANs are used for connecting users. Secondary VLANs are isolated from each other
at Layer 2. 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
3-1
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) 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:

Create a VLAN and enter VLAN
vlan vlan-id
view
Configure the VLAN as an
isolate-user-vlan enable Required
isolate-user-VLAN
Assign ports to the

isolate-user-VLAN and Access Refer to Assigning an Access Port to a
ensure that at least one port VLAN Use either
port takes the approach.
isolate-user-VLAN as its Hybrid Refer to Assigning a Hybrid Port to a
default VLAN port VLAN
Create secondary VLANs vlan { vlan-id1 [ to vlan-id2 ] | all } Required
Assign ports to each
secondary VLAN and Access Refer to Assigning an Access Port to a
ensure that at least one port VLAN
Required to choose
port in a secondary
either
VLAN takes the
secondary VLAN as its Hybrid Refer to Assigning a Hybrid Port to a
default VLAN port VLAN
isolate-user-vlan isolate-user-vlan-id
Associate the isolate-user-VLAN
secondary secondary-vlan-id [ to Required
with the specified secondary VLANs
secondary-vlan-id ]
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 Ethernet 1/5 to
VLAN 5, and associate VLAN 5 with secondary VLANs VLAN 2 and VLAN 3. Assign Ethernet 1/2 to
VLAN 2 and Ethernet 1/1 to VLAN 3.
z Configure VLAN 6 on Device C as an isolate-user-VLAN, assign the uplink port Ethernet 1/5 to
VLAN 6, and associate VLAN 6 with secondary VLANs VLAN 3 and VLAN 4. Assign Ethernet 1/3 to
VLAN 3 and Ethernet 1/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
Eth 1/3
Host A
1/1 Eth Host C
Eth1/5 Eth1/5
Eth
1/2 1/4
Eth Device C
Device B Device A
Host B Host D
VLAN 2 VLAN 4
The following part provides only the configuration on Device B and Device C.
# Configure the isolate-user-VLAN.
[DeviceB] vlan 5
[DeviceB-vlan5] isolate-user-vlan enable
[DeviceB-vlan5] port ethernet 1/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] vlan 6
[DeviceC-vlan6] isolate-user-vlan enable
[DeviceC-vlan6] port ethernet 1/5
# 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
Tagged Ports: none
Untagged Ports:
Ethernet1/1 Ethernet1/2 Ethernet1/5
VLAN ID: 2
VLAN Type: static
Isolate-user-VLAN type : secondary
3-4
Tagged Ports: none
Untagged Ports:
VLAN ID: 3
VLAN Type: static
Isolate-user-VLAN type : secondary
Tagged Ports: none
Untagged Ports:
[DeviceB]
3-5
4 Voice VLAN Configuration
When configuring voice VLAN, go to these sections for information you are interested in:
z Overview
z Configuring 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 the 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 vendors 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 00d0-1e00-0000 Pingtel phone
5 0060-b900-0000 Philips/NEC phone
6 00e0-7500-0000 Polycom phone
7 00e0-bb00-0000 3Com phone
z 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.
z You can remove the default OUI address of a device manually and then add new ones manually.
4-1
Voice VLAN Mode
Voice VLAN may operate in automatic mode or manual mode. The mode here refers to how a port joins
a voice VLAN.
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 the voice VLAN are automatically performed by the
system.
z In manual mode, you should assign an IP phone access port to the 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 the 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
Port voice
Voice traffic type Port link type
VLAN 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
Automatic Tagged voice traffic
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
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
is the voice VLAN and that the voice VLAN is permitted
Untagged voice traffic
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
z 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 If an IP phone sends untagged voice traffic, to realize the voice VLAN feature, you must configure
the default VLAN of the access port as the voice VLAN. In this case 802.1 x authentication function
cannot be realized.
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 for the Voice VLAN
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 Voice VLAN

z Create the corresponding VLAN before configuring the voice VLAN;

z You need not create VLAN 1 as it is the default VLAN. However, you cannot configure VLAN 1 as a
voice VLAN.
Configuring a Port to Operate in Automatic Voice VLAN Mode
Follow these steps to configure a port to operate in automatic voice VLAN mode:
4-3
Optional
1440 minutes by default.
Set the voice VLAN aging
voice vlan aging minutes The voice VLAN aging time configuration
time
is only applicable on ports in automatic
voice VLAN mode.
Enable the voice VLAN voice vlan security Optional

security mode enable Enabled by default
Optional
voice vlan mac-address By default, each voice VLAN has default
Add a recognizable OUI
oui mask oui-mask OUI addresses configured. Refer to
address
[ description text ] Table 4-1 for the default OUI addresses
of different vendors.
Enable voice VLAN
voice vlan vlan-id enable Required
globally

Optional
Configure the port to
Automatic voice VLAN mode by default.
operate in automatic voice voice vlan mode auto
VLAN mode The voice VLAN modes of different ports
are independent of one another.
Enable voice VLAN on the Required

voice vlan enable
port 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 Protocol-Based VLAN Configuration.
z Do not configure the default VLAN of a port in automatic voice VLAN mode as the voice VLAN.
z Only the voice vlan security enable command or the undo voice vlan security enable
command issued before the voice vlan vlan-id enable command takes effect.
Configuring a Port to Operate in Manual Voice VLAN Mode
Follow these steps to configure the port to operate in manual voice VLAN mode:

Enable the voice VLAN security Optional

voice vlan security enable
mode Enabled by default
4-4
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

undo voice vlan mode auto
manual voice VLAN mode Disabled by default
Refer to Assigning an Access

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

Trunk port
voice VLAN 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
z At a time, only one existing static VLAN can be configured as the voice VLAN on a device.
z Voice VLAN is mutually exclusive with Link Aggregation Control Protocol (LACP) on a port.
z Only the voice vlan security enable command or the undo voice vlan security enable
command issued before the voice vlan vlan-id enable command takes effect.
z To make voice VLAN take effect on a port which is enabled with voice VLAN and operates in
manual voice VLAN mode, you need to assign the port to the voice VLAN manually.
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
4-5
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 Ethernet 1/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.
Network diagram
Figure 4-1 Network diagram for automatic voice VLAN mode configuration
Device A Device B
Internet
VLAN 2
Eth1/1 Eth2/1
VLAN 2
010-1001 0755-2002
OUI: 0011-2200-0000
Mask: ffff-ff00-0000
# 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 description test
# Enable voice VLAN globally.

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

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

[DeviceA-Ethernet1/1] voice vlan enable
[DeviceA-Ethernet1/1] return
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
00d0-1e00-0000 ffff-ff00-0000 Pingtel phone
0060-b900-0000 ffff-ff00-0000 Philips/NEC 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
--------------------------------
Ethernet1/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 Ethernet 1/1 as a hybrid port.
z Configure Ethernet 1/1 to operate in manual voice VLAN mode. Configure Ethernet 1/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.
4-7
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.)
[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 Ethernet 1/1 to operate in manual voice VLAN mode.

[DeviceA-Ethernet1/1] undo voice vlan mode auto
# Configure Ethernet 1/1 as a hybrid port.

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

[DeviceA-Ethernet1/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
4-8
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
0011-2200-0000 ffff-ff00-0000 test
00d0-1e00-0000 ffff-ff00-0000 Pingtel phone
0060-b900-0000 ffff-ff00-0000 Philips/NEC 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
--------------------------------
Ethernet1/1 MANUAL
4-9
Table of Contents
1 Port Isolation Configuration 1-1

Introduction to Port Isolation 1-1
Configuring the Isolation Group for a Single-Isolation-Group Device1-3
Assigning a Port to the Isolation Group1-3
Specifying the Uplink Port for the Isolation Group 1-4
Configuring an Isolation Group for a Multiple-Isolation-Group Device 1-5
Adding a Port to an Isolation Group 1-5
Specifying the Uplink Port for an Isolation Group 1-6
Displaying and Maintaining Isolation Groups1-6
Port Isolation Configuration Example (on Single-isolation-group Devices Supporting Uplink Port) 1-7
Networking Requirement 1-7
Networking diagram1-7
Configuration procedure 1-7
Port Isolation Configuration Example (on Multiple-isolation-group Devices Supporting Uplink Port) 1-8
Networking Requirement 1-8
Networking diagram1-8
i

Assign a port to the
Configure a YES YES YES YES
isolation group
single
isolation Specify the uplink
group for the isolation NO NO NO NO
group
Assign a port to an
Configure NO NO NO NO
isolation group
multiple
isolation Specify the uplink
groups for an isolation NO NO NO NO
group
1 Port Isolation Configuration
When configuring port isolation, go to these sections for information you are interested in:
z Introduction to Port Isolation
z Configuring the Isolation Group for a Single-Isolation-Group Device
z Configuring an Isolation Group for a Multiple-Isolation-Group Device
z Port Isolation Configuration Example (on Single-isolation-group Devices Supporting Uplink Port)
z Port Isolation Configuration Example (on Multiple-isolation-group Devices Supporting Uplink Port)
Introduction to Port Isolation

To implement Layer 2 isolation, you can add different ports to different VLANs. However, this wastes
limited VLAN resources. With port isolation, ports can be isolated within the same VLAN by assigning
them to isolation groups. This provides you more secure and flexible networking schemes.
Currently:
z Some devices support only one isolation group that is created automatically by the system as
isolation group 1. These devices are referred to as single-isolation-group devices. Users can
neither remove the isolation group nor create other isolation groups on such devices.
1-1
z Some devices support multiple isolation groups which can be configured manually. These devices
are referred to as multiple-isolation-group devices. The number of supported isolation groups
z There is no restriction on the number of ports to be assigned to an isolation group.
z The member port of an aggregation group cannot be configured as the uplink port of an isolation
group and vice versa. If you assign a port to an aggregation group and to an isolation group as the
uplink port at the same time, the aggregation group configuration will take effect and the isolation
group configuration will be removed for backward configuration file compatibility. For detailed
information about link aggregation, refer to Link Aggregation Configuration in the Access Volume.
z The member port of a service loopback group cannot be configured as the uplink or ordinary port of
an isolation group and vice versa.
z Support for a single isolation group or multiple isolation groups varies with devices.
Port isolation is independent of the VLAN the port belongs to. For ports belonging to different VLANs,
Layer 2 data can pass through them only from the ordinary ports to the uplink port in the same isolation
group unidirectionally. Within the same VLAN, there are two types of connectivity of Layer 2 data on
ports within and outside the isolation group:
z On a device supporting uplink port, the supported Layer 2 data transmission between different
types of ports is shown in Figure 1-1.
z On a device not supporting uplink port, Layer 2 data transmission between ports within and outside
the isolation group is supported.
Figure 1-1 Layer 2 traffic forwarding for an isolation group (with uplink port supported)
1-2
The arrows in the above figure indicate the transmission direction of Layer 2 data.
Configuring the Isolation Group for a Single-Isolation-Group Device

Assigning a Port to the Isolation Group
Follow these steps to add a port to the isolation group:


interface view interface-number Use one of the commands.
Enter aggregate bridge-aggregation subsequent configurations apply to
interface interface view interface-number the current port.
view or, z In Layer-2 aggregate interface view,
port group the subsequent configurations apply
view to the Layer-2 aggregate interface
Enter port port-group manual and all its member ports.
group view port-group-name z In port group view, the subsequent
configurations apply to all ports in the
port group.
Assign the port or ports to the Required
isolation group as an port-isolate enable No ports are added to the isolation group
ordinary port or ports by default.
1-3
Specifying the Uplink Port for the Isolation Group
Follow these steps to specify the uplink port for the isolation group:

Required
Use either command.
interface
Enter Ethernet z In Ethernet interface view, the
interface-type
interface view subsequent configurations apply to
interface-number
the current port
z In Layer-2 aggregate interface view,
only the Layer-2 aggregate interface
Enter Ethernet or
is configured as the uplink port of the
Layer-2 aggregate
isolation group. You can configure
interface view
the member ports of the aggregation
interface group corresponding to the Layer-2
Enter Layer-2
bridge-aggregati aggregate interface as ordinary ports
aggregate
on of the isolation group. Thus
interface view
interface-number configured, these ports are set to the
unselected state in the aggregation
group, that is, these ports cannot
forward user traffic.
current port as the
port-isolate uplink-port An isolation group has no uplink port by
uplink port of the
isolation group default.
z The support for uplink port varies with device models.

z An isolation group can have only one uplink port. The uplink port you configured for an isolation
group can overwrite the previous one, if any.
z You can add a port to multiple isolation groups as an ordinary port. However, you cannot configure
an ordinary port in an isolation group as the uplink port in any isolation group.
z You cannot configure the uplink port of an isolation group as an ordinary port in any isolation group
or the uplink port in any other isolation group.
group and vice versa.
1-4
Configuring an Isolation Group for a Multiple-Isolation-Group
Device
Adding a Port to an Isolation Group
Follow these steps to configure an isolation group for a multiple-isolation-group device:

port-isolate group
Create an isolation group Required
group-number
interface view interface-number Use one of the commands.
Enter aggregate bridge-aggregation subsequent configurations apply to
interface interface view interface-number the current port
view, or
z In Layer-2 aggregate interface view,
port
the subsequent configurations apply
group
to the Layer-2 aggregate interface and
view Enter port port-group manual all its member ports.
group view port-group-name z In port group view, the subsequent
configurations apply to all ports in the
port group.
Add the port/ports to an Required
port-isolate enable
isolation group as an No ports are added to an isolation group
group group-number
ordinary port/ordinary ports by default.
1-5
Specifying the Uplink Port for an Isolation Group
Follow these steps to specify the uplink port for an isolation group:

Enter Required
interface
Ethernet Use either command.
interface-type
interface
interface-number z In Ethernet interface view, the subsequent
view
Enter configurations apply to the current port
Ethernet z In Layer-2 aggregate interface view, only
interface the Layer-2 aggregate interface is
view or configured as the uplink port of the
Layer-2 Enter isolation group. You can configure the
aggregate layer-2 interface member ports of the aggregation group
interface aggregate bridge-aggregation corresponding to the Layer-2 aggregate
view interface interface-number interface as ordinary ports of the isolation
view group. Thus configured, these ports are set
to the unselected state in the aggregation
group, that is, these ports cannot forward
user traffic.
Assign the current port port-isolate Required
to an isolation group as uplink-port group An isolation group has no uplink port by
the uplink port group-number default.
z Support for uplink port varies with device models.

z An isolation group can have only one uplink port. When a user configures multiple ports as the
uplink port, only the last one prevails.
z When a port has already been configured as an ordinary port for an isolation group, it cannot be
configured as an uplink port, and vice versa.
group and vice versa.
Displaying and Maintaining Isolation Groups

Display the isolation group
information on a display port-isolate group Available in any view
single-isolation-group device
Display the isolation group
display port-isolate group
information on a Available in any view
[ group-number ]
multiple-isolation-group device
1-6
Port Isolation Configuration Example (on Single-isolation-group
Devices Supporting Uplink Port)
Networking Requirement
z Users Host A, Host B, and Host C are connected to Ethernet 1/1, Ethernet 1/2, and Ethernet 1/3 of
Device.
z Device is connected to the Internet through Ethernet 1/0.
z Ethernet 1/1, Ethernet 1/2, Ethernet 1/3, and Ethernet 1/0 belong to the same VLAN. It is desired
that Host A, Host B, and Host C cannot communicate with each other at Layer 2, but can access
the Internet.
Networking diagram
Figure 1-2 Networking diagram for port isolation configuration
Internet
Eth1/0
Device
Eth1/1 Eth1/3
Eth1/2
Host A Host B Host C
# Add ports Ethernet 1/1, Ethernet 1/2 and Ethernet 1/3 to the isolation group.
<Device> system-view
[Device] interface ethernet 1/1
[Device-Ethernet1/1] port-isolate enable
[Device-Ethernet1/1] quit
# Configure port Ethernet 1/0 as the uplink port of the isolation group.
[Device-Ethernet1/0] port-isolate uplink-port
[Device-Ethernet1/0] return
# Display the information about the isolation group.
1-7
<Device> display port-isolate group
Port-isolate group information:
Uplink port support: YES
Group ID: 1
Uplink port: Ethernet1/0
Group members:
Port Isolation Configuration Example (on Multiple-isolation-group

Devices Supporting Uplink Port)
Networking Requirement
z Users Host A, Host B, and Host C are connected to Ethernet 1/1, Ethernet 1/2, and Ethernet 1/3 of
Device.
z Device is connected to the Internet through Ethernet 1/0.
z Ethernet 1/1, Ethernet 1/2, Ethernet 1/3, and Ethernet 1/0 belong to the same VLAN. It is desired
that Host A, Host B, and Host C cannot communicate with each other at Layer 2, but can access
the Internet.
Networking diagram
Figure 1-3 Networking diagram for port isolation configuration
Internet
Eth1/0
Device
Eth1/1 Eth1/3
Eth1/2
# Create isolation group 2.

[Device] port-isolate group 2
# Add Ethernet 1/1, Ethernet 1/2, and Ethernet 1/3 to isolation group 2.
[Device-Ethernet1/1] port-isolate enable group 2
1-8
# Configure port Ethernet 1/0 as the uplink port of isolation group 2.

[Device-Ethernet1/0] port-isolate uplink-port group 2
[Device-Ethernet1/0] return
# Display information of isolation group 2.

<Device> display port-isolate group 2
Port-isolate group information:
Uplink port support: YES
Group ID: 2
Uplink port: Ethernet1/0
Group members:
1-9
Table of Contents
1 Dynamic Route Backup Configuration1-1

Overview 1-1
Introduction to Dynamic Route Backup 1-1
Features of Dynamic Route Backup1-1
Workflow of Dynamic Route Backup 1-2
Dynamic Route Backup Configuration 1-2
Creating a Dynamic Route Backup Group 1-2
Enabling the Dynamic Route Backup Function on a Backup Interface1-3
Configuring the Delay for Disconnecting a Backup Link 1-3
Dynamic Route Backup Configuration Examples 1-4
Example I1-4
Example II1-6
Example III1-8
Configuration Example for Using One Dynamic Route Backup Group to Monitor Multiple Network
Segments 1-11
i
1 Dynamic Route Backup Configuration
When configuring dynamic route backup, go to these sections for information you are interested in:
z Overview
z Dynamic Route Backup Configuration
z Dynamic Route Backup Configuration Examples
Currently, the dynamic route backup function is available to the following dialup interfaces: dialer
interfaces, PRI interfaces, BRI interfaces, serial interfaces operating in the asynchronous mode, AM
interfaces, and AUX interfaces.
Overview
Introduction to Dynamic Route Backup
As a new way of route backup, the dynamic route backup function employs dial control center (DCC) to
dynamically maintain dialup links. It can provide backup for dialup links based on routes.
The dynamic route backup function combines the backup function and the routing function. It provides
you with reliable connections and standard dial-on-demand services.
Features of Dynamic Route Backup
The dynamic route backup function is mainly used to provide backup for dynamic routes, and moreover,
it can also provide backup for static routes and directly-connected routes.
The dynamic route backup function is appropriate for implementations with multiple interfaces and
multiple routers, and it is not dedicated to a specific interface or link.
With the dynamic route backup function enabled, the backup link will be activated automatically when
the primary link fails. The primary-backup switchover does not incur dialup delay (the route
convergence time not counted in).
1-1
The dynamic route backup function is routing protocol-independent. It can collaborate with Routing
Information Protocol version 1 (RIPv1), RIPv2, Open Shortest Path First (OSPF), Intermediate
System-Intermediate System (IS-IS), and Border Gateway Protocol (BGP). However, some routing
protocols (such as BGP) use the optimal routes by default. So with BGP employed, when the backup
link is activated due to a failure of the primary link to the monitored network segment, the device will
learn routes to the monitored network segment through BGP. When the primary link resumes, the
device will learn routes to the monitored network segment through BGP too. However, the routes that
the primary link learns may be less optimal than what the backup link learns. As a result, the latter
remains valid, dynamic route monitoring fails, and the backup link-to-primary link switchover fails.
To address this problem, you can take the following measures.
z Making sure the IP address assigned to the backup link is larger than that assigned to the primary
link.
z Making sure the same route can be adopted by multiple links (which can be achieved through load
balancing configuration).
Workflow of Dynamic Route Backup
The dynamic route backup function is implemented as dynamic route backup groups. In a dynamic
route backup group, the backup link is activated when the primary link leading to the monitored network
segment fails. A dynamic route backup group operates as follows.
1) The system checks for the routes to the monitored network segment and monitors whether the
routes to the monitored network segment are updated.
2) If at least one route to the monitored network segment exists, and the route is originated from an
interface with the dynamic route backup function disabled, the primary link operates properly.
3) If no such a route exists, the primary link is considered to be shut down and unavailable, and the
backup link will be activated.
4) After the backup link is activated successfully, the data is transferred across it. When the primary
link restores, the backup link can be torn down either immediately or after the timer expires,
depending on the related configuration.
Dynamic Route Backup Configuration

Creating a Dynamic Route Backup Group
You can create a dynamic route backup group in one of the following two ways.
1) Create multiple dynamic route backup groups, each of which monitors a network segment. The
backup link will be activated when the route to a network segment being monitored gets invalid.
Each dynamic route backup group can establish or tear down a link through a dialup interface.
2) Create a dynamic route backup group to monitor multiple network segments. The backup link will
be activated when the routes to all the network segments being monitored get invalid. When
establishing the backup link, the dynamic route backup group checks for the dialup interfaces
configured with the dialer route command and try to establish the backup link on the first such
interface. Note that only one backup link is established.
1-2
Follow these steps to create a dynamic route backup group:
Create a dynamic route backup standby routing-rule Required

group or add a network segment group-number ip ip-address By default, no dynamic route
to be monitored to the group { mask | mask-length } backup group is created.
z The IP address specified in the standby routing-rule command must be the same as that
specified in the dialer route command.
z Refer to DCC Commands in the Access Volume for information about the dialer route command.
Enabling the Dynamic Route Backup Function on a Backup Interface
Follow these steps to enable the dynamic route backup function on a backup interface:
interface-number
Required
Enable the dynamic route standby routing-group
backup function group-number By default, the dynamic route
backup function is disabled.
Before enabling the dynamic route backup function on a backup interface, make sure DCC is enabled
on the interface.
Configuring the Delay for Disconnecting a Backup Link
Normally, when the primary link resumes, the backup link will be torn down. To prevent route instability,
you can specify the backup link remain valid for specific period after the primary link resumes by
configuring the delay for disconnecting a backup link.
Follow these steps to configure the delay for disconnecting a backup link:
interface-number
1-3
Configure the delay for Optional

standby timer
disconnecting a backup By default, the delay for disconnecting
routing-disable seconds
link a backup link is 20 seconds.
Dynamic Route Backup Configuration Examples

Example I
z Router B is connected to Router A and Router C through serial interfaces connecting to two X.25
networks.
z Router A and Router C are connected to the same ISDN switched network through their ISDN BRI
interfaces. Router A and Router C can call each other. The telephone number of Router C is
8810052.
z The serial interfaces are in the network segment 10.0.0.0/8, and the BRI interfaces are in the
network segment 20.0.0.0/8.
z Use Router A as the master device of a dynamic route backup group to monitor the network
segment 30.0.0.0/8, which is connected to Router C.
Network diagram
Figure 1-1 Network diagram for dynamic route backup configuration (I)
# Create a dialer access group rule.
# Configure dialup parameters for BRI 3/0.

[RouterA-Bri3/0] ip address 20.0.0.1 8
1-4
# Configure Serial 2/0 and encapsulate the X.25 protocol on it.
[RouterA-Serial2/0] x25 map ip 10.0.0.2 x121-address 15 broadcast
# Configure RIP.
[RouterA] rip
[RouterA-rip-1] import-route direct
# Create a dynamic route backup group.

[RouterA] standby routing-rule 1 ip 30.0.0.1 32
# Configure the routes used by the serial interface to adopt higher priorities over those used by the
dialup interface.
[RouterA-Bri3/0] rip metricin 2
# Enable the dynamic route backup function.

[RouterA-Bri3/0] standby routing-group 1
# Enable X.25 switching on Router B.
# Configure Serial 2/0 and Serial 2/1 as X.25 interfaces.

# Configure switching information for X.25.


[RouterC-Bri3/0] ip address 20.0.0.2 8
1-5
[RouterC-Bri3/0] quit

[RouterC-Serial2/1] link-protocol x25 dte ietf
[RouterC-Serial2/1] x25 map ip 10.0.0.1 x121-address 10 broadcast
[RouterC-Serial2/1] ip address 10.0.0.2 8
# Configure the interface Loopback 1.

[RouterC] interface loopback 1
[RouterC-Loopback1] ip address 30.0.0.1 32
[RouterC-Loopback1] quit
# Configure RIP.
[RouterC] rip
[RouterC-rip-1] network 10.0.0.0
[RouterC-rip-1] import-route direct
Example II
z Router A and Router B are directly connected through their serial interfaces. They are also
connected to the same ISDN switched network through their ISDN BRI interfaces and can thus call
each other. The telephone number of Router B is 8810052.
z The serial interfaces of the two routers are in the network segment 10.0.0.0/8, and their BRI
interfaces are in the network segment 20.0.0.0/8.
segment 40.0.0.0/8, which is connected to Router B.
Network diagram
Figure 1-2 Network diagram for dynamic route backup configuration (II)
1-6
# Configure the dialup parameters for BRI 3/0.

[RouterA-Bri3/0] ip address 20.0.0.1 8

# Configure OSPF.
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.0.0.0 0.255.255.255
[RouterA-ospf-1-area-0.0.0.0] import-route direct
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit

dialup interface.
[RouterA-Bri3/0] ospf cost 2000
[RouterA-Bri3/0] ospf network-type broadcast
# Enable the dynamic route backup function.

[RouterA-Bri3/0] standby routing-group 1
# Configure the dialup parameters for BRI 3/0.

[RouterB-Bri3/0] ip address 20.0.0.2 8
1-7


[RouterB] interface loopback 1
[RouterB-Loopback1] ip address 40.0.0.1 32
[RouterB-Loopback1] quit
# Configure OSPF.
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 10.0.0.0 0.255.255.255
[RouterB-ospf-1-area-0.0.0.0] import-route direct
Example III
z Router A and Router B are connected through an X.25 network.

z Router A and Router B are connected to the same ISDN switched network through their ISDN BRI
interfaces, each of which has two B channels bound in it. Router A and Router B can call each
other through a resource-shared DCC (RS-DCC). The telephone number of Router A is 8810010,
and that of Router B is 8810052.
segment 30.0.0.0/8, which is connected to Router B.
z Normally, the X.25 link functions as the primary link between Router A and Router B. When the
route to the network segment 30.0.0.0/8 gets invalid (for example, when the X.25 network fails),
Router A establishes an ISDN BRI link to router B automatically.
Network diagram
Figure 1-3 Network diagram for dynamic route backup configuration (III)
1-8
# Create a dialer access group rule and a local user database.

# Configure a RS-DCC on Dialer0.

[RouterA-Dialer0] ip address 20.0.0.1 24
[RouterA-Dialer0] standby routing-group 1
# Bind BRI 3/0 to Dialer 0.


[RouterA-Serial2/0] x25 map ip 10.0.0.2 x121-address 20 broadcast
# Configure RIP.
[RouterA] rip
dialup interface.
1-9
[RouterA-Bri3/0] rip metricin 2
# Create a dialer access group rule and configure a local user database.
# Configure a RS-DCC on Dialer 0.

[RouterB-Dialer0] link-protocol ppp
[RouterB-Dialer0] ip address 20.0.0.2 24

[RouterB-Bri3/0] dialer bundle-member 1
[RouterB-Bri3/0] ppp authentication-mode pap
[RouterB-Bri3/0] ppp pap local-user userb password simple userb
# Configure X.25-related parameters on Serial 2/0.

[RouterB-Serial2/0] link-protocol x25 dte ietf
[RouterB-Serial2/0] x25 map ip 10.0.0.1 x121-address 10 broadcast

[RouterB-Loopback1] ip address 30.0.0.1 32
[RouterB-Loopback1] quit
# Configure RIP.
[RouterB] rip
[RouterB-rip-1] import-route direct
1-10
Configuration Example for Using One Dynamic Route Backup Group to Monitor
Multiple Network Segments
z Router A and Router B are connected through a FR network. They are also connected through an
ISDN switched network and can thus call each other. The telephone number of Router A is 660330,
and that of Router B is 660220.
z Use Router A as the master device of a dynamic route backup group to monitor the three network
segments 10.0.0.1/8, 11.0.0.1/8, and 12.0.0.1/8, which are all connected to Router B.
z Normally, the FR link functions as the primary link between Router A and Router B. When the
routes to all the three network segments get invalid, Router A establishes an ISDN BRI link to
Router B automatically.
Network diagram
Figure 1-4 Network diagram for monitoring multiple subnets through a dynamic route backup group
This network diagram only illustrates a simple implementation. In actual use, the monitored network
segments can be connected to multiple devices.
# Create a dynamic route backup group to monitor the three network segments.
[RouterA] standby routing-rule 1 ip 10.0.0.0 255.0.0.0
# Configure the CE1 interface to operate in PRI mode.
1-11
[RouterA] controller e1 2/1
[RouterA-E1 2/1] pri-set
[RouterA-E1 2/1] quit
# Configure Serial 2/0 as an FR interface.

[RouterA-Serial2/0] fr inarp
# Configure DCC polling on the PRI interface.

[RouterA-Serial2/1:15] ip address 2.0.0.1 255.0.0.0
[RouterA-Serial2/1:15] dialer enable-circular
[RouterA-Serial2/1:15] dialer-group 1
[RouterA-Serial2/1:15] dialer route ip 10.0.0.0 mask 8 660220
[RouterA-Serial2/1:15] standby routing-group 1
# Configure RIP.
[RouterA] rip
dialup interface.
[RouterA-Serial2/1:15] rip metricin 2
# Create a dialer access group rule for dialup.
[RouterB] system
# Configure the CE1 interface to operate in PRI mode.

[RouterB] controller e1 2/1
[RouterB-E1 2/1] pri-set
[RouterB-E1 2/1] quit
# Configure Serial 2/0 as an FR interface.

[RouterB-Serial2/0] fr inarp
[RouterB-Serial2/0] fr map ip 1.0.0.1 200
1-12
# Configure DCC polling on the PRI interface Serial 2/1:15.
[RouterB-Serial2/1:15] ip address 2.0.0.2 255.0.0.0
[RouterB-Serial2/1:15] dialer enable-circular
[RouterB-Serial2/1:15] dialer-group 1
[RouterB-Serial2/1:15] dialer route ip 2.0.0.1 mask 8 660330
[RouterB-Serial2/1:15] quit
# Configure the Ethernet interfaces with the network segments attached.

# Configure RIP.
[RouterB] rip
[RouterB-rip-1] import-route direct
1-13
Table of Contents
1 Logical Interface Configuration 1-1

Logical Interface Overview1-1
Dialer Interface1-2
Loopback Interface1-2
Introduction to Loopback Interface 1-2
Configuring a Loopback Interface 1-3
Null Interface 1-3
Introduction to Null Interface 1-3
Configuring a Null Interface 1-3
RPR Logical Interface 1-4
Introduction to RPR Logical Interface1-4
Configuring a RPR Logical Interface 1-4
Subinterface 1-4
Introduction to Subinterface 1-4
Configuring an Ethernet Subinterface 1-5
Configuring a WAN Subinterface 1-6
Ethernet Subinterface Configuration Example 1-8
WAN Subinterface Configuration Example 1-10
MP-Group Interface1-11
MFR Interface 1-11
VT and VA Interface1-12
Introduction to VT and VA Interface 1-12
Configuring a VT1-12
Displaying and Maintaining VTs and VA Interfaces 1-13
Troubleshooting VT/VA Interface 1-14
VE Interface 1-14
Introduction to VE 1-14
Configuring a VE Interface 1-15
i
Feature MSR20-1X MSR20 MSR30 MSR50

RPR logical interface NO NO NO NO
z By default, when an Ethernet subinterface is created, this subinterface is not associated with any
VLAN, and the packets on the interface are of no encapsulation type.
1 Logical Interface Configuration
When configuring logical interfaces, go to these sections for information you are interested in:
z Logical Interface Overview
z Dialer Interface
z Loopback Interface
z Null Interface
z RPR Logical Interface
z Subinterface
z MP-Group Interface
z MFR Interface
z VT and VA Interface
z VE Interface
This chapter only describes the basic configurations of logical interfaces. For the configuration of the
data link layer, network layer, and special features, refer to the relevant features in the Access Volume
and the IP Services Volume.
Logical Interface Overview

Logical interfaces are virtual interfaces that can exchange data but do not exist physically. Examples of
logical interfaces include the loopback interface, null interface, subinterface, multilink point-to-point
1-1
protocol group (MP-group) interface, multilink frame relay (MFR) interface, backup center logical
channel, and virtual template (VT).
Dialer Interface
Dialer interface is designed for configuring dial control center (DCC) parameters. You can apply the
parameters configured for a dialer interface to a physical interface by binding the latter to the dialer
interface. The following interfaces can be used as dialer interfaces: asynchronous serial interfaces
(including synchronous/asynchronous serial interfaces operating in asynchronous mode), AUX
interfaces, AM interfaces, ISDN BRI interfaces, and ISDN PRI interfaces.
DCC is a routing technology used for interconnecting routers through public switched network (PSTN or
ISDN). It can provide dial-on-demand services. In some occasions, data to be exchanged between
routers is small but bursty. DCC enables connections to be established among routers only when data
exchange demands occur, thus providing you a flexible and economic networking solution.
Refer to DCC Configuration in the Access Volume for more information about DCC.
Loopback Interface
Introduction to Loopback Interface
A loopback interface is a software-only virtual interface. The physical layer state and link layer protocols
of a loopback interface are always up unless the loopback interface is manually shut down. A loopback
interface can be configured with an IP address. For saving IP address resources, the IP address is
automatically configured with a 32-bit mask. Routing protocols can be enabled on a loopback interface,
and a loopback interface is capable of sending and receiving routing protocol packets.
Loopback interfaces are widely applied, for example, a loopback interface address can be configured
as the source address of all the IP packets that the device generates. The loopback interface address is
a stable unicast address, so the loopback interface address is usually regarded as the identification of a
device. If you configure an authentication or security server to permit or deny packets with a specific
loopback interface address, all the packets a specific device generates are permitted or denied. In this
way, the packet filtering rules are simplified. Note that, when a loopback interface is used for source
address binding, make sure that the route from the loopback interface to the peer is reachable; all data
packets sent to the loopback interface are considered as packets sent to the device itself, so the device
does not forward these packets.
Because a loopback interface is always up, it can be used for some special purposes. For example, if a
router ID is not configured for a dynamic routing protocol, the highest loopback interface address is
selected as the router ID.
1-2
Configuring a Loopback Interface
Follow these steps to configure a loopback interface:

Create a Loopback interface and interface loopback

enter Loopback interface view interface-number
Optional
Shut down the loopback interface shutdown A loopback interface is up on
being created.
z The subnet mask of the IP address assigned to a Loopback interface can only be 32 bits in length.
z Parameters such as IP addresses and IP routes can be configured on Loopback interfaces. Refer
to the IP Services Volume for detailed configurations.
Null Interface
Introduction to Null Interface
Null interfaces are completely software-like logical interfaces. Null interfaces are always up. However,
they can neither forward data packets nor have IP addresses and link layer protocols configured on
them. With a null interface specified as the next hop of a static route to a specific network segment, any
packets routed to the network segment are dropped. Null interface provides you a way to filter packets.
That is, you can simply transmit unwanted traffic to a null interface rather than applying ACLs.
For example, by executing the ip route-static 92.101.0.0 255.255.0.0 null 0 command (which
configures a static route leading to a null interface), you can have all the packets destined to the network
segment 92.101.0.0/16 discarded.
Configuring a Null Interface
Follow these steps to configure a null interface:

Required
Enter null interface view interface null 0 Null0 interface is the default null
interface on a device. It can neither be
created nor removed.
1-3
RPR Logical Interface
Introduction to RPR Logical Interface
The support for RPR logical interfaces varies by device.
A resilient packet ring (RPR) logical interface is a layer-3 logical interface used for facilitating RPR.
Initially, a RPR node is composed of a west physical interface and an east physical interface. The two
interfaces are fixed as a couple in the chip. One interface failure makes the whole node obsolete. On a
device supporting RPR logical interfaces, you can bind any two physical interfaces to a RPR logical
interface to form a RPR node. When one physical interface fails, you can replace it with another
physical interface. Additionally, the configuration on a RPR logical interface can be synchronized to
physical interfaces, thus simplifying the configuration procedure.
Configuring a RPR Logical Interface
The following table lists the basic configuration procedure of RPR logical interfaces. For the detailed
information about RPR logical interfaces, refer to RPR Configuration in the Access Volume.
Follow these steps to configure a RPR logical interface:

Enter RPR interface view interface rpr interface-number Required
Optional
By default, the default
Set the description information description text description information of a
RPR interface is interface
name interface.
Optional
Defaults to 1500 bytes
Optional
Shut down the RPR interface shutdown A RPR interface is in the up
state by default.
Subinterface
Introduction to Subinterface
Subinterfaces are logical virtual interfaces configured on a main interface. The main interface can be
either a physical interface (such as a Layer-3 Ethernet interface) or a logical interface (such as an MFR
interface). The subinterfaces on a main interface share the physical layer parameters of the main
interface but can have link layer and network layer parameters of their own. Disabling or enabling a
subinterface does not affect the main interface, but the main interface status change affects the
subinterfaces. The subinterfaces cannot operate normally unless the main interface is connected.
1-4
A single physical interface containing multiple subinterfaces enables you to network in a more flexible
way.
You can create subinterfaces for the following physical interfaces:
z Ethernet interface. An Ethernet subinterface associated with no VLAN supports only IPX, while an
Ethernet subinterface associated with a VLAN supports both IP and IPX.
z WAN interfaces with their data link layer protocols being frame relay, whose subinterfaces support
IP and IPX.
z WAN interfaces with their data link layer protocols being X.25, whose subinterfaces support IP and
IPX.
z ATM interface, whose subinterfaces support only IP.
Configuring an Ethernet Subinterface
Configuring operation parameters for an Ethernet subinterface
Ethernet subinterfaces fall into Layer 2 Ethernet subinterfaces and Layer-3 subinterfaces.
z Layer 2 Ethernet subinterface enables Layer 2 packets to be forwarded among VLANs. With Layer
2 Ethernet subinterfaces configured, Layer 2 Ethernet packets of a VLAN corresponding to a
subinterface can be forwarded to VLANs corresponding to other subinterfaces. Such subinterfaces
are applicable in occasions where devices cooperate with high-end firewall plug-in cards.
z Layer-3 Ethernet subinterface enables Layer-3 Ethernet interfaces to identify packets by VLANs.
By configuring multiple subinterfaces on an Ethernet interface, you can have packets of different
VLANs forwarded through the corresponding subinterfaces, thus improving the flexibility of
networking implementations.
Follow these steps to configure an Ethernet subinterface:

Required
interface { ethernet | If the specified Ethernet subinterface does not exist,
Create an Ethernet
gigabitethernet | this command firstly creates the subinterface and
subinterface and
ten-gigabitethernet } then leads you to Ethernet subinterface view.
enter Ethernet
interface-number.subnu The support of the ethernet keyword and the
subinterface view
mber gigabitethernet keyword varies with device
models.
Required
By default:
z When a device supporting this command
creates an Ethernet subinterface, this
Set the subinterface is not associated with any VLAN,
encapsulation type and the packets on the interface are of no
and associated vlan-type dot1q vid encapsulation type.
VLAN for the vlan-id z When a device not supporting this command
Ethernet creates an Ethernet subinterface, the ID of its
subinterface associated VLAN is the subinterface number
and cannot be modified, and the encapsulation
type of the interface is dot1q. For example, if you
create a subinterface 10 with the interface
Ethernet 1/1.10 command, the ID of the VLAN
associated with this subinterface is 10.
1-5
z You can perform IP- and IPX-related configuration for an Ethernet subinterface. Refer to the IP
Services Volume and IPX Volume for detailed configurations.
z Only associating an Ethernet subinterface with a VLAN can activate the subinterface and enable
the subinterface to transmit and receive packets normally.
z For the local and remote Ethernet subinterfaces to transmit traffic correctly, configure them with the
same subinterface number and VLAN ID.
Display and maintain Ethernet subinterfaces
After the above configuration, you can use the display command in any view to view the configuration
information of the Ethernet subinterface, so as to verify the configuration.
Follow these steps to display and maintain Ethernet subinterfaces:
To do Use the command

display interface interface-type
Display the information about a subinterface
interface-number.subnumber
Display the information about the VLAN of a display vlan interface interface-type
subinterface interface-number.subnumber
For information about the display vlan interface command, refer to the display vlan command in
VLAN Commands of the Access Volume.
Configuring a WAN Subinterface
Configure a subinterface on a WAN interface with its link-layer protocol being frame relay
1) Create a subinterface
Follow these steps to create a subinterface:

interface serial
Enter serial interface view Required
interface-number
Required
Set the data link layer protocol link-protocol fr [ nonstandard
of the interface to frame relay | ietf | mfr interface-number] By default, the data link layer
protocol of an interface is PPP.
1-6
Create a subinterface for the interface serial Required

serial interface and enter the interface-number.subnumber By default, point-to-multipoint
corresponding view [ p2mp | p2p ] subinterfaces are created.
2) Configure relevant operation parameters

On a subinterface of a WAN interface with its data link layer protocol being frame relay, you can perform
the following configuration.
z Creating a frame relay address mapping that is different from the that of the WAN interface (also
known as the main interface)
z Assigning an IP address for the subinterface. The IP address can be in a network segment different
from that where the WAN interface resides.
z Assigning an IPX network number and configuring other IPX-related operation parameters for the
subinterface, which can be different from those of the WAN interface
z Creating virtual circuits corresponding to the subinterface
For related information, refer to Frame Relay Configuration in the Access Volume, IPX Configuration in
the IPX Volume, and related sections in the IP Services Volume.
Configure a subinterface on a WAN interface with its data link layer protocol being X.25
1) Create a subinterface
Follow these steps to create a subinterface:

interface serial
Enter serial interface view Required
interface-number
Required
Set the data link layer protocol link-protocol x25 [ dte | dce ]
of the interface to X.25 [ ietf | nonstandard ] By default, the data link layer
protocol of an interface is PPP.
Create a subinterface on the interface serial Required

serial interface and enter the interface-number.subnumber By default, point-to-multipoint
corresponding view [ p2mp | p2p ] subinterfaces are created.

On a subinterface of a WAN interface with its data link layer protocol being X.25, you can perform the
following configuration.
z Creating an X.25 address mapping that is different from that of the WAN interface (also known as
the main interface)
from that where the WAN interface resides.
z Assigning an IPX network numbers and configure other IPX-related operation parameters for the
subinterface, which can be different from those of the WAN interface.
1-7
For related information, refer to LAPB and X.25 Configuration in the Access Volume, IPX Configuration
in the IPX Volume, and related sections in the IP Services Volume.
Create an ATM subinterface
1) Create an ATM subinterface

Follow these steps to create an ATM subinterface:

Required
If the specified ATM subinterface does not
Create an ATM interface atm exist, this command firstly creates the
subinterface and enter interface-number.subnumber subinterface and then leads you to ATM
ATM subinterface view [ p2mp | p2p ] subinterface view.
By default, point-to-multipoint
subinterfaces are created.

On an ATM subinterface, you can perform the following configuration.
from that where the ATM main interface resides
For related information, refer to ATM Configuration in the Access Volume and related sections in the IP
Services Volume.
Ethernet Subinterface Configuration Example
As shown in Figure 1-1, Host A and Host B are connected to Switch A; Host C and Host D are
connected to Switch B. Host A and Host C belong to VLAN 10; Host B and Host D belong to VLAN 20.
It is required that:
z The IP addresses of router subinterfaces Ethernet 3/0.10, Ethernet 3/0.20, Ethernet 4/0.10, and
Ethernet 4/0.20 are 1.0.0.1/8, 2.0.0.1/8, 3.0.0.1/8, and 4.0.0.1/8.
z Host A can communicate with Host B; Host C can communicate with Host D. That is, devices
connected to the same switch but belonging to different VLANs can communicate with each other.
z Host A can communicate with Host C; Host B can communicate with Host D. That is, devices
connected to different switches but belonging to the same VLAN can communicate with each other.
z Host A can communicate with Host D; Host B can communicate with Host C. That is, devices
connected to different switches and belonging to different VLANs can communicate with each
other.
1-8
Network diagram
Figure 1-1 Network diagram for Ethernet subinterface configuration
The support for the vlan-type dot1q vid command varies by device. This command is required for a
device supporting this command, because only associating an Ethernet subinterface with a VLAN can
activate the subinterface and enable the subinterface to transmit and receive packets normally.
z Configure Router
# Create Ethernet subinterfaces (that is, Ethernet 3/0.10, Ethernet 3/0.20, Ethernet 4/0.10, and
Ethernet 4/0.20), specify an IP addresses for each subinterface, and associate each subinterface with a
VLAN.
[Router] interface ethernet 3/0.10
[Router-Ethernet3/0.10] ip address 1.0.0.1 255.0.0.0
[Router-Ethernet3/0.10] vlan-type dot1q vid 10
[Router-Ethernet3/0.10] quit
1-9
WAN Subinterface Configuration Example
z Router A is connected to Router B and Router C through its Serial 1/0 interface and a frame relay
network.
z Configure subinterfaces on Serial 1/0 of Router A to enable users in LAN 1 (which is connected to
Router A) to access both LAN 2 (which is connected to Router B) and LAN 3 (which is connected to
Router C).
Network diagram
Figure 1-2 Network diagram for WAN subinterface configuration
# Enter Serial 1/0 interface view.
[Sysname] interface serial 1/0
# Set the data link layer protocol to frame relay.

[Sysname-Serial1/0] link-protocol fr
# Specify the frame relay terminal type as DTE.

[Sysname-Serial1/0] fr interface-type dte
[Sysname-Serial1/0] quit
# Create a point-to-point subinterface Serial 1/0.1.

[Sysname] interface serial 1/0.1 p2p
# Set the IP address of Serial 1/0.1 to 1.1.1.1/24.
1-10
[Sysname-Serial1/0.1] ip address 1.1.1.1 255.255.255.0
# Assign a virtual circuit to Serial 1/0.1, with the DLCI being 50.
[Sysname-Serial1/0.1] fr dlci 50
[Sysname-fr-dlci-Serial1/0.1-50] quit
[Sysname-Serial1/0.1] quit
# Create a point-to-point subinterface Serial 1/0.2.

[Sysname] interface serial 1/0.2 p2p
# Set the IP address of Serial 1/0.2 to 1.1.2.1/24.

[Sysname-Serial1/0.2] ip address 1.1.2.1 255.255.255.0
# Assign a virtual circuit to Serial 1/0.2, with the DLCI being 60.
[Sysname-Serial1/0.2] fr dlci 60
[Sysname- fr-dlci-Serial1/0.2-60] quit
[Sysname-Serial1/0.2] quit
# Configure static routes from Router A to LAN 2 and LAN 3.

[Sysname] ip route-static 2.2.0.0 255.255.0.0 1.1.1.2
[Sysname] ip route-static 2.3.0.0 255.255.0.0 1.1.2.2
2) The configurations of Router B and Router C are similar to that of Router A and thus omitted.
MP-Group Interface
MP-group interfaces are used in multilink PPP (MP) links. MP-group interfaces are dedicated to MP and
cannot be used for any other purposes. Refer to PPP Configuration in the Access Volume for
information about MP groups.
Follow these steps to create an MP-group interface:

Required
Create an MP-group interface If the specified MP-group
interface mp-group interface does not exist, this
and enter MP-group interface
mp-number command firstly creates the
view
interface and then leads you to
MP-group interface view.
View the information about the display interface mp-group
MP-group interface [ mp-number ]
MFR Interface
An MFR interface is a logical interface for a bundle of physical frame relay links. You can configure
subinterfaces on MFR interfaces, thus providing high-rate and broad-bandwidth links for a frame relay
network. Refer to Frame Relay Configuration in the Access Volume for related information.
1-11
Follow these steps to create an MFR interface:

Required
If the specified MFR main
Create an MFR main interface interface does not exist, this
interface mfr interface-number
and enter MFR interface view command firstly creates the
interface and then leads you to
MFR interface view.
Required
Create an MFR subinterface If the specified MFR
interface mfr subinterface does not exist, this
and enter MFR subinterface
interface-number.subnumber command firstly creates the
view
subinterface and then leads
you to MFR subinterface view.
display interface mfr
View the information about the
[ interface-number | Available in any view
MFR interface
interface-number.subnumber ]
View the information about the display mfr [ interface
MFR bundling and bundled interface-type interface-number Available in any view
links | verbose ]
Refer to Frame Relay Configuration in the Access Volume for information about MFR interface
parameters.
VT and VA Interface
Introduction to VT and VA Interface
A virtual template (VT) is a template used for configuring a virtual access (VA) interface. VTs are mainly
used in VPN and MP implementations.
After a VPN session is established, a VA interface is necessary for exchanging data with the peer end.
You can specify a VT for the VA interface to be created dynamically. Refer to the VPN Volume for
information about VPN.
As for an MP, which comprises of multiple PPP channels, a VA interface is also necessary for
exchanging data with the peer end. You can specify a VT too for the VA interface to be created
dynamically. Refer to PPP Configuration in the Access Volume for information about MP.
Configuring a VT
In VPN and MP implementations, the creation and removal of VA interfaces are done by the system and
are transparent to users. You just need to configure VPNs or MPs on corresponding physical interfaces,
create and configure VTs and then associate the VTs with the corresponding physical interfaces.
1-12
Create a VT
Follow these steps to create a VT:

Required
interface virtual-template If the specified VT does not
Create a VT and enter VT view exist, this command firstly
interface-number
creates the VT and then leads
you to VT view.
broadcast-limit link
links that can send multicast or
interface-number Defaults to 30.
broadcast packets for the VT
Before removing a VT, make sure that all the virtual interfaces created using it are removed and the VT
is not in use.
Configure VT operation parameters
Compared with normal physical interfaces, a VT supports only PPP on data link layer and IP on the
network layer. You can configure the following operation parameters for a VT:
z PPP operation parameters
z IP address of the VT
z IP address (or IP address pool) to be assigned to the PPP peer
Refer to PPP Configuration in the Access Volume and related sections in the IP Services Volume for
related information.
Associate a VT with a physical interfaces
VA interfaces are not manually created. They are created dynamically by the system and adopt the
parameters defined in a specific VT. A VA interface can be removed due to failures of lower layer
connections or user intervention.
In VPN implementations, you need to associate Layer 2 tunneling protocol (L2TP) groups with VTs.
Refer to the VPN Volume for related information. In MP implementations, you need to associate MP
users with VTs. Refer to PPP Configuration in the Access Volume for related information.
Displaying and Maintaining VTs and VA Interfaces
After the above configuration, you can use the display command in any view to view the configuration
information about the VTs and VA interfaces, so as to verify the configuration.
1-13
Follow these steps to display VTs and VA interfaces:

display interface virtual-template
Display the information about a VT
interface-number
display virtual-access [ va-number | dialer
Display the information about a VA interface dialer-number | peer peer-address | user
user-name | vt vt-number ] *
Troubleshooting VT/VA Interface
Before troubleshooting, you need to make clear whether the VT is used for creating VPN virtual
interfaces or MP virtual interfaces so as to locate the VT failures accordingly.
Symptom
Virtual interfaces cannot be created.
Solution
The causes may be:

z No IP address is configured for the VT. As a result, PPP negotiation fails and the VA interface
cannot be brought up.
z PPP authentication parameters are incorrect. PPP negotiation fails if the user name the peer
device uses is not defined on the local device. As a result, the VA interface cannot be brought up.
z The IP address (or IP address pool) to be assigned to the peer is not configured. As a result, the VA
interface cannot provide the IP addresses the peer device requests. In this case, the VA interface
cannot be brought up.
VE Interface
Introduction to VE
Support for VE interfaces varies by device.
Consisting of Layer-3 Virtual-Ethernet (VE) interfaces and Layer 2 VE-Bridge interfaces, Virtual
Ethernet (VE) interfaces are logical interfaces implemented on interface boards. They are mainly used
for PPPoEoA, IPoEoA, and EoA.
z Point to Point Protocol over Ethernet over ATM (PPPoEoA) contains three layers: the top layer is
PPP, the layer in the middle is PPP over Ethernet (PPPoE), and the bottom layer is PPPoEoA.
Note that the parameters for PPPoE are configured through Layer-3 VE interfaces on the interface
boards of the access device. Refer to ATM Configuration in the Access Volume for more
information.
z IPoEoA and EoA are used to bind VE interfaces to PVCs to carry Ethernet packets over ATM.
IPoEoA is for binding Layer-3 VE interfaces while EoA is for binding Layer 2 VE interfaces. Refer to
ATM Configuration in the Access Volume for more information.
1-14
Configuring a VE Interface
When implementing PPPoEoA, IPoEoA, and EoA through a permanent virtual channel (PVC), you need
to associate a VE interface with the PVC. Otherwise, you cannot configure the PVC.
Configuring a Layer-3 VE interface
Follow these steps to configure a Layer-3 VE Interface:

Required
Create a Layer-3 If the specified Layer-3 VE interface does not exist,
interface
VE interface and this command firstly creates the Layer-3 VE
virtual-ethernet
enter Layer-3 VE interface and then leads you to Layer-3 VE
interface-number
interface view interface view.
You can create up to 1024 Layer-3 VE interfaces.
Configuring a Layer-2 VE interface
Follow these steps to configure a Layer-2 VE Interface:

Required
Create a Layer-2 If the specified Layer-2 VE interface does not exist,
VE interface and interface ve-bridge this command firstly creates the Layer-2 VE
enter Layer-2 VE interface-number interface and then leads you to Layer-2 VE
interface view interface view.
You can create up to 1024 Layer-2 VE interfaces.
z The configuration of a VE interface is similar to that of an Ethernet interface. Refer to Ethernet

Interface Configuration in the Access Volume for related information.
z The displaying and maintenance of a VE interface is similar to those of an Ethernet interface. Refer
to Ethernet Interface Configuration in the Access Volume for related information.
z Refer to ATM Configuration in the Access Volume for information about PPPoEoA configuration.
1-15
Table of Contents
1 WLAN Interface Configuration .................................................................................................................1-1

Overview .................................................................................................................................................1-1
WLAN-Radio Interface ............................................................................................................................1-1
Introduction......................................................................................................................................1-1
Configuring a WLAN-Radio Interface ..............................................................................................1-2
WLAN-ESS Interface ..............................................................................................................................1-2
Introduction......................................................................................................................................1-2
Entering WLAN-ESS Interface View ...............................................................................................1-2
Configuring the WLAN-ESS Interface .............................................................................................1-2
WLAN-DBSS Interface............................................................................................................................1-3
Introduction......................................................................................................................................1-3
WLAN-BSS Interface ..............................................................................................................................1-3
Introduction......................................................................................................................................1-3
Configuring a WLAN-BSS Interface ................................................................................................1-3
WLAN-Ethernet Interface ........................................................................................................................1-4
Introduction......................................................................................................................................1-4
Entering WLAN-Ethernet Interface View .........................................................................................1-4
Configuring a WLAN-Ethernet Interface..........................................................................................1-4
Displaying and Maintaining a WLAN Interface .....................................................................................1-10
i

WLAN-Radio Interface YES NO NO NO
WLAN-BSS Interface YES NO NO NO
WLAN-Ethernet Interface YES NO NO NO
1 WLAN Interface Configuration
When configuring a WLAN interface, go to these sections for information you are interested in:
z Overview
z WLAN-Radio Interface
z WLAN-ESS Interface
z WLAN-DBSS Interface
z WLAN-BSS Interface
z WLAN-Ethernet Interface
Overview
Wireless devices (including wireless switches and wireless routers) support WLAN-Radio interfaces,
which are physical interfaces that provide wireless network access.
z Wireless switches support WLAN-ESS and WLAN-DBSS virtual interfaces. For each wireless
access service, the WLAN module dynamically creates a WLAN-DBSS virtual interface, whose
VLAN configuration inherits from the corresponding WLAN-ESS interface.
z Wireless routers support WLAN-BSS and WLAN-Ethernet virtual interfaces. WLAN-Radio
interfaces on routers can be used as common physical access interfaces. They can be bound to
WLAN-BSS interfaces and WLAN-Ethernet interfaces.
WLAN-Radio Interface
Introduction
WLAN-Radio interfaces are physical interfaces and are used for providing wireless access service.
They can be configured but cannot be removed manually.
1-1
Configuring a WLAN-Radio Interface
Follow these steps to configure a WLAN-Radio interface:
To do Use the Command Remarks
Enter WLAN-Radio interface interface wlan-radio

Required
Optional
Set the description string for the By default, the description
description text
interface string of an interface is
interface-name + interface.
Optional
Shut down the WLAN-Radio
shutdown By default, a WLAN-Radio
interface
interface is up.
WLAN-ESS Interface
Introduction
WLAN-ESS interfaces are virtual Layer 2 interfaces. They operate like Layer 2 access Ethernet ports
and have Layer 2 attributes. They also support multiple Layer 2 protocols. A WLAN-ESS interface can
also be used as a template for configuring WLAN-DBSS interfaces. WLAN-DBSS interfaces created on
a WLAN-ESS interface adopts the configuration of the WLAN-ESS interface.
Entering WLAN-ESS Interface View
Follow these steps to enter WLAN-Ethernet interface view:

Required
Enter WLAN-ESS interface wlan-ess If the WLAN-ESS interface does not exist,
interface view interface-number this command creates the WLAN-ESS
interface first.
Configuring the WLAN-ESS Interface
You can configure the description of a WLAN-ESS interface and assign the interface to a common
VLAN or multicast VLAN. This section just provides features supported on WLAN-ESS interfaces. For
detailed information about these features and commands, refer to the corresponding sections.
Follow these steps to configure a WLAN-ESS interface:

Configure the description of the interface description
z port
Configure the VLAN
z port access vlan
1-2
Configure Configure multicast VLAN port

multicast Configure IPv6 multicast VLAN port
z The type of all WLAN-ESS interfaces is access.

z Before executing the port access vlan command, make sure that the VLAN identified by the
vlanid argument already exists. You can use the vlan command to create a VLAN.
z Some configurations (only VLAN-related configurations currently) of a WLAN-ESS interface with
WLAN-DBSS interfaces created on it cannot be modified, and the WLAN-ESS interface cannot be
removed either.
WLAN-DBSS Interface
Introduction
WLAN-DBSS interfaces are virtual Layer 2 interfaces. They operate like Layer 2 access Ethernet ports
and have Layer 2 attributes. They also support multiple Layer 2 protocols and 802.1X. A WLAN-DBSS
interface created on a WLAN-ESS interface adopts the configuration of the WLAN-ESS interface. On a
wireless switch, the WLAN module dynamically creates a WLAN-DBSS interface for each wireless
access service and removes the interface after the service expires.
WLAN-BSS Interface
Introduction
WLAN-BSS interfaces are virtual Layer 2 interfaces. They operate like Layer 2 access Ethernet ports
and have Layer 2 attributes. A WLAN-BSS interface supports multiple Layer 2 protocols. On a wireless
router, a WLAN-Radio interface bound to a WLAN-BSS interface operates as a Layer 2 interface.
Configuring a WLAN-BSS Interface
Follow these steps to configure a WLAN-BSS interface:
Required
Enter WLAN-BSS interface wlan-bss If the WLAN-BSS interface does not exist,
interface view interface-number this command creates the WLAN-BSS
interface first.
Optional
Set the description string
description text By default, the description string of an
for the interface
interface is interface-name + interface.
1-3
Optional
Add the WLAN-BSS
port access vlan vlanid By default, an interface belongs to VLAN
interface to a VLAN
1 (the default VLAN).
Shut down the WLAN-BSS Optional

shutdown
interface By default, a WLAN-BSS interface is up.
Before executing the port access vlan command, make sure the VLAN identified by the vlanid
argument already exists. You can use the vlan command to create a VLAN.
WLAN-Ethernet Interface
Introduction
WLAN-Ethernet interfaces are virtual Layer 3 interfaces. They operate like Layer 3 Ethernet interfaces
and have Layer 3 attributes. You can assign an IP address to a WLAN-Ethernet interface. On a wireless
router, a WLAN-Radio interface bound to a WLAN-Ethernet interface operates as a Layer 3 interface.
Entering WLAN-Ethernet Interface View
Follow these steps to enter WLAN-Ethernet interface view:
Required
Enter WLAN-Ethernet interface wlan-ethernet If the WLAN-Ethernet interface does not
interface view interface-number exist, this command creates the
WLAN-Ethernet interface first.
Configuring a WLAN-Ethernet Interface
For a WLAN-Ethernet interface, you can configure basic parameters such as MTU, and ARP, DHCP,
and routing protocols as listed in the following table (for information about the commands/features
listed in the following table, refer to the corresponding volumes).
1-4
Follow these steps to configure a WLAN-Ethernet interface:

qos max-bandwidth
shutdown
Configure an interface mtu
description
enable snmp trap updown
arp max-learning-num
Configure ARP arp proxy enable
proxy-arp enable
Configure the interface as a
ip address bootp-alloc
BOOTP client
Configure DHCP
dhcp select server global-pool
server
dhcp relay address-check

dhcp relay information enable
dhcp relay information format
Configure Configure DHCP
dhcp relay information strategy
DHCP relay
dhcp relay release
dhcp relay server-select
dhcp select relay
Configure DHCP
ip address dhcp-alloc
client
ip count firewall-denied
Configure IP Accounting ip count inbound-packets
ip count outbound-packets
Assign an IP address to the
ip address
interface
ip forward-broadcast
Configure IP performance
tcp mss
Configure IP unicast policy-based
ip policy-based-route
routing
Configure UDP Helper udp-helper server
Configure URPF ip urpf
Configure fast forwarding ip fast-forwarding
1-5
ipv6 address
ipv6 address auto link-local
ipv6 mtu
ipv6 nd autoconfig managed-address-flag
ipv6 nd autoconfig other-flag
ipv6 nd dad attempts
ipv6 nd ns retrans-timer
Configure basic IPv6 settings
ipv6 nd nud reachable-time
ipv6 nd ra halt
ipv6 nd ra interval
ipv6 nd ra prefix
ipv6 nd ra router-lifetime
ipv6 neighbors max-learning-num
ipv6 policy-based-route
Configure NAT-PT natpt enable
isis authentication-mode
isis circuit-level
isis circuit-type p2p
isis cost
isis dis-name
isis dis-priority
isis enable
isis mesh-group
Configure IS-IS
isis peer-ip-ignore
isis small-hello
isis timer csnp
isis timer hello
isis timer holding-multiplier
isis timer lsp
isis timer retransmit
isis silent
ospf authentication-mode simple
ospf authentication-mode
ospf cost
ospf dr-priority
ospf mtu-enable
Configure OSPF ospf network-type
ospf timer dead
ospf timer hello
ospf timer poll
ospf timer retransmit
ospf trans-delay
1-6
rip authentication-mode
rip input
rip output
rip metricin
Configure RIP rip metricout
rip poison-reverse
rip split-horizon
rip summary-address
rip version
Configure IPv6 IS-IS isis ipv6 enable
ospfv3 cost
ospfv3 mtu-ignore
ospfv3 timer dead
ospfv3 timer hello
Configure IPv6 OSPFv3
ospfv3 timer retransmit
ospfv3 area
ospfv3 dr-priority
ospfv3 trans-delay
ripng default-route
ripng enable
ripng metricin
Configure IPv6 RIPng ripng metricout
ripng poison-reverse
ripng split-horizon
ripng summary-address
mpls
mpls ldp
mpls ldp enable
Configure basic MPLS
mpls ldp advertisement
capabilities
mpls ldp timer hello-hold
mpls ldp timer keepalive-hold
mpls ldp transport-address
Configure BGP/MPLS VPN ip binding vpn-instance
pppoe-server bind virtual-template
Configure PPPoE
pppoe-client dial-bundle-number
Configure bridge sets bridge-set
1-7
multicast minimum-ttl
Configure multicast ipv6 minimum-hoplimit
multicast routing
and forwarding multicast boundary
multicast ipv6 boundary
Configure IPv6 multicast ipv6 minimum-hoplimit
multicast routing
and forwarding multicast ipv6 boundary
igmp enable
igmp fast-leave
igmp group-policy
igmp last-member-query-interval
igmp max-response-time
igmp require-router-alert
Configure IGMP
igmp robust-count
igmp send-router-alert
igmp static-group
igmp timer other-querier-present
igmp timer query
igmp version
mld enable
Configure
mld last-listener-query-interval
multicast
mld max-response-time
mld require-router-alert
mld send-router-alert
mld robust-count
Configure MLD
mld timer other-querier-present
mld timer query
mld version
mld static-group
mld group-policy
mld fast-leave
pim bsr-boundary
pim hello-option
pim holdtime
pim require-genid
pim sm
Configure PIM pim dm
pim state-refresh-capable
pim timer graft-retry
pim timer hello
pim timer join-prune
pim triggered-hello-delay
1-8
pim ipv6 bsr-boundary

pim ipv6 hello-option
pim ipv6 holdtime
pim ipv6 require-genid
pim ipv6 sm
Configure IPv6
pim ipv6 dm
PIM
pim ipv6 state-refresh-capable
pim ipv6 timer graft-retry
pim ipv6 timer hello
pim ipv6 timer join-prune
pim ipv6 triggered-hello-delay
qos car
Configure TP, TS, qos gts any cir
and port rate
limiting qos gts acl
qos lr
Apply a QoS policy qos apply policy
qos fifo queue-length
qos pq pql
qos cq cql
Configure queue
qos wfq
scheduling
QOS qos max-bandwidth
qos reserved-bandwidth pct
qos rtpq start-port
Configure priority qos priority

mapping qos trust
qos wred weighting-constant
Configure qos wred ip-precedence
congestion
avoidance qos wred enable
qos wred apply
Configure DAR dar protocol-statistic
firewall ethernet-frame-filter
firewall packet-filter
Configure firewall
firewall packet-filter ipv6
firewall aspf
nat outbound
Configure NAT nat outbound static
nat server
portal auth-network
Configure Portal
portal server
Configure IPSec ipsec policy
1-9
standby interface
standby threshold
Configure the backup center standby timer delay
standby timer flow-check
standby bandwidth
Configure NetStream ip netstream
ntp-service broadcast-client
ntp-service broadcast-server
Configure NTP ntp-service multicast-client
ntp-service multicast-server
ntp-service in-interface disable
ipx encapsulation
ipx tick
ipx rip mtu
ipx sap mtu
ipx sap gns-disable-reply
Configure IPX
ipx sap disable
ipx network
ipx netbios-propagation
ipx split-horizon
ipx update-change-only
port-security authorization ignore
port-security max-mac-count
port-security port-mode { mac-and-psk |
mac-authentication | mac-else-userlogin-secure |
Configure port security mac-else-userlogin-secure-ext | psk | userlogin-secure |
userlogin-secure-ext | userlogin-secure-ext-or-psk |
userlogin-secure-or-mac | userlogin-secure-or-mac-ext }
port-security preshared-key { pass-phrase | raw-key }
port-security tx-key-type 11key
Displaying and Maintaining a WLAN Interface

Follow these steps to display and maintain a WLAN interface:

Display information about a display interface wlan-radio
WLAN-Radio interface [ interface-number ]
Display information about a display interface wlan-ess
WLAN-ESS interface [ interface-number ]
Display information about a display interface wlan-dbss
WLAN-DBSS interface [ interface-number ]
Display information about a display interface wlan-bss
WLAN-BSS interface [ interface-number ]
1-10
display interface
wlan-ethernet Available in any view
WLAN-Ethernet interface
1-11
Table of Contents
1 ARP Configuration.....................................................................................................................................1-1
ARP Overview.........................................................................................................................................1-2
ARP Function ..................................................................................................................................1-2
ARP Message Format .....................................................................................................................1-2
ARP Address Resolution Process...................................................................................................1-3
ARP Table .......................................................................................................................................1-3
Configuring ARP .....................................................................................................................................1-4
Configuring a Static ARP Entry .......................................................................................................1-4
Configuring the Maximum Number of ARP Entries.........................................................................1-5
Configuring the Maximum Number of ARP Entries for an Interface ...............................................1-6
Setting the Aging Time for Dynamic ARP Entries ...........................................................................1-6
Enabling the ARP Entry Check .......................................................................................................1-6
Enabling the Support for ARP Requests from a Natural Network...................................................1-7
ARP Configuration Example............................................................................................................1-7
Configuring Gratuitous ARP....................................................................................................................1-8
Introduction to Gratuitous ARP........................................................................................................1-8
Configuring Gratuitous ARP ............................................................................................................1-8
Configuring ARP Source Suppression....................................................................................................1-9
Introduction to ARP Source Suppression........................................................................................1-9
Configuring ARP Source Suppression ............................................................................................1-9
Displaying and Maintaining ARP Source Suppression ...................................................................1-9
Configuring ARP Defense Against IP Packet Attack ............................................................................1-10
Introduction to ARP Defense Against IP Packet Attack ................................................................1-10
Enabling ARP Defense Against IP Packet Attack .........................................................................1-10
Configuring Authorized ARP .................................................................................................................1-10
Introduction to Authorized ARP .....................................................................................................1-10
Configuring Authorized ARP .........................................................................................................1-11
Example for Configuring Authorized ARP on a DHCP Server ......................................................1-11
Example for Configuring Authorized ARP on a DHCP Relay Agent .............................................1-13
Configuring ARP Detection ...................................................................................................................1-14
Introduction to ARP Detection .......................................................................................................1-14
Enabling ARP Detection Based on DHCP Snooping Security Entries..........................................1-15
Configuring ARP Detection Based on Specified Objects ..............................................................1-15
Configuring ARP Packet Rate Limit ..............................................................................................1-16
Displaying and Maintaining ARP Detection...................................................................................1-16
ARP Detection Configuration Example .........................................................................................1-16
Configuring MFF ...................................................................................................................................1-18
Introduction to MFF .......................................................................................................................1-18
Basic Concepts of MFF .................................................................................................................1-19
Protocols and Standards ...............................................................................................................1-20
Configuring MFF............................................................................................................................1-20
Displaying and Maintaining MFF ...................................................................................................1-22
MFF Configuration Example in a Tree Network ............................................................................1-22
i
MFF Configuration Example in a Ring Network ............................................................................1-23
Configuring ARP Snooping ...................................................................................................................1-26
Introduction to ARP Snooping .......................................................................................................1-26
Operation of ARP Snooping ..........................................................................................................1-26
Configuring ARP Snooping ...........................................................................................................1-26
Displaying and Maintaining ARP Snooping...................................................................................1-26
Configuring the ARP Fast-Reply Mechanism .......................................................................................1-27
Introduction to ARP Fast-Reply Mechanism Used in a Wireless Network....................................1-27
Working Mechanism ......................................................................................................................1-27
Configuring the ARP Fast-Reply Mechanism................................................................................1-27
ARP Fast-Reply Mechanism Configuration Example....................................................................1-28
Displaying and Maintaining ARP...........................................................................................................1-29
2 Proxy ARP Configuration .........................................................................................................................2-1

Proxy ARP Overview...............................................................................................................................2-1
Enabling Proxy ARP................................................................................................................................2-1
Displaying and Maintaining Proxy ARP ..................................................................................................2-2
Proxy ARP Configuration Examples .......................................................................................................2-2
Proxy ARP Configuration Example (on Routers) ............................................................................2-2
Proxy ARP Configuration Example (on Switches) ..........................................................................2-3
Local Proxy ARP Configuration Example in Case of Port Isolation ................................................2-4
Local Proxy ARP Configuration Example in Super VLAN...............................................................2-5
Local Proxy ARP Configuration Example in Isolate-user-vlan ........................................................2-6
ii

Maximum number of ARP entries
No No No No
supported by the system
Maximum number of ARP entries
Yes Yes Yes Yes
that an interface can learn
ARP entry check Yes Yes Yes Yes
Support for ARP requests from a
Yes Yes Yes Yes
natural network
Gratuitous ARP Yes Yes Yes Yes
ARP source suppression Yes Yes Yes Yes
ARP defense against IP packet
No No No No
attack
Authorized ARP Yes Yes Yes Yes
ARP detection No No No No
MAC-forced forwarding (MFF) No No No No
Proxy ARP Yes Yes Yes Yes
This document is organized as follows:

z ARP Configuration
z Proxy ARP Configuration
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 Configuring ARP Source Suppression
z Configuring ARP Defense Against IP Packet Attack
z Configuring Authorized ARP
1-1
z Configuring ARP Detection
z Configuring MFF
z Configuring ARP Snooping
z Configuring the ARP Fast-Reply Mechanism
z Displaying and Maintaining ARP
ARP Overview
ARP Function
Address Resolution Protocol (ARP) is used to resolve an IP address into a data link layer address.
An IP address is the address of a host at the network layer. To send a network layer packet to a
destination host, the device must know the data link layer address (such as the MAC address) of the
destination host. To this end, the IP address must be resolved into the corresponding data link layer
address.
Unless otherwise stated, the data link layer addresses that appear in this chapter refer to the 48-bit
Ethernet MAC addresses.
ARP Message Format
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.
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.
1-2
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 destination 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.
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.
1-3
An ARP table contains ARP entries, which fall into two categories: dynamic and static.
1) 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
interface goes down, the corresponding dynamic ARP entry will be removed.
2) A static ARP entry is manually configured and maintained. It cannot get aged or be overwritten by a
dynamic ARP entry. It can be 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 interface for the entry
besides the IP address and MAC address.
z A non-permanent static ARP entry has only an IP address and MAC address configured. If the
outbound interface is a Layer 3 Ethernet interface, the non-permanent ARP entry can be directly
used for forwarding data; if the outbound interface is a VLAN interface, it cannot be directly used for
forwarding data. If a non-permanent static ARP entry matches an IP packet to be forwarded, the
device sends an ARP request first. If the source IP and MAC addresses in the received ARP reply
are the same as the IP and MAC addresses of the non-permanent static ARP entry, the device
adds the interface receiving the ARP reply into the non-permanent static ARP entry. Then the entry
can be used for forwarding IP packets.
Usually ARP dynamically resolves IP addresses to MAC addresses, without manual intervention.
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.
Follow these steps to configure a static ARP entry:
Required
arp static ip-address
No permanent static ARP entry
mac-address vlan-id
Configure a permanent static is configured by default.
ARP entry Support for the vpn-instance
[ vpn-instance
vpn-instance-name ] argument depends on the
device model.
Required
No non-permanent static ARP
arp static ip-address
Configure a non-permanent entry is configured by default.
mac-address [ vpn-instance
static ARP entry Support for vpn-instance
vpn-instance-name ]
vpn-instance-name depends
on the device model.
1-4
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.
Configuring the Maximum Number of ARP Entries
Set the maximum number of ARP entries to 64K
Follow these steps to set the maximum number of ARP entries to 64K (namely, 65,536):

Set the maximum number of Required

arp max-num 65536
ARP entries to 64K 4K by default.
z The setting can take effect only after you save it and restart the system.
z When the maximum number of ARP entries the system supports is set to 64K, cards that do not
support this number cannot be started.
Set the maximum number of ARP entries to 4K
Follow these steps to set the maximum number of ARP entries to 4K (namely, 4096):

Set the maximum number of Required

undo arp max-num
ARP entries to 4K 4K by default
1-5
z The setting can take effect only after you save it and restart the system.
z When the maximum number of ARP entries the system supports is set to 4K, all cards can be
started.
Configuring the Maximum Number of ARP Entries for an Interface
Follow these steps to set the maximum number of dynamic ARP entries that an interface can learn:
interface-number

arp max-learning-num
dynamic ARP entries that an The value range and the default
number
interface can learn value vary with devices.
Setting the Aging Time for Dynamic ARP Entries
After dynamic ARP entries expire, the system will delete them from the ARP table. You can adjust the
aging time for dynamic ARP entries according to the actual network condition.
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
1-6
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:
Optional
Enable the ARP entry
arp check enable Enabled by default. That is, the device
check
does not learn multicast MAC addresses.
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.
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
z Enable the ARP entry check.

z Set the aging time for dynamic ARP entries to 10 minutes.
z Enable the support for ARP requests from a natural network.
z Set the maximum number of dynamic ARP entries that VLAN-interface 100 can learn to 1,000.
1-7
z Add a static ARP entry, with the IP address being 192.168.1.1/24, the MAC address being
00e0-fc01-0000, and the outbound interface being Ethernet 1/0 of VLAN 10.
[Sysname] arp check enable
[Sysname] arp timer aging 10
[Sysname] naturemask-arp enable
[Sysname] vlan 10
[Sysname-Ethernet1/0] port access vlan 10
[Sysname] interface vlan-interface 10
[Sysname-vlan-interface10] arp max-learning-num 1000
[Sysname-vlan-interface10] quit
[Sysname] arp static 192.168.1.1 00e0-fc01-0000 10 ethernet1/0
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.
1-8
Enable the gratuitous ARP gratuitous-arp-learning Required

packet learning function enable Enabled by default.
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
unresolvable destination IP addresses that
limit limit-value 10 by default.
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
1-9
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:
Optional
Enable ARP defense against IP
arp resolving-route enable The default setting depends on
packet attack
the device model.
Configuring Authorized ARP
z This feature is only supported on Layer 3 Ethernet interfaces.

z For information about DHCP server and DHCP relay agent, refer to DHCP Configuration in the IP
Services Volume.
Introduction to Authorized ARP
Authorized ARP entries are generated based on the DHCP clients address leases on the DHCP server
or security entries on the DHCP relay agent.
1-10
Authorized ARP can detect abnormal offline events and prevent attacks from illegal clients using other
clients IP or MAC addresses, and allow only legal clients to access network resources, thus enhancing
network security.
Static ARP entries can overwrite authorized ARP entries, and authorized ARP entries can overwrite
dynamic ARP entries. But authorized ARP entries cannot overwrite static ARP entries, and dynamic
ARP entries cannot overwrite authorized ARP entries.
Configuring Authorized ARP
After enabled with authorized ARP, an interface starts authorized ARP entry aging and is disabled from
learning dynamic ARP entries.
After you disable authorized ARP on the interface, the interface is enabled to learn dynamic ARP entries
and disabled from authorized ARP entry aging.
Follow these steps to enable authorized ARP:

interface-number
Configure the DHCP server (or Required
DHCP relay agent) to support dhcp update arp
authorized ARP Not configured by default.
Enable authorized ARP on the Required

arp authorized enable
interface Not enabled by default.
Configure the aging time for arp authorized time-out Optional

authorized ARP entries seconds 1200 seconds by default.
With the arp authorized enable command executed, an interface of a DHCP server (or a DHCP relay
agent) that does not support authorized ARP is disabled from dynamically learning ARP entries and
cannot generate authorized ARP entries.
Example for Configuring Authorized ARP on a DHCP Server
z Router A acts as a DHCP server with an IP address pool of 10.1.1.0/24. Enable authorized ARP on
Ethernet 1/0 of Router A.
z Router B is a DHCP client which obtains an IP address of 10.1.1.2/24 from the DHCP server.
1-11
Network diagram
Figure 1-3 Network diagram for authorized ARP configuration
# Configure the IP address of Ethernet 1/0.
[RouterA-Ethernet1/0] ip address 10.1.1.1 24
# Configure DHCP.
[RouterA] dhcp enable
[RouterA] dhcp server ip-pool 1
[RouterA-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0
[RouterA-dhcp-pool-1] quit
# Enter Layer 3 Ethernet interface view.

# Configure the DHCP server to support authorized ARP.

[RouterA-Ethernet1/0] dhcp update arp
# Enable authorized ARP.

[RouterA-Ethernet1/0] arp authorized enable
# Configure the aging time for authorized ARP entries.

[RouterA-Ethernet1/0] arp authorized time-out 120
[RouterB-Ethernet1/0] ip address dhcp-alloc
3) After Router B obtains an IP address from Router A, display the authorized ARP entry information
on Router A.
[RouterA] display arp all
Type: S-Static D-Dynamic A-Authorized
IP Address MAC Address VLAN ID Interface Aging Type
10.1.1.2 0012-3f86-e94c N/A Eth1/0 1 A
From the above information, you can see that Router A assigned an IP address of 10.1.1.2 to Router B.
1-12
Example for Configuring Authorized ARP on a DHCP Relay Agent
z Router A acts as a DHCP server with an IP address pool of 10.10.1.0/24.

z Router B is a DHCP relay agent, which conveys IP address from the DHCP server to the DHCP
client (Router C). Enable authorized ARP on Ethernet 1/1 of Router B.
Network diagram
Figure 1-4 Network diagram for authorized ARP configuration
# Configure DHCP.
[RouterA-dhcp-pool-1] gateway-list 10.10.1.1
# Enable DHCP.
[RouterB] dhcp enable
# Configure the IP addresses of Ethernet 1/0 and Ethernet 1/1.

[RouterB-Ethernet1/0] ip address 10.1.1.2 24
1-13
# Enable DHCP relay agent on Ethernet 1/1.
[RouterB-Ethernet1/1] dhcp select relay
# Add the DHCP server 10.1.1.1 to DHCP server group 1.

[RouterB] dhcp relay server-group 1 ip 10.1.1.1
# Correlate Ethernet 1/1 to DHCP server group 1.

[RouterB-Ethernet1/1] dhcp relay server-select 1
# Configure the DHCP server to support authorized ARP.

[RouterB-Ethernet1/1] dhcp update arp
# Enable authorized ARP.

[RouterB-Ethernet1/1] arp authorized enable
# Configure the aging time for authorized ARP entries.

[RouterB-Ethernet1/1] arp authorized time-out 120
[RouterC-Ethernet1/0] ip address dhcp-alloc
[RouterC-Ethernet1/0] quit
4) After Router B obtains the IP address from Router A, display the authorized ARP information on
Router B.
[RouterB] display arp all
Type: S-Static D-Dynamic A-Authorized
IP Address MAC Address VLAN ID Interface Aging Type
10.10.1.2 0012-3f86-e94c N/A Eth1/1 1 A
From the above information, you can see that Router A assigned an IP address of 10.10.1.2 to Router
C.
Configuring ARP Detection

z For information about DHCP snooping, refer to DHCP Configuration in the IP Services Volume.
Introduction to ARP Detection
In normal cases, a Layer 2 access device broadcasts an ARP request within a VLAN, and forwards ARP
replies 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 and other clients is modified.
Consequently, the attacker will receive the packets sent to the client.
1-14
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.
Follow these steps to enable ARP detection for a VLAN and specify a trusted port:

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.

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 replies. If the target MAC address is all-zero,
all-one, 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-one or
multicast IP addresses are considered invalid and the corresponding packets are discarded. With
this object specified, the source and destination IP addresses of ARP replies, and the source IP
address of ARP requests 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:

1-15
Specify objects for ARP arp detection validate Required

detection { dst-mac | ip | src-mac } * The default depends on the device model.
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.
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
Configure ARP packet rate limit ARP packet rate limit is
pps drop }
enabled by default.
Displaying and Maintaining ARP Detection

Display the VLANs enabled
display arp detection
with ARP detection
display arp detection statistics Available in any view

Display the ARP detection
[ interface interface-type
statistics
interface-number ]
Clear the ARP detection reset arp detection statistics [ interface
statistics interface-type interface-number ]
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.
1-16
Network diagram
Figure 1-5 Network diagram for ARP detection configuration
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> system-view
[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).
4) Configure Switch B
# Enable DHCP snooping.
<SwitchB> system-view
[SwitchB] dhcp-snooping
[SwitchB] interface ethernet 1/0
[SwitchB-Ethernet1/0] dhcp-snooping trust
[SwitchB-Ethernet1/0] quit
# 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 ethernet 1/0
[SwitchB-Ethernet1/0] 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 Ethernet 1/1 as 15 pps.

1-17
[SwitchB-Ethernet1/1] arp rate-limit rate 15 drop
[SwitchB-Ethernet1/2] arp rate-limit rate 15 drop
Configuring MFF

z For information about dynamic IP-MAC-port binding, refer to IP Source Guard Configuration in the
Security Volume.
z For information about VLAN mapping, refer to VLAN Mapping Configuration in the Access Volume.
z For information about DHCP snooping, refer to DHCP Configuration in the IP Services Volume.
z An MFF-enabled device and a host cannot ping each other.
Introduction to MFF
Traditional Ethernet networking solutions use the VLAN technology to isolate users at Layer 2 and to
allow them to communicate at Layer 3. However, when a large number of hosts need to be isolated at
Layer 2, many VLAN resources will be occupied, and many IP addresses are used because you have to
assign a network segment for each VLAN and an IP address for each VLAN interface for Layer 3
communication.
MAC-forced forwarding (MFF) was developed to provide a solution for Layer 2 isolation and Layer 3
communication between hosts in the same broadcast domain.
An MFF enabled device intercepts an ARP request and then returns the MAC address of a gateway (or
server) to the sender. In this way, the sender is forced to send packets to the gateway for traffic
monitoring and attack prevention.
Figure 1-6 Network diagram for MFF
As shown in Figure 1-6, Switch A and Switch B (Ethernet access nodes, or EANs) connect the hosts to
Switch C (aggregation node). The MFF enabled EANs forward packets from the hosts to the gateway
for further forwarding. Thus, both Layer 2 isolation and Layer 3 communication are enabled.
1-18
MFF is often used in cooperation with the DHCP snooping, ARP snooping, IP Source Guard, ARP
detection and VLAN mapping features to enhance network security by enabling traffic filtering, Layer 2
isolation and Layer 3 communication on the access switches.
Basic Concepts of MFF
User port
An MFF user port is directly connected to a host; it processes packets as follows:

z Allows DHCP packets and multicast packets to pass.
z Delivers ARP packets to the CPU.
z After learning gateways MAC addresses, a user port allows only the unicast packets with the
gateways MAC addresses as the destination MAC addresses to pass. If no gateways MAC
addresses are learned, a user port discards all received unicast packets.
Network port
An MFF network port is connected to a networking device, such as an access switch, a distribution
switch or a gateway. A network port processes packets as follows:
z Allows multicast packets and DHCP packets to pass.
z Delivers ARP packets to the CPU.
z Denies broadcast packets.
z You need to configure the following ports as network ports: upstream ports connected to a gateway,
ports connected to the downstream MFF devices in a cascaded network (a network with multiple
MFF devices connected to one another), and ports between devices in a ring network.
z A network port is not always an upstream port.
z If you enable MFF for a VLAN, each port in the VLAN must be an MFF network or user port.
Manual mode
The manual mode applies to the case where IP addresses are statically assigned to the hosts, and
therefore the hosts cannot obtain the gateway information through DHCP. In this case, a VLAN
maintains only the MAC address of the default gateway.
In the manual mode, after receiving an ARP request for a hosts MAC address from the gateway, the
MFF device directly replies the hosts MAC address to the gateway according to the ARP snooping
entries. The MFF device also forges ARP requests to get the gateways MAC address based on ARP
snooping entries.
After learning the gateways MAC address and then receiving an ARP packet with a different source
MAC address from the gateway, the MFF device will replace the old MAC address with the new one.
Automatic mode
The automatic mode applies to the situation where hosts use DHCP to obtain IP addresses.
With MFF automatic mode enabled, a DHCP snooping device, upon receiving a DHCP ACK message,
resolves Option 3 in the message (Router IP option) to obtain a gateway for the clients IP-MAC
snooping entry. If the DHCP ACK message contains multiple gateway addresses, only the first one is
1-19
recorded for the entry. If the message contains no gateway IP address, the first gateway recorded by
the current VLAN is used.
z In MFF automatic mode, a VLAN can learn and maintain up to 20 gateways. The gateway IP
addresses will not be updated, that is, the gateway information does not age unless MFF is
disabled.
z If the source MAC address of an incoming ARP packet from a gateway is different from the one
recorded, the MFF device will use the new MAC to replace the old one.
Detecting and maintaining gateways MAC addresses
You can configure the MFF device to detect gateways periodically.

To get a gateways MAC address, MFF uses the IP and MAC addresses of the first DHCP snooping
entry corresponding to the gateway as the source IP and MAC addresses of an ARP request, and sends
the ARP request to the gateway. Since then, MFF will always use this entry to detect the gateways
MAC address, unless the entry is removed. If the entry is removed, MFF will find another entry; if no any
other entry is found for the gateway, information about the gateway is removed.
ARP fast-reply mechanism
Like proxy ARP, the ARP fast-reply mechanism is used for Layer 3 communication between hosts,
which helps reduce the number of broadcast messages.
An MFF device processes ARP packets as follows:
z After receiving an ARP request from a host, the MFF device sends the MAC address of the
corresponding gateway to the host. In this way, hosts in the network have to communicate at Layer
3 through a gateway.
z After receiving an ARP request from a gateway, the MFF device sends the requested hosts MAC
address to the gateway if the corresponding entry is available; if the entry is not available, the MFF
device will forward the ARP request.
z The MFF device forwards ARP replies between hosts and gateways.
z If the source MAC addresses of ARP requests from gateways are different from those recorded,
the MFF device updates and broadcasts the IP and MAC addresses of the gateways.
RFC 4562: MAC-Forced Forwarding
Configuring MFF
Prerequisites
z Enable DHCP snooping on the device

z Configure DHCP snooping trusted ports
1-20
Enabling MFF

Enable MFF and specify an mac-forced-forwarding { auto Required

MFF operating mode | default-gateway gateway-ip } Disabled by default.
Configuring a network port

Enter port view
interface-number
Configure the port as a network mac-forced-forwarding Required

port network-port By default, the port is a user port.
Enabling periodic gateway probe

Enable periodic gateway MAC mac-forced-forwarding Required

address probe gateway probe Disabled by default.
Specifying the IP addresses of servers
You can specify a servers IP address in either manual or automatic MFF mode. The server can be a
DHCP server, a server providing some other service, or the real IP address of a VRRP standby group.
After you specify a servers IP address and then an ARP request from the server is received, the MFF
device will reply with the corresponding MAC address to the server. In this way, packets from a host to a
server are forwarded by the gateway, while packets from a server to a host are not forwarded by the
gateway.

Specify the IP addresses mac-forced-forwarding Required

of servers server server-ip&<1-10> No MFF server is specified by default.
1-21
Displaying and Maintaining MFF

Display MFF port configuration display mac-forced-forwarding
information interface
Display the MFF configuration display mac-forced-forwarding vlan
information of a specified VLAN vlan-id
MFF Configuration Example in a Tree Network
As shown in the following figure, all the devices are in the same VLAN. Host A, Host B, and Host C
obtain IP addresses from the DHCP server. They are isolated at Layer 2, and can communicate with
each other through Gateway.
Network diagram
Figure 1-7 Network diagram for MFF configuration
1) Configure Gateway
<Gateway> system-view
[Gateway] interface ethernet 0/1
[Gateway-Ethernet0/1] ip address 10.1.1.100 24
2) Configure the DHCP server
# Enable DHCP, and configure a DHCP address pool.
[Device] dhcp enable
[Device] dhcp server ip-pool 1
[Device-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0
# Add the gateways IP address into DHCP address pool 1.

[Device-dhcp-pool-1] gateway-list 10.1.1.100
1-22
[Device-dhcp-pool-1] quit

[Device-Ethernet0/2] ip address 10.1.1.50 24
3) Configure Switch A
[SwitchA] dhcp-snooping
# Enable MFF.
[SwitchA] vlan 100
[SwitchA-vlan-100] mac-forced-forwarding auto
[SwitchA-vlan-100] quit
# Configure Ethernet 1/2 as a network port.

[SwitchA] interface ethernet 1/2
[SwitchA-Ethernet1/2] mac-forced-forwarding network-port
# Configure Ethernet 1/2 as a DHCP snooping trusted port.

[SwitchA-Ethernet1/2] dhcp-snooping trust
# Enable MFF.
[SwitchB] vlan 100
[SwitchB-vlan-100] mac-forced-forwarding auto
[SwitchB-vlan-100] quit

[SwitchB-Ethernet1/6] mac-forced-forwarding network-port

MFF Configuration Example in a Ring Network
As shown in the following figure, all the devices are in the same VLAN, and the switches form a ring.
Host A, Host B, and Host C obtain IP addresses from the DHCP server. They are isolated at Layer 2,
and can communicate with each other through Gateway.
1-23
Network diagram
Figure 1-8 Network diagram for MFF configuration
1) Configure Gateway
<Gateway> system-view
[Gateway] interface ethernet 0/1
[Gateway-Ethernet0/1] ip address 10.1.1.100 24
# Enable DHCP and configure an address pool.
[Device] dhcp enable
[Device] dhcp server ip-pool 1
[Device-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0
# Add gateways IP address into DHCP address pool 1.

[Device-dhcp-pool-1] gateway-list 10.1.1.100
[Device-dhcp-pool-1] quit

[SwitchA] dhcp-snooping
# Enable STP.
[SwitchA] stp enable
# Enable MFF.
[SwitchA] vlan 100
[SwitchA-vlan-100] mac-forced-forwarding auto
[SwitchA-vlan-100] quit
1-24

[SwitchA-Ethernet1/2] dhcp-snooping trust
[SwitchA-Ethernet1/2] quit


[SwitchA-Ethernet1/3] dhcp-snooping trust no-user-binding
# Enable STP.
[SwitchB] stp enable
# Enable MFF
[SwitchB] vlan 100
[SwitchB-vlan-100] mac-forced-forwarding auto
[SwitchB-vlan-100] quit


[SwitchB-Ethernet1/4] dhcp-snooping trust no-user-binding


5) Configure Switch C
# Enable STP.
<SwitchC> system-view
[SwitchC] stp enable
1-25
Configuring ARP Snooping
Introduction to ARP Snooping
The ARP snooping feature is used in Layer 2 switching networks. It creates ARP snooping entries using
ARP packets, and the entries can be used by MFF to answer ARP requests from a gateway.
Operation of ARP Snooping
After you enable ARP snooping on a VLAN of a device, ARP packets received by the interfaces of the
VLAN are redirected to the CPU. The CPU uses ARP packets to create ARP snooping entries
comprising source IP and MAC addresses, source VLAN and receiving port information.
The aging time and valid period of an ARP snooping entry are 25 minutes and 15 minutes respectively.
If an ARP snooping entry is not updated within 15 minutes since its creation, it will become invalid and
cannot be used. After that, if an ARP packet whose source IP and MAC addresses correspond with the
entry is received, the entry becomes valid, and its aging timer restarts. If the aging time of an ARP entry
expires, the entry is removed.
If an ARP packet that has the same source IP address as but has a different source MAC address from
a valid ARP entry is received, the ARP packet is considered as an attack. Because an ARP snooping
entry conflict occurs in this case, the ARP snooping entry becomes invalid and is removed after 25
minutes.
Configuring ARP Snooping

Required
Enable ARP snooping arp-snooping enable
Displaying and Maintaining ARP Snooping

display arp-snooping [ ip
Display ARP snooping entries Available in any view
ip-address | vlan vlan-id ]
reset arp-snooping [ ip
Remove ARP snooping entries Available in user view
ip-address | vlan vlan-id ]
1-26
Configuring the ARP Fast-Reply Mechanism
Introduction to ARP Fast-Reply Mechanism Used in a Wireless Network
In a wireless network, APs are connected to the AC through tunnels, so the stations can communicate
with the AC through APs and can further access the gateway through the AC. If a station broadcasts an
ARP request through its AP, the AC needs to send the ARP request to the other APs. Thus, a large
amount of tunnel resources is occupied, affecting network performance. To solve this problem, the ARP
fast-reply mechanism is introduced.
With this feature enabled on a VLAN, the AC can answer ARP requests from the stations in the VLAN,
thus to reduce the number of ARP broadcast messages on the network.
The ARP fast-reply mechanism is different from that of the MFF feature. MFF is enabled on access
devices to forward clients packets to the gateway, implementing Layer 3 communication and Layer 2
isolation. The ARP fast-reply mechanism for wireless networks helps reduce ARP broadcasts and
tunnel resource consumption and its implementation is based on DHCP snooping and ARP snooping
entries.
The user information can be recorded in DHCP snooping entries and ARP snooping entries.
Working Mechanism
If the device receives an ARP request with the destination IP address being the corresponding VLAN
interfaces IP address, it processes the packet as a normal ARP packet. If not, it searches the DHCP
snooping table for a match:
z If a match is found and the interface of the entry is the Ethernet interface that received the ARP
request, no reply is returned; otherwise, a reply is returned.
z If no match is found, the device searches the ARP snooping table. If a match is found and the
interface of the matching entry is the Ethernet interface that received the ARP request, no reply is
returned; otherwise, a reply is returned.
z If no match is found in both the DHCP snooping and ARP snooping tables, the ARP request is
forwarded or delivered to other modules.
Configuring the ARP Fast-Reply Mechanism

1-27
Enable the ARP fast-reply Required

arp fast-reply enable
mechanism Disabled by default.
z Enabling the ARP fast-reply mechanism also enables DHCP snooping for the VLAN.
z To better use the ARP fast-reply mechanism, you can enable ARP snooping at the same time.
ARP Fast-Reply Mechanism Configuration Example
As shown in the following figure, Station 1, Station 2 through Station 100, and Station 101 through 200
can access the network through AP 1, AP 2 and AP 3 respectively. AP 1, AP 2 and AP 3 are connected
to the AC through Switch.
If Station 1 wants to access Station 200, it broadcasts an ARP request and the AC sends it to AP 2 and
AP 3. As ARP broadcasts occupy tunnel resources excessively especially when many APs exist on the
network, you can enable the ARP fast-reply mechanism on the AC to reduce the number of ARP
broadcasts. In the following example, Station 200 has obtained an IP address through DHCP. After ARP
fast-reply is enabled, the AC, upon receiving an ARP request from Station 1, can directly return an ARP
reply without sending the ARP request to other APs.
Network diagram
Figure 1-9 Network diagram for ARP fast-reply mechanism
1) Configure the AC
1-28
# Refer to the wireless controller configuration manual. (In Figure 1-9, the APs are connected to VLAN
1.)
2) Enable ARP snooping for VLAN 1 on the AC.
<AC> system-view
[AC] vlan 1
[AC-vlan1] arp-snooping enable
[AC-vlan1] quit
3) Enable ARP fast-reply for VLAN 1 on the AC.
[AC] vlan 1
[AC-vlan1] arp fast-reply enable
[AC-vlan1] quit
Displaying and Maintaining ARP

display arp { { all | dynamic | static } | vlan vlan-id
For
| interface interface-type interface-number }
centralized
[ [ verbose ] [ | { begin | exclude | include }
Display the devices
regular-expression ] | count ] Available in
ARP entries in
display arp { { all | dynamic | static } [ slot slot-id ] any view
the ARP table
For distributed | vlan vlan-id | interface interface-type
devices interface-number } [ [ verbose ] [ | { begin |
exclude | include } regular-expression ] | count ]
For
Display the display arp ip-address [ verbose ] [ | { begin |
centralized
ARP entry for exclude | include } regular-expression ] Available in
devices
a specified IP any view
address For distributed display arp ip-address [ slot slot-id ] [ verbose ] [ |
devices { begin | exclude | include } regular-expression ]
display arp vpn-instance vpn-instance-name [ |

Display the ARP entries for a Available in
{ begin | exclude | include } regular-expression |
specified VPN instance any view
count ]
Display the aging time for Available in
display arp timer aging
dynamic ARP entries any view
For
reset arp { all | dynamic | static | interface
Clear ARP centralized
interface-type interface-number } Available in
entries from devices
user view
the ARP table For distributed reset arp { all | dynamic | static | slot slot-id |
devices interface interface-type interface-number }
Support for the verbose argument in the commands depends on the device model.
1-29
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

For an ARP request of a host on a network to be forwarded to an interface that is on the same network
but isolated at Layer 2 or a host on another network, the device connecting the two physical or virtual
networks must be able to respond to the request. This is achieved by proxy ARP.
Proxy ARP allows Layer 3 communication between interfaces isolated at Layer 2 or located on different
networks.
In one of the following cases, you need to enable the 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:
Enter interface view Required
interface-number
Required
Enable proxy ARP proxy-arp enable
Required
Enable local proxy ARP local-proxy-arp enable
2-1
Displaying and Maintaining Proxy ARP
Display whether proxy ARP is display proxy-arp [ interface
enabled interface-type interface-number ]
Display whether local proxy display local-proxy-arp [ interface
ARP is enabled interface-type interface-number ]
Proxy ARP Configuration Examples

Proxy ARP Configuration Example (on Routers)
Host A and Host D are on the same subnet. But from the angle of the device, they are located in
different subnets. Configure proxy ARP on the device to enable the communication between Host A and
Host D.
Network diagram
Figure 2-1 Network diagram for proxy ARP (on routers)
Host A Host B
192.168.10.100/16
0000.0c94.36aa
Subnet A
Eth1/0
192.168.10.99/24
Router
Eth1/1
192.168.20.99/24
Subnet B
192.168.20.200/16
0000.0c94.36dd
Host C Host D
1) Configure the IP address 192.168.10.99/24 for Ethernet 1/0 and 192.168.20.99/24 for Ethernet 1/1.
2) Configure proxy ARP on the device to enable the communication between Host A and Host D.
[Router-Ethernet1/0] proxy-arp enable
2-2
[Router-Ethernet1/1] proxy-arp enable
Proxy ARP Configuration Example (on Switches)
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-2 Network diagram for proxy ARP (on switches)
# Configure Proxy ARP on the device to enable the communication between Host A and Host D.
<Switch> system-view
[Switch] vlan 2
[Switch-vlan2] quit
[Switch] interface vlan-interface 1
[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-interface2] proxy-arp enable
2-3
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 Ethernet 1/0 and Ethernet 1/1
of Switch respectively.
z The switch is connected to Router via Ethernet 1/2.
z Ethernet 1/0 and Ethernet 1/1 isolated at layer 2 can implement layer 3 communication.
Network diagram
Figure 2-3 Network diagram for local proxy ARP between isolated ports
Router
Eth1/0
VLAN 2
Vlan-int2
192.168.10.100/16
VLAN 2
port-isolate group 2
Eth1/2
uplink-port
Eth1/0
Eth1/1
Host A Switch Host B

192.168.10.99/16 192.168.10.200/16
z The switch in this diagram is a distributed device.

z The switch isolates all traffic in this configuration example, so you need to configure local proxy
ARP on VLAN-interface 2 of the router to enable the communication between Host A and Host B. If
the two ports (Ethernet 1/0 and Ethernet 1/1) on the switch are isolated only at Layer 2, you can
enable the communication between the two hosts by configuring local proxy ARP directly on
VLAN-interface 2 of the switch.
1) Configure the Switch

# Add Ethernet 1/0, Ethernet 1/1 and Ethernet 1/2 to VLAN 2. Host A and Host B are isolated and
unable to exchange Layer 2 packets.
[Switch] port-isolate group 2
[Switch] vlan 2
[Switch-vlan2] port ethernet 1/0
[Switch-vlan2] quit
[Switch] interface ethernet 1/0
2-4
[Switch-Ethernet1/0] port-isolate enable group 2
[Switch-Ethernet1/0] interface ethernet 1/1
[Switch-Ethernet1/1] port-isolate enable group 2
[Switch-Ethernet1/1] interface ethernet 1/2
[Switch-Ethernet1/2] port-isolate uplink-port group 2
# Create VLAN 2, and add Ethernet 1/0 to VLAN 2.
[Router] vlan 2
[Router-vlan2] port ethernet 1/0
[Router-vlan2] interface vlan-interface 2
[Router-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.
[Router-Vlan-interface2] local-proxy-arp enable
[Router-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 Ethernet 1/0 belongs to VLAN 2 and Ethernet 1/1 belongs to VLAN 3.
z Layer 3 communication is implemented between the sub-VLANs.
Network diagram
Figure 2-4 Network diagram for local proxy ARP in super VLAN
# Create the super VLAN and the sub-VLANs. Add Ethernet 1/0 to VLAN 2 and Ethernet 1/1 to VLAN 3.
Configure the IP address 192.168.10.100/16 for the interface of VLAN 10.
2-5
[Switch] vlan 2
[Switch-vlan2] quit
[Switch] vlan 3
[Switch-vlan3] quit
[Switch] vlan 10
[Switch-vlan10] supervlan
[Switch-vlan10] subvlan 2 3
[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 is attached to Router.

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

# Create VLAN 2, VLAN 3, and VLAN 5 on the Switch. Add Ethernet 1/0 to VLAN 2, Ethernet 1/1 to
VLAN 3, and Ethernet 1/2 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.
[Switch] vlan 2
[Switch-vlan2] quit
[Switch] vlan 3
[Switch-vlan3] quit
[Switch] vlan 5
[Switch-vlan5] isolate-user-vlan enable
[Switch-vlan5] quit
[Switch] isolate-user-vlan 5 secondary 2 3
# Create VLAN 5 and add Ethernet 1/0 to it.
[Router] vlan 5
[Router-vlan5] port ethernet 1/0
[Router-vlan5] interface vlan-interface 5
[Router-Vlan-interface5] ip address 192.168.10.100 255.255.0.0
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.
2-7
[Router-Vlan-interface5] local-proxy-arp enable
[Router-Vlan-interface5] quit
Ping Host B on Host A to verify that the two hosts are reachable to each other, which indicates Layer 3
2-8
Table of Contents
1 IP Terminal Access Configuration 1-1

IP Terminal Access Overview 1-1
IP Terminal Access Features 1-2
IP Terminal Access Specifications 1-5
IP Terminal Access Configuration Task List 1-5
Configuring the Initiator 1-6
Enabling IP Terminal Access 1-6
Creating an IP Terminal Access Service1-6
Creating an IP Terminal1-7
Configuring Receiver Parameters 1-7
Configuring Terminal Address Binding1-7
Configuring Server Connection Authentication 1-8
Setting the Terminal Timeout Lock Timer 1-8
Specifying Terminal Lock Hotkey(s)1-8
Setting the Terminal Timeout Disconnection Timer 1-8
Configuring Manual Link Disconnection 1-9
Enabling Encryption1-9
Configuring Source Address Binding 1-9
Configure VPN Binding1-9
Configuring AAA Authentication 1-10
Configuring the Processing Approach for Special Characters 1-12
Configuring Link Detection 1-12
Configuring TCP Buffers1-12
Enabling Telnet Parameters Negotiation1-13
Configuring the Receiver 1-13
Displaying and Maintaining IP Terminal Access Configuration 1-13
IP Terminal Access Configuration Example1-13
i
1 IP Terminal Access Configuration
When configuring IP terminal access, go to these sections for information you are interested in:
z IP Terminal Access Overview
z IP Terminal Access Configuration Task List
z Configuring the Initiator
z Configuring the Receiver
z Displaying and Maintaining IP Terminal Access Configuration
z IP Terminal Access Configuration Example
IP Terminal Access Overview

IP terminal access allows a terminal to access a remote Unix/Linux server, which is also known as a
front-end processor (FEP) through a router. The router serves as the initiator to forward data between
the terminal and the Unix/Linux server that serves as the receiver. Services running on the Unix/Linux
server use the ttyd program to send service interfaces to the terminal through the router. IP terminal
access identifies a terminal using its IP address and offers a series of functions such as data encryption,
screen saving and terminal lock.
Figure 1-1 shows a typical IP terminal access application scenario.
Figure 1-1 Typical application of IP terminal access
1-1
As shown in the figure above, the initiator, which is enabled with IP terminal access, initiates a TCP
connection to the receiver for the terminal in a bank outlet to access the FEP in the bank branch over an
IP network. Banking services run on the FEP. Information entered into the terminal by an employee at
the bank outlet is sent to the FEP through the initiator. The FEP then returns the corresponding service
interface to the service terminal though the initiator, thereby implementing data exchange between the
outlet and the branch.
IP Terminal Access Features
In Figure 1-2, the IP terminals are connected to a router through Ethernet interfaces, and the router is
connected to the FEPs over an IP network.
Figure 1-2 Network diagram for IP terminal access
IP terminal access supports the following features:
Terminal address binding
The terminal address binding feature can prevent unqualified users from accessing the router. There
are two address binding methods:
z IP address binding
z IP-to-MAC address binding
If the access information (IP address/IP and MAC addresses) of a terminal matches a configured
binding entry on the router, the terminal is considered qualified and permitted to access the router;
otherwise, the terminal cannot access the router.
If the access router is not directly connected to terminals, packets from terminals do not carry their own
MAC addresses, and therefore, you cannot bind MAC addresses for them.
1-2
Server connection authentication
A user may need the FEP to perform authentication on the access router to enhance data security. At
present, two authentication modes are supported: character string-based authentication and
MAC-based authentication.
In character string-based authentication, which is similar to password authentication, the same
authentication character string is configured on both the FEP and the router. To establish a connection
with the FEP, the router sends the authentication character string to the FEP, which then checks
whether the authentication character string is correct. If yes, the authentication succeeds; if not, the
authentication fails and the connection attempt fails.
In MAC-based authentication, the same MAC address is configured on both the FEP and the router,
and the authentication process is the same as that of character string-based authentication. This MAC
address belongs to an interface on the router and can be specified with a command.
Terminal timeout lock
If a terminal does not exchange data with the access router within a specified period, the terminal is
locked and cannot be operated until it passes authentication again. If no authentication is configured on
the router, the function does not take effect.
Terminal hotkey lock
The access router provides the terminal hotkey lock function for users to lock terminals using hotkeys.
After a terminal is locked, you need to enter authentication information to operate it. If no authentication
is configured on the router, the function does not take effect.
Note that the username for unlocking the terminal should be consistent with the authentication
username used before the terminal is locked.
Terminal timeout disconnection
If a terminal does not exchange data with the router within a specified period, the router disconnects the
terminal from the FEP to release resources without affecting other connections.
Manual link disconnection
With this function, when you want to adjust attributes for a terminal or the TCP connection to a terminal
is abnormal, you can manually disconnect from the terminal on the router.
Encryption
Due to the extensive use of IP terminal access in banking systems, the requirements of data security
become higher and higher. The terminal access data encryption function can encrypt data transmitted
between the router and FEPs to enhance data security.
As shown in Figure 1-3, data is transmitted in ciphertext between Router A and the FEP. Router A and
the FEP that runs the program ttyd are responsible for data encryption and decryption. At present,
advanced encryption standard (AES) encryption is supported.
1-3
Figure 1-3 Data encryption between the router and the FEP
Source address binding
The source address binding feature allows you to use the IP address of a stable interface (a loopback
interface or dialer interface is recommended) as the source IP address for TCP connections initiated
from the router to FEPs. This feature can be used in the following cases:
z In a wide area network (WAN), the router accesses a FEP through the primary dial-up link after
passing authentication. If the primary link fails, the router tries to use the secondary link, but it
cannot pass the authentication of the FEP because the IP address is changed.
z For security or some other reason, the actual source IP addresses of TCP connections from the
router to FEPs may need to be hidden.
Make sure that the FEPs and the specified source IP address of the router are reachable to each other.
VPN binding
The VPN binding feature enables IP terminal access to support VPN multi-instance, that is, you can
assign terminals connected to the router into multiple VPNs. A terminal in a VPN can access FEPs or
remote routers in the VPN.
AAA authentication
To enhance security of IP terminal access, the access router provides AAA authentication to block
illegal users. Two authentication modes, password and scheme, are supported. In password mode,
the user needs to enter the correct password to pass authentication. In scheme mode, authentication is
implemented by an AAA authentication server, such as a RADIUS server.
Application backup
The application backup feature allows you to specify a primary FEP and multiple secondary FEPs on
the access router. When the primary FEP fails, the access router can contact a secondary FEP to
ensure continuous service.
Special characters processing
To enable different terminals to recognize special characters (such as the carriage return character) of
the FEP, you can transform the new-line character CRLF (ASCII code 0d0a or 0d00) or the carriage
return character CR (ASII code 0d) to a common form (CR or CRLF).
Link detection
With the link detection feature, a failure of the link between a terminal and the access router or between
the access router and the FEP can be located in time, so that the corresponding network resources can
be released.
1-4
Service screen saving
With the service screen saving feature, when an IP terminal is locked manually or due to timeout, the
current operation interface on the terminal is saved and will be displayed after the terminal is unlocked.
IP Terminal Access Specifications
Initiator Specifications
Table 1-1 Initiator specifications
Item Description
Maximum number of connections supported by the router 256
Maximum number of services supported by the router 64
Maximum number of connections that an IP terminal can initiate 16
Maximum number of terminals that can use a common service 256
Receiver specifications
Table 1-2 Receiver specifications
Item Description
Maximum number of VTYs supported by a Unix FEP 250
Maximum number of VTYs supported by a Linux FEP 160
z Suse Linux
z Turbo Linux
z Redflag Linux
Supported Linux versions z Redhat
z SCO Unix
z AIX
z Red Hat Linux 9.0
IP Terminal Access Configuration Task List

You need to perform configurations on the initiator and the receiver respectively as needed. The initiator
is the router and the receiver is the Unix/Linux server.
Complete the following tasks to configure IP terminal access:
1-5
Task Remarks
Enabling IP Terminal Access Required
Creating an IP Terminal Access Service Required
Creating an IP Terminal Required
Configuring Receiver Parameters Required
Configuring Terminal Address Binding Optional
Configuring Server Connection Authentication Optional
Setting the Terminal Timeout Lock Timer Optional
Specifying Terminal Lock Hotkey(s) Optional
Configuring the Setting the Terminal Timeout Disconnection Timer Optional

Initiator Configuring Manual Link Disconnection Optional
Enabling Encryption Optional
Configuring Source Address Binding Optional
Configure VPN Binding Optional
Configuring AAA Authentication Optional
Configuring the Processing Approach for Special Characters Optional
Configuring Link Detection Optional
Configuring TCP Buffers Optional
Enabling Telnet Parameters Negotiation Optional
Configuring the Receiver Required
Configuring the Initiator

Enabling IP Terminal Access
Follow these steps to enable IP terminal access:

Required
Enable IP terminal access ipta server enable
Creating an IP Terminal Access Service
IP terminal access services are provided by the receiver. After a service is created on the initiator, the
command line interface (CLI) turns from system view to IP terminal access (IPTA) service view. Then,
you can configure attributes for the service (such as authentication mode and encryption). When a
terminal user requests this service, the initiator will create a connection to the receiver based on the
configured information.
Follow these steps to create an IP terminal access service:
1-6
Create an IP terminal access
ipta service service-name Required
service
Creating an IP Terminal
You need to specify a terminal number when creating an IP terminal to uniquely identify the IP terminal
on the initiator. You can bind a terminal number to the IP address of a terminal through terminal address
binding. After a terminal is created, the CLI turns from system view to terminal view. Then, you can
configure attributes (such as an IP address or a MAC address) for the terminal.
Follow these steps to create an IP terminal:

Create an IP terminal ipta terminal ttyid Required
Configuring Receiver Parameters
You can specify several receivers with different priorities on the initiator. The receiver with the highest
priority is the primary receiver, and others are secondary ones.
Follow these steps to configure receiver parameters:

Enter IPTA service view ipta service service-name
Required
server ip ip-address port
Specify a receiver port-number [ priority By default, no FEP is specified
priority-level ] for the IPTA service. The
default FEP priority is 0.
Allow the terminal(s) to access
terminal ttyid [ to ttyid ] Required
the service
Required
Specify a listen port for the
listen port port-number No listen port is specified for an
service
IPTA service by default.
Configuring Terminal Address Binding
Follow these steps to configure terminal address binding:

Enter terminal view ipta terminal ttyid
1-7
Required
Bind an IP address or an IP
ip ip-address [ mac By default, no IP or MAC
address and MAC address to
mac-address ] address is bound to the
the terminal
terminal.
Configuring Server Connection Authentication
Follow these steps to configure server connection authentication:

ipta bind { string string | Required

Specify the MAC address
mac-address interface By default, no authentication is
or string for server
{ interface-type interface-number | performed between the access
connection authentication
interface-name } router and a receiver.
Setting the Terminal Timeout Lock Timer
Follow these steps to set the terminal timeout lock timer:

Set the terminal timeout lock timer idle-timeout seconds Optional

timer for the service lock 600 seconds by default.
Specifying Terminal Lock Hotkey(s)
Follow these steps to specify IP terminal lock hotkey(s):

Specify IP terminal lock Required

ipta lock-key ascii-cod &<1-3>
hotkey(s) Not specified by default.
Setting the Terminal Timeout Disconnection Timer
Follow these steps to set the terminal timeout disconnection timer:

1-8
Set the terminal timeout timer idle-timeout seconds Optional

disconnection timer disconnect 600 seconds by default.
Configuring Manual Link Disconnection
Follow these steps to configure manual link disconnection:

ipta disconnect { all | service
Manually disconnect
service-name | terminal ttyid Required
terminal(s) from receiver(s)
[ service service-name ] }
Enabling Encryption
Follow these steps to enable data encryption:

Enable data encryption using Required

encryption algorithm { aes |
the specified encryption
quick } Disabled by default.
algorithm
Configuring Source Address Binding
Follow these steps to configure source address binding:

Required
By default, no source IP
Configure source address address is bound to the service.
source ip ip-address
binding The IP address of the outbound
interface is used as the source
IP address of TCP connections.
Configure VPN Binding
You can configure VPN binding in system view or terminal view.

Follow these steps to configure VPN binding in system view:
1-9
Required
ipta bind vpn-instance
Bind the terminal(s) to the VPN No terminal-VPN binding is
vpn-name terminal ttyid-list
configured by default.
Follow these steps to configure VPN binding in terminal view:

Required
Bind the terminal to the VPN bind vpn-instance vpn-name No terminal-VPN binding is
Configuring AAA Authentication
IP terminal access supports three authentication modes: none, password, and scheme.
z With the none mode configured, a service can be accessed without authentication. However, this
may put security into risk.
z With the password mode configured, a service cannot be accessed until the correct password is
provided. The password needs to be configured on the router beforehand.
z With the scheme mode configured, a service cannot be accessed until both the correct username
and password are provided. The username and password need to be configured on the router
beforehand. The scheme mode provides local authentication and remote authentication. For local
authentication, you need to configure a local user and set corresponding parameters (for details,
refer to scheme mode configuration steps); for remote authentication, you need to set the
username and password on the remote authentication server. For detailed information about
authentication modes and parameters, refer to AAA RADIUS HWTACACS Configuration in the
Security Volume. By default, local authentication is adopted.
Follow these steps to configure the none authentication mode:

Required
Configure the IP terminal By default, the IP terminal
authentication-mode none authentication mode is none;
authentication mode as none
that is, no terminal
1-10
Follow these steps to configure the password authentication mode:

Required
authentication-mode
authentication mode as authentication mode is none;
password
password that is, no terminal
Required
set authentication password By default, no authentication is
Configure a login password
{ cipher | simple } password performed, and no login
password is configured.
Follow these steps to configure the scheme authentication mode (local authentication):

Required
authentication mode as authentication-mode scheme authentication mode is none;
scheme that is, no terminal
Required
Create a local user and enter
local-user user-name By default, no local user is
local user view
configured on the device.
Configure an authentication password { cipher | simple }
Required
password password
Configure the service type for service-type terminal [ level
Required
the user level ] }
For more information about the local-user, password and service-type commands, refer to the AAA
RADIUS HWTACACS Configuration in the Security Volume.
1-11
Configuring the Processing Approach for Special Characters
Follow these steps to configure the processing approach for special characters:

Required
Specify a processing approach
transform enter { cr | crlf } By default, the system does not
for CR and CRLF
transform CR and CRLF.
Configuring Link Detection
The router periodically sends keepalives to detect the links to a terminal and to a FEP.
Follow these steps to configure link detection:

Optional
Configure parameters for By default, the interval for sending
tcp keepalive time counter keepalives is 300 seconds, and the
sending keepalives
maximum number of keepalive
sending times is 3.
Keepalive parameters take effect for connections established after they are configured.
Configuring TCP Buffers
Follow these steps to configure TCP buffers:

Configure the size of the TCP Optional

tcp recvbuf-size recvsize
receive buffer 2048 bytes by default.
Configure the size of the TCP Optional

tcp sendbuf-size sendsize
send buffer 2048 bytes by default.
1-12
Enabling Telnet Parameters Negotiation
With the telnet parameters negotiation function enabled for a terminal, the router negotiates parameters
such as the terminal type and terminal rate before establishing a telnet connection.
Follow these steps to enable the telnet parameters negotiation function:

Enable telnet parameters Required

telnet negotiation enable
negotiation Disabled by default.
Configuring the Receiver

The receiver of IP terminal access is an FEP. The main program of terminal access at an FEP is the
program ttyd (ttyd executable), which implements data exchange with the router-side programs. For
how to configure FEPs of different types, refer to FEP Installation and Configuration in Terminal Access
Configuration in the IP Services Volume.
Displaying and Maintaining IP Terminal Access Configuration

display ipta { status | statistics }
{ service [ service-name ] | terminal Available in any view
IP terminal access
[ ttyid [ service service-name ] ] }
reset ipta statistics { service
Clear the statistics of a
[ service-name ] | terminal ttyid Available in user view
specified terminal/service
[ service service-name ] }
IP Terminal Access Configuration Example

As shown in the following figure, the chuxu and duigong services run on the Unix server, whose IP
address is 16.58.70.240. The listen ports of the ttyd program on the Unix server are 9010 and 9020.
Four terminals are connected to the Ethernet interfaces on a switch, which is connected to the router
through an Ethernet interface. Configure IP terminal access on the router for the terminals to access the
services. It is required to specify source IP address 6.6.6.1 for the router to establish TCP connections
to the server.
1-13
Network Diagram
Figure 1-4 Network diagram for IP terminal access
1) Configure the router (initiator).

# Enable IP terminal access.
[Sysname] ipta server enable
# Configure Terminal A.
[Sysname] ipta terminal 1
[Sysname-ipta-terminal-1] ip 1.1.1.2 mac 11e0-fc12-433b
[Sysname-ipta-terminal-1] telnet negotiation enable
[Sysname-ipta-terminal-1] transform enter cr
[Sysname-ipta-terminal-1] quit
The configurations of Terminal B, Terminal C, and Terminal D are similar to that of Terminal A and thus
omitted.
# Configure the IP address of the dialer interface.
[Sysname] interface dialer 0
[Sysname-Dialer0] ip address 6.6.1.1 255.255.255.0
[Sysname-Dialer0] quit
# Configure the duigong service.

[Sysname] ipta service duigong
[Sysname-ipta-service-duigong] server ip 2.2.2.2 port 9010 [Sysname-ipta-service-duigong]
listen port 1024
[Sysname-ipta-service-duigong] terminal 1 to 4
[Sysname-ipta-service-duigong] quit
1-14
# Configure the chuxu service.
[Sysname] ipta lock-key 27
[Sysname] ipta service chuxu
[Sysname-ipta-service-chuxu] server ip 2.2.2.2 port 9020 priority 0
[Sysname-ipta-service-chuxu] listen port 2048
[Sysname-ipta-service-chuxu] terminal 1 to 4
[Sysname-ipta-service-chuxu] timer idle-timeout 60 lock
[Sysname-ipta-service-chuxu] encryption algorithm aes
[Sysname-ipta-service-chuxu] tcp recvbuf-size 512
[Sysname-ipta-service-chuxu] tcp sendbuf-size 512
[Sysname-ipta-service-chuxu] tcp keepalive 1800 2
[Sysname-ipta-service-chuxu] set authentication password cipher ipta
[Sysname-ipta-service-chuxu] authentication-mode password
[Sysname-ipta-service-chuxu] source ip 6.6.1.1
[Sysname-ipta-service-chuxu] quit
# Configure Ethernet interfaces.

[Sysname-Ethernet1/2] ip address 1.1.1.1 255.255.0.0
2) Configuring the Unix server (receiver)
# Install the ttyd program.
Before configuring the receiver, you need to know the operating system and version of the receiver. In
this chapter, Sco openserver Unix 5.0.5 is adopted.
For installing ttyd, ttyadmcmd and ttyadm programs using a floppy disk or FTP, refer to FEP Installation
and Configuration in Terminal Access Configuration in the IP Services Volume.
# Add the following command lines in the system configuration file /etc/inittab.
z Add the duigong service terminal IDs.
C50:234:respawn:/etc/getty ttyp50 m
z Add the chuxu service terminal IDs.
Because active terminals are used, you need to configure the pseudo terminals as respawn.
z Execute the init q command to bring the configuration into effect.
# init q
# Create the configuration files for the services.

z Create the configuration file ttyd_duigong.conf on the FEP.
serverport 9010
1-15
mode 1
ttyp50 6.6.1.1 1
ttyp51 6.6.1.1 2
ttyp52 6.6.1.1 3
ttyp53 6.6.1.1 4
z Create the configuration file ttyd_chuxu.conf on the FEP.
serverport 9020
mode 1
screen 1
sendsize 512
readsize 300
ttyp31 6.6.1.1 1
ttyp32 6.6.1.1 2
ttyp33 6.6.1.1 3
ttyp34 6.6.1.1 4
# Configure routes.
z Add the following routes on the FEP.
# route add 6.6.1.1 -netmask 255.0.0.0 16.58.70.1
z Check the routing table on the Unix server using the following command.
# netstat -r
Add the route configuration into the /etc/rc2.d/S85tcp file, so that the system can automatically add the
corresponding routes after startup.
# Modify the configuration file of the bank service.
Because service programs vary with banks, the configuration approaches are different. Each bank can
modify the terminal configuration files of service programs independently, such as the terminal
emulation type, type of the card swipe machine, printer and password keyboard. Terminals can work
normally only after the terminal configuration files are correctly configured.
# Run the ttyd program.
Start the ttyd program on the FEP.
# /etc/ttyd /etc/ttyd_duigong.conf
# /etc/ttyd /etc/ttyd_chuxu.conf
You can follow these steps to enable ttyd autorun at system startup.
z Create the /etc/rc2.d/S99ttyd file, and add the commands for starting ttyd into the file.
/etc/ttyd /etc/ttyd_duigong.conf
/etc/ttyd /etc/ttyd_chuxu.conf
z Change the file mode of the file to the executable mode.
# chmod u+x /etc/rc2.d/S99ttyd
Thus, the ttyd program can run automatically at system startup.
1-16
The above configurations are performed on Sco openserver Unix 5.0.5. For configurations on a FEP of
a different Unix platform, refer to FEP Installation and Configuration in Terminal Access Configuration in
the IP Services Volume.
1-17
Table of Contents
1 DHCP Overview1-1
Introduction to DHCP 1-1
DHCP Address Allocation 1-2
Allocation Mechanisms1-2
Dynamic IP Address Allocation Process 1-3
IP Address Lease Extension 1-3
DHCP Message Format 1-4
DHCP Options1-4
DHCP Options Overview 1-4
Introduction to DHCP Options 1-5
Self-Defined Options 1-5
Protocols and Standards1-8
2 DHCP Server Configuration2-1

Introduction to DHCP Server 2-1
Application Environment2-1
DHCP Address Pool 2-1
IP Address Allocation Sequence 2-3
DHCP Server Configuration Task List 2-3
Enabling DHCP 2-3
Enabling the DHCP Server on an Interface 2-3
Configuring an Address Pool for the DHCP Server 2-4
Configuration Task List2-4
Creating a DHCP Address Pool 2-4
Configuring an Address Allocation Mode 2-5
Configuring a Domain Name Suffix for the Client 2-7
Configuring DNS Servers for the Client2-7
Configuring WINS Servers and NetBIOS Node Type for the Client2-7
Configuring the BIMS Server Information for the Client 2-8
Configuring Gateways for the Client2-9
Configuring Option 184 Parameters for the Client with Voice Service2-9
Configuring the TFTP Server and Bootfile Name for the Client 2-10
Configuring Self-Defined DHCP Options2-10
Configuring the DHCP Server Security Functions 2-11
Enabling Unauthorized DHCP Server Detection2-11
Configuring IP Address Conflict Detection 2-12
Configuring the DHCP Server to Support Authorized ARP2-12
Configuring the Handling Mode for Option 82 2-13
Displaying and Maintaining the DHCP Server 2-14
DHCP Server Configuration Examples (on a Router)2-15
Static IP Address Assignment Configuration Example 2-15
Dynamic IP Address Assignment Configuration Example 2-16
Self-Defined Option Configuration Example2-18
i
DHCP Server Configuration Examples (on a Switch)2-18
Static IP Address Assignment Configuration Example 2-18
Dynamic IP Address Assignment Configuration Example 2-19
Self-Defined Option Configuration Example2-21
Troubleshooting DHCP Server Configuration 2-21
3 DHCP Relay Agent Configuration 3-1

Introduction to DHCP Relay Agent 3-1
Application Environment3-1
Fundamentals3-2
DHCP Relay Agent Support for Option 82 3-2
Configuring the DHCP Relay Agent3-3
Enabling DHCP 3-3
Enabling the DHCP Relay Agent on an Interface 3-4
Correlating a DHCP Server Group with a Relay Agent Interface3-4
Configuring the DHCP Relay Agent to Send a DHCP-Release Request 3-5
Configuring the DHCP Relay Agent Security Functions 3-5
Configuring the DHCP Relay Agent to Support Option 823-8
Displaying and Maintaining DHCP Relay Agent Configuration3-10
DHCP Relay Agent Configuration Examples (on a Router)3-10
DHCP Relay Agent Configuration Example 3-10
DHCP Relay Agent Option 82 Support Configuration Example3-11
DHCP Relay Agent Configuration Examples (on a Switch)3-12
DHCP Relay Agent Configuration Example 3-12
DHCP Relay Agent Option 82 Support Configuration Example3-13
Troubleshooting DHCP Relay Agent Configuration3-14
4 DHCP Client Configuration4-1

Introduction to DHCP Client4-1
Enabling the DHCP Client on an Interface 4-1
Displaying and Maintaining the DHCP Client 4-2
DHCP Client Configuration Example (on a Router)4-2
DHCP Client Configuration Example (on a Switch) 4-3
5 DHCP Snooping Configuration 5-1

DHCP Snooping Overview5-1
Function of DHCP Snooping 5-1
Application Environment of Trusted Ports 5-2
DHCP Snooping Support for Option 825-3
Configuring DHCP Snooping Basic Functions5-4
Configuring DHCP Snooping to Support Option 825-5
Prerequisites5-5
Configuring DHCP Snooping to Support Option 82 5-5
Displaying and Maintaining DHCP Snooping 5-6
DHCP Snooping Configuration Examples 5-7
DHCP Snooping Configuration Example5-7
DHCP Snooping Option 82 Support Configuration Example 5-7
6 BOOTP Client Configuration 6-1

Introduction to BOOTP Client 6-1
ii
BOOTP Application 6-1
Obtaining an IP Address Dynamically 6-2
Configuring an Interface to Dynamically Obtain an IP Address Through BOOTP6-2
Displaying and Maintaining BOOTP Client Configuration6-3
BOOTP Client Configuration Example (on a Router) 6-3
BOOTP Client Configuration Example (on a Switch)6-3
iii

Authorized ARP
support on DHCP Yes Yes Yes Yes
server
DHCP relay
agent security Yes Yes Yes Yes
functions
Authorized ARP
support on DHCP Yes Yes Yes Yes
relay agent
DHCP snooping
No No Yes Yes
Option 82 support
z On an MSR series router, DHCP-snooping is supported on FIC-16FSW, FIC-24FSW, MIM-16FSW,
and MIM-24FSW interface cards only.
This document is organized as follows:

z DHCP Overview
z DHCP Server Configuration
z DHCP Relay Agent Configuration
z DHCP Client Configuration
z DHCP Snooping Configuration
z BOOTP Client Configuration
1 DHCP Overview
Introduction to DHCP
The fast expansion and growing complexity of networks result in scarce IP addresses assignable to
hosts. Meanwhile, as many people need to take their laptops across networks, the IP addresses need
to be changed accordingly. Therefore, related configurations on hosts become more complex. The
Dynamic Host Configuration Protocol (DHCP) was introduced to solve these problems.
DHCP is built on a client-server model, in which a client sends a configuration request and then the
server returns a reply to send configuration parameters such as an IP address to the client.
1-1
A typical DHCP application, as shown in Figure 1-1, includes a DHCP server and multiple clients (PCs
and laptops).
Figure 1-1 A typical DHCP application
A DHCP client can get an IP address and other configuration parameters from the server on another
subnet via a DHCP relay agent. For information about the DHCP relay agent, refer to Introduction to
DHCP Relay Agent.
DHCP Address Allocation

Allocation Mechanisms
DHCP supports three mechanisms for IP address allocation.

z Manual allocation: The network administrator assigns an IP address to a client like a WWW server,
and DHCP conveys the assigned address to the client.
z Automatic allocation: DHCP assigns a permanent IP address to a client.
z Dynamic allocation: DHCP assigns an IP address to a client for a limited period of time, which is
called a lease. Most clients obtain their addresses in this way.
1-2
Dynamic IP Address Allocation Process
Figure 1-2 Dynamic IP address allocation process
As shown in Figure 1-2, a DHCP client obtains an IP address from a DHCP server via four steps:
1) The client broadcasts a DHCP-DISCOVER message to locate a DHCP server.
2) A DHCP server offers configuration parameters such as an IP address to the client in a
DHCP-OFFER message. The sending mode of the DHCP-OFFER is determined by the flag field in
the DHCP-DISCOVER message. Refer to DHCP Message Format for related information.
3) If several DHCP servers send offers to the client, the client accepts the first received offer, and
broadcasts it in a DHCP-REQUEST message to formally request the IP address.
4) All DHCP servers receive the DHCP-REQUEST message, but only the server from which the client
accepts the offered IP address returns a DHCP-ACK message to the client, confirming that the IP
address has been allocated to the client, or returns a DHCP-NAK unicast message, denying the IP
address allocation.
z After the client receives the DHCP-ACK message, it will probe whether the IP address assigned by
the server is in use by broadcasting a gratuitous ARP packet. If the client receives no response
within the specified time, the client can use this IP address. Otherwise, the client sends a
DHCP-DECLINE message to the server and request an IP address again.
z If there are multiple DHCP servers, the IP addresses that are offered by the DHCP servers but not
selected by the client are still assignable to other clients.
IP Address Lease Extension
The IP address dynamically allocated by a DHCP server to a client has a lease. When the lease elapses,
the IP address will be reclaimed by the DHCP server. If the client wants to use the IP address longer, it
has to extend the lease duration.
When the half lease duration elapses, the DHCP client sends to the DHCP server a DHCP-REQUEST
unicast to extend the lease duration. Upon availability of the IP address, the DHCP server returns a
DHCP-ACK unicast confirming that the clients lease duration has been extended, or a DHCP-NAK
unicast denying the request.
1-3
If the client receives no reply, it will broadcast another DHCP-REQUEST message for lease extension
after 7/8 lease duration elapses. The DHCP server will handle the request as above mentioned.
DHCP Message Format

Figure 1-3 gives the DHCP message format, which is based on the BOOTP message format and
involves eight types. These types of messages have the same format except that some fields have
different values. The numbers in parentheses indicate the size of each field in bytes.
Figure 1-3 DHCP message format
z op: Message type defined in option field. 1 = REQUEST, 2 = REPLY

z htype, hlen: Hardware address type and length of a DHCP client.
z hops: The number of relay agents a request message traveled.
z xid: Transaction ID, a random number chosen by the client to identify an IP address allocation.
z secs: Filled in by the client, the number of seconds elapsed since the client began address
acquisition or renewal process. Currently this field is reserved and set to 0.
z flags: The leftmost bit is defined as the BROADCAST (B) flag. If this flag is set to 0, the DHCP
server sent a reply back by unicast; if this flag is set to 1, the DHCP server sent a reply back by
broadcast. The remaining bits of the flags field are reserved for future use.
z ciaddr: Client IP address.
z yiaddr: 'your' (client) IP address, assigned by the server.
z siaddr: Server IP address, from which the clients obtained configuration parameters.
z giaddr: IP address of the first relay agent a request message traveled.
z chaddr: Client hardware address.
z sname: The server host name, from which the client obtained configuration parameters.
z file: Bootfile name and path information, defined by the server to the client.
z options: Optional parameters field that is variable in length, which includes the message type,
lease, domain name server IP address, and WINS IP address.
DHCP Options
DHCP Options Overview
The DHCP message adopts the same format as the Bootstrap Protocol (BOOTP) message for
compatibility, but differs from it in the option field, which identifies new features for DHCP.
1-4
DHCP uses the option field in DHCP messages to carry control information and network configuration
parameters, implementing dynamic address allocation and providing more network configuration
information for clients.
Figure 1-4 shows the DHCP option format.
Figure 1-4 DHCP option format
Introduction to DHCP Options
The common DHCP options are:

z Option 6: DNS server option. It specifies the DNS server IP address to be assigned to the client.
z Option 51: IP address lease option.
z Option 53: DHCP message type option. It identifies the type of the DHCP message.
z Option 55: Parameter request list option. It is used by a DHCP client to request specified
configuration parameters. The option contains values that correspond to the parameters requested
by the client.
z Option 66: TFTP server name option. It specifies a TFTP server to be assigned to the client.
z Option 67: Bootfile name option. It specifies the bootfile name to be assigned to the client.
z Option 150: TFTP server IP address option. It specifies the TFTP server IP address to be assigned
to the client.
For more information about DHCP options, refer to RFC 2132.
Self-Defined Options
Some options, such as Option 43, have no unified definitions in RFC 2132. The formats of some
self-defined options are introduced as follows.
Vendor-specific option (Option 43)
DHCP servers and clients exchange vendor-specific information through messages containing the
vendor-specific option (Option 43). Upon receiving a DHCP message requesting Option 43 (in Option
55), the DHCP server returns a response message containing Option 43 to assign vendor-specific
information to the DHCP client.
The DHCP client can obtain the preboot executive environment (PXE) server address through Option
43, to further obtain the bootfile or other control information from the PXE server.
Figure 1-5 shows the format of Option 43.
1-5
Figure 1-5 Format of Option 43
0 7 15 23 31
Option type (0x2B) Option length Sub-option type (0x80) Sub-option length
PXE server list (variable)
...
For scalability sake, the PXE server address is configured as a sub-option of Option 43 so that the
DHCP client can obtain more information through Option 43. The value of the sub-option type is 0x80.
Figure 1-6 shows the format of the PXE server address list. Currently, the value of the PXE server type
can only be 0.
Figure 1-6 Format of PXE server address list
Relay agent option (Option 82)
Option 82 is the relay agent option in the option field of the DHCP message. It records the location
information of the DHCP client. When a DHCP relay agent or DHCP snooping device receives a clients
request, it adds Option 82 to the request message and sends it to the server.
The administrator can locate the DHCP client to further implement security control and accounting. The
Option 82 supporting server can also use such information to define individual assignment policies of IP
address and other parameters for the clients.
Option 82 involves at most 255 sub-options. At least one sub-option must be defined. Now the DHCP
relay agent supports two sub-options: sub-option 1 (Circuit ID) and sub-option 2 (Remote ID).
Option 82 has no unified definition. Its padding formats vary with vendors.
You can use the following two methods to configure Option 82:
z User-defined method: Manually specify the content of Option 82.
z Non-user-defined method: Pad Option 82 in the default normal or verbose format.
If you choose the second method, you can specify the code type for the sub-options as ASCII or HEX.
1) Normal padding format
The padding contents for sub-options in the normal padding format are:
z sub-option 1: Padded with the VLAN ID and interface number of the interface that received the
clients request. The following figure gives its format. The value of the sub-option type is 1, and that
of the circuit ID type is 0.
1-6
Figure 1-7 Sub-option 1 in normal padding format
z sub-option 2: Padded with the MAC address of the DHCP relay agent interface or the MAC address
of the DHCP snooping device that received the clients request. The following figure gives its
format. The value of the sub-option type is 2, and that of the remote ID type is 0.
Figure 1-8 Sub-option 2 in normal padding format
2) Verbose padding format:

The padding contents for sub-options in the verbose padding format are:
z sub-option 1: Padded with the user-specified access node identifier (ID of the device that adds
Option 82 in DHCP messages), and type, number, and VLAN ID of the interface that received the
clients request. Its format is shown in Figure 1-9.
Figure 1-9 Sub-option 1 in verbose padding format
In Figure 1-9, except that the VLAN ID field has a fixed length of 2 bytes, all the other padding contents
of sub-option 1 are length variable.
z sub-option 2: Padded with the MAC address of the DHCP relay agent interface or the MAC address
of the DHCP snooping device that received the clients request. It has the same format as that in
normal padding format, as shown in Figure 1-8.
Option 184
Option 184 is a reserved option, and parameters in the option can be defined as needed. The device
supports Option 184 carrying the voice related parameters, so a DHCP client with voice functions can
get an IP address along with specified voice parameters from the DHCP server.
Option 184 involves the following sub-options:
1-7
z Sub-option 1: IP address of the primary network calling processor, which is a server serving as the
network calling control source and providing program downloads.
z Sub-option 2: IP address of the backup network calling processor that DHCP clients will contact
when the primary one is unreachable.
z Sub-option 3: Voice VLAN ID and the result whether DHCP clients take this ID as the voice VLAN
or not.
z Sub-option 4: Failover route that specifies the destination IP address and the called number (SIP
users use such IP addresses and numbers to communicate with each other) that a SIP user uses
to reach another SIP user when both the primary and backup calling processors are unreachable.
You must define the sub-option 1 to make other sub-options take effect.

z RFC2131: Dynamic Host Configuration Protocol
z RFC2132: DHCP Options and BOOTP Vendor Extensions
z RFC1542: Clarifications and Extensions for the Bootstrap Protocol
z RFC 3046: DHCP Relay Agent Information Option
1-8
2 DHCP Server Configuration
When configuring the DHCP server, go to these sections for information you are interested in:
z Introduction to DHCP Server
z DHCP Server Configuration Task List
z Enabling DHCP
z Enabling the DHCP Server on an Interface
z Configuring an Address Pool for the DHCP Server
z Configuring the DHCP Server Security Functions
z Configuring the Handling Mode for Option 82
z Displaying and Maintaining the DHCP Server
z DHCP Server Configuration Examples (on a Router)
z DHCP Server Configuration Examples (on a Switch)
z Troubleshooting DHCP Server Configuration
z The DHCP server configuration is supported only on Layer 3 Ethernet interfaces (or subinterfaces),
virtual Ethernet interfaces, VLAN interfaces, Layer 3 aggregate interfaces, serial interfaces,
MP-group interfaces, and loopback interfaces. The secondary IP address pool configuration is not
supported on serial, MP-group or loopback interfaces.
z DHCP snooping must be disabled on the DHCP server.
Introduction to DHCP Server

Application Environment
The DHCP server is well suited to the network where:

z It is hard to implement manual configuration and centralized management.
z The hosts are more than the assignable IP addresses and it is impossible to assign a fixed IP
address to each host. For example, an ISP limits the number of hosts to access the Internet at a
time, so lots of hosts need to acquire IP addresses dynamically.
z A few hosts need fixed IP addresses.
DHCP Address Pool
Address pool structure
In response to a clients request, the DHCP server selects an idle IP address from an address pool and
sends it together with other parameters such as lease and DNS server address to the client.
2-1
The address pool database is organized as a tree. The root of the tree is the address pool for natural
networks, branches are address pools for subnets, and leaves are addresses statically bound to clients.
For the same level address pools, a previously configured pool has a higher selection priority than a
new one.
At the very beginning, subnetworks inherit network parameters and clients inherit subnetwork
parameters. Therefore, common parameters, for example a DNS server address, should be configured
at the highest (network or subnetwork) level of the tree.
After establishment of the inheritance relationship, the new configuration at the higher level (father) of
the tree will be:
z Inherited if the lower level (child) has no such configuration, or
z Overridden if the lower level (child) has such configuration.
The IP address lease does not enjoy the inheritance attribute.
Principles for selecting an address pool
The DHCP server observes the following principles to select an address pool when assigning an IP
address to a client:
1) If there is an address pool where an IP address is statically bound to the MAC address or ID of the
client, the DHCP server will select this address pool and assign the statically bound IP address to
the client. For the configuration of this address pool, refer to section Configuring manual address
allocation.
2) Otherwise, the DHCP server will select the smallest address pool that contains the IP address of
the receiving interface (if the client and the server reside in the same network segment), or the
smallest address pool that contains the IP address specified in the giaddr field of the clients
request (if a DHCP relay agent is in-between). If no IP address is available in the address pool, the
DHCP server will fail to assign an address to the client because it cannot assign an IP address from
the father address pool to the client. For the configuration of such address pool, refer to section
Configuring dynamic address allocation.
For example, two address pools are configured on the DHCP server, 1.1.1.0/24 and 1.1.1.0/25. If the IP
address of the interface receiving DHCP requests is 1.1.1.1/25, the DHCP server will select IP
addresses for clients from address pool 1.1.1.0/25. If no IP address is available in the address pool, the
DHCP server will fail to assign addresses to clients. If the IP address of the interface receiving DHCP
requests is 1.1.1.130/25, the DHCP server will select IP addresses for clients from the 1.1.1.0/24
address pool.
Keep the IP addresses for dynamic allocation within the subnet where the interface of the DHCP server
or DHCP relay agent resides to avoid wrong IP address allocation.
2-2
IP Address Allocation Sequence
A DHCP server assigns an IP address to a client according to the following sequence:

1) The IP address manually bound to the clients MAC address or ID
2) The IP address that was ever assigned to the client
3) The IP address designated by the Option 50 field in a DHCP-DISCOVER message
4) The first assignable IP address found in a proper DHCP address pool
5) The IP address that was a conflict or passed its lease duration
If no IP address is assignable, the server will not respond.
DHCP Server Configuration Task List

Complete the following tasks to configure the DHCP server:
Task Remarks
Enabling DHCP Required
Enabling the DHCP Server on an Interface Optional
Configuring an Address Pool for the DHCP Server Required

Configuring the DHCP Server Security Functions Optional
Configuring the Handling Mode for Option 82 Optional
Enabling DHCP
Enable DHCP before performing other configurations.
Follow these steps to enable DHCP:

Required
Enable DHCP dhcp enable
Enabling the DHCP Server on an Interface

With the DHCP server enabled on an interface, upon receiving a clients request, the DHCP server will
assign an IP address from its address pool to the DHCP client.
Follow these steps to enable the DHCP server on an interface:

interface-number
Enable the DHCP server on an dhcp select server Optional

interface global-pool [ subaddress ] Enabled by default.
2-3
If a DHCP relay agent exists between the DHCP server and client, the DHCP server, regardless of
whether the subaddress keyword is used, will select an IP address from the address pool containing
the primary IP address of the DHCP relay agents interface (connected to the client).
When the DHCP server and client are on the same subnet:
z With the keyword subaddress specified, the DHCP server will assign an IP address from the
address pool containing the secondary IP address of the servers interface (connected to the client);
if the interface has multiple secondary IP addresses, the address pool containing the first
assignable secondary IP address is selected. If the interface has no secondary IP addresses, the
server is unable to assign an IP address to the client.
z Without the keyword subaddress specified, the DHCP server will assign an IP address from the
address pool containing the primary IP address of the servers interface (connected to the client).
Configuring an Address Pool for the DHCP Server

Complete the following tasks to configure an address pool:
Task Remarks
Creating a DHCP Address Pool Required
Configuring an Address Configuring manual address allocation Required to configure

Allocation Mode Configuring dynamic address allocation either of the two
Configuring a Domain Name Suffix for the Client

Configuring DNS Servers for the Client
Configuring WINS Servers and NetBIOS Node Type for the Client
Configuring the BIMS Server Information for the Client
Optional
Configuring Gateways for the Client
Configuring Option 184 Parameters for the Client with Voice Service
Configuring the TFTP Server and Bootfile Name for the Client
Configuring Self-Defined DHCP Options
Creating a DHCP Address Pool
Follow these steps to create a DHCP address pool:
Create a DHCP address dhcp server ip-pool Required

pool and enter its view pool-name No DHCP address pool is created by default.
2-4
Configuring an Address Allocation Mode
You can configure either the static binding or dynamic address allocation for an address pool as
needed.
It is required to specify an address range for the dynamic address allocation. A static binding is a special
address pool containing only one IP address.
Configuring manual address allocation
Some DHCP clients such as a WWW server need fixed IP addresses. You can create a static binding of
a clients MAC or ID to IP address in the DHCP address pool.
When the client with the MAC address or ID requests an IP address, the DHCP server will find the IP
address from the binding for the client.
A DHCP address pool now supports only one static binding, which can be a MAC-to-IP or ID-to-IP
binding.
Follow these steps to configure the static binding in a DHCP address pool:

dhcp server ip-pool
Enter DHCP address pool view
pool-name
static-bind ip-address Required

Bind IP addresses statically ip-address [ mask-length | No IP addresses are
mask mask ] statically bound by default.
Specify the MAC static-bind mac-address Required to configure either
Bind MAC address mac-address of the two
addresses or
IDs statically static-bind client-identifier Neither is bound statically by
Specify the ID default.
client-identifier
2-5
z Use the static-bind ip-address command together with static-bind mac-address or static-bind
client-identifier command to accomplish a static binding configuration.
z In a DHCP address pool, if you execute the static-bind mac-address command before the
static-bind client-identifier command, the latter will overwrite the former and vice versa.
z If you use the static-bind ip-address, static-bind mac-address, or static-bind client-identifier
command repeatedly in the DHCP address pool, the new configuration will overwrite the previous
one.
z The IP address of the static binding cannot be an interface address of the DHCP server. Otherwise,
an IP address conflict may occur and the bound client cannot obtain an IP address correctly.
z The ID of the static binding must be identical to the ID displayed by using the display dhcp client
verbose command on the client. Otherwise, the client cannot obtain an IP address.
Configuring dynamic address allocation
You need to specify one and only one address range using a mask for the dynamic address allocation.
To avoid address conflicts, the DHCP server excludes IP addresses used by the gateway or FTP server
from dynamic allocation.
You can specify the lease duration for a DHCP address pool different from others, and a DHCP address
pool can only have the same lease duration. A lease does not enjoy the inheritance attribute.
Follow these steps to configure the dynamic address allocation:

Enter DHCP address dhcp server ip-pool

pool view pool-name
Required
Specify an IP address network network-address
range [ mask-length | mask mask ] Not specified by default, meaning no
assignable address.
expired { day day [ hour hour Optional
Specify the address
[ minute minute ] ] |
lease duration One day by default.
unlimited }
Optional
dhcp server forbidden-ip Except IP addresses of the DHCP
Exclude IP addresses
low-ip-address server interfaces, all addresses in the
from automatic allocation
[ high-ip-address ] DHCP address pool are assignable by
default.
2-6
z In DHCP address pool view, using the network command repeatedly overwrites the previous
configuration.
z Using the dhcp server forbidden-ip command repeatedly can exclude multiple IP address ranges
from allocation.
Configuring a Domain Name Suffix for the Client
You can specify a domain name suffix in each DHCP address pool on the DHCP server to provide the
clients with the domain name suffix. With this suffix assigned, the client only needs to input part of a
domain name, and the system will add the domain name suffix for name resolution. For details about
DNS, refer to DNS Configuration in the IP Services Volume.
Follow these steps to configure a domain name suffix in the DHCP address pool:

Enter the DHCP address pool dhcp server ip-pool

view pool-name
Specify a domain name suffix Required

domain-name domain-name
for the client Not specified by default.
Configuring DNS Servers for the Client
When a DHCP client wants to access a host on the Internet via the host name, it contacts a Domain
Name System (DNS) server holding host name-to-IP address mappings to get the host IP address. You
can specify up to eight DNS servers in the DHCP address pool.
Follow these steps to configure DNS servers in the DHCP address pool:

dhcp server ip-pool
pool-name
Specify DNS servers for the Required

dns-list ip-address&<1-8>
client Not specified by default.
Configuring WINS Servers and NetBIOS Node Type for the Client
A Microsoft DHCP client using NetBIOS protocol contacts a Windows Internet Naming Service (WINS)
server for name resolution. Therefore, the DHCP server should assign a WINS server address when
assigning an IP address to the client.
You can specify up to eight WINS servers in a DHCP address pool.
2-7
You need to specify in a DHCP address pool a NetBIOS node type for the client to approach name
resolution. There are four NetBIOS node types:
z b (broadcast)-node: The b-node client sends the destination name in a broadcast message. The
destination returns its IP address to the client after receiving the message.
z p (peer-to-peer)-node: The p-node client sends the destination name in a unicast message to the
WINS server, and the WINS server returns the destination IP address.
z m (mixed)-node: A combination of broadcast first and peer-to-peer second. The m-node client
broadcasts the destination name, if no response is received, then unicasts the destination name to
the WINS server to get the destination IP address.
z h (hybrid)-node: A combination of peer-to-peer first and broadcast second. The h-node client
unicasts the destination name to the WINS server, if no response is received, then broadcasts it to
get the destination IP address.
Follow these steps to configure WINS servers and NetBIOS node type in the DHCP address pool:

dhcp server ip-pool

pool-name
Required (optional for b-node)
Specify WINS server IP
nbns-list ip-address&<1-8> No address is specified by
addresses for the client
default.
netbios-type { b-node | Required

Specify the NetBIOS node type
h-node | m-node | p-node } Not specified by default.
If b-node is specified for the client, you need to specify no WINS server address.
Configuring the BIMS Server Information for the Client
A DHCP client performs regular software update and backup using configuration files obtained from a
branch intelligent management system (BIMS) server. Therefore, the DHCP server needs to offer
DHCP clients the BIMS server IP address, port number, shared key from the DHCP address pool.
Follow these steps to configure the BIMS server IP address, port number, and shared key in the DHCP
address pool:

dhcp server ip-pool
pool-name
Specify the BIMS server IP bims-server ip ip-address Required
address, port number, and [ port port-number ] sharekey
shared key key Not specified by default.
2-8
Configuring Gateways for the Client
DHCP clients that want to access hosts outside the local subnet request gateways to forward data. You
can specify gateways in each address pool for clients and the DHCP server will assign gateway
addresses while assigning an IP address to the client. Up to eight gateways can be specified in a DHCP
address pool.
Follow these steps to configure the gateways in the DHCP address pool:

dhcp server ip-pool
pool-name
gateway-list Required
Specify gateways
ip-address&<1-8> No gateway is specified by default.
Configuring Option 184 Parameters for the Client with Voice Service
To assign voice calling parameters along with an IP address to DHCP clients with voice service, you
need to configure Option 184 on the DHCP server. For information about Option 184, refer to Option
184.
If Option 55 in the request from a DHCP client contains Option 184, the DHCP server will return
parameters specified in Option 184 to the client. The client then can initiate a call using parameters in
Option 184.
Follow these steps to configure option 184 parameters in the DHCP address pool:

dhcp server ip-pool
pool-name
Specify the IP address of the voice-config ncp-ip Required

primary network calling processor ip-address Not specified by default.
Specify the IP address of the voice-config as-ip Optional

backup network calling processor ip-address Not specified by default.
voice-config voice-vlan Optional

Configure the voice VLAN
vlan-id { disable | enable } Not configured by default.
Optional
Specify the failover IP address and voice-config fail-over
dialer string ip-address dialer-string No failover IP address or dialer
string is specified by default.
Specify an IP address for the network calling processor before performing other configuration.
2-9
Configuring the TFTP Server and Bootfile Name for the Client
This task is to specify the IP address and name of a TFTP server and the bootfile name in the DHCP
address pool. The DHCP clients use these parameters to contact the TFTP server, requesting the
configuration file used for system initialization, which is called auto-configuration. The request process
of the client is described below:
1) When a router starts up without loading any configuration file, the system sets an active interface
(such as the interface of the default VLAN or a Layer 3 Ethernet interface) as the DHCP client to
request from the DHCP server for parameters, such as an IP address and name of a TFTP server,
and the bootfile name.
2) After getting related parameters, the DHCP client will send a TFTP request to obtain the
configuration file from the specified TFTP server for system initialization. If the client cannot get
such parameters, it will perform system initialization without loading any configuration file.
To implement auto-configuration, you need to specify the IP address or name of a TFTP server and the
bootfile name in the DHCP address pool on the DHCP server, but you do not need to perform any
configuration on the DHCP client.
When Option 55 in the clients request contains parameters of Option 66, Option 67, or Option 150, the
DHCP server will return the IP address or name of the specified TFTP server, and bootfile name to the
client.
Follow these steps to configure the IP address and name of the TFTP server and the bootfile name in
the DHCP address pool:

dhcp server ip-pool
pool-name
tftp-server ip-address Optional

Specify the TFTP server
ip-address Not specified by default.
Specify the name of the TFTP tftp-server domain-name Optional

server domain-name Not specified by default.
Optional
Specify the bootfile name bootfile-name bootfile-name
Not specified by default.
Configuring Self-Defined DHCP Options
By configuring self-defined DHCP options, you can

z Define new DHCP options. New configuration options will come out with DHCP development. To
support these new options, you can add them into the attribute list of the DHCP server.
z Define existing DHCP options. Some options have no unified definitions in RFC 2132; however,
vendors can define such options as Option 43 as needed. The self-defined DHCP option enables
DHCP clients to obtain vendor-specific information.
z Extend existing DHCP options. When the current DHCP options cannot meet the customers
requirements (for example, you cannot use the dns-list command to configure more than eight
DNS server addresses), you can configure a self-defined option for extension.
Follow these steps to configure a self-defined DHCP option in the DHCP address pool:
2-10
dhcp server ip-pool
pool-name
option code { ascii ascii-string Required

Configure a self-defined DHCP
| hex hex-string&<1-16> | No DHCP option is configured
option
ip-address ip-address&<1-8> } by default.
Table 2-1 Description of common options
Corresponding
Option Option name Command parameter
command
3 Router Option gateway-list ip-address
6 Domain Name Server Option dns-list ip-address
15 Domain Name domain-name ascii
NetBIOS over TCP/IP Name
44 nbns-list ip-address
Server Option
NetBIOS over TCP/IP Node
46 netbios-type hex
Type Option
66 TFTP server name tftp-server ascii
67 Bootfile name bootfile-name ascii
43 Vendor Specific Information hex
Be cautious when configuring self-defined DHCP options because such configuration may affect the
DHCP operation process.
Configuring the DHCP Server Security Functions

This configuration is necessary to secure DHCP services on the DHCP server.
Before performing this configuration, complete the following configurations on the DHCP server:
z Enable DHCP
z Configure the DHCP address pool
Enabling Unauthorized DHCP Server Detection
Unauthorized DHCP servers may exist on networks, and they reply DHCP clients with wrong IP
addresses.
With this feature enabled, upon receiving a DHCP request, the DHCP server will record the IP address
2-11
of the DHCP server which assigned an IP address to the DHCP client and the receiving interface. The
administrator can use this information to check out any unauthorized DHCP servers.
Follow these steps to enable unauthorized DHCP server detection:

Enable unauthorized DHCP Required

dhcp server detect
server detection Disabled by default.
With the unauthorized DHCP server detection enabled, the device puts a record once for each DHCP
server. The administrator needs to find unauthorized DHCP servers from the log information.
Configuring IP Address Conflict Detection
To avoid IP address conflicts, the DHCP server checks whether the address to be assigned is in use by
sending ping packets.
The DHCP server pings the IP address to be assigned using ICMP. If the server gets a response within
the specified period, the server will select and ping another IP address; otherwise, the server will ping
the IP addresses once again until the specified number of ping packets are sent. If still no response is
received, the server will assign the IP address to the requesting client (The DHCP client probes the IP
address by sending gratuitous ARP packets).
Follow these steps to configure IP address conflict detection:

Optional
Specify the number of dhcp server ping packets One ping packet by default.
ping packets number The value 0 indicates that no ping
operation is performed.
Optional
Configure a timeout
dhcp server ping timeout 500 ms by default.
waiting for ping
milliseconds The value 0 indicates that no ping
responses
operation is performed.
Configuring the DHCP Server to Support Authorized ARP
2-12
A DHCP server can work in cooperation with authorized ARP to block illegal clients, avoid learning
incorrect ARP entries and guard against attacks such as MAC address spoofing. Only the clients that
have valid leases on the DHCP server are considered legal clients.
When authorized ARP is enabled, the ARP automatic learning function is disabled. ARP entries can be
added by the DHCP server which notifies authorized ARP to add/delete/change authorized ARP entries
when adding/deleting/changing IP address leases. Thus, only the clients that have obtained IP
addresses from the DHCP server can access the network normally, while other clients are considered
illegal clients and are unable to access the network.
Follow these steps to configure the DHCP server to support authorized ARP:

interface-number
Configure the DHCP server to Required

dhcp update arp
support authorized ARP Not supported by default.
z Authorized ARP can only be configured on Layer 3 interfaces.

z When the working mode of the interface is changed from DHCP server to DHCP relay agent,
neither the IP address leases nor the authorized ARP entries will be deleted. However, these ARP
entries may conflict with new ARP entries generated on the DHCP relay agent; therefore, you are
recommended to delete the existing IP address leases when changing the interface working mode
to DHCP relay agent.
z Disabling the DHCP server to support authorized ARP will not delete the IP address leases, but will
delete the corresponding authorized ARP entries.
z For more information about authorized ARP, refer to ARP Configuration in the IP Services Volume.
Configuring the Handling Mode for Option 82

When the DHCP server receives a message with Option 82, if the server is configured to handle Option
82, it will return a response message carrying Option 82 to assign an IP address to the requesting client.
If the server is configured to ignore Option 82, it will assign an IP address to the client without adding
Option 82 in the response message.
Before performing this configuration, complete the following configuration on the DHCP server:
z Enable DHCP
z Configure the DHCP address pool
Configuring the handling mode for Option 82
Follow these steps to enable the DHCP server to handle Option 82:
2-13
Enable the server to handle dhcp server relay Optional

Option 82 information enable Enabled by default.
To support Option 82, it is required to perform configuration on both the DHCP server and relay agent
(or the device enabled with DHCP snooping). Refer to Configuring the DHCP Relay Agent to Support
Option 82 and Configuring DHCP Snooping to Support Option 82 for related configuration details.
Displaying and Maintaining the DHCP Server

Display information about IP address display dhcp server conflict { all | ip
conflicts ip-address }
Display information about lease display dhcp server expired { all | ip
expiration ip-address | pool [ pool-name ] }
Display information about assignable IP
display dhcp server free-ip
addresses
Display IP addresses excluded from
Available in
automatic allocation in the DHCP display dhcp server forbidden-ip
any view
address pool
display dhcp server ip-in-use { all |
Display information about bindings
ip ip-address | pool [ pool-name ] }
Display information about DHCP server
display dhcp server statistics
statistics
Display tree organization information of display dhcp server tree { all | pool
address pool(s) [ pool-name ] }
Clear information about IP address reset dhcp server conflict { all | ip
conflicts ip-address }
Clear information about dynamic reset dhcp server ip-in-use { all | ip Available in
bindings ip-address | pool [ pool-name ] } user view
Clear information about DHCP server

reset dhcp server statistics
statistics
2-14
Using the save command does not save DHCP server lease information. Therefore, when the system
boots up or the reset dhcp server ip-in-use command is executed, no lease information will be
available in the configuration file. In this case, the server will deny the request for lease extension from
a client and the client needs to request an IP address again.
DHCP Server Configuration Examples (on a Router)

DHCP networking involves two types:
z The DHCP server and client are on the same subnet and perform direct message delivery.
z The DHCP server and client are not on the same subnet and communicate with each other via a
DHCP relay agent.
The DHCP server configuration for the two types is the same.
Static IP Address Assignment Configuration Example
Router B (DHCP client) obtains a static IP address, DNS server address, and gateway address from
Router A (DHCP server).
Network diagram
Figure 2-1 Network diagram for static IP address assignment
1) Configure the IP address of Ethernet 1/1 on Router A.

# Enable DHCP.
2-15
# Create DHCP address pool 0, configure a static IP-MAC binding, DNS server and gateway in it.
[RouterA-dhcp-pool-0] static-bind ip-address 10.1.1.5
[RouterA-dhcp-pool-0] static-bind mac-address 000f-e200-0002
[RouterA-dhcp-pool-0] dns-list 10.1.1.2
Dynamic IP Address Assignment Configuration Example
z The DHCP server (Router A) assigns IP address to clients on subnet 10.1.1.0/24, which is
subnetted into 10.1.1.0/25 and 10.1.1.128/25.
z The IP addresses of Ethernet 1/1 and Ethernet 1/2 on Router A are 10.1.1.1/25 and 10.1.1.129/25
respectively.
z In subnet 10.1.1.0/25, the address lease duration is ten days and twelve hours, domain name suffix
aabbcc.com, DNS server address 10.1.1.2/25, WINS server address 10.1.1.4/25, and gateway
address 10.1.1.126/25.
z In the subnet 10.1.1.128/25, the address lease duration is five days, domain name suffix
aabbcc.com, DNS server address 10.1.1.2/25, and gateway address 10.1.1.254/25 and there is no
WINS server address.
z The domain name suffix and DNS server address on subnets 10.1.1.0/25 and 10.1.1.128/25 are
the same. Therefore, the domain name suffix and DNS server address need to be configured only
for subnet 10.1.1.0/24. Subnet 10.1.1.0/25 and 10.1.1.128/25 can inherit the configuration of
subnet 10.1.1.0/24.
In this example, the number of requesting clients connected to Ethernet 1/1 should be less than 122,
and that of clients connected to Ethernet 1/2 less than 124.
2-16
Network diagram
Figure 2-2 DHCP network
Client WINS server Client Client
10.1.1.4/25
Eth1/1 Eth1/2
10.1.1.126/25 10.1.1.1/25 10.1.1.129/25 10.1.1.254/25
Gateway A Router A Gateway B

10.1.1.2/25 DHCP server
Eth1/1
Router B
DNS server Client Client
Client
1) Specify IP addresses for interfaces (omitted)

# Enable DHCP.
# Exclude IP addresses from dynamic allocation (addresses of the DNS server, WINS server, and
gateways).
[RouterA] dhcp server forbidden-ip 10.1.1.2
# Configure DHCP address pool 0 (address range, client domain name suffix and DNS server address).
[RouterA-dhcp-pool-0] domain-name aabbcc.com
[RouterA-dhcp-pool-0] dns-list 10.1.1.2
# Configure DHCP address pool 1 (address range, gateway, WINS server, and lease duration).
[RouterA-dhcp-pool-1] expired day 10 hour 12
[RouterA-dhcp-pool-1] nbns-list 10.1.1.4
# Configure DHCP address pool 2 (address range, gateway and lease duration).
[RouterA-dhcp-pool-2] expired day 5
2-17
Self-Defined Option Configuration Example
z The DHCP client (Router B) obtains the IP address and PXE server addresses from the DHCP
server (Router A).
z The IP address that Router B obtains belongs to the network segment 10.1.1.0/24.
z The PXE server addresses that Router B obtains are 1.2.3.4 and 2.2.2.2.
Network diagram
Figure 2-3 Network diagram for self-defined option configuration (a router as the DHCP server)
Specify IP address for interface Ethernet 1/0 (omitted).

Configure the DHCP server
# Enable DHCP.
# Configure DHCP address pool 0.

[RouterA-dhcp-pool-0] option 43 hex 80 0B 00 00 02 01 02 03 04 02 02 02 02
DHCP Server Configuration Examples (on a Switch)

DHCP networking involves two types:
z The DHCP server and client are on the same subnet and exchange messages directly.
z The DHCP server and client are not on the same subnet and they communicate with each other via
a DHCP relay agent.
The DHCP server configuration for the two types is the same.
Static IP Address Assignment Configuration Example
Switch B (DHCP client) obtains a static IP address, DNS server address, and gateway address from
Switch A (DHCP server).
2-18
Network diagram
Figure 2-4 Network diagram for static IP address assignment
Client
Vlan-int2
10.1.1.126/25 10.1.1.1/25
Gateway A Switch A
10.1.1.2/25 DHCP server
Vlan-int2
Switch B
DNS server Client
1) Configure the IP address of VLAN-interface 2 on Switch A.

[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.1 25
[SwitchA-Vlan-interface2] quit
# Enable DHCP.
# Create DHCP address pool 0, configure a static IP-MAC binding, DNS server and gateway in it.
[SwitchA-dhcp-pool-0] static-bind ip-address 10.1.1.5
[SwitchA-dhcp-pool-0] static-bind mac-address 000f-e200-0002
[SwitchA-dhcp-pool-0] dns-list 10.1.1.2
[SwitchA-dhcp-pool-0] gateway-list 10.1.1.126
Dynamic IP Address Assignment Configuration Example
z The DHCP server (Switch A) assigns IP address to clients in subnet 10.1.1.0/24, which is
subnetted into 10.1.1.0/25 and 10.1.1.128/25.
z The IP addresses of VLAN-interfaces 1 and 2 on Switch A are 10.1.1.1/25 and 10.1.1.129/25
respectively.
z In address pool 10.1.1.0/25, the address lease duration is ten days and twelve hours, domain
name suffix aabbcc.com, DNS server address 10.1.1.2/25, gateway 10.1.1.126/25, and WINS
server 10.1.1.4/25.
z In address pool 10.1.1.128/25, the address lease duration is five days, domain name suffix
aabbcc.com, DNS server address 10.1.1.2/25, and gateway address 10.1.1.254/25, and there is
no WINS server address.
2-19
z The domain name and DNS server address on subnets 10.1.1.0/25 and 10.1.1.128/25 are the
same. Therefore, the domain name suffix and DNS server address can be configured only for
subnet 10.1.1.0/24. Subnet 10.1.1.128/25 can inherit the configuration of subnet 10.1.1.0/24.
In this example, the number of requesting clients connected to VLAN-interface 1 should be less than
122, and that of clients connected to VLAN-interface 2 less than 124.
Network diagram
Figure 2-5 DHCP network diagram
Specify IP addresses for VLAN interfaces (omitted).

# Enable DHCP.
# Exclude IP addresses (addresses of the DNS server, WINS server and gateways).
[SwitchA] dhcp server forbidden-ip 10.1.1.2
# Configure DHCP address pool 0 (address range, client domain name suffix, and DNS server
address).
[SwitchA-dhcp-pool-0] domain-name aabbcc.com
[SwitchA-dhcp-pool-0] dns-list 10.1.1.2
# Configure DHCP address pool 1 (address range, gateway, lease duration, and WINS server).
2-20
[SwitchA-dhcp-pool-1] expired day 10 hour 12
[SwitchA-dhcp-pool-1] nbns-list 10.1.1.4
# Configure DHCP address pool 2 (address range, gateway, and lease duration).
[SwitchA-dhcp-pool-2] expired day 5
Self-Defined Option Configuration Example
z The DHCP client (Switch B) obtains an IP address and PXE server addresses from the DHCP
server (Switch A).
z The IP address that Switch B obtains belongs to network segment 10.1.1.0/24.
z The PXE server addresses that Switch B obtains are 1.2.3.4 and 2.2.2.2.
Network diagram
Figure 2-6 Network diagram for self-defined option configuration (a switch as the DHCP server)
Vlan-int2
10.1.1.1/24 Vlan-int2
Switch A Switch B
DHCP server DHCP client
Specify IP addresses for the interfaces (omitted).

# Enable DHCP.
# Configure DHCP address pool 0.

[SwitchA-dhcp-pool-0] option 43 hex 80 0B 00 00 02 01 02 03 04 02 02 02 02
Troubleshooting DHCP Server Configuration

Symptom
A clients IP address obtained from the DHCP server conflicts with another IP address.
2-21
Analysis
A host on the subnet may have the same IP address.
Solution
1) Disconnect the clients network cable and ping the clients IP address on another host with a long
timeout time to check whether there is a host using the same IP address.
2) If a ping response is received, the IP address has been manually configured on the host. Execute
the dhcp server forbidden-ip command on the DHCP server to exclude the IP address from
dynamic allocation.
3) Connect the clients network cable. Release the IP address and obtain another one on the client.
Take WINDOW XP as an example, run cmd to enter DOS window. Type ipconfig/release to
relinquish the IP address and then ipconfig/renew to obtain another IP address.
2-22
3 DHCP Relay Agent Configuration
When configuring the DHCP relay agent, go to these sections for information you are interested in:
z Introduction to DHCP Relay Agent
z Configuring the DHCP Relay Agent
z Displaying and Maintaining DHCP Relay Agent Configuration
z DHCP Relay Agent Configuration Examples (on a Router)
z DHCP Relay Agent Configuration Examples (on a Switch)
z Troubleshooting DHCP Relay Agent Configuration
z The DHCP relay agent configuration is supported only on Layer 3 Ethernet interfaces (or
subinterfaces), virtual Ethernet interfaces, VLAN interfaces, Layer 3 aggregate interfaces, and
serial interfaces.
z DHCP snooping must be disabled on the DHCP relay agent.
Introduction to DHCP Relay Agent

Application Environment
Since DHCP clients request IP addresses via broadcast messages, the DHCP server and clients must
be on the same subnet. Therefore, a DHCP server must be available on each subnet, which is not
practical.
DHCP relay agent solves the problem. Via a relay agent, DHCP clients communicate with a DHCP
server on another subnet to obtain configuration parameters. Thus, DHCP clients on different subnets
can contact the same DHCP server for ease of centralized management and cost reduction.
3-1
Fundamentals
Figure 3-1 shows a typical application of the DHCP relay agent.

Figure 3-1 DHCP relay agent application
DHCP client DHCP client
IP network
DHCP relay agent
DHCP client DHCP client DHCP server
No matter whether a relay agent exists or not, the DHCP server and client interact with each other in a
similar way (see section Dynamic IP Address Allocation Process). The following describes the
forwarding process on the DHCP relay agent.
Figure 3-2 DHCP relay agent work process
As shown in Figure 3-2, the DHCP relay agent works as follows:

1) After receiving a DHCP-DISCOVER or DHCP-REQUEST broadcast message from a DHCP client,
the DHCP relay agent fills the giaddr field of the message with its IP address and forwards the
message to the designated DHCP server in unicast mode.
2) Based on the giaddr field, the DHCP server returns an IP address and other configuration
parameters to the relay agent, which conveys them to the client.
DHCP Relay Agent Support for Option 82
Option 82 records the location information of the DHCP client. The administrator can locate the DHCP
client to further implement security control and accounting. For more information, refer to Relay agent
option (Option 82).
If the DHCP relay agent supports Option 82, it will handle a clients request according to the contents
defined in Option 82, if any. The handling strategies are described in the table below.
3-2
If a reply returned by the DHCP server contains Option 82, the DHCP relay agent will remove the Option
82 before forwarding the reply to the client.
If a clients
Handling Padding
requesting The DHCP relay agent will
strategy format
message has
Drop Random Drop the message.
Forward the message without changing
Keep Random
Option 82.
Forward the message after replacing the
normal original Option 82 with the Option 82
padded in normal format.
Option 82
Replace verbose original Option 82 with the Option 82
padded in verbose format.
user-defined original Option 82 with the user-defined
Option 82.
Forward the message after adding the
normal
Option 82 padded in normal format.
no Option 82 verbose
Option 82 padded in verbose format.

user-defined
user-defined Option 82.

Complete the following tasks to configure the DHCP relay agent:
Task Remarks
Enabling DHCP Required
Enabling the DHCP Relay Agent on an Interface Required

Correlating a DHCP Server Group with a Relay Agent Interface Required
Configuring the DHCP Relay Agent to Send a DHCP-Release Request Optional
Configuring the DHCP Relay Agent Security Functions Optional

Configuring the DHCP Relay Agent to Support Option 82 Optional
Configuring the DHCP Relay Agent

Enabling DHCP
Enable DHCP before performing other DHCP-related configurations.
3-3
Follow these steps to enable DHCP:

Required
Enable DHCP dhcp enable
Enabling the DHCP Relay Agent on an Interface
With this task completed, upon receiving a DHCP request from the enabled interface, the relay agent
will forward the request to a DHCP server for address allocation.
Follow these steps to enable the DHCP relay agent on an interface:

interface-number
Required
Enable the DHCP relay agent
dhcp select relay With DHCP enabled, interfaces
on the current interface
work in the DHCP server mode.
z If you enabled the DHCP relay agent on an Ethernet subinterface, a client connected must also use
a subinterface to guarantee normal communication with the relay agent. In this case, if the client is
a PC, it cannot obtain an IP address.
z If the DHCP client obtains an IP address via the DHCP relay agent, the address pool of the subnet
to which the IP address of the DHCP relay agent belongs must be configured on the DHCP server.
Otherwise, the DHCP client cannot obtain a correct IP address.
Correlating a DHCP Server Group with a Relay Agent Interface
To improve reliability, you can specify several DHCP servers as a group on the DHCP relay agent and
correlate a relay agent interface with the server group. When the interface receives requesting
messages from clients, the relay agent will forward them to all the DHCP servers of the group.
Follow these steps to correlate a DHCP server group with a relay agent interface:

Create a DHCP server group dhcp relay server-group Required

and add a server into the group group-id ip ip-address Not created by default.
interface-number
3-4
Required
Correlate the DHCP server dhcp relay server-select By default, no interface is
group with the current interface group-id correlated with any DHCP
server group.
z You can specify up to twenty DHCP server groups on the relay agent and eight DHCP server
addresses for each DHCP server group.
z The IP addresses of DHCP servers and those of relay agents interfaces cannot be on the same
subnet. Otherwise, the client cannot obtain an IP address.
z A DHCP server group can correlate with one or multiple DHCP relay agent interfaces, while a relay
agent interface can only correlate with one DHCP server group. Using the dhcp relay
server-select command repeatedly overwrites the previous configuration. However, if the
specified DHCP server group does not exist, the interface still uses the previous correlation.
z The group-id in the dhcp relay server-select command was specified by the dhcp relay
server-group command.
Configuring the DHCP Relay Agent to Send a DHCP-Release Request
Sometimes, you need to release a clients IP address manually on the DHCP relay agent. With this task
completed, the DHCP relay agent can actively send a DHCP-RELEASE request that contains the
clients IP address to be released. Upon receiving the DHCP-RELEASE request, the DHCP server then
releases the IP address for the client.
Follow these steps to configure the DHCP relay agent in system view to send a DHCP-RELEASE
request:

Configure the DHCP relay agent to send a

dhcp relay release ip client-ip Required
DHCP-RELEASE request
Configuring the DHCP Relay Agent Security Functions
Security functions supported by the DHCP relay agent vary with devices.
Creating static bindings and enable IP address check
The DHCP relay agent can dynamically record clients IP-to-MAC bindings after clients get IP
addresses. It also supports static bindings, which means you can manually configure IP-to-MAC
3-5
bindings on the DHCP relay agent, so that users can access external network using fixed IP addresses.
For avoidance of invalid IP address configuration, you can configure the DHCP relay agent to check
whether a requesting clients IP and MAC addresses match a binding (both dynamic and static bindings)
on the DHCP relay agent. If not, the client cannot access outside networks via the DHCP relay agent.
Follow these steps to create a static binding and enable IP address check:

dhcp relay security static Optional

Create a static binding ip-address mac-address [ interface No static binding is created by
interface-type interface-number ] default.
interface-number
Enable invalid IP address dhcp relay address-check { disable Required

check | enable } Disabled by default.
z The dhcp relay address-check command can be executed only on Layer 3 Ethernet interfaces
(including sub-interfaces) and VLAN interfaces.
z The dhcp relay address-check enable command is independent of other commands of the
DHCP relay agent. That is, the invalid address check takes effect when this command is executed,
regardless of whether other commands are used.
z The dhcp relay address-check enable command only checks IP and MAC addresses of clients.
z You are recommended to configure IP address check on the interface enabled with the DHCP relay
agent; otherwise, the valid DHCP clients may not be capable of accessing networks.
z When using the dhcp relay security static command to bind an interface to a static binding entry,
make sure that the interface is configured as a DHCP relay agent; otherwise, address entry
conflicts may occur.
z When a synchronous/asynchronous serial interface requests an IP address through DHCP, the
DHCP relay agent does not record the corresponding IP-to-MAC binding.
Configuring dynamic binding update interval
Via the DHCP relay agent, a DHCP client sends a DHCP-RELEASE unicast message to the DHCP
server to relinquish its IP address. In this case the DHCP relay agent simply conveys the message to
the DHCP server, thus it does not remove the IP address from its bindings. To solve this problem, the
DHCP relay agent can update dynamic bindings at a specified interval.
The DHCP relay agent uses the IP address of a client and the MAC address of the DHCP relay interface
to periodically send a DHCP-REQUEST message to the DHCP server.
z If the server returns a DHCP-ACK message or does not return any message within a specified
interval, which means the IP address is assignable now, the DHCP relay agent will update its
bindings by aging out the binding entry of the IP address.
z If the server returns a DHCP-NAK message, which means the IP address is still in use, the relay
agent will not age it out.
3-6
Follow these steps to configure dynamic binding update interval:

Optional
Configure binding dhcp relay security
update interval tracker { interval | auto } auto by default. (auto interval is calculated by the
relay agent according to the number of bindings.)
Configuring the DHCP relay agent to support authorized ARP
A DHCP relay agent can work in cooperation with authorized ARP to block illegal clients, to avoid
learning incorrect ARP entries and to guard against attacks such as MAC address spoofing. Only the
clients whose IP-to-MAC binding are recorded on the DHCP relay agent are considered legal clients.
When authorized ARP is enabled on the DHCP relay agent, the ARP automatic learning function is
disabled. ARP entries can be added by the DHCP relay agent which notifies authorized ARP to
add/delete/change authorized ARP entries when adding/deleting/changing dynamic IP-to-MAC
bindings. Thus, only the clients that have passed the authentication of the DHCP relay agent can
access the network normally, while other clients are considered illegal clients and unable to access the
network.
Follow these steps to configure the DHCP relay agent to support authorized ARP:

interface-number
Configure the DHCP relay agent to Required

dhcp update arp
support authorized ARP Not supported by default.
z Authorized ARP can only be configured on Layer 3 interfaces.

z Disabling the DHCP relay agent to support authorized ARP will not delete dynamic bindings, but
will delete the corresponding authorized ARP entries.
z Since the DHCP relay agent does not notify the authorized ARP module of the static bindings, you
need to configure the corresponding static ARP entries for authorized ARP.
z For more information about authorized ARP, refer to ARP Configuration in the IP Services Volume.
3-7
Enabling unauthorized DHCP servers detection
There are unauthorized DHCP servers on networks, which reply DHCP clients with wrong IP
addresses.
With this feature enabled, upon receiving a DHCP request, the DHCP relay agent will record the IP
address of the DHCP server which assigned an IP address to the DHCP client and the receiving
interface. The administrator can use this information to check out any DHCP unauthorized servers.
Follow these steps to enable unauthorized DHCP server detection:

Enable unauthorized DHCP Required

dhcp relay server-detect
server detection Disabled by default.
With the unauthorized DHCP server detection enabled, the device puts a record once for each DHCP
server. The administrator needs to find unauthorized DHCP servers from the log information. After the
recorded information of a DHCP server is cleared, a new record will be put for the DHCP server.
Configuring the DHCP Relay Agent to Support Option 82
Prerequisites
You need to complete the following tasks before configuring the DHCP relay agent to support Option 82.
z Enabling DHCP
z Enabling the DHCP relay agent on the specified interface
z Correlating a DHCP server group with relay agent interfaces
Configuring the DHCP relay agent to support Option 82
Follow these steps to configure the DHCP relay agent to support Option 82:

interface-number
Enable the relay agent to support dhcp relay information Required

Option 82 enable Disabled by default.
Configure the handling strategy for dhcp relay information Optional
requesting messages containing strategy { drop | keep |
Option 82 replace } replace by default.
3-8
dhcp relay information

format { normal |
Configure the padding verbose [ node-identifier Optional
format for Option 82 { mac | sysname | normal by default.
user-defined
node-identifier } ] }
Optional
By default, the code type
Configure depends on the padding
Configure the code dhcp relay information
non-user-def format of Option 82. Each field
type for the circuit ID circuit-id format-type
ined Option has its own code type.
sub-option { ascii | hex }
82 The code type configuration
applies to non-user-defined
Option 82 only.
Optional
By default, the code type is
Configure the code dhcp relay information
hex.
type for the remote ID remote-id format-type
sub-option { ascii | hex } This code type configuration
Option 82 only.
Optional
Configure the padding
dhcp relay information By default, the padding
content for the circuit
circuit-id string circuit-id content depends on the
ID sub-option
Configure padding format of Option 82.
user-defined
Option 82 Optional
Configure the padding dhcp relay information
content for the remote remote-id string By default, the padding
ID sub-option { remote-id | sysname } content depends on the
padding format of Option 82.
z To support Option 82, it is required to perform related configuration on both the DHCP server and
relay agent. Refer to Configuring the Handling Mode for Option 82 for DHCP server configuration of
this kind.
z If the handling strategy of the DHCP relay agent is configured as replace, you need to configure a
padding format for Option 82. If the handling strategy is keep or drop, you need not configure any
padding format.
z If sub-option 1 (node identifier) of Option 82 is padded with the device name (sysname) of a node,
the device name must contain no spaces. Otherwise, the DHCP relay agent will drop the message.
3-9
Displaying and Maintaining DHCP Relay Agent Configuration
Display information about DHCP
display dhcp relay { all | interface
server groups correlated to a
interface-type interface-number }
specified or all interfaces
Display Option 82 configuration display dhcp relay information { all |
information on the DHCP relay agent interface interface-type interface-number }
Display information about bindings of display dhcp relay security [ ip-address |
DHCP relay agents dynamic | static ]
Display statistics information about
display dhcp relay security statistics Available in
bindings of DHCP relay agents
any view
Display information about the
refreshing interval for entries of display dhcp relay security tracker
dynamic IP-to-MAC bindings
display dhcp relay server-group
configuration of a specified or all
{ group-id | all }
DHCP server groups
Display packet statistics on relay display dhcp relay statistics
agent [ server-group { group-id | all } ]
Clear packet statistics from relay reset dhcp relay statistics Available in
agent [ server-group group-id ] user view
DHCP Relay Agent Configuration Examples (on a Router)

DHCP Relay Agent Configuration Example
Ethernet 1/1 of the DHCP relay agent (Router A) connects to the subnet where DHCP clients reside.
The IP address of Ethernet 1/1 is 10.10.1.1/24, and the IP address of Ethernet 1/2 is 10.1.1.2/24 that
communicates with the DHCP server 10.1.1.1/24. As shown in the figure below, Router A forwards
messages between DHCP clients and the DHCP server.
Network diagram
Figure 3-3 Network diagram for DHCP relay agent (on a router)
Eth1/1 Eth1/2
10.10.1.1/24 10.1.1.2/24
Eth1/0
10.1.1.1/24
Router A Router B
DHCP relay agent DHCP server
3-10
# Enable DHCP.
# Add DHCP server 10.1.1.1 into DHCP server group 1

[RouterA] dhcp relay server-group 1 ip 10.1.1.1
# Enable the DHCP relay agent on Ethernet 1/1.

[RouterA-Ethernet1/1] dhcp select relay

[RouterA-Ethernet1/1] dhcp relay server-select 1
z Performing configuration on the DHCP server is also required to guarantee the client-server
communication via the DHCP relay agent. Refer to DHCP Server Configuration Examples (on a
Router) for DHCP server configuration information.
z If the DHCP relay agent and server are on different subnets, routes in between must be reachable.
DHCP Relay Agent Option 82 Support Configuration Example
z Enable Option 82 on the DHCP relay agent (Router A).

z Configure the handling strategy for DHCP requests containing Option 82 as replace.
z Configure the padding content for the circuit ID sub-option as company001 and for the remote ID
sub-option as device001.
z Router A forwards DHCP requests to the DHCP server (Router B) after replacing Option 82 in the
requests, so that the DHCP clients can obtain IP addresses.
Network diagram
Refer to Figure 3-3.
# Enable DHCP.
# Add DHCP server 10.1.1.1 into DHCP server group 1.

[RouterA] dhcp relay server-group 1 ip 10.1.1.1
# Enable the DHCP relay agent on Ethernet 1/1.

[RouterA-Ethernet1/1] dhcp select relay
3-11
[RouterA-Ethernet1/1] dhcp relay server-select 1
# Enable the DHCP relay agent to support Option 82, and perform Option 82-related configurations.
[RouterA-Ethernet1/1] dhcp relay information enable
[RouterA-Ethernet1/1] dhcp relay information strategy replace
[RouterA-Ethernet1/1] dhcp relay information circuit-id string company001
[RouterA-Ethernet1/1] dhcp relay information remote-id string device001
You need to perform corresponding configurations on the DHCP server to make the Option 82
configurations function normally.
DHCP Relay Agent Configuration Examples (on a Switch)

DHCP Relay Agent Configuration Example
VLAN-interface 1 on the DHCP relay agent (Switch A) connects to the network where DHCP clients
reside. The IP address of VLAN-interface 1 is 10.10.1.1/24 and IP address of VLAN-interface 2 is
10.1.1.2/24 that communicates with the DHCP server 10.1.1.1/24. As shown in Figure 3-4, Switch A
forwards messages between DHCP clients and the DHCP server.
Network diagram
Figure 3-4 Network diagram for DHCP relay agent (on a switch)
Vlan-int1 Vlan-int2
10.10.1.1/24 10.1.1.2/24
Vlan-int2
10.1.1.1/24
Switch A Switch B
DHCP relay agent DHCP server
# Enable DHCP.

[SwitchA] dhcp relay server-group 1 ip 10.1.1.1
# Enable the DHCP relay agent on VLAN-interface 1.
3-12
[SwitchA-Vlan-interface1] dhcp select relay
# Correlate VLAN-interface 1 to DHCP server group 1.

[SwitchA-Vlan-interface1] dhcp relay server-select 1
z Performing the configuration on the DHCP server is also required to guarantee the client-server
communication via the relay agent. Refer to DHCP Server Configuration Examples (on a Switch)
for DHCP server configuration information.
z If the DHCP relay agent and server are on different subnets, routes in between must be reachable.
DHCP Relay Agent Option 82 Support Configuration Example
z Enable Option 82 on the DHCP relay agent (Switch A).

z Configure the padding content for the circuit ID sub-option as company001 and for the remote ID
sub-option as device001.
z Switch A forwards DHCP requests to the DHCP server (Switch B) after replacing Option 82 in the
Network diagram
# Enable DHCP.

[SwitchA] dhcp relay server-group 1 ip 10.1.1.1
# Enable the DHCP relay agent on VLAN-interface 1.

[SwitchA-Vlan-interface1] dhcp select relay
# Correlate VLAN-interface 1 to DHCP server group 1.

[SwitchA-Vlan-interface1] dhcp relay server-select 1
# Enable the DHCP relay agent to support Option 82, and perform Option 82-related configurations.
[SwitchA-Vlan-interface1] dhcp relay information enable
[SwitchA-Vlan-interface1] dhcp relay information strategy replace
[SwitchA-Vlan-interface1] dhcp relay information circuit-id string company001
[SwitchA-Vlan-interface1] dhcp relay information remote-id string device001
3-13
You need to perform corresponding configurations on the DHCP server to make the Option 82
configurations function normally.
Troubleshooting DHCP Relay Agent Configuration

Symptom
DHCP clients cannot obtain any configuration parameters via the DHCP relay agent.
Analysis
Some problems may occur with the DHCP relay agent or server configuration. Enable debugging and
execute the display command on the DHCP relay agent to view the debugging information and
interface state information for locating the problem.
Solution
Check that:
z The DHCP is enabled on the DHCP server and relay agent.
z The address pool on the same subnet where DHCP clients reside is available on the DHCP server.
z The routes between the DHCP server and DHCP relay agent are reachable.
z The relay agent interface connected to DHCP clients is correlated with correct DHCP server group
and IP addresses for the group members are correct.
3-14
4 DHCP Client Configuration
When configuring the DHCP client, go to these sections for information you are interested in:
z Introduction to DHCP Client
z Enabling the DHCP Client on an Interface
z Displaying and Maintaining the DHCP Client
z DHCP Client Configuration Example (on a Router)
z DHCP Client Configuration Example (on a Switch)
z The DHCP client configuration is supported only on Layer 3 Ethernet interfaces (or subinterfaces),
VLAN interfaces, and Layer 3 aggregate interfaces.
z When multiple VLAN interfaces with the same MAC address use DHCP for IP address acquisition
via a relay agent, the DHCP server cannot be a Windows 2000 Server or Windows 2003 Server.
z You are not recommended to enable both the DHCP client and the DHCP snooping on the same
device. Otherwise, DHCP snooping entries may fail to be generated, or the DHCP client may fail to
obtain an IP address.
z You cannot configure an interface of an aggregation group as a DHCP client.
Introduction to DHCP Client

With the DHCP client enabled on an interface, the interface will use DHCP to obtain configuration
parameters such as an IP address from the DHCP server.
Enabling the DHCP Client on an Interface

Follow these steps to enable the DHCP client on an interface:

Enable the DHCP client on ip address dhcp-alloc [ client-identifier Required

the interface mac interface-type interface-number ] Disabled by default.
4-1
z An interface can be configured to acquire an IP address in multiple ways, but these ways are
mutually exclusive. The latest configuration will overwrite the previous one.
z After the DHCP client is enabled on an interface, no secondary IP address is configurable for the
interface.
z If the IP address assigned by the DHCP server shares a network segment with the IP addresses of
other interfaces on the device, the DHCP client enabled interface will not request any IP address of
the DHCP server, unless the conflicted IP address is manually deleted and the interface is made
UP again by first executing the shutdown command and then the undo shutdown command or
the DHCP client is enabled on the interface by executing the undo ip address dhcp-alloc and ip
address dhcp-alloc commands in sequence.
Displaying and Maintaining the DHCP Client

Display specified configuration display dhcp client [ verbose ] [ interface Available in any
information interface-type interface-number ] view
DHCP Client Configuration Example (on a Router)

On a LAN, Router B contacts the DHCP server via Ethernet 1/1 to obtain an IP address.
Network diagram
See Figure 2-2.
The following is the configuration on Router B shown in Figure 2-2.

# Enable the DHCP client on Ethernet 1/1.
[RouterB-Ethernet1/1] ip address dhcp-alloc
To implement the DHCP client-server model, you need to perform related configuration on the DHCP
server. For details, refer to DHCP Server Configuration Examples (on a Router).
4-2
DHCP Client Configuration Example (on a Switch)
On a LAN, Switch B contacts the DHCP server via VLAN-interface 1 to obtain an IP address.
Network diagram
See Figure 2-5.
The following is the configuration on Switch B shown in Figure 2-5.

# Enable the DHCP client on VLAN-interface 1.
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ip address dhcp-alloc
To implement the DHCP client-server model, you need to perform related configuration on the DHCP
server. For details, refer to DHCP Server Configuration Examples (on a Switch).
4-3
5 DHCP Snooping Configuration
When configuring DHCP snooping, go to these sections for information you are interested in:
z DHCP Snooping Overview
z Configuring DHCP Snooping Basic Functions
z Configuring DHCP Snooping to Support Option 82
z Displaying and Maintaining DHCP Snooping
z DHCP Snooping Configuration Examples
z DHCP snooping is supported only on Layer 2 Ethernet interfaces.

z DHCP snooping supports no link aggregation. If a Layer 2 Ethernet interface is added into an
aggregation group, DHCP snooping configuration on it will not take effect. When the interface is
removed from the group, DHCP snooping can take effect.
z The DHCP snooping enabled device does not work if it is between the DHCP relay agent and
DHCP server, and it can work when it is between the DHCP client and relay agent or between the
DHCP client and server.
z The DHCP snooping enabled device cannot be a DHCP server or DHCP relay agent.
z You are not recommended to enable the DHCP client, BOOTP client, and DHCP snooping on the
same device. Otherwise, DHCP snooping entries may fail to be generated, or the BOOTP
client/DHCP client may fail to obtain an IP address.
DHCP Snooping Overview

Function of DHCP Snooping
As a DHCP security feature, DHCP snooping can implement the following:
Recording IP-to-MAC mappings of DHCP clients
For security, a network administrator needs to use the mappings between DHCP clients IP addresses
obtained from the DHCP server and their MAC addresses. DHCP snooping is used to record such
mappings.
DHCP snooping records clients MAC and IP addresses by reading their DHCP-REQUEST and
DHCP-ACK messages from trusted ports. The network administrator can check out which IP addresses
are assigned to the DHCP clients with the display dhcp-snooping command.
Ensuring DHCP clients to obtain IP addresses from valid DHCP servers
If there is an unauthorized DHCP server on a network, the DHCP clients may obtain invalid IP
addresses. With DHCP snooping, the ports of a device can be configured as trusted or untrusted,
ensuring the clients to obtain IP addresses from authorized DHCP servers.
5-1
z Trusted: A trusted port forwards DHCP messages normally to guarantee that DHCP clients can
obtain valid IP addresses from a DHCP server.
z Untrusted: An untrusted port discards the DHCP-ACK or DHCP-OFFER packets from any DHCP
server to prevent DHCP clients from receiving invalid IP addresses.
Application Environment of Trusted Ports
Configuring a trusted port connected to a DHCP server
A DHCP snooping devices port that is connected to an authorized DHCP server directly or indirectly
should be configured as a trusted port to forward reply messages from the DHCP server.
As shown in Figure 5-1, Ethernet 1/1 on Switch B is connected to Switch A (a DHCP server). Ethernet
1/1 should be configured as a trusted port, so that it can forward replies from Switch A.
Figure 5-1 Configure a trusted port connected with a DHCP sever
Configuring trusted ports in a cascaded network
In a cascaded network involving multiple DHCP snooping devices, the ports connected to other DHCP
snooping devices should be configured as trusted ports.
To save system resources, you can disable the trusted ports, which are indirectly connected to DHCP
clients, from recording clients IP-to-MAC bindings upon receiving DHCP requests.
As shown in Figure 5-2, Switch A, Switch B, and Switch C are DHCP snooping devices. Ethernet 1/2
and Ethernet 1/3 on Switch A, Ethernet 1/1 and Ethernet 1/2 on Switch B, and Ethernet 1/2, Ethernet
1/3, and Ethernet 1/4 on Switch C are configured as trusted ports. Disable the trusted ports, Ethernet
1/3 on Switch A, Ethernet 1/1 on Switch B, Ethernet 1/3 and Ethernet 1/4 on Switch C, which are not
directly connected to DHCP clients, from recording clients IP-to-MAC bindings.
5-2
Figure 5-2 Configure trusted ports in a cascaded network
DHCP Snooping Support for Option 82
Option 82 records the location information of the DHCP client. The administrator can locate the DHCP
client to further implement security control and accounting. For more information, refer to Relay agent
option (Option 82).
If DHCP snooping supports Option 82, it will handle a clients request according to the contents defined
in Option 82, if any. The handling strategies are described in the table below.
If a reply returned by the DHCP server contains Option 82, the DHCP snooping device will remove the
Option 82 before forwarding the reply to the client. If the reply contains no Option 82, the DHCP
snooping device forwards it directly.
If a clients
Handling Padding
requesting The DHCP snooping device will
strategy format
message has
Drop Random Drop the message.
Forward the message without changing
Keep Random
Option 82.
normal original Option 82 with the Option 82
padded in normal format.
Option 82
Replace verbose original Option 82 with the Option 82
padded in verbose format.
user-defined original Option 82 with the user-defined
Option 82.
5-3
If a clients
Handling Padding
requesting The DHCP snooping device will
strategy format
message has
normal
Option 82 padded in normal format.
no Option 82 verbose
Option 82 padded in verbose format.

user-defined
user-defined Option 82.
The handling strategy and padding format for Option 82 on the DHCP snooping device are the same as
those on the relay agent.
Configuring DHCP Snooping Basic Functions

Follow these steps to configure DHCP snooping basic functions:

Required
Enable DHCP snooping dhcp-snooping
interface-number
dhcp-snooping trust Required

Specify the port as trusted
[ no-user-binding ] Untrusted by default.
z You need to specify the ports connected to the valid DHCP servers as trusted to ensure that DHCP
clients can obtain valid IP addresses. The trusted port and the port connected to the DHCP client
must be in the same VLAN.
z Configuring both the DHCP snooping and selective QinQ function on the switch is not
recommended because it may result in malfunctioning of DHCP snooping.
5-4
Configuring DHCP Snooping to Support Option 82
Prerequisites
You need to enable the DHCP snooping function before configuring DHCP snooping to support Option
82.
Configuring DHCP Snooping to Support Option 82
Follow these steps to configure DHCP snooping to support Option 82:

interface-number
Enable DHCP snooping to support dhcp-snooping Required

Option 82 information enable Disabled by default.
Configure the handling strategy for dhcp-snooping Optional
requesting messages containing information strategy
Option 82 { drop | keep | replace } replace by default.
dhcp-snooping
information format
Configure the padding { normal | verbose Optional
format for Option 82 [ node-identifier { mac | normal by default.
sysname | user-defined
node-identifier } ] }
Optional
By default, the code type
Configure depends on the padding
non-user-def Configure the code dhcp-snooping
format of Option 82. Each
ined Option type for the circuit ID information circuit-id
field has its own code type.
82 sub-option format-type { ascii | hex }
This code type configuration
Option 82 only.
Optional
Configure the code dhcp-snooping hex by default.
type for the remote ID information remote-id The code type configuration
sub-option format-type { ascii | hex } applies to non-user-defined
Option 82 only.
5-5
Optional
Configure the padding dhcp-snooping
content for the circuit information [ vlan vlan-id ] By default, the padding
ID sub-option circuit-id string circuit-id content depends on the
Configure padding format of Option 82.
user-defined
Option 82 dhcp-snooping Optional
Configure the padding
information [ vlan vlan-id ] By default, the padding
content for the remote
remote-id string content depends on the
ID sub-option
{ remote-id | sysname } padding format of Option 82.
z To support Option 82, it is required to perform related configuration on both the DHCP server and
the device enabled with DHCP snooping. Refer to Configuring the Handling Mode for Option 82 for
DHCP server configuration of this kind.
z If the handling strategy of the DHCP-snooping-enabled device is configured as replace, you need
to configure a padding format for Option 82. If the handling strategy is keep or drop, you need not
configure any padding format.
z If the Option 82 is padded with the device name (sysname) of a node, the device name must
contain no spaces. Otherwise, the DHCP-snooping-enabled device will drop the message.
Displaying and Maintaining DHCP Snooping

Display DHCP snooping IP-to-MAC
display dhcp-snooping [ ip ip-address ]
bindings
Display Option 82 configuration display dhcp-snooping information
information on the DHCP snooping { all | interface interface-type
device interface-number }
Available in any
Display DHCP For centralized display dhcp-snooping packet
view
packet statistics devices statistics
on the DHCP For distributed display dhcp-snooping packet
snooping device devices statistics [ slot slot-number ]
Display information about trusted
display dhcp-snooping trust
ports
reset dhcp-snooping { all | ip
Clear DHCP snooping entries
ip-address }
Clear DHCP For centralized Available in

reset dhcp-snooping packet statistics
packet statistics devices user view
on the DHCP For distributed reset dhcp-snooping packet statistics
snooping device devices [ slot slot-number ]
5-6
DHCP Snooping Configuration Examples
DHCP Snooping Configuration Example
z Switch B is connected to a DHCP server through Ethernet 1/1, and to two DHCP clients through
Ethernet 1/2 and Ethernet 1/3.
z Ethernet 1/1 forwards DHCP server responses while the other two do not.
z Switch B records clients IP-to-MAC address bindings in DHCP-REQUEST messages and
DHCP-ACK messages received from trusted ports.
Network diagram
Figure 5-3 Network diagram for DHCP snooping configuration

# Specify Ethernet 1/1 as trusted.

DHCP Snooping Option 82 Support Configuration Example
z Enable DHCP snooping and Option 82 support on Switch B.

z On Ethernet 1/2, configure the padding content for the circuit ID sub-option as company001 and
for the remote ID sub-option as device001.
z On Ethernet 1/3, configure the padding format as verbose, access node identifier as sysname,
and code type as ascii for Option 82.
z Switch B forwards DHCP requests to the DHCP server (Switch A) after replacing Option 82 in the
5-7
Network diagram

# Specify Ethernet 1/1 as trusted.

# Configure Ethernet 1/2 to support Option 82.

[SwitchB-Ethernet1/2] dhcp-snooping information enable
[SwitchB-Ethernet1/2] dhcp-snooping information strategy replace
[SwitchB-Ethernet1/2] dhcp-snooping information circuit-id string company001
[SwitchB-Ethernet1/2] dhcp-snooping information remote-id string device001
# Configure Ethernet 1/3 to support Option 82.

[SwitchB-Ethernet1/3] dhcp-snooping information enable
[SwitchB-Ethernet1/3] dhcp-snooping information strategy replace
[SwitchB-Ethernet1/3] dhcp-snooping information format verbose node-identifier sysname
[SwitchB-Ethernet1/3] dhcp-snooping information circuit-id format-type ascii
[SwitchB-Ethernet1/3] dhcp-snooping information remote-id format-type ascii
5-8
6 BOOTP Client Configuration
While configuring a BOOTP client, go to these sections for information you are interested in:
z Introduction to BOOTP Client
z Configuring an Interface to Dynamically Obtain an IP Address Through BOOTP
z Displaying and Maintaining BOOTP Client Configuration
z BOOTP client configuration only applies to Layer 3 Ethernet interfaces (including sub-interfaces),
Layer 3 aggregate interfaces and VLAN interfaces.
z If several VLAN interfaces sharing the same MAC address obtain IP addresses through a BOOTP
relay agent, the BOOTP server cannot be a Windows 2000 Server or Windows 2003 Server.
z You are not recommended to enable both the DHCP client and DHCP snooping on the same
device. Otherwise, DHCP snooping entries may fail to be generated, or the BOOTP client may fail
to obtain an IP address.
z You cannot configure an interface of an aggregation group as a BOOTP client.
Introduction to BOOTP Client

z BOOTP Application
z Obtaining an IP Address Dynamically
z Protocols and Standards
BOOTP Application
After you specify an interface of a device as a BOOTP client, the interface can use BOOTP to get
information (such as IP address) from the BOOTP server, which simplifies your configuration.
Before using BOOTP, an administrator needs to configure a BOOTP parameter file for each BOOTP
client on the BOOTP server. The parameter file contains information such as MAC address and IP
address of a BOOTP client. When a BOOTP client originates a request to the BOOTP server, the
BOOTP server will search for the BOOTP parameter file and return the corresponding configuration
information.
Because you need to configure a parameter file for each client on the BOOTP server, BOOTP usually
runs under a relatively stable environment. If the network changes frequently, DHCP is more suitable.
6-1
Because a DHCP server can interact with a BOOTP client, you can use the DHCP server to configure
an IP address for the BOOTP client, without any BOOTP server.
Obtaining an IP Address Dynamically
A DHCP server can take the place of the BOOTP server in the following dynamic IP address
acquisition.
A BOOTP client dynamically obtains an IP address from a BOOTP server in the following steps:
1) The BOOTP client broadcasts a BOOTP request, which contains its own MAC address.
2) The BOOTP server receives the request and searches the configuration file for the corresponding
IP address and other information according to the MAC address of the BOOTP client. The BOOTP
server then returns a BOOTP response to the BOOTP client.
3) The BOOTP client obtains the IP address from the received response.
Some protocols and standards related to BOOTP include:

z RFC 951: Bootstrap Protocol (BOOTP)
z RFC 2132: DHCP Options and BOOTP Vendor Extensions
z RFC 1542: Clarifications and Extensions for the Bootstrap Protocol
Configuring an Interface to Dynamically Obtain an IP Address

Through BOOTP
Follow these steps to configure an interface to dynamically obtain an IP address:

interface-number
Configure an interface to Required

dynamically obtain IP ip address bootp-alloc By default, an interface does not use
address through BOOTP BOOTP to obtain an IP address.
6-2
Displaying and Maintaining BOOTP Client Configuration
Display related information on a display bootp client [ interface
BOOTP client interface-type interface-number ]
BOOTP Client Configuration Example (on a Router)

Ethernet 1/1 of Router B is connected to the LAN to obtain an IP address from the DHCP server by
using BOOTP.
Network diagram
See Figure 2-2.
The following describes only the configuration on Router B serving as a client.

# Configure Ethernet 1/1 to dynamically obtain an IP address by using BOOTP.
[RouterB-Ethernet1/1] ip address bootp-alloc
To make the BOOTP client obtain an IP address from the DHCP server, you need to perform additional
configurations on the DHCP server. For details, refer to DHCP Server Configuration Examples (on a
Router).
BOOTP Client Configuration Example (on a Switch)

Network requirement
Switch Bs port belonging to VLAN 1 is connected to the LAN. VLAN-interface 1 obtains an IP address
from the DHCP server by using BOOTP.
Network diagram
See Figure 2-5.
The following describes only the configuration on Switch B serving as a client.

# Configure VLAN-interface 1 to dynamically obtain an IP address from the DHCP server.
[SwitchB-Vlan-interface1] ip address bootp-alloc
6-3
To make the BOOTP client obtain an IP address from the DHCP server, you need to perform additional
configurations on the DHCP server. For details, refer to DHCP Server Configuration Examples (on a
Switch).
6-4
Table of Contents
1 DNS Configuration1-1
DNS Overview1-1
Static Domain Name Resolution 1-1
Dynamic Domain Name Resolution 1-2
DNS Proxy1-3
Configuring the DNS Client1-3
Configuring Static Domain Name Resolution 1-3
Configuring Dynamic Domain Name Resolution1-4
Configuring the DNS Proxy1-4
Displaying and Maintaining DNS 1-5
DNS Configuration Examples 1-5
Static Domain Name Resolution Configuration Example1-5
Dynamic Domain Name Resolution Configuration Example1-6
DNS Proxy Configuration Example 1-9
Troubleshooting DNS Configuration 1-10
i
1 DNS Configuration
When configuring DNS, go to these sections for information you are interested in:
z DNS Overview
z Configuring the DNS Client
z Configuring the DNS Proxy
z Displaying and Maintaining DNS
z DNS Configuration Examples
z Troubleshooting DNS Configuration
This document only covers IPv4 DNS configurations. For introduction to IPv6 DNS configurations, refer
to IPv6 Basics Configuration in the IP Services Volume.
DNS Overview
Domain Name System (DNS) is a distributed database used by TCP/IP applications to translate
domain names into corresponding IP addresses. With DNS, you can use easy-to-remember domain
names in some applications and let the DNS server translate them into correct IP addresses.
There are two types of DNS services, static and dynamic. After a user specifies a name, the device
checks the local static name resolution table for an IP address. If no IP address is available, it contacts
the DNS server for dynamic name resolution, which takes more time than static name resolution.
Therefore, some frequently queried name-to-IP address mappings are stored in the local static name
resolution table to improve efficiency.
Static Domain Name Resolution
The static domain name resolution means setting up mappings between domain names and IP
addresses. IP addresses of the corresponding domain names can be found in the static domain
resolution table when you use applications such as telnet.
1-1
Dynamic Domain Name Resolution
Resolving procedure
Dynamic domain name resolution is implemented by querying the DNS server. The resolution
procedure is as follows:
1) A user program sends a name query to the resolver of the DNS client.
2) The DNS resolver looks up the local domain name cache for a match. If a match is found, it sends
the corresponding IP address back. If not, it sends a query to the DNS server.
3) The DNS server looks up the corresponding IP address of the domain name in its DNS database.
If no match is found, it sends a query to a higher level DNS server. This process continues until a
result, whether successful or not, is returned.
4) The DNS client returns the resolution result to the application after receiving a response from the
DNS server.
Figure 1-1 Dynamic domain name resolution
Figure 1-1 shows the relationship between the user program, DNS client, and DNS server.
The resolver and cache comprise the DNS client. The user program and DNS client can run on the
same device or different devices, while the DNS server and the DNS client usually run on different
devices.
Dynamic domain name resolution allows the DNS client to store latest mappings between domain
names and IP addresses in the dynamic domain name cache. There is no need to send a request to the
DNS server for a repeated query next time. The aged mappings are removed from the cache after
some time, and latest entries are required from the DNS server. The DNS server decides how long a
mapping is valid, and the DNS client gets the aging information from DNS messages.
DNS suffixes
The DNS client normally holds a list of suffixes which can be defined by users. It is used when the name
to be resolved is incomplete. The resolver can supply the missing part. For example, a user can
configure com as the suffix for aabbcc.com. The user only needs to type aabbcc to get the IP address
of aabbcc.com. The resolver can add the suffix and delimiter before passing the name to the DNS
server.
z If there is no dot in the domain name (for example, aabbcc), the resolver will consider this a host
name and add a DNS suffix before query. If no match is found after all the configured suffixes are
used respectively, the original domain name (for example, aabbcc) is used for query.
z If there is a dot in the domain name (for example, www.aabbcc), the resolver will directly use this
domain name for query. If the query fails, the resolver adds a DNS suffix for another query.
1-2
z If the dot is at the end of the domain name (for example, aabbcc.com.), the resolver will consider it
a fully qualified domain name (FQDN) and return the query result, successful or failed. Hence, the
dot . at the end of the domain name is called the terminating symbol.
Currently, the device supports static and dynamic DNS services.
If an alias is configured for a domain name on the DNS server, the device can resolve the alias into the
IP address of the host.
DNS Proxy
Introduction to DNS proxy
A DNS proxy forwards DNS requests and replies between DNS clients and a DNS server.
As shown in Figure 1-2, a DNS client sends a DNS request to the DNS proxy, which forwards the
request to the designated DNS server, and conveys the reply from the DNS server to the client.
The DNS proxy simplifies network management. When the DNS server address is changed, you only
need to change the configuration on the DNS proxy instead of on each DNS client.
Figure 1-2 DNS proxy networking application
Operation of a DNS proxy
1) A DNS client considers the DNS proxy as the DNS server, and sends a DNS request to the DNS
proxy, that is, the destination address of the request is the IP address of the DNS proxy.
2) The DNS proxy searches the local static domain name resolution table after receiving the request.
If the requested information exists in the table, the DNS proxy returns a DNS reply to the client.
3) If the requested information does not exist in the static domain name resolution table, the DNS
proxy sends the request to the designated DNS server for domain name resolution.
4) After receiving a reply from the DNS server, the DNS proxy forwards the reply to the DNS client.
Configuring the DNS Client

Configuring Static Domain Name Resolution
Follow these steps to configure static domain name resolution:
1-3
Configure a mapping between Required
a host name and IP address in ip host hostname ip-address
the static name resolution table Not configured by default.
The IP address you last assign to the host name will overwrite the previous one if there is any.
You may create up to 50 static mappings between domain names and IP addresses.
Configuring Dynamic Domain Name Resolution
Follow these steps to configure dynamic domain name resolution:

Enable dynamic domain name Required

dns resolve
resolution Disabled by default.
Required
Specify a DNS server dns server ip-address
Not specified by default
Configure a domain name Optional

dns domain domain-name
suffix Not configured by default
You may configure up to six DNS servers and ten DNS suffixes.
Configuring the DNS Proxy

Follow these steps to configure the DNS proxy:

Required
Enable DNS proxy dns proxy enable
1-4
Displaying and Maintaining DNS
Display the static domain name
display ip host
resolution table
display dns server
Display DNS server information
[ dynamic ]
display dns domain

Display domain name suffixes
[ dynamic ]
Display the information of the Available in any view
display dns dynamic-host
dynamic domain name cache
Display the DNS proxy table display dns proxy table
Clear the information of the
reset dns dynamic-host Available in user view
dynamic domain name cache
DNS Configuration Examples

Static Domain Name Resolution Configuration Example
Device uses the static domain name resolution to access Host with IP address 10.1.1.2 through domain
name host.com.
Network diagram
Figure 1-3 Network diagram for static domain name resolution
# Configure a mapping between host name host.com and IP address 10.1.1.2.

[Sysname] ip host host.com 10.1.1.2
# Execute the ping host.com command to verify that the device can use the static domain name
resolution to get the IP address 10.1.1.2 corresponding to host.com.
[Sysname] ping host.com
PING host.com (10.1.1.2):
56 data bytes, press CTRL_C to break
1-5
--- host.com ping statistics ---
0.00% packet loss
Dynamic Domain Name Resolution Configuration Example
z The IP address of the DNS server is 2.1.1.2/16 and the name suffix is com.
z Device serves as a DNS client, and uses the dynamic domain name resolution and the suffix to
access the host with the domain name host.com and the IP address 3.1.1.1/16.
Network diagram
Figure 1-4 Network diagram for dynamic domain name resolution
z Before performing the following configuration, make sure that there is a route between the device
and the host, and the IP addresses of the interfaces are configured as shown Figure 1-4.
z This configuration may vary with different DNS servers. The following configuration is performed
on a Windows 2000 server.
1) Configure the DNS server

# Enter DNS server configuration page.
Select Start > Programs > Administrative Tools > DNS.
# Create zone com.
In Figure 1-5, right click Forward Lookup Zones, select New zone, and then follow the instructions to
create a new zone named com.
1-6
Figure 1-5 Create a zone
# Create a mapping between the host name and IP address.

Figure 1-6 Add a host
In Figure 1-6, right click zone com, and then select New Host to bring up a dialog box as shown in
Figure 1-7. Enter host name host and IP address 3.1.1.1.
1-7
Figure 1-7 Add a mapping between domain name and IP address
2) Configure the DNS client

# Enable dynamic domain name resolution.
[Sysname] dns resolve
# Specify the DNS server 2.1.1.2.

[Sysname] dns server 2.1.1.2
# Configure com as the name suffix.

[Sysname] dns domain com
3) Configuration verification
# Execute the ping host command on the device to verify that the communication between the device
and the host is normal and that the corresponding destination IP address is 3.1.1.1.
[Sysname] ping host
Trying DNS resolve, press CTRL_C to break
Trying DNS server (2.1.1.2)

0.00% packet loss
1-8
DNS Proxy Configuration Example
z Specify Device A as the DNS server of Device B (the DNS client).

z Device A acts as a DNS proxy. The IP address of the real DNS server is 4.1.1.1.
z Device B implements domain name resolution through Device A.
Network diagram
Figure 1-8 Network diagram for DNS proxy
Before performing the following configuration, assume that Device A, the DNS server, and the host are
reachable to each other and the IP addresses of the interfaces are configured as shown in Figure 1-8.
1) Configure the DNS server

This configuration may vary with different DNS servers. When a Windows 2000 server acts as the DNS
server, refer to Dynamic Domain Name Resolution Configuration Example for related configuration
information.
2) Configure the DNS proxy
[DeviceA] dns server 4.1.1.1
# Enable DNS proxy.

[DeviceA] dns proxy enable
3) Configure the DNS client
# Enable the domain name resolution function.
1-9
[DeviceB] dns resolve

[DeviceB] dns server 2.1.1.2
4) Configuration verification
# Execute the ping host.com command on Device B to verify that the communication between the
device and the host is normal and that the corresponding destination IP address is 3.1.1.1.
[DeviceB] ping host.com
Trying DNS resolve, press CTRL_C to break
Trying DNS server (2.1.1.2)

0.00% packet loss
Troubleshooting DNS Configuration

Symptom
After enabling the dynamic domain name resolution, the user cannot get the correct IP address.
Solution
z Use the display dns dynamic-host command to verify that the specified domain name is in the
cache.
z If the specified domain name does not exist, check that dynamic domain name resolution is
enabled and the DNS client can communicate with the DNS server.
z If the specified domain name is in the cache, but the IP address is incorrect, check that the DNS
client has the correct IP address of the DNS server.
z Verify the mapping between the domain name and IP address is correct on the DNS server.
1-10
Table of Contents
1 IP Accounting Configuration1-1
Introduction to IP Accounting 1-1
Configuring IP Accounting 1-1
IP Accounting Configuration Example 1-2
Network Diagram1-3
Displaying and Maintaining IP Accounting Configuration 1-4
i
1 IP Accounting Configuration
When configuring IP accounting, go to these sections for information you are interested in:
z Introduction to IP Accounting
z Configuring IP Accounting
z IP Accounting Configuration Example
z Displaying and Maintaining IP Accounting Configuration
Introduction to IP Accounting
The IP accounting feature implements the statistics of IP packets passing through the router. These IP
packets include those sent and forwarded by the router normally as well as those denied by the firewall.
The statistics of the IP accounting includes information such as source and destination IP addresses,
protocol number, packet sum, and byte sum. The statistics results of IP packets passing the firewall and
those matching the IP accounting rule are respectively stored and displayed.
Each IP accounting rule consists of an IP address and its mask, namely, a subnet address, which is the
result of ANDing the IP address with its mask. IP packets are sorted as follows:
z If a firewall is configured on an interface and incoming and outgoing IP packets are denied by the
firewall, these IP packets are counted in the firewall-denied table.
z If the source or destination IP address of the IP packets passing the interface or the firewall, if
configured, matches a network address in the IP accounting rule, the packets are counted in the
interior table. Otherwise, the packets are counted in the exterior table.
z If the flow records in an accounting table are not updated within their aging time, the router
considers that the records time out and deletes them.
Configuring IP Accounting
Assign an IP address and mask to the interface on which the IP accounting feature needs to be enabled.
If necessary, configure a firewall on the interface.
Follow these steps to configure IP accounting:
1-1
Required
Enable the IP accounting feature ip count enable
Optional
Configure the aging time for a flow
ip count timeout minutes 720 minutes (namely, 12
record
hours) by default.
ip count Optional
Configure the maximum number of flow
interior-threshold
records in the interior table 512 by default.
number
ip count Optional
Configure the maximum number of flow
exterior-threshold
records in the exterior table 0 by default.
number
Required
Up to 32 rules can be
configured.
ip count rule { mask | If no rule is configured, the
Configure IP accounting rules
mask-length } current packets are not
concerned and are all
counted in the exterior
table.
interface-number
Count incoming valid IP
ip count
packets on the current
inbound-packets
interface
Count outgoing valid IP Required
ip count
Configure packets on the current
outbound-packets Select at least one type of
the type of interface
packet accounting.
packet Count firewall-denied Otherwise, no IP packets
accounting ip count firewall-denied are to be counted on the
incoming packets on the
inbound-packets current interface.
current interface
Count firewall-denied
ip count firewall-denied
outgoing packets on the
outbound-packets
current interface
IP Accounting Configuration Example

As shown in Figure 1-1, the router is connected to Host A and Host B through Ethernet interfaces.
Enable IP accounting on Ethernet 1/0 of the router to count the IP packets from Host A to Host B, with
the aging time for IP accounting entries being 24 hours.
1-2
Network Diagram
Figure 1-1 Network diagram for IP accounting configuration
z Configure the router.

# Enable IP accounting.
[Router] ip count enable
# Configure an IP accounting rule.

[Router] ip count rule 1.1.1.1 24
# Set the aging time to 1440 minutes (24 hours).

[Router] ip count timeout 1440
# Set the maximum number of accounting entries in the interior table to 100.
[Router] ip count interior-threshold 100
# Set the maximum number of accounting entries in the exterior table to 20.
[Router] ip count exterior-threshold 20
# Assign Ethernet 1/0 an IP address and count both incoming and outgoing IP packets on it.
[Router-Ethernet1/0] ip address 1.1.1.2 24
[Router-Ethernet1/0] ip count inbound-packets
[Router-Ethernet1/0] ip count outbound-packets
# Assign Ethernet 1/1 an IP address.

[Router-Ethernet1/1] ip address 2.2.2.1 24
z Configure Host A and Host B.
# Configure static routes from Host A to Host B and from Host B to Host A. Ping Host B from Host A.
Omitted.
z Display the IP accounting information.
# Display IP accounting information on the router.
[Router] display ip count inbound-packets interior
1 Inbound streams information in interior list:
SrcIP DstIP Protocol Pkts Bytes
1.1.1.1 2.2.2.2 ICMP 4 240
[Router] display ip count outbound-packets interior
1-3
1 Outbound streams information in interior list:
SrcIP DstIP Protocol Pkts Bytes
2.2.2.2 1.1.1.1 ICMP 4 240
The two hosts can be replaced by other types of network devices such as routers.
Displaying and Maintaining IP Accounting Configuration

Display the IP accounting rules display ip count rule Available in any view
display ip count { inbound-packets |
Display IP accounting
outbound-packets } { exterior | Available in any view
information
firewall-denied | interior }
reset ip count { all | exterior |
Clear IP accounting information Available in user view
firewall | interior }
After you configure a new IP accounting rule, it is possible that some originally rule-incompliant packets
from a subnet comply with the new rule. Information about these packets is then saved in the interior
table. The exterior table, however, may still contain information about these packets. Therefore, in
some cases, the interior and exterior tables contain statistics information about the IP packets from the
same subnet. The statistics information in the exterior table will be removed when the aging time
expires.
1-4
Table of Contents
1 IP Addressing Configuration1-1
IP Addressing Overview1-1
IP Address Classes 1-1
Special Case IP Addresses1-2
Subnetting and Masking 1-3
IP Unnumbered 1-3
Configuring IP Addresses 1-3
Assigning an IP Address to an Interface 1-4
IP Addressing Configuration Example (on Routers) 1-4
IP Addressing Configuration Example (on Switches)1-6
Configuring IP Unnumbered 1-8
IP Unnumbered Configuration Example (on Routers)1-9
IP Unnumbered Configuration Example (on Switches)1-10
Displaying and Maintaining IP Addressing1-12
i

Manual IP addresses
Yes Yes Yes Yes
assignment
IP address assignment
Yes Yes Yes Yes
through BOOTP
IP address allocation
Yes Yes Yes Yes
through DHCP
IP address allocation
Yes Yes Yes Yes
through PPP negotiation
1 IP Addressing Configuration
When assigning IP addresses to interfaces on your device, go to these sections for information you are
interested in:
z IP Addressing Overview
z Configuring IP Addresses
z Configuring IP Unnumbered
z Displaying and Maintaining IP Addressing
IP Addressing Overview
z IP Address Classes
z Special Case IP Addresses
z IP Unnumbered
IP Address Classes
IP addressing uses a 32-bit address to identify each host on a network. An example is

01010000100000001000000010000000 in binary. To make IP addresses in 32-bit form easier to read,
they are written in dotted decimal notation, each being four octets in length, for example, 10.1.1.1.
Each IP address breaks down into two parts:
1-1
z Net-id: First several bits of the IP address defining a network, also known as class bits.
z Host-id: Identifies a host on a network.
For administration sake, IP addresses are divided into five classes. Which class an IP address belongs
to depends on the first one to four bits of the net-id, as shown in the following figure (in which the blue
parts represent the address class).
Figure 1-1 IP address classes
Table 1-1 describes the address ranges of these five classes. Currently, the first three classes of IP
addresses are used in quantity.
Table 1-1 IP address classes and ranges
Class Address range Description

The IP address 0.0.0.0 is used by a host at
bootstrap for temporary communication. This
address is never a valid destination address.
A 0.0.0.0 to 127.255.255.255 Addresses starting with 127 are reserved for
loopback test. Packets destined to these
addresses are processed locally as input
packets rather than sent to the link.
B 128.0.0.0 to 191.255.255.255
C 192.0.0.0 to 223.255.255.255
D 224.0.0.0 to 239.255.255.255 Multicast address.
Reserved for future use except for the
E 240.0.0.0 to 255.255.255.255
broadcast address 255.255.255.255.
Special Case IP Addresses
The following IP addresses are for special use, and they cannot be used as host IP addresses:
z IP address with an all-zero net ID: Identifies a host on the local network. For example, IP address
0.0.0.16 indicates the host with a host ID of 16 on the local network.
z IP address with an all-zero host ID: Identifies a network.
z IP address with an all-one host ID: Identifies a directed broadcast address. For example, a packet
with the destination address of 192.168.1.255 will be broadcasted to all the hosts on the network
192.168.1.0.
1-2
Subnetting and Masking
Subnetting was developed to address the risk of IP address exhaustion resulting from fast expansion of
the Internet. The idea is to break a network down into smaller networks called subnets by using some
bits of the host-id to create a subnet-id. To identify the boundary between the host-id and the
combination of net-id and subnet-id, masking is used. (When subnetting is not adopted, a mask
identifies the boundary between the net-id and the host-id.)
Each subnet mask comprises 32 bits related to the corresponding bits in an IP address. In a subnet
mask, the part containing consecutive ones identifies the combination of net-id and subnet-id whereas
the part containing consecutive zeros identifies the host-id.
Figure 1-2 shows how a Class B network is subnetted.
Figure 1-2 Subnet a Class B network
When designing your network, you should note that subnetting is somewhat a tradeoff between subnets
and accommodated hosts. For example, a Class B network can accommodate 65,534 (216 2. Of the
two deducted Class B addresses, one with an all-one host-id is the broadcast address and the other
with an all-zero host-id is the network address) hosts before being subnetted. After you break it down
into 512 (29) subnets by using the first 9 bits of the host-id, you have only 7 bits for the host-id and thus
have only 126 (27 2) hosts in each subnet. The maximum number of hosts is thus 64,512 (512 126),
1022 less after the network is subnetted.
Class A, B, and C networks, before being subnetted, use these default masks (also called natural
masks): 255.0.0.0, 255.255.0.0, and 255.255.255.0 respectively.
IP Unnumbered
Logically, to enable IP on an interface, you must assign this interface a unique IP address. Yet, you can
borrow an IP address already configured on one of other interfaces on your device instead. This is
called IP unnumbered and the interface borrowing the IP address is called IP unnumbered interface.
You may need to use IP unnumbered to save IP addresses either when available IP addresses are
inadequate or when an interface is brought up but for occasional use.
Configuring IP Addresses
Besides directly assigning an IP address to an interface, you may configure the interface to obtain one
through BOOTP, DHCP, or PPP address negotiation as alternatives. If you change the way an interface
obtains an IP address, from manual assignment to BOOTP for example, the IP address obtained from
BOOTP will overwrite the old one manually assigned.
1-3
Support for IP address acquisition modes depends on the device model.
This chapter only covers how to assign an IP address manually. For other approaches, refer to DHCP
Configuration in the IP Services Volume and PPP Configuration in the Access Volume.
This section includes:

z Assigning an IP Address to an Interface
z IP Addressing Configuration Example (on Routers)
z IP Addressing Configuration Example (on Switches)
Assigning an IP Address to an Interface
You may assign an interface multiple IP addresses, one primary and multiple secondaries, to connect
multiple logical subnets on the same physical subnet.
Follow these steps to assign an IP address to an interface:

interface-number
Required
Assign an IP
ip address ip-address { mask No IP address is assigned by default.
address to the
| mask-length } [ sub ] The availability of the sub keyword
interface
depends on the device model.
z The primary IP address you assigned to the interface can overwrite the old one if there is any.
z You cannot assign secondary IP addresses to an interface that has BOOTP, DHCP, PPP, or IP
unnumbered configured.
z The primary and secondary IP addresses you assign to the interface can be located on the same
network segment. However, this should not violate the rule that different physical interfaces on your
device, a primary interface and its subinterfaces, or the subinterfaces on a father interface must
reside on different network segments.
IP Addressing Configuration Example (on Routers)
As shown in Figure 1-3, Ethernet 1/0 on Router is connected to a LAN comprising two segments:
172.16.1.0/24 and 172.16.2.0/24.
To enable the hosts on the two network segments to access the external network through the router,
and enable the hosts on the two network segments to communicate with each other, do the following:
1-4
z Assign a primary IP address and a secondary IP address to Ethernet 1/0 on the router.
z Set the router as the gateway on all hosts.
Network diagram
Figure 1-3 Network diagram for IP address configuration (on a router)
172.16.1.0/24 Router
Host B
Eth1/0
172.16.1.1/24
172.16.1.2/24 172.16.2.1/24 sub
172.16.2.2/24
Host A
172.16.2.0/24
# Assign a primary IP address and a secondary IP address to Ethernet 1/0.

[Router-Ethernet1/0] ip address 172.16.2.1 255.255.255.0 sub
# Set the gateway address to 172.16.1.1 on the PCs attached to 172.16.1.0/24, and to 172.16.2.1 on
the PCs attached to 172.16.2.0/24.
# Use the ping command to verify the connectivity between the router and the hosts on the subnet
172.16.1.0/24.
<Router> ping 172.16.1.2

0.00% packet loss
The information shown above indicates the router can communicate with the hosts on the subnet
172.16.1.0/24.
1-5
# Use the ping command to verify the connectivity between the router and the hosts on the subnet
172.16.2.0/24.
<Router> ping 172.16.2.2

0.00% packet loss
The information shown above indicates the router can communicate with the hosts on the subnet
172.16.2.0/24.
# Use the ping command to verify the connectivity between the hosts on the subnet 172.16.1.0/24 and
hosts on subnet 172.16.2.0/24. Ping Host B on Host A to verify that the ping operation is successful.
IP Addressing Configuration Example (on Switches)
As shown in Figure 1-4, the VLAN-interface 1 on a switch is connected to a LAN comprising two
segments: 172.16.1.0/24 and 172.16.2.0/24.
To enable the hosts on the two network segments to access the external network through the switch,
and enable the hosts on the two network segments to communicate with each other, do the following:
z Assign a primary IP address and a secondary IP address to VLAN-interface 1 on the switch.
z Set the switch as the gateway on all hosts.
1-6
Network diagram
Figure 1-4 Network diagram for IP addressing configuration (on a switch)
# Assign a primary IP address and a secondary IP address to VLAN-interface 1.

[Switch-Vlan-interface1] ip address 172.16.2.1 255.255.255.0 sub
# Set the gateway address to 172.16.1.1 on the PCs attached to the subnet 172.16.1.0/24, and to
172.16.2.1 on the PCs attached to the subnet 172.16.2.0/24.
# Use the ping command to verify the connectivity between the switch and the hosts on the subnet
172.16.1.0/24.
<Switch> ping 172.16.1.2

0.00% packet loss
The information shown above indicates the switch can communicate with the hosts on the subnet
172.16.1.0/24.
# Use the ping command to verify the connectivity between the switch and the hosts on the subnet
172.16.2.0/24.
1-7
<Switch> ping 172.16.2.2

0.00% packet loss
The information shown above indicates the switch can communicate with the hosts on the subnet
172.16.2.0/24.
# Use the ping command to verify the connectivity between hosts on the subnet 172.16.1.0/24 and
hosts on subnet 172.16.2.0/24. Ping Host B on Host A to verify that the ping operation is successful.
Configuring IP Unnumbered
This section includes:
z Configuration Prerequisites
z Configuration Procedure
z IP Unnumbered Configuration Example (on Routers)
z IP Unnumbered Configuration Example (on Switches)
Assign a primary IP address to the interface from which you want to borrow the IP address. Alternatively,
you may configure the interface to obtain one through BOOTP, DHCP, or PPP negotiation.
Follow these steps to configure IP unnumbered on an interface:

interface-number
Required
Specify the current interface to ip address unnumbered
borrow the IP address of the interface interface-type The interface does not borrow
specified interface interface-number IP addresses from other
interfaces by default.
1-8
z Serial, dialer, POS, and ATM interfaces can borrow IP addresses from Layer 3 Ethernet interfaces
or other interfaces.
z Layer 3 Ethernet interfaces, tunnel interfaces, and loopback interfaces cannot borrow IP addresses
of other interfaces, but other interfaces can borrow IP addresses of these interfaces.
z One interface cannot borrow an IP address from an unnumbered interface.
z Multiple interfaces can use the same unnumbered IP address.
z If an unnumbered interface has multiple IP addresses, only the primary IP address can be
borrowed.
z The IP address of the borrowing interface varies with that of the borrowed interface. That is, if an IP
address is configured for the borrowed interface, the IP address of the borrowing interface is the
same as that of the borrowed interface; if no IP address is configured for the borrowed interface, no
IP address is assigned for the borrowing interface.
IP Unnumbered Configuration Example (on Routers)
Two routers on an intranet are connected to each other through serial interfaces across DDN, and they
each connect to a LAN through Ethernet interfaces.
To save IP addresses, configure the serial interfaces to borrow IP addresses from the Ethernet
interfaces.
Network diagram
Figure 1-5 Network diagram for IP unnumbered configuration (on routers)
# Assign a primary IP address to Ethernet 1/1.
1-9
# Configure Serial 2/1 to borrow an IP address from Ethernet 1/1.
[RouterA-Serial2/1] ip address unnumbered interface ethernet 1/1
# Create a route to the Ethernet segment attached to Router B, specifying interface Serial 2/1 as the
outgoing interface.
[RouterA] ip route-static 172.16.20.0 255.255.255.0 serial 2/1
# Assign a primary IP address to Ethernet 1/1.
# Configure interface Serial 2/1 to borrow an IP address from Ethernet 1/1.

[RouterB-Serial2/1] ip address unnumbered interface ethernet 1/1
# Create a route to the Ethernet segment attached to Router A, specifying interface Serial 2/1 as the
outgoing interface.
[RouterB] ip route-static 172.16.10.0 255.255.255.0 serial 2/1
3) Ping a host attached to Router B from Router A to verify the configuration.

0.00% packet loss
The output shows that the host can be pinged.
IP Unnumbered Configuration Example (on Switches)
Two switches on an intranet are connected to each other through POS interfaces across DDN, and they
each connect to a LAN through VLAN-interfaces.
To save IP addresses, configure the POS interfaces to borrow IP addresses from the VLAN interfaces.
1-10
Network diagram
Figure 1-6 Network diagram for IP unnumbered configuration (on switches)
DDN
POS5/1 POS5/1
Switch A Switch B
Vlan-int100 Vlan-int100
172.16.10.1/24 172.16.20.1/24
# Assign an IP address to VLAN-interface 100
[SwitchA-Vlan-interface100] ip address 172.16.10.1 255.255.255.0
# Configure interface POS 5/1 to borrow an IP address from interface VLAN-interface 100.
[SwitchA] interface pos 5/1
[SwitchA-Pos5/1] ip address unnumbered interface vlan-interface 100
[SwitchA-Pos5/1] quit
# Create a route to the segment attached to Switch B, specifying interface POS 5/1 as the outgoing
interface.
[SwitchA] ip route-static 172.16.20.0 255.255.255.0 pos 5/1
# Assign an IP address to VLAN-interface 100
[SwitchB-Vlan-interface100] ip address 172.16.20.1 255.255.255.0
[SwitchB-Vlan-interface100] quit
# Configure interface POS 5/1 to borrow an IP address from interface VLAN-interface 100.
[SwitchB] interface pos 5/1
[SwitchB-Pos5/1] ip address unnumbered interface vlan-interface 100
[SwitchB-Pos5/1] quit
# Create a route to the segment attached to Switch A, specifying interface POS 5/1 as the outgoing
interface.
[SwitchB] ip route-static 172.16.10.0 255.255.255.0 pos 5/1
3) Ping a host attached to Switch B from Switch A to verify the configuration.
[SwitchA] ping 172.16.20.2
1-11

0.00% packet loss
Displaying and Maintaining IP Addressing

Display information about a specified display ip interface [ interface-type Available in any
or all Layer 3 interfaces interface-number ] view
Display brief information about a display ip interface brief Available in any
specified or all Layer 3 interfaces [ interface-type [ interface-number ] ] view
1-12
Table of Contents
1 IP Performance Configuration1-1
IP Performance Overview 1-1
Enabling Reception and Forwarding of Directed Broadcasts to a Directly Connected Network 1-2
Enabling Reception of Directed Broadcasts to a Directly Connected Network1-2
Enabling Forwarding of Directed Broadcasts to a Directly Connected Network 1-2
Configuration Example (on Routers) 1-3
Configuration Example (on Switches) 1-4
Configuring TCP Attributes 1-5
Configuring TCP MSS for the Interface1-5
Enabling the SYN Cookie Feature 1-5
Enabling Protection Against Naptha Attack1-6
Configuring TCP Optional Parameters1-7
Configuring ICMP to Send Error Packets 1-8
Displaying and Maintaining IP Performance 1-10
i

Reception and forwarding
of directed broadcasts to a Yes Yes Yes Yes
directly connected network
SYN Cookie Yes Yes Yes Yes
Naptha attack prevention Yes Yes Yes Yes
1 IP Performance Configuration
When configuring IP performance, go to these sections for information you are interested in:
z IP Performance Overview
z Enabling Reception and Forwarding of Directed Broadcasts to a Directly Connected Network
z Configuring TCP Attributes
z Configuring ICMP to Send Error Packets
z Displaying and Maintaining IP Performance
IP Performance Overview
In some network environments, you need to adjust the IP parameters to achieve best network
performance. IP performance configuration includes:
z Enabling the device to receive and forward directed broadcasts
z Configuring the maximum TCP segment size (MSS) of the interface
z Enabling the SYN Cookie feature and protection against Naptha attack
z Configuring TCP timers
z Configuring the TCP buffer size
z Enabling ICMP error packets sending
1-1
Enabling Reception and Forwarding of Directed Broadcasts to a
Directly Connected Network
Directed broadcasts refer to broadcast packets sent to a specific network. In the destination IP address
of a directed broadcast, the network ID is a network-specific number and the host ID is all ones.
Enabling the device to receive and forward directed broadcasts to a directly connected network will give
hackers an opportunity to attack the network. Therefore, the device is disabled from receiving and
forwarding directed broadcasts by default. However, you should enable the feature when:
z Using the UDP Helper function to convert broadcasts to unicasts and forward them to a specified
server.
z Using the Wake on LAN function to forward directed broadcasts to a host on the remote network.
Enabling Reception of Directed Broadcasts to a Directly Connected Network
If a device is enabled to receive directed broadcasts, the device will determine whether to forward them
according to the configuration on the outgoing interface.
Follow these steps to enable the device to receive directed broadcasts:

Required
Enable the device to receive By default, the device is
ip forward-broadcast
directed broadcasts disabled from receiving
directed broadcasts.
Some devices can still receive broadcasts (for example, port broadcasts that need to be forwarded via
UDP Helper) from a designated UDP port while others will directly discard all directed broadcasts, even
if these devices are all disabled from receiving directed broadcasts.
Enabling Forwarding of Directed Broadcasts to a Directly Connected Network
Follow these steps to enable the device to forward directed broadcasts:

interface-number
1-2
Required
Enable the interface to forward ip forward-broadcast [ acl By default, the device is
directed broadcasts acl-number ] disabled from forwarding
directed broadcasts.
z You can reference an ACL to forward only directed broadcasts permitted by the ACL.
z If you execute the ip forward-broadcast acl command on an interface repeatedly, the last
execution overwrites the previous one. If the command executed last time does not include the acl
acl-number, the ACL configured previously will be removed.
Configuration Example (on Routers)
As shown in Figure 1-1, the hosts interface and Ethernet 1/1 of Router A are on the same network
segment (1.1.1.0/24). Interface Ethernet 1/0 of Router A and interface Ethernet 1/0 of Router B are on
another network segment (2.2.2.0/24). The default gateway of the host is Ethernet 1/1 (IP address
1.1.1.2/24) of Router A. Configure a static route on Router B to enable the reachability between the host
and Router B.
Network diagram
Figure 1-1 Network diagram for receiving and forwarding directed broadcasts on a router
z Configure Router A
# Enable Router A to receive directed broadcasts.
[RouterA] ip forward-broadcast
# Configure IP addresses for Ethernet 1/1 and Ethernet 1/0.

# Enable Ethernet 1/0 to forward directed broadcasts.

[RouterA-Ethernet1/0] ip forward-broadcast
1-3
z Configure Router B
# Enable Router B to receive directed broadcasts.
[RouterB] ip forward-broadcast
# Configure a static route to the host.

# Configure an IP address for Ethernet 1/0.

After the above configurations, if you ping the subnet broadcast address (2.2.2.255) of interface
Ethernet 1/0 of Router A on the host, the ping packets can be received by interface Ethernet 1/0 of
Router B. However, if you disable the ip forward-broadcast command, the ping packets cannot be
received by interface Ethernet 1/0 of Router B.
Configuration Example (on Switches)
As shown in Figure 1-2, the hosts interface and VLAN-interface 3 of Switch A are on the same network
segment (1.1.1.0/24). VLAN-interface 2 of Switch A and VLAN-interface 2 of Switch B are on another
network segment (2.2.2.0/24). The default gateway of the host is VLAN-interface 3 (IP address
1.1.1.2/24) of Switch A. Configure a static route on Switch B to enable the reachability between host
and Switch B.
Network diagram
Figure 1-2 Network diagram for receiving and forwarding directed broadcasts (on a switch)
z Configure Switch A
# Enable Switch A to receive directed broadcasts.
[SwitchA] ip forward-broadcast
# Configure IP addresses for VLAN-interface 3 and VLAN-interface 2.

# Enable VLAN-interface 2 to forward directed broadcasts.
1-4
[SwitchA-Vlan-interface2] ip forward-broadcast
z Configure Switch B
# Enable Switch B to receive directed broadcasts.
[SwitchB] ip forward-broadcast
# Configure a static route to the host.

[SwitchB] ip route-static 1.1.1.1 24 2.2.2.2
# Configure an IP address for VLAN-interface 2.

[SwitchB-Vlan-interface2] ip address 2.2.2.1 24
After the above configurations, if you ping the subnet broadcast address (2.2.2.255) of VLAN-interface
2 of Switch A on the host, the ping packets can be received by VLAN-interface 2 of Switch B. However,
if you disable the ip forward-broadcast command, the ping packets cannot be received by the
VLAN-interface 2 of Switch B.
Configuring TCP Attributes

Configuring TCP MSS for the Interface
An interfaces TCP MSS determines whether the TCP packets of the interface need to be fragmented. If
the size of a packet is smaller than the TCP MSS, the packet is not fragmented; otherwise, it will be
fragmented according to the TCP MSS.
Follow these steps to configure TCP MSS of the interface:

interface-number
Configure TCP MSS of Required

tcp mss value
the interface TCP MSS is 1460 bytes by default.
Enabling the SYN Cookie Feature
As a general rule, the establishment of a TCP connection involves the following three handshakes:
1) The request originator sends a SYN message to the target server.
2) After receiving the SYN message, the target server establishes a TCP semi-connection in the
SYN_RECEIVED state, returns a SYN ACK message to the originator, and waits for a response.
3) After receiving the SYN ACK message, the originator returns an ACK message. Thus, the TCP
connection is established.
1-5
Malicious attackers may mount SYN Flood attacks during TCP connection establishment. Attackers
send SYN messages to the server to establish TCP connections, but they never make any response to
SYN ACK messages. As a result, a large amount of TCP semi-connections are established, resulting in
heavy resource consumption and making the server unable to handle services normally.
The SYN Cookie feature can prevent SYN Flood attacks. After receiving a TCP connection request, the
server directly returns a SYN ACK message, instead of establishing a TCP semi-connection. Only after
receiving an ACK message from the client can the server establish a connection, and then enter the
ESTABLISHED state. In this way, large amounts of TCP semi-connections could be avoided to protect
the server against SYN Flood attacks.
Follow these steps to enable the SYN Cookie feature:

Required
Enable the SYN Cookie feature tcp syn-cookie enable
z If the MD5 authentication is enabled, the SYN Cookie feature will not function. After the MD5
authentication is disabled, the configured SYN Cookie feature will be enabled automatically.
z With the SYN Cookie feature enabled, only the MSS, instead of the windows zoom factor and
timestamp, is negotiated during TCP connection establishment.
Enabling Protection Against Naptha Attack
Naptha attacks are similar to the SYN Flood attacks. Attackers can perform Naptha attacks by using the
six TCP connection states (CLOSING, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, LAST_ACK, and
SYN_RECEIVED), and SYN Flood attacks by using only the SYN_RECEIVED state.
Naptha attackers control a huge amount of hosts to establish TCP connections with the server, keep
these connections in the same state (any of the six), and request for no data so as to exhaust the
memory resource of the server. As a result, the server cannot process normal services.
The protection against Naptha attack reduces the risk of the server being attacked by accelerating the
aging of TCP connections in a state. After the protection against Naptha attack is enabled, the device
periodically checks the number of TCP connections in each state. If it detects that the number of TCP
connections in a state exceeds the maximum number, it will accelerate the aging of TCP connections in
such a state.
Follow these steps to enable the protection against Naptha attack:
1-6
Enable the protection Required

tcp anti-naptha enable
against Naptha attack Disabled by default.
Optional
tcp state { closing |
5 by default.
Configure the established | fin-wait-1 |
maximum of TCP fin-wait-2 | last-ack | If the maximum number of TCP
connections in a state syn-received } connections in a state is 0, the aging of
connection-number number TCP connections in this state will not be
accelerated.
Configure the TCP tcp timer check-state Optional

state check interval timer-value 30 seconds by default.
z With the protection against Naptha attack enabled, the device will periodically check and record the
number of TCP connections in each state.
z With the protection against Naptha attack enabled, if the device detects that the number of TCP
connections in a state exceeds the maximum number, the device will consider that there is a
Naptha attack and accelerate the aging of these TCP connections. The device will not stop
accelerating the aging of TCP connections until the number of TCP connection in such a state is
less than 80% of the maximum number.
Configuring TCP Optional Parameters
TCP optional parameters that can be configured include:

z synwait timer: When sending a SYN packet, TCP starts the synwait timer. If no response packets
are received within the synwait timer timeout, the TCP connection is not successfully created.
z finwait timer: When the TCP connection is in FIN_WAIT_2 state, finwait timer will be started. If no
FIN packets are received within the timer timeout, the TCP connection will be terminated. If FIN
packets are received, the TCP connection state changes to TIME_WAIT. If non-FIN packets are
received, the system restarts the timer from receiving the last non-FIN packet. The connection is
broken after the timer expires.
z Size of TCP receive/send buffer
Follow these steps to configure TCP optional parameters:

Configure TCP synwait tcp timer syn-timeout Optional

timers timeout value time-value By default, the timeout value is 75 seconds.
Configure TCP finwait tcp timer fin-timeout Optional

timers timeout value time-value By default, the timeout value is 675 seconds.
1-7
Configure the size of tcp window Optional

TCP receive/send buffer window-size By default, the buffer is 8 KB.
The actual length of the finwait timer is determined by the following formula:
Actual length of the finwait timer = (Configured length of the finwait timer 75) + configured length of the
synwait timer
Configuring ICMP to Send Error Packets

Sending error packets is a major function of ICMP protocol. In case of network abnormalities, ICMP
packets are usually sent by the network or transport layer protocols to notify corresponding devices so
as to facilitate control and management.
Advantages of sending ICMP error packets
There are three kinds of ICMP error packets: redirect packets, timeout packets and destination
unreachable packets. Their sending conditions and functions are as follows.
1) Sending ICMP redirect packets
A host may have only a default route to the default gateway in its routing table after startup. The default
gateway will send ICMP redirect packets to the source host, telling it to reselect a correct next hop to
send the subsequent packets, if the following conditions are satisfied:
z The receiving and forwarding interfaces are the same.
z The selected route has not been created or modified by ICMP redirect packet.
z The selected route is not the default route of the device.
z There is no source route option in the packet.
ICMP redirect packets function simplifies host administration and enables a host to gradually establish a
sound routing table to find out the best route.
2) Sending ICMP timeout packets
If the device received an IP packet with a timeout error, it drops the packet and sends an ICMP timeout
packet to the source.
The device will send an ICMP timeout packet under the following conditions:
z If the device finds the destination of a packet is not itself and the TTL field of the packet is 1, it will
send a TTL timeout ICMP error message.
z When the device receives the first fragment of an IP datagram whose destination is the device itself,
it starts a timer. If the timer times out before all the fragments of the datagram are received, the
device will send a reassembly timeout ICMP error packet.
3) Sending ICMP destination unreachable packets
If the device receives an IP packet with the destination unreachable, it will drop the packet and send an
ICMP destination unreachable error packet to the source.
Conditions for sending this ICMP packet:
1-8
z If neither a route nor the default route for forwarding a packet is available, the device will send a
network unreachable ICMP error packet.
z If the destination of a packet is local while the transport layer protocol of the packet is not supported
by the local device, the device sends a protocol unreachable ICMP error packet to the source.
z When receiving a packet with the destination being local and transport layer protocol being UDP, if
the packets port number does not match the running process, the device will send the source a
port unreachable ICMP error packet.
z If the source uses strict source routing" to send packets, but the intermediate device finds that the
next hop specified by the source is not directly connected, the device will send the source a source
routing failure ICMP error packet.
z When forwarding a packet, if the MTU of the sending interface is smaller than the packet but the
packet has been set Dont Fragment, the device will send the source a fragmentation needed
and Dont Fragment (DF)-set ICMP error packet.
Disadvantages of sending ICMP error packets
Although sending ICMP error packets facilitates network control and management, it still has the
following disadvantages:
z Sending a lot of ICMP packets will increase network traffic.
z If receiving a lot of malicious packets that cause it to send ICMP error packets, the devices
performance will be reduced.
z As the redirection function increases the routing table size of a host, the hosts performance will be
reduced if its routing table becomes very large.
z If a host sends malicious ICMP destination unreachable packets, end users may be affected.
To prevent such problems, you can disable the device from sending ICMP error packets.
Follow these steps to disable sending of ICMP error packets:

Enable sending of ICMP redirect Required

ip redirects enable
packets Disabled by default.
Disable sending of ICMP timeout Required

undo ip ttl-expires
packets Enabled by default.
Enable sending of ICMP destination Required

ip unreachables enable
unreachable packets Disabled by default.
The device stops sending TTL timeout ICMP error packets after sending ICMP timeout packets is
disabled. However, reassembly timeout error packets will be sent normally.
1-9
Displaying and Maintaining IP Performance
Display current TCP connection state display tcp status
Display TCP connection statistics display tcp statistics
Display UDP statistics display udp statistics
For centralized
Display display ip statistics
devices
statistics of IP
packets display ip statistics [ slot
For distributed devices
slot-number ]
For centralized
Display display icmp statistics
devices
statistics of
ICMP flows display icmp statistics [ slot
slot-number ]
Available in any
For centralized display ip socket [ socktype view
devices sock-type ] [ task-id socket-id ]
Display socket
information display ip socket [ socktype
For distributed devices sock-type ] [ task-id socket-id ]
[ slot slot-number ]
display fib [ | { begin | include |
exclude } regular-expression | acl
Display FIB forward information
acl-number | ip-prefix
ip-prefix-name ]
display fib ip-address1 [ { mask1 |

Display FIB forward information matching mask-length1 } [ ip-address2
the specified destination IP address { mask2 | mask-length2 } | longer ] |
longer ]
Display statistics about the FIB items display fib statistics
For centralized
reset ip statistics
Clear statistics devices Available in user
of IP packets reset ip statistics [ slot view
slot-number ]
Available in user
Clear statistics of TCP connections reset tcp statistics
view
Available in user
Clear statistics of UDP traffic reset udp statistics
view
1-10
Table of Contents
1 IP Unicast Policy Routing Configuration 1-1

Introduction to IP Unicast Policy Routing1-1
Policy Routing1-1
Policy Routing and Track1-1
Configuring IP Unicast Policy Routing 1-2
Defining a Policy1-2
Enabling Local Policy Routing1-4
Enabling Interface Policy Routing 1-4
Displaying and Maintaining IP Unicast Policy Routing Configuration1-4
IP Unicast Policy Routing Configuration Examples 1-5
Configuring Policy Routing Based on ACL1-5
Configuring Policy Routing Based on Packet Size1-6
i
1 IP Unicast Policy Routing Configuration
When configuring IP unicast policy routing, go to these sections for information you are interested in:
z Introduction to IP Unicast Policy Routing
z Configuring IP Unicast Policy Routing
z Displaying and Maintaining IP Unicast Policy Routing Configuration
z IP Unicast Policy Routing Configuration Examples
Introduction to IP Unicast Policy Routing

Policy Routing
Policy routing, also known as policy based routing (PBR) is a routing mechanism based on user-defined
policies. Different from the traditional destination-based routing mechanism, policy routing enables you
to use policies (based on the source address, address length, and other criteria) to route packets
flexibly.
Policy routing involves local policy routing and interface policy routing.
z Local policy routing applies to locally generated packets only.
z Interface policy routing applies to packets arriving at the interface.
In general, policy routing takes precedence over destination-based routing. That is, policy routing is
applied to the packets matching the specified policy, and other packets are forwarded through
destination-based routing. However, if policy routing has a default outgoing interface (next hop)
configured, destination-based routing takes precedence over policy routing.
Policy Routing and Track
Associated with a Track object, IP unicast policy routing can sense topology changes faster. The status
of a Track object can be Positive, Negative, or Invalid. The policy routing configuration takes effect
only when the status of the associated Track object is Positive.
For details about Track configuration information, refer to the track command in Track Commands of
the System Volume.
1-1
Configuring IP Unicast Policy Routing
Defining a Policy
A policy can consist of multiple nodes identified by node numbers. The smaller the node number is, the
higher the priority of the node is. A policy node, which consists of if-match clauses and apply clauses,
is used to route IP packets.
An if-match clause specifies a match criterion on a node while an apply clause specifies an action to
be taken on packets.
There is an AND relationship between if-match clauses on a node. That is, a packet must satisfy all the
if match clauses of the node before the action specified by the apply clause is taken.
Currently, two types of if-match clause are available: if-match packet-length and if-match acl. You
can specify only one if-match clause of each type in a policy node.
There are five types of apply clause: apply ip-precedence, apply output-interface, apply
ip-address next-hop, apply default output-interface, and apply ip-address default next-hop. You
can specify only one apply clause of each type in a policy node. The priorities of the apply clauses are
in the following descending order:
z apply ip-precedence: If configured, this clause will always be executed.
z apply output-interface and apply ip-address next-hop: The apply output-interface clause
takes precedence over the apply ip-address next-hop clause. This means that only the apply
output-interface clause will be executed when both are configured.
z apply default output-interface and apply ip-address default next-hop: The apply default
output-interface clause takes precedence over the apply ip-address default next-hop clause.
This means that only the apply default output-interface clause is executed when both are
configured. They take effective only when no outgoing interface or next hop is defined for packets,
or the defined outgoing interface or next hop is invalid and the destination address does not match
any route in the routing table.
There is an OR relationship between the nodes of a policy. That is, if a packet matches a node, it passes
the policy.
When configuring policy nodes, you need to specify the match mode as permit or deny:
z permit: Specifies the match mode of a policy node as permit. If a packet satisfies all the if-match
clauses on the policy node, the apply clause is executed. If not, the packet will go to the next policy
node.
z deny: Specifies the match mode of a policy node as deny. When a packet satisfies all the if-match
clauses on the policy node, the packet will be rejected and will not go to the next policy node.
A packet satisfying the match criteria on a node will not go to other nodes. If the packet does not satisfy
the match criteria of any node of the policy, the packet cannot pass the policy and will be forwarded
through the routing table.
You can define two next hops or two outgoing interfaces at most for a policy node. In this way, packets
are forwarded in turn through the two outgoing interfaces or two next hops to achieve load sharing.
You can associate policy routing with a Track object when configuring an outgoing interface, default
outgoing interface, next hop, or default next hop, so as to determine the availability of the next hop
dynamically. After you configure a Track object association in an apply clause, when an event occurs:
z If the status of the Track object is Positive, the apply clause can forward packets.
z If the status of the Track object is Negative or Invalid, the apply clause cannot forward packets.
1-2
Follow these steps to define a policy:

Create a policy or policy policy-based-route
node and enter policy policy-name [ deny | Required
node view permit ] node node-number
Define a packet length if-match packet-length
Optional
match criterion min-len max-len
Define an ACL match
if-match acl acl-number Optional
criterion
Set an IP precedence apply ip-precedence { type
Optional
type/value | value}
Optional
Two interfaces at most can be specified to
apply output-interface
send matching IP packets. These two
interface-type
interfaces are simultaneously active to
interface-number [ track
achieve load sharing.
Set outgoing interfaces track-entry-number ]
[ interface-type For a non-P2P outgoing interface
interface-number [ track (broadcast and NBMA interfaces) such as
track-entry-number ] ] Ethernet interface, multiple next hops are
possible, and thus packets may not be
forwarded successfully.
apply ip-address next-hop Optional

ip-address [ track
Set next hops track-entry-number ] Two next hops at most can be specified.
[ ip-address [ track These two next hops are simultaneously
track-entry-number ] ] active to achieve load sharing.
apply default
output-interface Optional
interface-type
Set default outgoing interface-number [ track Two default outgoing interfaces at most
interfaces track-entry-number ] can be specified. These two interfaces are
[ interface-type simultaneously active to achieve load
interface-number [ track sharing.
track-entry-number ] ]
apply ip-address default Optional

next-hop ip-address [ track Two default next hops at most can be
Set default next hops track-entry-number ] specified. These two next hops are
[ ip-address [ track simultaneously active to achieve load
track-entry-number ] ] sharing.
You can use the apply output-interface command to configure two outgoing interfaces or use the
apply ip-address next-hop command to configure two next hops. After that, you can specify a new
outgoing interface or a new next hop to overwrite the earlier configured outgoing interface or next hop.
If you want to modify the two outgoing interfaces or next hops, you can directly specify two interfaces or
next hops using the apply output-interface or apply ip-address next-hop command.
1-3
Enabling Local Policy Routing
Policy routing involves local policy routing and interface policy routing. In most cases, interface policy
routing is used.
Local policy routing is used to route packets generated by the local device. You can enable interface
policy routing and local policy routing respectively. Only one policy can be referenced when local policy
routing is enabled.
Follow these steps to enable the local policy routing:

Enable local policy routing ip local policy-based-route Required

based on a policy policy-name Disabled by default.
Enabling Interface Policy Routing
Interface policy routing is applied to packets arriving on an interface. Only one policy can be referenced
when policy routing is enabled on an interface.
Follow these steps to enable interface policy routing:

interface-number
Enable interface policy routing ip policy-based-route Required

based on a policy policy-name Disabled by default.
Displaying and Maintaining IP Unicast Policy Routing Configuration

Display information about local
policy routing and interface policy display ip policy-based-route
routing
display ip policy-based-route setup

Display the configuration
{ interface interface-type
information of policy routing Available in any
interface-number | local | policy-name }
view
display ip policy-based-route
Display the statistics of policy
statistics { interface interface-type
routing
interface-number | local }
Display the information of policy display policy-based-route
routing based on a specified policy [ policy-name ]
Clear the statistics of policy routing reset policy-based-route statistics Available in user
based on a specified policy [ policy-name ] view
1-4
IP Unicast Policy Routing Configuration Examples
Configuring Policy Routing Based on ACL
As shown in Figure 1-1, define the policy aaa for policy routing so that TCP packets arriving on Ethernet
1/0 are forwarded via Serial 2/0 and other packets are forwarded through the routing table.
z Node 5 defines packets matching ACL 3101 are sent to Serial 2/0.
z Node 10 defines packets matching ACL 3102 do not go through policy routing.
Network diagram
Figure 1-1 Network diagram for policy routing
# If the router supports firewall, set the filtering mode to deny.

[Router] firewall default deny
# Define ACLs.
[Router-acl-adv-3101] rule permit tcp
[Router-acl-adv-3101] quit
[Router-acl-adv-3102] rule permit ip
[Router-acl-adv-3102] quit
# Define Node 5 of policy aaa so that TCP packets are forwarded via Serial 2/0.
[Router] policy-based-route aaa permit node 5
[Router-pbr-aaa-5] if-match acl 3101
[Router-pbr-aaa-5] apply output-interface serial 2/0
[Router-pbr-aaa-5] quit
1-5
# Define Node 10 of policy aaa so that policy routing will not be applied to packets matching ACL 3102
and these packets will be forwarded through the routing table.
[Router] policy-based-route aaa deny node 10
[Router-pbr-aaa-10] if-match acl 3102
[Router-pbr-aaa-10] quit
# Apply the policy aaa to Ethernet 1/0.

[Router-Ethernet1/0] ip policy-based-route aaa
Configuring Policy Routing Based on Packet Size
Policy routing based on policy lab1 is enabled on Ethernet 1/0 of Router A. Packets with a size of 64 to
100 bytes are forwarded to 150.1.1.2/24, while packets with a size of 101 to 1,000 bytes are forwarded
to 151.1.1.2/24. All other packets are forwarded through the routing table.
Network diagram
Figure 1-2 Network diagram for policy routing based on packet size
z Configuration on Router A.
# Configure RIP.
[RouterA] rip
# Apply the policy lab1 to Ethernet 1/0.

[RouterA-Ethernet1/0] ip policy-based-route lab1
# Forward IP packets with a size of 64 to 100 bytes to the next hop 150.1.1.2 and those with a size of
101 to 1,000 bytes to the next hop 151.1.1.2.
1-6
[RouterA] policy-based-route lab1 permit node 10
[RouterA-pbr-lab1-10] if-match packet-length 64 100
[RouterA-pbr-lab1-10] apply ip-address next-hop 150.1.1.2
[RouterA-pbr-lab1-10] quit
[RouterA] policy-based-route lab1 permit node 20
[RouterA-pbr-lab1-20] if-match packet-length 101 1000
[RouterA-pbr-lab1-20] apply ip-address next-hop 151.1.1.2
z Configuration on Router B
# Configure RIP.
[RouterB] rip
1-7
Table of Contents
1 UDP Helper Configuration 1-1

Introduction to UDP Helper 1-1
Configuring UDP Helper 1-1
Displaying and Maintaining UDP Helper1-2
UDP Helper Configuration Examples1-3
UDP Helper Configuration Example I (on a Router) 1-3
UDP Helper Configuration Example I (on a Switch)1-3
UDP Helper Configuration Example II (on a Router) 1-4
UDP Helper Configuration Example II (on a Switch)1-5
i
1 UDP Helper Configuration
When configuring UDP Helper, go to these sections for information you are interested in:
z Introduction to UDP Helper
z Configuring UDP Helper
z Displaying and Maintaining UDP Helper
z UDP Helper Configuration Examples
UDP Helper can be currently configured on VLAN interfaces and Layer 3 Ethernet interfaces (including
subinterfaces) only.
Introduction to UDP Helper

Sometimes, a host needs to forward broadcasts to obtain network configuration information or request
the names of other devices on the network. However, if the server or the device to be requested is
located in another broadcast domain, the host cannot obtain such information through broadcast.
To solve this problem, the device provides the UDP Helper function to relay specified UDP packets. In
other words, UDP Helper functions as a relay agent that converts UDP broadcast packets into unicast
packets and forwards them to a specified destination server.
With UDP Helper enabled, the device decides whether to forward a received UDP broadcast packet
according to the UDP destination port number of the packet.
z If the destination port number of the packet matches the one pre-configured on the device, the
device modifies the destination IP address in the IP header, and then sends the packet to the
specified destination server.
z If not, the device sends the packet to the upper layer protocol for processing.
Configuring UDP Helper

Follow these steps to configure UDP Helper:
1-1
Required
Enable UDP Helper udp-helper enable
Enable the forwarding of udp-helper port { port-number Required

packets with the specified UDP | dns | netbios-ds | netbios-ns No UDP port number is
destination port number(s) | tacacs | tftp | time } specified by default.
interface-number
Specify the destination server Required

to which UDP packets are to be udp-helper server ip-address No destination server is
forwarded specified by default.
z On the devices supporting the directed broadcast suppression function, the receiving of directed
broadcasts to a directly connected network is disabled by default. As a result, UDP Helper is
available only when the ip forward-broadcast command is configured in system view. For details
about the ip forward-broadcast command, refer to IP Performance Configuration in the IP
Services Volume.
z The UDP Helper enabled device cannot forward DHCP broadcast packets. That is to say, the UDP
port number cannot be set to 67 or 68.
z For the dns, netbios-ds, netbios-ns, tacacs, tftp, and time keywords, you can specify port
numbers or the corresponding parameters. For example, udp-helper port 53 and udp-helper port
dns specify the same UDP port number.
z The configuration of all UDP ports is removed if you disable UDP Helper.
z You can configure up to 256 UDP port numbers to enable the forwarding of packets with these
UDP port numbers.
z You can configure up to 20 destination servers on an interface.
Displaying and Maintaining UDP Helper

display udp-helper server
Displays the information of
forwarded UDP packets
interface-number ]
Clear statistics about packets
reset udp-helper packet Available in user view
forwarded
1-2
UDP Helper Configuration Examples
UDP Helper Configuration Example I (on a Router)
On Router A, configure UDP helper to forward broadcast packets (with UDP destination port number 55
and destination IP address 255.255.255.255 or 10.110.255.255 to the destination server 10.2.1.1/16.
Network diagram
Figure 1-1 Network diagram for UDP Helper configuration I (on a router)
The following configuration assumes that a route from Router A to the network segment 10.2.0.0/16 is
available.
# Enable UDP Helper.

[RouterA] udp-helper enable
# Enable the forwarding of broadcast packets with the UDP destination port 55.
[RouterA] udp-helper port 55
# Specify the destination server 10.2.1.1 on Ethernet 1/0.

[RouterA-Ethernet1/0] udp-helper server 10.2.1.1
UDP Helper Configuration Example I (on a Switch)
On Switch A, configure UDP helper to forward broadcast packets (with UDP destination port number 55
and destination IP address 255.255.255.255 or 10.110.255.255 to the destination server 10.2.1.1/16.
1-3
Network diagram
Figure 1-2 Network diagram for UDP Helper configuration I (on a switch)
The following configuration assumes that a route from Switch A to the network segment 10.2.0.0/16 is
available.
# Enable Switch A to receive directed broadcasts.

[SwitchA] ip forward-broadcast

[SwitchA] udp-helper enable
# Enable the forwarding broadcast packets with the UDP destination port 55.
[SwitchA] udp-helper port 55
# Specify the destination server 10.2.1.1 on VLAN-interface 1.

[SwitchA-Vlan-interface1] udp-helper server 10.2.1.1
UDP Helper Configuration Example II (on a Router)
On Router C, configure UDP helper to forward broadcast packets (with UDP destination port number 55
and destination IP address 10.2.255.255 to the destination server 10.2.1.1/16.
1-4
Network diagram
Figure 1-3 Network diagram for UDP Helper configuration II (on a router)
The following configuration assumes that a route from Router A to the network segment 10.2.0.0/16 is
available.
1) Configure interface IP addresses for Router A, Router B, and Router C (omitted)

[RouterC] udp-helper enable
[RouterC] udp-helper port 55
# Specify the destination server 10.2.1.1 on Ethernet 1/1.

[RouterC-Ethernet1/1] udp-helper server 10.2.1.1
UDP Helper Configuration Example II (on a Switch)
On Switch C, configure UDP helper to forward broadcast packets (with UDP destination port number 55
and destination IP address 10.2.255.255 to the destination server 10.2.1.1/16.
1-5
Network diagram
Figure 1-4 Network diagram for UDP Helper configuration II (on a switch)
The following configuration assumes that a route from Switch A to the network segment 10.2.0.0/16 is
available.
1) Create VLANs. Add the interfaces to the corresponding VLANs, and configure IP addresses for the
VLAN interfaces on Switch A, Switch B, and Switch C (omitted)
2) Configure Switch C.
# Enable Switch C to receive directed broadcasts.
[SwitchC] ip forward-broadcast

[SwitchC] udp-helper enable
[SwitchC] udp-helper port 55
# Specify the destination server 10.2.1.1 on VLAN-interface 2.

[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] udp-helper server 10.2.1.1
1-6
Table of Contents
1 URPF Configuration 1-1

URPF Overview 1-1
What is URPF1-1
How URPF Works 1-2
Configuring URPF 1-2
i
1 URPF Configuration
The term router in this document refers to a router in a generic sense or a Layer 3 switch.
When configuring URPF, go to these sections for information you are interested in:
z URPF Overview
z Configuring URPF
URPF Overview
What is URPF
Unicast Reverse Path Forwarding (URPF) protects a network against source address spoofing attacks.
Attackers launch attacks by creating a series of packets with forged source addresses. For applications
using IP-address-based authentication, this type of attacks allows unauthorized users to access the
system in the name of authorized users, or even access the system as the administrator. Even if the
attackers cannot receive any response packets, the attacks are still disruptive to the attacked target.
Figure 1-1 Attack based on source address spoofing
As shown in Figure 1-1, Router A originates a request to the server (Router B) by sending a packet with
a forged source IP address of 2.2.2.1/8, and Router B sends a packet to Router C at 2.2.2.1/8 in
response to the request. Consequently, this packet attacks both Router B and Router C.
URPF can prevent source address spoofing attacks.
1-1
How URPF Works
URPF provides two check modes: strict and loose. In addition, it supports ACL check and default route
check.
URPF works as follows:
1) If the source address of an incoming packet is found in the FIB table:
z In strict approach, URPF does a reverse route lookup for routes to the source address of the packet.
If at least one outgoing interface of such a route matches the receiving interface, the packet passes
the check. Otherwise, the packet is dropped.
z In loose approach, the packet is forwarded normally.
2) If the source address is not found in the FIB table, URPF makes a decision based on the default
route and the allow-default-route keyword.
z If a default route is available but the allow-default-route keyword is not configured, the packet is
rejected no matter which check approach is taken.
z If both a default route and the allow-default-route keyword are configured, URPFs decision
depends on the check approach. In strict approach, URPF lets the packet pass if the outgoing
interface of the default route is the receiving interface, and otherwise rejects it. In loose approach,
URPF lets the packet pass directly.
3) A rejected packet will be filtered by an ACL, if specified. If the packet passes the ACL, it is
forwarded as normal; otherwise, it is discarded.
Configuring URPF
Follow these steps to configure URPF:

ip urpf { loose | strict } Required

Enable URPF check
[ allow-default-route ] [ acl acl-number ] Disabled by default.
1-2
Table of Contents
1 Fast Forwarding Configuration 1-1

Introduction to Fast Forwarding 1-1
Configuring Fast Forwarding1-2
Displaying and Maintaining Fast Forwarding 1-2
Fast Forwarding Configuration Example1-2
i
1 Fast Forwarding Configuration
When configuring fast forwarding, go to these sections for the information you are interested in:
z Introduction to Fast Forwarding
z Configuring Fast Forwarding
z Displaying and Maintaining Fast Forwarding
z Fast Forwarding Configuration Example
The term router in this document refers to a router in a generic sense or an Ethernet switch running
routing protocols.
Introduction to Fast Forwarding

Forwarding efficiency is a key index of the performance of a router. In an ordinary forwarding process,
when a router receives a packet, it copies the packet from the interface memory to the CPU. Then, the
CPU searches the routing table for routes matching the destination address to fix the best route and
encapsulate the packet into a proper link layer frame. At last, the link layer frame is copied to the output
queue through direct memory access (DMA) for forwarding.
Fast forwarding employs cache and the data-flow-based technology to handle packets. The data on the
Internet is generally based on data flow, which is a specific application between two hosts, for example,
the operation of using FTP to transfer a file. A data flow is usually described by five tuples (source IP
address, source port number, destination IP address, destination port number, and protocol number).
When the first packet is forwarded by means of searching the routing table, corresponding routing
information is generated in the cache so that the subsequent packets in the flow can be forwarded by
means of searching the cache directly. Fast forwarding reduces route lookup time and enhances
forwarding throughput of IP packets because the routing table is already optimized in the cache and
therefore the searching speed is especially high.
The performance of fast forwarding is sometimes affected by some attributes, for example, packet
queue management and packet header compression. Although fast forwarding can process
segmented IP packets, it does not support re-segmentation of IP packets.
1-1
Currently, fast forwarding is supported:
z On all kinds of high-speed interfaces (including sub-interfaces), such as Ethernet, synchronous
PPP, Frame Relay and HDLC interfaces.
z On PPP MP links.
z On IPHC compression or VJ compression enabled PPP links.
z When packet filtering is configured.
z When Application Specific Packet Filter (ASPF) is configured.
z When Network Address Translation (NAT) is configured.
z When Generic Routing Encapsulation (GRE) is configured.
Configuring Fast Forwarding

Follow these steps to configure fast forwarding:

interface-number
Optional
Enable fast forwarding on the
ip fast-forwarding [ inbound | By default, fast forwarding is
interface in the inbound or
outbound ] enabled in the inbound and
outbound direction
outbound directions.
Displaying and Maintaining Fast Forwarding

Display all the information in
the fast forwarding cache or the display ip fast-forwarding
fast forwarding information of a cache [ ip-address ]
specified IP address
Clear the information in the reset ip fast-forwarding
fast-forwarding cache cache
Fast Forwarding Configuration Example

View the fast forwarding table on Router B.
1-2
Network diagram
Figure 1-1 Network diagram for fast forwarding configuration
# Configure the IP address of interface Ethernet 1/1.
# Configure a static route.

[RouterA] ip route-static 22.1.1.0 255.0.0.0 11.1.1.2
# Configure the IP address of interface Serial 2/1.
[RouterC] interface serial2/1

[RouterC] ip route-static 11.1.1.0 255.0.0.0 22.1.1.1
# Configure IP addresses of interface Ethernet 1/1 and Serial 2/1.
[RouterB] interface serial2/1
# Display the fast forwarding table on Router B. The following result is displayed, indicating no fast
forwarding entry is created.
[RouterB] display ip fast-forwarding cashe
# Ping the IP address of Serial 2/1 of Router C on Router A, and reply packets can be received.
1-3

0.00% packet loss
# Display the fast forwarding table on Router B. The following result is displayed, indicating fast
forwarding entries are created.
<RouterB> display ip fast-forwarding cashe
Fast-Forwarding cache: total 3 items
Index SIP SPort DIP DPort Pro Input_If Output_If Flg
423 :0 22.1.1.2 0 11.1.1.1 0 1 S2/1 Eth1/1 7
507 :0 11.1.1.1 8 22.1.1.2 0 1 Eth1/1 S2/1 7
1-4
Table of Contents
1 IPv6 Basics Configuration 1-1

IPv6 Overview 1-1
IPv6 Features 1-2
Introduction to IPv6 Address 1-3
Introduction to IPv6 Neighbor Discovery Protocol1-6
IPv6 PMTU Discovery 1-8
Introduction to IPv6 DNS 1-9
IPv6 Basics Configuration Task List 1-10
Configuring Basic IPv6 Functions 1-10
Enabling IPv6 1-10
Configuring an IPv6 Unicast Address1-10
Configuring IPv6 NDP 1-12
Configuring a Static Neighbor Entry 1-12
Configuring the Maximum Number of Neighbors Dynamically Learned 1-13
Configuring Parameters Related to RA Messages 1-13
Configuring the Maximum Number of Attempts to Send an NS Message for DAD 1-16
Configuring PMTU Discovery1-16
Configuring the Interface MTU 1-16
Configuring a Static PMTU for a Specified IPv6 Address 1-16
Configuring the Aging Time for Dynamic PMTUs 1-17
Configuring IPv6 TCP Properties1-17
Configuring IPv6 FIB-Based Forwarding 1-18
Configuring ICMPv6 Packet Sending1-18
Configuring the Maximum ICMPv6 Error Packets Sent in an Interval 1-18
Enable Sending of Multicast Echo Replies1-19
Enabling Sending of ICMPv6 Time Exceeded Packets 1-19
Configuring IPv6 DNS 1-20
Configuring Static IPv6 Domain Name Resolution1-20
Configuring Dynamic IPv6 Domain Name Resolution1-20
Displaying and Maintaining IPv6 Basics Configuration1-21
IPv6 Configuration Example (on Routers) 1-23
IPv6 Configuration Example (on Switches) 1-27
Troubleshooting IPv6 Basics Configuration 1-32
i
MSR
Feature MSR 20 MSR 30 MSR 50
20-1X
Configuring IPv6 and
link-layer addresses for Yes Yes Yes Yes
Layer 3 interfaces
Configuring IPv6 and
link-layer addresses for Yes Yes Yes Yes
ports in a VLAN
1 IPv6 Basics Configuration
When configuring IPv6 basics, go to these sections for information you are interested in:
z IPv6 Overview
z IPv6 Basics Configuration Task List
z Configuring Basic IPv6 Functions
z Configuring IPv6 NDP
z Configuring PMTU Discovery
z Configuring IPv6 TCP Properties
z Configuring IPv6 FIB-Based Forwarding
z Configuring ICMPv6 Packet Sending
z Configuring IPv6 DNS
z Displaying and Maintaining IPv6 Basics Configuration
z IPv6 Configuration Example (on Routers)
z Troubleshooting IPv6 Basics Configuration
IPv6 Overview
Internet Protocol Version 6 (IPv6), also called IP next generation (IPng), was designed by the Internet
Engineering Task Force (IETF) as the successor to Internet Protocol Version 4 (IPv4). The significant
difference between IPv6 and IPv4 is that IPv6 increases the IP address size from 32 bits to 128 bits.
This section covers the following:
z IPv6 Features
z Introduction to IPv6 Address
1-1
z Introduction to IPv6 Neighbor Discovery Protocol
z IPv6 PMTU Discovery
z Introduction to IPv6 DNS
IPv6 Features
Header format simplification
IPv6 cuts down some IPv4 header fields or move them to the IPv6 extension headers to reduce the
length of the basic IPv6 header. IPv6 uses the basic header with a fixed length, thus making IPv6 packet
handling simple and improving the forwarding efficiency. Although the IPv6 address size is four times
the IPv4 address size, the basic IPv6 header size is 40 bytes and is only twice the IPv4 header size
(excluding the Options field).
Figure 1-1 Comparison between IPv4 packet header format and basic IPv6 packet header format
Adequate address space
The source and destination IPv6 addresses are both 128 bits (16 bytes) long. IPv6 can provide 3.4 x
1038 addresses to fully meet the requirements of hierarchical address division as well as allocation of
public and private addresses.
Hierarchical address structure
IPv6 adopts the hierarchical address structure to quicken route search and reduce the system sources
occupied by the IPv6 routing table by route aggregation.
Automatic address configuration
To simplify host configuration, IPv6 supports stateful and stateless address configuration.
z Stateful address configuration means that a host acquires an IPv6 address and related information
from a server (for example, a DHCP server).
z Stateless address configuration means that a host automatically generates an IPv6 address and
related information on the basis of its own link-layer address and the prefix information advertised
by a router.
1-2
In addition, a host can generate a link-local address on the basis of its own link-layer address and the
default prefix (FE80::/10) to communicate with other hosts on the same link.
Built-in security
IPv6 uses IPSec as its standard extension header to provide end-to-end security. This feature provides
a standard for network security solutions and enhances the interoperability between different IPv6
applications.
QoS support
The Flow Label field in the IPv6 header allows the device to label packets of a flow and provide special
handling for these packets.
Enhanced neighbor discovery mechanism
The IPv6 neighbor discovery protocol is implemented through a group of Internet Control Message
Protocol Version 6 (ICMPv6) messages that manage the information exchange between neighbor
nodes on the same link. The group of ICMPv6 messages takes the place of Address Resolution
Protocol (ARP) messages, Internet Control Message Protocol version 4 (ICMPv4) router discovery
messages, and ICMPv4 redirection messages and provides a series of other functions.
Flexible extension headers
IPv6 cancels the Options field in the IPv4 header but introduces multiple extension headers to provide
scalability while improving efficiency. The Options field contains 40 bytes at most, while the size of IPv6
extension headers is restricted to the maximum size of IPv6 packets.
Introduction to IPv6 Address
IPv6 address format
An IPv6 address is represented as a set of 16-bit hexadecimals, separated by colons. An IPv6 address
is divided into eight groups, and the 16 bits of each group are represented by four hexadecimal
numbers, for example, 2001:0000:130F:0000:0000:09C0:876A:130B.
To simplify the representation of IPv6 addresses, zeros in IPv6 addresses can be handled as follows:
z Leading zeros in each group can be removed. For example, the above-mentioned address can be
represented in a shorter format as 2001:0:130F:0:0:9C0:876A:130B.
z If an IPv6 address contains two or more consecutive groups of zeros, they can be replaced by a
double-colon ::. For example, the above-mentioned address can be represented in the shortest
format as 2001:0:130F::9C0:876A:130B.
A double-colon can be used only once in an IPv6 address. Otherwise, the device is unable to determine
how many zeros that double-colons represent when converting them to zeros to restore a 128-bit IPv6
address.
An IPv6 address consists of two parts: address prefix and interface ID. The address prefix and the
interface ID are respectively equivalent to the network ID and the host ID in an IPv4 address.
1-3
An IPv6 address prefix is written in IPv6-address/prefix-length notation, where the IPv6-address is in
any of the notations above mentioned, and prefix-length is a decimal number indicating how many bits
from the left-most of an IPv6 address is the address prefix.
IPv6 address classification
IPv6 addresses fall into three types: unicast address, multicast address, and anycast address.
z Unicast address: An identifier for a single interface, similar to an IPv4 unicast address. A packet
sent to a unicast address is delivered to the interface identified by that address.
z Multicast address: An identifier for a set of interfaces (typically belonging to different nodes), similar
to an IPv4 multicast address. A packet sent to a multicast address is delivered to all interfaces
identified by that address.
z Anycast address: An identifier for a set of interfaces (typically belonging to different nodes). A
packet sent to an anycast address is delivered to one of the interfaces identified by that address
(the target interface is nearest to the source, according to a routing protocols measure of
distance).
There are no broadcast addresses in IPv6. Their function is replaced by multicast addresses.
The type of an IPv6 address is designated by the first several bits called format prefix. Table 1-1 lists the
mappings between address types and format prefixes.
Table 1-1 Mappings between address types and format prefixes
Type Format prefix (binary) IPv6 prefix ID

Unassigned address 00...0 (128 bits) ::/128
Loopback address 00...1 (128 bits) ::1/128
Unicast Link-local address 1111111010 FE80::/10
address
Site-local address 1111111011 FEC0::/10
Global unicast
other forms
address
Multicast address 11111111 FF00::/8
Anycast addresses are taken from unicast address space and
Anycast address
are not syntactically distinguishable from unicast addresses.
Unicast address
There are several types of unicast addresses, including aggregatable global unicast address, link-local
address, and site-local address.
z The aggregatable global unicast addresses, equivalent to public IPv4 addresses, are provided for
network service providers. This type of address allows efficient prefix aggregation to restrict the
number of global routing entries.
1-4
z The link-local addresses are used for communication between link-local nodes in neighbor
discovery and stateless autoconfiguration. Packets with link-local source or destination addresses
are not forwarded to other links.
z IPv6 unicast site-local addresses are similar to private IPv4 addresses. Packets with site-local
source or destination addresses are not forwarded out of the local site (a private network).
z Loopback address: The unicast address 0:0:0:0:0:0:0:1 (represented in the shortest format as ::1)
is called the loopback address and may never be assigned to any physical interface. Like the
loopback address in IPv4, it may be used by a node to send an IPv6 packet to itself.
z Unassigned address: The unicast address ":: is called the unassigned address and may not be
assigned to any node. Before acquiring a valid IPv6 address, a node may fill this address in the
source address field of an IPv6 packet. It cannot be used as a destination IPv6 address.
Multicast address
IPv6 multicast addresses listed in Table 1-2 are reserved for special purpose.
Table 1-2 Reserved IPv6 multicast addresses
Address Application
FF01::1 Node-local scope all nodes multicast address
FF02::1 Link-local scope all nodes multicast address
FF01::2 Node-local scope all routers multicast address

FF02::2 Link-local scope all routers multicast address
FF05::2 Site-local scope all routers multicast address
Besides, there is another type of multicast address: solicited-node address. A solicited-node multicast
address is used to acquire the link-layer address of a neighbor node on the same link, and is also used
for duplicate address detection (DAD). Each IPv6 unicast or anycast address has a corresponding
solicited-node address. The format of a solicited-node multicast address is as follows:
FF02:0:0:0:0:1:FFXX:XXXX
Where, FF02:0:0:0:0:1:FF is permanent and consists of 104 bits, and XX:XXXX is the last 24 bits of an
IPv6 unicast or anycast address.
Interface identifier in IEEE EUI-64 format
An interface identifier is used to identify a unique interface on a link and is 64 bits long. An interface
identifier in IEEE EUI-64 format is derived from the link-layer address (MAC) of an interface. A MAC
address is 48 bits long and therefore, to get the interface identifier, the hexadecimal number FFFE
needs to be inserted in the middle of the MAC address (behind the 24 high-order bits). To ensure the
interface identifier obtained from a MAC address is unique, it is necessary to set the universal/local (U/L)
bit (the seventh high-order bit) to 1. Thus, an interface identifier in IEEE EUI-64 format is obtained.
1-5
Figure 1-2 Convert a MAC address into an EUI-64 interface identifier
Introduction to IPv6 Neighbor Discovery Protocol
The IPv6 Neighbor Discovery Protocol (NDP) uses five types of ICMPv6 messages to implement the
following functions:
z Address resolution
z Neighbor reachability detection
z Duplicate address detection
z Router/prefix discovery and address autoconfiguration
z Redirection
Table 1-3 lists the types and functions of ICMPv6 messages used by the NDP.
Table 1-3 Types and functions of ICMPv6 messages
ICMPv6 message Number Function

Used to acquire the link-layer address of a neighbor
Neighbor solicitation (NS)
135 Used to verify whether the neighbor is reachable
message
Used to perform a duplicate address detection
Used to respond to an NS message
Neighbor advertisement When the link layer changes, the local node initiates an
136
(NA) message NA message to notify neighbor nodes of the node
information change.
After started, a node sends an RS message to request
Router solicitation (RS)
133 the router for an address prefix and other configuration
message
information for the purpose of autoconfiguration.
Used to respond to an RS message
Router advertisement With the RA message suppression disabled, the router
134
(RA) message regularly sends an RA message containing information
such as prefix information options and flag bits.
When a certain condition is satisfied, the default
gateway sends a redirect message to the source host
Redirect message 137
so that the host can reselect a correct next hop router
to forward packets.
The NDP mainly provides the following functions:
1-6
Address resolution
Similar to the ARP function in IPv4, a node acquires the link-layer addresses of neighbor nodes on the
same link through NS and NA messages. Figure 1-3 shows how node A acquires the link-layer address
of node B.
Figure 1-3 Address resolution
The address resolution procedure is as follows:

1) Node A multicasts an NS message. The source address of the NS message is the IPv6 address of
the sending interface of node A and the destination address is the solicited-node multicast address
of node B. The NS message contains the link-layer address of node A.
2) After receiving the NS message, node B judges whether the destination address of the packet is its
solicited-node multicast address. If yes, node B learns the link-layer address of node A, and then
unicasts an NA message containing its link-layer address.
3) Node A acquires the link-layer address of node B from the NA message.
Neighbor reachability detection
After node A acquires the link-layer address of its neighbor node B, node A can verify whether node B is
reachable according to NS and NA messages.
1) Node A sends an NS message whose destination address is the IPv6 address of node B.
2) If node A receives an NA message from node B, node A considers that node B is reachable.
Otherwise, node B is unreachable.
Duplicate address detection
After node A acquires an IPv6 address, it will perform duplicate address detection (DAD) to determine
whether the address is being used by any other node (similar to the gratuitous ARP function of IPv4).
DAD is accomplished through NS and NA messages. Figure 1-4 shows the DAD procedure.
Figure 1-4 Duplicate address detection
The DAD procedure is as follows:
1-7
1) Node A sends an NS message whose source address is the unassigned address :: and destination
address is the corresponding solicited-node multicast address of the IPv6 address to be detected.
The NS message contains the IPv6 address.
2) If node B uses this IPv6 address, node B returns an NA message. The NA message contains the
IPv6 address of node B.
3) Node A learns that the IPv6 address is being used by node B after receiving the NA message from
node B. Otherwise, node B is not using the IPv6 address and node A can use it.
Router/prefix discovery and address autoconfiguration
Router/prefix discovery means that a node locates the neighboring routers, and learns the prefix of the
network where the host is located, and other configuration parameters from the received RA message.
Stateless address autoconfiguration means that a node automatically generates an IPv6 address
according to the information obtained through router/prefix discovery.
The router/prefix discovery is implemented through RS and RA messages. The router/prefix discovery
1) After started, a node sends an RS message to request the router for the address prefix and other
configuration information for the purpose of autoconfiguration.
2) The router returns an RA message containing information such as prefix information option. (The
router also regularly sends an RA message.)
3) The node automatically generates an IPv6 address and other information for its interface according
to the address prefix and other configuration parameters in the RA message.
z In addition to an address prefix, the prefix information option also contains the preferred lifetime
and valid lifetime of the address prefix. After receiving a periodic RA message, the node updates
the preferred lifetime and valid lifetime of the address prefix accordingly.
z An automatically generated address is applicable within the valid lifetime and is removed when the
valid lifetime times out.
Redirection
When a host is started, its routing table may contain only the default route to the gateway. When certain
conditions are satisfied, the gateway sends an ICMPv6 redirect message to the source host so that the
host can select a better next hop to forward packets (similar to the ICMP redirection function in IPv4).
The gateway sends an IPv6 ICMP redirect message when the following conditions are satisfied:
z The receiving interface is the forwarding interface.
z The selected route itself is not created or modified by an IPv6 ICMP redirect message.
z The selected route is not the default route.
z The forwarded IPv6 packet does not contain any routing extension header.
IPv6 PMTU Discovery
The links that a packet passes from the source to the destination may have different MTUs. In IPv6,
when the packet size exceeds the path MTU ( the minimum MTU of all links), the packet will be
1-8
fragmented at the source end so as to reduce the processing pressure of forwarding devices and utilize
network resources properly.
The path MTU (PMTU) discovery mechanism is to find the minimum MTU of all links in the path from the
source to the destination. Figure 1-5 shows the working procedure of PMTU discovery.
Figure 1-5 Working procedure of PMTU discovery
The working procedure of the PMTU discovery is as follows:

1) The source host uses its MTU to send packets to the destination host.
2) If the MTU supported by a forwarding interface is smaller than the packet size, the forwarding
device will discard the packet and return an ICMPv6 error packet containing the interface MTU to
the source host.
3) After receiving the ICMPv6 error packet, the source host uses the returned MTU to send packets to
the destination.
4) Step 2 to step 3 are repeated until the destination host receives the packet. In this way, the
minimum MTU of all links in the path from the source host to the destination host is determined.
Introduction to IPv6 DNS
IPv6 Domain Name System (DNS) is responsible for translating domain names into IPv6 addresses,
instead of IPv4 addresses.
Like IPv4 DNS, IPv6 DNS also involves static domain name resolution and dynamic domain name
resolution. The function and implementation of these two types of domain name resolution are the same
as those of IPv4 DNS. For details, refer to DNS Configuration in the IP Services Volume.
Usually, the DNS server connecting IPv4 and IPv6 networks not only contains A records (IPv4
addresses), but also AAAA records (IPv6 addresses). The DNS server can convert domain names into
IPv4 addresses or IPv6 addresses. In this way, the DNS server implements the functions of both IPv6
DNS and IPv4 DNS.
Protocols and standards related to IPv6 include:

z RFC 1881: IPv6 Address Allocation Management
z RFC 1887: An Architecture for IPv6 Unicast Address Allocation
z RFC 1981: Path MTU Discovery for IP version 6
z RFC 2375: IPv6 Multicast Address Assignments
z RFC 2460: Internet Protocol, Version 6 (IPv6) Specification.
z RFC 2461: Neighbor Discovery for IP Version 6 (IPv6)
1-9
z RFC 2462: IPv6 Stateless Address Autoconfiguration
z RFC 2463: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification
z RFC 2464: Transmission of IPv6 Packets over Ethernet Networks
z RFC 2526: Reserved IPv6 Subnet Anycast Addresses
z RFC 3307: Allocation Guidelines for IPv6 Multicast Addresses
z RFC 3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
z RFC 3596: DNS Extensions to Support IP Version 6
IPv6 Basics Configuration Task List

Complete the following tasks to perform IPv6 basics configuration:
Task Remarks
Configuring Basic IPv6 Functions Required
Configuring IPv6 NDP Optional
Configuring PMTU Discovery Optional
Configuring IPv6 TCP Properties Optional

Configuring IPv6 FIB-Based Forwarding Optional
Configuring ICMPv6 Packet Sending Optional
Configuring IPv6 DNS Optional
Configuring Basic IPv6 Functions

Enabling IPv6
Before performing IPv6-related configurations, you need to Enable IPv6. Otherwise, an interface cannot
forward IPv6 packets even if it has an IPv6 address configured.
Follow these steps to Enable IPv6:

Required
Enable IPv6 ipv6
Configuring an IPv6 Unicast Address
IPv6 site-local addresses and aggregatable global unicast addresses can be configured in the following
ways:
z EUI-64 format: When the EUI-64 format is adopted, the IPv6 address prefix of an interface is the
configured prefix, and the interface identifier is derived from the link-layer address of the interface.
z Manual configuration: IPv6 site-local addresses or aggregatable global unicast addresses are
configured manually.
z Stateless address autoconfiguration: IPv6 global unicast addresses are generated automatically
based on the address prefix information contained in the RA message.
1-10
IPv6 link-local addresses can be configured in either of the following ways:
z Automatic generation: The device automatically generates a link-local address for an interface
according to the link-local address prefix (FE80::/10) and the link-layer address of the interface.
z Manual assignment: IPv6 link-local addresses can be assigned manually.
Follow these steps to configure an IPv6 unicast address:

interface-number
ipv6 address { ipv6-address
Manually assign an
Configure prefix-length |
IPv6 address
an IPv6 ipv6-address/prefix-length } One of the three commands is
aggregatabl required.
Adopt the EUI-64 ipv6 address
e global By default, no site-local
format to form an ipv6-address/prefix-length
unicast address or aggregatable global
IPv6 address eui-64
address or unicast address is configured
site-local Adopt stateless for an interface.
address address ipv6 address auto
autoconfiguration
Automatically Optional
generate a ipv6 address auto By default, after an IPv6
Configure link-local address link-local site-local address or
an IPv6 for the interface aggregatable global unicast
link-local address is configured for an
address Manually assign a interface, a link-local address
ipv6 address ipv6-address
link-local address will be generated
link-local
for the interface automatically.
1-11
z Support for the ipv6 address auto command depends on the device model.
z After an IPv6 site-local address or aggregatable global unicast address is configured for an
interface, a link-local address is generated automatically. The automatically generated link-local
address is the same as the one generated by using the ipv6 address auto link-local command. If
a link-local address is manually assigned to an interface, this manual link-local address takes effect.
If the manually assigned link-local address is removed, the automatically generated link-local
address takes effect.
z Manual assignment takes precedence over automatic generation. That is, if you first adopt
automatic generation and then manual assignment, the manually assigned link-local address will
overwrite the automatically generated one. If you first adopt manual assignment and then
automatic generation, the automatically generated link-local address will not take effect and the
link-local address of an interface is still the manually assigned one. If you delete the manually
assigned address, the automatically generated link-local address is validated.
z The undo ipv6 address auto link-local command can be used only after the ipv6 address auto
link-local command is executed. However, if an IPv6 site-local address or aggregatable global
unicast address is already configured for an interface, the interface still has a link-local address
because the system automatically generates one for the interface. If no IPv6 site-local address or
aggregatable global unicast address is configured, the interface has no link-local address.
z The manually configured global unicast address takes precedence over the one automatically
generated. If a global unicast address has been automatically generated on an interface when you
manually configure another one with the same address prefix, the latter overwrites the previous
one. After that, the overwritten automatic global unicast address will not be restored even if the
manual one is removed. Instead, a new global unicast address will be automatically generated
again based on the address prefix information in the RA message that the interface receives for the
next time.
z Executing the undo ipv6 address auto command removes all the automatically-generated global
unicast addresses from an interface. The automatically generated link-local address on the
interface can be removed only when no IPv6 site-local address or global unicast address exists,
and the ipv6 address auto link-local command is not configured.
Configuring IPv6 NDP

Configuring a Static Neighbor Entry
The IPv6 address of a neighbor node can be resolved into a link-layer address dynamically through NS
and NA messages or through a manually configured static neighbor entry.
The device uniquely identifies a static neighbor entry according to the neighbor IPv6 address and the
local Layer 3 interface ID. Currently, there are two configuration methods:
z Associate a neighbor IPv6 address and link-layer address with a Layer 3 interface.
z Associate a neighbor IPv6 address and link-layer address with a port in a VLAN.
1-12
Support for the two configuration modes above depends on the device model.
Follow these steps to configure a static neighbor entry:

ipv6 neighbor ipv6-address mac-address

Configure a static
{ vlan-id port-type port-number | interface Required
neighbor entry
interface-type interface-number }
You can adopt either of the two methods above to configure a static neighbor entry.
z After a static neighbor entry is configured by using the first method, the device needs to resolve the
corresponding Layer 2 port information of the VLAN interface.
z If you adopt the second method, you should ensure that the corresponding VLAN interface exists
and that the Layer 2 port specified by port-type port-number belongs to the VLAN specified by
vlan-id. After a static neighbor entry is configured, the device relates the VLAN interface to the IPv6
address to uniquely identify a static neighbor entry.
Configuring the Maximum Number of Neighbors Dynamically Learned
The device can dynamically acquire the link-layer address of a neighbor node through NS and NA
messages and add it into the neighbor table. Too large a neighbor table may reduce the forwarding
performance of the device. You can restrict the size of the neighbor table by setting the maximum
number of neighbors that an interface can dynamically learn. When the number of dynamically learned
neighbors reaches the threshold, the interface will stop learning neighbor information.
Follow these steps to configure the maximum number of neighbors dynamically learned:

interface-number
number of neighbors ipv6 neighbors
dynamically learned by an max-learning-num number The default value depends on
interface the device model.
Configuring Parameters Related to RA Messages
You can enable an interface to send RA messages, and configure the interval for sending RA messages
1-13
and parameters in RA messages. After receiving an RA message, a host can use these parameters to
perform corresponding operations. Table 1-4 lists the configurable parameters in an RA message and
their descriptions.
Table 1-4 Parameters in an RA message and their descriptions
Parameters Description
When sending an IPv6 packet, a host uses the value to fill the Cur Hop Limit field
Cur hop limit in IPv6 headers. The value is also filled into the Cur Hop Limit field in response
messages of a device.
Prefix
After receiving the prefix information advertised by the device, the hosts on the
information
same link can perform stateless autoconfiguration.
options
This field determines whether hosts use the stateful autoconfiguration to acquire
IPv6 addresses.
If the M flag is set to 1, hosts use the stateful autoconfiguration to acquire IPv6
M flag addresses (for example, through a DHCP server). Otherwise, hosts use the
stateless autoconfiguration to acquire IPv6 addresses, that is, hosts generate
IPv6 addresses according to their own link-layer addresses and the prefix
information issued by the router.
This field determines whether hosts use the stateful autoconfiguration to acquire
information other than IPv6 addresses.
O flag If the O flag is set to 1, hosts use the stateful autoconfiguration to acquire
information other than IPv6 addresses (for example, through a DHCP server).
Otherwise, hosts use the stateless autoconfiguration to acquire information other
than IPv6 addresses.
This field is used to set the lifetime of the router that sends RA messages to
serve as the default router of hosts. According to the router lifetime in the
Router lifetime
received RA messages, hosts determine whether the router sending RA
messages can serve as the default router.
If the device fails to receive a response message within the specified time after
Retrans timer
sending an NS message, the device will retransmit the NS message.
If the neighbor reachability detection shows that a neighbor is reachable, the
device considers the neighbor reachable within the specified reachable time. If
Reachable time
the device needs to send a packet to a neighbor after the specified reachable
time expires, the device will reconfirm whether the neighbor is reachable.
The values of the Retrans Timer and the Reachable Time configured for an interface are sent to hosts
via RA messages. Furthermore, this interface sends NS messages at the interval of Retrans Timer and
considers a neighbor reachable within the Reachable Time.
Follow these steps to configure parameters related to an RA message:

Configure the hop Optional

ipv6 nd hop-limit value
limit 64 by default.
1-14
interface-number
Disable the RA Required
message undo ipv6 nd ra halt
suppression By default, RA messages are suppressed.
Optional
By default, the maximum interval for
Configure the sending RA messages is 600 seconds, and
maximum and ipv6 nd ra interval the minimum interval is 200 seconds.
minimum intervals for max-interval-value The device sends RA messages at random
sending RA min-interval-value intervals between the maximum interval
messages and the minimum interval.
The minimum interval should be less than or
equal to 0.75 times the maximum interval.
ipv6 nd ra prefix Optional

{ ipv6-address prefix-length |
Configure the prefix By default, no prefix information is
ipv6-address/prefix-length }
information in RA configured for RA messages, and the IPv6
valid-lifetime
messages address of the interface sending RA
preferred-lifetime
[ no-autoconfig | off-link ] * messages is used as the prefix information.
Optional
ipv6 nd autoconfig By default, the M flag bit is set to 0, that is,
Set the M flag bit to 1
managed-address-flag hosts acquire IPv6 addresses through
stateless autoconfiguration.
Optional
ipv6 nd autoconfig By default, the O flag bit is set to 0, that is,
Set the O flag bit to 1
other-flag hosts acquire other information through
stateless autoconfiguration.
Configure the router Optional
ipv6 nd ra router-lifetime
lifetime in RA
value 1800 seconds by default.
messages
Optional
By default, the local interface sends NS
Set the NS ipv6 nd ns retrans-timer messages at an interval of 1000
retransmission timer value milliseconds, and the value of the Retrans
Timer field in RA messages sent by the
local interface is 0.
Optional
Set the reachable ipv6 nd nud By default, the neighbor reachable time on
time reachable-time value the local interface is 30000 milliseconds,
and the value of the Reachable Timer field
in RA messages is 0.
The maximum interval for sending RA messages should be less than or equal to the router lifetime in
RA messages.
1-15
Configuring the Maximum Number of Attempts to Send an NS Message for DAD
An interface sends a neighbor solicitation (NS) message for duplicate address detection after acquiring
an IPv6 address. If the interface does not receive a response within a specified time (determined by the
ipv6 nd ns retrans-timer command), it continues to send an NS message. If it still does not receive a
response after the number of sent attempts reaches a configurable threshold, the acquired address is
considered usable.
Follow these steps to configure the attempts to send an NS message for DAD:

interface-number
Configure the number of Optional

ipv6 nd dad attempts
attempts to send an NS 1 by default. When the value argument is
value
message for DAD set to 0, DAD is disabled.
Configuring PMTU Discovery

Configuring the Interface MTU
IPv6 routers do not support packet fragmentation. After an IPv6 router receives an IPv6 packet, if the
packet size is greater than the MTU of the forwarding interface, the router will discard the packet.
Meanwhile, the router sends the MTU to the source host through an ICMPv6 packet Packet Too Big
message. The source host fragments the packet according to the MTU and resends it. To reduce the
extra flow overhead resulting from packets being discarded, a proper interface MTU should be
configured according to the actual networking environment.
Follow these steps to configure the interface MTU:

interface-number

ipv6 mtu mtu-size
interface MTU The default value depends on the device model.
Configuring a Static PMTU for a Specified IPv6 Address
You can configure a static PMTU for a specified destination IPv6 address. When a source host sends a
packet through an interface, it compares the interface MTU with the static PMTU of the specified
destination IPv6 address. If the packet size is larger than the smaller one between the two values, the
host fragments the packet according to the smaller value.
1-16
Follow these steps to configure a static PMTU for a specified address:

Required
Configure a static PMTU for a ipv6 pathmtu ipv6-address
specified IPv6 address [ value ] By default, no static PMTU is
configured.
Configuring the Aging Time for Dynamic PMTUs
After the path MTU from a source host to a destination host is dynamically determined (refer to IPv6
PMTU Discovery), the source host sends subsequent packets to the destination host on basis of this
MTU. After the aging time expires, the dynamic PMTU is removed and the source host re-determines a
dynamic path MTU through the PMTU mechanism.
The aging time is invalid for a static PMTU.
Follow these steps to configure the aging time for dynamic PMTUs:

Configure the aging time for Optional

ipv6 pathmtu age age-time
dynamic PMTUs 10 minutes by default.
Configuring IPv6 TCP Properties

The IPv6 TCP properties you can configure include:
z synwait timer: When a SYN packet is sent, the synwait timer is triggered. If no response packet is
received before the synwait timer expires, the IPv6 TCP connection establishment fails.
z finwait timer: When the IPv6 TCP connection status is FIN_WAIT_2, the finwait timer is triggered. If
no packet is received before the finwait timer expires, the IPv6 TCP connection is terminated. If a
FIN packet is received, the IPv6 TCP connection status becomes TIME_WAIT. If non-FIN packets
are received, the finwait timer is reset upon receipt of the last non-FIN packet and the connection is
terminated after the finwait timer expires.
z Size of the IPv6 TCP sending/receiving buffer.
Follow these steps to configure IPv6 TCP properties:

tcp ipv6 timer fin-timeout Optional

Set the finwait timer
wait-time 675 seconds by default.
tcp ipv6 timer syn-timeout Optional

Set the synwait timer
wait-time 75 seconds by default.
Set the size of the IPv6 TCP Optional

tcp ipv6 window size
sending/receiving buffer 8 KB by default.
1-17
Configuring IPv6 FIB-Based Forwarding
With the IPv6 FIB caching function enabled, the device searches the FIB cache to forward packets, thus
reducing the searching time and improving forwarding efficiency.
In the IPv6 FIB load sharing mode, the device can decide how to select equal cost multi-paths (ECMP)
to forward packets. Currently, two load sharing modes are supported:
z Load sharing based on the HASH algorithm: A certain algorithm based on the source IPv6 address
and destination IPv6 address is adopted to select an ECMP route to forward packets.
z Load sharing based on polling: Each ECMP route is used in turn to forward packets.
Follow these steps to configure the IPv6 FIB-based forwarding:

For centralized devices ipv6 fibcache Required
Enable the Disabled by default.
IPv6 FIB The slot-number argument
caching ipv6 fibcache
For distributed devices and the all keyword are
function { slot-number | all }
both applicable to a
distributed device.
Configure the load sharing ipv6 Optional
Configure based on the HASH fib-loadbalance-type
the IPv6 By default, the load sharing
algorithm hash-based
FIB load based on polling is
sharing undo ipv6 adopted, that is, each
Configure the load sharing ECMP route is used in turn
mode fib-loadbalance-type
based on polling to forward packets.
hash-based
Configuring ICMPv6 Packet Sending

Configuring the Maximum ICMPv6 Error Packets Sent in an Interval
If too many ICMPv6 error packets are sent within a short time in a network, network congestion may
occur. To avoid network congestion, you can control the maximum number of ICMPv6 error packets
sent within a specified time, currently by adopting the token bucket algorithm.
You can set the capacity of a token bucket, namely, the number of tokens in the bucket. In addition, you
can set the update interval of the token bucket, namely, the interval for restoring the configured capacity.
One token allows one ICMPv6 error packet to be sent. Each time an ICMPv6 error packet is sent, the
number of tokens in a token bucket decreases by one. If the number of ICMPv6 error packets
successively sent exceeds the capacity of the token bucket, the additional ICMPv6 error packets cannot
be sent out until the capacity of the token bucket is restored.
1-18
Follow these steps to configure the capacity and update interval of the token bucket:

Optional
By default, the capacity of a token bucket is 10 and
Configure the
Ipv6 icmp-error the update interval is 100 milliseconds. That is, at
capacity and
{ bucket bucket-size | most 10 IPv6 ICMP error packets can be sent
update interval of
ratelimit interval } * within 100 milliseconds.
the token bucket
The update interval 0 indicates that the number of
ICMPv6 error packets sent is not restricted.
Enable Sending of Multicast Echo Replies
If hosts are capable of answering multicast echo requests, Host A can attack Host B by sending an echo
request with the source being Host B to a multicast address, then all the hosts in the multicast group will
send echo replies to Host B. Therefore, to prevent such an attack, a device is disabled from replying
multicast echo requests by default.
Follow these steps to enable sending of multicast echo replies:

Enable sending of multicast ipv6 icmpv6
Not enabled by default.
echo replies multicast-echo-reply enable
Enabling Sending of ICMPv6 Time Exceeded Packets
A device sends an ICMPv6 time exceeded packet in the following cases.

z If a received IPv6 packets destination IP address is not the local address and its hop count is 1, the
device sends an ICMPv6 time-to-live count exceeded packet to the source.
z Upon receiving the first fragment of an IPv6 datagram with the destination IP address being the
local address, the device starts a timer. If the timer expires before all the fragments arrive, an
ICMPv6 fragment reassembly time exceeded packet is sent to the source.
If large amounts of malicious packets are received, the performance of a device degrades greatly
because it has to send back ICMP time exceeded packets. You can disable sending of ICMPv6
time-to-live count exceeded packets.
Follow these steps to enable sending of ICMPv6 time exceeded packets:

Enable sending of ICMPv6 time Required

ipv6 hoplimit-expires enable
exceeded packets Enabled by default.
1-19
Configuring IPv6 DNS
Configuring Static IPv6 Domain Name Resolution
Configuring static IPv6 domain name resolution is to establish the mapping between a host name and
an IPv6 address. When using such applications as Telnet, you can directly input a host name and the
system will resolve the host name into an IPv6 address. Each host name can correspond to only one
IPv6 address.
Follow these steps to configure static IPv6 domain name resolution:

Configure a host name to IPv6 ipv6 host hostname

Required
address mapping ipv6-address
Configuring Dynamic IPv6 Domain Name Resolution
You can use the following command to enable the dynamic domain name resolution function. In addition,
you need to configure a DNS server so that a query request message can be sent to the correct server
for resolution. The system can support at most six DNS servers.
You can configure a DNS suffix so that you only need to enter part of a domain name, and the system
can automatically add the preset suffix for address resolution. The system can support at most 10 DNS
suffixes.
Follow these steps to configure dynamic IPv6 domain name resolution:

Enable the dynamic domain Required

dns resolve
name resolution function Disabled by default.
Required
dns server ipv6
Configure an IPv6 DNS ipv6-address If the IPv6 address of the DNS server is a
server [ interface-type link-local address, you need to specify the
interface-number ] interface-type and interface-number
argument.
Required
dns domain By default, no domain name suffix is
Configure a DNS suffix
domain-name configured, that is, the domain name is
resolved according to the input information.
The dns resolve and dns domain commands are the same as those of IPv4 DNS. For details about
the commands, refer to DNS Commands in the IP Services Volume.
1-20
Displaying and Maintaining IPv6 Basics Configuration
Display DNS suffix information display dns domain [ dynamic ]
Display IPv6 dynamic domain name cache
display dns ipv6 dynamic-host
information
Display IPv6 DNS server information display dns ipv6 server [ dynamic ]
For centralized devices display ipv6 fib [ ipv6-address ]

Display the
IPv6 FIB entries display ipv6 fib [ slot-number ]
[ ipv6-address ]
Display the total For centralized devices display ipv6 fibcache
number of
routes in the For distributed devices display ipv6 fibcache slot-number
IPv6 FIB cache
Display the host name to IPv6 address
display ipv6 host
mappings in the static DNS database Available in
display ipv6 interface any view
Display the IPv6 interface settings [ interface-type [ interface-number ] ]
[ verbose ]
display ipv6 neighbors

{ ipv6-address | all | dynamic |
For centralized interface interface-type
devices interface-number | static | vlan
vlan-id } [ | { begin | exclude |
include } regular-expression ]
Display neighbor
information display ipv6 neighbors
{ { ipv6-address | all | dynamic |
static } [ slot slot-number ] |
For distributed devices interface interface-type
interface-number | vlan vlan-id } [ |
1-21
display ipv6 neighbors { all |
For centralized dynamic | interface interface-type
Display the total devices interface-number | static | vlan
number of vlan-id } count
neighbor entries
satisfying the display ipv6 neighbors { { all |
specified dynamic | static } [ slot slot-number ]
conditions For distributed devices | interface interface-type
interface-number | vlan vlan-id }
count
Display the PMTU information of an IPv6 display ipv6 pathmtu { ipv6-address
address | all | dynamic | static }
For centralized display ipv6 socket [ socktype

devices socket-type ] [ task-id socket-id ] Available in
Display socket any view
information display ipv6 socket [ socktype
For distributed devices socket-type ] [ task-id socket-id ] [ slot
slot-number ]
Display the For centralized

display ipv6 statistics
statistics of IPv6 devices
packets and
display ipv6 statistics [ slot
ICMPv6 packets For distributed devices
slot-number ]
Display the IPv6 TCP connection statistics display tcp ipv6 statistics
Display the IPv6 TCP connection status
display tcp ipv6 status
information
Display the IPv6 UDP connection statistics display udp ipv6 statistics
Clear IPv6 dynamic domain name cache
reset dns ipv6 dynamic-host
information
For centralized
reset ipv6 fibcache
Clear FIB cache devices
entries reset ipv6 fibcache { slot-number |
all }
reset ipv6 neighbors { all | dynamic
For centralized
| interface interface-type
devices
Clear IPv6 interface-number | static }
neighbor reset ipv6 neighbors { all | dynamic
information | interface interface-type Available in
For distributed devices user view
interface-number | slot slot-number |
static }
reset ipv6 pathmtu { all | static |
Clear the specified PMTU values
dynamic}
Clear the For centralized

reset ipv6 statistics
statistics of IPv6 devices
and ICMPv6 reset ipv6 statistics [ slot
packets For distributed devices
slot-number ]
Clear all IPv6 TCP connection statistics reset tcp ipv6 statistics
Clear the statistics of all IPv6 UDP packets reset udp ipv6 statistics
1-22
The display dns domain command is the same as the one of IPv4 DNS. For details about the
commands, refer to DNS Commands in the IP Services Volume.
IPv6 Configuration Example (on Routers)

z Host, Router A and Router B are directly connected through Ethernet interfaces. Configure IPv6
addresses for the interfaces and verify the connectivity between them.
z The aggregatable global unicast address of Ethernet 1/1 and Ethernet 1/2 on Router A are
3001::1/64 and 2001::1/64 respectively.
z The aggregatable global unicast address of Ethernet 1/1 on Router B is 3001::2/64, and a route to
Host is available.
z IPv6 is enabled for Host to automatically get an IPv6 address through IPv6 NDP.
Network diagram
Figure 1-6 Network diagram for IPv6 address configuration (on routers)
z Configure Router A
# Enable IPv6.
[RouterA] ipv6
# Assign an aggregatable global unicast address for interface Ethernet 1/1.

[RouterA-Ethernet1/1] ipv6 address 3001::1/64
# Assign an aggregatable global unicast addresses for interface Ethernet 1/2 and allow it to advertise
RA messages (no interface advertises RA messages by default).
[RouterA-Ethernet1/1] interface ethernet 1/2
[RouterA-Ethernet1/2] ipv6 address 2001::1/64
[RouterA-Ethernet1/2] undo ipv6 nd ra halt
z Configure Router B
# Enable IPv6.
[RouterB] ipv6
# Assign an aggregatable global unicast address for interface Ethernet 1/1.

1-23
[RouterB-Ethernet1/1] ipv6 address 3001::2/64
# Configure an IPv6 static route with destination IP address 2001::/64 and next hop address 3001::1.
[RouterB-Ethernet1/1] ipv6 address 2001:: 64 3001::1
z Configure Host
Enable IPv6 for Host to automatically get an IPv6 address through IPv6 NDP.
[RouterA-Ethernet1/1] display ipv6 neighbors interface ethernet 1/2
Type: S-Static D-Dynamic
IPv6 Address Link-layer VID Interface State T Age
FE80::215:E9FF:FEA6:7D14 0015-e9a6-7d14 N/A Eth1/2 STALE D 1238
2001::15B:E0EA:3524:E791 0015-e9a6-7d14 N/A Eth1/2 STALE D 1248
The above information shows that the IPv6 aggregatable global unicast address that Host obtained is
2001::15B:E0EA:3524:E791.
Verification
# Display the IPv6 interface information on Router A.

[RouterA-Ethernet1/1] display ipv6 interface ethernet 1/1 verbose
Ethernet1/1 current state :UP
Line protocol current state :UP
IPv6 is enabled, link-local address is FE80::20F:E2FF:FE00:2
Global unicast address(es):
3001::1, subnet is 3001::/64
Joined group address(es):
FF02::1:FF00:0
FF02::1:FF00:1
FF02::1:FF00:2
FF02::2
FF02::1
MTU is 1500 bytes
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND retransmit interval is 1000 milliseconds
Hosts use stateless autoconfig for addresses
IPv6 Packet statistics:
InReceives: 25829
InTooShorts: 0
InTruncatedPkts: 0
InHopLimitExceeds: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 47
1-24
OutRequests: 89
OutForwDatagrams: 48
InNoRoutes: 0
InTooBigErrors: 0
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 6
InMcastNotMembers: 25747
OutMcastPkts: 48
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
[RouterA-Ethernet1/1] display ipv6 interface ethernet 1/2 verbose
IPv6 is enabled, link-local address is FE80::20F:E2FF:FE00:1C0
2001::1, subnet is 2001::/64
FF02::1:FF00:0
FF02::1:FF00:1
FF02::1:FF00:1C0
FF02::2
FF02::1
MTU is 1500 bytes
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 600 seconds
ND router advertisements live for 1800 seconds
InReceives: 272
InTooShorts: 0
InTruncatedPkts: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 159
OutRequests: 1012
1-25
InNoRoutes: 0
InTooBigErrors: 0
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 79
OutMcastPkts: 938
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
# Display the IPv6 interface settings on Router B.

[RouterB-Ethernet1/1] display ipv6 interface ethernet 1/1 verbose
3001::2, subnet is 3001::/64
FF02::1:FF00:0
FF02::1:FF00:2
FF02::1:FF00:1234
FF02::2
FF02::1
MTU is 1500 bytes
InReceives: 117
InTooShorts: 0
InTruncatedPkts: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 117
OutRequests: 83
OutForwDatagrams: 0
InNoRoutes: 0
InTooBigErrors: 0
1-26
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 28
OutMcastPkts: 7
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
# Ping Router A and Router B from Host, and ping Router A and Host from Router B to verify the
connectivity between them.
When you ping a link-local address, you should use the i parameter to specify an interface for the
link-local address.
[RouterB-Ethernet1/1] ping ipv6 -c 1 3001::1

PING 3001::1 : 56 data bytes, press CTRL_C to break
Reply from 3001::1
bytes=56 Sequence=1 hop limit=64 time = 2 ms
--- 3001::1 ping statistics ---

0.00% packet loss
[RouterB-Ethernet1/1] ping ipv6 -c 1 2001::15B:E0EA:3524:E791
PING 2001::15B:E0EA:3524:E791 : 56 data bytes, press CTRL_C to break
Reply from 2001::15B:E0EA:3524:E791
--- 2001::15B:E0EA:3524:E791 ping statistics ---

0.00% packet loss
As shown in the output information, Host can ping Router B and Router A.
IPv6 Configuration Example (on Switches)

z Host, Switch A and Switch B are directly connected through Ethernet ports. Add the Ethernet ports
into corresponding VLANs, configure IPv6 addresses for the VLAN interfaces and verify the
connectivity between them.
z The aggregatable global unicast addresses of VLAN-interface 2 and VLAN-interface 1 on Switch A
are 3001::1/64 and 2001::1/64 respectively.
1-27
z The aggregatable global unicast address of VLAN-interface 2 on Switch B is 3001::2/64, and a
route to Host is available.
z IPv6 is enabled for Host to automatically get an IPv6 address through IPv6 NDP.
Network diagram
Figure 1-7 Network diagram for IPv6 address configuration (on switches)
z Configure Switch A
# Enable IPv6.
[SwitchA] ipv6
# Specify an aggregatable global unicast address for VLAN-interface 2.

[SwitchA] vlan 2
[SwitchA-vlan2] interface vlan-interface 2
[SwitchA-Vlan-interface2] ipv6 address 3001::1/64
# Specify an aggregatable global unicast address for VLAN-interface 1, and allow it to advertise RA
messages (no interface advertises RA messages by default).
[SwitchA-Vlan-interface2] interface vlan-interface 1
[SwitchA-Vlan-interface1] ipv6 address 2001::1/64
[SwitchA-Vlan-interface1] undo ipv6 nd ra halt
z Configure Switch B
# Enable IPv6.
[SwitchB] ipv6
# Configure an aggregatable global unicast address for VLAN-interface 2.

[SwitchB-Vlan-interface2] ipv6 address 3001::2/64
# Configure an IPv6 static route with destination IP address 2001::/64 and next hop address 3001::1.
[SwitchB-Vlan-interface2] ipv6 address 2001:: 64 3001::1
z Configure Host
Enable IPv6 for Host to automatically get an IPv6 address through IPv6 NDP.
[SwitchA-Vlan-interface1] display ipv6 neighbors interface ethernet 1/2
Type: S-Static D-Dynamic
IPv6 Address Link-layer VID Interface State T Age
FE80::215:E9FF:FEA6:7D14 0015-e9a6-7d14 1 Eth1/2 STALE D 1238
2001::15B:E0EA:3524:E791 0015-e9a6-7d14 1 Eth1/2 STALE D 1248
The above information shows that the IPv6 aggregatable global unicast address that Host obtained is
2001::15B:E0EA:3524:E791.
1-28
Verification
# Display the IPv6 interface settings on Switch A.

[SwitchA-Vlan-interface1] display ipv6 interface vlan-interface 2 verbose
Vlan-interface2 current state :UP
3001::1, subnet is 3001::/64
FF02::1:FF00:0
FF02::1:FF00:1
FF02::1:FF00:2
FF02::2
FF02::1
MTU is 1500 bytes
InReceives: 25829
InTooShorts: 0
InTruncatedPkts: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 47
OutRequests: 89
InNoRoutes: 0
InTooBigErrors: 0
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 6
OutMcastPkts: 48
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
[SwitchA-Vlan-interface1] display ipv6 interface vlan-interface 1 verbose
1-29
IPv6 is enabled, link-local address is FE80::20F:E2FF:FE00:1C0
2001::1, subnet is 2001::/64
FF02::1:FF00:0
FF02::1:FF00:1
FF02::1:FF00:1C0
FF02::2
FF02::1
MTU is 1500 bytes
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 600 seconds
ND router advertisements live for 1800 seconds
InReceives: 272
InTooShorts: 0
InTruncatedPkts: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 159
OutRequests: 1012
InNoRoutes: 0
InTooBigErrors: 0
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 79
OutMcastPkts: 938
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
# Display the IPv6 interface settings on Switch B.

[SwitchB-Vlan-interface2] display ipv6 interface vlan-interface 2 verbose
1-30
3001::2, subnet is 3001::/64
FF02::1:FF00:0
FF02::1:FF00:2
FF02::1:FF00:1234
FF02::2
FF02::1
MTU is 1500 bytes
InReceives: 117
InTooShorts: 0
InTruncatedPkts: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 117
OutRequests: 83
OutForwDatagrams: 0
InNoRoutes: 0
InTooBigErrors: 0
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 28
OutMcastPkts: 7
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
# Ping Switch A and Switch B on Host, and ping Switch A and Host on Switch B to verify the connectivity
between them.
1-31
When you ping a link-local address, you should use the i parameter to specify an interface for the
link-local address.
[SwitchB-Vlan-interface2] ping ipv6 -c 1 3001::1

Reply from 3001::1

0.00% packet loss
[SwitchB-Vlan-interface2] ping ipv6 -c 1 2001::15B:E0EA:3524:E791
PING 2001::15B:E0EA:3524:E791 : 56 data bytes, press CTRL_C to break
Reply from 2001::15B:E0EA:3524:E791
--- 2001::15B:E0EA:3524:E791 ping statistics ---

0.00% packet loss
As shown in the output information, Host can ping Switch B and Switch A.
Troubleshooting IPv6 Basics Configuration

Symptom
The peer IPv6 address cannot be pinged.
Solution
z Use the display current-configuration command in any view or the display this command in
system view to verify that IPv6 is enabled.
z Use the display ipv6 interface command in any view to verify that the IPv6 address of the
interface is correct and the interface is up.
z Use the debugging ipv6 packet command in user view to enable the debugging for IPv6 packets
to help locate the cause.
1-32
Table of Contents
1 NAT-PT Configuration 1-1

NAT-PT Overview 1-1
NAT-PT Mechanism 1-2
Implementing NAT-PT 1-2
NAT-PT Configuration Task List 1-3
Configuring NAT-PT1-3
Enabling NAT-PT1-4
Configuring a NAT-PT Prefix1-4
Configuring Source IPv4-to-IPv6 Address Mappings1-5
Configuring Source IPv6-to-IPv4 Address Mappings1-5
Configuring a NAT-PT Aging time for a Protocol 1-7
Configuring the Maximum Number of Sessions1-8
Setting the ToS/Traffic Class Field after NAT-PT Translation1-8
Displaying and Maintaining NAT-PT 1-9
NAT-PT Configuration Examples1-9
Configuring Dynamic Source IPv6-to-IPv4 Address Mappings1-9
Configuring Static IPv4-to-IPv6 and IPv6-to-IPv4 Mappings1-10
Troubleshooting NAT-PT 1-12
i
1 NAT-PT Configuration
When configuring NAT-PT, go to these sections for information you are interested in:
z NAT-PT Overview
z Configuring NAT-PT
z Displaying and Maintaining NAT-PT
z NAT-PT Configuration Examples
z Troubleshooting NAT-PT
NAT-PT Overview
Because of the coexistence of IPv4 networks and IPv6 networks, Network Address Translation
Protocol Translation (NAT-PT) was introduced to realize translation between IPv4 and IPv6 addresses.
For example, it can enable a host in an IPv6 network to access the FTP server in an IPv4 network.
As shown in Figure 1-1, NAT-PT runs on the device between IPv4 and IPv6 networks. The address
translation is transparent to both IPv4 and IPv6 networks. Users in the IPv6 and IPv4 networks can
communicate without changing their configurations.
Figure 1-1 Network diagram for NAT-PT
In view of the following limitations, NAT-PT is not recommended in some applications (for example,
tunneling is recommended in the case where an IPv6 host needs to communicate with another IPv6
host across an IPv4 network).
z In NAT-PT translation, the request and response packets of a session must be processed by the
same NAT-PT device.
z The Options field in the IPv4 packet header cannot be translated.
z NAT-PT does not provide end-to-end security.
Currently, NAT-PT supports ICMP, DNS, FTP, and other protocols that employ the network layer
protocol but have no address information in the protocol messages.
To get more information about NAT-PT, go to these topics:
1-1
z NAT-PT Mechanism
z Implementing NAT-PT
NAT-PT Mechanism
There are three NAT-PT mechanisms to realize translation between IPv4 and IPv6 addresses: Static
NAT-PT mapping, Dynamic NAT-PT mapping, and NAPT-PT.
Static NAT-PT mapping
Static NAT-PT mappings are manually configured for translation between IPv6 and IPv4 addresses.
Dynamic NAT-PT mapping
Dynamic NAT-PT does not provide one-to-one mappings between IPv6 addresses and IPv4
addresses.
To implement dynamic NAT-PT, you need to create an address pool. After that, NAT-PT selects
available addresses from the address pool to accomplish the mappings between IPv6 addresses and
IPv4 addresses.
NAPT-PT
Network Address Port Translation Protocol Translation (NAPT-PT) realizes the IPv6 TCP/UDP port
number to IPv4 TCP/UDP port number translation besides dynamic address translation. With NAPT-PT,
different IPv6 addresses can correspond to one IPv4 address. Different IPv6 hosts are distinguished by
different port numbers so that these IPv6 hosts can share one IPv4 address to accomplish the address
translation.
Implementing NAT-PT
Session initiated by an IPv6 host
Figure 1-2 NAT-PT implementation (session initiated by an IPv6 host)
The NAT-PT implementation process for a session initiated by an IPv6 host is as follows:
1) A packet from an IPv6 host to an IPv4 host reaches the NAT-PT device. The NAT-PT device
translates the source IPv6 address of the packet into an IPv4 address according to the static or
dynamic IPv6-to-IPv4 mapping.
2) The NAT-PT device translates the IPv6 destination address of the packet into an IPv4 address
according to the IPv6-to-IPv4 mapping, if configured, at the IPv4 network side. Without any
mapping configured on the IPv4 network side, if the lowest 32 bits of the destination IPv6 address
in the packet can be directly translated into a valid IPv4 address, the destination IPv6 address is
translated into an IPv4 address. Otherwise, the translation fails.
1-2
3) After the source and destination IPv6 addresses of the packet are translated into IPv4 addresses,
the NAT-PT device forwards the packet to the IPv4 host. Meanwhile, the IPv6-to-IPv4 address
mappings are stored in the NAT-PT device.
4) After a packet from the IPv4 host to the IPv6 host arrives at the NAT-PT device, the device swaps
the source and destination IPv4 addresses according to the stored mappings and forwards the
packet to the IPv6 host.
Session initiated by an IPv4 host
The NAT-PT implementation process for a session initiated by an IPv4 host is as follows:
1) A packet from an IPv4 host to an IPv6 host reaches the NAT-PT device. The NAT-PT device
translates the source IPv4 address of the packet into an IPv6 address according to the static or
dynamic IPv4-to-IPv6 mapping.
2) The NAT-PT device translates the destination IPv4 address of the packet into an IPv6 address
according to the IPv6-to-IPv4 mapping on the IPv6 network side.
3) After the source and destination IPv4 addresses of the packet are translated into IPv6 addresses,
the NAT-PT device forwards the packet to the IPv6 host. Meanwhile, the IPv4-to-IPv6 address
mappings are stored in the NAT-PT device.
4) After a packet from the IPv6 host to the IPv4 host arrives at the NAT-PT device, the device swaps
the source and destination IPv6 addresses according to the stored mappings and forwards the
packet to the IPv4 host.
z RFC 2765: Stateless IP/ICMP Translation Algorithm

z RFC 2766: Network Address Translation - Protocol Translation (NAT-PT)
NAT-PT Configuration Task List

Complete the following tasks to configure NAT-PT:
Task Remarks
Enabling NAT-PT Required
Configuring a NAT-PT Prefix Optional
Configuring Source IPv4-to-IPv6 Address Mappings Required

Configuring Source IPv6-to-IPv4 Address Mappings Required
Configuring a NAT-PT Aging time for a Protocol Optional
Configuring the Maximum Number of Sessions Optional
Setting the ToS/Traffic Class Field after NAT-PT Translation Optional
Configuring NAT-PT
Before implementing NAT-PT, you need to enable the IPv6 forwarding function on the device and
configure an IPv4 or IPv6 address as required on the interface to be enabled with NAT-PT.
1-3
Fast forwarding will invalidate NAT-PT. Therefore, before enabling NAT-PT, you need to disable fast
forwarding by executing the undo ip fast-forwarding command in interface view, or clear existing fast
forwarding entries by executing the reset ip fast-forwarding cache command in user view. For
details about the two commands, refer to Fast Forwarding Commands in the IP Services Volume.
Enabling NAT-PT
Follow these steps to enable NAT-PT:

interface-number
Enable NAT-PT on the Required

natpt enable
interface Disabled by default.
Configuring a NAT-PT Prefix
A NAT-PT prefix is used for dynamic IPv4-to-IPv6 or IPv6-to-IPv4 mappings.

After you configure a NAT-PT prefix:
z For dynamic IPv6-to-IPv4 mappings, when receiving a packet from an IPv6 network to an IPv4
network, the NAT-PT device detects the prefix of the destination IPv6 address of the packet. An
IPv6-to-IPv4 translation will be performed only when the prefix is the same as the configured
NAT-PT one.
z For dynamic IPv4-to-IPv6 mappings, if the source IPv4 address matches the specified ACL, the
configured NAT-PT prefix will be added to translate the source IPv4 address into an IPv6 address.
Follow these steps to configure a NAT-PT prefix:
natpt prefix natpt-prefix [ interface interface-type

Configure a NAT-PT prefix Required
interface-number [ nexthop ipv4-address ] ]
z The NAT-PT prefix must not be the same as the network address of the NAT-PT enabled interface
on the IPv6 network.
z To delete a NAT-PT prefix that has been referenced by another command, you need to cancel the
referenced configuration first.
1-4
Configuring Source IPv4-to-IPv6 Address Mappings
When a packet is sent from an IPv4 network to an IPv6 network, the source IPv4 address is translated
to an IPv6 address in accordance with the configured mapping.
There are static and dynamic IPv4-to-IPv6 address mappings.
z A static IPv4-to-IPv6 address mapping is used to translate a source IPv4 address into a
corresponding IPv6 address.
z A dynamic IPv4-to-IPv6 address mapping means that if the source IPv4 address matches the
specified ACL, a NAT-PT prefix will be added to translate the source IPv4 address into an IPv6
address.
Follow these steps to configure IPv4-to-IPv6 address mappings:
natpt v4bound static { ipv4-address

Configure an
Configure ipv6-address | v6server protocol
IPv4-to-IPv6 address Required to
IPv4-to-IP protocol-type ipv4-address ipv4-port-number
mapping configure
v6 ipv6-address ipv6-port-number }
either of the
address Configure dynamic
natpt v4bound dynamic acl number two
mappings IPv4-to-IPv6 address
acl-number prefix natpt-prefix
mappings
z The natpt-prefix argument specified in the natpt v6bound dynamic prefix natpt-prefix interface
interface-type interface-number command must have been configured with the natpt prefix
command.
z For ACL configuration, refer to ACL configuration in the Security Volume.
Configuring Source IPv6-to-IPv4 Address Mappings
When a packet is sent from an IPv6 network to IPv4 network, the source IPv6 address is translated to
an IPv4 address in accordance with the configured static or dynamic mapping.
z A static IPv6-to-IPv4 address mapping is used to translate a source IPv6 address into a
corresponding IPv4 address.
z A dynamic IPv6-to-IPv4 mapping means that if the source IPv6 address matches a specified IPv6
ACL or matches a specified NAT-PT prefix, the source IPv6 address will be translated into an IPv4
address in a specified NAT-PT address pool or the IPv4 address of a specified interface.
The device provides four types of dynamic mapping.
z Combination 1: Combination of an IPv6 ACL with an address pool
If the source IPv6 address of a packet matches the specified IPv6 ACL, the source IPv6 address will be
translated into an IPv4 address of the specified address pool.
z Combination 2: Combination of an IPv6 ACL with an interface address
1-5
If the source IPv6 address of a packet matches the specified IPv6 ACL, the source IPv6 address will be
translated into an IPv4 address of the specified interface.
z Combination 3: Combination of a NAT-PT prefix with an address pool
If the destination IPv6 address of a packet matches the NAT-PT prefix, the source IPv6 address will be
translated into an IPv4 address of the specified address pool.
z Combination 4: Combination of a NAT-PT prefix with an interface address
If the destination IPv6 address of a packet matches the NAT-PT prefix, the source IPv6 address will be
translated into an IPv4 address of the specified interface.
To use combination 1 or combination 3, you need to configure a NAT-PT address pool first.
A NAT-PT address pool is a group of contiguous IPv4 addresses and is used to translate an IPv6
address into an IPv4 address dynamically. When an IPv6 packet is sent from an IPv6 network to an
IPv4 network, if the combination 1 or 3 is set, the NAT-PT device will select an IPv4 address from the
NAT-PT address pool as the source IPv4 address of the IPv6 packet.
Follow these steps to configure IPv6-to-IPv4 address mappings:
Configure static Configure a static natpt v6bound static

Required to
or dynamic IPv6-to-IPv4 address mapping ipv6-address ipv4-address
configure
IPv6-to-IPv4
Configure dynamic either of the
address See the table below.
IPv6-to-IPv4 address mapping two
mappings
Follow these steps to configure dynamic IPv6-to-IPv4 address mapping:
1-6
natpt address-group
Associate an IPv6 ACL with an address pool: group-number start-ipv4-address
If the source IPv6 address of an IPv6 packet end-ipv4-address
matches the specified IPv6 ACL, the source natpt v6bound dynamic acl6
IPv6 address will be translated into an IPv4 number acl-number
address of the specified address pool. address-group address-group
[ no-pat ]
Associate an IPv6 ACL with an interface
address:
natpt v6bound dynamic acl6
If the source IPv6 address of an IPv6 packet number acl-number interface
matches the specified IPv6 ACL, the source interface-type interface-number Configure
IPv6 address will be translated into the IPv4 any of the
address of the specified interface. four types of
Associate a NAT-PT prefix with an address natpt address-group dynamic
pool: group-number start-ipv4-address mappings.
If the destination IPv6 address of an IPv6 end-ipv4-address
packet matches the specified NAT-PT prefix, natpt v6bound dynamic prefix
the source IPv6 address will be translated into natpt-prefix address-group
an IPv4 address of the specified address pool. address-group [ no-pat ]
Associate a NAT-PT prefix with an interface
address
natpt v6bound dynamic prefix
If the destination IPv6 address of an IPv6 natpt-prefix interface
packet matches the specified NAT-PT prefix, interface-type interface-number
the source IPv6 address will be translated into
the IPv4 address of the specified interface.
z The NAT-PT prefix referenced in a natpt v6bound command must have been configured with the
natpt prefix command.
z For ACL configuration, refer to ACL configuration in the Security Volume.
Configuring a NAT-PT Aging time for a Protocol
You can set a NAT-PT aging time for a protocol. If a packet of the protocol cannot be translated within
the aging time, NAT-PT stops address translation.
1-7
Follow these steps to configure a NAT-PT aging time for a protocol:
Required
The defaults are as follows:
10 seconds for a DNS packet,
natpt aging-time 5 seconds for a FINRST packet,
Configure a NAT-PT
{ default | { dns | finrst |
aging time for a 5 seconds for a FRAG packet,
frag | icmp | syn | tcp |
protocol 20 seconds for a ICMP packet,
udp } time-value }
240 seconds for a SYN packet,
40 seconds for a UDP packet, and
86400 seconds for a TCP packet
Configuring the Maximum Number of Sessions
You can set the maximum number of allowed sessions. When the number of concurrent sessions
reaches the maximum, no new session can be established.
Follow these steps to configure the maximum number of sessions:
Configure the maximum natpt max-session Required

number of NAT-PT sessions max-number 2,048 by default.
Setting the ToS/Traffic Class Field after NAT-PT Translation
After NAT-PT translation, you can set the ToS/Traffic Class field in packets to 0 or leave it unchanged.
Follow these steps to set the ToS and Traffic Class field in packets after NAT-PT translation:

Set the Traffic Class field in Required

natpt turn-off
IPv6 packets translated from The default is the same as that of the
traffic-class
IPv4 packets to 0 ToS field in IPv4 packets.
Set the ToS field in IPv4 Required

packets translated from IPv6 natpt turn-off tos The default is the same as that of the
packets to 0 Traffic Class field in IPv6 packets.
1-8
Displaying and Maintaining NAT-PT
Display all NAT-PT configuration information display natpt all
Display NAT-PT address pool configuration
display natpt address-group
information
Display the static and dynamic NAT-PT display natpt
address mappings address-mapping
Available in any
Display the NAT-PT aging time display natpt aging-time
view
Display the NAT-PT fragment session
display natpt frag-sessions
information
Display the dynamic NAT-PT session display natpt session { all |
information icmp | tcp | udp }
Display NAT-PT statistics information display natpt statistics
reset natpt
Clear dynamic NAT-PT address mappings
dynamic-mappings
Available in user
Clear all NAT-PT For a centralized device reset natpt statistics
view
statistics reset natpt statistics [ slot
information For a distributed device
slot-number ]
NAT-PT Configuration Examples

Configuring Dynamic Source IPv6-to-IPv4 Address Mappings
An IPv4 network is connected to an IPv6 network through a NAT-PT device Router B. Dynamic
IPv6-to-IPv4 mappings are configured on Router B so that IPv6 hosts can access IPv4 hosts but IPv4
hosts cannot access IPv6 hosts.
Network diagram
Figure 1-3 Network diagram for dynamic IPv6-to-IPv4 mapping configuration
1) Configure Router A in the IPv4 network

2) Configure Router C in the IPv6 network
1-9
[RouterC] ipv6
[RouterC-Serial2/0] ipv6 address 2001::2/64
# Configure a default route to Router B.

[RouterC] ipv6 route-static 3001:: 16 2001::1
# Configure interface addresses and enable NAT-PT on the interfaces.
[RouterB] ipv6
[RouterB-Serial2/0] natpt enable
[RouterB-Serial2/1] ipv6 address 2001::1/64
# Configure a NAT-PT prefix.

[RouterB] natpt prefix 3001::
# Configure a NAT-PT address pool.

[RouterB] natpt address-group 1 8.0.0.10 8.0.0.19
# Associate the prefix with the address pool for IPv6 hosts accessing IPv4 hosts.
[RouterB] natpt v6bound dynamic prefix 3001:: address-group 1
Verification
If you carry out the ping ipv6 3001::0800:0002 command on Router C after completing the
configurations above, response packets can be received.
At this time, you can see on Router B the established NAT-PT session.
[RouterB] display natpt session all
NATPT Session Info:

No IPV6Source IPV4Source Pro
IPV6Destination IPV4Destination
1 2001::0002 ^57259 8.0.0.19 ^12288 ICMP
3001::0800:0002 ^ 0 8.0.0.2 ^ 0
Configuring Static IPv4-to-IPv6 and IPv6-to-IPv4 Mappings
An IPv4 network is connected to an IPv6 network through a NAT-PT device Router B. Static
IPv4-to-IPv6 and IPv6-to-IPv4 mappings are configured on Router B so that the IPv4 and IPv6
networks can access each other.
1-10
Network diagram
Figure 1-4 Network diagram for NAT-PT (static IPv4-to-IPv6 and IPv6-to-IPv4 mappings)
1) Configure Router A in the IPv4 network

[RouterA] ip route-static 0.0.0.0 0 serial2/0
2) Configure Router C in the IPv6 network
[RouterC] ipv6
[RouterC-Serial2/0] ipv6 address 2001::2/64
[RouterC] ipv6 route-static :: 0 serial 2/0
# Configure interface addresses and enable NAT-PT on the interfaces.
[RouterB] ipv6
[RouterB-Serial2/1] ipv6 address 2001::1/64
# Configure a NAT-PT prefix.

[RouterB] natpt prefix 3001::
# Configure a static IPv4-to-IPv6 mapping.

[RouterB] natpt v4bound static 8.0.0.2 3001::5
# Configure a static IPv6-to-IPv4 mapping.

[RouterB] natpt v6bound static 2001::2 8.0.0.5
Verification
After the above configurations, using the ping 8.0.0.5 command on Router A can receive responses,
1-11
and you can view the following NAT-PT session information on Router B using the display command.
NATPT Session Info:

1 3001::0005 ^ 0 8.0.0.2 ^ 0 ICMP
2001::0002 ^ 0 8.0.0.5 ^ 0
Using the ping ipv6 3001::5 command on Router C can receive response packets, and you can view
the following NAT-PT session information on Router B using the display command.
NATPT Session Info:

1 2001::0002 ^ 0 8.0.0.5 ^ 0 ICMP
3001::0005 ^ 0 8.0.0.2 ^ 0
Troubleshooting NAT-PT
Symptom:
NAT-PT is abnormal.
Solution:
z Enable debugging for NAT-PT.

z Locate the fault according to the debugging information of the device, and then make further
judgments by using other commands. During debugging, check whether the source address of a
packet is translated correctly. If not, it is possible that the address pool is configured incorrectly.
1-12
Table of Contents
1 Dual Stack Configuration1-1

Dual Stack Overview1-1
Configuring Dual Stack 1-1
i
1 Dual Stack Configuration
When configuring dual stack, go to these sections for information you are interested in:
z Dual Stack Overview
z Configuring Dual Stack
Dual Stack Overview

Dual stack is the most direct approach to making IPv6 nodes compatible with IPv4 nodes. The best way
for an IPv6 node to be compatible with an IPv4 node is to maintain a complete IPv4 stack. A network
node that supports both IPv4 and IPv6 is called a dual stack node. A dual stack node configured with an
IPv4 address and an IPv6 address can have both IPv4 and IPv6 packets transmitted.
For an upper layer application supporting both IPv4 and IPv6, either TCP or UDP can be selected at the
transport layer, while IPv6 stack is preferred at the network layer.
Figure 1-1 illustrates the IPv4/IPv6 dual stack in relation to the IPv4 stack.
Configuring Dual Stack

You must enable the IPv6 packet forwarding function before dual stack. Otherwise, the device cannot
forward IPv6 packets even if IPv6 addresses are configured for interfaces.
Follow these steps to configure dual stack on a gateway:
1-1
Enable the IPv6 packet forwarding Required

ipv6
function Disabled by default.
interface-number
Required
By default, no IP
ip address ip-address
Configure an IPv4 address for the address is configured.
{ mask | mask-length }
interface Support for the sub
[ sub ]
keyword depends on
the device model.
Configure Manually ipv6 address

specify an IPv6 { ipv6-address prefix-length | Use either command.
an IPv6
global address ipv6-address/prefix-length } By default, no site-local
unicast address or global
Configure an unicast address is
address or ipv6 address
IPv6 address in configured on an
site-local ipv6-address/prefix-length
Configure the EUI-64 interface.
address eui-64
an IPv6 format
address Automatically
on the create an IPv6 ipv6 address auto Optional
interface link-local link-local By default, after you
Configure
an IPv6 address configured an IPv6
link-local site-local address or
Manually global unicast address,
address specify an IPv6 ipv6 address ipv6-address a link local address is
link-local link-local automatically created.
address
For more information about IPv6 address, refer to IPv6 Basics Configuration in the IP Services Volume.
1-2
Table of Contents
1 Tunneling Configuration1-1
Introduction to Tunneling 1-2
IPv6 over IPv4 Tunnel 1-2
IPv4 over IPv4 Tunnel 1-6
IPv4/IPv6 over IPv6 Tunnel1-7
6PE Overview1-8
Tunneling Configuration Task List 1-9
Configuring IPv6 Manual Tunnel1-9
Configuring Automatic IPv4-Compatible IPv6 Tunnel1-17
Configuring 6to4 Tunnel1-24
6to4 Tunnel Configuration Example (on Routers)1-26
6to4 Tunnel Configuration Example (on Switches) 1-28
6to4 Relay Configuration Example (on Routers)1-31
6to4 Tunnel Configuration Example (on Switches) 1-33
Configuring ISATAP Tunnel1-35
Configuration Example (on a Router)1-37
Configuration Example (on a Switch) 1-40
Configuring IPv4 over IPv4 Tunnel 1-42
i
Displaying and Maintaining Tunneling Configuration1-67
Troubleshooting Tunneling Configuration 1-67
ii

Expedite termination No No No No
1 Tunneling Configuration
When configuring tunneling, go to these sections for information you are interested in:
z Introduction to Tunneling
z Tunneling Configuration Task List
z Configuring IPv6 Manual Tunnel
z Configuring Automatic IPv4-Compatible IPv6 Tunnel
z Configuring 6to4 Tunnel
z Configuring ISATAP Tunnel
z Configuring IPv4 over IPv4 Tunnel
z Displaying and Maintaining Tunneling Configuration
z Troubleshooting Tunneling Configuration
The format of a tunnel interface number for centralized devices is different from that for distributed
devices. For centralized devices, the tunnel interface number is in the X format, where the value range
of X depends on the device model. For distributed devices, the tunnel interface number is in the A/B/C
format, where A, B, and C represent the slot number of a card, the slot number of a sub-card, and the
tunnel interface number respectively. The value ranges of A, B and C vary with devices. Only the tunnel
interface of centralized devices is covered in this document.
1-1
Introduction to Tunneling
The expansion of the Internet results in scarce IPv4 addresses. The technologies such as temporary
IPv4 address allocation and Network Address Translation (NAT) relieve the problem of IPv4 address
shortage to some extent. However, these technologies not only increase the overhead in address
resolution and processing, but also lead to upper-layer application failures. Furthermore, they will still
face the problem that IPv4 addresses will eventually be used up. Internet Protocol Version 6 (IPv6)
adopting the 128-bit addressing scheme completely solves the above problem. Since significant
improvements have been made in address space, security, network management, mobility, and QoS,
IPv6 becomes one of the core standards for the next generation Internet protocol. IPv6 is compatible
with all protocols except IPv4 in the TCP/IP suite. Therefore, IPv6 can completely take the place of IPv4.
Before IPv6 becomes the dominant protocol, networks using the IPv6 protocol stack are expected to
communicate with the Internet using IPv4. Therefore, an IPv6-IPv4 interworking technology must be
developed to ensure the smooth transition from IPv4 to IPv6. In addition, the interworking technology
should provide efficient, seamless information transfer. The Internet Engineering Task Force (IETF)
sets up the next generation transition (NGTRANS) working group to study problems about IPv4-to-IPv6
transition and efficient, seamless IPv4-IPv6 interworking. Currently, multiple transition technologies and
interworking solutions are available. With their own characteristics, they are used to solve
communication problems in different transition stages under different environments.
Currently, there are three major transition technologies: dual stack (RFC 2893), tunneling (RFC 2893),
and NAT-PT (RFC 2766).
Tunneling is an encapsulation technology, which utilizes one network protocol to encapsulate packets of
another network protocol and transfer them over the network. A tunnel is a virtual point-to-point
connection. In practice, the virtual interface that supports only point-to-point connections is called tunnel
interface. One tunnel provides one channel to transfer encapsulated packets. Packets can be
encapsulated and decapsulated at both ends of a tunnel. Tunneling refers to the whole process from
data encapsulation to data transfer to data decapsulation.
z For related configuration about the dual protocol stack, refer to Dual Stack Configuration in the IP
Services Volume.
z For related configuration about NAT-PT, refer to NAT-PT Configuration in the IP Services Volume.
z The device supports IPv6 on the provider edge routers (6PE) a transition technology.
IPv6 over IPv4 Tunnel
Implementation
The IPv6 over IPv4 tunneling mechanism encapsulates an IPv4 header in IPv6 data packets so that
IPv6 packets can pass an IPv4 network through a tunnel to realize interworking between isolated IPv6
networks, as shown in Figure 1-1.
1-2
The devices at both ends of an IPv6 over IPv4 tunnel must support IPv4/IPv6 dual stack.
Figure 1-1 IPv6 over IPv4 tunnel
The IPv6 over IPv4 tunnel processes packets in the following way:
1) A host in the IPv6 network sends an IPv6 packet to the device at the source end of the tunnel.
2) After determining according to the routing table that the packet needs to be forwarded through the
tunnel, the device at the source end of the tunnel encapsulates the IPv6 packet with an IPv4
header and forwards it through the physical interface of the tunnel.
3) The encapsulated packet goes through the tunnel to reach the device at the destination end of the
tunnel. The device at the destination end decapsulates the packet if the destination address of the
encapsulated packet is the device itself.
4) The destination device forwards the packet according to the destination address in the
decapsulated IPv6 packet. If the destination address is the device itself, the device forwards the
IPv6 packet to the upper-layer protocol for processing.
Configured tunnel and automatic tunnel
An IPv6 over IPv4 tunnel can be established between hosts, between hosts and devices, and between
devices. The tunnel destination needs to forward packets if the tunnel destination is not the final
destination of the IPv6 packet.
Tunnels are divided into configured tunnels and automatic tunnels depending on how the IPv4 address
of the tunnel destination is acquired.
z If the destination address of an IPv6 over IPv4 tunnel cannot be acquired from the destination
address of IPv6 packets, it needs to be configured manually. Such a tunnel is called a configured
tunnel.
z If the interface address of an IPv6 over IPv4 tunnel has an IPv4 address embedded into an IPv6
address, the IPv4 address of the tunnel destination can be acquired automatically. Such a tunnel is
called an automatic tunnel.
Type
According to the way an IPv6 packet is encapsulated, IPv6 over IPv4 tunnels are divided into the
following types:
1-3
Tunnel type Tunnel mode
IPv6 manual tunnel
Manually configured tunnel IPv6-over-IPv4 generic routing encapsulation (GRE) tunnel (GRE
tunnel for short)
Automatic IPv4-compatible IPv6 tunnel
Automatic tunnel 6to4 tunnel
Intra-site automatic tunnel addressing protocol (ISATAP) tunnel
The configuration parameters for each tunnel mode are listed in the following table:
Source/destination IP address of the IP address of the tunnel

Tunnel mode
tunnel interface
IPv6 manual The source/destination IP address is a
IPv6 address
tunnel manually configured IPv4 address.
The source IP address is a manually

Automatic IPv4-compatible IPv6 address, in
configured IPv4 address, while the
IPv4-compatible the format
destination IP address does not need to
IPv6 tunnel of ::IPv4-source-address/96
be configured.
configured IPv4 address, while the 6to4 address, in the format of
6to4 tunnel
destination IP address does not need to 2002:IPv4-source-address::/48
be configured.
ISATAP address, in the format of
configured IPv4 address, while the
ISATAP tunnel Prefix:0:5EFE:IPv4-source-addre
destination IP address does not need to
ss/64
be configured.
IPv6-over-IPv4 The source/destination IP address is a
IPv6 address
GRE tunnel manually configured IPv4 address.
1) IPv6 manually configured tunnel

A manually configured tunnel is a point-to-point link. Each link is a separate tunnel. IPv6 manually
configured tunnels are mainly used to provide stable connections for regular secure communication
between border routers or between border routers and hosts for access to remote IPv6 networks.
2) Automatic IPv4-compatible IPv6 tunnel
An automatic IPv4-compatible IPv6 tunnel is a point-to-multipoint link. IPv4-compatible IPv6 addresses
are adopted at both ends of such a tunnel. The address format is 0:0:0:0:0:0:a.b.c.d/96, where a.b.c.d
represents an embedded IPv4 address. The tunnel destination is automatically determined by the
embedded IPv4 address, which makes it easy to create a tunnel for IPv6 over IPv4. However, an
automatic IPv4-compatible IPv6 tunnel must use IPv4-compatible IPv6 addresses and it is still
dependent on IPv4 addresses. Therefore, automatic IPv4-compatible IPv6 tunnels have limitations.
3) 6to4 tunnel
z Ordinary 6to4 tunnel
An automatic 6to4 tunnel is a point-to-multipoint tunnel and is used to connect multiple isolated IPv6
networks over an IPv4 network to remote IPv6 networks. The embedded IPv4 address in an IPv6
address is used to automatically acquire the destination IPv4 address of the tunnel.
The automatic 6to4 tunnel adopts 6to4 addresses. The address format is 2002:abcd:efgh:subnet
1-4
number::interface ID/64, where 2002 represents the fixed IPv6 address prefix, and abcd:efgh
represents the 32-bit globally unique source IPv4 address of the 6to4 tunnel, in hexadecimal notation.
For example, 1.1.1.1 can be represented by 0101:0101. The part that follows 2002:abcd:efgh uniquely
identifies a host in a 6to4 network. The tunnel destination is automatically determined by the embedded
IPv4 address, which makes it easy to create a 6to4 tunnel.
Because the 16-bit subnet number of the 64-bit address prefix in 6to4 addresses can be customized
and the first 48 bits in the address prefix are fixed to a permanent value and the IPv4 address of the
tunnel source or destination, it is possible that IPv6 packets can be forwarded by the tunnel. A 6to4
tunnel interconnects IPv6 networks over an IPv4 network, and overcomes the limitations of an
automatic IPv4-compatible IPv6 tunnel.
z 6to4 relay
A 6to4 tunnel is only used to connect 6to4 networks, whose IP prefix must be 2002::/16. However, IPv6
network addresses with the prefix such as 2001::/16 may also be used in IPv6 networks. To connect a
6to4 network to an IPv6 network, a 6to4 router must be used as a gateway to forward packets to the
IPv6 network. Such a router is called 6to4 relay router.
As shown in Figure 1-2, a static route must be configured on the border router in the 6to4 network and
the next-hop address must be the 6to4 address of the 6to4 relay router. In this way, all packets destined
for the IPv6 network will be forwarded to the 6to4 relay router, and then to the IPv6 network. Thus,
interworking between the 6to4 network (with the address prefix starting with 2002) and the IPv6 network
is realized.
Figure 1-2 Principle of 6to4 tunnel and 6to4 relay
4) ISATAP tunnel
With the application of the IPv6 technology, there will be more and more IPv6 hosts in the existing IPv4
network. The ISATAP tunneling technology provides a satisfactory solution for IPv6 application. An
ISATAP tunnel is a point-to-point automatic tunnel. The destination of a tunnel can automatically be
acquired from the embedded IPv4 address in the destination address of an IPv6 packet.
When an ISATAP tunnel is used, the destination address of an IPv6 packet and the IPv6 address of a
tunnel interface both adopt special ISATAP addresses. The ISATAP address format is
prefix(64bit):0:5EFE:ip-address. The 64-bit prefix is the prefix of a valid IPv6 unicast address, while
ip-address is a 32-bit source IPv4 address in the form of a.b.c.d or abcd:efgh, which need not be
globally unique. Through the embedded IPv4 address, an ISATAP tunnel can automatically be created
to transfer IPv6 packets.
1-5
The ISATAP tunnel is mainly used for connection between IPv6 routers or between a host and an IPv6
router over an IPv4 network.
Figure 1-3 Principle of ISATAP tunnel
5) GRE tunnel
IPv6 packets can be carried over GRE tunnels to pass through the IPv4 network by using standard GRE
protocol to encapsulate them. Like the IPv6 manually configured tunnel, a GRE tunnel is a point-to-point
link, too. Each link is a separate tunnel. GRE tunnels are mainly used to provide stable connections for
regular secure communication between border routers or between hosts and border routers. For related
configurations, refer to GRE Configuration in the VPN Volume.
Expedite termination
For a tunnel packet arriving at the device, if the source IP address matches the address of the expedite
termination subnet, the packet is sent to an IPv6 tunnel protocol engine to forward, or sent to the CPU
for processing. If the tunnel packet needs forwarding, the IPv6 tunnel protocol engine removes the IP
encapsulation to obtain the original IPv6 packet and then forwards it directly.
The IPv6 over IPv4 GRE tunnel supports the expedite termination function. There are two cases:
z The expediting subnet is not applicable to a configured tunnel (for example, GRE tunnel and IPv6
manually configured tunnel). After the expedite termination function is enabled, the system will
automatically consider the destination address of a tunnel as the address of the expedite
termination subnet, and the subnet mask as 255.255.255.255.
z For automatic tunnels (for example, automatic IPv4-compatible IPv6 tunnel, automatic 6to4 tunnel,
and ISATAP tunnel), you must carry out the expediting subnet command to designate an IP
address and subnet mask for the expedite termination subnet after carrying out the expediting
enable command.
IPv4 over IPv4 Tunnel
Introduction to IPv4 over IPv4 tunneling protocol
The IPv4 over IPv4 tunneling protocol (RFC 1853) is developed for IP data packet encapsulation so that
data can be transferred from one IPv4 network to another IPv4 network.
Encapsulation and decapsulation
Packets traveling through a tunnel undergo an encapsulation and decapsulation process. Figure 1-4
shows these two processes.
1-6
Figure 1-4 Principle of IPv4 over IPv4 tunnel
z Encapsulation
The encapsulation process is as follows:
1) The interface of Router A connecting to an IPv4 host receives an IP packet and submits it to the IP
protocol stack for processing.
2) The IP protocol stack determines how to route the packet according to the destination address in
the IP header. If the packet needs to be routed to the IPv4 host connected to Router B, the packet
is sent to Router As tunnel interface that is connected to Router B.
3) After the tunnel interface receives the packet, the packet is encapsulated and submitted to the IP
protocol stack for processing. The IP protocol stack determines the outgoing interface of the tunnel
according to the IP header.
z Decapsulation
Contrary to the encapsulation process, the decapsulation process is as follows:
1) The IP packet received from the IPv4 network interface is sent to the IP protocol stack which then
checks the protocol number in the IP header.
2) If the protocol number is IPv4, the IP packet is sent to the tunnel module for decapsulation.
3) The decapsulated IP packet is sent back to the IP protocol stack for processing.
IPv4/IPv6 over IPv6 Tunnel
Introduction to IPv4/IPv6 over IPv6 tunneling protocol
The IPv4/IPv6 over IPv6 tunneling protocol (RF2473) is developed for IPv4 or IPv6 data packet
encapsulation so that encapsulated packets can be transmitted over an IPv6 network. The
encapsulated packets are IPv6 tunnel packets.
Figure 1-5 Principle of IPv4/IPv6 over IPv6 tunnel
1-7
The original data in Figure 1-5 refers to an IPv4 or IPv6 packet.
Encapsulation and decapsulation
The encapsulation process is as follows:

1) After receiving the original packet, the interface of Router A connecting private network A submits it
to the corresponding data module for processing. The data module then determines how to route
the packet.
2) If the packet needs to be routed to Host B connected to Router B, the packet is sent to Router As
tunnel interface that is connected to Router B.
3) After receiving the packet, the tunnel interface adds an IPv6 header to it and submits it to the IPv6
module for processing.
4) The IPv6 module re-determines a route according to the destination address in the IPv6 header.
Contrary to the encapsulation process, the decapsulation process is as follows:
1) The packet received from the IPv6 network interface is sent to the IPv6 module for processing.
2) If the passenger protocol is IPv4 or IPv6, the packet is sent to the tunnel processing module for
decapsulation.
3) The decapsulated packet is sent to the corresponding protocol module for the secondary routing
process.
GRE can realize the IPv4/IPv6 over IPv6 tunnel function. For related configurations, refer to GRE
Configuration in the VPN Volume.
6PE Overview
IPv6 on the provider edge routers (6PE) is a transition technology by which Internet service providers
(ISPs) can use existing IPv4 backbone networks to allow communications between isolated IPv6
networks.
The major concept of the 6PE is that the IPv6 routing information of users is converted into IPv6 routing
information with labels and is spread into IPv4 backbone networks of ISPs through Internal Border
Gateway Protocol (IBGP) sessions. When IPv6 packets are forwarded, traffic will be labeled after
entering tunnels of backbone networks. The tunnels can be GRE tunnels or MPLS LSPs.
Figure 1-6 Network diagram for 6PE
When an ISP wants to utilize the existing IPv4/MPLS network to provide IPv6 traffic switching capability
through MPLS, only the PE routers need to be upgraded. Therefore, it is a high efficient solution that
1-8
ISPs use the 6PE technology as an IPv6 transition mechanism. Furthermore, the operation risk of the
6PE technology is very low.
For more information or configuration related to 6PE, refer to IPv6 BGP Configuration in the IP Routing
Volume.
RFC 1853: IP in IP Tunneling

RFC 2473: Generic Packet Tunneling in IPv6 Specification
RFC 2893: Transition Mechanisms for IPv6 Hosts and Routers
RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
RFC 4214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Tunneling Configuration Task List

Complete the following tasks to configure the tunneling feature:
Task Remarks
Configuring IPv6 Manual Tunnel Optional
Configuring IPv6 Configuring Automatic IPv4-Compatible IPv6 Tunnel Optional

over IPv4 tunnel Configuring 6to4 Tunnel Optional
Configuring ISATAP Tunnel Optional
Configuring IPv4 over IPv4 Tunnel Optional
Configuring IPv6 Manual Tunnel

z Configure IP addresses for interfaces (such as the VLAN interface, Ethernet interface, and
loopback interface) on the device to ensure normal communication.
z Specify one of the above interfaces as the source interface of the tunnel.
z Ensure reachability between the tunnel source and destination addresses.
1-9
Follow these steps to configure an IPv6 manual tunnel:

Required
Enable IPv6 ipv6 By default, the IPv6 packet
forwarding function is disabled.
Required
Create a tunnel interface and
interface tunnel number By default, there is no tunnel
enter tunnel interface view
interface on the device.
Configure a ipv6 address { ipv6-address Required

global prefix-length | Use either command.
unicast IPv6 ipv6-address/prefix-length }
By default, no IPv6 global unicast
address or a ipv6 address address or site-local address is
site-local ipv6-address/prefix-length configured for the tunnel
Configure an
address eui-64 interface.
IPv6 address
for the tunnel
interface ipv6 address auto link-local Optional
Configure a By default, a link-local address
link-local will automatically be created
ipv6 address ipv6-address when an IPv6 global unicast
IPv6 address link-local address or site-local address is
configured.
Required
By default, the tunnel is a GRE
Specify the IPv6 manual tunnel. The same tunnel mode
tunnel-protocol ipv6-ipv4
tunnel mode should be configured at both ends
of the tunnel. Otherwise, packet
delivery will fail.
Required
source { ip-address |
Configure a source address or By default, no source address or
interface-type
interface for the tunnel interface is configured for the
interface-number }
tunnel.
Required
Configure a destination
destination ip-address By default, no destination address
address for the tunnel
is configured for the tunnel.
Optional
Reference a service loopback service-loopback-group By default, the tunnel does not
group number reference any service loopback
group.
Optional
Enable the expedite
expediting enable By default, the expedite
termination function
termination function is disabled.
Optional
Configure the IPv6 MTU of the
ipv6 mtu mtu-size The default value depends on the
tunnel interface
device model.
1-10
z Support for the service-loopback-group and expediting enable commands depends on the
device model.
z For the configuration of IPv6 MTU of a tunnel interface, refer to the ipv6 mtu command in IPv6
Basics Commands of the IP Services Volume.
z When you create a tunnel interface on a distributed device, the slot of the tunnel interface is
recommended to be that of the source interface, namely, the interface sending packets. In this way,
the forwarding efficiency can be improved.
z For a distributed device, the tunnel configuration is not removed from the active board upon
switchover or from the standby board upon its removal. If you configure the same tunnel, the
system will display the prompt that the tunnel still exists. To delete the tunnel interface, use the
undo interface tunnel command.
z After a tunnel interface is deleted, all the above features configured on the tunnel interface will be
deleted.
z If the addresses of the tunnel interfaces at the two ends of a tunnel are not in the same network
segment, a forwarding route through the tunnel to the peer must be configured so that the
encapsulated packet can be forwarded normally. You need to configure static or dynamic routing at
both ends of the tunnel. For detailed configuration, refer to Static Routing Configuration or other
routing protocol configuration in the IP Routing Volume.
z When you configure a static route at one tunnel end, you need to configure a route to the
destination IPv6 address of the packet, instead of the IPv4 address of the tunnel destination, and
set the outbound interface to the tunnel interface at the local end or set the next-hop to the tunnel
interface at the peer end. The similar configuration needs to be performed at the other tunnel end.
z When you configure dynamic routing at both tunnel ends, you need to enable the dynamic routing
protocol on the tunnel interfaces. For related configurations, refer to related contents in the IP
Routing Volume.
z To reference a service loopback group on the tunnel interface, you must have created the service
loopback group. Otherwise, the tunnel interface will not be up. For devices that do not support
service loopback, no service loopback group needs to be referenced on the tunnel interface. For
creation and configuration of a service loopback group, refer to Service Loopback Configuration in
the Access Volume.
As shown in Figure 1-7, two IPv6 networks are connected to an IPv4 network through Router A and
Router B respectively. Router A and Router B are reachable to each other. Configure an IPv6 manual
tunnel between Router A and Router B to make the two IPv6 networks reachable to each other.
1-11
Network diagram
Figure 1-7 Network diagram for an IPv6 manual tunnel (on routers)
z Configuration on Router A
# Enable IPv6.
[RouterA] ipv6
# Configure an IPv4 address for Ethernet 1/0.


[RouterA-Ethernet1/1] ipv6 address 3002::1 64
# Configure an IPv6 manual tunnel.

[RouterA] interface tunnel 0
[RouterA-Tunnel0] ipv6 address 3001::1/64
[RouterA-Tunnel0] source ethernet 1/0
[RouterA-Tunnel0] destination 192.168.50.1
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4
[RouterA-Tunnel0] quit
# Configure a static route to IPv6 Group 2 through tunnel 0 on Router A.

[RouterA] ipv6 route-static 3003:: 64 tunnel 0
# Enable IPv6.
[RouterB] ipv6


1-12

[RouterB] interface tunnel 0
[RouterB-Tunnel0] ipv6 address 3001::2/64
[RouterB-Tunnel0] source ethernet 1/0
[RouterB-Tunnel0] destination 192.168.100.1
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4
[RouterB-Tunnel0] quit
# Configure a static route to IPv6 Group 1 through tunnel 0 on Router B.

[RouterB] ipv6 route-static 3002:: 64 tunnel 0
Configuration verification
After the above configurations, display the status of the tunnel interfaces on Router A and Router B,
respectively:
[RouterA] display ipv6 interface tunnel 0 verbose
Tunnel0 current state :UP
IPv6 is enabled, link-local address is FE80::C0A8:6401
3000::1, subnet is 3000::/64
FF02::1:FFA8:6401
FF02::1:FF00:1
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
InReceives: 55
...
[RouterB] display ipv6 interface tunnel 0 verbose
3000::1, subnet is 3000::/64
FF02::1:FFA8:3201
FF02::1:FF00:1
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
1-13
InReceives: 55
...
# Ping the IPv6 address of Ethernet 1/1 at the peer end from Router A:
[RouterA] ping ipv6 3003::1
Reply from 3003::1
Reply from 3003::1
Reply from 3003::1
Reply from 3003::1
Reply from 3003::1

0.00% packet loss
As shown in Figure 1-8, two IPv6 networks are connected to an IPv4 network through Switch A and
Switch B respectively. Switch A and Switch B are reachable to each other. Configure an IPv6 manual
tunnel between Switch A and Switch B to make the two IPv6 networks reachable to each other.
Network diagram
Figure 1-8 Network diagram for an IPv6 manual tunnel (on switches)
z Configuration on Switch A
1-14
# Enable IPv6.
[SwitchA] ipv6
# Configure an IPv4 address for VLAN-interface 100.


[SwitchA-Vlan-interface101] ipv6 address 3002::1 64
# Configure a manual IPv6 tunnel.

[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] ipv6 address 3001::1/64
[SwitchA-Tunnel0] source vlan-interface 100
[SwitchA-Tunnel0] destination 192.168.50.1
[SwitchA-Tunnel0] tunnel-protocol ipv6-ipv4
[SwitchA-Tunnel0] quit
# Configure a static route to IPv6 Group 2 through tunnel 0 on Switch A.

[SwitchA] ipv6 route-static 3003:: 64 tunnel 0
z Configuration on Switch B
# Enable IPv6.
[SwitchB] ipv6

[SwitchB] vlan 100
[SwitchB-vlan100] port ethernet 1/0
[SwitchB-vlan100] quit


[SwitchB] interface tunnel 0
[SwitchB-Tunnel0] ipv6 address 3001::2/64
[SwitchB-Tunnel0] source vlan-interface 100
[SwitchB-Tunnel0] destination 192.168.100.1
[SwitchB-Tunnel0] tunnel-protocol ipv6-ipv4
[SwitchB-Tunnel0] quit
# Configure a static route to IPv6 Group 1 through tunnel 0 on Switch B.
1-15
[SwitchB] ipv6 route-static 3002:: 64 tunnel 0
After the above configurations, display the status of the tunnel interfaces on Switch A and Switch B,
respectively.
[SwitchA] display ipv6 interface tunnel 0 verbose
3000::1, subnet is 3000::/64
FF02::1:FFA8:6401
FF02::1:FF00:1
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
InReceives: 55
...
[SwitchB] display ipv6 interface tunnel 0 verbose
3000::1, subnet is 3000::/64
FF02::1:FFA8:3201
FF02::1:FF00:1
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
InReceives: 55
...
# Ping the IPv6 address of VLAN-interface 102 at the peer end from Switch A.
[SwitchA] ping ipv6 3003::1
Reply from 3003::1
1-16
Reply from 3003::1
Reply from 3003::1
Reply from 3003::1
Reply from 3003::1

0.00% packet loss
Configuring Automatic IPv4-Compatible IPv6 Tunnel

Follow these steps to configure an automatic IPv4-compatible IPv6 tunnel:

Required
Enable the IPv6 packet
ipv6 By default, the IPv6 packet forwarding
forwarding function
function is disabled.
Create a tunnel interface Required

and enter tunnel interface interface tunnel number By default, there is no tunnel interface
view on the device.
ipv6 address
Configure an { ipv6-address prefix-length Required
IPv6 global | Use either command.
unicast ipv6-address/prefix-length }
Configure address or a By default, no IPv6 global unicast
an IPv6 site-local ipv6 address address or site-local address is
address address ipv6-address/prefix-length configured for the tunnel interface.
for the eui-64
tunnel
interface ipv6 address auto Optional
Configure an link-local
IPv6 By default, a link-local address will
link-local automatically be generated when an
ipv6 address ipv6-address IPv6 global unicast or site-local address
address link-local is configured for the interface.
1-17
Required
Configure an automatic By default, the tunnel is a GRE tunnel.
tunnel-protocol ipv6-ipv4
IPv4-compatible IPv6 The same tunnel mode should be
auto-tunnel
tunnel configured at both ends of the tunnel.
Otherwise, packet delivery will fail.
Configure a source source { ip-address | Required

address or interface for the interface-type By default, no source address or
tunnel interface-number } interface is configured for the tunnel.
Optional
Reference a service service-loopback-group
loopback group number By default, the tunnel interface does not
reference any service loopback group.
Optional
Enable the expedite
expediting enable By default, the expedite termination
Configure an address and Optional

expediting subnet
mask for the expedite By default, no expedite termination
ip-address mask
termination subnet subnet is configured for a tunnel.
Optional
Configure the IPv6 MTU
on the tunnel interface
device model.
device model.
z For the configuration of the IPv6 MTU on a tunnel interface, refer to the ipv6 mtu command in IPv6
1-18
z No destination address needs to be configured for an automatic IPv4-compatible IPv6 tunnel.
segment, a route to the peer must be configured so that the encapsulated packet can be forwarded
normally. You can configure static or dynamic routing. Automatic tunnels do not support dynamic
routing. You need to configure a route to the peer at both ends of the tunnel. For the detailed
configuration, refer to Static Routing Configuration or other routing protocol configuration in the IP
Routing Volume.
z The automatic tunnel interfaces using the same encapsulation protocol cannot share the same
source IP address.
z To reference a service loopback group on the tunnel interface, you must have created the service
loopback group. Otherwise, the tunnel interface will not be up. For devices that do not support
service loopback, no service loopback group needs to be referenced on the tunnel interface. For
creation and configuration of a service loopback group, refer to Service Loopback Configuration in
the Access Volume.
As shown in Figure 1-9, two IPv6 networks are connected to an IPv4 network through Router A and
Router B respectively. Router A and Router B are reachable to each other. Configure an automatic
IPv4-compatible IPv6 tunnel between Router A and Router B to make the two IPv6 networks reachable
to each other.
1-19
Network diagram
Figure 1-9 Network diagram for an automatic IPv4-compatible IPv6 tunnel (on routers)
# Enable IPv6.
[RouterA] ipv6

# Configure an automatic IPv4-compatible IPv6 tunnel.

[RouterA-Tunnel0] ipv6 address ::192.168.100.1/96
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 auto-tunnel
# Enable IPv6.
[RouterB] ipv6


[RouterB-Tunnel0] ipv6 address ::2.1.1.2/96
[RouterB-Tunnel0] source serial 2/0
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 auto-tunnel
After the above configurations, display the status of the tunnel interfaces on Router A and Router B,
respectively.
[RouterA] display ipv6 interface tunnel 0 verbose
1-20
::192.168.100.1, subnet is ::/96
FF02::1:FFA8:6401
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
InReceives: 65
...
[RouterB] display ipv6 interface tunnel 0 verbose
::192.168.50.1, subnet is ::/96
FF02::1:FFA8:3201
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
InReceives: 65
...
# Ping the IPv4-compatible IPv6 address at the peer end from Router A.
[RouterA] ping ipv6 ::192.168.50.1
PING ::192.168.50.1 : 56 data bytes, press CTRL_C to break
Reply from ::192.168.50.1
Reply from ::192.168.50.1
Reply from ::192.168.50.1
Reply from ::192.168.50.1
Reply from ::192.168.50.1
1-21
--- ::192.168.50.1 ping statistics ---

0.00% packet loss
As shown in Figure 1-10, two IPv6 networks are connected to an IPv4 network through Switch A and
Switch B respectively. Switch A and Switch B are reachable to each other. Configure an automatic
IPv4-compatible IPv6 tunnel between Switch A and Switch B to make the two IPv6 networks reachable
to each other.
Network diagram
Figure 1-10 Network diagram for an automatic IPv4-compatible IPv6 tunnel (on switches)
# Enable IPv6.
[SwitchA] ipv6


[SwitchA-Tunnel0] ipv6 address ::192.168.100.1/96
[SwitchA-Tunnel0] tunnel-protocol ipv6-ipv4 auto-tunnel
# Enable IPv6.
[SwitchB] ipv6
1-22

[SwitchB-Tunnel0] ipv6 address ::192.168.50.1/96
[SwitchB-Tunnel0] tunnel-protocol ipv6-ipv4 auto-tunnel
After the above configurations, display the status of the tunnel interfaces on Switch A and Switch B,
respectively.
[SwitchA] display ipv6 interface tunnel 0 verbose
::192.168.100.1, subnet is ::/96
FF02::1:FFA8:6401
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
InReceives: 65
...
[SwitchB] display ipv6 interface tunnel 0 verbose
::192.168.50.1, subnet is ::/96
FF02::1:FFA8:3201
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1480 bytes
1-23
InReceives: 65
...
# Ping the IPv4-compatible IPv6 address at the peer end from Switch A.
[RouterA] ping ipv6 ::192.168.50.1
PING ::192.168.50.1 : 56 data bytes, press CTRL_C to break
Reply from ::192.168.50.1
Reply from ::192.168.50.1
Reply from ::192.168.50.1
Reply from ::192.168.50.1
Reply from ::192.168.50.1
--- ::192.168.50.1 ping statistics ---

0.00% packet loss
Configuring 6to4 Tunnel

Follow these steps to configure a 6to4 tunnel:

Required

and enter tunnel interface interface tunnel number By default, there is no tunnel
view interface on the device.
1-24
Configure an ipv6 address { ipv6-address Required.

IPv6 global prefix-length | Use either command.
By default, no IPv6 global
address or a unicast address or site-local
Configure ipv6 address
site-local address is configured for the
an IPv6 ipv6-address/prefix-length eui-64
address tunnel interface.
address
for the
tunnel ipv6 address auto link-local Optional
interface Configure an By default, a link-local address
IPv6 link-local will automatically be generated
ipv6 address ipv6-address when an IPv6 global unicast
address link-local address or site-local address is
configured.
Required
Set a 6to4 tunnel tunnel-protocol ipv6-ipv4 6to4 tunnel. The same tunnel mode
should be configured at both
ends of the tunnel. Otherwise,
packet delivery will fail.
Required
Configure a source address source { ip-address | By default, no source address or
or interface for the tunnel interface-type interface-number } interface is configured for the
tunnel.
Optional
loopback group number By default, no service loopback
group is referenced.
Optional
Enable the expedite
expediting enable By default, the expedite
termination function is disabled.
Optional
Configure an address and
expediting subnet ip-address By default, no expedite
mask for the expedite
mask termination subnet is configured
termination subnet
for a tunnel.
Optional
Configure the IPv6 MTU on
ipv6 mtu mtu-size The default value depends on
the tunnel interface
the device model.
device model.
z For the configuration of the MTU of IPv6 packets sent over a tunnel interface, refer to the ipv6 mtu
command in IPv6 Basics Commands of the IP Services Volume.
1-25
z No destination address needs to be configured for an automatic tunnel because the destination
address can automatically be obtained from the IPv4 address embedded in the IPv4-compatible
IPv6 address.
segment, a route to the peer must be configured so that the encapsulated packet can be forwarded
normally. You can configure static or dynamic routing. Automatic tunnels do not support dynamic
routing. You need to configure a route to the peer at both end of the tunnel. For the detailed
configuration, refer to Static Routing Configuration or other routing protocol configuration in the IP
Routing Volume.
source IP address.
z If some devices need to reference a service loopback group on the tunnel interface to receive and
send packets, you must have configured the service loopback group. Otherwise, the tunnel
interface will not be up to communicate. For devices that do not support service loopback, no
service loopback group needs to be configured on the tunnel interface. For creation and
configuration of a service loopback group, refer to Service Loopback Configuration in the Access
Volume.
6to4 Tunnel Configuration Example (on Routers)
As shown in Figure 1-11, two 6to4 networks are connected to an IPv4 network through two 6to4 routers
(Router A and Router B) respectively. Configure a 6to4 tunnel to make Host A and Host B reachable to
each other.
To enable communication between 6to4 networks, you need to configure 6to4 addresses for 6to4
routers and hosts in the 6to4 networks.
z The IPv4 address of Ethernet 1/0 on Router A is 2.1.1.1/24, and the corresponding 6to4 prefix is
2002:0201:0101::/48 after it is translated to an IPv6 address. Assign interface tunnel 0 to subnet
2002:0201:0101::/64 and Ethernet 1/1 to subnet 2002:0201:0101:1::/64.
z The IPv4 address of Ethernet 1/0 on Router B is 5.1.1.1/24, and the corresponding 6to4 prefix is
2002:0501:0101::/48 after it is translated to an IPv6 address. Assign interface tunnel 0 to subnet
2002:0501:0101::/64 and Ethernet 1/1 to subnet 2002:0501:0101:1::/64.
1-26
Network diagram
Figure 1-11 Network diagram for a 6to4 tunnel (on routers)
z Configuration on Router A.
# Enable IPv6.
[RouterA] ipv6

# Configure a route from Ethernet 1/0 of Router A to Ethernet 1/0 of Router B. (Here the next-hop
address of the static route is represented by [nexthop]. In practice, you should configure the real
next-hop address according to the network.)
[RouterA] ip route-static 5.1.1.1 24 [nexthop]

[RouterA-Ethernet1/1] ipv6 address 2002:0201:0101:1::1/64
# Configure the 6to4 tunnel.

[RouterA-Tunnel0] ipv6 address 2002:201:101::1/64
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
# Configure a static route whose destination address is 2002::/16 and next-hop is the tunnel interface.
# Enable IPv6.
[RouterB] ipv6
1-27
# Configure a route from Ethernet 1/0 of Router B to Ethernet 1/0 of Router A. (Here the next-hop
[RouterB] ip route-static 2.1.1.1 24 [nexthop]

[RouterB-Ethernet1/1] ipv6 address 2002:0501:0101:1::1/64
# Configure a 6to4 tunnel.

[RouterB-Tunnel0] ipv6 address 2002:0501:0101::1/64
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
[RouterB] ipv6 route-static 2002:: 16 tunnel 0
After the above configuration, ping Host B from Host A or ping Host A from Host B.
D:\>ping6 -s 2002:201:101:1::2 2002:501:101:1::2
Pinging 2002:501:101:1::2
from 2002:201:101:1::2 with 32 bytes of data:
Reply from 2002:501:101:1::2: bytes=32 time=13ms

Reply from 2002:501:101:1::2: bytes=32 time<1ms
Ping statistics for 2002:501:101:1::2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 13ms, Average = 3ms
6to4 Tunnel Configuration Example (on Switches)
As shown in Figure 1-12, two 6to4 networks are connected to an IPv4 network through two 6to4
switches (Switch A and Switch B) respectively. Configure a 6to4 tunnel to make Host A and Host B
reachable to each other.
1-28
To enable communication between 6to4 networks, you need to configure 6to4 addresses for 6to4
switches and hosts in the 6to4 networks.
z The IPv4 address of VLAN-interface 100 on Switch A is 2.1.1.1/24, and the corresponding 6to4
prefix is 2002:0201:0101::/48 after it is translated to an IPv6 address. Assign interface tunnel 0 to
subnet 2002:0201:0101::/64 and VLAN-interface 101 to subnet 2002:0201:0101:1::/64.
z The IPv4 address of VLAN-interface 100 on Switch B is 5.1.1.1/24, and the corresponding 6to4
prefix is 2002:0501:0101::/48 after it is translated to an IPv6 address. Assign interface tunnel 0 to
subnet 2002:0501:0101::/64 and VLAN-interface 101 to subnet 2002:0501:0101:1::/64.
Network diagram
Figure 1-12 Network diagram for a 6to4 tunnel (on switches)
# Enable IPv6.
[SwitchA] ipv6

[SwitchA] vlan 100
[SwitchA-vlan100] port ethernet 1/0
[SwitchA-vlan100] quit
# Configure a route from VLAN-interface 100 of Switch A to VLAN-interface 100 of Switch B. (Here the
next-hop address of the static route is represented by [nexthop]. In practice, you should configure the
real next-hop address according to the network.)
[SwitchA] ip route-static 5.1.1.1 24 [nexthop]

[SwitchA] vlan 101
[SwitchA-Vlan-interface101] ipv6 address 2002:0201:0101:1::1/64
1-29

[SwitchA-Tunnel0] ipv6 address 2002:201:101::1/64
[SwitchA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
# Enable IPv6.
[SwitchB] ipv6

[SwitchB] vlan 100
# Configure a route from VLAN-interface 100 of Switch B to VLAN-interface 100 of Switch A. (Here the
[SwitchB] ip route-static 2.1.1.1 24 [nexthop]

[SwitchB] vlan 101
[SwitchB-Vlan-interface101] ipv6 address 2002:0501:0101:1::1/64

[SwitchB-Tunnel0] ipv6 address 2002:0501:0101::1/64
[SwitchB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
# Configure a static route whose destination address is 2002::/16 and the next hop is the tunnel
interface.
[SwitchB] ipv6 route-static 2002:: 16 tunnel 0
After the above configuration, ping Host B from Host A or ping Host A from Host B.
1-30
D:\>ping6 -s 2002:201:101:1::2 2002:501:101:1::2
Pinging 2002:501:101:1::2

Reply from 2002:501:101:1::2: bytes=32 time<1ms
Ping statistics for 2002:501:101:1::2:

6to4 Relay Configuration Example (on Routers)
As shown in Figure 1-13, Router A is a 6to4 router, and 6to4 addresses are used on the connected IPv6
network. Router B serves as a 6to4 relay router and is connected to the IPv6 network (2001::/16).
Configure a 6to4 tunnel between Router A and Router B to make Host A and Host B reachable to each
other.
Network diagram
Figure 1-13 Network diagram for a 6to4 relay (on routers)
6to4 router 6to4 delay

Eth1/0 Eth1/0
2.1.1.1/24 6.1.1.1/24
Router A IPv4 netwok
Router B
Eth1/1 Tunnel 0 Tunnel 0 Eth1/1
2002:0201:0101:1::1/64 2002:0201:0101::1/64 2002:0601:0101::1/64 2001::1/64
6to4 network IPv6 network
Host A Host B
2002:0201:0101:1::2/64 2001::2/64
The configuration on a 6to4 relay router is similar to that on a 6to4 router. However, to enable
communication between the 6to4 network and the IPv6 network, you need to configure a static route to
the IPv6 network on the 6to4 router.
# Enable IPv6.
[RouterA] ipv6
1-31
# Configure a route from Ethernet 1/0 of Router A to Ethernet 1/0 of Router B. (Here the next-hop
[RouterA] ip route-static 6.1.1.1 24 [nexthop]

[RouterA-Ethernet1/1] ipv6 address 2002:0201:0101:1::1/64

[RouterA-Tunnel0] ipv6 address 2002:0201:0101::1/64
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
# Configure the default route to the IPv6-only network.

[RouterA] ipv6 route-static :: 0 2001:0601:0101::1
# Enable IPv6.
[RouterB] ipv6

# Configure a route from Ethernet 1/0 of Router B to Ethernet 1/0 of Router A. (Here the next-hop
[RouterB] ip route-static 2.1.1.1 24 [nexthop]

[RouterB-Ethernet1/1] ipv6 address 2001::1/16

[RouterB-Tunnel0] ipv6 address 2001:0601:0101::1/64
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
1-32
After the above configuration, ping Host B from Host A.

D:\>ping6 -s 2002:201:101:1::2 2001::2
Pinging 2001::2
Reply from 2001::2: bytes=32 time=13ms

Reply from 2001::2: bytes=32 time<1ms
Ping statistics for 2001::2:

6to4 Tunnel Configuration Example (on Switches)
As shown in Figure 1-14, Switch A is a 6to4 switch, and 6to4 addresses are used on its IPv6 network.
Switch B serves as a 6to4 relay switch and is connected to the IPv6 network (2001::/16). Configure a
6to4 tunnel between Switch A and Switch B to make Host A and Host B reachable to each other.
Network diagram
Figure 1-14 Network diagram for a 6to4 relay (on switches)
6to4 switch 6to4 delay

2.1.1.1/24 6.1.1.1/24
Switch A IPv4 netwok Switch B
Vlan-int101 Tunnel 0 Tunnel 0 Vlan-int101
2002:0201:0101:1::1/64 2002:0201:0101::1/64 2002:0601:0101::1/64 2001::1/64
6to4 network IPv6 network
Host A Host B
2002:0201:0101:1::2/64 2001::2/64
The configuration on a 6to4 relay switch is similar to that on a 6to4 switch. However, to enable
communication between the 6to4 network and the IPv6 network, you need to configure a static route to
the IPv6 network on the 6to4 switch.
1-33
# Enable IPv6.
[SwitchA] ipv6

[SwitchA] vlan 100
# Configure a route from VLAN-interface 100 of Switch A to VLAN-interface 100 of Switch B. (Here the
[SwitchA] ip route-static 6.1.1.1 24 [nexthop]

[SwitchA] vlan 101
[SwitchA-Vlan-interface101] ipv6 address 2002:0201:0101:1::1/64

[SwitchA-Tunnel0] ipv6 address 2002:0201:0101::1/64
[SwitchA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
# Configure a default route to the IPv6-only network.

[SwitchA] ipv6 route-static :: 0 2001:0601:0101::1
# Enable IPv6.
[SwitchB] ipv6

[SwitchB] vlan 100
1-34
# Configure a route from VLAN-interface 100 of Switch B to VLAN-interface 100 of Switch A. (Here the
[SwitchB] ip route-static 2.1.1.1 24 [nexthop]

[SwitchB] vlan 101
[SwitchB-Vlan-interface101] ipv6 address 2001::1/16

[SwitchB-Tunnel0] ipv6 address 2001:0601:0101::1/64
[SwitchB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
After the above configuration, ping Host B from Host A.

D:\>ping6 -s 2002:201:101:1::2 2001::2
Pinging 2001::2

Reply from 2001::2: bytes=32 time<1ms
Ping statistics for 2001::2:

Configuring ISATAP Tunnel

1-35
Follow these steps to configure an ISATAP tunnel:

Required
Enable IPv6 ipv6 By default, the IPv6 forwarding

and enter tunnel interface interface tunnel number By default, there is no tunnel
view interface on the device.
Configure an ipv6 address { ipv6-address

Required.
IPv6 global prefix-length |
ipv6-address/prefix-length } Use either command.
unicast
Configur address or By default, no IPv6 global unicast
ipv6 address
e an IPv6 site-local address is configured for the tunnel
ipv6-address/prefix-length
address address interface.
eui-64
for the
tunnel ipv6 address auto link-local Optional
interface Configure an By default, a link-local address will
IPv6 link-local ipv6 address ipv6-address automatically be generated when an
address link-local IPv6 global unicast address or
link-local address is configured.
Required
tunnel-protocol ipv6-ipv4 tunnel. The same tunnel mode
Set an ISATAP tunnel
isatap should be configured at both ends of
the tunnel. Otherwise, packet
delivery will fail.
Configure a source source { ip-address | Required

address or interface for the interface-type By default, no source address or
tunnel interface-number } interface is configured for the tunnel.
Optional
loopback group number By default, no service loopback group
ID is referenced.
Optional
Enable the expedite
expediting enable By default, the expedite termination
Configure an address and Optional

expediting subnet ip-address
mask for the expedite By default, no expedite termination
mask
termination subnet subnet is configured for a tunnel.
Optional
Configure the IPv6 MTU
on the tunnel interface
device model.
1-36
z Support for the service-loopback-group, expediting enable, and expediting subnet commands
z For the IPv6 MTU configuration on a tunnel interface, refer to the ipv6 mtu command in IPv6
segment, a route to the peer must be configured at both ends so that the encapsulated packet can
be forwarded normally. You can configure static or dynamic routing. Automatic tunnels do not
support dynamic routing. For the detailed configuration, refer to Static Routing Configuration or
other routing protocol configuration in the IP Routing Volume.
source IP address.
z If some devices need to reference a service loopback group ID on the tunnel interface to receive
and send packets, you must have configured the service loopback group. Otherwise, the tunnel
service loopback group ID needs to be configured on the tunnel interface. For creation and
Volume.
Configuration Example (on a Router)
As shown in Figure 1-15, an IPv6 network is connected to an IPv4 network through an ISATAP router. It
is required that the IPv6 host in the IPv4 network can access the IPv6 network through the ISATAP
tunnel.
1-37
Network diagram
Figure 1-15 Network diagram for an ISATAP tunnel (on a router)
z Configuration on the ISATAP router

# Enable IPv6.
[Router] ipv6
# Configure addresses for interfaces.

[Router-Ethernet1/0] ipv6 address 3001::1/64
# Configure an ISATAP tunnel.

[Router] interface tunnel 0
[Router-Tunnel0] ipv6 address 2001::1/64 eui-64
[Router-Tunnel0] source ethernet 1/1
[Router-Tunnel0] tunnel-protocol ipv6-ipv4 isatap
# Disable the RA suppression so that hosts can acquire information such as the address prefix from the
RA message released by the ISATAP router.
[Router-Tunnel0] undo ipv6 nd ra halt
[Router-Tunnel0] quit
# Configure a static route to the ISATAP host.

[Router] ipv6 route-static 2001:: 16 tunnel 0
z Configuration on the ISATAP host
The specific configuration on the ISATAP host is related to its operating system. The following example
shows the configuration of the host running the Windows XP.
# On a Windows XP-based host, the ISATAP interface is usually interface 2. Configure the IPv4 address
of the ISATAP router on interface 2 to complete the configuration on the host. Before that, display
information on the ISATAP interface:
C:\>ipv6 if 2
Interface 2: Automatic Tunneling Pseudo-Interface
Guid {48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE}
does not use Neighbor Discovery
1-38
does not use Router Discovery
routing preference 1
EUI-64 embedded IPv4 address: 0.0.0.0
router link-layer address: 0.0.0.0
preferred link-local fe80::5efe:2.1.1.2, life infinite
link MTU 1280 (true link MTU 65515)
current hop limit 128
reachable time 42500ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 0
default site prefix length 48
# A link-local address (fe80::5efe:2.1.1.2) in the ISATAP format was automatically generated for the
ISATAP interface. Configure the IPv4 address of the ISATAP router on the ISATAP interface.
C:\>ipv6 rlu 2 2.1.1.1
After carrying out the above command, look at the information on the ISATAP interface.
C:\>ipv6 if 2
uses Router Discovery
preferred global 2001::5efe:2.1.1.2, life 29d23h59m46s/6d23h59m46s (public)
DAD transmits 0
# By comparison, it is found that the host acquires the address prefix 2001::/64 and automatically
generates the address 2001::5efe:2.1.1.2. Meanwhile, uses Router Discovery is displayed, indicating
that the router discovery function is enabled on the host. At this time, ping the IPv6 address of the tunnel
interface of the router. If the address is successfully pinged, an ISATAP tunnel is established.
C:\>ping 2001::5efe:2.1.1.1
Pinging 2001::5efe:2.1.1.1 with 32 bytes of data:
Reply from 2001::5efe:2.1.1.1: time=1ms

Ping statistics for 2001::5efe:2.1.1.1:

1-39
After the above configuration, the ISATAP host can access the host in the IPV6 network.
Configuration Example (on a Switch)
As shown in Figure 1-16, an IPv6 network is connected to an IPv4 network through an ISATAP switch.
The destination address of the tunnel is an ISATAP address. It is required that IPv6 hosts in the IPv4
network can access the IPv6 network through the ISATAP tunnel.
Network diagram
Figure 1-16 Network diagram for an ISATAP tunnel (on a switch)
z Configuration on the switch

# Enable IPv6.
[Switch] ipv6
# Configure addresses for interfaces.

[Switch] vlan 100
[Switch-vlan100] quit
[Switch-Vlan-interface100] ipv6 address 3001::1/64
[Switch] vlan 101
[Switch-vlan101] quit
# Configure an ISATAP tunnel.

[Switch] interface tunnel 0
[Switch-Tunnel0] ipv6 address 2001::1/64 eui-64
[Switch-Tunnel0] source vlan-interface 101
1-40
[Switch-Tunnel0] tunnel-protocol ipv6-ipv4 isatap
# Disable the RA suppression so that hosts can acquire information such as the address prefix from the
RA message released by the ISATAP switch.
[Switch-Tunnel0] undo ipv6 nd ra halt
[Switch-Tunnel0] quit
# Configure a static route to the ISATAP host.

[Switch] ipv6 route-static 2001:: 16 tunnel 0
z Configuration on the ISATAP host
The specific configuration on the ISATAP host is related to its operating system. The following example
shows the configuration of the host running the Windows XP.
# On a Windows XP-based host, the ISATAP interface is usually interface 2. Configure the IPv4 address
of the ISATAP router on the interface to complete the configuration on the host. Before doing that,
display the ISATAP interface information:
C:\>ipv6 if 2
does not use Router Discovery
DAD transmits 0
# A link-local address (fe80::5efe:2.1.1.2) in the ISATAP format was automatically generated for the
ISATAP interface. Configure the IPv4 address of the ISATAP switch on the ISATAP interface.
C:\>ipv6 rlu 2 2.1.1.1
# After carrying out the above command, look at the information on the ISATAP interface.
C:\>ipv6 if 2
uses Router Discovery
preferred global 2001::5efe:2.1.1.2, life 29d23h59m46s/6d23h59m46s (public)
1-41
DAD transmits 0
# By comparison, it is found that the host acquires the address prefix 2001::/64 and automatically
generates the address 2001::5efe:2.1.1.2. Meanwhile, uses Switch Discovery is displayed, indicating
that the switch discovery function is enabled on the host. At this time, ping the IPv6 address of the
tunnel interface of the switch. If the address is successfully pinged, an ISATAP tunnel is established.
C:\>ping 2001::5efe:2.1.1.1
Pinging 2001::5efe:2.1.1.1 with 32 bytes of data:

Ping statistics for 2001::5efe:2.1.1.1:

After the above configurations, the ISATAP host can access the host in the IPV6 network.
Configuring IPv4 over IPv4 Tunnel

Follow these steps to configure an IPv4 over IPv4 tunnel:

Required
interface tunnel number By default, there is no tunnel
ip address ip-address Required

Configure an IPv4 address for
{ mask | mask-length } By default, no IPv4 address is
the tunnel interface
[ sub ] configured for the tunnel interface.
1-42
Optional
tunnel-protocol tunnel. The same tunnel mode
Set an IPv4 over IPv4 tunnel
ipv4-ipv4 should be configured at both ends of
the tunnel. Otherwise, packet
delivery will fail.
source { ip-address | Required

Configure a source address or
interface-type By default, no source address or
interface for the tunnel interface
interface-number } interface is configured for the tunnel.
Required
Configure a destination
destination ip-address By default, no destination address is
address for the tunnel interface
configured for the tunnel.
Optional
Reference a service loopback service-loopback-group
group number By default, no service loopback
group ID is referenced.
Optional
Configure the IPv6 MTU on the
mtu mtu-size The default value depends on the
tunnel interface
device model.
Support for the service-loopback-group command depends on the device model.
1-43
encapsulated packet can be forwarded normally. You need to configure a static or dynamic route at
both ends of the tunnel. For the detailed configuration, refer to Static Routing Configuration or other
z The IPv4 address and the destination address of a tunnel interface cannot be in the same network
segment.
z The destination address of a route with a tunnel interface as the egress interface and the
destination address of the tunnel interface must not be in the same network segment.
z Two or more tunnel interfaces using the same encapsulation protocol must have different source
and destination addresses.
z If you specify a source interface instead of a source address for the tunnel, the source address of
the tunnel is the primary IP address of the source interface.
z When you configure dynamic routing at each tunnel end, you need to enable the dynamic routing
protocol on the tunnel interface. For related configurations, refer to related contents in the IP
Routing Volume.
z If some devices need to reference a service loopback group on the tunnel interface to receive and
send packets, you must have configured the service loopback group. Otherwise, the tunnel
service loopback group ID needs to be configured on the tunnel interface. For creation and
Volume.
The two subnets Group 1 and Group 2 running IPv4 are interconnected via an IPv4 over IPv4 tunnel
between Router A and Router B.
1-44
Network diagram
Figure 1-17 Network diagram for an IPv4 over IPv4 tunnel (on routers)
# Configure an IPv4 address for Serial 2/0 (the physical interface of the tunnel).
# Create the interface tunnel 1.

# Configure an IPv4 address for the interface tunnel 1.

[RouterA-Tunnel1] ip address 10.1.2.1 255.255.255.0
# Configure the tunnel encapsulation mode.

# Configure a source address for the interface tunnel 1 (IP address of Serial 2/0).
[RouterA-Tunnel1] source 2.1.1.1
# Configure a destination address for the interface tunnel 1 (IP address of Serial 2/1 of Router B).
# Configure a static route from Router A through the interface tunnel 1 to Group 2.
[RouterA] ip route-static 10.1.3.0 255.255.255.0 tunnel 1
1-45


[RouterB-Tunnel2] ip address 10.1.2.2 255.255.255.0

# Configure the source address for the interface tunnel 2 (IP address of Serial 2/1).
[RouterB-Tunnel2] source 3.1.1.1
# Configure a destination address for the interface tunnel 2 (IP address of Serial 2/0 of Router A).
[RouterB-Tunnel2] destination 2.1.1.1
# Configure a static route from Router B through the interface tunnel 2 to Group 1.
[RouterB] ip route-static 10.1.1.0 255.255.255.0 tunnel 2
After the above configuration, display the status of the tunnel interfaces on Router A and Router B,
respectively.
<RouterA> display interface tunnel 1
Tunnel1 current state: UP
Description: Tunnel1 Interface
Internet Address is 10.1.2.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
Tunnel source 2.1.1.1, destination 3.1.1.1
Tunnel protocol/transport IP/IP
Last 300 seconds input: 0 bytes/sec, 0 packets/sec
Last 300 seconds output: 2 bytes/sec, 0 packets/sec
4 packets input, 256 bytes
0 input error
12 packets output, 768 bytes
0 output error
<RouterB> display interface tunnel 2

1-46
0 input error
0 output error
# Ping the IPv4 address of the peer interface Ethernet 1/0 from Router A.

0.00% packet loss
The two subnets Group 1 and Group 2 running IPv4 are interconnected via an IPv4 over IPv4 tunnel
between Switch A and Switch B.
Network diagram
Figure 1-18 Network diagram for an IPv4 over IPv4 tunnel (on switches)
Switch A Switch B
2.1.1.1/24 3.1.1.1/24
IPv4 netwok
Tunnel1 Tunnel2
10.1.1.1/24 10.1.3.1/24
10.1.2.1/24 10.1.2.2/24
IPv4 IPv4
Group 1 Group 2
1-47
[SwitchA] vlan 100
# Configure an IPv4 address for VLAN-interface 101 (configured on the physical interface of the tunnel).
[SwitchA] vlan 101


[SwitchA-Tunnel1] ip address 10.1.2.1 255.255.255.0

# Configure a source address for the interface tunnel 1 (IP address of VLAN-interface 101).
[SwitchA-Tunnel1] source 2.1.1.1
# Configure a destination address for the interface tunnel 1 (IP address of VLAN-interface 101 of Switch
B).
# Configure a static route from Switch through the interface tunnel 1 to Group 2.
[SwitchA] ip route-static 10.1.3.0 255.255.255.0 tunnel 1
[SwitchB] vlan 100
# Configure an IPv4 address for VLAN-interface 101 (the physical interface of the tunnel).
[SwitchB] vlan 101
1-48


[SwitchB-Tunnel2] ip address 10.1.2.2 255.255.255.0

# Configure the source address for the interface tunnel 2 (IP address of VLAN-interface 101).
[SwitchB-Tunnel2] source 3.1.1.1
# Configure the destination address for the interface tunnel 2 (IP address of VLAN-interface 101 of
Switch A).
[SwitchB-Tunnel2] destination 2.1.1.1
# Configure a static route from Switch B through the interface tunnel 2 to Group 1.
[SwitchB] ip route-static 10.1.1.0 255.255.255.0 tunnel 2
After the above configuration, display the status of the tunnel interfaces on Switch A and Switch B:
<SwitchA> display interface tunnel 1
0 input error
0 output error
<SwitchB> display interface tunnel 2

1-49
0 input error
0 output error
# Ping the IPv4 address of the peer interface VLAN-interface 100 from Switch A.

0.00% packet loss


Required
Enable IPv6 ipv6 By default, the IPv6 packet forwarding
Create a tunnel Required

interface and enter interface tunnel number By default, there is no tunnel interface on
tunnel interface view the device.
1-50
Configure an IPv4 ip address ip-address Required

address for the tunnel { mask | mask-length } By default, no IPv4 address is configured
interface [ sub ] for the tunnel interface.
Optional
Configure the tunnel By default, the tunnel is a GRE tunnel. The
tunnel-protocol ipv4-ipv6 same tunnel mode should be configured at
mode
both ends of the tunnel. Otherwise, packet
delivery will fail.
Configure the source source { ipv6-address | Required

address or interface for interface-type By default, no source address or interface
the tunnel interface interface-number } is configured for the tunnel.

destination address for destination ipv6-address By default, no destination address is
the tunnel interface configured for the tunnel.
Optional
loopback group number By default, no service loopback group ID is
referenced.
Configure the IPv6 Optional

MTU on the tunnel ipv6 mtu mtu-size The default value depends on the device
interface model.
z Support for the encapsulation-limit and service-loopback-group commands depends on the

device model.
z For the configuration of the IPv6 MTU on a tunnel interface, refer to the ipv6 mtu command in IPv6
1-51
encapsulated packet can be forwarded normally. You need to configure a static or dynamic route at
both ends of the tunnel. For the detailed configuration, refer to Static Routing Configuration or other
z Two or more tunnel interfaces using the same encapsulation protocol must have different source
and destination addresses.
z When you configure dynamic routing at each tunnel end, you need to enable the dynamic routing
protocol on the tunnel interface. For related configurations, refer to related contents in the IP
Routing Volume.
z To reference a service loopback group on the tunnel interface, you must have configured the
service loopback group. Otherwise, the tunnel interface will not be up. For devices that do not
support service loopback, no service loopback group needs to be configured on the tunnel
interface. For creation and configuration of a service loopback group, refer to Service Loopback
The two subnets Group 1 and Group 2 of the private network running IPv4 are interconnected over the
IPv6 network by using an IPv4 over IPv6 tunnel between Router A and Router B.
Network diagram
Router A Router B
S2/0 S2/1
2002::1:1/64 2002::2:1/24
IPv6 network
Eth1/0 Tunnel1 Tunnel2 Eth1/0

30.1.1.1/24 30.1.2.1/24 30.1.2.2/24 30.1.3.1/24
IPv4 IPv4
Group 1 Group 2
1-52
# Enable IPv6.
[RouterA] ipv6

[RouterA-Serial2/0] ipv6 address 2002::1:1 64



[RouterA-Tunnel1] source 2002::1:1
[RouterA-Tunnel1] destination 2002::2:1
[RouterA] ip route-static 30.1.3.0 255.255.255.0 tunnel 1
# Enable IPv6.
[RouterB] ipv6

[RouterB-Serial2/1] ipv6 address 2002::2:1 64

1-53
[RouterB-Tunnel2] ip address 30.1.2.2 255.255.255.0

# Configure the source address for the interface tunnel 2 (IP address of Serial 2/1).
[RouterB-Tunnel2] source 2002::2:1
[RouterB-Tunnel2] destination 2002::1:1
[RouterB] ip route-static 30.1.1.0 255.255.255.0 tunnel 2
respectively.
<RouterA> display interface tunnel 1
Tunnel source 2002::0001:0001, destination 2002::0002:0001
Tunnel protocol/transport IP/IPv6
0 input error
0 output error
<RouterB> display interface tunnel 2

1-54
0 input error
0 output error

0.00% packet loss
The two subnets Group 1 and Group 2 in the private network running IPv4 are interconnected over the
IPv6 network by using an IPv4 over IPv6 tunnel between Switch A and Switch B.
Network diagram
Switch A Switch B
2002::1:1/64 2002::2:1/24
IPv6 network
Vlan-int100 Tunnel2 Vlan-int100
Tunnel1
30.1.1.1/24 30.1.2.2/24 30.1.3.1/24
30.1.2.1/24
IPv4 IPv4
Group 1 Group 2
# Enable IPv6.
[SwitchA] ipv6

[SwitchA] vlan 100
1-55
# Configure an IPv6 address for VLAN-interface 101 (the physical interface of the tunnel)
[SwitchA] vlan 101
[SwitchA-Vlan-interface101] ipv6 address 2002::1:1 64



[SwitchA-Tunnel1] source 2002::1:1
# Configure the destination address of the interface tunnel 1 (IP address of VLAN-interface 101 of
Switch B).
[SwitchA-Tunnel1] destination 2002::2:1
# Configure a static route from Switch A through the interface tunnel 1 to Group 2.
[SwitchA] ip route-static 30.1.3.0 255.255.255.0 tunnel 1
# Enable IPv6.
[SwitchA] ipv6

[SwitchB] vlan 100
[SwitchB] vlan 101
[SwitchB-Vlan-interface101] ipv6 address 2002::2:1 64
1-56


[SwitchB-Tunnel2] ip address 30.1.2.2 255.255.255.0

[SwitchB-Tunnel2] source 2002::2:1
Switch A).
[SwitchB-Tunnel2] destination 2002::1:1
[SwitchB] ip route-static 30.1.1.0 255.255.255.0 tunnel 2
After the configuration, display the status of the tunnel interfaces on Switch A and Switch B,
respectively.
<SwitchA> display interface tunnel 1
0 input error
0 output error
<SwitchB> display interface tunnel 2

1-57
0 input error
0 output error

0.00% packet loss


Required
Required
Interface tunnel number By default, there is no tunnel
1-58
ipv6 address
Configure an { ipv6-address prefix-length
IPv6 global |
address or
Configure an site-local ipv6 address Required
IPv6 address ipv6-address/prefix-length Use any command.
address
for the tunnel eui-64 By default, no IPv6 address is
interface configured for the tunnel interface.
Configure an ipv6 address auto
IPv6 link-local
link-local ipv6 address ipv6-address
address link-local
Optional
Set an IPv6 over IPv6 tunnel tunnel-protocol ipv6-ipv6 tunnel. The same tunnel mode
should be configured at both ends
of the tunnel. Otherwise, packet
delivery will fail.
Required
Configure a source address or source { ipv6-address |
interface for the tunnel interface-type By default, no source address or
interface interface-number } interface is configured for the
tunnel.
Required
Configure the destination
destination ipv6-address By default, no destination address
address for the tunnel interface
is configured for the tunnel.
encapsulation-limit
number of nested
[ number ] 4 by default.
encapsulations of a packet
Optional
Reference a service loopback service-loopback-group
group number By default, no service loopback
group ID is referenced.
Optional
Configure the IPv6 MTU on the
tunnel interface
device model.
z Support for the encapsulation-limit and service-loopback-group commands depends on the

device model.
z For the IPv6 MTU configuration on a tunnel interface, refer to the ipv6 mtu command in IPv6
1-59
z When you create a tunnel interface on a distributed device, the slot of the tunnel interface should
be that of the source interface, namely, the interface sending packets. In this way, the forwarding
efficiency can be improved.
encapsulated packet can be forwarded normally. You can configure static or dynamic routes. For
the detailed configuration, refer to Static Routing Configuration or other routing protocol
configuration in the IP Routing Volume. Two or more tunnel interfaces using the same
encapsulation protocol must have different source and destination addresses.
z The IPv6 address and the destination address of a tunnel interface must not be in the same
network segment.
z The destination address of a route with the tunnel interface as the egress interface and the
destination address of the tunnel interface must not be in the same network segment.
z Before configuring dynamic routes, you must enable the dynamic routing protocol on the tunnel
interfaces at both ends of the tunnel. Such a route must be configured at both ends of the tunnel.
For related configurations, refer to related contents in the IP Routing Volume.
z Only the IPv6 over IPv6 tunnel has a maximum number of nested encapsulations for a packet.
z To reference a service loopback group on the tunnel interface, you must have configured the
service loopback group. Otherwise, the tunnel interface will not be up. For devices that do not
support service loopback, no service loopback group needs to be referenced on the tunnel
interface. For creation and configuration of a service loopback group, refer to Service Loopback
The two subnets Group 1 and Group 2 running IPv6 are interconnected by using an IPv6 over IPv6
tunnel between Router A and Router B.
1-60
Network diagram
# Enable IPv6.
[RouterA] ipv6

[RouterA-Ethernet1/0] ipv6 address 2002:1::1 64
[RouterA-Serial2/0] ipv6 address 2002::11:1 64


[RouterA-Tunnel1] ipv6 address 3001::1:1 64

[RouterA-Tunnel1] source 2002::11:1
[RouterA-Tunnel1] destination 2002::22:1
[RouterA] ipv6 route-static 2002:3:: 64 tunnel 1
# Enable IPv6.
[RouterB] ipv6
1-61
[RouterB-Ethernet1/0] ipv6 address 2002:3::1 64
[RouterB-Serial2/1] ipv6 address 2002::22:1 64


[RouterB-Tunnel2] ipv6 address 3001::1:2 64

[RouterB-Tunnel2] source 2002::22:1
[RouterB-Tunnel2] destination 2002::11:1
[RouterB] ipv6 route-static 2002:1:: 64 tunnel 2
respectively.
<RouterA> display ipv6 interface tunnel 1 verbose
IPv6 is enabled, link-local address is FE80::2013:1
3001::1:1, subnet is 3001::/64
FF02::1:FF13:1
FF02::1:FF01:1
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1460 bytes
...
<RouterB> display ipv6 interface tunnel 2 verbose
1-62
3001::1:2, subnet is 3001::/64
FF02::1:FF24:1
FF02::1:FF01:2
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1460 bytes
...
<RouterA> ping ipv6 2002:3::1
PING 2002:3::1 : 56 data bytes, press CTRL_C to break
Reply from 2002:3::1
--- 2002:3::1 ping statistics ---

0.00% packet loss
The two subnets Group 1 and Group 2 running IPv6 are interconnected by using an IPv6 over IPv6
tunnel between Switch A and Switch B.
1-63
Network diagram
# Enable IPv6.
[SwitchA] ipv6

[SwitchA] vlan 100
[SwitchA-Vlan-interface100] ipv6 address 2002:1::1 64
[SwitchA] vlan 101
[SwitchA-Vlan-interface101] ipv6 address 2002::11:1 64


[SwitchA-Tunnel1] ipv6 address 3001::1:1 64

[SwitchA-Tunnel1] source 2002:11::1
Switch B).
[SwitchA-Tunnel1] destination 2002::22:1
1-64
# Configure a static route from Switch A through the interface tunnel 1 to Group 2.
[SwitchA] ipv6 route-static 2002:3:: 64 tunnel 1
# Enable IPv6.
[SwitchB] ipv6

[SwitchB] vlan 100
[SwitchB-Vlan-interface100] ipv6 address 2002:3::1 64
[SwitchB] vlan 101
[SwitchB-Vlan-interface101] ipv6 address 2002::22:1 64


[SwitchB-Tunnel2] ipv6 address 3001::1:2 64

# Configure the source address for the interface tunnel 2 (IP address of VLAN-interface 101)
[SwitchB-Tunnel2] source 2002::22:1
Switch A).
[SwitchB-Tunnel2] destination 2002::11:1
[SwitchB] ipv6 route-static 2002:1:: 64 tunnel 2
After the above configuration, display the status of the tunnel interfaces on Switch A and Switch B,
respectively.
<SwitchA> display ipv6 interface tunnel 1 verbose
1-65
3001::1:1, subnet is 3001::/64
FF02::1:FF13:1
FF02::1:FF01:1
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1460 bytes
...
<SwitchB> display ipv6 interface tunnel 2 verbose
3001::1:2, subnet is 3001::/64
FF02::1:FF24:1
FF02::1:FF01:2
FF02::1:FF00:0
FF02::2
FF02::1
MTU is 1460 bytes
...
[SwitchA] ping ipv6 2002:3::1
PING 2002:3::1 : 56 data bytes, press CTRL_C to break
--- 2002:3::1 ping statistics ---

1-66
0.00% packet loss
Displaying and Maintaining Tunneling Configuration

Display information about a display interface tunnel
specified tunnel interface [ number ]
Display IPv6 information
display ipv6 interface tunnel
related to a specified tunnel Available in any view
[ number ] [ verbose ]
interface
Troubleshooting Tunneling Configuration

Symptom: After the configuration of related parameters such as tunnel source address, tunnel
destination address, and tunnel mode, the tunnel interface is still not up.
Solution: Follow the steps below:
1) The common cause is that the physical interface of the tunnel source is not up. Use the display
interface tunnel or display ipv6 interface tunnel commands to view whether the physical
interface of the tunnel source is up. If the physical interface is down, use the debugging tunnel
event command in user view to view the cause.
2) Another possible cause is that the tunnel destination is unreachable. Use the display ipv6
routing-table or display ip routing-table command to view whether the tunnel destination is
reachable. If no routing entry is available for tunnel communication in the routing table, configure
related routes.
1-67
Table of Contents
1 IPv6 Unicast Policy Routing Configuration 1-1

Introduction to IPv6 Unicast Policy Routing 1-1
Configuring IPv6 Unicast Policy Routing 1-1
Defining an IPv6 Policy1-1
Enabling IPv6 Local Policy Routing1-3
Enabling IPv6 Interface Policy Routing 1-4
Displaying and Maintaining IPv6 Unicast Policy Routing Configuration 1-4
IPv6 Unicast Policy Routing Configuration Examples 1-4
Configuring Policy Routing Based on ACL1-4
Configuring Policy Routing Based on Packet Size1-6
i
1 IPv6 Unicast Policy Routing Configuration
When configuring IPv6 unicast policy routing, go to these sections for information you are interested in:
z Introduction to IPv6 Unicast Policy Routing
z Configuring IPv6 Unicast Policy Routing
z Displaying and Maintaining IPv6 Unicast Policy Routing Configuration
z IPv6 Unicast Policy Routing Configuration Examples
Introduction to IPv6 Unicast Policy Routing

Policy routing, also known as policy based routing (PBR), is a routing mechanism based on the
user-defined policies. Different from the traditional destination-based routing mechanism, policy routing
enables you to implement policies (based on the source address, address length, and other criteria)
that make packets flexibly take different routes.
Policy routing involves local policy routing and interface policy routing:
z Local policy routing applies to locally generated packets only. In most cases, interface policy
routing applies;
z Interface policy routing applies to incoming packets on an interface.
In general, policy routing takes precedence over destination-based routing. That is, policy routing is
applied when packets match the policy, and otherwise, destination-based routing is applied. However, if
only a default outgoing interface (next hop) is configured for the policy, destination-based routing takes
precedence over policy routing.
Configuring IPv6 Unicast Policy Routing

Defining an IPv6 Policy
An IPv6 policy can consist of multiple nodes identified by node number. The smaller a node number is,
the higher the priority the node has. A policy, which consists of if-match clauses and apply clauses, is
used to route IPv6 packets.
An if-match clause defines what kind of packets can pass, and an apply clause defines the action to
be taken on permitted packets.
Currently, two types of if-match clause are available: if-match packet-length and if-match acl6. In
each policy node, you can specify only one if-match clause for each type.
1-1
There are six types of apply clauses: apply ipv6-precedence, apply output-interface, apply
ipv6-address next-hop, apply default output-interface, apply ipv6-address default next-hop, and
apply destination-based-forwarding. You can specify only one apply clause for each type in a policy
node. In the case that a packet satisfies all if-match clauses on a node, the application priorities of
these types of apply clauses are ranked as follows:
z apply ipv6-precedence: If configured, this clause will always be executed.
z apply output-interface and apply ipv6-address next-hop: The apply output-interface clause
takes precedence over the apply ipv6-address next-hop clause. This means that only the apply
output-interface clause will be executed when both are configured.
z apply default output-interface and apply ipv6-address default next-hop: Alike, the apply
default output-interface clause takes precedence over the apply ipv6-address default
next-hop clause. This means that only the apply default output-interface clause is executed
when both are configured. Either of these two clauses is executed only when neither outgoing
interface nor next hop is configured for the packet, and the destination address does not have a
corresponding route in the routing table.
z apply destination-based-forwarding: Enables IPv6 destination based forwarding. If this clause
is configured, denied packets can still be forwarded through the routing table. If not, denied
packets are discarded.
There is an AND relationship between if-match clauses on a node. That is, a packet must satisfy all the
if match clauses of the node before the action specified by the apply clause is taken. There is an OR
relationship between nodes of a policy. That is, if a packet matches a node, it passes the policy.
When configuring policy nodes, you need to specify the match mode as permit or deny:
z permit: Specifies the match mode as permit for a policy node. If a packet satisfies all the if-match
clauses on the policy node, the apply clauses are executed. If not, the packet will go to the next
policy node for a match.
z deny: Specifies the match mode as deny for a policy node. When a packet satisfies all the
if-match clauses on the policy node, the packet will be denied and will not go to the next policy
node for a match.
A packet satisfying the match criteria on a node of a policy will not go to other nodes. If the packet does
not satisfy the match criteria of any node of the policy, the packet cannot pass the policy and will be
forwarded through the routing table.
You can define five next hops or five outgoing interfaces at most for per-flow load balancing.
Follow theses steps to define an IPv6 policy:
Required
Create a policy or policy node and enter ipv6 policy-based-route policy-name
policy node view [ deny | permit ] node sequence-num Not created
by default
Define an IPv6 packet length match
if-match packet-length min-len max-len Optional
criterion
Define an IPv6 ACL match criterion if-match acl6 acl6-number Optional
Set a precedence for permitted IPv6
apply ipv6-precedence { type | value } Optional
packets
Set an outgoing interface for permitted apply output-interface interface-type
Optional
IPv6 packets interface-number
1-2
Set a next hop for permitted IPv6 apply ipv6-address next-hop
Optional
packets ipv6-address
Set a default outgoing interface for apply default output-interface
Optional
permitted IPv6 packets interface-type interface-number
Set a default next hop for permitted apply ipv6-address default next-hop
Optional
IPv6 packets ipv6-address
Enable destination based forwarding apply destination-based-forwarding Optional
z If a policy has only one node that has no if-match clause or apply clause configured, all packets
can pass it. The statistics of IPv6 unicast policy routing will not be changed.
z If a policy node has if-match clauses but has no apply clauses configured, all packets will match
against these if-match clauses, while no apply clauses are applicable to permitted packets, which
will not go to the next node for a match. The statistics of IPv6 unicast policy routing will not be
changed.
z If a policy node has no if-match clause but has apply clauses configured, all packets can pass it,
and then are forward through the apply clauses if the permit keyword is specified for the node, or
are denied if the deny keyword is specified. They will not match against any other node. In this
case, the statistics of IPv6 unicast policy routing will be changed.
z If a non existent ACL is referenced, the ACL based match criterion will not take effect.
z If a local Ethernet interface, sub Ethernet interface or Virtual-Template interface is specified as the
outgoing interface, packets can be forwarded through the interface but the forwarding may fail,
because the interface is a broadcast interface. Therefore, you need to specify a next hop.
z If the match mode of a policy node is deny, no apply clauses will be executed. Packets that pass
the match criteria are routed through the routing table, so neither debug information nor statistics
for the denied packets will be available.
Enabling IPv6 Local Policy Routing
IPv6 local policy routing is used to route packets generated by the local device. Only one policy can be
referenced when local policy routing is enabled.
Follow these steps to enable IPv6 local policy routing:
Enable IPv6 local policy routing ipv6 local policy-based-route Required

based on a policy policy-name Not enabled by default
1-3
Enabling IPv6 Interface Policy Routing
Interface policy routing is applied to packets arriving on an interface. Only one policy can be referenced
when policy routing is enabled on an interface.
Follow these steps to enable IPv6 interface policy routing:
Enable IPv6 policy routing Required

based on a policy on the ipv6 policy-based-route policy-name Not enabled by
interface default
Displaying and Maintaining IPv6 Unicast Policy Routing

Configuration
Display information about local policy
display ipv6 policy-based-route
routing and interface policy routing
display ipv6 policy-based-route setup

Display IPv6 policy routing
{ policy-name | interface interface-type
configuration information
interface-number | local } Available in any
display ipv6 policy-based-route view
Display the statistics of IPv6 policy
statistics { interface interface-type
routing
interface-number | local }
Display information about IPv6 policy display ipv6 config policy-based-route
routing [ policy-name ]
Clear the statistics of IPv6 policy Available in
reset ipv6 policy-based-route statistics
routing user view
IPv6 Unicast Policy Routing Configuration Examples

Configuring Policy Routing Based on ACL
As shown in the following figure, define policy aaa so that TCP packets arriving on the interface
Ethernet 1/0 are forwarded via Serial 2/0 and other packets are forwarded through the routing table.
z Node 5 allows packets matching ACL 3101 to travel through Serial 2/0.
z Node 10 allows packets matching ACL 3102 to be forwarded through the routing table.
1-4
Network diagram
Figure 1-1 Network diagram for policy routing based on source address
Internet
Router
S2/0 S2/1
Eth1/0
Subnet A
10::110/64
Host A Host B
# Define ACLs, making ACL 3001 match TCP packets, and ACL 3002 match IPv6 packets.
[Router] ipv6
[Router] acl ipv6 number 3001
[Router-acl6-adv-3001] rule permit tcp
[Router-acl6-adv-3001] quit
[Router] acl ipv6 number 3002
[Router-acl6-adv-3002] rule permit ipv6
[Router-acl6-adv-3002] quit
# Define Node 5 of policy aaa, allowing TCP packets to be forwarded via Serial 2/0.
[Router] ipv6 policy-based-route aaa permit node 5
[Router-pbr6-aaa-5] if-match acl6 3001
[Router-pbr6-aaa-5] apply output-interface serial 2/0
[Router-pbr6-aaa-5] quit
# Define Node 10 of policy aaa, allowing packets matching ACL 3102 to be forwarded through the
routing table.
[Router] ipv6 policy-based-route aaa deny node 10
[Router-pbr6-aaa-10] if-match acl6 3002
[Router-pbr6-aaa-10] quit
# Apply policy aaa on Ethernet 1/0 to enable policy routing.

[Router-Ethernet1/0] ipv6 address 10::110 64
[Router-Ethernet1/0] ipv6 policy-based-route aaa
1-5
Configuring Policy Routing Based on Packet Size
The policy lab1 is applied to the interface Ethernet 1/0 of Router A. Packets with a size from 64 to 100
bytes are forwarded to 150::2/64, while packets with a size from 101 to 1,000 bytes are forwarded to
151::2/64. All other packets are forwarded through the routing table.
Network diagram
Figure 1-2 Network diagram for policy routing based on packet size
60100bytes
S2/0 S2/0
Router A 150::1/24 150::2/24 Router B
S2/1 S2/1
151::1/24 151::2/24
Enable policy
routing on Eth1/0 1011000bytes
# Configure RIPng.
[RouterA] ipv6
[RouterA] ripng 1
[RouterA-ripng-1] quit
[RouterA-Serial2/0] ipv6 address 150::1 64
[RouterA-Serial2/0] ripng 1 enable
[RouterA-Serial2/1] ipv6 address 151::1 64
[RouterA-Serial2/1] ripng 1 enable
# Apply the policy lab1 to the interface Ethernet 1/0 to handle incoming packets.
[RouterA-Ethernet1/0] ripng 1 enable
[RouterA-Ethernet1/0] ipv6 policy-based-route lab1
# Define the nodes of policy lab1 to forward IP packets with a size from 64 to 100 bytes to the next hop
150::2/64 and those with a size from 101 to 1,000 bytes to the next hop 151::2/64.
[RouterA] ipv6 policy-based-route lab1 permit node 10
[RouterA-pbr6-lab1-10] if-match packet-length 64 100
[RouterA-pbr6-lab1-10] apply ipv6-address next-hop 150::2
[RouterA-pbr6-lab1-10] quit
1-6
[RouterA] ipv6 policy-based-route lab1 permit node 20
[RouterA-pbr6-lab1-20] if-match packet-length 101 1000
[RouterA-pbr6-lab1-20] apply ipv6-address next-hop 151::2
# Configure RIPng.
[RouterB] ipv6
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB-Serial2/0] ipv6 address 150::2 64
[RouterB-Serial2/0] ripng 1 enable
[RouterB-Serial2/1] ipv6 address 151::2 64
[RouterB-Serial2/1] ripng 1 enable
1-7
Table of Contents
1 Terminal Access Configuration 1-1

Introduction to Terminal Access1-1
Introduction to Terminal Access Types 1-1
Typical Applications of Terminal Access 1-3
Terminal Access Feature List1-3
Terminal Access Features1-4
Terminal Access Specifications1-9
Terminal Access Configuration Task List1-10
TTY Terminal Access Configuration 1-11
Configuring the TTY Initiator 1-11
Configuring the TTY Receiver 1-15
TTY Terminal Access Configuration Example 1-15
Telnet Terminal Access Configuration 1-17
Configuring the Telnet Initiator 1-17
Configuring Telnet Receiver1-20
Telnet Terminal Access Configuration Example 1-20
RTC Terminal Access Configuration1-22
Configuring the RTC Initiator (RTC Client)1-22
Configuring the RTC Receiver (RTC Server) 1-25
Asynchronous RTC Terminal Access Configuration Example 1-28
Asynchronous RTC Multi-instance Configuration Example 1-29
Displaying and Maintaining Terminal Access Configuration1-31
2 FEP Installation and Configuration2-1

Installing and Configuring SCO OpenServer Server 2-1
Installing Device Drivers 2-1
Modifying System Configuration File inittab 2-4
Editing the ttyd Configuration File 2-5
Modifying Route Configuration File 2-7
Running and Terminating ttyd on Unix Server 2-8
Installing and Using ttyd Administration Program ttyadm2-9
Installing and Configuring SCO UnixWare Server 2-16
Modifying System Configuration File ttydefs 2-18
Editing ttyd Configuration File 2-18
Installing and Configuring SUN OS Server 2-18
i
Running and Terminating ttyd on the Unix Server 2-20
Installing and Configuring IBM AIX Server2-20
Running and Terminating ttyd on the Unix Server 2-21
Installing and Configuring HP-UX Server2-22
Editing ttyd Configuration File 2-23
Installing and Configuring Red Hat Linux Server2-24
3 Terminal Access Troubleshooting3-1

Prompts on Terminals 3-1
Terminal Access Troubleshooting3-2
4 Terminal Access FAQ4-1
ii
1 Terminal Access Configuration
When configuring terminal access, go to these sections for information you are interested in:
z Introduction to Terminal Access
z Terminal Access Configuration Task List
z TTY Terminal Access Configuration
z Telnet Terminal Access Configuration
z RTC Terminal Access Configuration
z Displaying and Maintaining Terminal Access Configuration
Introduction to Terminal Access

Terminal access refers to the connection of a terminal to a router through an asynchronous interface for
data exchange with a front-end processor (FEP) or another terminal through the router.
Three types of network devices are used in terminal access:
z Terminal: A terminal is a character device generally connected to another device through a serial
interface cable. A user inputs characters by using the terminal keyboard. Then, the characters are
transferred to another device through the serial interface cable. After processing the characters,
the device returns the result to the terminal, which then displays the result on its screen.
z Terminal access initiator (hereinafter referred to as initiator): An initiator sends a TCP connection
request and serves as the client of the TCP connection. Generally, a router is used as an initiator
z Terminal access receiver (hereinafter referred to as receiver): A receiver responds to a TCP
connection request and serves as the server of the TCP connection. A receiver can be an FEP or a
router. An FEP is a system installed with an application program for banking, postal service,
taxation, customs, civil aviation, and so on. An FEP can be a Unix server or a Linux server.
Once a TCP connection is established, the router, functioning as either the terminal access initiator or
receiver, can transparently transmit the data from the terminal to the peer over the TCP connection.
Transparent means that no manual or extra operation is required.
Introduction to Terminal Access Types
Three types of terminal access are used in different applications: true type terminal (TTY) access,
Telnet terminal access, and remote terminal connection (RTC) access. TTY terminal access and Telnet
terminal access are used to help implement services between a terminal and an FEP, with a router
1-1
being the initiator, the FEP being the receiver. The difference between them is the way of establishing a
TCP connection between the initiator and the receiver. RTC terminal access is used to monitor terminal
data. It is initiated by a router and received by another router. The following describe the three types of
terminal access:
Introduction to TTY Terminal Access
The initiator and receiver of TTY terminal access are a router and an FEP. The service terminal is
connected to the router through an asynchronous serial interface. The router is connected to the FEP
through a network. Application services run on the FEP. The FEP interacts with the router through the
ttyd program, and the router pushes the service display to the service terminal. The router transports
data transparently between the connected service terminal and FEP to implement service interaction
and processing.
The TTY terminal access solution implements the fixed terminal number function and offers many
enhanced functions such as dynamic multi-service switching, real-time screen saving, terminal reset,
and data encryption. Meanwhile, the FEP provides professional terminal management software,
enriching the system functions while simplifying the management. In addition, the combination of TTY
terminal access and routers makes remote offices possible and implementation of IP telephony more
easy, offering a solution for establishing high-efficient networks with diverse functions.
Introduction to Telnet Terminal Access
The initiator and receiver of Telnet terminal access are a router and an FEP. A service terminal is
connected to the router (Telnet client) through an asynchronous serial interface. The router is
connected to the FEP (Telnet server) through a network. Application services run on the FEP. The FEP
interacts with the router through Telnet, thereby implementing data exchange between the terminal and
the FEP.
Telnet terminal access implements the following basic functions: up to eight VTYs supported on a
terminal, TTY terminal access or Telnet terminal access used by the VTYs on a terminal, menu screen
switching, VTY service fast switching, and terminal screen saving.
Introduction to RTC Terminal Access
The initiator and receiver of RTC terminal access are routers. RTC terminal access is another typical
application of terminal access. It interconnects a local terminal and a remote terminal through routers
for data exchange and data monitoring. At present, RTC terminal access supports the asynchronous
mode only.
In asynchronous RTC terminal access, the monitoring terminal at the data center and the monitored
terminal are each connected to a different router through an asynchronous serial interface, and the
routers exchange data with each other through an IP network. Normally, the router connected to the
monitoring device acts as the terminal access initiator (the RTC client). The monitoring device is always
ready to initiate a connection request at any time to access the data on the monitored device. The router
connected to the monitored terminal acts as the terminal access receiver (the RTC server) and is
always ready to receive the connection requests from the monitoring device and send monitored data in
response.
RTC terminal access mainly serves the following three purposes:
z Enabling the monitoring device to manage and monitor remote terminals,
z Collecting data from the remote terminals.
z Fulfilling the functions of a multiplexing device and transmitting data over IP networks for easy
network upgrade.
1-2
Typical Applications of Terminal Access
Terminal access is widely used in the systems in which large numbers of FEPs are deployed, such as
banking, postal service, taxation, customs, and civil aviation. This manual uses a banking system as an
example to describe terminal access functions, configuration, and applications. Figure 1-1 shows a
typical terminal access application.
Figure 1-1 Typical application of terminal access
As shown in the figure above, the arrowhead of a dotted line indicates the direction of an established
TCP connection, from the initiator to the receiver.
The purple dotted line represents TTY/Telnet terminal access. The bank outlet is connected to the FEP
of the branch through Router A, which is capable of terminal access, over an IP network. Banking
services run on the FEP, and the information entered by an employee at the bank outlet is sent to the
FEP through Router A. The FEP then sends the corresponding service display to the service terminal
though Router A, thereby implementing data exchange between the outlet and the branch.
The orange dotted line represents RTC terminal access. Router B acts as an RTC client and Router A
the RTC server. Router B initiates monitoring requests and Router A, upon receiving a monitoring
request, sends the data from the monitored terminal to the monitoring device through Router B, so as to
implement terminal monitoring.
Terminal Access Feature List
The following table lists the features of terminal access. "All" in this table means that all the terminal
access types, including TTY, Telnet, and RTC (RTC client or RTC server), support the feature.
Supporting terminal
Feature Description
access type
Source address binding TTY, Telnet, RTC client
Terminal menu TTY, Telnet
Fast VTY service switching TTY, Telnet, RTC client
VTY redrawing TTY
1-3
Supporting terminal
Feature Description
access type
Idle connection timeout All
Terminal number fixing TTY
Data encryption TTY
Automatic link establishment TTY, Telnet, RTC client
Automatic link teardown All

One-to-one access TTY
Terminal display language
All
configuration
Screen saving TTY, Telnet, RTC client
Read blocking All

Terminal reset TTY, Telnet, RTC client
For Telnet terminal access, only the
Connectivity test TTY, Telnet connectivity test between the
terminal and the router is supported.
Data send delay All
TCP buffer parameter
All
configuration
Terminal buffer parameter
All
configuration
Threshold for VTY switching
RTC client
failure times
Receiver VTY switching rules RTC server
RTC terminal authentication RTC client, RTC server
Terminal access multi-instance All
Server connection
TTY
authentication
See section Displaying and
Statistics support All Maintaining Terminal Access
Configuration.
See the Debugging Terminal Access
Debugging information support All
part in the Debugging volume.
Terminal Access Features
Figure 1-2 shows a terminal access implementation.
1-4
Figure 1-2 Network diagram for terminal access
Source address binding
The principle of source IP address binding is to configure an IP address on a stable interface (the
loopback interface or dialer interface is recommended) and use this address as the source IP address
of the upstream TCP connection from the router through IP unnumbered configuration.
If an FEP runs, the IP address of the router connected to the FEP needs to be authenticated. Therefore,
when the dial-up backup function is used in a wide area network (WAN), if the primary link fails, the
router begins to use the backup interface. In that case, the IP address of the router is changed, and the
authentication fails if source IP address binding is not implemented. To avoid such failures, configure
source IP address binding on the router to use a fixed IP address to establish a TCP connection with the
FEP.
For security or some other reason, the actual IP address used in the upstream TCP connection on the
router may need to be hidden and another IP address needs to be used. In that case, you also need to
configure source IP address binding.
Make sure the FEP and the routers IP address is reachable to each other.
Terminal menu
Terminal menu allows you to bring up the menu interface by pressing the menu hotkey at the terminal.
The menu interface displays the services provided by each VTY on the terminal. By entering a service
option, you can switch to the corresponding service display. The menu interface displays:
TTY ACCESS SYSTEM
VERSION 3.0
1. SELECT VTY(0): chuxu_zhu

2. SELECT VTY(1): chuxu_bei
1-5
0. QUIT
INPUT YOUR CHOICE:
Fast VTY service switching
The characteristics of banking services require each bank branch to provide services such as deposit
and corporate services. However, a terminal at an outlet can process only one type of service. To solve
this problem, the terminal access feature of the router implements the VTY switching function, enabling
a terminal to process multiple services at the same time and to switch between the services
dynamically.
In terminal access, each terminal is divided into eight virtual type terminals (VTYs) logically, each of
which can be configured to correspond to a service (also known as an application). An operator of a
terminal can press the VTY switching menu hotkey to bring up the VTY switching menu and select a
VTY to switch between different services dynamically. This allows more flexible use of terminal access.
In addition, the VTY switching feature provides the screen saving function. When an operator switches
from service 1 to service 2, the operating interface of service 1 is automatically saved. When the
operator switches from service 2 back to service 1, the original operating interface is automatically
restored. If the original operating interface is lost due to a fault, the operator can use the terminal
redrawing function to recover it.
VTY redrawing
You can set the VTY redrawing hotkey on the router. When a terminal does not display the normal
terminal interface for some reasons (for example, when illegible characters appear after the terminal is
turned off and then turned on), pressing the terminal redrawing hotkey can restore the normal terminal
interface.
Idle connection timeout
If the idle connection timeout function is enabled and no data is transmitted between the initiator and
receiver within the idle connection timeout period, the initiator and receiver are disconnected from each
other automatically.
Terminal number fixing
As shown in Figure 1-2, the terminal access program running on the router connected to the terminal
enables the terminals to access the FEPs. The terminals are connected to the router through
asynchronous serial interfaces. The router numbers all the terminals. On the other side, the router
connects to multiple FEPs over the network. Each FEP runs multiple applications. Terminal access
universally numbers all the applications, regardless of whether these applications are running on the
same FEP or on multiple FEPs. With the numbering of the terminals and the applications and the
special processing through the router, the mappings between the terminals and the banking services
are established to implement fixed terminal numbering.
Data encryption
Due to the extensive use of terminal access in banking systems, the requirements of data security
become higher and higher. The terminal access data encryption function can be used to encrypt the
data transmitted between the router and FEPs to improve data security.
1-6
As shown in Figure 1-3, data is transmitted in ciphertext between Router A and the FEP. Router A and
the FEP that runs the program ttyd are responsible for data encryption and decryption. At present, the
advanced encryption standard (AES) encryption is supported.
Figure 1-3 Data encryption procedure between the router and the FEP
Automatic link establishment
The terminal access feature supports the automatic link establishment function. You can enable this
function and configure the automatic link establishment time in terminal template view. When the
terminal is in the "ok" state (meaning the physical connection is normal), the initiator automatically
establishes a TCP connection to the receiver after the specified period. If the automatic link
establishment function is disabled on the terminal, a link needs to be established manually. In this mode,
the initiator establishes a TCP connection to the receiver only after you enter a character on the
terminal.
Automatic link teardown
The terminal access feature supports the automatic link teardown function. You can enable the function
and configure the automatic teardown time for the terminal in terminal template view. When the terminal
device and the initiator are disconnected from each other, the terminal enters the "down" state. Then
after the specified period of time, the initiator automatically tears down the TCP connection to the
receiver. In this case, the TCP connection remains active if the automatic link teardown function is
disabled.
One-to-one access
In one-to-one access, each terminal communicates with the FEP through a TCP connection to achieve
optimum communication quality and highest communication speed under various link states. High
terminal echo rates can still be achieved over low-speed links through parameter adjustments.
Frequent and massive printing needs of users can also be satisfied in this mode.
Terminal display language configuration
The initiator generally sends some unsolicited information, such as menus and link establishment
information, to the terminal. To meet different language needs, the prompt information can be displayed
in either English or Chinese (the default).
Screen saving
Some types of terminals provide the screen saving function, enabling the terminals to switch to the
corresponding screen upon receiving the specified screen code, such as \E!10Q. When you perform
1-7
VTY service fast switching, the router sends a screen code to the terminal, which switches to the
corresponding operation interface after saving the current operation interface.
To save the screens of multiple VTYs, you need to set different screen codes for these VTYs and make
sure the number of screen codes supported by the terminal is greater than the number of configured
VTYs. Note that this function needs terminal support. In addition, the screen codes that can be identified
vary with terminal types and the number of supported screen codes may also be different. For details,
refer to the corresponding terminal manuals.
Read blocking
Terminal data read blocking means that, if the router has not sent data received from the terminal
successfully, the router stops receiving data from the terminal until all the data is sent successfully.
Generally, you need to enable this function only when the transmission rate between the router and the
FEP is less than that between the router and the terminal.
Terminal reset
In case the terminal fails to communicate with the receiver, you can press the terminal reset hotkey on
the terminal so that the initiating router will first disconnect and then reestablish the TCP connection with
the receiver.
Connectivity test
You can set the terminal test hotkey on the router. By pressing the test hotkey on the terminal, you can
test the connectivity between the terminal and the router and the TCP connectivity between the terminal
and the FEP.
Data send delay
After data send delay is configured on the router, upon receiving data from the terminal, the router will
not send the data to the FEP until the specified period elapses. This allows the information collected
within the specified period to be sent together, thus increasing bandwidth utilization.
TCP buffer parameter configuration
Terminal access allows you to perform two types of buffer parameter configuration operations: TCP
buffer and terminal buffer. TCP buffer is used to store the data exchanged between the sender and
receiver. Terminal buffer is used to store the data exchanged between the sender and the terminal.
You can set some parameters of TCP connection, including receive buffer size, transmit buffer size,
non-delay attribute, keepalive interval and transmission times.
Terminal buffer parameter configuration
You can set the parameters of terminal buffer, including whether to clear the buffer before receiving data,
receive buffer size, transmit buffer threshold, and the maximum size of data to be sent to the terminal at
one time.
Threshold for VTY switching failure times
When an RTC client needs to initiate a connection to an RTC server, it first initiates a connection to the
RTC server that corresponds to the VTY with the lowest number. If the number of connection failures
exceeds the threshold configured, the RTC client will initiate a connection to the RTC server that
corresponds to the VTY with the second lowest number.
1-8
Receiver VTY switching rules
If the RTC server is configured to switch between VTYs based on priority (the lower the VTY number,
the higher the priority) and the VTY number corresponding to a new connection request is less than the
VTY number corresponding to the existing connection, the RTC server tears down the existing
connection and begins to use the new connection for communication. If the RTC server is not
configured to perform VTY switching based on priority and a connection is already established, the RTC
server will ignore any new connection request.
RTC terminal authentication
In terminal access, the RTC server can perform password authentication for RTC clients to enhance
security. Authentication succeeds only when the passwords configured on the RTC server and the RTC
client are the same.
Terminal access multi-instance
Terminal access multi-instance means that terminal access supports VPN multi-instance. That is, some
of the terminals connected to the router can be grouped in one VPN domain and some other in another
VPN domain. This allows a terminal to access the FEP or remote router that is in the same VPN domain
as the terminal.
Server connection authentication
In practice, some users need to use the FEP to perform necessary authentication on the connected
router to enhance data security. At present, two authentication modes are supported: character
string-based authentication and MAC-based authentication.
In character string-based authentication, which is similar to password authentication, the same
authentication character string is configured on the FEP and the router. To establish a connection with
the FEP, the router sends the authentication character string to the FEP, and the FEP checks whether
the authentication character string is correct. If yes, the authentication succeeds; if not, the
authentication fails and the connection attempt fails.
The difference between MAC-based authentication and character string-based authentication is that
the MAC addresses configured on the FEP and the router are the same. This MAC address is the MAC
address of an interface on the router (You can specify this MAC address with a command).
Terminal Access Specifications
Specifications of the terminal access initiator
No. Item Description

255 (This number is subject to the number of
router interfaces available for terminal access.
1 Maximum number of TTYs For TTY terminal access, this number is also
subject to the number of FEPs that can be
configured.)
2 Maximum number of APPs 2,040
Maximum number of VTYs supported
3 8
by each TTY
1-9
z Asynchronous serial interface: 3AS, 8AS,
16AS, 8ASE, 16ASE
Types of interfaces supported by
4 z Synchronous/ Asynchronous serial interface:
terminal access
2SA, 4SA, 2S1B, 8LSA, 4SAE, 8SAE
z AUX interface
5 Terminal emulation type VT100
6 Terminal baud rate 300 bps to 115,200 bps
Specifications of the terminal access receiving router

255 (This number is subject to
1 Maximum number of TTYs the number of router interfaces
available for terminal access.)
2 Maximum number of APPs 2,040
3 Maximum number of VTYs supported by each TTY 8
Specifications of the terminal access receiving FEP

1 Maximum number of VTYs supported by a Unix FEP 250
2 Maximum number of VTYs supported by a Linux FEP 160

z SCO OpenServer 5.0.5
z SCO UnixWare 7.1 (only for
the one-to-one mode)
3 Supported Unix versions
z Sun OS 5.7
z IBM AIX 4.3.3
z HP UX 10.20, 11.0
4 Supported Linux version Red Hat Linux 9.0
Terminal Access Configuration Task List

You need to perform configuration on the initiator and the receiver respectively as required. RTC
terminal access is initiated and received by routers. TTY terminal access and Telnet terminal access are
initiated by a router and received by a FEP.
Functionally, the configuration commands fall into three types: basic configuration commands,
advanced configuration commands, and display and maintenance commands. Basic configuration
commands are the commands that must be used for normal operation of terminal access. Advanced
configuration commands are used for implementing the extended functions of terminal access. Display
and maintenance commands are used for displaying and debugging terminal access.
In terms of view, the configuration commands can be classified as the commands available in user view,
commands available in system view, commands available in template view, and commands available in
interface view. Most important configurations of the terminal access system are performed in templates.
You can save a series of router parameter configurations in a template. When applying a template to an
1-10
interface, (an asynchronous interface, for example), the system creates a TTY according to the
contents of the template and the specified terminal number, and sets up VTYs on the basis of the
configuration information in the template. If you modify a template that was applied to an interface, you
can use the update changed-config command to update the configuration of the terminal using the
template. For convenience, you can configure multiple templates at the same time and apply the
templates on different interfaces. Note that only one template can be applied on one interface.
Complete the following tasks to configure terminal access:
Task Remarks
Configure TTY Configuring the TTY Initiator Optional

terminal access Configuring the TTY Receiver Optional
Configure Telnet Configuring the Telnet Initiator Optional

terminal access Configuring Telnet Receiver Optional
Configure RTC Configuring the RTC Initiator (RTC Client) Optional

terminal access Configuring the RTC Receiver (RTC Server) Optional
TTY Terminal Access Configuration

Configuring the TTY Initiator
Follow these steps to perform basic TTY initiator configuration:

Enable terminal access on the Required

rta server enable
router Disabled by default.
Create a terminal template and
rta template template-name Required
enter terminal template view
Required
vty vty-number tty remote After this configuration, Telnet
Configure a TTY VTY ip-address port-number VTYs can be configured in this
[ source source-ip ] template, but RTC client VTYs
or RTC server VTYs cannot.
Exit terminal template view quit
interface-number
Required
Configure the asynchronous By default, an asynchronous
serial interface to operate in the async mode flow serial interface operates in the
flow mode protocol mode and an AUX
interface the flow mode.
Apply the template to the rta terminal template-name
Required
interface terminal-number
Exit interface view quit
1-11
Enter TTY user interface view [ last-num1 ] | tty first-num2
[ last-num2 ] }
Required
Enable software flow control of
the data on the current user flow-control software By default, the flow control
interface mode is none; that is, no flow
control is implemented.
z For details about the async mode flow command, refer to the async mode command in WAN
Interface Commands in the Access Volume.
z After a template is applied on an interface, you need to set the flow control mode of the user
interface corresponding to the interface to software flow control. You can use the display
user-interface command to display the associations between interfaces and user interfaces.
z For details about the user-interface command, refer to the user-interface command in User
Interface Commands in the System Volume.
z For details about the flow-control software command, refer to the flow-control command in User
Interface Commands in the System Volume.
Follow these steps to perform advanced TTY initiator configuration:

Configure the global source IP Optional

rta source-ip ip-address
address of TCP connection Not configured by default.
Bind the MAC address of the rta bind mac-address Optional
interface for service connection interface interface-type
authentication interface-number Not configured by default.
Bind the character string for Optional

service connection rta bind string string
authentication Not configured by default.
Enter terminal template view rta template template-name
Optional
Configure the automatic link 0 seconds by default; that is, no
auto-close time
teardown time automatic link teardown is
performed.
Optional
auto-link time
establishment time automatic link establishment is
performed.
Optional
Bind a VPN instance bind vpn-instance vpn-name
1-12
Optional
Enable data encryption data protect router-unix By default, data encryption is
disabled between the router
and the Unix FEP.
Enable terminal data read Optional

data read block
blocking Disabled by default.
Optional
Configure the terminal data
data send delay milliseconds 0 milliseconds by default; that
send delay
is, there is no send delay.
Configure the router not to clear Optional

the terminal receive buffer after By default, the router clears the
driverbuf save
the TCP connection is terminal receive buffer after the
established TCP connection is established.
Configure the terminal receive Optional

driverbuf size size
buffer size 8 KB by default.
Optional
Configure the TCP connection
idle-timeout seconds 0 seconds by default; that is,
idle timeout time
the connection never times out.
Optional
menu hotkey Not configured by default.
Configure the menu hotkey
ascii-code&<1-3> Use the print menu command
before using this command.
Optional
Configure a screen code for the Not configured by default.
menu screencode string
menu screen Use the print menu command
Configure the language of the print language { chinese | Optional

print information english } Chinese by default.
Enable the router to print Optional

print information
information on the terminal Enabled by default.
Optional
By default, terminal connection
Configure to print terminal
information is printed on the
connection information on the print connection-info
terminal.
terminal
Use the print menu command
Optional
Enabled by default.
Enable to print menu on the
print menu Use the print information
terminal
command before using this
command.
Configure the VTY redrawing Optional

redrawkey ascii-code&<1-3>
hotkey Not configured by default.
Configure the terminal reset Optional

resetkey ascii-code&<1-3>
1-13
Configure the maximum size of Optional
data to be sent to a terminal at sendbuf bufsize size
one time 500 bytes by default.
Configure the terminal send Optional

sendbuf threshold value
buffer threshold Not configured by default.
Configure the connectivity test Optional

testkey ascii-code&<1-3>
Optional
By default, receive buffer size is
tcp { keepalive time count | 2,048 bytes, send buffer size is
nodelay | recvbuf-size 2,048 bytes, delay is enabled,
Configure TCP parameters
recvsize | sendbuf-size keepalive interval is 50
sendsize } seconds, and the number of
times for transmitting a
keepalive is 3.
Configure a description for a vty vty-number description Optional

VTY string Not configured by default.
Configure the character string Optional
vty vty-number screencode
for triggering VTY screen
string Not configured by default.
saving
Configure the VTY switching vty vty-number hotkey Optional

hotkey ascii-code&<1-3> Not configured by default.
Update the configuration update changed-config Optional
z If both the global source IP address and the source IP address for a VTY are configured, the one
for the VTY is used.
z The TCP parameters must be configured before TCP connections are established. If you configure
the parameters after a TCP connection is established, the TCP connection must be reestablished
for the parameters to take effect. Pressing the reset hotkey on the terminal can reestablish the TCP
connection.
z Receive buffer size must be configured before the terminal template is applied. If you configure the
receive buffer size after a terminal template is applied, you need to remove the application of the
terminal template and apply the terminal template again for the receive buffer size to take effect.
z The ASCII value of the hotkey must be different from the ASCII value of any other hotkey
configured on the device. Otherwise, hotkey conflicts will occur. For example, the hotkey value
cannot be set to 17 or 19 because these two values are used for the hotkeys of flow control. In
addition, using the hotkey may not get a response rapidly when the terminal displays too much
data.
1-14
Configuring the TTY Receiver
The receiver of TTY terminal access is an FEP. The main program of terminal access at an FEP is the
program ttyd (ttyd executable), which implements the data exchange with the router-side programs. To
configure your FEP, refer to the related sections in FEP Installation and Configuration.
TTY Terminal Access Configuration Example
The deposit services run on the Unix server, whose IP address is 1.1.254.77/16. The listening port of
the ttyd program on the Unix server is 9010.
The router is connected to four terminals through its four asynchronous interfaces. The source IP
address to be bound is 2.2.2.1/32.
Network diagram
Figure 1-4 Network diagram for TTY terminal access configuration
Perform the following configuration in one-to-one mode:

z Configure the initiator (router).
# Enable terminal access.
[Sysname] rta server enable
z # Create a template and enter template view.
[Sysname] rta template temp1
# Configure a VTY application.

[Sysname-rta-template-temp1] vty 0 tty remote 1.1.254.77 9010
[Sysname-rta-template-temp1] quit
# Configure the Ethernet interface.

1-15
# Create a Loopback interface and configure source IP address binding.
[Sysname] interface loopback 0
[Sysname-loopback0] ip address 2.2.2.1 255.255.0.0
[Sysname-loopback0] quit
[Sysname] rta source-ip 2.2.2.1
# Apply the template to the asynchronous serial interfaces.

[Sysname] interface async 1/0
[Sysname-Async1/0] async mode flow
[Sysname-Async1/0] rta terminal temp1 1
[Sysname-Async1/0] interface async 1/1
# Configure software flow control.

[Sysname] user-interface tty 17 20
[Sysname-ui-tty17-20] flow-control software
z Configure the receiver (Unix server).
Perform the following configuration by referring to FEP Installation and Configuration. The following
uses SCO OpenServer Unix as an example.
1) # Edit the file /etc/ttyd.conf.
serverport 9010
mode 1
ttyp40 2.2.2.1 1
ttyp41 2.2.2.1 2
ttyp42 2.2.2.1 3
ttyp43 2.2.2.1 4
2) Modify system configuration file /etc/inittab
Suppose the terminals operate in the active terminal mode. Check whether the pseudo terminal devices
have been configured in the file inittab. Edit the file /etc/inittab and see whether the following information
is available. If not, add this information.
After adding, execute the init q command to bring the configuration into effect.
# init q
The above are basic configurations. After verifying terminal connectivity to the server, you can proceed
with other configurations.
3) Add a route on the FEP.
# route add 2.2.2.1 netmask 255.255.0.0 1.1.247.88
1-16
Telnet Terminal Access Configuration
Configuring the Telnet Initiator
Follow these steps to perform basic Telnet initiator configuration:


rta server enable
Required
vty vty-number telnet remote After this configuration, the
Configure a Telnet VTY ip-address [ port-number ] template can be configured
[ source source-ip ] with Telnet VTYs, but not RTC
client VTYs or RTC server
VTYs.
Required
Enter interface view The interface type must be
interface-number
supported by terminal access.
Required
Apply the template to an rta terminal template-name
Required
Exit interface view. quit
[ last-num2 ] }
Required
data on the current user flow-control software By default, the flow control
1-17
Interface Commands in the Access Volume.
Interface Commands of the System Volume.
Follow these steps to perform advanced Telnet initiator configuration:

Configure the global Optional

source IP address of rta source-ip ip-address
TCP connection Not configured by default.
Enter terminal template

rta template template-name
view
Optional
Configure the automatic
auto-close time 0 seconds by default; that is, no
link teardown time
automatic link teardown is performed.
Optional
Configure the automatic 0 seconds by default; that is, no
auto-link time
link establishment time automatic link establishment is
performed.
Optional
Bind a VPN instance bind vpn-instance vpn-name
Enable terminal data Optional

data read block
read blocking Disabled by default.
Optional
Configure the terminal
data send delay milliseconds 0 milliseconds by default; that is, there
data send delay
is no send delay.
Configure the router not Optional
to clear the terminal
receive buffer after a driverbuf save By default, the router clears the
TCP connection is terminal receive buffer after a TCP
established connection is established.
Configure the terminal Optional

driverbuf size number
buffer size 8,192 bytes by default.
Configure the TCP Optional

connection idle timeout idle-timeout seconds 0 seconds by default; that is, the
time connection never times out.
1-18
Optional
Configure the menu menu hotkey Not configured by default
hotkey ascii-code&<1-3> Configure menu printing before
configuring the menu hotkey.
Configure a screen code Optional

menu screencode string
for the menu screen Not configured by default.
Optional
Configure to print
terminal connection
print connection-info information is printed on the terminal.
information on the
terminal Use the print information command
Configure the router to Optional

print information on the print information By default, the router prints information
terminal on the terminal.
Optional
By default, the menu is printed on the
Configure the router to
print menu terminal.
print the menu
Use the print information command
Configure the language print language { chinese | Optional

of the print information english } Chinese by default.
Set the terminal reset Optional

resetkey ascii-code&<1-3>
size of data to be sent at sendbuf bufsize size
Configure the terminal Optional

send buffer threshold Not configured by default.
Set the terminal Optional

testkey ascii-code&<1-3>
connectivity test hotkey Not configured by default.
Optional
tcp { recvbuf-size recvsize | By default, receive buffer size is 2,048
Configure TCP sendbuf-size sendsize | bytes, send buffer size is 2,048 bytes,
parameters nodelay | keepalive time delay is enabled, keepalive interval is
count } 50 seconds, and the number of times
for sending a keepalive is 3.
Configure a description vty vty-number description Optional

for a VTY string Not configured by default.
Configure a screen code
vty vty-number screencode Optional
for a VTY screen
string Not configured by default.
Configure the VTY vty vty-number hotkey Optional

switching hotkey ascii-code&<1-3> Not configured by default.
1-19
z If both the global source IP address and the source IP address of a VTY are configured, the one of
the VTY is used.
z The parameters for TCP connections must be configured before the TCP connections are
established. If you configure the parameters after a TCP connection is established, the TCP
connection must be reestablished for the parameters to take effect. Pressing the reset hotkey on
the terminal can reestablish the TCP connection.
z The receive buffer size must be configured before the terminal template is applied. If you configure
the receive buffer size after a terminal template is applied, you need to remove the application of
the terminal template and apply the terminal template again for the receive buffer size to take
effect.
data.
Configuring Telnet Receiver
The receiver of Telnet terminal access is an FEP. An FEP only needs to run the Telnet server program
and the corresponding application program; there is no need to modify or compile the Unix kernel.
Telnet Terminal Access Configuration Example
Consider two Unix FEPs whose IP addresses are 10.110.96.53 and 10.110.96.54 respectively and
whose port numbers are 23. A Star terminal is used at the outlet. On the terminal, the first VTY
corresponds to FEP 1, with the VTY switching hotkey of < Alt+A >; the second VTY corresponds to FEP
2, with the VTY switching hotkey of <Alt+B> and the menu hotkey of <Alt+C>.
Network diagram
Figure 1-5 Network diagram for Telnet terminal access configuration
1-20
z Configure the initiator.

# Create a terminal access template and enter its view.

[Sysname] rta template temp2
# Configure VTY 0.
[Sysname-rta-template-temp2] vty 0 telnet remote 10.110.96.53
[Sysname-rta-template-temp2] vty 0 description chuxu_zhu
# Configure the screen saving code for the VTY 0.

[Sysname-rta-template-temp2] vty 0 screencode \E!8Q
# Configure the hotkey for VTY 0 as <Alt+A>.

[Sysname-rta-template-temp2] vty 0 hotkey 1 96 13
# Configure VTY 1.
[Sysname-rta-template-temp2] vty 1 telnet remote 10.110.96.54
[Sysname-rta-template-temp2] vty 1 description chuxu_bei
# Configure the screen saving code for VTY 1.

[Sysname-rta-template-temp2] vty 1 screencode \E!9Q
# Configure the hotkey for VTY 1 as <Alt+B>.

[Sysname-rta-template-temp2] vty 1 hotkey 1 97 13
# Configure the menu hotkey as <Alt+C>.

[Sysname-rta-template-temp2] menu hotkey 1 98 13
[Sysname-rta-template-temp2] quit
# Apply the template to the asynchronous serial interface.

[Sysname-Async1/0] quit
# Configure software flow control.

[Sysname] user-interface tty 17
[Sysname-ui-tty17] flow-control software
After the above-mentioned configurations, you can see the following menu on the terminal (You can
enter an option on the display or exit by pressing <Esc>.):
TTY ACCESS SYSTEM
VERSION 3.0
1. SELECT VTY(0): chuxu_zhu

2. SELECT VTY(1): chuxu_bei
0. QUIT
1-21
INPUT YOUR CHOICE:
z Configure the receiver.
The receivers of Telnet terminal access are FEPs. An FEP only needs to run the Telnet server program
and the corresponding application program; there is no need to modify or compile the Unix kernel.
RTC Terminal Access Configuration

Configuring the RTC Initiator (RTC Client)
The initiator of asynchronous RTC terminal access is an RTC client connected to the monitoring device.
The receiver of asynchronous RTC terminal access is the RTC server connected to the monitored
device. An RTC client can initiate a connection request to the RTC server at any time to access the
data.
Follow these steps to perform basic RTC initiator (RTC client) configuration:


rta server enable

Required
vty vty-number rtc-client
remote ip-address After this configuration, the
Create a RTC client VTY template cannot be configured
port-number [ source
source-ip ] with any TTY, Telnet, or RTC
server VTYs.
Required
interface-number
Required
Apply the template to the rta terminal template-name
Required
[ last-num2 ] }
Required
data on the current user flow-control software By default, the flow control
1-22
Interface Commands of the Access Volume.
Follow these steps to perform advanced RTC initiator (RTC Client) configuration:


address for TCP connections Not configured by default.
Optional
auto-close time
performed.
Optional
auto-link time
establishment time automatic link establishment is
performed.
Bind a VPN instance to the Optional

bind vpn-instance vpn-name
template Not configured by default.

data read block
Optional
Configure the data send delay data send delay milliseconds 0 milliseconds by default; that
Optional
Configure the router not to clear
the terminal buffer after a TCP driverbuf save By default, the router clears the
connection is established terminal receive buffer after a
TCP connection is established.
Configure the terminal receive Optional

driverbuf size size
buffer size 8,192 bytes by default.
Optional
idle timeout time
1-23
Optional
Configure to print terminal information is printed on the
connection information on the print connection-info terminal.
terminal Use the print information
command before using this
command.
Optional
Configure the router to print
print information By default, the router prints
information on the terminal
information on the terminal.

Optional
Set the terminal reset hotkey resetkey ascii-code&<1-3>
data sent by the terminal send sendbuf bufsize size
buffer at one time 500 bytes by default.

Optional
tcp { recvbuf-size recvsize | 2,048 bytes, send buffer size is
sendbuf-size sendsize | 2,048 bytes, delay is enabled,
nodelay | keepalive time keepalive interval is 50
count } seconds, and the number of
times for sending a keepalive is
3.
Configure the password for vty vty-number password Optional

VTY authentication { simple | cipher } string Not configured by default.
Configure a screen code for the vty vty-number screencode Required

VTY screen string Not configured by default.
Configure the VTY switching vty vty-number hotkey Optional

hotkey ascii-code&<1-3> Not configured by default.
Optional
Configure the VTY switching Not configured by default; that
vty-switch threshold times
threshold is, no switching will be
performed.
1-24
z To implement terminal access authentication, terminal access authentication must be configured
on both the RTC server and the RTC client, and the authentication passwords must be the same
for the authentication to succeed.
z The bind vpn-instance command is used when the RTC client also acts as an MPLS PE router at
the same time. When you apply a terminal template configured with the bind vpn-instance
command to an asynchronous serial interface, the terminal connected to the asynchronous serial
interface is bound with the VPN instance. Thus, the RTC client can receive terminal access
packets from multiple VPNs and initiate connection requests through multiple asynchronous serial
interfaces.
z If both the global source IP address and the source IP address for a VTY are configured, the VTY
uses the latter one.
z The TCP parameters must be configured before a TCP connection is established. If you configure
connection.
z The receive buffer size must be configured before the terminal template is applied. If you configure
effect.
data.
Configuring the RTC Receiver (RTC Server)
Follow these steps to perform basic RTC receiver (RTC server) configuration:
Enable terminal access rta server enable Required
rta rtc-server listen-port Required

Configure the listening port
port-number Not configured by default.
Required
vty vty-number rtc-server After this configuration, the
Create a RTC server VTY remote ip-address template cannot be configured
terminal-number with any TTY, Telnet, or RTC
client VTYs.
1-25
Required
nterface interface-type
nterface-number
Required
Apply the template to an rta terminal template-name
Required
Exit interface view. quit
[ last-num2 ] }
Required
the data on the current user flow-control software By default, the flow control
Interface Commands of the Access Volume.
Follow these steps to perform advanced RTC receiver (RTC server) configuration:

address for TCP connections Not configured by default.
Optional
auto-close time
performed.
Bind a VPN instance to the Optional

bind vpn-instance vpn-name
template Not configured by default.
1-26

data read block
Optional
Configure the terminal data
data send delay milliseconds 0 milliseconds by default; that
send delay
Optional
Configure the router not to clear
the terminal buffer after a TCP driverbuf save By default, the router clears the
connection is established terminal receive buffer after a
TCP connection is established.
Configure the terminal buffer Optional

driverbuf size number
size 8 KB by default.
Optional
idle timeout time
Optional
Configure to print terminal
information is printed on the
connection information on the print connection-info
terminal.
terminal
Use the print menu command
Optional
Configure the router to print
print information By default, the router prints
information on the terminal
information on the terminal.

data to be sent to a terminal at sendbuf bufsize size

Optional
tcp { recvbuf-size recvsize | 2,048 bytes, send buffer size is
sendbuf-size sendsize | 2,048 bytes, delay is enabled,
nodelay | keepalive time keepalive interval is 50
count } seconds, and the number of
times for sending a keepalive is
3.
Configure the password for the vty vty-number password Optional

VTY authentication { simple | cipher } string Not configured by default.
Configure the RTC server to Optional
perform VTY switching by
vty-switch priority By default, the VTY switching is
priority (the lower the VTY
number, the higher the priority) performed not by priority.
1-27
z The port number specified for the VTY application on the RTC client must be the same as the
listening port number specified on the RTC server.
z The vty-number argument of the command vty rtc-server remote configured on the RTC server
must be the same as the terminal-number argument of the command rta terminal configured on
the RTC client; otherwise, no TCP connection can be established
z Each terminal of the RTC server corresponds to a different RTC client.
z If not configured with the bind vpn-instance command, the RTC server can accept connection
requests from any VPNs.
z The TCP parameters must be configured before a TCP connection is established. If you configure
connection.
z The receive buffer size must be configured before a terminal template is applied. If you configure
effect.
Asynchronous RTC Terminal Access Configuration Example
Two routers, one serving as the RTC client and the other the RTC server, are connected to the central
terminal device and the remote terminal device respectively.
z The RTC listening port of the RTC server is 9000.
z The central terminal device is connected to the asynchronous serial interface Async 1/0 on the
RTC client. The remote terminal device is connected to the asynchronous serial interface Async
1/0 on the RTC server.
z The RTC client and the RTC server have the same terminal number of 1.
Network diagram
Figure 1-6 Network diagram for asynchronous RTC terminal access configuration
1-28
1) Configure the RTC server.

# Set the listening port of the server.

[Sysname] rta rtc-server listen-port 9000

[Sysname] rta template rtcserver
# Configure the VTY.

[Sysname-rta-template-rtcserver] vty 0 rtc-server remote 10.111.0.12 1
[Sysname-rta-template-rtcserver] vty 0 password simple 123
# Apply the template to the interface.

[Sysname-rta-template-rtcserver] quit
[Sysname-Async1/0] rta terminal rtcserver 1
2) Configure the RTC client.

[Sysname] rta template rtcclient
# Configure the VTY.

[Sysname-rta-template-rtcclient] vty 0 rtc-client remote 10.111.95.10 9000
[Sysname-rta-template-rtcclient] vty 0 password simple 123
# Apply the template to the interface.

[Sysname-Async1/0] rta terminal rtcclient 1
Asynchronous RTC Multi-instance Configuration Example
Terminal CE A in the monitoring center and remote terminal CE B are in MPLS VPNA and respectively
connected to the interface Async 1/0 on PE A and PE B. It is required to monitor CE B in real time
through CE A.
z The terminal numbers of PE A and PE B are 2.
z The listening port of the RTC server is 9000.
1-29
Network diagram
Figure 1-7 Network diagram for asynchronous RTC multi-instance configuration
1) Configure the RTC server.

# Configure MPLS L3VPN. For details, see MPLS L3VPN Configuration in the MPLS Volume.
# Bind Loopback 1 to VPNA.
[PEB] interface loopback 1
[PEB-LoopBack1] ip binding vpn-instance vpna
[PEB-LoopBack1] ip address 169.254.3.1 32
[PEB-LoopBack1] quit

[PEB] rta server enable
# Configure the listening port number of the RTC server.

[PEB] rta rtc-server listen-port 9000
# Configure the terminal access template.

[PEB] rta template rtcs
# Configure VTY 0 on the RTC server.

[PEB-rta-template-rtcs] vty 0 rtc-server remote 169.254.2.1 2
# Bind the VPN instance to the template .

[PEB-rta-template-rtcs] bind vpn-instance vpna
[PEB-rta-template-rtcs] quit
# Configure interface async 1/0.

[PEB] interface async 1/0
[PEB-Async1/0] async mode flow
[PEB-Async1/0] rta terminal rtcs 2
2) Configure the RTC client.
# Configure MPLS L3VPN. For details, see MPLS L3VPN Configuration in the MPLS Volume.
# Bind Loopback 1 to VPNA.
[PEA] interface loopback 1
1-30
[PEA-LoopBack1] ip address 169.254.2.1 32
[PEA-LoopBack1] ip binding vpn-instance vpna
[PEA-LoopBack1] quit

[PEA] rta server enable
# Configure a terminal access template.

[PEA] rta template rtcc
# Configure VTY 0 on the RTC client.

[PEA-rta-template-rtcc] vty 0 rtc-client remote 169.254.3.1 9000
# Bind VPNA to the template.

[PEA-rta-template-rtcc] bind vpn-instance vpna
[PEA-rta-template-rtcc] quit
# Configure interface async 1/0.

[PEA] interface async 1/0
[PEA-Async1/0] async mode flow
[PEA-Async1/0] rta terminal rtcc 2
[PEA-Async1/0] quit
Displaying and Maintaining Terminal Access Configuration

display rta { all | statistics |
Display specified terminal
terminal-number { brief | detail Available in any view
access information
| statistics | vty-number } }
reset rta statistics
Clear the statistics of a terminal Available in user view
terminal-number
1-31
2 FEP Installation and Configuration
When installing and configuring FEP, go to these sections for information you are interested in:
z Installing and Configuring SCO OpenServer Server
z Installing and Configuring SCO UnixWare Server
z Installing and Configuring SUN OS Server
z Installing and Configuring IBM AIX Server
z Installing and Configuring HP-UX Server
z Installing and Configuring Red Hat Linux Server
To implement terminal access with an FEP as the receiver, the router-side program serving as the
initiator must work together with the FEP-side programs serving as the server that receives connection
requests from the initiator. This chapter covers the installation, configuration, operation, and
management of FEP-side programs.
Normally, an FEP runs the following two programs:
z ttyd (ttyd executable) program, which is the main program running at the FEP side in terminal
access. It exchanges data with the router-side program.
z ttyadm terminal administration program, consisting of two executables: ttyadmcmd and ttyadm.
This program manages the ttyd program.
A Unix FEP supports up to 250 terminals. A Linux FEP supports up to 150 terminals.
Installing and Configuring SCO OpenServer Server

Installing Device Drivers
Using a floppy disk
The following describes the installation procedure using a floppy disk.

1) Switch to a console terminal.
To install the ttyd program, you need at least one console terminal. In SCO OpenServer Unix, use a
hotkey from <Alt+F1> to <Alt+F12> to switch between console terminals.
2) Log in as a super user such as root.
To install and configure this program, you must log in as a super user as follows:
Step1: Press a hotkey to switch to a console, <Alt+F4> for example. The following interface appears:
SCO OpenServer(TM) Release 5 (scosysv) (tty04)
login:
Step 2: At the prompt of login:, enter root. Then, at the prompt of Password:, enter the password root.
Then, you can log in to the Unix server as root.
3) Install the drivers
Insert the floppy disk into the floppy drive of the Unix server and then run the mount command to mount
the floppy drive.
# mount /dev/fd0 /mnt
2-1
Copy the executable files to the Unix server.
# cp /mnt/ttyd /etc/ttyd
# cp /mnt/TTYADMCMD /etc/ttyadmcmd
# cp /mnt/TTYADM /etc/ttyadm
Change the file mode of the files to the executable mode.

# chmod 744 /etc/ttyd /etc/ttyadm /etc/ttyadmcmd
File names are case-sensitive in Unix. Use the ls /mnt command to view the names of the files before
copying them.
Thus, the ttyd, ttyadmcmd, and ttyadm programs are installed.
After completing the above-mentioned tasks, make sure you use the umount command to unmount the
floppy drive as follows:
# cd /
# umount /mnt
Using FTP
You can also use FTP to install the ttyd programs. The following describes the installation procedure
using FTP on a Windows system.
1) Place the ttyd programs in a directory
You must place the ttyd programs under a directory of the Windows system, for example, c:\ttyd.
2) Open the DOS window and run the ftp command.
Open the DOS window. Run the ftp command under the directory c:\ttyd to connect to the Unix server
and log in as root. The following configuration example assumes that the IP address of the FEP is
10.110.96.53:
C:\ttyd>ftp 10.110.96.53
Connected to 10.110.96.53.
220-
220 sco2 FTP server (Version 2.1WU(1)) ready.
User (10.110.96.53:(none)):User (10.110.96.53:(none)): root
331 Password required for root.
Password:
230 User root logged in.
ftp>
3) Enter the directory /etc of the Unix server, and transfer the programs ttyd and ttyadmcmd to the
Unix server in binary format (ttyd and ttyadmcmd are binary executables).
ftp> cd /etc
ftp> bin
2-2
ftp> put ttyd
ftp> put ttyadmcmd
Transfer the program ttyadm to the Unix server in text format. Then, exit FTP.
ftp> ascii
ftp> put ttyadm
ftp> bye
4) On the Unix server, change the file modes of the programs to the executable mode.
# chmod u+x /etc/ttyd /etc/ttyadm /etc/ttyadmcmd
Now, the ttyd, ttyadmcmd, and ttyadm programs are installed.
Using the installer
For the SCO OpenServer Unix system, make sure you have a standard program installation CD
supporting this system. You can use the installation program named VOL.000.000 on the disk to install
the ttyd, ttyadmcmd, and ttyadm programs to your SCO OpenServer Unix server. The installation
1) Copy the installation file VOL.000.000 to a directory on the SCO OpenServer Unix server. The
following example assumes that the installation file is copied to the directory /build. Type scoadmin
to open the SCO manager.
2) From [\File\Software Manager], select [\Software\Install New...] to enter software installation
interface, and then select local installation.
3) Select [Media Images] for Media Device.
4) In [Image Directory], enter the directory holding the installation file (this example assumes
VOL.000.000 is placed in the directory /build). Press <Enter>, and information about the programs
under the directory that can be installed will be listed, such as " ttyd for sco openserver 5.05".
5) Select [Install] to start the installation. After the programs are installed, a message of OK is
displayed.
Now, the ttyd, ttyadmcmd, and ttyadm programs are all installed.
Before configuration, you must determine the mappings between pseudo terminals on the Unix server
and ports on the router.
If the Unix system is connected with many terminals, the required resources may exceed the default of
the Unix system. In this case, you must modify the kernel parameters of the Unix system.
The method for modifying the kernel of the SCO OpenServer Unix system is as follows:
Adding pseudo terminals
By default, SCO OpenServer Unix supports up to 64 pseudo terminals. To connect to more terminals,
you must add pseudo terminals on the Unix system.
Before adding pseudo terminals, you must check whether the pseudo terminals exist. For example, you
can use the following command to check whether ttyp50/ptyp50 devices exist. Generally, ttyp and ptyp
devices are present in pairs and each pair shares the same device number.
# ls -l /dev/ttyp50 /dev/ptyp50
If pseudo terminals exist, the console displays the following information:

crw-rw-rw- 1 root sys 59, 50 Aug 6 18:44 /dev/ptyp50
crw------- 1 bin terminal 58, 50 Aug 15 16:24 /dev/ttyp50
2-3
If not, you must create pseudo terminals. To do so, use the scoadmin program as follows.
1) Launch scoadmin.
# scoadmin
2) Select [Hardware/Kernel Manager].
3) Select [Tune Parameters...].
4) Enter 9 to select [TTY and console configuration].
5) Change the value of NSPTTYS: number of pseudo-ttys on system. to 256.
6) Compile the kernel and restart the server. Then, the maximum number of devices becomes 256.
When the kernel is compiled, /etc/inittab is overwritten by /etc/conf/cf.d/init.base. Therefore, back up

/etc/inittab before creating a new kernel.
Modifying the maximum number of files a process can open
By default, each SCO OpenServer Unix process can open up to 110 files. If a Unix server is to be
connected with more than 50 terminals, change number to 600. To do so, execute the following
command:
# /etc/conf/cf.d/configure
Select 7 (User and group configuration), and then change the [maximum number of open files per
process] field to 600.
Modifying the maximum number of processes a user can open
By default, a SCO OpenServer Unix user can open up to 100 processes. If a Unix server is to be
connected with a number of terminals (usually more than 50), change the number to 600. To do so,
execute the following command:
# /etc/conf/cf.d/configure
Select 7 (User and group configuration), and then change the [maximum number of processes available
to user] field to 600.
Validating the new configuration
After modifying system kernel parameters, you must follow the system prompts to run ./link_unix to link
to the system kernel again and then restart the system to bring the changes into effect.
Modifying System Configuration File inittab
Check whether the pseudo terminals are configured in file inittab. Taking ttyp50 as example, edit file
/etc/inittab and check whether the following line is present:
If the line is absent, add it. In the sample line, C50 is the identifier of the line. Each line in file inittab
must have a unique identifier consisting of no more than four characters. According to banking
applications, pseudo terminals fall into two categories: active terminal and dumb terminal. When an
active terminal user logs into the Unix server, the Unix server pushes the login interface to the terminal.
When a dumb terminal user logs into the Unix server, the Unix server does not push the login interface
2-4
to the terminal. In system configuration file inittab, the third column of a line is "respawn" for an active
terminal and "off" for a dumb terminal.
After adding the line, execute the init q command to bring the configuration into effect.
# init q
In addition, you can use the enable command to configure a pseudo terminal as an active terminal, or
use the disable command to configure a pseudo terminal as a dumb terminal.
# enable ttyp50
Editing the ttyd Configuration File
The default ttyd configuration file is /etc/ttyd.conf. In a ttyd configuration file, you can define the listening
port number and map the terminal numbers on the router to the pseudo terminals on the Unix server.
The following shows the format of ttyd configuration file:
# The router terminal access configuration file on the Unix server
serverport 9010
mode 1
nodelay 1
screen 0
lang 1
logsep 1
debugpath /var/ttydlist
sendsize 512
readsize 300
noblock 1
ttyp30 10.110.96.44 1 accesstime 1 8:00-18:00
exit 1
compat 1
The following explains the file format:

In the configuration file, the lines starting with a "#" are comment lines.
serverport 9010
TCP listening port for the ttyd process. By default, it is 9010. A Unix server can run multiple ttyd
processes, each of which must use a unique configuration file and a unique listening port.
mode 1
Operating mode of the ttyd process. It can be 0 for many-to-one mode or 1 for one-to-one mode.
Currently, it must be set to 1.
nodelay 1
Specifies the ttyd process to support (with a value of 1) or not to support (with a value of 0) the nodelay
attribute. The default is 1, meaning that ttyd responds instantly upon receiving data from the peer. On
low speed lines, this can improve the echoing speed.
screen 0
Specifies the ttyd process to support (with a value of 1) or not to support (with a value of 0) the screen
saving function. The default is 0.
2-5
lang 1
Specifies the language for prompting ttyd authentication failure. It can be 0 for Chinese or 1 for English.
The default is 0.
logsep 1
Specifies whether to save ttyd logs separately. It can be 1, meaning that a log file is used for each
terminal, or 0, meaning a log file is used for all the terminals. The default is 1.
debugpath /var/ttydlist
Destination directory of the ttyd debugging file(s). It is /var/ttydlist by default.
autogetty 0
Specifies whether the ttyd program automatically calls the getty program. It can be 0, meaning that, it is
configured in the inittab system configuration file that the system is responsible for calling the getty
program, or 1, meaning the ttyd program will call the getty program. In SCO UnixWare, this value must
be set to 1. Once you set a value of 1, you can no longer configure it in the /etc/inittab file; otherwise,
the program cannot operate normally.
This parameter functions in one-to-one mode only.
sendsize 512
Maximum size of data that the ttyd program can put onto the network in one operation (in bytes). The
default is 512 bytes, and the recommended value is from 384 to 1,024 bytes. You can adjust this value
based on the WAN link status.
readsize 300
Size of data that the ttyd program can read from a pseudo terminal in one operation (in bytes). The
default is 256 bytes, and the recommended value is from 200 to 384 bytes. You can adjust this value
based on the WAN link status.
Note that the value of readsize must be less than that of sendsize.
ttyp30 10.110.96.44 1 accesstime 2 8:00-12:00 13:00-18:00
The triple of the pseudo terminal number, router IP address, and the terminal number configured on the
asynchronous serial interface of the router uniquely determines which router and which terminal on the
router a pseudo terminal corresponds to. This guarantees terminal number fixing. For example, the
above sample entry shows that pseudo terminal ttyp30 on the Unix server corresponds to the terminal
connected to the asynchronous interface with a terminal number of 1 on router 10.110.96.44. The name
of a pseudo terminal must be present in the /dev directory and must start with tty. To configure pseudo
terminal names not to start with "tty", you must use a full path name starting with "/dev/".
accesstime 2 8:00-12:00 13:00-18:00 in the sample entry specifies that the terminal can be connected
to the Unix server during two periods only: 8:00 to 12:00 and 13:00 to 18:00. Up to four access periods
can be defined for a terminal. By default, no time restriction is imposed. Note that access periods are
synchronized with the system clock of the FEP. This parameter functions in one-to-one mode only.
ttyp30 10.110.96.44 1 mac 02-f3-22-3e-2e-01
This sample entry specifies that the router with the IP address of 10.110.96.44 has a MAC address of
02-f3-22-3e-2e-01, and that the router must send its MAC address for authentication before it can
2-6
perform normal operations. After this command is used, MAC address binding must also be configured
on the router.
To configure authentication and access periods at the same time, you need to configure them in the
same line and make sure the access period is configured before the authentication. See the following
example:
ttyp30 10.110.96.44 1 accesstime 1 8:00-18:00 mac 02-f3-22-3e-2e-01
ttyp30 10.110.96.44 1 <str> beijing-01 </str>
"<str> beijing-01 </str>" indicates the character string that the router with the IP address of
10.110.96.44 needs to send for authentication. The router needs to send its authentication character
string. If the authentication character string is consistent with that in the configuration file, the
authentication succeeds; otherwise, the authentication fails. After this command is used, character
string binding must also be configured on the router.
To configure authentication and access periods at the same time, you need to configure them in the
same line and make sure the access period is configured before the authentication. See the following
example:
ttyp30 10.110.96.44 1 accesstime 1 8:00-18:00 <str> beijing-01 </str>
exit 1
You can type "exit" on the terminal to terminate the TCP connection between the terminal and the Unix
server. The default is 0, meaning the TCP connection will not be terminated.
compat 1
Specifies to be compatible with the previous router versions, but some terminal access features will not
be available. The default is 0, indicating incompatibility with the previous router versions.
The ttyd configuration file supports dynamic adding. That is, after ttyd is started, the corresponding
terminal configuration items can be added. The addition takes effect after connection requests are
initiated from the terminals connected to the router or after the configuration file is refreshed with the
ttyadm program, without the need of restarting the ttyd program.
Addition takes effect automatically. For modification and deletion to take effect, however, the
configuration file must be refreshed.
Normally, you need to configure items 1, 2, 4, 9, 11, 12, and 13 as required and use defaults for other
items.
When too many terminals are configured in a configuration file, the file is liable to be modified
improperly. Therefore, you are recommended to configure multiple configuration files on a Unix server
with many pseudo terminals, so that a configuration error does not affect too many applications.
Modifying Route Configuration File
In terminal access, the router is usually connected to the Unix server through WANs and therefore
located on an IP subnet different from that of the Unix server, in which case you must configure a route
on the Unix server. The following example shows how to do so:
2-7
In the example above, 10.110.96.0 is the destination subnet, with the subnet mask of 255.255.255.0
and the next hop IP address of 63.1.1.250.
Running and Terminating ttyd on Unix Server
Running ttyd
You can run the ttyd program after the installation and configuration After installing the device drivers
and configuring the configuration files, you can run the ttyd program as long as you can ping through the
router from the Unix server.
Execute the following command to run the ttyd program.
# /etc/ttyd
If you do not specify any parameters for the command, the default configuration file /etc/ttyd.conf is
used. To specify another configuration file, you must enter file in the following format:
# /etc/ttyd /etc/ttyd9020.conf
A Unix server can run multiple ttyd programs, each of which must use a unique configuration file and a
unique listening port.
You can enter the following command to view the version of ttyd.
# /etc/ttyd -h
Terminating ttyd
The ttyd program operates in multi-process mode. After you launch the program, you may find multiple
ttyd processes. You can enter this command to view information about processes:
# ps -ef | grep ttyd
In one-to-one access mode, ttyd processes are in a two-tier process architecture, where the main
process is parent process 1 and the others are child processes. When you launch a ttyd program, a ttyd
main process is started. Whenever a TCP connection is established between the Unix server and a
terminal, a child ttyd process is started.
# ps -ef | grep ttyd
root 8312 8309 0 17:06:14 ? 00:00:00 /etc/ttyd ttyp40 10.110.96.44 6 /etc/ttyd9010.conf
1026
root 8313 8309 0 17:06:15 ? 00:00:00 /etc/ttyd ttyp41 10.110.96.44 7 /etc/ttyd9010.conf
1028
root 8309 1 0 17:06:11 ? 00:00:00 /etc/ttyd
The output reveals the relations between the processes:

z Process 8309 is the first ttyd process launched, for its parent process is 1.
z Processes 8312 and 8313 correspond to asynchronous interfaces with the terminal numbers of 6
and 7 on router 10.110.96.44 respectively, and their parent process is process 8309.
z All processes use the default configuration file /etc/ttyd.conf.
z You can use the kill 8309 command to kill the ttyd process 8309 and all its child processes, that is,
all the processes mentioned above.
z You can use the kill 8312 command to kill the ttyd child processes corresponding to the pseudo
terminal ttyp40.
You are recommended to use the kill command, rather than the kill -9 command, to kill ttyd processes.
2-8
With automatic link establishment function configured on the router, after you kill a child process and
then use ps-ef, you may still find a process corresponding to the same pseudo terminal, which is
actually a new process.
Enabling ttyd autorun at system startup
1) Open the file /etc/init.d/ttyd.

# vi /etc/init.d/ttyd
2) Add the following to the file:
case "$1" in
'start')
echo "Start ttyd ..."
# To launch multiple configuration files, list each of them in a line.

/etc/ttyd /etc/ttyd.conf
;;
'stop')
echo "Stop ttyd ..."
pid=`ps -ef | grep ttyd | awk '{if ($3 == 1) print $0}' | awk '{print $2}'`
if [ ! "$pid" = "" ]
then
kill $pid
fi
;;
esac
3) Save your configuration and exit.
4) Link the file to the startup directory.
# chmod u+x /etc/init.d/ttyd
# ln -s /etc/init.d/ttyd /etc/rc2.d/S99ttyd
# ln -s /etc/init.d/ttyd /etc/rc0.d/K00ttyd
Installing and Using ttyd Administration Program ttyadm
A terminal administration program named ttyadm is provided for managing ttyd easily on a Unix server.
It consists of two executable files: ttyadmcmd and ttyadm. ttyadm is a shell program and can be
modified as needed and run without compilation, greatly facilitating maintenance. You can use this tool
to manage ttyd processes, without the need of entering complex commands manually. You can also
add your own shell commands into the ttyadm program as desired.
The programs ttyadm, ttyd, and ttyadmcmd must be placed under the same directory.
2-9
After logging into the Unix server as root, enter /etc/ttyadm at the prompt to launch ttyd administration
program. The following main interface appears:
******************************
ttyd Administration Program
******************************
Main menu
1 - Process management
2 - View TCP connections.
3 - View system resources.
4 - View router status.
5 - View statistics.
6 - Edit ttyd configuration file.
0 - Exit
Enter:
You can select a function by entering the corresponding number displayed on the screen. The following
describe each of the functions.
Process management
In the main interface, select option 1 to enter the process management submenu. Then, you can
manage ttyd processes by selecting the corresponding options.
******************************
******************************
Process management
1 Start ttyd.
2 - Display ttyd processes.
3 - Terminate a ttyd process.
4 - Terminate all the ttyd processes corresponding to a specified router
IP address.
5 - Terminate the ttyd process corresponding to a specified terminal.
6 - Set the log output level.
7 - Update the ttyd configuration file.
0 - Return to the main menu.
1) Start ttyd
From the process management submenu, select option 1 and you will be prompted to enter the
directory of the configuration file. The screen displays the following information:
Please enter the ttyd configuration file directory (the default is /etc/ttyd.conf):
Here, you can enter the configuration file directory of the ttyd program to be started. The default is
/etc/ttyd.conf. If you press <Enter> directly, the ttyd program will be started directly. The operation is the
same as entering /etc/ttyd /etc/ttyd.conf at the prompt. If you press <Enter> after entering the
configuration file name, this operation is the same as entering "/etc/ttyd configuration file name" at the
prompt.
2) Display ttyd processes
From the process management submenu, select option 2 to display the ttyd processes running in the
system. The screen displays the following information:
2-10
Main process:
Process No. Port No. Debugging level Number of bytes received from socket Number of bytes
received from tty
12674 9998 0 2 57
6108 9022 3 8 69
Child process:
Process NO. Parent process No. tty device name Router IP Port No. Terminal No.
Debugging level
12676 12674 ttyp55 10.110.96.44 1219 6 0
3) Terminate a ttyd process.
From the process management submenu, select option 3 to display all the ttyd processes running in the
system. Then, you can terminate a ttyd process by entering its process number. If you enter the process
number of a ttyd main process, all the ttyd child processes of that main process will be terminated as
well.
Here is an example:
Main process:
Process No. Port No. Debugging level Number of bytes received from socket Number of bytes
received from tty
12674 9998 0 2 57
6108 9022 3 8 69
Child process:
Process NO. Main process No. tty device name Router IP Port No. Terminal No. Debugging
level
12676 12674 ttyp55 10.110.96.44 1219 6 0
Enter process NO.: 6108
Press <Enter> to return.

4) Terminate all the ttyd processes corresponding to a specified router IP address.
From the process management submenu, select option 4 to display the following information:
Enter router IP address:
Here, you can terminate all the ttyd processes associated with a router by entering the corresponding
router IP address. This makes operation more convenient because you can terminate multiple
processes at one time.
5) Terminate the ttyd process corresponding to a specified terminal.
Terminal in use: ttyp55
Enter the terminal name to terminate (ttypxx):
Here, you can terminate the ttyd process associated with a terminal by entering the corresponding
terminal name. This makes operation more convenient because you do not need to query the number of
the process before terminating it.
6) Set the log output levels.
When a system fault occurs, you may need to determine the cause by viewing the system logs. The
system creates a log file for each main ttyd process and child process. The output directory of the ttyd
debugging file(s) is /var/ttydlist by default. The debugging file of the main ttyd process is named in the
format of ttydxxxx.log, where xxxx is the number for the listening port of the main process. The
2-11
debugging file of a child process is named in the format of ttypxx.log, where ttypxx is the name of the
ttyp device corresponding to the child process.
There are four log output levels:
z Level 0. At this level, only error information is output.
z Level 1. At this level, alarm information is output besides error information.
z Level 2. At this level, prompt information is output besides error and alarm information.
z Level 3. At this level, besides error, alarm, and prompt information, all the data read from and
written to sockets and pseudo-terminals (PTYs) are output in the character format and in the
hexadecimal format respectively.
The default log output level is level 0; that is, only error information will be output. To view more detailed
log information, you need to adjust the log output levels. After the log output level is set to a higher one,
the debugging information that is displayed at all the lower levels will also be output.
Enter the terminal name corresponding to the process or child process.
Here, after you enter the process number or terminal name and press <Enter>, the system will prompt
you to enter the new log output level by displaying the following information:
Enter the new log output level:
Here, the log output level for the corresponding ttyd process will be updated after you enter the new log
output level and press <Enter>.
z When you change the log output level for a process, you can specify a main process by providing
the process number only, but you can specify a child process either by providing the child process
number or the pseudo terminal device name corresponding to the child process.
z If the size of a log file exceeds 1 MB, when its corresponding ttyd process starts the next time, it will
be cleared by the ttyd program and the logging will start all over again. Therefore, save debugging
logs in time.
7) Refresh the ttyd configuration file.

Enter the port No. in the configuration file.
Here, when you enter the corresponding listening port number, the configuration of the ttyd process
corresponding to the configuration file is automatically refreshed.
8) Return to the main menu.
From the process management submenu, selection option 8 to return to the main menu.
Displaying TCP connections
In the main interface, selection option 2 to display the TCP connections in the system. This operation is
same as executing the netstat -p tcp command. The screen displays:
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 sco2.9040 10.110.96.64.listen ESTABLISHED
2-12
tcp 0 0 sco2.ftp 10.110.96.69.1079 ESTABLISHED
tcp 0 0 sco2.9998 10.110.96.44.1219 ESTABLISHED
tcp 0 0 sco2.telnet 10.110.96.54.1235 ESTABLISHED
tcp 0 0 sco2.9021 10.110.96.48.listen ESTABLISHED
Displaying system resource information
In the main interface, select option 3 to enter the system resource submenu. Then, you can display
system resource information by selecting an option in the following. The screen displays:
*****************************
******************************
Display system resources
1 - Display CPU resources.
2 - Display memory resources.
3 - Display stream resources.
Enter:
1) Display CPU resources.
From the system resource submenu, select option 1 to display the CPU resources in the system. This
operation is the same as executing the sar -u 1 5 command. The following displays:
SCO_SV sco2 3.2v5.0.5 i80386 07/15/2002
14:33:16 %usr %sys %wio %idle (-u)

14:33:17 0 0 0 100
14:33:18 0 0 0 100
14:33:19 0 0 0 100
14:33:20 0 0 0 100
14:33:21 0 0 0 100
Average 0 0 0 100

2) Display memory resources.
From the system resource submenu, select option 2 to display the memory resources in the system.
This operation is the same as executing the sar -r 1 5 command. The following displays:
SCO_SV sco2 3.2v5.0.5 i80386 07/15/2002
15:03:24 freemem freeswp availrmem availsmem (-r)

15:03:25 23683 390000 28329 71244
15:03:26 23683 390000 28329 71244
15:03:27 23683 390000 28329 71244
15:03:28 23683 390000 28329 71244
2-13
15:03:29 23683 390000 28329 71244
Average 23683 390000 28329 71244

3) Display stream resources.
From the system resource submenu, select 3 to display the stream resources in the system. The
following displays:
streams allocation:
config alloc free total max fail
stream 4096 134 3962 10692 135 0
queues 566 271 295 21387 273 0
mblks 2319 445 1874 761868 2149 1
buffer headers 2746 1279 1467 52307 2654 0
class 1, 64 bytes 192 9 183 240804 172 0
class 2, 128 bytes 192 0 192 234865 168 0
class 3, 256 bytes 304 9 295 96179 292 0
class 4, 512 bytes 32 0 32 26368 32 0
class 5, 1024 bytes 32 0 32 2734 29 0
class 6, 2048 bytes 274 182 92 6460 273 0
class 7, 4096 bytes 171 170 1 185 171 0
class 8, 8192 bytes 5 0 5 70 5 0
class 9, 16384 bytes 2 0 2 3 2 0
class 10, 32768 bytes 0 0 0 0 0 0
class 11, 65536 bytes 0 0 0 0 0 0
class 12, 131072 bytes 0 0 0 0 0 0
class 13, 262144 bytes 0 0 0 0 0 0
class 14, 524288 bytes 0 0 0 0 0 0
total configured streams memory: 8000.00KB
streams memory in use: 1103.09KB
maximum streams memory used: 1569.64KB
From the system resource submenu, selection option 0 to return to the main menu.
Displaying router status
On the main interface, select option 0 and the system prompts you for the router IP address. After you
enter the router IP address, the router status submenu displays:
******************************
******************************
Display router status - 10.110.96.44
1 - Display brief tty information.
2 - Display detailed tty information.
3 - Display brief tty-server information.
4 - Display detailed tty-server information.
2-14
Enter:
1) Display brief tty information.
From the router status submenu, select option 1 to display the brief information of TTYs on the
corresponding router. The following displays:
INTERFACE TTY_ID VTY_ID APP_ID TTY_STATE FLOW_C BUF_SIZE RATE
Async6 6 0 6 Ok Stop 4096 0%
Async7 7 0 1 Ok Stop 4096 0%
Async7 7 1 3 Ok Stop 4096 0%
stdin: END
2) Display detailed tty information.
From the router status submenu, select option 2 to display detailed information of TTYs on the
corresponding router. Following is part of the screen display:
Tty6 Detail Statistic
Interface Used : Async6
Current State : Ok
Flow Control : Stop
Current VTY : 0
Current APP : 6
TTY Recv : 2219 Bytes
TTY Send : 2336030 Bytes
Last Recv Time : 21:59:11
Last Send Time : 21:59:11
---------------------
Current VTY Recv : 2219 Bytes
Current VTY Send : 2336030 Bytes
Current APP Recv : 2327134 Bytes
Current APP Send : 2490 Bytes
3) Display brief tty-server information.
From the router status submenu, select option 3 to display the APP summary on the corresponding
router. The following displays:
APP_ID HOST_IP PORT STATE APP_TYPE APP_NAME
1 10.110.96.53 9998 Kept Special sco1
2 10.110.96.53 9997 Kept Normal sco2
3 10.110.96.53 9900 Kept Special sco3
6 10.110.96.53 9998 Linked Special sco4
4) Display detailed tty-server information.
From the router status submenu, select option 4 to display detailed APP information on the
corresponding router. Following is part of the screen display:
App1 Detail Statistic
Server IP Address : 10.110.96.53
Server Port : 9998
Source IP Address : 0.0.0.0
Local Port : 0
Server State : Kept
Server Mode : Special
Socket RecvBuf Size : 2048 Bytes
2-15
Socket SendBufSize : 1024 Bytes
-----------------------
Socket Recv : 27371 Bytes
Socket Send : 1217 Bytes
Last Recv Time : 04:42:15
Last Send Time : 04:42:15
From the router status submenu, selection option 0 to return to the main menu.
Displaying statistics
On the main interface, select option 5 to display the following:

Terminals in use: ttyp55
Enter terminal name:
Enter a terminal name to display all the statistics about the terminal. The following displays:
Process ID. Parent process No. tty device name Router IP Port No. Terminal No.
Debugging level
12676 12674 ttyp55 10.110.96.44 1219 6 0
Statistics:
Total number of packets read from socket: 3
Total number of bytes read from socket: 4
Number of bytes last read from socket: 1
Time when socket was last read?2002-07-15 13:59:43
Total number of packets written to socket: 2
Total number of bytes written to socket: 116
Number of bytes last written to socket: 58
Time when socket was last written to? 2002-07-15 13:59:44
Total number of packets read from pty: 2
Total number of bytes read from pty: 116
Number of bytes last read from pty: 58
Time when pty was last read?2002-07-15 13:59:44
Total number of packets written to pty: 2
Total number of bytes written to pty: 2
Number of bytes last written to pty: 1
Time when pty was last written to? 2002-07-15 13:59:43
Editing ttyd configuration file
On the main interface, select option 6 and the system prompts you for the configuration file name. If the
entered configuration file exists, the file is opened. If the a new configuration file name is entered, a
configuration file template is opened to facilitate the configuration file editing.
Installing and Configuring SCO UnixWare Server

Using the floppy disk
Refer to section Using a floppy disk.
2-16
Using FTP
Refer to section Using FTP.
When the number of pseudo terminals on the SCO UnixWare server is not enough, you can use the
scoadmin configuration program to add pseudo terminals as follows:
1) Launch scoadmin.
2) Select [Networking].
3) Select [Network Configuration Manager].
4) Select [TCP/IP].
5) Select [Protocol].
6) Select [Modify protocol configuration...].
7) Select [Advanced options].
8) Select [Pseudo ttys]. The default value is 32. Change the value to 256.
9) Compile the kernel.
# /etc/conf/bin/idbuild -B
10) Reboot the FEP.
# init 6
Then, the system can support up to 256 pseudo terminals.

You can also increase the number of pseudo terminals by installing programs acp and update as
follows:
11) Change the value of kernel parameter NUMSCOPT to 256.
# /etc/conf/bin/idtune NUMSCOPT 256
12) Install the acp package, which is in the first disk for SCO UnixWare. Select a terminal number of
256 during installation.
# pkgadd -d cdrom1 acp
13) Install the update package, which is in the second disk for SCO UnixWare.
# pkgadd -d cdrom1 update711
After installation, the system rebuilds the kernel and reboots automatically.
By default, each SCO UnixWare process can open up to 64 files. If a Unix server is to be connected with
a large number of terminals (usually more than 50), change the value to 400. To do so, use the following
commands:
# idtune SFNOLIM 400
# idbuild B
By default, each SCO UnixWare user can open up to 80 processes. If a Unix server is to be connected
with many terminals (usually more than 50), change the value to 500. To do so, use the following
commands:
# idtune MAXUP 500
# idtune NPROC 1000
# idbuild B
2-17
Modifying System Configuration File ttydefs
Locate the line starting with 9600: in file /etc/ttydefs. If the echoctl option is present, set it to echoctl.
If Chinese cannot be used normally, add the istrip option to the line. For example:
9600: 9600 sane imaxbel iexten -echoctl echoke -istrip -tabs ::: 4800
To run ttyd on the SCO UnixWare system, you do not need to configure pseudo terminal related
parameters in file /etc/inittab.
Editing ttyd Configuration File
Refer to section Editing the ttyd Configuration File.
The terminal access router is usually connected to the Unix server through WANs and therefore located
on an IP segment different from that of the Unix server, in which case you must configure a route on the
Unix server.
The following example shows how to do so:
# route add netmask 255.255.255.0 net 10.110.96.0 63.1.1.250
and the nexthop IP address of 63.1.1.250.
Running ttyd
Refer to section Running ttyd.
Terminating ttyd
Refer to section Terminating ttyd.
Refer to section Enabling ttyd autorun at system startup.
Refer to section Installing and Using ttyd Administration Program ttyadm.
Installing and Configuring SUN OS Server

2-18
In the SUN OS system, a floppy disk is mounted automatically and no mount operation is needed.
Using FTP
If there are not enough pseudo terminals on the SUN OS system, you can add new pseudo terminals by
modifying the system file as follows:
1) Open the system file.
# vi /etc/system
Add set npty=176 into the file:

3) Create the file "reconfigure".
# touch /reconfigure
4) Reboot the system.
# reboot
The number of supported pseudo terminals is now 176.
By default, each SUN OS process can open up to 64 files. If a Unix server is to be connected with a
number of terminals (usually more than 50), change the value to 400. To do so, edit file /etc/system to
add the following line:
set rlim_fd_cur = 400
After modification, you must reboot the server to bring your configuration into effect. You do not need to
change other system kernel parameters.
Follow these steps to modify the system configuration file inittab:

1) Check whether a pseudo terminal has been configured in the inittab configuration file.
Take the device ttyp50 as an example. Edit the file /etc/inittab and check whether this file contains the
following line:
T1:234:respawn:/etc/getty ttyp50
If the line is absent, add it. In the sample line, T1 is the identifier of the line. Each line in the file inittab
must have a unique identifier consisting of no more than two characters. In system configuration file
inittab, the third column of a line is "respawn" for an active terminal and off for a dumb terminal.
2) Bring the configuration into effect after the addition.
# init q
2-19
Unix server.
# route add net 10.110.96.0 63.1.1.250
Running and Terminating ttyd on the Unix Server
Running ttyd
Terminating ttyd
Refer to section Enabling ttyd autorun at system startup.
Installing and Configuring IBM AIX Server

Using FTP
When the number of pseudo terminals on the IBM AIX server is not enough, you can use the smit
configuration program to add pseudo terminals as follows:
1) Launch smit.
# smit
2) Select [Devices].
3) Select [PTY].
4) Select [Maximum number of BSD Pseudo-Terminals] and set it to 256. Now, the number of
supported pseudo terminals is 256.
2-20
Adding pseudo terminals on the IBM AIX server does not require reboot.
By default, each IBM AIX user can open up to 128 processes. If a Unix server is to be connected with
many terminals (usually more than 50), change the value to 500. To do so, use the following commands:
# smit
After entering the menu interface, select the [system management] to open the submenu.
From the submenu, select [change/show characteristics of operating system] and change the value of
[maximum number processes allowed per user] to 500.
1) Check whether the pseudo terminal has been configured in the inittab configuration file.
Take the device ttyA6 as an example. Edit the file /etc/inittab and check whether this file contains the
following line:
ttyA6:234:respawn:/usr/sbin/getty /dev/ttyA6
If the line is absent, add it. In the sample line, ttyA6 is the identifier of the line. Each line in file inittab
must have a unique identifier consisting of no more than four characters. In system configuration file
inittab, the third column of a line is "respawn" for an active terminal and "off" for a dumb terminal.
# init q
Unix server.
# route add net 10.110.96.0 63.1.1.250
Running and Terminating ttyd on the Unix Server
Running ttyd
Refer to section Running and Terminating ttyd on Unix Server.
2-21
Terminating ttyd
Add the command for starting ttyd at the end of the file /etc/inittab.
# vi /etc/inittab
Append the following line

ttyd:23:wait:/etc/ttyd /etc/ttyd.conf
Installing and Configuring HP-UX Server

Using FTP
Adding VTYs
If there are not enough pseudo terminals on the HP-UX server, you can add new pseudo terminals by
modifying the system file as follows:
1) Launch sam.
# sam
2) Select [Kernel Configuration].
3) Select [Configurable Parameters].
Change the value of the npty parameter to 256.
4) Compile the kernel.
5) Reboot the device.
Now, the number of pseudo terminals is 256 in the directories /dev/pty and /dev/ptym.
Link the added devices to /dev as follows:
# ln /dev/pty/ttyy0 /dev/ttyy0
# ln /dev/ptym/ptyy0 /dev/ptyy0
Modifying the maximum number of processes supported by the system
By default, the HP-UX server supports up to 664 processes. If a Unix server is to be connected with
many terminals (usually more than 50), change the value to 2000. To do so, use the following
commands:
# sam
2-22
After entering the menu interface, select [kernel configuration] to enter the submenu, and then select
[configurable parameters] and change the value of [nproc] to 2000.
Take the device ttypa as an example. Edit the file /etc/inittab and check whether this file contains the
following line:
pa:3456:respawn:/usr/sbin/getty ttypa 9600
If the line is absent, add it. In the sample line, pa is the identifier of the line. Each line in file inittab must
have a unique identifier consisting of no more than four characters. In system configuration file inittab,
the third column of a line is "respawn" for an active terminal and "off" for a dumb terminal.
# init q
Editing ttyd Configuration File
Unix server.
# route add net 10.110.96.0 netmask 255.255.255.0 63.1.1.250
Running ttyd
Refer to section Running and Terminating ttyd on Unix Server.
Terminating ttyd
1) Create the file /sbin/init.d/ttyd.

# vi /sbin/init.d/ttyd
2) Add the following contents:
case "$1" in
'start_msg')
echo "Start ttyd"
;;
'start')
# To launch multiple configuration files, list each of them in a line.
2-23
/etc/ttyd /etc/ttyd.conf
;;
'stop_msg')
echo "Stop ttyd"
;;
'stop')
pid=`ps -ef | grep ttyd | awk '{if ($3 == 1) print $0}' | awk '{print $2}'`
if [ ! "$pid" = "" ]
then
kill $pid
fi
;;
esac
4) Link the file to the startup directory.
# chmod u+x /sbin/init.d/ttyd
# ln -s /sbin/init.d/ttyd /sbin/rc2.d/S99ttyd
# ln -s /sbin/init.d/ttyd /sbin/rc2.d/K00ttyd
Installing and Configuring Red Hat Linux Server

Using FTP
Setting the maximum number of open files
By default, Red Hat Linux supports up to 1,024 open files. To change the maximum number of open files
supported, use the following command:
# ulimit n 4096
Changing the maximum number of user processes
By default, the Red Hat Linux server supports up to 4,096 user processes. Normally, you do not need to
change this value. To change it, use the following command:
# ulimit -u 4096
Displaying system parameters
Display system parameters by using the following command:

# ulimit a
2-24
The following contents are displayed:
[root@redhat root]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
Take the device ttypa as an example. Edit the file /etc/inittab and check whether this file contains the
following line:
pa:3456:respawn:/usr/sbin/getty ttypa 9600
If the line is absent, add it. In the sample line, pa is the identifier of the line. Each line in file inittab must
have a unique identifier consisting of no more than four characters. In system configuration file inittab,
the third column of a line is "respawn" for an active terminal and "off" for a dumb terminal.
The available pseudo terminals include ttyxy, where the value of "x" ranges from a to e and p to z and
that of "y" ranges from hexadecimal 0 to f. Examples are ttyp6, ttypa, ttyz1, and ttyz9.
# init q
3) Start ttyd before the system starts the file /etc/inittab.
To start ttyd before the system starts the file /etc/inittab, you must edit the file /etc/rc.d/rc.sysinit;
otherwise, the system will prompt a message similar to "" INIT:" Id "v0" respawning too fast, disabled for
5 minutes" and it may take a while before the login window appears. No such problems will occur if all
these devices present in the file inittab have been opened by ttyd. Append the following contents to line
30 in the file /etc/rc.d/rc.sysinit:

# Start the graphical boot, if necessary
if [ "$BOOTUP" = "graphical" ]; then
if [ -x /usr/bin/rhgb ]; then
/usr/bin/rhgb
else
export BOOTUP=color
fi
fi
#start ttyd
/root/ttydp/ttyd /root/ttydp/tty9000.conf
/root/ttydp/ttyd /root/ttydp/tty9001.conf
2-25
sleep 10
last=0
for i in `LC_ALL=C grep '^[0-9]*.*respawn:/sbin/mingetty' /etc/inittab | sed 's/
^.* tty$[0-9][0-9]*$.*/\1/g'`; do

Unix server.
# route add net 10.110.96.0 netmask 255.255.255.0 63.1.1.250
and the gateway (a router) IP address of 63.1.1.250.
Running ttyd
Terminating ttyd
2-26
3 Terminal Access Troubleshooting
When troubleshooting terminal access, go to these sections for information you are interested in:
z Prompts on Terminals
z Terminal Access Troubleshooting
Prompts on Terminals
No. Prompt Description
(TTY tty-number: vty-number
Creating a socket failed because, for example, no
1 starting connect to server
WAN IP address is configured on the router.
fail!)
The router failed to establish a TCP connection to the
2 Unix server because, for example, the Unix server is
fail to connect server-name!)
turned on but ttyd is not running.
The corresponding entries in the ttyd configuration file
of the Unix server may be wrong, or the ttyd listening
3 authentication failed or
port on the Unix server and the application port on the
server-name no response)
router are different.
The TCP connection established between the Unix
server and the router is down. This may occur when
4 peer socket close, fail to
you close ttyd on the Unix server or turn off the Unix
connect server-name!)
server.
Normally, the router should be able to establish a
TCP connection to the Unix server quickly. If the
system prompts that the connection is still not
5 connecting with
established after a long time, the Unix server may be
server-name...)
off or some other problems may have occurred. Press
a key on the terminal to initiate a new connection.
A TCP connection is established between the router
6 success to connect with
and the Unix server.
server-name)
(TTY tty-number: vty-number The status of the socket on the router changes when
7 link error with server-name the router is establishing a TCP connection or
while sending) sending data to the Unix server.
The router just tore down a TCP connection and is
(TTY tty-number:%d break
reestablishing another TCP connection to the Unix
9 and reconnect with
server. This message appears when a terminal user
server-name)
presses the terminal reset hotkey.
When terminal access periods are configured in the
(Out of time range, access ttyd configuration file on the Unix server, this
10
forbidden!) message appears if a terminal tries to access the
Unix server during forbidden periods.
Authentication of a terminal failed. The corresponding
(authentication failed, fail to
11 pseudo terminal on the Unix server cannot be
open pty device!)
opened.
3-1
No. Prompt Description
Authentication of a terminal failed. The TCP
(authentication failed, too
12 connection number established by the ttyd program
many tcp links!)
on the Unix server has reached the upper limit.
The source IP address of the TCP connection
(authentication failed, invalid corresponding to the terminal is not consistent with
13
IP address!) the IP address configured in the ttyd configuration file
on the Unix server.
Authentication of a terminal failed. The terminal
(authentication failed, invalid
14 number is not identical to that configured in the ttyd
TTY No.!)
configuration file on the Unix server.
(authentication failed, Authentication of a terminal failed. An unknown error
15
unknown error!) occurred.
Terminal Access Troubleshooting

Check if there is any prompt displayed on the terminal
1) If there is a prompt displayed on the terminal

Refer to sections Prompts on Terminals or Check whether the router and Unix server can ping each
other for detailed information.
2) If there is no prompt displayed on the terminal
Refer to section Check whether the cable connecting the terminal to the router is OK.
3) Verify terminal connectivity by using the terminal connectivity test hotkey
In router terminal access, a command is provided for testing terminal connectivity. This command can
be used to test the physical connectivity between a terminal and a router and the TCP connectivity
between the terminal and the Unix server. Once the terminal connectivity test hotkey is configured in
interface view, the terminal connectivity test function is enabled.
Now, you can enter the test hotkey on the terminal. If the physical connectivity between the terminal and
router is correct, the terminal screen will display "Terminal to Router test OK!" if you have set the
language type to English on the Unix server. This means the connectivity between the terminal and the
asynchronous serial interface of the router is correct and they can exchange data with each other
normally. Refer to section Check whether the router and Unix server can ping each other. If the TCP
connection between the terminal and the Unix server is correct, the terminal screen displays "Terminal
to Unix test OK!". This means a TCP connection has been established between the application used by
the terminal and the ttyd program on the UNIX server, and the terminal can communicate with the
server normally. Refer to section For an active terminal, verify the configuration of system file inittab.
Check whether the cable connecting the terminal to the router is OK
1) Pin assignment of the asynchronous serial interface and terminal access converter
If the terminal displays nothing on its screen, verify that the cable connection is correct. Different
models of terminals have different pin assignments with their primary serial interfaces, so a certain type
of converter may be required.
In terminal access, 8ASE and 16ASE modules and their cables are used the most frequently. The
connection cables for the 8ASE/16ASE modules have 8/16 asynchronous serial interfaces, namely
8AS/16AS cables, which fall into three types: 8AS/16AS cable (DB-25/DB-9), 8AS/16AS cable (RJ-45
3-2
for telecom), and 8AS/16AS cable (RJ-45 for banks). Telecom means that the 8AS/16AS (RJ-45)
cables, which are blue, are for telecom carriers. Bank means that the 8AS/16AS (RJ-45) cables which
are white and labeled with Dumb Terminal are used for terminal access in banks.
The following table describes the pins of 8AS/16AS cables.
Serial
RJ-45 (for Signal
interfa DB-25 DB-9 Signal Signal description
telecom/banks) direction
ce
5 8 8/7 CTS Clear to send
6 6 7/3 DSR Data set ready
3 2 6/5 RxD Receive data
Asynch
ronous 7 5 5/4 GND - Logical ground
serial
interfac 8 1 4/1 DCD Data carrier detect
e
2 3 3/6 TxD Transmit data
20 4 2/2 DTR Data terminal ready
4 7 1/8 RTS Request to send
Terminal access converters are exclusively used for 8AS cables (RJ-45 for banks) and 16AS cables
(RJ-45 for banks) to connect to terminals. One end of the cable is an RJ-45 receptacle for connecting to
a standard network cable, and the other end is a DB-25 receptacle for connecting to a terminal. The
following table describes the pins of the terminal access converter.
RJ-45 (female) DB-25 (female) Signal

1 8 DCD
2 6 DSR
3 20 DTR
4 7 GND
5 2 TxD
6 3 RxD
7 4 RTS
8 5 CTS
The common terminal access connection in banking systems is shown in the following figure.
3-3
Figure 3-1 Terminal access joint detail
For detailed cable descriptions, refer to the related manuals.

2) 3-wire, 5-wire, and 8-wire asynchronous serial interface cables
When a 3-wire asynchronous serial interface cable is used, since dsr/dtr and flow control signal lines
are absent, you must use the undo detect dsr-dtr and flow-control none (or flow-control software
inbound) commands on the asynchronous serial interface, to not detect the dsr/dtr signals so that the
asynchronous interface automatically enters the up state, and to not detect hardware flow control
signals by adopting software flow control or no flow control.
When a 5-wire asynchronous serial interface cable is used, since flow control signal lines are absent,
you must use the flow-control none or flow-control software inbound command on the
asynchronous interface, to not detect hardware flow control signals by adopting software flow control or
no flow control instead.
When a 8-wire asynchronous serial interface cable is used, all the required signal lines are available;
therefore, you do not need to configure the above-mentioned commands on the asynchronous
interface.
Check whether the router and Unix server can ping each other
1) If yes
The WAN line between the router and the Unix server functions well, and the criterion is satisfied for the
router to establish a TCP connection to the server. Refer to section Check whether the main ttyd
process and its child processes are present.
2) If not
Check the configuration of the WAN interface of the router, the WAN line provided by the ISP, and the
router related parameters on the router and server.
Check whether the main ttyd process and its child processes are present
Use the process management function provided by the ttyd administration program or the ps ef | grep
ttyd command to check whether the main ttyd process and its child processes are present.
1) The ttyd main process does not exist.
The ttyd program is not running. Run the program as follows:
# /etc/ttyd
If you do not specify any parameters for the command, the default configuration file /etc/ttyd.conf is
used. To specify another configuration file, you must enter a file name in the following format:
3-4
# /etc/ttyd /etc/ttyd9020.conf
2) The main ttyd process exits but none of its child processes does.
The ttyd program has been started, but no TCP connection has been established between the router
and the Unix server. First, verify that the connection modes set on the router and the FEP are the same,
for example, both in the one-to-one mode. Then, check whether it is because the terminal
authentication failed or opening the pseudo terminal failed. Refer to the section Verify the configuration
of the router and the ttyd configuration of the server are correct and consistent or Prompts on Terminals.
3) The main ttyd process and its child processes exist.
The ttyd program has been started, and a TCP connection has been established between the router
and the Unix server. Refer to section Check whether the router has established a TCP connection with
the Unix server.
Verify the configuration of the router and the ttyd configuration of the server are correct and
consistent
z Verify router configuration is correct.

z Verify the configuration file ttyd.conf on the Unix server is correct.
z Verify either the one-to-one or many-to-one mode is configured on both sides.
z Verify the port numbers configured on both sides are consistent.
z Verify the IP address and terminal number configured in ttyd.conf and those on the router are
consistent.
z If source IP address binding is configured on the router, verify the source IP address can be pinged
through from the Unix server
Check whether the router has established a TCP connection with the Unix server
1) Verify TCP connectivity using the terminal connectivity test hotkey

In terminal access, a command is provided for testing terminal connectivity. This command can be used
to verify the TCP connectivity between a terminal and a Unix server. Once the terminal connectivity test
hotkey is configured on the interface, the terminal connectivity test function is enabled.
Now, you can press the test hotkey on the terminal. If the TCP connection between the terminal and the
Unix server is correct, the terminal screen displays " Terminal to Unix test OK!". This means a TCP
connection has been established between the application used by the terminal and the ttyd program on
the UNIX server, and the terminal can communicate with the server normally. Refer to section For an
active terminal, verify the configuration of system file inittab for detailed information.
If the terminal does not display Terminal to Unix test OK!, no TCP connection has been established
between the application used by the terminal and the ttyd program on the Unix server, or the
corresponding pseudo terminal on the Unix server is not operating normally. Refer to section View the
debugging information of the router and ttyd program of the server for detailed information.
2) Verify terminal TCP connectivity with the echo command
First, confirm the pseudo terminal ttypxx on the Unix server corresponding to the terminal by using the
configuration file ttyd.conf. Then, execute the following command on the Unix server:
# echo 123456789 > /dev/ttypxx
This command sends the string 123456789 to the terminal ttypxx (xx indicates the terminal index).
If the string appears on the terminal, a TCP connection has been established between the application
used by the terminal and the ttyd program on the Unix server, and the terminal can communicate with
3-5
the server normally. Refer to section For an active terminal, verify the configuration of system file inittab
for detailed information.
If the string does not appear on the terminal, no TCP connection has been established between the
application used by the terminal and the ttyd program on the Unix server, or the corresponding pseudo
terminal on the Unix server is not operating normally. Refer to the section View the debugging
information of the router and ttyd program of the server for detailed information.
For an active terminal, verify the configuration of system file inittab
An active terminal is a pseudo terminal that pushes the login interface.

1) The inittab system file configuration is not correct.
First, find in the configuration file ttyd.conf on the Unix server the pseudo terminal that corresponds to
the terminal, ttyp50 for example. Then, edit the file /etc/inittab and check whether the file contains the
following line:
If the line is absent, add it.
Execute the init q command to bring the configuration into effect.
# init q
You can also use the enable command to configure a pseudo terminal as an active terminal, or use the
disable command to configure a pseudo terminal as a dumb terminal.
# enable ttyp50
2) The inittab system file configuration is correct.
X. Refer to the section View the debugging information of the router and ttyd program of the server.
For a dumb terminal, check whether the pseudo terminal is activated
A dumb terminal is a pseudo terminal that does not push the login interface.
Check whether the banking service process has activated the pseudo terminal. If not, activate it. If yes,
refer to the section View the debugging information of the router and ttyd program of the server.
View the debugging information of the router and ttyd program of the server
A debugging file is created for each main ttyd process and child process. By default, the destination
directory of the ttyd debugging file(s) is /var/ttydlist. You can change this directory in the configuration
file ttyd.conf. The debugging file of the main ttyd process is named in the format of ttydxxxx.log, where
xxxx is the number of the listening port of the main process. The debugging file of a child process is
named in the format of ttypxx.log, where ttypxx is the name of the ttyp device for the child process.
The following analyses the common ttyd debugging information and provides some solutions.
1) authentication 1.1.92.52 failed.
Cause: The ttyd configuration file contains no configuration for the router. Solution: Configure the IP
address of the router in the ttyd configuration file, and then press <Enter> on the terminal.
2) Fail: Too many tcp links
Cause: Too many TCP connections have been established on the Unix server so that new TCP
connection requests cannot be accepted.
3) Fail: authenticate <10.110.96.44 6> fail, no such termNo in config file
Cause: The TTY number is not configured in the configuration file.
3-6
4) Fail: authenticate <10.110.96.44 6> fail, no such ip in config file
Cause: The IP address of the router, 10.110.96.44, is not configured in the configuration file.
5) Fail: connection closed by peer
Cause: The TCP connection has been closed by the router.
6) Fail: the swap is not enough to store the data , so some data is discarded
Cause: Data from the router is not written into the PTY device (pseudo terminal), making the buffer full
and subsequent data discarded. Typically, this is because the PTY device is not operating normally.
7) Fail:fail to write data into screen
Cause: Data on the screen cannot be saved.
8) Fail:fail to recv data from socket
Cause: Failed to read user data from the socket.
9) Fail:fail to write data into pty
Cause: Failed to write data to the PTY device.
10) Fail:fail to read pty
Cause: Failed to read data from the PTY device.
11) Fail:fail to write data into socket
Cause: Failed to write data to the socket.
12) Fail:child process exit for out of time range
Cause: The user was accessing the Unix server out of the defined periods.
13) Fail:Failed in opening pty5, out of devices
Cause: Failed to find the device.
14) Fail:Failed in opening pty5, errno=5
Cause: Failed to open device pty5. The value of the errno parameter tells the cause.
15) Fail:It failed in binding server,so it exited
Cause: Another process is using the listening port number specified in the ttyd configuration file.
16) Fail:It failed in opening ttyd config file
Cause: Failed to open the file with the specified path.
17) Fail:Too many main process, so can't add the new one
Cause: Too many main ttyd processes are started up on the Unix server.
18) Fail:It failed in creating or get device xxx,so exit
Cause: Failed to create a device used by the ttyd process. This is usually resulted from Unix system
resource problems.
If you cannot locate the problem, save the debugging information of both the router and the Unix server
and send it to a customer service engineer to locate it.
Change the corresponding pseudo terminal on the Unix server
If the above-mentioned procedure cannot solve the problem, try to use another pseudo terminal on the
Unix server corresponding to the terminal by following these steps:
1) If the pseudo terminal is an active terminal, sign off; if it is a dumb terminal, terminate it from the
banking service process and delete its configuration in the configuration file of the banking service.
3-7
2) Modify configuration file ttyd.conf on the Unix server to change the original pseudo terminal to a
new pseudo terminal.
If the new pseudo terminal is an active terminal, make sure that you have enabled it. If it is a dumb
terminal, configure the terminal in the configuration file of the banking service.
3) Use the process management function of the ttyd administration program or the kill command to
kill the ttyd child process corresponding to the original terminal, or run the ttyd administration
program and use the menu for refreshing configuration file to refresh ttyd program configuration.
If the new pseudo terminal is a dumb terminal, activate this terminal in the banking service process.
3-8
4 Terminal Access FAQ
If there are insufficient stream resources on the Unix server, modify kernel parameters.
If an FEP is connected to too many terminals, you need to modify the Unix kernel of the FEP to increase
stream resources to avoid insufficient stream resources in operation.
You can view system resources utilization by using the ttyd administration program or the following
command:
# netstat -m
streams allocation:
config alloc free total max fail
stream 4096 134 3962 10692 135 0
queues 566 271 295 21387 273 0
mblks 2319 445 1874 761868 2149 1
buffer headers 2746 1279 1467 52307 2654 0
class 1, 64 bytes 192 9 183 240804 172 0
class 2, 128 bytes 192 0 192 234865 168 0
class 3, 256 bytes 304 9 295 96179 292 0
class 4, 512 bytes 32 0 32 26368 32 0
class 5, 1024 bytes 32 0 32 2734 29 0
class 6, 2048 bytes 274 182 92 6460 273 0
class 7, 4096 bytes 171 170 1 185 171 0
class 8, 8192 bytes 5 0 5 70 5 0
class 9, 16384 bytes 2 0 2 3 2 0
class 10, 32768 bytes 0 0 0 0 0 0
class 11, 65536 bytes 0 0 0 0 0 0
class 12, 131072 bytes 0 0 0 0 0 0
class 13, 262144 bytes 0 0 0 0 0 0
class 14, 524288 bytes 0 0 0 0 0 0
total configured streams memory: 8000.00KB
streams memory in use: 1103.09KB
maximum streams memory used: 1569.64KB
A value of 1 for the fail column means the system stream resources are insufficient and you need to
increase stream resources by modifying the Unix server kernel.
You can follow these steps to modify system stream resources (taking SCO OpenServer Unix 5.0x as
an example):
1) Log in to the Unix server as a superuser.
2) Enter scoadmin to run SCO OpenServer Unix administration program.
3) Select [Hardware/Kernel Manager] from the main interface to enter the level 2 interface.
4) Select [Tune Parameters] to enter the level 3 interface.
5) Under the [Configuration tunables] title, Select [12 Streams] to enter the level 4 interface.
6) Set the [NSTRPAGES] field to 2000 (the default is 500).
7) Exit to the level 2 interface and select [Relink Kernel] to recompile the kernel.
4-1
8) Exit scoadmin and reboot the Unix server.
After reboot, the change takes effect. You can use the netstat -m command to view current system
stream resources. The last but three line of command output will show that the total configured streams
memory is changed from 2,048 KB to 8,000 KB.
Some banking services cannot use pseudo terminal names containing more than six
characters
By default, the name of a pseudo terminal consists of six characters, for example, ttyp50. But some
banking services do not support pseudo terminal names containing six or more characters. Therefore,
you must modify the names to 5-character long names. The following example shows the steps:
1) Kill all the current main and child ttyd processes.
2) Modify pseudo terminal names in configuration file ttyd.conf, for example:
Original: ttyp30 10.110.96.11 0
Modified: ttya0 10.110.96.11 0
3) Modify 6-character pseudo terminal names to 5-character ones with the following commands:
# mv /dev/ttyp30 /dev/ttya0
# mv /dev/ptyp30 /dev/ptya0
4) Modify attributes of the pseudo terminals with the following commands:
# chmod 666 /dev/ttya0
# chmod 666 /dev/ptya0
5) Synchronize with the following command:
# sync
6) For active terminals, add corresponding pseudo terminal configuration in system file inittab by
using the following command:
a0:234:respawn:/etc/getty ttya0 m
7) Add configuration entry for pseudo terminal ttya0 in the banking service configuration file.
8) Restart the ttyd program.
Thus, 6-character VTY names are changed to 5-character ones.
A terminal does not display the login interface
A terminal does not display the login interface in the following cases:
z Sometimes, when you kill the main ttyd process, some banking service process may remain. In this
case, when you restart ttyd, the terminal cannot be opened.
z The terminal has baud rates different from those of the asynchronous interface.
z The corresponding device is not configured in file inittab.
z The router and the Unix server use different application modes, for example, the Unix server may
use the many-to-one mode and the router may use the one-to-one mode. Note that the router only
supports the one-to-one mode currently.
Solution:
z For the first case, you may check the UNIX server log for a message similar to open ptyp10 failed:
I/O error. In such a case, execute the following command on the Unix server:
# ps -ef | grep ttyp10
Then, kill all the displayed processes associated with ttyp10.
z For the second case, you must reconfigure the baud rates to be consistent.
z For the third case, you must configure the corresponding device in file inittab.
4-2
z For the fourth case, you must configure the router and the Unix server to use the same application
mode.
Terminal echoing speed is low
Use the ttyd administration program to check the system resource occupation rate of the Unix server. If
the rate is relatively high, locate which service process is abnormal and, if necessary, kill the process.
If the rate is not high, open the ttyd configuration file to examine whether the sendsize and readsize
options are properly configured. For low speed WAN links (at 9,600 bps for example), the two options
must be modified accordingly.
In addition, for higher terminal echoing speed, one-to-one mode is recommended.
The terminal displays abnormally for some banking services
Some banking services require certain types of terminal emulation. Terminal emulation type is
configured for each pseudo terminal in system file /etc/ttytype on the Unix server. When upgrading
network devices, if you modify pseudo terminal numbers, you must edit the system file to add terminal
emulation types for the new pseudo terminals. Taking ttyp50 as an example, you must add the following
line to the file /etc/ttytype:
vt100 ttyp50
If a pseudo terminal is configured with no terminal emulation type in file /etc/ttytype on the Unix server,
the pseudo terminal uses the default emulation type unknown, and the prompt message at login TERM
= (unknown) displays.
Some pseudo terminals cannot be opened
After ttyd is started, if the log does not prompt that a terminal is open, the terminal is not open. Check the
configuration file to see whether the terminal is given a valid name.
If other configurations are all correct but the log shows that some pseudo terminals cannot be opened,
check whether the terminals are under directory /dev. If not, try to use another existent pseudo terminal
or create the pseudo terminal. If yes, check whether a process is using the pseudo terminal.
The status of a terminal is not OK but UP on the router
If a terminal is correctly connected to the router, its status should be OK when you use the display rta
command. If its status is UP, terminal access is not started, and you must use the rta server enable
command in system view on the router to enable terminal access.
The TCP connection is intermittently up/establishing and down
z Verify that the same application mode (many-to-one or one-to-one) is configured on both the router
and the Unix server.
z Verify that the router and Unix server are configured consistently and that the configurations
comply with the parameter configuration conventions. Most mistakes result from inconsistent
configurations.
z Check whether source address binding is configured. With source address binding configured, the
router IP address configured on the Unix server must be the bound IP address.
z Verify that correct routes are configured on both the router and Unix server.
4-3
Illegible characters are displayed when a terminal handles a service
Check whether test, redrawing, switching hotkeys and the like are configured. Hotkey values may
conflict with data. You can change the hotkey values.
Check whether the application mode is many-to-one, which may cause data for terminals to fall into
confusion. Upgrade to a router version supporting one-to-one mode and switch to one-to-one
application mode.
Pressing menu switching hotkey cannot bring up the menu
When a terminal is listing directories or outputting data, pressing the menu switching hotkey cannot
bring up the menu. Perform VTY switching when the terminal is idle.
With terminal access enabled, a powered terminal is still down
z Check whether the asynchronous interface is configured with the undo modem command.
z Verify that the terminal cable is OK.
z Verify that the converter connecting the terminal and the router is wired correctly.
Only the first configuration file has a corresponding process when multiple configuration
files are configured
Check whether the listening ports configured in the configuration files are in conflict.
The terminal cannot display the login interface after configuration and no error message is
logged on the Unix server
Check the configuration file to see whether the same application mode is configured on the router and
the Unix server. This problem occurs if the Unix server uses the many-to-one mode and the router uses
one-to-one mode.
The terminal connected to a credit card (IC card) swipe reader does not work
Check the hardware versions of the interface modules using the display version command.
First, check the hardware versions of the interface modules. 8AS modules have two hardware versions:
1.x and 2.x. 8AS modules with a hardware version of 1.x do not support card swiping and those with a
hardware version of 2.x do. No such problems happen to any other interface modules.
4-4
Table of Contents
1 sFlow Configuration 1-1

sFlow Overview1-1
Introduction to sFlow 1-1
Operation of sFlow 1-2
Configuring sFlow 1-2
Displaying and Maintaining sFlow1-3
sFlow Configuration Example 1-3
Troubleshooting sFlow Configuration 1-4
The Remote sFlow Collector Cannot Receive sFlow Packets 1-4
i
1 sFlow Configuration
When configuring sFlow, go to these sections for information you are interested in:
z sFlow Overview
z Configuring sFlow
z Displaying and Maintaining sFlow
z sFlow Configuration Example
z Troubleshooting sFlow Configuration
sFlow Overview
Introduction to sFlow
Sampled Flow (sFlow) is a traffic monitoring technology mainly used to collect and analyze traffic
statistics.
The sFlow system involves an sFlow agent embedded in a device and a remote sFlow collector. The
sFlow agent collects traffic statistics and packets from the sFlow enabled ports on the device,
encapsulates the information into sFlow packets, and sends the packets to the sFlow collector. The
sFlow collector analyzes the sFlow packets and displays the results.
sFlow has the following two sampling mechanisms:
z Packet-based sampling: An sFlow enabled port samples one packet out of a configurable number
of packets passing through it.
z Time-based sampling: The sFlow agent samples the statistics of all sFlow enabled ports at a
configurable interval.
As a traffic monitoring technology, sFlow has the following advantages:
z Supporting traffic monitoring on Gigabit and higher-speed networks.
z Providing scalability to allow one sFlow collector to monitor multiple or more sFlow agents.
z Implementing the low-cost sFlow agent.
1-1
Currently, only the sFlow agent function is supported on the device.
Operation of sFlow
sFlow operates as follows:

1) With sFlow enabled, a physical port encapsulates sampled data into packets and sends them to
the sFlow agent.
2) The sFlow agent periodically collects the statistics of all sFlow enabled ports.
3) When the sFlow packet buffer overflows or the one-second timer expires, the sFlow agent sends
sFlow packets to the specified sFlow collector.
Configuring sFlow
The sFlow feature enables the remote sFlow collector to monitor the network and analyze sFlow packet
statistics.
Follow these steps to configure sFlow:

Specify the IP address of the Required

sflow agent ip ip-address
sFlow agent Not configured by default.
Specify the IP address and port sflow collector ip ip-address Required

number of the sFlow collector [ port port-num ] Not specified by default.
Set the counter sampling
interval at which the sFlow Optional
sflow interval interval-time
agent collects the statistics of 20 seconds by default.
sFlow enabled ports
interface-number
Enable sFlow in the inbound or sflow enable { inbound | Required

outbound direction outbound } Not enabled by default.
Optional
Specify the sFlow sampling sflow sampling-mode
mode { determine | random } The default depends on the
device model.
Specify the number of packets Optional

out of which the interface will sflow sampling-rate rate The default depends on the
sample a packet device model.
Optional
Specify the sFlow version sflow version { 4 | 5 } The default depends on the
device model.
1-2
z The sFlow agent and sFlow collector must not have the same IP address.
z Currently, you can specify at most two sFlow collectors on the device.
Displaying and Maintaining sFlow

Display sFlow On a centralized device display sflow
Available in any
configuration
On a distributed device display sflow [ slot slot-id ] view
information
sFlow Configuration Example

z Host A is connected with Server through Device (sFlow agent).

z Enable sFlow on Ethernet 1/1 to monitor traffic on the port.
z Device sends sFlow packets through Ethernet 1/0 to the sFlow collector (Host B), which analyzes
the sFlow packets and displays results.
Network diagram
Figure 1-1 Network diagram for sFlow configuration
Host B
3.3.3.2/16
Collector
Eth1/0
3.3.3.1/16 Eth1/2
2.2.2.1/16
Eth1/1
1.1.1.2/16
Host A Server
1.1.1.1/16
Device 2.2.2.2/16
# Configure the IP address of Ethernet 1/0 on Device as 3.3.3.1/16.

# Specify the IP address of the sFlow agent.

[Device] sflow agent ip 3.3.3.1
# Specify the IP address and port number of the sFlow collector.
1-3
[Device] sflow collector ip 3.3.3.2 port 6343
# Set the sFlow interval to 30 seconds.

[Device] sflow interval 30
# Enable sFlow in both the inbound and outbound directions on Ethernet 1/1.
[Device-Ethernet1/1] sflow enable inbound
[Device-Ethernet1/1] sflow enable outbound
# Specify the packet sampling rate on the interface.

[Device-Ethernet1/1] sflow sampling-rate 100000
# Specify the traffic sampling mode.

[Device-Ethernet1/1] sflow sampling-mode random
# Display the sFlow configuration information.

[Device-Ethernet1/1] display sflow
sFlow Version: 5
sFlow Global Information:
Agent IP:3.3.3.1
Collector IP:3.3.3.2 Port:6343
Interval(s): 30
sFlow Port Information:
Interface Direction Rate Mode Status
Eth1/1 In/Out 100000 Random Active
Troubleshooting sFlow Configuration

The Remote sFlow Collector Cannot Receive sFlow Packets
Symptom
The remote sFlow collector cannot receive sFlow packets.
Analysis
z sFlow is not enabled globally because the sFlow agent or/and the sFlow collector is/are not
specified.
z No port is enabled with sFlow to sample data.
z The IP address of the sFlow collector specified on the sFlow agent is different from that of the
remote sFlow collector.
z No IP address is configured for the Layer 3 interface on the device, or the IP address is configured,
but the UDP packets with the IP address being the source cannot reach the sFlow collector.
z The physical link between the device and the sFlow collector fails.
Solution
1) Check whether sFlow is correctly configured by displaying sFlow configuration with the display
sflow command.
2) Check whether the correct IP address is configured for the device to communicate with the sFlow
collector.
3) Check whether the physical link between the device and the sFlow collector is normal.
1-4
Table of Contents
1 Virtual Fragment Reassembly Configuration 1-1

Overview 1-1
Configuring Virtual Fragment Reassembly 1-1
Displaying and Maintaining Virtual Fragment Reassembly 1-2
Virtual Fragment Reassembly Configuration Example 1-2
i
1 Virtual Fragment Reassembly Configuration
When configuring virtual fragment reassembly, go to these sections for information you are interested
in.
z Overview
z Configuring Virtual Fragment Reassembly
Overview
To prevent each service module (such as IPSec, NAT and firewall) from processing packet fragments
that do not arrive in order, you can enable the virtual fragment reassembly feature, which can virtually
reassemble the fragments of a datagram through fragment check, sequencing and caching, ensuring
fragments arriving at each service module is in order.
The virtual fragment reassembly feature can detect the following types of fragment attacks, and discard
the attack fragments for security.
z Tiny fragment attack: The fact that the first fragment of a datagram is very small and the Layer 4
(such as TCP and UDP) header is placed into the second fragment is considered a tiny fragment
attack.
z Overlapping fragment attack: The fact that two consecutive incoming fragments are identical is
considered an overlapping fragment attack.
z Fragment-flood attack: The fact that the maximum number of concurrent reassemblies or the
maximum number of fragments per datagram is reached is considered a fragment-flood attack.
Configuring Virtual Fragment Reassembly

Follow these steps to configure virtual fragment reassembly:

ip virtual-reassembly [ drop-fragments | Required

Enable virtual fragment
max-fragments number | max-reassemblies By default, the
reassembly
number | timeout seconds ] * feature is disabled.
1-1
z The virtual fragment reassembly feature only applies to incoming packets on an interface.
z The virtual fragment reassembly feature does not support load sharing, that is, the fragments of an
IP datagram cannot arrive through different interfaces.
Displaying and Maintaining Virtual Fragment Reassembly

Table 1-1 Display and maintain virtual fragment reassembly

Display information about display ip virtual-reassembly
virtual fragment reassembly on [ interface interface-type Available in any view
the interface(s) interface-number ]
Virtual Fragment Reassembly Configuration Example

z Router A connects to Host and Router B.

z NAT is enabled on Ethernet 1/1 of Router A.
z Configure virtual fragment reassembly on Ethernet 1/1 of Router A.
Network diagram
Figure 1-1 Network diagram for virtual fragment reassembly
1) Configure the host.

# Configure a static route to Router B. (Omitted)
# Configure NAT and virtual fragment reassembly.
[RouterA] nat static 10.1.1.1 10.2.2.3
[RouterA-Ethernet1/2] nat outbound static
1-2
[RouterA-Ethernet1/2] interface ethernet 1/1
[RouterA-Ethernet1/1] ip virtual-reassembly
With the virtual fragment reassembly feature, Router A will check, sequence, and cache fragments that
do not arrive in order at Ethernet 1/1. You can use the display ip virtual-reassembly command to view
related information.
1-3
Table of Contents
1 IP Routing Overview1-1
IP Routing and Routing Table1-1
Routing 1-1
Routing Table 1-2
Routing Protocol Overview 1-3
Static Routing and Dynamic Routing1-3
Classification of Dynamic Routing Protocols1-3
Routing Protocols and Routing Priority 1-4
Load Balancing and Route Backup 1-5
Route Recursion1-5
Sharing of Routing Information1-6
Configuring Load Sharing 1-6
Configuring Bandwidth-Based Non-Balanced Load Sharing 1-6
Configuring the Load Sharing Bandwidth for an Interface 1-6
Configuring a Router ID 1-7
Displaying and Maintaining a Routing Table1-7
Configuration Example1-8
Bandwidth-Based Load Sharing Configuration Example 1-8
i

IPv6 Yes Yes Yes Yes
Bandwidth-based
Yes Yes Yes Yes
non-balanced load sharing
Interface-based load sharing Yes Yes Yes Yes
1 IP Routing Overview
Go to these sections for information you are interested in:

z IP Routing and Routing Table
z Routing Protocol Overview
z Configuring Load Sharing
z Configuring a Router ID
z Displaying and Maintaining a Routing Table
IP Routing and Routing Table

Routing
Routing in the Internet is achieved through routers. Upon receiving a packet, a router finds an optimal
route based on the destination address and forwards the packet to the next router in the path until the
packet reaches the last router, which forwards the packet to the intended destination host.
1-1
Routing Table
Routing table
Routing tables play a key role in routing. Each router maintains a routing table, and each entry in the
table specifies which physical interface a packet destined for a certain destination should go out to
reach the next hop (the next router) or the directly connected destination.
Routes in a routing table can be divided into three categories by origin:
z Direct routes: Routes discovered by data link protocols, also known as interface routes.
z Static routes: Routes that are manually configured.
z Dynamic routes: Routes that are discovered dynamically by routing protocols.
Contents of a routing table
A routing table includes the following key items:

z Destination address: Destination IP address or destination network.
z Network mask: Specifies, in company with the destination address, the address of the destination
network. A logical AND operation between the destination address and the network mask yields
the address of the destination network. For example, if the destination address is 129.102.8.10 and
the mask 255.255.0.0, the address of the destination network is 129.102.0.0. A network mask is
made of a certain number of consecutive 1s. It can be expressed in dotted decimal format or by the
number of the 1s.
z Outbound interface: Specifies the interface through which the IP packets are to be forwarded.
z IP address of the next hop: Specifies the address of the next router on the path. If only the
outbound interface is configured, its address will be the IP address of the next hop.
z Priority for the route. Routes to the same destination but having different nexthops may have
different priorities and be found by various routing protocols or manually configured. The optimal
route is the one with the highest priority (with the smallest metric).
Routes can be divided into two categories by destination:
z Subnet routes: The destination is a subnet.
z Host routes: The destination is a host.
Based on whether the destination is directly connected to a given router, routes can be divided into:
z Direct routes: The destination is directly connected to the router.
z Indirect routes: The destination is not directly connected to the router.
To prevent the routing table from getting too large, you can configure a default route. All packets without
matching any entry in the routing table will be forwarded through the default route.
In Figure 1-1, the IP address on each cloud represents the address of the network. Router G is
connected to three networks and therefore has three IP addresses for its three physical interfaces. Its
routing table is shown under the network topology.
1-2
Figure 1-1 A sample routing table
Router A Router F
17.0.0.1 17.0.0.0 17.0.0.3
16.0.0.2 11.0.0.2
17.0.0.2
Router D
16.0.0.0 11.0.0.0
14.0.0.3
16.0.0.1 11.0.0.1
14.0.0.2 14.0.0.4
Router B 14.0.0.0 Router G
15.0.0.2 12.0.0.1
Router E 14.0.0.1
15.0.0.0 12.0.0.0
13.0.0.2
15.0.0.1 12.0.0.2
13.0.0.3 13.0.0.1
13.0.0.0
Router C Router H
Destination Network Nexthop Interface

11.0.0.0 11.0.0.1 2
12.0.0.0 12.0.0.1 1
13.0.0.0 12.0.0.2 1
14.0.0.0 14.0.0.4 3
15.0.0.0 14.0.0.2 3
16.0.0.0 14.0.0.2 3
17.0.0.0 11.0.0.2 2
Routing Protocol Overview

Static Routing and Dynamic Routing
Static routing is easy to configure and requires less system resources. It works well in small, stable
networks with simple topologies. Its major drawback is that you must perform routing configuration
again whenever the network topology changes; it cannot adjust to network changes by itself.
Dynamic routing is based on dynamic routing protocols, which can detect network topology changes
and recalculate the routes accordingly. Therefore, dynamic routing is suitable for large networks. Its
disadvantages are that it is difficult to configure, and that it not only imposes higher requirements on the
system, but also consumes a certain amount of network resources.
Classification of Dynamic Routing Protocols
Dynamic routing protocols can be classified based on the following standards:
Operational scope
z Interior gateway protocols (IGPs): Work within an autonomous system, including RIP, OSPF, and
IS-IS.
z Exterior gateway protocols (EGPs): Work between autonomous systems. The most popular one is
BGP.
1-3
An autonomous system refers to a group of routers that share the same routing policy and work under
the same administration.
Routing algorithm
z Distance-vector protocols: RIP and BGP. BGP is also considered a path-vector protocol.
z Link-state protocols: OSPF and IS-IS.
The main differences between the above two types of routing algorithms lie in the way routes are
discovered and calculated.
Type of the destination address
z Unicast routing protocols: RIP, OSPF, BGP, and IS-IS.

z Multicast routing protocols: PIM-SM and PIM-DM.
This chapter focuses on unicast routing protocols. For information on multicast routing protocols, refer
to the IP Multicast Volume.
Version of IP protocol
IPv4 routing protocols: RIP, OSPFv2, BGP4, and IS-IS.

IPv6 routing protocols: RIPng, OSPFv3, BGP4+, and IPv6 IS-IS.
Support for IPv6 varies by device.
Routing Protocols and Routing Priority
Different routing protocols may find different routes to the same destination. However, not all of those
routes are optimal. In fact, at a particular moment, only one protocol can uniquely determine the current
optimal route to the destination. For the purpose of route selection, each routing protocol (including
static routes) is assigned a priority. The route found by the routing protocol with the highest priority is
preferred.
The following table lists some routing protocols and the default priorities for routes found by them:
Routing approach Priority

DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
1-4
Routing approach Priority
OSPF NSSA 150
IBGP 255
EBGP 255
UNKNOWN 256
z The smaller the priority value, the higher the priority.

z The priority for a direct route is always 0, which you cannot change. Any other type of routes can
have their priorities manually configured.
z Each static route can be configured with a different priority.
z IPv4 and IPv6 routes have their own respective routing tables.
Load Balancing and Route Backup
Load Balancing
In multi-route mode, a routing protocol can be configured with multiple equal-cost routes to the same
destination. These routes have the same priority and will all be used to accomplish load balancing if
there is no route with a higher priority available. A given routing protocol may find several routes with the
same metric to the same destination, and if this protocol has the highest priority among all the active
protocols, these routes will be considered valid routes for load balancing.
z The number of routes for load balancing varies by device.

z In current implementations, routing protocols supporting load balancing are static routing, RIP,
OSPF, BGP, and IS-IS.
Route backup
Route backup can help improve network reliability. With route backup, you can configure multiple routes
to the same destination, expecting the one with the highest priority to be the main route and all the rest
backup routes.
Under normal circumstances, packets are forwarded through the main route. When the main route goes
down, the route with the highest priority among the backup routes is selected to forward packets. When
the main route recovers, the route selection process is performed again and the main route is selected
again to forward packets.
Route Recursion
The nexthops of some BGP routes (except eBGP routes) and static routes configured with nexthops
may not be directly connected. To forward the packets, the outgoing interface to reach the nexthop must
1-5
be available. Route recursion is used to find the outgoing interface based on the nexthop information of
the route. Link-state routing protocols, such as OSPF and IS-IS, do not need route recursion because
they obtain nexthop information through route calculation.
Sharing of Routing Information
As different routing protocols use different routing algorithms to calculate routes, they may find different
routes. In a large network with multiple routing protocols, it is required for routing protocols to share their
routing information. Each routing protocol has its own route redistribution mechanism. For detailed
information, refer to the IP Routing Volume.
Configuring Load Sharing

Load sharing is implemented in the following ways:
z Flow-based load sharing: After fast forwarding is enabled, only flow-based load sharing can be
performed. For example, assume there are two equal-cost routes on the device. If one data flow is
to pass through the device, it will be forwarded through either route; if two data flows are to pass
through, they will be forwarded through the two routes separately.
z Packet-based load sharing: After fast forwarding is disabled, packets can be evenly forwarded over
the two equal-cost routes.
z Bandwidth-based non-balanced load sharing: After fast forwarding is disabled, packets can be
forwarded based on the configurable bandwidths of the interfaces. The greater bandwidth an
interface has, the more packets it forwards.
Configuring Bandwidth-Based Non-Balanced Load Sharing
Follow these steps to configure bandwidth-based non-balanced load sharing

Configure bandwidth-based Optional

bandwidth-based-sharing
non-balanced load sharing Disabled by default
z Bandwidth-based non-balanced load sharing does not support the load sharing of flows. Therefore,
you have to disable fast forwarding on the corresponding outbound and inbound interfaces.
z Support for this feature varies with devices.
Configuring the Load Sharing Bandwidth for an Interface
Follow these steps to configure the load sharing bandwidth for an interface:

interface-number
1-6
Optional
Configure the load sharing
load-bandwidth bandwidth The default is the physical
bandwidth for the interface
bandwidth of the interface.
z The load sharing bandwidth of an interface defaults to the physical bandwidth of the interface.
z If you specify a value of 0 for the bandwidth argument, routing is disabled on the interface and the
interface will not be used for load sharing. But this does not affect other states of the physical
interface.
z Support for this feature varies with devices.
Configuring a Router ID
Some routing protocols use a router ID to identify a device. You can configure a router ID for a device. If
no router ID is configured, the default router ID is used.

Optional
Configure a router ID router id router-id
Displaying and Maintaining a Routing Table

Display brief information about display ip routing-table [ vpn-instance
Available in any
the active routes in the routing vpn-instance-name ] [ verbose | | { begin |
view
table exclude | include } regular-expression ]
Display information about display ip routing-table ip-address
Available in any
routes to the specified [ mask-length | mask ] [ longer-match ]
view
destination [ verbose ]
display ip routing-table ip-address1
routes with destination Available in any
{ mask-length | mask } ip-address2
addresses in the specified view
{ mask-length | mask } [ verbose ]
range
display ip routing-table acl acl-number Available in any
routes permitted by an IPv4
[ verbose ] view
basic ACL
Display routing information display ip routing-table ip-prefix Available in any
permitted by an IPv4 prefix list ip-prefix-name [ verbose ] view
Display routes of a routing display ip routing-table protocol protocol Available in any
protocol [ inactive | verbose ] view
1-7
Display statistics about the
display ip routing-table [ vpn-instance Available in any
network routing table or a VPN
vpn-instance-name ] statistics view
routing table
Display VPN recursive route display ip relay-route [ vpn-instance Available in any
information vpn-instance-name ] view
Display statistics about display load-sharing ip address ip-address Available in any
bandwidth-based load sharing mask view
Available in any
Display the router ID display router id
view
Clear statistics about reset load-sharing statistics { all | ip Available in user
bandwidth-based load sharing address ip-address mask } view
reset ip routing-table statistics protocol
Clear statistics for the routing Available in user
[ vpn-instance vpn-instance-name ] { all |
table or a VPN routing table view
protocol }
Display brief IPv6 routing table Available in any
display ipv6 routing-table
information view
Display verbose IPv6 routing Available in any
display ipv6 routing-table verbose
table information view
Display routing information for
display ipv6 routing-table ipv6-address Available in any
a specified destination IPv6
prefix-length [ longer-match ] [ verbose ] view
address
Display routing information display ipv6 routing-table acl acl6-number Available in any
permitted by an IPv6 ACL [ verbose ] view
Display routing information display ipv6 routing-table ipv6-prefix Available in any
permitted by an IPv6 prefix list ipv6-prefix-name [ verbose ] view
Display IPv6 routing display ipv6 routing-table protocol protocol Available in any
information of a routing protocol [ inactive | verbose ] view
Available in any
Display IPv6 routing statistics display ipv6 routing-table statistics
view
Display IPv6 routing display ipv6 routing-table ipv6-address1
Available in any
information for an IPv6 address prefix-length1 ipv6-address2 prefix-length2
view
range [ verbose ]
Display IPv6 recursive route Available in any
display ipv6 relay-route
information view
Clear specified IPv6 routing reset ipv6 routing-table statistics protocol Available in user
table statistics { all | protocol } view
Bandwidth-Based Load Sharing Configuration Example
On Router A, there are three equal-cost routes to the destination network 10.2.1.0/24, as shown in
Figure 1-2:
<Sysname> display fib
FIB Table:
1-8
Total number of Routes : 4
Flag:
U:Useable G:Gateway H:Host B:Blackhole D:Dynamic S:Static
R:Reject L:Generated by ARP or ESIS
Destination/Mask Nexthop Flag TimeStamp Interface Token

10.2.1.0/24 10.1.1.2 GSU t[0] Eth0/0 invalid
10.2.1.0/24 10.1.2.2 GSU t[0] Atm1/0 invalid
10.2.1.0/24 10.1.3.2 GSU t[0] Serial2/0 invalid
Use the display load-sharing ip address command to display bandwidths on interfaces.

<Sysname> display load-sharing ip address 10.2.1.0 24
There are/is totally 3 route entry(s) to the same destination network.
Nexthop Packet(s) Bandwidth[KB] Flow(s) Interface
10.1.1.2 763851 100000 0 Ethernet0/0
10.1.2.2 1193501 155000 0 Atm1/0
10.1.3.2 15914 2048 0 Serial2/0
The display shows that packets are load-shared according to their default bandwidths.
Specify the load sharing bandwidths for ATM 1/0, Ethernet 0/0, and Serial 2/0 on Router A as 100 kbps,
200 kbps, and 300 kbps, respectively.
Network diagram
Figure 1-2 Network diagram for bandwidth-based non-balanced load sharing
# On Router A, configure load sharing bandwidths for the three interfaces.

[Sysname-Ethernet0/0] load-bandwidth 200
[Sysname-Atm1/0] load-bandwidth 100
[Sysname] interface serial 2/0
[Sysname-serial2/0] load-bandwidth 300
[Sysname-serial2/0] quit
# Display bandwidths of the three interfaces.

[Sysname] display load-sharing ip address 10.2.1.0 24
There are/is totally 3 route entry(s) to the same destination network.
1-9
Nexthop Packet(s) Bandwidth[KB] Flow(s) Interface
10.1.2.2 142824 100 0 Atm1/0
10.1.1.2 285648 200 0 Ethernet0/0
10.1.3.2 428472 300 0 Serial2/0
The display shows that packets are load-shared according to the specified interface bandwidths.
1-10
Table of Contents
1 BGP Configuration 1-1

BGP Overview1-1
Formats of BGP Messages 1-2
BGP Path Attributes 1-4
BGP Route Selection1-8
iBGP and IGP Synchronization 1-10
Settlements for Problems in Large Scale BGP Networks 1-11
BGP GR1-14
MP-BGP 1-15
BGP Configuration Task List1-16
Configuring BGP Basic Functions1-16
Prerequisites1-16
Controlling Route Distribution and Reception1-18
Prerequisites1-18
Configuring BGP Route Redistribution1-18
Enable Guard Route Redistribution1-19
Configuring BGP Route Summarization1-20
Advertising a Default Route to a Peer or Peer Group 1-20
Configuring BGP Route Distribution Filtering Policies 1-21
Configuring BGP Route Reception Filtering Policies 1-22
Enabling BGP and IGP Route Synchronization 1-22
Configuring BGP Route Dampening 1-23
Configuring BGP Route Attributes 1-23
Prerequisites1-23
Tuning and Optimizing BGP Networks 1-25
Prerequisites1-26
Configuring a Large Scale BGP Network1-27
Configuring BGP Peer Groups 1-27
Configuring BGP Community 1-28
Configuring a BGP Route Reflector 1-29
Configuring a BGP Confederation1-30
Configuring BGP GR1-30
Enabling Trap1-31
Displaying and Maintaining BGP 1-32
Displaying BGP 1-32
Resetting BGP Connections1-33
Clearing BGP Information 1-33
BGP Configuration Examples (on Routers) 1-33
i
BGP Basic Configuration1-33
BGP and IGP Synchronization Configuration 1-37
BGP Load Balancing and MED Attribute Configuration 1-39
BGP Community Configuration 1-41
BGP Route Reflector Configuration 1-44
BGP Confederation Configuration1-46
BGP Path Selection Configuration 1-49
BGP Configuration Examples (on Switches) 1-52
BGP Basic Configuration1-52
BGP and IGP Synchronization Configuration 1-56
BGP Load Balancing and MED Attribute Configuration 1-58
BGP Community Configuration 1-61
BGP Route Reflector Configuration 1-63
BGP Confederation Configuration1-65
BGP Path Selection Configuration 1-68
Troubleshooting BGP1-72
No BGP Peer Relationship Established 1-72
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 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 Displaying and Maintaining BGP
z BGP Configuration Examples (on Routers)
z BGP Configuration Examples (on Switches)
z Troubleshooting BGP
The term router refers to a router 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
1-1
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
A router advertising BGP messages is called a BGP speaker. It establishes peer relationships with 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 simpify 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.
1-2
z Type: This 1-byte unsigned integer indicates the type code of the message. The following type
codes are defined: 1Open, 2-Update, 3-Notification, 4Keepalive, and 5Route-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:
Figure 1-2 BGP open message format
0 7 15 31
Version
My Autonomous System
Hold Time
BGP Identifier
Opt Parm Len

Optional Parameters
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.
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(Variable) N Octets
Total Path Attribute Length 2 Octets
Path Attributes(Variable) N Octets
NLRI(Variable) 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.
1-3
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.
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:
1-4
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.
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 receivers AS is leftmost, as shown below:
1-5
Figure 1-6 AS_PATH attribute
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
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
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.
1-7
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 route originated by the local router
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
z Select the route with the smallest next hop cost
z Select the route with the shortest CLUSTER_LIST
1-8
z Select the route with the smallest ORIGINATOR_ID
z Select the route advertised by the router with the smallest Router ID
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 add the route into its BGP routing table and 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.
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:
1-13
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.
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.
1-14
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
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
1-15
BGP Configuration Task List
Complete the following tasks to configure BGP:
Task Remarks
Configuring BGP Basic Functions Required
Configuring BGP Route Redistribution Optional
Enable Guard Route Redistribution Optional
Enable Guard Route Redistribution Optional
Controlling Route Advertising a Default Route to a Peer or Peer Group Optional

Distribution and Reception Configuring BGP Route Distribution Filtering Policies Optional
Configuring BGP Route Reception Filtering Policies Optional

Enabling BGP and IGP Route Synchronization Optional
Configuring BGP Route Dampening Optional
Configuring BGP Route Attributes Optional

Tuning and Optimizing BGP Networks Optional
Configuring BGP Peer Groups Optional
Configuring a Large Scale Configuring BGP Community Optional

BGP Network Configuring a BGP Route Reflector Optional
Configuring a BGP Confederation Optional
Configuring BGP GR Optional
Enabling Trap Optional
Configuring BGP Basic Functions

The section describes BGP basic configuration.
z This section does not differentiate between BGP and MP-BGP.

z Since BGP runs on TCP, you need to specify the IP addresses of peers, which may not be directly
connected.
z Using logical links can also establish BGP peer relationships.
z In general, IP addresses of loopback interfaces are used to improve stability of BGP connections.
Prerequisites
The neighboring nodes are accessible to each other at the network layer.
Follow these steps to configure BGP basic functions:
1-16
Enable BGP and enter BGP

bgp as-number
view Not enabled by default
Optional
If no IP addresses are configured
Specify a Router ID router-id ip-address for loopback interface and other
interfaces, the task becomes
required.
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
peer { group-name | Optional
Configure a description for a
ip-address } description
peer or a peer group Not configured by default
description-text
Enable IPv4 unicast address Optional

default ipv4-unicast
family for all peers Enabled by default
Optional
Enable a peer peer ip-address enable
Enabled by default
peer { group-name | Optional

Ignore a peer or peer group
ip-address } ignore Not ignored by default
Optional
Enable the globally log-peer-change
logging of Enabled by default
peer state Optional
changes for a peer or peer { group-name |
peer group ip-address } log-change Enabled by default
Specify a preferred value for peer { group-name | Optional
routes from a peer or peer ip-address } preferred-value
group value The preferred value defaults to 0.
Optional
peer { group-name | By default, BGP uses the
Specify the source interface for ip-address } outbound interface of the best
establishing TCP connections connect-interface route to the BGP peer as the
to a peer or peer group interface-type source interface for establishing
interface-number a TCP connection to the
peer/peer group.
Optional
Allow the establishment of
peer { group-name | Not allowed by default. By
eBGP connection to a non
ip-address } ebgp-max-hop specifying hop-count, you can
directly connected peer/peer
[ hop-count ] specify the max hops for the
group
eBGP connection.
1-17
z It is required to specify for a BGP router a router ID, a 32-bit unsigned integer and the unique
identifier of the router in the AS.
z You can specify a router ID manually. If not, the system selects the highest IP address among
loopback interface addresses; if no loopback interface IP addresses are available, it selects the
highest IP address among physical interfaces as the router ID. It is recommended to specify a
loopback interface address as the router ID to enhance network reliability. Only when the interface
with the Router ID is deleted will the system select another Router ID.
z You need to create a peer group before configuring it. Refer to Configuring BGP Peer Groups.
z To establish multiple BGP connections between two routers, you need to specify on the local router
the source interfaces for establishing TCP connections to the peers on the peering BGP router
respectively; otherwise, the local BGP router may fail to establish TCP connections to the peers
when using the outbound interfaces of the best routes as the source interfaces.
z 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. You need not use this command for directly connected eBGP peers, which employ loopback
interfaces for peer relationship establishment.
z If you both reference a routing policy and use the peer { group-name | ip-address } preferred-value
value command to set a preferred value for routes from a peer, the routing policy sets a non-zero
preferred value for routes matching it. Other routes not matching the routing policy uses the value
set with the command. If the preferred value in the routing policy is zero, the routes matching it will
use the value set with the command. For information about using a routing policy to set a preferred
value, refer to the command peer { group-name | ip-address } route-policy route-policy-name
{ export | import } in this document, and the command apply preferred-value preferred-value in
Routing Policy Commands of the IP Routing Volume.
Controlling Route Distribution and Reception

Prerequisites
Before configuring this task, you have completed BGP basic configuration.
Configuring BGP Route Redistribution
BGP can advertise the routing information of the local AS to peering ASs, but it redistributes routing
information from IGP into BGP rather than self-finding. During route redistribution, BGP can filter routing
information from specific routing protocols.
Follow these steps to configure BGP route redistribution:
Enter BGP view bgp as-number
1-18
Enable BGP to redistribute Optional
default route into the BGP default-route imported
routing table Not enabled by default
import-route protocol [ process-id | Required

Redistribute routes from
all-processes ] [ med med-value | Not redistributed by
another routing protocol
route-policy route-policy-name ] * default
network ip-address [ mask | Optional
Inject a network to the BGP
mask-length ] [ short-cut |
routing table Not injected by default
route-policy route-policy-name ]
z The ORIGIN attribute of routes redistributed using the import-route command is Incomplete.
z The ORIGIN attribute of networks advertised into the BGP routing table with the network
command is IGP. These networks must exist in the local IP routing table, and using a routing policy
makes routes control more flexible.
Enable Guard Route Redistribution
Support for this feature varies with devices.
Guard routes use NULL 0 as the outbound interface.

You can enable Guard route redistribution into BGP on a Guard device, After that, when a Guard route
is configured on the Guard device, the Guard route is redistributed into the BGP route table and
advertised to a BGP peer. In this way, traffic that is received by the BGP peer and destined to the
destination of the Guard route is diverted to the Guard device, which then handles the traffic as
configured. For detailed Guard route information and configuration, refer to "Guard Route
Configuration" in the IP Routing Volume.
Follow these steps to enable Guard route redistribution into BGP:

Enter system system system-view
import-route guard [ med Required
Enable Guard route
med-value | route-policy
redistribution into BGP Disabled by default
route-policy-name ] *
1-19
z A Guard route configured on a router is neither installed into the FIB nor used by the router to
forward IP packets.
z Guard routes redistributed into the BGP route table have an ORIGIN attribute of incomplete.
Configuring BGP Route Summarization
To reduce the routing table size on medium and large BGP networks, you need to configure route
summarization on peers. BGP supports two summarization modes: automatic and manual.
z Automatic summarization: Summarizes redistributed IGP subnets. With the feature configured,
BGP advertises only summary natural networks rather than subnets. The default route and routes
injected with the network command can not be summarized.
z Manual summarization: Summarizes BGP local routes. The manual summary routes enjoy higher
priority than automatic ones.
Follow these steps to configure BGP route summarization:
Configure Required
automatic route summary automatic No route summarization
Configur summarization is configured by default.
e BGP
route aggregate ip-address { mask | Choose either as
summari Configure manual mask-length } [ as-set | attribute-policy needed; if both are
zation route route-policy-name | detail-suppressed configured, the manual
summarization | origin-policy route-policy-name | route summarization
suppress-policy route-policy-name ]* takes effect.
Advertising a Default Route to a Peer or Peer Group
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 Not advertised by
peer or peer group
[ route-policy route-policy-name ] default
1-20
With the peer default-route-advertise command executed, the 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.
Configuring 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.
1-21
Configuring BGP Route Reception Filtering Policies
Follow these steps to configure BGP route reception filtering policies:
Filter incoming routes filter-policy { acl-number | Required to choose any;

with an ACL or IP prefix ip-prefix ip-prefix-name }
list import No route reception filtering is
configured by default;
Reference a routing peer { group-name | You can configure a filtering policy as
policy to filter routes from ip-address } route-policy needed;
a peer/peer group policy-name import
If several filtering policies are
Reference an ACL to filter peer { group-name | configured, they are applied in the
routing information from a ip-address } filter-policy following sequence:
peer/peer group acl-number import z filter-policy import
Reference an AS path z peer filter-policy import
peer { group-name | z peer as-path-acl import
ACL to filter routing
ip-address } as-path-acl
information from a z peer ip-prefix import
as-path-acl-number import
peer/peer group z peer route-policy import
Reference an IP prefix list Only routes passing the first policy,
peer { group-name | can they go to the next, and only
to filter routing
ip-address } ip-prefix routes passing all the configured
information from a
ip-prefix-name import policies, can they be received.
peer/peer group
peer { group-name |
Specify the number of
ip-address } route-limit
prefixes that can be
prefix-number [ { alert-only | The number is not limited by default.
received from a peer/peer
reconnect reconnect-time } |
group
percentage-value ] *
z Only routes permitted by the specified filtering policies can they be installed into the local BGP
routing table.
z Members of a peer group can have different route reception filtering policies from the peer group.
Enabling BGP and IGP Route Synchronization
By default, when a BGP router receives an iBGP route, it only checks the reachability of the routes next
hop before advertisement. With BGP and IGP synchronization configured, the BGP router cannot
advertise the route to eBGP peers unless the route is also available in the IGP routing table.
Follow these steps to configure BGP and IGP synchronization:
1-22
Enable synchronization Required

synchronization
between BGP and IGP Not enabled by default
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 Required

Configure BGP
half-life-unreachable reuse suppress
route dampening Not configured by default
ceiling | route-policy route-policy-name ] *
Configuring BGP Route Attributes

Prerequisites
Before configuring this task, you have configured BGP basic functions.
You can configure BGP route attributes to influence BGP route selection.
Follow these steps to configure BGP route attributes:
preference Optional
{ external-preference
Configure preferences for external, internal-preference The default preferences
internal, local routes local-preference | of external, internal, and
route-policy local routes are 255, 255,
route-policy-name } and 130 respectively.
default local-preference Optional

Configure the default local preference
value 100 by default
1-23
Configure the default Optional

default med med-value
MED value 0 by default
Enable the comparison Optional
of MED of routes from compare-different-as-med
different ASs Not enabled by default
Configure
the MED
attribute Enable the comparison Optional
of MED of routes from bestroute compare-med
each AS Not enabled by default

bestroute
of MED of routes from
med-confederation Not enabled by default
confederation peers
Optional
By default,
advertisements to an
eBGP peer/peer group
Specify the router as the next hop of peer { group-name | take the router as the
routes sent to a peer/peer group ip-address } next-hop-local next hop, while
advertisements to an
iBGP peer/peer group do
not take the local router
as the next hop.
Configure repeating Optional

peer { group-name |
times of local AS The local AS number can
ip-address } allow-as-loop
number in routes from not be repeated in routes
[ number ]
a peer/peer group from the peer/peer group.
Optional
Disable BGP from
considering By default, BGP
bestroute as-path-neglect considers AS_PATH
AS_PATH during best
route selection during best route
selection.
Optional
Specify a fake AS peer { group-name | Not specified by default
Configure the number for a ip-address } fake-as
AS_PATH This command is only
peer/peer group as-number applicable to an eBGP
attribute
peer or peer group.
Substitute local AS
number for the AS Optional
peer { group-name |
number of a peer/peer The substitution is not
ip-address } substitute-as
group in the configured by default.
AS_PATH attribute
Configure BGP to not
keep private AS Optional
numbers in the peer { group-name | By default, BGP updates
AS_PATH attribute of ip-address } public-as-only carry private AS
updates to a numbers.
peer/peer group
1-24
z Using a routing policy can set preferences for routes matching it. Routes not matching it use the
default preferences.
z If other conditions are identical, the route with the smallest MED value is selected as the best
external route.
z Using the peer next-hop-local command can specify the router as the next hop for routes sent to
a peer/peer group. If BGP load balancing is configured, the router specify itself as the next hop for
routes sent to a peer/peer group regardless of whether the peer next-hop-local command is
configured.
z In a third party next hop" network, that is , the two eBGP peers reside in a common broadcast
subnet, the BGP router does not specify itself as the next hop for routes sent to the eBGP peer,
unless the peer next-hop-local command is configured.
z 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.
z You can specify a fake AS number to hide the real one as needed. The fake AS number applies to
routes sent to eBGP peers only, that is, eBGP peers in other ASs can only find the fake AS number.
z The peer substitute-as command is used only in specific networking environments. Inappropriate
use of the command may cause routing loops.
Tuning and Optimizing BGP Networks

This task involves the following parts:
1) Configure BGP timers
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 after the
holdtime elapses, it tears down the connection.
When establishing a BGP connection, the two parties compare their holdtimes, taking the shorter one
as the common holdtime.
2) Reset BGP connections
After modifying a routing policy, you have to reset BGP connections to make the new one take effect,
causing short time disconnections. The current BGP implementation supports the route-refresh
capability. With this capability enabled on all BGP routers in a network, when a policy is modified on a
router, the router advertises a route-refresh message to its peers, which then resend their routing
information to the router. Therefore, the local router can perform dynamic route update and apply the
new policy without tearing down BGP connections.
If a peer not supporting route-refresh exists in the network, you must configure the peer
keep-all-routes command to save all routes from the peer.
3) Configure BGP authentication
BGP employs TCP as the transport protocol. To enhance security, you can configure BGP to perform
MD5 authentication when establishing a TCP connection. BGP MD5 authentication is not for BGP
packets. It is used to set passwords for TCP connections. If the authentication fails, the TCP connection
can not be established.
1-25
Prerequisites
Before configuring this task, you have configured BGP basic functions
Follow these steps to tune and optimize BGP networks:
Configure keepalive timer keepalive keepalive Optional

interval and holdtime hold holdtime
Configure The keepalive interval
BGP timers Configure keepalive peer { group-name | defaults to 60 seconds,
interval and holdtime ip-address } timer keepalive holdtime defaults to 180
for a peer/peer group keepalive hold holdtime seconds.
Optional
The intervals for sending
peer { group-name | the same update to an
Configure the interval for sending the
ip-address } iBGP peer and an eBGP
same update to a peer/peer group
route-update-interval interval peer default to 15
seconds and 30 seconds
respectively.
Disable BGP
peer { group-name |
route-refresh and Optional
ip-address }
multi-protocol
capability-advertise Enabled by default
extensions for a
conventional
peer/peer group
peer { group-name |
Enable BGP route Optional
ip-address }
refresh for a peer/peer
capability-advertise Enabled by default
group
route-refresh
Keep all original routes
Configur from a peer/peer group Optional
peer { group-name |
e BGP regardless of whether
ip-address } keep-all-routes Not kept by default
soft reset they pass the inbound
filtering policy
Return to user view return
Perform manual soft refresh bgp { all | ip-address |

reset on BGP group group-name | external | Required
connections internal } { export | import }
Enable the clearing of the direct Optional

eBGP session on any interface that ebgp-interface-sensitive
becomes down Enabled by default
Enable MD5 authentication when peer { group-name | Optional

establishing a TCP connection to the ip-address } password { cipher
peer/peer group | simple } password Enabled by default
1-26
Optional
Configure the number of BGP load
balance number Load balancing is not
balanced routes
enabled by default.
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 Use of the peer keep-all-routes command saves all routing updates from the peer regardless of
whether any filtering policy is configured. The system uses these updates to rebuild the routing
table after a soft reset.
z Performing BGP soft reset can refresh the routing table and apply the new policy without tearing
down BGP sessions.
z BGP soft reset requires all routers in the network have the route-refresh capability. If not, you need
use the peer keep-all-routes command to keep all routing information from a BGP peer to perform
soft reset.
z Configured in BGP view, MD5 authentication also applies to the MP-BGP VPNv4 extension,
because the same TCP connection is used.
Configuring a Large Scale BGP Network

In a large-scale BGP network, configuration and maintenance become difficult due to large numbers of
BGP peers. In this case, configuring peer groups makes management easier and improves route
distribution efficiency. Peer group includes iBGP peer group, where peers belong to the same AS, and
eBGP peer group, where peers belong to different ASs. If peers in an eBGP group belong to the same
external AS, the eBGP peer group is a pure eBGP peer group, and if not, a mixed eBGP peer group.
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.
Before configuring this task, you have made peering nodes accessible to each other at the network
layer.
Configuring BGP Peer Groups
Follow these steps to configure BGP peer groups:
1-27
Create an iBGP peer group group-name Optional

group [ internal ] You can add multiple peers
Configure
an iBGP into the group. The system
peer peer ip-address group will create these peers
Add a peer into the automatically and specify the
group group-name [ as-number
iBGP peer group local AS number as their AS
as-number ]
in BGP view.
Create an eBGP peer
group group-name external Optional
group
Configure You can add multiple peers
a pure Specify the AS peer group-name into the group. The system
eBGP number for the group as-number as-number will create these peers
peer automatically and specify the
group peer ip-address group local AS number as their AS
Add a peer into the
group-name [ as-number in BGP view.
group
as-number ]
Create an eBGP peer
group group-name external
group
Configure
Specify a peer and the Optional
a mixed peer ip-address as-number
AS number for the
eBGP as-number You can add multiple peers
peer
peer into the group.
group peer ip-address group
Add a peer into the
group-name [ as-number
group
as-number ]
z You need not specify the AS number when creating an iBGP peer group.
z If there are peers in a peer group, you can neither change the AS number of the group nor use the
undo command to remove the AS number
z You need specify the AS number for each peer in a mixed eBGP peer group respectively.
Configuring BGP Community
Follow these steps to configure BGP community:
1-28
Advertise the
peer { group-name | ip-address }
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

Apply a routing policy to routes advertised
route-policy route-policy-name Not configured
to a peer/peer group
export by default
z When configuring BGP community, you need to configure a routing policy to define the community
attribute, and apply the routing policy to route advertisement.
z For routing policy configuration, refer to Routing Policy Configuration in the IP Routing Volume.
Configuring a BGP Route Reflector
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 to avoid routing loops.
1-29
Configuring a BGP Confederation
Follow these steps to configure a BGP confederation:
Configure a
confederation id as-number
confederation ID Required
Configure a BGP
confederation Specify sub-ASs Not configured by
confederation peer-as default
contained in the
as-number-list
confederation
Enable compatibility with routers not Optional
compliant with RFC 3065 in the confederation nonstandard
confederation Not enabled by default
z A confederation contains 32 sub-ASs at most. The as-number of a sub-AS takes effect in the
confederation only.
z 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.
Configuring BGP GR
Perform the following configuration on the GR Restarter and GR Helper respectively.
A device can act as both the GR Restarter and GR Helper at the same time.
Follow these steps to configure BGP GR:

Enable BGP, and enter its view bgp as-number
Required
Enable GR Capability for BGP graceful-restart
Disabled by default
Configure the maximum time Optional
graceful-restart timer restart
allowed for the peer to
timer 150 seconds by default
reestablish a BGP session
Configure the maximum time to graceful-restart timer Optional

wait for the End-of-RIB marker wait-for-rib timer 180 seconds by default
1-30
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 Router-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 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.)
Follow these steps to enable Trap:
Optional
Enable Trap for BGP snmp-agent trap enable bgp
Enabled by default
1-31
Displaying and Maintaining BGP
Displaying BGP

Display peer group information display bgp group [ group-name ]
Display advertised BGP routing
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 display bgp routing-table [ ip-address [ { mask |
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 display bgp routing-table community
information matching the [ aa:nn&<1-13> ] [ no-advertise | no-export |
specified BGP community no-export-subconfed ]* [ whole-match ]
display bgp routing-table community-list
Display routing information Available
{ basic-community-list-number [ whole-match ] |
matching a BGP community list in any
adv-community-list-number }&<1-16>
view
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 originating from display bgp routing-table different-origin-as
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 bgp routing-table peer ip-address

Display routing information to
{ advertised-routes | received-routes }
or 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
Display BGP routing statistics display bgp routing-table statistic
1-32
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 user
reset bgp flap-info [ regexp as-path-regexp | view
Clear route flap information as-path-acl as-path-acl-number | ip-address
[ mask | mask-length ] ]
BGP Configuration Examples (on Routers)

BGP Basic Configuration
In the following figure are all BGP routers. Between Router A and Router B is an eBGP connection.
iBGP speakers Router B, Router C, and Router D are fully meshed.
Network diagram
Figure 1-16 Network diagram for BGP basic configuration (on routers)
1) Configure IP addresses for interfaces (omitted)
1-33
2) Configure iBGP connections
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 9.1.1.2 as-number 65009
[RouterB-bgp] quit
# Configure Router C.
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 9.1.3.1 as-number 65009
[RouterC-bgp] quit
# Configure Router D.
[RouterD] bgp 65009
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] peer 9.1.1.1 as-number 65009
[RouterD-bgp] quit
3) Configure the eBGP connection
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.1.1 as-number 65009
# Inject network 8.0.0.0/8 to the BGP routing table.

[RouterA-bgp] network 8.0.0.0
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp] quit
# Display BGP peer information on Router B.

[RouterB] 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
1-34
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 Router B has established BGP connections to other routers.
# Display BGP routing information on Router A.
[RouterA] 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
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 8.0.0.0 0.0.0.0 0 0 i
# Display BGP routing information on Router B.

[RouterB] display bgp routing-table

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

[RouterC] display bgp routing-table

i 8.0.0.0 200.1.1.2 0 100 0 65008i
From above outputs, you can find Router A has learned no route to AS65009, and Router C has learned
network 8.0.0.0 but the next hop 200.1.1.2 is unreachable, and thus the route is invalid.
1-35
4) Redistribute direct routes
[RouterB] bgp 65009
[RouterB-bgp] import-route direct
# Display BGP routing table information on Router A.


*> 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.3.0/24 200.1.1.1 0 0 65009?
* 200.1.1.0 200.1.1.1 0 0 65009?
# Display BGP routing table information on Router C.


*>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.3.0/24 9.1.3.1 0 100 0 ?
*>i 200.1.1.0 9.1.3.1 0 100 0 ?
You can find the route 8.0.0.0 becomes valid with the next hop as Router A.
# Ping 8.1.1.1 on Router C.
[RouterC] ping 8.1.1.1

1-36
0.00% packet loss
BGP and IGP Synchronization Configuration
As shown below, OSPF is the IGP protocol in AS65009, where Router C is a non-BGP router. Between
Router A and Router B is an eBGP connection.
Network diagram
Figure 1-17 Network diagram for BGP and IGP synchronization

2) Configure OSPF (ommited)
[RouterA] bgp 65008

[RouterA-bgp] network 8.1.1.0 24
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp] quit
4) Configure BGP and IGP synchronization
# Configure BGP to redistribute routes from OSPF on Router B.
[RouterB] bgp 65009
[RouterB-bgp] import-route ospf 1
[RouterB-bgp] quit
1-37

*> 8.1.1.0/24 0.0.0.0 0 0 i

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

[RouterB] ospf
[RouterB-ospf-1] import-route bgp
[RouterB-ospf-1] quit
# Display routing table information on Router C.

<RouterC> display ip routing-table
8.1.1.0/24 O_ASE 150 1 9.1.1.1 S2/0

9.1.1.0/24 Direct 0 0 9.1.1.2 S2/0
9.1.1.1/32 Direct 0 0 9.1.1.1 S2/0
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 Eth1/0
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
# Enable route automatic summarization on Router B.
[RouterB] bgp 65009
[RouterB-bgp] summary automatic


1-38
*> 8.1.1.0/24 0.0.0.0 0 0 i

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

[RouterA] ping -a 8.1.1.1 9.1.2.1

0.00% packet loss
BGP Load Balancing and MED Attribute Configuration
This example describes how to configure BGP load balancing, and how to use the MED attribute to
affect BGP route election.
As shown in the figure below, all routers run BGP, and Router A resides in AS65008, Router B and
Router C in AS65009. Between Router A and Router B, Router A and Router C are eBGP connections,
and between Router B and Router C is an iBGP connection.
Network diagram
Figure 1-18 Network diagram for BGP path selection (on routers)

2) Configure BGP connections
1-39
[RouterA] bgp 65008
[RouterA-bgp] network 8.0.0.0 255.0.0.0
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp] network 9.1.1.0 255.255.255.0
[RouterB-bgp] quit
[RouterC] bgp 65009
[RouterC-bgp] network 9.1.1.0 255.255.255.0
[RouterC-bgp] quit


*> 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, you can find two routes to the destination 9.1.1.0/24 are available, and the route
with the next hop 200.1.1.1 is the best route because Router B has a smaller router ID than Router C.
3) Configure load balancing
[RouterA] bgp 65008
[RouterA-bgp] balance 2
[RouterA-bgp] quit

1-40

*> 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, you can find two routes to the destination 9.1.1.0/24 are available, and both of
them are best routes.
4) Configure the MED attribute.
# Configure the default MED value for Router B.
[RouterB] bgp 65009
[RouterB-bgp] default med 100


*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.2.1 0 0 65009i
* 200.1.1.1 100 0 65009i
From the above information, you can find the route with the next hop 200.1.2.1 is the best route,
because its MED (0) is smaller than the MED (100) of the other route with the next hop 200.1.1.1
(Router B).
BGP Community Configuration
Router B establishes eBGP connections with Router A and Router C. Configure No_Export community
attribute on Router A to make routes from AS 10 not advertised by AS 20 to any other AS.
1-41
Network diagram
Figure 1-19 Network diagram for BGP community configuration (on routers)

2) Configure eBGP connections.
[RouterA] bgp 10
[RouterA-bgp] network 9.1.1.0 255.255.255.0
[RouterA-bgp] quit
[RouterB] bgp 20
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterC-bgp] quit
# Display BGP routing table information on Router B.

[RouterB] display bgp routing-table 9.1.1.0

Paths: 1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:
1-42
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
Router B has advertised the route to Router C in AS 30.

# Display BGP routing table information on Router C.

*> 9.1.1.0/24 200.1.3.1 0 20 10i
Router C has learned the route to the destination 9.1.1.0/24 from Router B.
3) Configure BGP community attribute
# Configure a routing policy.
[RouterA] route-policy comm_policy permit node 0
[RouterA-route-policy] apply community no-export
[RouterA-route-policy] quit
# Apply the routing policy.

[RouterA] bgp 10
[RouterA-bgp] peer 200.1.2.2 route-policy comm_policy export
[RouterA-bgp] peer 200.1.2.2 advertise-community


From : 200.1.2.1 (1.1.1.1)
Community : No-Export
AS-path : 10
Origin : igp
1-43
Not advertised to any peers yet
You can find the No-export community attribute in the above output. In this case, the route of 9.1.1.0/24
is not available in the routing table of Router C.
BGP Route Reflector Configuration
In the following figure, all routers run BGP.

z Between Router A and Router B is an eBGP connection, between Router C and Router B, Router
C and Router D are iBGP connections.
z Router C is a route reflector with clients Router B and D.
z Router D can learn route 1.0.0.0/8 from Router C.
Network diagram
Figure 1-20 Network diagram for BGP route reflector configuration

2) Configure BGP connections (omitted)
[RouterA] bgp 100

[RouterA-bgp] network 1.0.0.0
[RouterA-bgp] quit
[RouterB] bgp 200
[RouterB-bgp] peer 193.1.1.1 next-hop-local
[RouterB-bgp] quit
1-44
[RouterC] bgp 200
[RouterC-bgp] quit
[RouterD] bgp 200
[RouterD-bgp] quit
3) Configure the route reflector
# Configure Router C as the route reflector.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.2 reflect-client
[RouterC-bgp] peer 194.1.1.2 reflect-client
[RouterC-bgp] quit
# Display the BGP routing table on Router B.

*> 1.0.0.0 192.1.1.1 0 0 100i
# Display the BGP routing table on Router D.

[RouterD] display bgp routing-table

i 1.0.0.0 193.1.1.2 0 100 0 100i
Router D learned the route 1.0.0.0/8 from Router C.
1-45
BGP Confederation Configuration
To reduce iBGP connections in AS 200, split it into three sub-ASs, AS65001, AS65002 and AS65003.
Routers in AS65001 are fully meshed.
Network diagram
Figure 1-21 Network diagram for BGP confederation configuration
Device Interface IP address Device Interface IP address

Router A S2/1 200.1.1.1/24 Router D Eth1/0 10.1.3.2/24
Eth1/0 10.1.1.1/24 Eth1/1 10.1.5.1/24
Eth1/1 10.1.2.1/24 Router E Eth1/0 10.1.4.2/24
Eth1/2 10.1.3.1/24 Eth1/1 10.1.5.2/24
Eth1/3 10.1.4.1/24 Router F Eth1/0 9.1.1.1/24
Router B Eth1/0 10.1.1.2/24 S2/0 200.1.1.2/24
Router C Eth1/0 10.1.2.2/24

2) Configure the BGP confederation
[RouterA] bgp 65001
[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp] peer 10.1.1.2 next-hop-local
[RouterA-bgp] quit
[RouterB] bgp 65002
1-46
[RouterB-bgp] confederation id 200
[RouterB-bgp] confederation peer-as 65001 65003
[RouterB-bgp] quit
[RouterC] bgp 65003
[RouterC-bgp] confederation id 200
[RouterC-bgp] confederation peer-as 65001 65002
[RouterC-bgp] quit
3) Configure iBGP connections in AS65001.
[RouterA] bgp 65001
[RouterA-bgp] quit
[RouterD] bgp 65001
[RouterD-bgp] confederation id 200
[RouterD-bgp] quit
# Configure Router E.
[RouterE] bgp 65001
[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] confederation id 200
[RouterE-bgp] peer 10.1.4.1 as-number 65001
[RouterE-bgp] quit
4) Configure the eBGP connection between AS100 and AS200.
[RouterA] bgp 65001
[RouterA-bgp] quit
# Configure Router F.
<RouterF> system-view
[RouterF] bgp 100
[RouterF-bgp] router-id 6.6.6.6
1-47
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] network 9.1.1.0 255.255.255.0
[RouterF-bgp] quit
5) Verify the configuration.

*>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,
# Display BGP routing table information on Router D.


*>i 9.1.1.0/24 10.1.3.1 0 100 0 100i

[RouterD] display bgp routing-table 9.1.1.0

1-48

From : 10.1.3.1 (1.1.1.1)
AS-path : 100
Origin : igp
State : valid, internal, best,
BGP Path Selection Configuration
z In the figure below, all routers run BGP. Between Router A and Router B, and between Router A
and Router C are eBGP connections. Between Router B and Router D, and between Router D and
Router C are iBGP connections.
z OSPF is the IGP protocol in AS 200.
z Configure routing policies to make Router D give priority to the route 1.0.0.0/8 learned from Router
C.
Network diagram
Figure 1-22 Network diagram for BGP path selection configuration

Router A Eth1/0 1.0.0.0/8 Router D S2/0 195.1.1.1/24
S2/0 192.1.1.1/24 S2/1 194.1.1.1/24
S2/1 193.1.1.1/24 Router C S2/0 195.1.1.2/24
Router B S2/0 192.1.1.2/24 S2/1 193.1.1.2/24
S2/1 194.1.1.2/24

2) Configure OSPF on routers B, C and D
[RouterB] ospf
1-49
[RouterB-ospf] area 0
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterC] ospf
[RouterC-ospf] area 0
[RouterC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
[RouterD] ospf
[RouterD-ospf] area 0
[RouterD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] quit
[RouterD-ospf-1] quit
[RouterA] bgp 100
# Inject network 1.0.0.0/8 into the BGP routing table of Router A.

[RouterA-bgp] quit
[RouterB] bgp 200
[RouterB-bgp] quit
# Configure Router C
[RouterC] bgp 200
[RouterC-bgp] quit
# Configure Router D
[RouterD] bgp 200
1-50
[RouterD-bgp] quit
4) Configure different attribute values for the route 1.0.0.0/8 to make Router D give priority to the route
learned from Router C.
z Specify a higher MED value for the route 1.0.0.0/8 advertised to 192.1.1.2 to make Router D give
priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterA-acl-basic-2000] quit
# Define routing policy apply_med_50 that sets the MED value of route 1.0.0.0/8 to 50, and routing
policy apply_med_100 that sets the MED value of route 1.0.0.0/8 to 100.
[RouterA] route-policy apply_med_50 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 50
[RouterA] route-policy apply_med_100 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 100
# Apply routing policy apply_med_50 to the route advertised to 193.1.1.2 (Router C), and apply routing
policy apply_med_100 to the route advertised to 192.1.1.2 (Router B).
[RouterA] bgp 100
[RouterA-bgp] peer 193.1.1.2 route-policy apply_med_50 export
[RouterA-bgp] peer 192.1.1.2 route-policy apply_med_100 export
[RouterA-bgp] quit


Status codes: * - valid, > - best, d damped,
h history, i internal, s suppressed, S Stale
Origin : i IGP, e EGP, ? incomplete
*>i 1.0.0.0 193.1.1.1 50 100 0 100i

* i 192.1.1.1 100 100 0 100i
The route 1.0.0.0/8 learned from Router C is the optimal.

z Specify different local preferences for route 1.0.0.0/8 on Router B and C to make Router D give
priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8 on Router C.
[RouterC] acl number 2000
[RouterC-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterC-acl-basic-2000] quit
1-51
# Define routing policy localpref on Router C to set the local preference of route 1.0.0.0/8 to 200 (the
default is 100).
[RouterC] route-policy localpref permit node 10
[RouterC-route-policy] if-match acl 2000
[RouterC-route-policy] apply local-preference 200
[RouterC-route-policy] quit
# Apply the routing policy localpref to the route from the peer 193.1.1.1 on Router C.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.1 route-policy localpref import
[RouterC-bgp] quit


*>i 1.0.0.0 193.1.1.1 0 200 0 100i

* i 192.1.1.1 0 100 0 100i
The route 1.0.0.0/8 learned from Router C is the optimal.
BGP Configuration Examples (on Switches)

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.
Network diagram
Figure 1-23 Network diagram for BGP basic configuration (on switches)
AS 65008 AS 65009
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
1-52

2) Configure iBGP connections
# Configure Switch B.
[SwitchB] bgp 65009
[SwitchB-bgp] router-id 2.2.2.2
[SwitchB-bgp] peer 9.1.1.2 as-number 65009
[SwitchB-bgp] quit
# Configure Switch C.
[SwitchC] bgp 65009
[SwitchC-bgp] router-id 3.3.3.3
[SwitchC-bgp] peer 9.1.3.1 as-number 65009
[SwitchC-bgp] quit
# Configure Switch D.
<SwitchD> system-view
[SwitchD] bgp 65009
[SwitchD-bgp] router-id 4.4.4.4
[SwitchD-bgp] peer 9.1.1.1 as-number 65009
[SwitchD-bgp] quit
# Configure Switch A.
[SwitchA] bgp 65008
[SwitchA-bgp] router-id 1.1.1.1
[SwitchA-bgp] peer 200.1.1.1 as-number 65009

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

[SwitchB] display bgp peer

1-53
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

*> 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

i 8.0.0.0 200.1.1.2 0 100 0 65008i
1-54
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.


*>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 ?
1-55
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-24 Network diagram for BGP and IGP synchronization

2) Configure OSPF (omitted)
[SwitchA] bgp 65008

[SwitchA-bgp] network 8.1.1.0 24
[SwitchA-bgp] quit
1-56
[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?
*> 9.1.2.0/24 3.1.1.1 2 0 65009?
# Configure OSPF to redistribute routes from BGP on Switch B.

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

<SwitchC> display ip routing-table
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
1-57
[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 65009?
# Use ping for verification.

[SwitchA] ping -a 8.1.1.1 9.1.2.1

0.00% packet loss
BGP Load Balancing and MED Attribute Configuration
z Configure BGP on all switches; Switch A is in AS65008, and Switch B and C in AS65009.
z Between Switch A and B, and between Switch A and C are eBGP connections, and an iBGP
connection is between Switch B and C.
1-58
Network diagram
Figure 1-25 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

[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
[SwitchC-bgp] network 9.1.1.0 255.255.255.0
[SwitchC-bgp] quit
# Display the routing table on Switch A.

1-59

*> 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
Two routes to 9.1.1.0/24 are available, and the one with the next hop being 200.1.1.1 is the optimal
because the ID of Switch B is smaller.
3) Configure loading balancing
[SwitchA] bgp 65008
[SwitchA-bgp] balance 2
[SwitchA-bgp] quit


*> 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, and both are the optimal.
4) Configure MED
# Configure the default MED of Switch B.
[SwitchB] bgp 65009
[SwitchB-bgp] default med 100


1-60
*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.2.1 0 0 65009i
* 200.1.1.1 100 0 65009i
From the above information, you can find the route with the next hop 200.1.2.1 is the best route,
because its MED (0) is smaller than the MED (100) of the other route with the next hop 200.1.1.1
(Switch B).
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-26 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
1-61
[SwitchB-bgp] quit
[SwitchC] bgp 30
[SwitchC-bgp] quit
# Display the BGP routing table on Switch B.

[SwitchB] display bgp routing-table 9.1.1.0


From : 200.1.2.1 (1.1.1.1)
AS-path : 10
Origin : igp
Advertised to such 1 peers:
200.1.3.2
Switch B advertised routes to Switch C in AS30.

# Display the routing table on Switch C.

*> 9.1.1.0/24 200.1.3.1 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
1-62
[SwitchA-bgp] peer 200.1.2.2 advertise-community
# Display the routing table on Switch B.


From : 200.1.2.1 (1.1.1.1)
Community : No-Export
AS-path : 10
Origin : igp
The route 9.1.1.0/24 is not available in the routing table of Switch C.
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-27 Network diagram for BGP route reflector configuration

Route
Reflector
Vlan-int100
1.1.1.1/8
193.1.1.1/24 194.1.1.1/24
Vlan-int200 Switch C
192.1.1.1/24
Switch A

192.1.1.2/24 193.1.1.2/24 194.1.1.2/24
AS 100
AS 200 Switch D
Switch B

1-63
[SwitchA] bgp 100

[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-64
*> 1.0.0.0 192.1.1.1 0 0 100i
# 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-28 Network diagram for BGP confederation configuration (on switches)
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

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-65
[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
1-66
[SwitchE] bgp 65001
[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] 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)
AS-path : (65001) 100
Origin : igp
State : valid, external-confed, best,
1-67

*>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)
AS-path : 100
Origin : igp
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-68
Network diagram
Figure 1-29 Network diagram for BGP path selection configuration

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
Vlan-int300 194.1.1.2/24
1) Configure IP addresses for interfaces (omitted).

2) Configure OSPF on Switch B, C, and D.
[SwitchB] ospf
[SwitchB-ospf] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchC] ospf
[SwitchC-ospf] area 0
[SwitchC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] quit
[SwitchC-ospf-1] quit
[SwitchD] ospf
[SwitchD-ospf] area 0
[SwitchD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[SwitchD-ospf-1-area-0.0.0.0] quit
[SwitchD-ospf-1] quit
1-69
[SwitchA] bgp 100
# Inject network 1.0.0.0/8 to the BGP routing table on Switch A.

[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-70
[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-71
* 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 peers AS number.

2) Use the display bgp peer command to verify the peers 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-72
Table of Contents
1 IS-IS Configuration 1-1

IS-IS Overview 1-1
Basic Concepts1-2
IS-IS Area 1-3
IS-IS Network Type 1-5
IS-IS PDU Format1-7
Supported IS-IS Features1-12
IS-IS Configuration Task List 1-16
Configuring IS-IS Basic Functions 1-16
Enabling IS-IS1-17
Configuring the IS Level and Circuit Level 1-17
Configuring the Network Type of an Interface as P2P 1-18
Configuring IS-IS Routing Information Control 1-18
Configuring IS-IS Link Cost 1-18
Specifying a Priority for IS-IS 1-20
Configuring the Maximum Number of Equal Cost Routes 1-20
Configuring IS-IS Route Summarization 1-20
Advertising a Default Route1-21
Configuring IS-IS Route Redistribution 1-21
Configuring IS-IS Route Filtering1-22
Configuring IS-IS Route Leaking1-23
Tuning and Optimizing IS-IS Networks 1-23
Specifying Intervals for Sending IS-IS Hello and CSNP Packets1-23
Specifying the IS-IS Hello Multiplier 1-24
Configuring a DIS Priority for an Interface1-24
Disabling an Interface from Sending/Receiving IS-IS Packets 1-25
Disabling Hello Source Address Check for a PPP interface 1-25
Enabling an Interface to Send Small Hello Packets1-26
Configuring LSP Parameters1-26
Configuring SPF Parameters 1-30
Setting the LSDB Overload Bit 1-30
Configuring IS-IS Authentication1-30
Configuring Neighbor Relationship Authentication1-31
Configuring Area Authentication1-31
Configuring Routing Domain Authentication 1-31
Configuring System ID to Host Name Mappings 1-32
Configuring a Static System ID to Host Name Mapping 1-32
Configuring Dynamic System ID to Host Name Mapping 1-32
i
Configuring IS-IS GR 1-33
Enabling the Logging of Neighbor State Changes1-34
Enabling IS-IS SNMP Trap 1-34
Displaying and Maintaining IS-IS 1-34
IS-IS Configuration Examples (on Routers)1-35
IS-IS Basic Configuration 1-35
DIS Election Configuration 1-40
Configuring IS-IS Route Redistribution 1-44
IS-IS GR Configuration Example1-48
IS-IS Authentication Configuration Example 1-49
IS-IS Configuration Example (on Switches)1-52
IS-IS Basic Configuration 1-52
DIS Election Configuration 1-57
IS-IS-based Graceful Restart Configuration Example1-61
IS-IS Authentication Configuration Example 1-62
ii
1 IS-IS Configuration
When configuring IS-IS, go to these sections for information you are interested in:
z IS-IS Overview
z IS-IS Configuration Task List
z Configuring IS-IS Basic Functions
z Configuring IS-IS Routing Information Control
z Tuning and Optimizing IS-IS Networks
z Configuring IS-IS Authentication
z Configuring System ID to Host Name Mappings
z Configuring IS-IS GR
z Enabling the Logging of Neighbor State Changes
z Enabling IS-IS SNMP Trap
z Displaying and Maintaining IS-IS
z IS-IS Configuration Examples (on Routers)
z IS-IS Configuration Example (on Switches)
routing protocols.
IS-IS Overview
Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol designed by the
International Organization for Standardization (ISO) to operate on the connectionless network protocol
(CLNP).
The IS-IS routing protocol has been modified and extended in RFC 1195 by the International Engineer
Task Force (IETF) for application in both TCP/IP and OSI reference models, and the new one is called
Integrated IS-IS or Dual IS-IS.
IS-IS is an Interior Gateway Protocol (IGP) used within an Autonomous System. It adopts the Shortest
Path First (SPF) algorithm for route calculation.
1-1
Basic Concepts
IS-IS terminology
z Intermediate system (IS). An IS, similar to a router in TCP/IP, is the basic unit in IS-IS to generate
and propagate routing information. In the following text, an IS refers to a router.
z End system (ES). An ES refers to a host system in TCP/IP. ISO defines the ES-IS protocol for
communication between an ES and an IS, and therefore an ES does not participate in the IS-IS
processing.
z Routing domain (RD). A group of ISs exchanges routing information with each other using the
same routing protocol in a routing domain.
z Area. An area is a unit in a routing domain. The IS-IS protocol allows a routing domain to be divided
into multiple areas.
z Link State Database (LSDB). All link states in the network forms the LSDB. There is at least one
LSDB in each IS. The IS uses the SPF algorithm and LSDB to generate its own routes.
z Link State Protocol Data Unit (LSPDU) or Link State Packet (LSP). Each IS can generate an LSP
which contains all the link state information of the IS.
z Network Protocol Data Unit (NPDU). An NPDU is a network layer protocol packet in OSI, which is
equivalent to an IP packet in TCP/IP.
z Designated IS. On a broadcast network, the designated router is also known as the designated IS.
z Network service access point (NSAP). An NSAP is an OSI network layer address. It identifies an
abstract network service access point and describes the network address in the OSI reference
model.
IS-IS address format
1) NSAP
As shown in Figure 1-1, an NSAP address consists of the Initial Domain Part (IDP) and the Domain
Specific Part (DSP). The IDP is equal to the network ID of an IP address, and the DSP is equal to the
subnet and host ID.
The IDP includes the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI).
The DSP includes the High Order Part of DSP (HO-DSP), System ID and SEL, where the HO-DSP
identifies the area, the System ID identifies the host, and the SEL identifies the type of service.
The IDP and DSP are variable in length. The length of an NSAP address varies from 8 bytes to 20
bytes.
Figure 1-1 NSAP address format
2) Area address
The area address comprises the IDP and the HODSP of the DSP, which identify the area and the
routing domain. Different routing domains cannot have the same area address.
Generally, a router only needs one area address, and all nodes in the same routing domain must share
the same area address. However, a router can have three area addresses at most to support smooth
area merging, partitioning and switching.
1-2
3) System ID
A system ID identifies a host or router uniquely. It has a fixed length of 48 bits (6 bytes).
The system ID of a device can be generated from the Router ID. For example, a router uses the IP
address 168.10.1.1 of Loopback 0 as the Router ID, and the system ID in IS-IS can be obtained in the
following way:
z Extend each decimal number of the IP address to 3 digits by adding 0s from the left, like
168.010.001.001;
z Divide the extended IP address into 3 sections with 4 digits in each section to get the system ID
1680.1000.1001.
There are other methods to define a system ID. The principle is to make sure it can uniquely identify a
host or router.
4) SEL
The NSAP Selector (SEL), or the N-SEL, is similar to the protocol identifier in IP. Different transport
layer protocols correspond to different SELs. All SELs in IP are 00.
NET
A network entity title (NET) indicates the network layer information of an IS and does not include
transport layer information. It is a special NSAP address with the SEL being 0. Therefore, the length of
the NET is equal to the NSAP and is in the range 8 bytes to 20 bytes.
Generally, a router only needs one NET, but it can have three NETs at most for smooth area merging
and partitioning. When you configure multiple NETs, make sure their system IDs are the same.
For example, a NET is ab.cdef.1234.5678.9abc.00, where,
Area = ab.cdef, System ID = 1234.5678.9abc, and SEL = 00.
IS-IS Area
Two-level hierarchy
IS-IS has a two-level hierarchy to support large scale networks. A large scale routing domain is divided
into multiple Areas. A Level-1 router forwards routes within an area and a Level-2 router forwards routes
between areas.
Level-1 and Level-2
1) Level-1 router
A Level-1 router establishes neighbor relationships with Level-1 and Level-1-2 routers in the same area.
The LSDB maintained by the Level-1 router contains the local area routing information. It directs the
packets destined for an outside area to the nearest Level-1-2 router.
2) Level-2 router
A Level-2 router establishes neighbor relationships with the Level-2 and Level-1-2 routers in the same
or in different areas. It maintains a Level-2 LSDB which contains inter-area routing information. All the
Level-2 and Level-1-2 routers must be contiguous to form the backbone of a routing domain.
3) Level-1-2 router
A router with both Level-1 and Level-2 router functions is a Level-1-2 router. It can establish Level-1
neighbor relationships with the Level-1 and Level-1-2 routers in the same area, or establish Level-2
neighbor relationships with the Level-2 and Level-1-2 routers in different areas. A Level-1 router must
1-3
be connected to other areas through a Level-1-2 router. The Level-1-2 router maintains two LSDBs,
where the Level-1 LSDB is for routing within the area, and the Level-2 LSDB is for routing between
areas.
z The Level-1 routers in different areas can not establish neighbor relationships.
z The neighbor relationship establishment of Level-2 routers has nothing to do with area.
Figure 1-2 shows an IS-IS network topology. Area 1 comprises a set of Level-2 routers and is the
backbone. The other four areas are non-backbone areas connected to the backbone through Level-1-2
routers.
Figure 1-2 IS-IS topology
Figure 1-3 shows another IS-IS topology. The Level-1-2 routers connect to the Level-1 and Level-2
routers, and form the IS-IS backbone together with the Level-2 routers. There is no area defined as the
backbone in this topology. The backbone comprises all contiguous Level-2 and Level-1-2 routers which
can reside in different areas.
1-4
Figure 1-3 IS-IS topology
The IS-IS backbone does not need to be a specific Area.
Both the IS-IS Level-1 and Level-2 routers use the SPF algorithm to generate the shortest path tree
(SPT).
Routing method
A Level-1 router makes routing decisions based on the system ID. If the destination is not in the area,
the packet is forwarded to the nearest Level-1-2 router.
A Level-2 router routes packets across areas according to the area address.
Route leaking
An IS-IS routing domain is comprised of only one Level-2 area and multiple Level-1 areas. A Level-1
area consists of a group of Level-1 routers and is connected with a Level-2 area rather than other
Level-1 areas.
The routing information of a Level-1 area is sent to the Level-2 area through the Level-1-2 router.
Therefore, the Level-2 router knows the routing information of the entire IS-IS routing domain but does
not share the information of other Level-1 areas and the Level-2 area with the Level-1 area by default.
Since a Level-1 router simply sends packets destined for other areas to the nearest Level-1-2 router,
this may cause that the best paths cannot be selected.
To solve this problem, route leaking was introduced. A Level-2 router can advertise Level-2 routing
information to a specified Level-1 area. By having the routing information of other areas, a Level-1
router in the area can make a better routing decision for a packet to another area.
IS-IS Network Type
Network type
IS-IS supports two network types:

z Broadcast network, such as Ethernet, Token-Ring.
z Point-to-point network, such as PPP, HDLC.
1-5
For a Non-Broadcast Multi-Access (NBMA) interface, such as an ATM interface, you need to configure
subinterfaces for it and configure the interface type for the subinterfaces as point-to-point or broadcast.
IS-IS cannot run on point to multipoint (P2MP) links.
DIS and pseudonodes
On an IS-IS broadcast network, a router is elected as the Designated Intermediate System (DIS).
The Level-1 and Level-2 DISs are elected respectively. You can assign different priorities for different
level DIS elections. The higher a routers priority is, the more likelihood the router becomes the DIS. If
there are multiple routers with the same highest DIS priority, the one with the highest SNPA
(Subnetwork Point of Attachment) address (MAC address on a broadcast network) will be elected. A
router can be the DIS for different levels.
As shown in Figure 1-4, the same level routers on a network including non-DIS routers establish
adjacencies with each other.
Figure 1-4 DIS in the IS-IS broadcast network
The DIS creates and updates pseudonodes as well as generates their LSPs to describe all routers on
the network.
A pseudonode represents a virtual node on the broadcast network. It is not a real router. In IS-IS, it is
identified by the system ID of the DIS and a one-byte Circuit ID (a non zero value).
Using pseudonodes can reduce the resources consumed by SPF and simplify network topology.
On IS-IS broadcast networks, all routers are adjacent with each other. However, the DIS is responsible
for the synchronization of their LSDBs.
1-6
IS-IS PDU Format
PDU header format
IS-IS packets are encapsulated into link layer frames. The Protocol Data Unit (PDU) consists of two
parts, the headers and the variable length fields, where the headers comprise the PDU common header
and the PDU specific header. All PDUs have the same PDU common header, while the specific headers
vary by PDU type. The following figure shows the PDU format.
Figure 1-5 PDU format
Common header format
Figure 1-6 shows the PDU common header format.

Figure 1-6 PDU common header format
No. of Octets
Intradomain routing protocol discriminator 1
Length indicator 1
Version/Protocol ID extension 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1
Maximum area address 1
z Intradomain Routing Protocol Discriminator: Set to 0x83.

z Length Indicator: Length of the PDU header in bytes, including both common and specific headers.
z Version/Protocol ID Extension: Set to 1(0x01).
z ID Length: Length of the NSAP address and NET ID.
z R(Reserved): Set to 0.
z PDU Type: For details, refer to Table 1-1.
z Version: Set to 1(0x01).
z Maximum Area Address: Maximum number of area addresses supported.
Table 1-1 PDU type
Type PDU Type Acronym

15 Level-1 LAN IS-IS hello PDU L1 LAN IIH
16 Level-2 LAN IS-IS hello PDU L2 LAN IIH
17 Point-to-Point IS-IS hello PDU P2P IIH
18 Level-1 Link State PDU L1 LSP
20 Level-2 Link State PDU L2 LSP
24 Level-1 Complete Sequence Numbers PDU L1 CSNP
25 Level-2 Complete Sequence Numbers PDU L2 CSNP
1-7
Type PDU Type Acronym
26 Level-1 Partial Sequence Numbers PDU L1 PSNP
27 Level-2 Partial Sequence Numbers PDU L2 PSNP
Hello
Hello packets are used by routers to establish and maintain neighbor relationships. A hello packet is
also called an IS-to-IS hello PDU (IIH). For broadcast networks, the Level-1 routers use the Level-1
LAN IIHs; and the Level-2 routers use the Level-2 LAN IIHs. The P2P IIHs are used on point-to-point
networks.
Figure 1-7 illustrates the hello packet format in broadcast networks, where the blue fields are the
common header.
Figure 1-7 L1/L2 LAN IIH format
z Reserved/Circuit Type: The first 6 bits are reserved with a value of 0. The last 2 bits indicate the
router type. 00 means reserved, 01 indicates L1, 10 indicates L2, and 11 indicates L1/2.
z Source ID: System ID of the router advertising the hello packet.
z Holding Time: If no hello packets are received from the neighbor within the holding time, the
neighbor is considered down.
z PDU Length: Total length of the PDU in bytes.
z Priority: DIS priority.
z LAN ID: Includes the system ID and a one-byte pseudonode ID.
Figure 1-8 shows the hello packet format on the point-to-point networks.
1-8
Figure 1-8 P2P IIH format
Instead of the priority and LAN ID fields in the LAN IIH, the P2P IIH has a Local Circuit ID field.
LSP packet format
The Link State PDUs (LSP) carry link state information. LSP involves two types: Level-1 LSP and
Level-2 LSP. The Level-2 LSPs are sent by the Level-2 routers, and the Level-1 LSPs are sent by the
Level-1 routers. The level-1-2 router can send both types of LSPs.
The two types of LSPs have the same format, as shown in Figure 1-9.
Figure 1-9 L1/L2 LSP format
1-9
z PDU Length: Total length of the PDU in bytes.
z Remaining Lifetime: LSP remaining lifetime in seconds.
z LSP ID: Consists of the system ID, the pseudonode ID (one byte) and the LSP fragment number
(one byte).
z Sequence Number: LSP sequence number.
z Checksum: LSP checksum.
z P (Partition Repair): Only for L2 LSPs. It indicates whether the router supports partition repair.
z ATT (Attachment): Generated by a L1/L1 router for L1 LSPs only. It indicates that the router
generating the LSP is connected to multiple areas.
z OL (LSDB Overload): Indicates that the LSDB is not complete because the router runs out of
memory. In this case, other routers will not send packets to the overloaded router, except packets
destined to the networks directly connected to the router. For example, in Figure 1-10, Router A
forwards packets to Router C through Router B. Once other routers know the OL field of LSPs from
Router B is set to 1, Router A will send packets to Router C via Router D and Router E, but still
send to Router B packets destined to the network directly connected to Router B.
Figure 1-10 LSDB overload
z IS Type: Type of the router generating the LSP.
SNP format
A sequence number PDU (SNP) acknowledges the latest received LSPs. It is similar to an
Acknowledge packet, but more efficient.
SNP involves Complete SNP (CSNP) and Partial SNP (PSNP), which are further divided into Level-1
CSNP, Level-2 CSNP, Level-1 PSNP and Leval-2 PSNP.
CSNP covers the summary of all LSPs in the LSDB to synchronize the LSDB between neighboring
routers. On broadcast networks, CSNP is sent by the DIS periodically (10s by default). On point-to-point
networks, CSNP is only sent during the first adjacency establishment.
The CSNP packet format is shown in Figure 1-11.
1-10
Figure 1-11 L1/L2 CSNP format
PSNP only contains the sequence numbers of one or multiple latest received LSPs. It can acknowledge
multiple LSPs at one time. When LSDBs are not synchronized, a PSNP is used to request new LSPs
from neighbors.
Figure 1-12 shows the PSNP packet format.
Figure 1-12 L1/L2 PSNP format
No. of Octets
Intradomain routing protocol discriminator 1
Length indicator 1
Version/Protocol ID extension 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1
Maximum area address 1
PDU length 2
Source ID ID length+1
Variable length fields
CLV
The variable fields of PDU comprise multiple Code-Length-Value (CLV) triplets. Figure 1-13 shows the
CLV format.
1-11
Figure 1-13 CLV format
Table 1-2 shows that different PDUs contain different CLVs.
Table 1-2 CLV name and the corresponding PDU type
CLV Code Name PDU Type

1 Area Addresses IIH, LSP
2 IS Neighbors (LSP) LSP
4 Partition Designated Level2 IS L2 LSP
6 IS Neighbors (MAC Address) LAN IIH
7 IS Neighbors (SNPA Address) LAN IIH
8 Padding IIH
9 LSP Entries SNP
10 Authentication Information IIH, LSP, SNP

128 IP Internal Reachability Information LSP
129 Protocols Supported IIH, LSP
130 IP External Reachability Information L2 LSP

131 Inter-Domain Routing Protocol Information L2 LSP
132 IP Interface Address IIH, LSP
Code 1 to 10 of CLV are defined in ISO 10589 (code 3 and 5 are not shown in the table), and others are
defined in RFC 1195.
Supported IS-IS Features
Multiple instances and processes
IS-IS supports multiple instances and processes. Multiple processes allow a IS-IS process to work in
concert with a group of interfaces. This means that a router can run multiple IS-IS processes, and each
process corresponds to a unique group of interfaces.
For routers supporting VPN, each IS-IS process is associated with a VPN instance. Thus, the VPN
instance is also associated with interfaces corresponding to the process.
1-12
Hot standby
For detailed information about IS-IS hot standby, refer to HA configuration in the System Volume.
A distributed router supports IS-IS Hot Standby (HSB). The data is copied from the Active Main Board
(AMB) to the Standby Main Board (SMB). Whenever the AMB is down, the SMB can switch to the active
status to run IS-IS.
There are two kinds of IS-IS HSB. One is IS-IS data synchronization backup. After switching from AMB
to SMB, IS-IS can work immediately.
The other HSB is to backup only the configuration information of IS-IS during the switching from AMB to
SMB. After the graceful restart (GR), the IS-IS router will send requests to neighbors to synchronize the
LSDB.
IS-IS Graceful Restart
For detailed GR information , refer to GR Configuration in the System Volume.
After an IS-IS GR Restarter restarts IS-IS, it needs to complete the following two tasks to synchronize
the LSDB with its neighbors.
z To obtain effective IS-IS neighbor information without changing adjacencies.
z To obtain the LSDB contents.
After the restart, the GR Restarter will send an OSPF GR signal to its neighbors to keep the adjacencies.
After receiving the responses from neighbors, the GR Restarter can restore the neighbor table.
After reestablishing neighborships, the GR Restarter will synchronize the LSDB and exchange routing
information with all adjacent GR capable neighbors. After that, the GR Restarter will update its own
routing table and forwarding table based on the new routing information and remove the stale routes. In
this way, the IS-IS routing convergence is complete.
IS-IS TE
IS-IS Traffic Engineering (TE) creates and maintains the Label Switched Path (LSP).
When creating the Constraint-based Routed LSP (CR LSP), MPLS needs to get the traffic attribute
information of all links in the local area. The Traffic Engineering information of links is obtained from
IS-IS.
For detailed configuration of the IS-IS TE, refer to MPLS TE Configuration in the MPLS Volume.
1-13
Management tag
Management tag simplifies routing information management by carrying the management information
of the IP address prefixes (to control route redistribution from other routing protocols) and BGP
community and extended community attributes.
LSP fragment extension
IS-IS advertises link state information by flooding LSPs. One LSP carries a limited amount of link state
information; therefore, IS-IS fragments LSPs. Each LSP fragment is uniquely identified by a
combination of the System ID, Pseudonode ID (0 for a common LSP or a non-zero value for a
Pseudonode LSP), and LSP Number (LSP fragment number) of the node or pseudo node that
generated the LSP. The one-byte LSP Number field, allowing a maximum of only 256 fragments to be
generated by an IS-IS router, limits the amount of link information that the IS-IS router can advertise.
The LSP fragment extension feature allows an IS-IS router to generate more LSP fragments. Up to 50
additional virtual systems can be configured on the router, and each virtual system is capable of
generating 256 LSP fragments to enable the IS-IS router to generate up to 13056 LSP fragments.
1) Terms
z Originating System
It is the router actually running IS-IS. After LSP fragment extension is enabled, additional virtual
systems can be configured for the router. Originating system is the actual IS-IS process that originally
runs.
z System ID: System ID of the originating system.
z Additional System ID
Additional virtual system IDs are configured for the IS-IS router after LSP fragment extension is enabled.
Each additional system ID can generate 256 LSP fragments. Both the additional system ID and the
system ID must be unique in the entire routing domain.
z Virtual System
A virtual system is identified by an additional system ID and generates extended LSP fragments.
z Original LSP
It is the LSP generated by the originating system. The system ID in its LSP ID field is the system ID of
the originating system.
z Extended LSP
Extended LSPs are generated by virtual systems. The system ID in its LSP ID field is the virtual system
ID.
After additional system IDs are configured, an IS-IS router can advertise more link state information in
extended LSP fragments. Each virtual system can be considered a virtual router. An extended LSP
fragment is advertised by a virtual system identified by an additional system ID.
2) Operation modes
The LSP fragment extension feature operates in two modes:
z Mode-1: Applicable to a network where some routers do not support LSP fragment extension. In
this mode, adjacencies are formed between the originating system and virtual systems, with the
link cost from the originating system to each virtual system as 0. Thus, each virtual system acts as
a router connected to the originating system in the network, but the virtual systems are reachable
through the originating system only. Therefore, the IS-IS routers not supporting LSP fragment
1-14
extension can operate normally without modifying the extended LSP fragments received, but some
limitation is imposed on the link state information in the extended LSP fragments advertised by the
virtual systems.
z Mode-2: Applicable to a network where all the routers support LSP fragment extension. In this
mode, all the IS-IS routers know which virtual system belongs to which originating system;
therefore, no limitation is imposed on the link state information of the extended LSP fragments
advertised by the virtual systems.
The operation mode of LSP fragment extension is configured based on area and routing level. Mode-1
allows the routers supporting and not supporting LSP fragment extension to interoperate with each
other, but it restricts the link state information in the extended fragments. Mode-2 does not restrict the
link state information in the extended fragments, and is recommended for an area where all the routers
are at the same routing level and support LSP fragment extension.
Dynamic host name mapping mechanism
The dynamic host name mapping mechanism provides the mappings between the host names and the
system IDs for the IS-IS routers. The dynamic host name information is announced in the dynamic host
name CLV of an LSP.
This mechanism also provides the mapping between a host name and the DIS of a broadcast network,
which is announced in the dynamic host name TLV of a pseudonode LSP.
A host name is easier to remember than a system ID. After enabling this feature on the router, you can
see the host names instead of system IDs using the display command.
z ISO 10589 ISO IS-IS Routing Protocol

z ISO 9542 ES-IS Routing Protocol
z ISO 8348/Ad2 Network Services Access Points
z RFC 1195 - Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
z RFC 2763 - Dynamic Hostname Exchange Mechanism for IS-IS
z RFC 2966 - Domain-wide Prefix Distribution with Two-Level IS-IS
z RFC 2973 - IS-IS Mesh Groups
z RFC 3277 - IS-IS Transient Blackhole Avoidance
z RFC 3358 - Optional Checksums in ISIS
z RFC 3373 - Three-Way Handshake for IS-IS Point-to-Point Adjacencies
z RFC 3567 - Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication
z RFC 3719 - Recommendations for Interoperable Networks using IS-IS
z RFC 3786 - Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit
z RFC 3787 - Recommendations for Interoperable IP Networks using IS-IS
z RFC 3784 - IS-IS extensions for Traffic Engineering
z RFC 3847 - Restart signaling for IS-IS
1-15
IS-IS Configuration Task List
Complete the following tasks to configure IS-IS:
Task Remarks
Enabling IS-IS
Configuring IS-IS
Configuring the IS Level and Circuit Level Required
Basic Functions
Configuring the Network Type of an Interface as P2P
Configuring IS-IS Link Cost Optional

Specifying a Priority for IS-IS Required
Configuring the Maximum Number of Equal Cost Routes Optional
Configuring IS-IS
Routing Configuring IS-IS Route Summarization Optional
Information Advertising a Default Route Optional
Control
Configuring IS-IS Route Redistribution Optional
Configuring IS-IS Route Filtering Optional
Configuring IS-IS Route Leaking Optional
Specifying Intervals for Sending IS-IS Hello and CSNP Packets Optional
Specifying the IS-IS Hello Multiplier Optional
Configuring a DIS Priority for an Interface Optional
Disabling an Interface from Sending/Receiving IS-IS Packets Optional

Tuning and
Optimizing IS-IS Disabling Hello Source Address Check for a PPP interface Optional
Network
Enabling an Interface to Send Small Hello Packets Optional
Configuring LSP Parameters Optional

Configuring SPF Parameters Optional
Setting the LSDB Overload Bit Optional
Configuring Neighbor Relationship Authentication Optional

Configuring IS-IS
Configuring Area Authentication Optional
Authentication
Configuring Routing Domain Authentication Optional
Configuring Configuring a Static System ID to Host Name Mapping Optional

System ID to Host
Name Mappings Configuring Dynamic System ID to Host Name Mapping Optional
Enabling the Logging of Neighbor State Changes Optional
Enabling IS-IS SNMP Trap Optional
Configuring IS-IS Basic Functions

Before the configuration, accomplish the following tasks:

z Configure the link layer protocol.
1-16
z Configure an IP address for each interface, and make sure all neighboring nodes are reachable to
each other at the network layer.
Enabling IS-IS
Follow these steps to enable IS-IS:

Required
isis [ process-id ]
Enable the IS-IS routing Not enabled by default
[ vpn-instance
process and enter its view Support for vpn-instance
vpn-instance-name ]
vpn-instance-name varies by device.
Assign a network entity Required

network-entity net
title (NET) Not assigned by default
interface-number
Enable an IS-IS process Required

isis enable [ process-id ]
on the interface Disabled by default
Configuring the IS Level and Circuit Level
If only one area is available, it is recommended that:

z Configure the IS level of all routers as Level-1 or Level-2 and dont configure different levels in this
case because there is no need for all routers to maintain two identical LSDBs;
z Configure the IS level as Level-2 on all routers in an IP network for scalability.
For an interface of a Level-1 (or Level-2) router, the circuit level can only be Level-1 (or Level-2). For an
interface of a Level-1-2 router, the default circuit level is Level-1-2; if the router only needs to form
Level-1 (or Level-2) neighbor relationships, you can configure the circuit level for its interfaces as
Level-1 (or Level-2) to limit neighbor relationship establishment.
Follow these steps to configure the IS level and circuit level:

isis [ process-id ]
Enter IS-IS view [ vpn-instance Support for vpn-instance
vpn-instance-name ] vpn-instance-name varies by device.
is-level { level-1 | level-1-2 | Optional

Specify the IS level
level-2 } The default is Level-1-2.
interface-number
1-17
isis circuit-level [ level-1 | Optional

Specify the circuit level
level-1-2 | level-2 ] The default is Level-1-2.
Configuring the Network Type of an Interface as P2P
Interfaces with different network types operate differently. For example, broadcast interfaces on a
network need to elect the DIS and flood CSNP packets to synchronize the LSDBs, while P2P interfaces
on a network need not elect the DIS and have a different LSDP synchronization mechanism.
If there are only two routers on a broadcast network, you can configure the network type of attached
interfaces as P2P to avoid DIS election and CSNP flooding, saving network bandwidth and speeding up
network convergence.
Follow these steps to configure the network type of an interface:

interface-number
Optional
Configure the
network type for the isis circuit-type p2p By default, the network type of an interface
interface as P2P depends on the physical media. The network
type of a VLAN interface is broadcast.
You can only perform this configuration for a broadcast network with only two attached routers.
Configuring IS-IS Routing Information Control


z Configure network layer addresses for interfaces, and make sure adjacent nodes are reachable to
each other at the network layer.
z Enable IS-IS.
Configuring IS-IS Link Cost
The IS-IS cost of an interface is determined in the following order:

z ISIS cost specified in interface view.
z ISIS cost specified in system view. The cost is applied to the interfaces associated to the IS-IS
process.
1-18
z Automatically calculated cost: When the cost style is wide or wide-compatible, IS-IS
automatically calculates the cost using the formula: interface cost= (bandwidth reference
value/interface bandwidth) 10.
If none of the above costs is used, a default cost of 10 applies.
Configuring an IS-IS cost for an interface
Follow these steps to configure a cost for an interface:

isis [ process-id ] [ vpn-instance
Enter IS-IS view
vpn-instance-name ]
cost-style { narrow | wide |

Specify an IS-IS cost wide-compatible | { compatible | Optional
style narrow-compatible } narrow by default
[ relax-spf-limit ] }
interface-number
Optional
Specify a cost for the
isis cost value [ level-1 | level-2 ] No cost is specified for the
interface
Configuring a global IS-IS cost
Follow these steps to configure a global IS-IS cost:

Enter IS-IS view
vpn-instance-name ]

Specify an IS-IS cost wide-compatible | { compatible | Optional
style narrow-compatible } narrow by default
Required
Specify a global IS-IS
circuit-cost value [ level-1 | level-2 ] No global cost is specified by
cost
default.
Enable automatic IS-IS cost calculation
Follow these steps to enable automatic IS-IS cost calculation:

Enter IS-IS view
vpn-instance-name ]
1-19
cost-style { wide | Required

Specify an IS-IS cost style
wide-compatible } narrow by default
Enable automatic IS-IS cost Required

auto-cost enable
calculation Disabled by default
Configure a bandwidth Optional

reference value for automatic bandwidth-reference value
IS-IS cost calculation 100 Mbps by default
Specifying a Priority for IS-IS
A router may run multiple routing protocols. When routes to the same destination are found by multiple
routing protocols, the route learned by the protocol with the highest priority wins. You can reference a
routing policy to specify a priority for specific routes. For information about routing policy, refer to
Routing Policy Configuration in the IP Routing Volume.
Follow these steps to configure the priority of IS-IS.

Enter IS-IS view
vpn-instance-name ]
preference { route-policy Required

Specify a priority for IS-IS
route-policy-name | preference } * 15 by default
Configuring the Maximum Number of Equal Cost Routes
If there are multiple equal cost routes to the same destination, the traffic can be load balanced to
enhance efficiency.
Follow these steps to configure the maximum number of equal cost routes:

Enter IS-IS view
vpn-instance-name ]
Specify the maximum Required

maximum load-balancing
number of equal cost routes The number range and default
number
for load balancing vary by device.
Configuring IS-IS Route Summarization
This task is to configure a summary route, so routes falling into the network range of the summary route
are summarized into one route for advertisement. Doing so can reduce the size of routing tables, as well
as the scale of LSP and LSDB. Both IS-IS routes and redistributed routes can be summarized.
1-20
Follow these steps to configure route summarization:

Enter IS-IS view
vpn-instance-name ]
summary ip-address { mask | Required
Configure IS-IS route mask-length } [ avoid-feedback |
summarization generate_null0_route | tag tag | No route summarization is
[ level-1 | level-1-2 | level-2 ] ] * configured by default.
z The cost of the summary route is the lowest one among the costs of summarized routes.
z The router summarizes only the routes in the locally generated LSPs.
Advertising a Default Route
A router running IS-IS cannot redistribute any default route and thus cannot advertise a default route to
other neighbors. You can use the following commands to advertise a default route of 0.0.0.0/0 to the
same level neighbors.
Follow these steps to advertise a default route:

Enter IS-IS view
vpn-instance-name ]
default-route-advertise Required
Advertise a default route [ route-policy route-policy-name | The function is disabled by
[ level-1 | level-2 | level-1-2 ] ] * default.
The default route is only advertised to routers at the same level. You can use a routing policy to
generate the default route only when a local routing entry is matched by the policy.
Configuring IS-IS Route Redistribution
Redistribution of large numbers of routes on a device may affect the performance of other devices in the
network. In that case, you can configure a limit on the number of redistributed routes to limit the number
of routes to be advertised.
Follow these steps to configure IS-IS route redistribution from other routing protocols:
1-21
isis [ process-id ]
Enter IS-IS view [ vpn-instance
vpn-instance-name ]
import-route protocol Required

[ process-id | all-processes |
No route is redistributed by
allow-ibgp ] [ cost cost |
Redistribute routes from default.
cost-type { external |
another routing protocol If no level is specified, routes
internal } | [ level-1 | level-1-2 |
level-2 ] | route-policy are redistributed into the
route-policy-name | tag tag ] * Level-2 routing table by default.

number of redistributed Level import-route limit number
1/Level 2 IPv4 routes The default varies with devices.
Configuring IS-IS Route Filtering
You can reference a configured ACL, IP prefix list or routing policy to filter routes calculated from the
received LSPs and the routes redistributed from other routing protocols.
Filtering routes calculated from received LSPs
IS-IS saves the LSPs received from neighbors in the LSDB, uses the SPF algorithm to calculate the
shortest path tree with itself as the root and installs the routes into the IS-IS routing table.
By reference a configured ACL, IP prefix list or routing policy, you can filter the calculated routes and
only the routes matching the filter can be added into the IS-IS routing table.
Follow these steps to filter routes calculated from received LSPs:

Enter IS-IS view
vpn-instance-name ]
filter-policy { acl-number | ip-prefix Required

Filter routes calculated
ip-prefix-name | route-policy No filtering is configured by
from received LSPs
route-policy-name } import default.
Filtering redistributed routes
IS-IS can redistribute routes from other routing protocols or other IS-IS processes, add them into the
IS-IS routing table and advertise them in LSPs.
By reference a configured ACL, IP prefix list or routing policy, you can filter redistributed routes and only
the routes matching the filter can be added into the IS-IS routing table and advertised to neighbors.
Follow these steps to configure the filtering of redistributed routes:
1-22
Enter IS-IS view
vpn-instance-name ]
Configure the filtering of routes filter-policy { acl-number | ip-prefix Required
redistributed from another ip-prefix-name | route-policy
routing protocol or IS-IS route-policy-name } export [ protocol Not configured by
process [ process-id ] ] default
Configuring IS-IS Route Leaking
With IS-IS route leaking enabled, the Level-1-2 router can advertise the routing information of other
Level-1 areas and Level-2 area routing information to Level-1 routers.
Follow these steps to configure IS-IS route leaking:

Enter IS-IS view
vpn-instance-name ]
import-route isis level-2 into level-1

Enable IS-IS route [ filter-policy { acl-number | ip-prefix Required
leaking ip-prefix-name | route-policy Disabled by default
route-policy-name } | tag tag ] *
z If a filter policy is specified, only routes passing it can be advertised into Level-1 area.
z You can specify a routing policy in the import-route isis level-2 into level-1 command to filter
routes from Level-2 to Level-1. Other routing policies specified for route reception and
redistribution does not affect the route leaking.
Tuning and Optimizing IS-IS Networks


z Configure IP addresses for interfaces, and make adjacent nodes reachable to each other at the
network layer.
z Enable IS-IS.
Specifying Intervals for Sending IS-IS Hello and CSNP Packets
Follow these steps to configure intervals for sending IS-IS hello and CSNP packets:
1-23
interface-number
Specify the interval for sending isis timer hello seconds Optional
hello packets [ level-1 | level-2 ] 10 seconds by default
Specify the interval for sending Optional
isis timer csnp seconds
CSNP packets on the DIS of a
[ level-1 | level-2 ] 10 seconds by default
broadcast network
The interval between hello packets sent by the DIS is 1/3 the hello interval set with the isis timer hello
command.
Specifying the IS-IS Hello Multiplier
If a neighbor receives no hello packets from the router within the advertised hold time, it considers the
router down and recalculates the routes. The hold time is the hello multiplier times the hello interval.
Follow these steps to specify the IS-IS hello multiplier:

interface-number
Specify the number of hello packets a Optional
isis timer holding-multiplier
neighbor must miss before declaring the
value [ level-1 | level-2 ] 3 by default
router is down
On a broadcast link, Level-1 and Level-2 hello packets are advertised separately and therefore you
need to set a hello multiplier for each level. On a P2P link, Level-1 and Level-2 hello packets are
advertised in P2P hello packets, and you need not specify Level-1 or Level-2.
Configuring a DIS Priority for an Interface
On an IS-IS broadcast network, a router should be elected as the DIS at a routing level. You can specify
a DIS priority at a level for an interface. The greater the interfaces priority is, the more likelihood it
becomes the DIS.
Follow these steps to specify a DIS priority for an interface:
1-24
interface-number
Specify a DIS priority for the isis dis-priority value [ level-1 Optional
interface | level-2 ] 64 by default
If multiple routers in the broadcast network have the same highest DIS priority, the router with the
highest MAC address becomes the DIS.
Disabling an Interface from Sending/Receiving IS-IS Packets
After disabled from sending and receiving hello packets, an interface cannot form any neighbor
relationship, but can advertise directly connected networks in LSPs through other interfaces. By doing
so, you can save bandwidth and CPU resources while ensuring other routers know networks directly
connected to the interface.
Follow these steps to disable an interface from sending and receiving IS-IS packets:

interface-number
Disable the interface from sending Required

isis silent
and receiving IS-IS packets Not disabled by default
Disabling Hello Source Address Check for a PPP interface
On a P2P link, IS-IS verifies the source IP address of the incoming hello packets is in the same network
segment as the IP address of the receiving interface. If not, it discards the hello packets, and no
neighbor relationship can be established with the peer router.
For a PPP interface, the peers IP address may reside on a different network segment. In this case, you
can disable the hello source address check for the PPP interface to establish the neighbor relationship
with the peer.
Follow these steps to enable neighbor relationships over different network segments:

interface-number
1-25
Required
The command only applies to
Disable hello source address
isis peer-ip-ignore the PPP interface.
check for the PPP interface
Hello source address check is
enabled by default.
Enabling an Interface to Send Small Hello Packets
IS-IS messages cannot be fragmented at the IP layer because they are directly encapsulated into
frames. Therefore, any two IS-IS neighboring routers need to negotiate a common MTU. To avoid
sending big hellos for saving bandwidth, you can enable the interface to send small hello packets
without CLVs.
Follow these steps to enable an interface to send small hello packets:

interface-number
Enable the interface to send Required

small hello packets without isis small-hello Standard hello packets are sent
CLVs by default.
Configuring LSP Parameters
Configuring LSP timers
1) Specify the maximum age of LSPs

Each LSP has an age that decreases in the LSDB. Any LSP with an age of 0 is deleted from the LSDB.
You can adjust the age value based on the scale of a network.
Follow these steps to specify the maximum age of LSPs:

Enter IS-IS view
vpn-instance-name ]
Specify the maximum LSP Optional

timer lsp-max-age seconds
age 1200 seconds by default
2) Specify the LSP refresh interval and generation interval

Each router needs to refresh LSPs generated by itself at a configurable interval and send them to other
routers to prevent valid routes from being aged out. A smaller refresh interval speeds up network
convergence but consumes more bandwidth.
When the network topology changes, for example, a neighbor is down/up, or the interface metric,
system ID or area ID is changed, the router generates an LSP after a configurable interval. If such
1-26
changes occur frequently, excessive LSPs are generated, consuming a large amount of router
resources and bandwidth; in this case, you can adjust the LSP generation interval.
Follow these steps to specify the LSP refresh interval and generation interval:

Enter IS-IS view
vpn-instance-name ]
Specify the LSP refresh Optional

timer lsp-refresh seconds
interval 900 seconds by default
timer lsp-generation maximum-interval Optional

Specify the LSP
[ initial-interval [ incremental-interval ] ]
generation interval 2 seconds by default
[ level-1 | level-2 ]
3) Specify LSP sending intervals

If a change occurs in the LSDB, IS-IS advertises the changed LSP to neighbors. You can specify the
minimum interval for sending such LSPs.
On a P2P link, IS-IS requires an advertised LSP be acknowledged. If no acknowledgement is received
within a configurable interval, IS-IS will retransmit the LSP.
Follow these steps to configure LSP sending intervals:

interface-number
Optional
Specify the minimum interval
for sending LSPs and the isis timer lsp time [ count By default, the minimum
maximum LSP number that can count ] interval is 33 milliseconds, and
be sent at a time the maximum LSP number that
can be sent at a time is 5.
Specify the LSP retransmission Optional

isis timer retransmit seconds
interval on a P2P link 5 seconds by default
Specifying LSP lengths
IS-IS messages cannot be fragmented at the IP layer because they are directly encapsulated in frames.
Therefore, IS-IS routers in an area need to send LSPs smaller than the smallest interface MTU in this
area.
If the IS-IS routers have different interface MTUs, it is recommended to configure the maximum size of
generated LSP packets to be smaller than the smallest interface MTU in this area. Otherwise, the
routers have to dynamically adjust the LSP packet size to fit the smallest interface MTU, which takes
time and affects other services.
1-27
Follow these steps to specify LSP lengths:

Enter IS-IS view
vpn-instance-name ]
Specify the maximum length of generated lsp-length originate size 1497 bytes by
Level-1 LSPs or Level-2 LSPs [ level-1 | level-2 ] default
Specify the maximum length of received 1497 bytes by
lsp-length receive size
LSPs default
Enabling LSP flash flooding
Since changed LSPs may trigger SPF recalculation, you can enable LSP flash flooding to advertise the
changed LSPs before the router recalculates routes. Doing so can speed up network convergence.
Follow these steps to enable LSP flash flooding:

Enter IS-IS view
vpn-instance-name ]
flash-flood [ flood-count flooding-count | Required

Enable LSP flash
max-timer-interval flooding-interval | [ level-1 | Not enabled by
flooding
level-2 ] ] * default
Enabling LSP fragment extension
Follow these steps to enable LSP fragment extension:

Enter IS-IS view
vpn-instance-name ]
Enable LSP fragment Required
lsp-fragments-extend [ [ level-1 | level-2 |
extension and specify the
level-1-2 ] | [ mode-1 | mode-2 ] ] * Not enabled by default
working mode
Configure a virtual system Required

virtual-system virtual-system-id
ID Not configured by default
1-28
z After LSP fragment extension is enabled for an IS-IS process, the MTUs of all the interfaces
running the IS-IS process must not be less than 512; otherwise, LSP fragment extension will not
take effect.
z At least one virtual system needs to be configured for the router to generate extended LSP
fragments. An IS-IS process allows 50 virtual systems at most.
Limiting LSP flooding
In well connected ATM, FR and NBMA networks, many P2P links exist. The following figure shows a
fully meshed network, where Routers A, B, C and D run IS-IS. When Router A generates an LSP, it
floods the LSP out Ethernet 1/0, Ethernet 1/1 and Ethernet 1/2. After receiving the LSP from Ethernet
1/0, Router D floods it out Ethernet 1/1 and Ethernet 1/2 to Router B and Router C, which however has
received the LSP from Router A. in this case, LSP flooding consumes extra bandwidth.
Figure 1-14 Network diagram of a fully meshed network
Router A Router D
Eth1/0 Eth1/0
Eth1/1 Eth1/1
Eth1/2 Eth1/2
Eth1/2 Eth1/2
Eth1/1 Eth1/1
Eth1/0 Eth1/0
Router B Router C
To avoid this, you can configure some interfaces as a mesh group or/and configure the blocked
interfaces.
z After receiving an LSP, a member interface in a mesh group floods it out the interfaces that does
not belong to the mesh group.
z If an interface is blocked, it does not send LSPs unless the neighbor sends LSP requests to it.
Before configuring this task, you need to consider redundancy for interfaces to avoid the fact that LSP
packets cannot be flooded due to link failures.
Follow these steps to add an interface into a mesh group and block an interface:

interface-number
Add the interface to isis mesh-group Required to choose either.
a mesh group mesh-group-number
By default, the interface neither belongs
Block the interface isis mesh-group mesh-blocked to any mesh group nor is blocked.
1-29
The mesh group feature takes effect only on P2P interfaces.
Configuring SPF Parameters
When the LSDB changes on a router, a route calculation starts. Frequent route calculations consume a
lot of system resources, while route calculations at a proper interval improve efficiency. You can set an
appropriate interval for SPF calculations as needed.
Follow these steps to configure the SPF parameters:

Enter IS-IS view
vpn-instance-name ]
Optional
Configure the SPF timer spf maximum-interval
calculation interval [ initial-interval [ second-wait-interval ] ] The default SPF calculation
interval is 10 seconds.
Setting the LSDB Overload Bit
By setting the overload bit in sent LSPs, a router informs other routers of a failure that makes it
incapable of routing and forwarding packets.
When an IS-IS router cannot record the complete LSDP due to running out of memory or some other
reasons, it will calculate wrong routes. To make troubleshooting easier in this case, you can temporarily
isolate the router from the IS-IS network by setting the overload bit.
Follow these steps to set the LSDB overload bit:

Enter IS-IS view
vpn-instance-name ]
set-overload [ on-startup [ [ start-from-nbr Required
Set the overload bit system-id [ timeout1 [ nbr-timeout ] ] ] | timeout2 ]
[ allow { interlevel | external } * ] Not set by default
Configuring IS-IS Authentication

Complete the following tasks before this configuration:

z Configure network layer addresses for interfaces to make neighboring nodes accessible to each
other at the network layer.
z Enable IS-IS.
1-30
Configuring Neighbor Relationship Authentication
With neighbor relationship authentication configured, an interface adds the password in the specified
mode into hello packets to the peer and checks the password in the received hello packets. If the
authentication succeeds, it forms the neighbor relationship with the peer.
The authentication mode and password at both ends must be identical.
Follow these steps to configure neighbor relationship authentication:

interface-number
isis authentication-mode Required

Specify the authentication
{ simple | md5 } password Not authentication is configured
mode and password
[ level-1 | level-2 ] [ ip | osi ] by default.
The level-1 and level-2 keywords in the isis authentication-mode command are only supported on
Ethernet interfaces of routers, and VLAN interfaces and GigabitEthernet interfaces of switches, and the
interfaces must be configured with the isis enable command first.
Configuring Area Authentication
Area authentication enables a router not to install routing information from untrusted routers into the
Level-1 LSDB. The router encapsulates the authentication password in the specified mode into Level-1
packets (LSP, CSNP, PSNP) and check the password in received Level-1 packets.
Routers in a common area must have the same authentication mode and password.
Follow these steps to configure area authentication:

Enter IS-IS view
vpn-instance-name ]
Specify the area area-authentication-mode Required

authentication mode and { simple | md5 } password [ ip | No area authentication is
password osi ] configured by default.
Configuring Routing Domain Authentication
Routing domain authentication prevents untrusted routing information from entering into a routing
domain. A router with the authentication configured encapsulates the password in the specified mode
into Level-2 packets (LSP, CSNP, PSNP) and check the password in received Level-2 packets.
All the routers in the backbone must have the same authentication mode and password.
1-31
Follow these steps to configure routing domain authentication:

Enter IS-IS view
vpn-instance-name ]
Specify the routing Required

domain-authentication-mode
domain authentication No routing domain authentication
{ simple | md5 } password [ ip | osi ]
mode and password is configured by default.
Configuring System ID to Host Name Mappings

In IS-IS, a system ID identifies a router or host uniquely. A system ID has a fixed length of 6 bytes. When
an administrator needs to view IS-IS neighbor information, routing table or LSDB information, using the
system IDs in dotted decimal notation is not convenient. To solve it, you can configure the mappings
between system IDs and host names since host names are easier to remember and use.
Such mappings can be configured manually or dynamically. Note that:
z Using the display isis lsdb command on a router configured with dynamic system ID to host name
mapping displays router names rather than system IDs.
z If you configure both dynamic and static system ID to host name mappings on a router, the host
name for dynamic system ID to host name mapping applies.
Configuring a Static System ID to Host Name Mapping
Follow these steps to configure a static system ID to host name mapping:

Enter IS-IS view
vpn-instance-name ]
Required
Configure a system ID to host is-name map sys-id
name mapping for a remote IS map-sys-name A system ID can only
correspond to a host name.
Configuring Dynamic System ID to Host Name Mapping
You need to configure a static system ID to host name mapping for any other router in a network. When
a new router is added into the network or a mapping needs to be modified, you need to perform
configuration on all routers.
In this case, you can configure dynamic system ID to host name mapping. To do so, you need to
configure a host name for each router in the network. Each router advertises the host name in dynamic
host name CLVs to other routers. At last, all routers in the network have all the mappings to generate a
mapping table.
In addition, you can configure a name for the DIS in a broadcast network to help check the origin of
LSPs in the LSDB.
Follow these steps to configure dynamic system ID to host name mapping:
1-32
isis [ process-id ]
Enter IS-IS view [ vpn-instance
vpn-instance-name ]
Specify a host name for Required

is-name sys-name
the router No specified by default.
interface-number
Optional
This command takes effect only on a
Configure a DIS name isis dis-name symbolic-name router with dynamic system ID to host
name mapping configured.
This command is not supported on
P2P interfaces.
Configuring IS-IS GR
Restarting ISIS on a router causes transient network disconnection and route re-convergence.
With the Graceful Restart (GR) feature, the restarting router, known as the GR restarter, can notify the
event to its GR capable neighbors, which, known as the GR helpers, will keep their adjacencies with the
router within a configurable GR interval. After the restart, the router contacts its neighbors to retrieve its
routing table.
During the whole process, the network keeps stable.
You can enable the GR Restarter to suppress the Suppress-Advertisement (SA) bit in the hello PDUs.
In this way, its neighbors will still advertise the adjacencies within the specified period.
Follow these steps to configure GR on the GR Restarter and GR Helper respectively:
isis [ process-id ] Required

Enable IS-IS, and enter IS-IS
[ vpn-instance
view Disabled by default
vpn-instance-name ]
Enable the GR capability for Required

graceful-restart
IS-IS Disabled by default
Set the Graceful Restart Required

graceful-restart interval timer
Optional
Suppress the SA bit during
graceful-restart suppress-sa By default, the SA bit is not
restart
suppressed.
1-33
Enabling the Logging of Neighbor State Changes
Follow these steps to enable the logging of neighbor state changes:

Enter IS-IS view
vpn-instance-name ]
Enable the logging of neighbor Required

log-peer-change
state changes Enabled by default
With this feature enabled, the router delivers information about neighbor state changes to the terminal
for display.
Enabling IS-IS SNMP Trap

Follow these steps to enable IS-IS SNMP trap:

Enter IS-IS view
vpn-instance-name ]
Required
Enable SNMP trap is-snmp-traps enable
Enabled by default
Displaying and Maintaining IS-IS

Display brief IS-IS configuration display isis brief [ process-id |
information vpn-instance vpn-instance-name ]
display isis debug-switches
Display the status of IS-IS
{ process-id | vpn-instance Available in any view
debug switches
vpn-instance-name }
display isis graceful-restart status

Display the IS-IS Graceful
[ level-1 | level-2 ] [ process-id | Available in any view
Restart state
vpn-instance vpn-instance-name ]
display isis interface [ [ traffic-eng |
Display information about IS-IS
verbose ] * | tunnel ] [ process-id | Available in any view
enabled interfaces
Display IS-IS license
display isis license Available in any view
information
1-34
display isis lsdb [ [ l1 | l2 | level-1 |
level-2 ] | [ lsp-id LSPID | lsp-name
Display IS-IS LSDB information lspname ] | local | verbose ] * Available in any view
[ process-id | vpn-instance
vpn-instance-name ]
Display IS-IS mesh group display isis mesh-group [ process-id |
Display the
display isis name-table [ process-id |
host-name-to-system-ID Available in any view
mapping table
Display IS-IS neighbor display isis peer [ verbose ] [ process-id
information | vpn-instance vpn-instance-name ]
display isis route [ ipv4 ] [ [ level-1 |
Display IS-IS IPv4 routing
level-2 ] | verbose ] * [ process-id | Available in any view
information
Display IS-IS SPF calculation display isis spf-log [ process-id |
log information vpn-instance vpn-instance-name ]
display isis statistics [ level-1 | level-2 |
Display IS-IS statistics level-1-2 ] [ process-id | vpn-instance Available in any view
vpn-instance-name ]
Clear ISIS process data reset isis all [ process-id | vpn-instance
structure information vpn-instance-name ]
Clear the data structure
reset isis peer system-id [ process-id |
information of an IS-IS Available in user view
neighbor
IS-IS Configuration Examples (on Routers)

IS-IS Basic Configuration
As shown in Figure 1-15, Router A, B, C and Router D reside in an autonomous system. They are
interconnected through IS-IS.
Router A and Router B are Level-1 routers, Router D is a Level-2 router, and Router C is a Level-1-2
router connecting two areas. Router A, Router B, and Router C are in area 10, while Router D is in area
20.
1-35
Network diagram
Figure 1-15 Network diagram for IS-IS basic configuration

2) Configure IS-IS
# Configure Router A
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA-Serial2/0] isis enable 1
# Configure Router B
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB-Serial2/0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC-Serial2/0] isis enable 1
1-36
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD-Ethernet1/0] isis enable 1
[RouterD-Serial2/0] isis enable 1
# Display the IS-IS LSDB information of each router.
[RouterA] display isis lsdb
Database information for ISIS(1)

--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL

--------------------------------------------------------------------------
0000.0000.0001.00-00* 0x0000000d 0xb184 879 68 0/0/0
0000.0000.0002.00-00 0x0000000c 0xcf65 493 68 0/0/0
0000.0000.0003.00-00 0x00000013 0x2f38 594 111 1/0/0
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
[RouterB] display isis lsdb

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

--------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000000d 0xb184 707 68 0/0/0
0000.0000.0002.00-00* 0x0000000c 0xcd66 1167 68 0/0/0
0000.0000.0003.00-00 0x00000013 0x2d39 1136 111 1/0/0
1-37
[RouterC] display isis lsdb

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

------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000000d 0xc57a 991 68 0/0/0
0000.0000.0002.00-00 0x0000000c 0xef4d 1025 68 0/0/0
0000.0000.0003.00-00* 0x00000013 0x93dd 1026 111 1/0/0

------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000013 0xbb56 1026 100 0/0/0
0000.0000.0004.00-00 0x00000005 0xd086 904 84 0/0/0
[RouterD] display isis lsdb

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

------------------------------------------------------------------------
0000.0000.0003.00-00 0x00000013 0xbb56 910 100 0/0/0
0000.0000.0004.00-00* 0x00000005 0xd086 791 84 0/0/0
# Display the IS-IS routing information of each router. The routing table of Level-1 routers must contain
a default route with the next hop being the Level-1-2 router. The routing table of Level-2 router must
contain all routes of Level-1 and Level-2.
[RouterA] display isis route
Route information for ISIS(1)

-----------------------------
1-38
ISIS(1) IPv4 Level-1 Forwarding Table
-------------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/0 Direct D/L/-
10.1.2.0/24 20 NULL S2/0 10.1.1.1 R/-/-
192.168.0.0/24 20 NULL S2/0 10.1.1.1 R/-/-
0.0.0.0/0 10 NULL S2/0 10.1.1.1 R/-/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
[RouterC] display isis route

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

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct D/L/-
10.1.2.0/24 10 NULL S2/0 Direct D/L/-
192.168.0.0/24 10 NULL S2/2 Direct D/L/-

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct D/L/-
10.1.2.0/24 10 NULL S2/0 Direct D/L/-
192.168.0.0/24 10 NULL S2/2 Direct D/L/-
172.16.0.0/16 20 NULL S2/2 192.168.0.2 R/-/-

[RouterD] display isis route

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

-------------------------------------
1-39
--------------------------------------------------------------------------
192.168.0.0/24 10 NULL S2/0 Direct D/L/-
10.1.1.0/24 20 NULL S2/0 192.168.0.1 R/-/-
10.1.2.0/24 20 NULL S2/0 192.168.0.1 R/-/-
172.16.0.0/16 10 NULL Eth1/0 Direct D/L/-
DIS Election Configuration
As shown in Figure 1-16, on a broadcast network (Ethernet), Router A, Router B, Router C and Router
D reside in IS-IS area 10. Router A and Router B are Level-1-2 routers, Router C is a Level-1 router, and
Router D is a Level-2 router.
Change the DIS priority of Router A to make it selected as the Level-1-2 DIS router.
Network diagram
Figure 1-16 Network diagram for DIS selection configuration
1) Configure an IP address for each interface (omitted)

2) Enable IS-IS
[RouterA] isis 1
[RouterA-Ethernet1/0] isis enable 1
1-40
[RouterB] isis 1
[RouterB-Ethernet1/0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] is-level level-1
[RouterC-Ethernet1/0] isis enable 1
[RouterD] isis 1
# Display information about IS-IS neighbors of Router A.

[RouterA] display isis peer
Peer information for ISIS(1)

----------------------------
System Id: 0000.0000.0002

Interface: Ethernet1/0 Circuit Id: 0000.0000.0003.01
State: Up HoldTime: 21s Type: L1(L1L2) PRI: 64
System Id: 0000.0000.0003

State: Up HoldTime: 6s Type: L1 PRI: 64
System Id: 0000.0000.0002

System Id: 0000.0000.0004

1-41
# Display information about IS-IS interfaces of Router A.

[RouterA] display isis interface
Interface information for ISIS(1)

---------------------------------
Interface: Ethernet1/0
Id IPV4.State IPV6.State MTU Type DIS
001 Up Down 1497 L1/L2 No/No
# Display IS-IS interfaces of Router C.

[RouterC] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 Yes/No
# Display information about IS-IS interfaces of Router D.

[RouterD] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 No/Yes
By using the default DIS priority, Router C is the Level-1 DIS, and Router D is the Level-2 DIS. The
pseudonodes of Level-1 and Level-2 are 0000.0000.0003.01 and 0000.0000.0004.01 respectively.
3) Configure the DIS priority of Router A.

[RouterA-Ethernet1/0] isis dis-priority 100
# Display information about IS-IS neighbors of Router A.

[RouterA] display isis peer

----------------------------
System Id: 0000.0000.0002

System Id: 0000.0000.0003

1-42
System Id: 0000.0000.0002
System Id: 0000.0000.0004

# Display information about IS-IS interfaces of Router A.

[RouterA] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 Yes/Yes
After the DIS priority configuration, you can see Router A is the DIS for Level-1-2, and the pseudonode
is 0000.0000.0001.01.
# Display information about IS-IS neighbors and interfaces of Router C.
[RouterC] display isis peer

----------------------------
System Id: 0000.0000.0001

System Id: 0000.0000.0002

[RouterC] display isis interface

---------------------------------
# Display information about IS-IS neighbors and interfaces of Router D.

[RouterD] display isis peer

----------------------------
System Id: 0000.0000.0001

1-43
System Id: 0000.0000.0002

[RouterD] display isis interface

---------------------------------
Configuring IS-IS Route Redistribution
As shown in the following figure, Router A, Router B, Router C and Router D reside in the same AS.
They use IS-IS to interconnect. Router A and Router B is Level-1 routers, Router D is a Level-2 router,
and Router C is a Level-1-2 router.
It is required to redistribute RIP routes into IS-IS on Router D.
Network diagram
Figure 1-17 IS-IS route redistribution

2) Configure IS-IS basic functions
[RouterA] isis 1
1-44
[RouterA-Serial2/0] isis enable 1
[RouterB] isis 1
[RouterB-Serial2/0] isis enable 1
[RouterC] isis 1
[RouterD] isis 1
[RouterD-Serial2/0] isis enable 1
# Display IS-IS routing information on each router.

[RouterA] display isis route

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

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

--------------------------------------------------------------------------
1-45
10.1.1.0/24 10 NULL S2/0 Direct D/L/-
10.1.2.0/24 20 NULL S2/0 10.1.1.1 R/-/-
192.168.0.0/24 20 NULL S2/0 10.1.1.1 R/-/-
0.0.0.0/0 10 NULL S2/0 10.1.1.1 R/-/-

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

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct D/L/-
10.1.2.0/24 10 NULL S2/0 Direct D/L/-
192.168.0.0/24 10 NULL S2/2 Direct D/L/-

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct D/L/-
10.1.2.0/24 10 NULL S2/0 Direct D/L/-
192.168.0.0/24 10 NULL S2/2 Direct D/L/-
[RouterD] display isis route

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

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

--------------------------------------------------------------------------
192.168.0.0/24 10 NULL S2/0 Direct D/L/-
10.1.1.0/24 20 NULL S2/0 192.168.0.1 R/-/-
10.1.2.0/24 20 NULL S2/0 192.168.0.1 R/-/-
1-46
3) Configure RIPv2 on Router D and Router E, and configure route redistribution from RIP to IS-IS on
Router D.
# Configure RIPv2 on Router D.
[RouterD] rip 1
[RouterD-rip-1] network 10.0.0.0
[RouterD-rip-1] version 2
[RouterD-rip-1] undo summary
# Configure RIPv2 on Router E.

[RouterE] rip 1
[RouterE-rip-1] network 10.0.0.0
[RouterE-rip-1] version 2
[RouterE-rip-1] undo summary
# Configure route redistribution from RIP to IS-IS on Router D.

[Router-rip-1] quit
[RouterD] isis 1
[RouterDisis]import-route rip level-2
# Display IS-IS routing information on Router C.


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

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct D/L/-
10.1.2.0/24 10 NULL S2/0 Direct D/L/-
192.168.0.0/24 10 NULL S2/2 Direct D/L/-

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct D/L/-
10.1.2.0/24 10 NULL S2/0 Direct D/L/-
192.168.0.0/24 10 NULL S2/2 Direct D/L/-
10.1.4.0/24 10 NULL S2/2 192.168.0.2 R/L/-
10.1.5.0/24 20 NULL S2/2 192.168.0.2 R/L/-
1-47
10.1.6.0/24 20 NULL S2/2 192.168.0.2 R/L/-
IS-IS GR Configuration Example
Router A, Router B, and Router C belong to the same IS-IS routing domain, as illustrated in Figure 1-18.
Network diagram
Figure 1-18 Network diagram for IS-IS-based GR configuration
1) Configure IP addresses of the interfaces on each router and configure IS-IS.

Follow Figure 1-18 to configure the IP address and subnet mask of each interface on the router. The
configuration procedure is omitted.
Configure IS-IS on the routers, ensuring that Router A, Router B and Router C can communicate with
each other at layer 3 and dynamic route update can be implemented among them with IS-IS. The
configuration procedure is omitted here.
2) Configure IS-IS Graceful Restart.
# Enable IS-IS Graceful Restart on Router A and configure the Graceful Restart interval.
[RouterA] isis 1
[RouterA-isis-1] graceful-restart
[RouterA-isis-1] graceful-restart interval 150
[RouterA-isis-1] return
The configurations for Router B and Router C are similar and therefore are omitted here.
After Router A establishes adjacencies with Router B and Router C, they begin to exchange routing
information. Restart IS-IS on Router A, which enters into the restart state and sends connection
requests to its neighbors through the Graceful Restart mechanism to synchronize the LSDB. Using the
display isis graceful-restart status command can display the IS-IS GR status on Router A.
# Restart Router A.
<RouterA> reset isis all 1
Warning : Reset ISIS process? [Y/N]:y
1-48
# Check the IS-IS Graceful Restart state on Router A.
<RouterA> display isis graceful-restart status
Restart information for IS-IS(1)
--------------------------------------------------------------------
IS-IS(1) Level-1 Restart Status
Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 140
T2 Timer Status:
Remaining Time: 59

SA Bit Supported
T3 Timer Status:
Remaining Time: 140
T2 Timer Status:
Remaining Time: 59
IS-IS Authentication Configuration Example
As shown in the following figure, Router A, Router B, Router C and Router D reside in the same IS-IS
routing domain.
Router A, Router B, and Router C belong to Area 10, and Router D belongs to Area 20.
Configure neighbor relationship authentication between neighbors. Configure area authentication in
Area 10 to prevent untrusted routes from entering into the area. Configure routing domain
authentication on Router C and Router D to prevent untrusted routes from entering the routing domain.
1-49
Network diagram
Figure 1-19 IS-IS authentication configuration
1) Configure IP addresses for interfaces (Omitted).

2) Configure IS-IS basic functions.
[RouterA] isis 1
[RouterB] isis 1
[RouterC] isis 1
1-50
[RouterD] isis 1
3) Configure neighbor relationship authentication between neighbors.
# Specify the MD5 authentication mode and password eRq on Ethernet 1/0 of Router A and on Ethernet
1/0 of Router C.
[RouterA-Ethernet1/0] isis authentication-mode md5 eRg
[RouterC-Ethernet1/0] isis authentication-mode md5 eRg
# Specify the MD5 authentication mode and password t5Hr on Ethernet 1/0 of Router B and on Ethernet
1/1 of Router C.
[RouterB-Ethernet1/0] isis authentication-mode md5 t5Hr
[RouterC-Ethernet1/1] isis authentication-mode md5 t5Hr
# Specify the MD5 authentication mode and password hSec on Ethernet 1/0 of Router D and on
Ethernet 1/2 of Router C.
[RouterC-Ethernet1/2] isis authentication-mode md5 hSec
[RouterD-Ethernet1/0] isis authentication-mode md5 hSec
Configure area authentication. Specify the MD5 authentication mode and password 10Sec on Router A,
[RouterA] isis 1
[RouterA-isis-1] area-authentication-mode md5 10Sec
[RouterB] isis 1
[RouterB-isis-1] area-authentication-mode md5 10Sec
1-51
[RouterC] isis 1
[RouterC-isis-1] area-authentication-mode md5 10Sec
Configure routing domain authentication. Specify the MD5 authentication mode and password 1020Sec
on Router C and Router D.
[RouterC] isis 1
[RouterC-isis-1] domain-authentication-mode md5 1020Sec
[RouterD] isis 1
[RouterD-isis-1] domain-authentication-mode md5 1020Sec
[RouterD-isis-1] isis 1
IS-IS Configuration Example (on Switches)

IS-IS Basic Configuration
As shown in Figure 1-20, Switch A, B, C and Switch D reside in an IS-IS AS. Switch A and B are Level-1
switches, Switch D is a Level-2 switch and Switch C is a Level-1-2 switch. Switch A, B and C are in Area
10, while Switch D is in Area 20.
Network diagram
Figure 1-20 Network diagram for IS-IS basic configuration

2) Configure IS-IS
[SwitchA] isis 1
[SwitchA-isis-1] is-level level-1
[SwitchA-isis-1] network-entity 10.0000.0000.0001.00
[SwitchA-isis-1] quit
1-52
[SwitchA-Vlan-interface100] isis enable 1
[SwitchB] isis 1
[SwitchB-isis-1] is-level level-1
[SwitchB-isis-1] network-entity 10.0000.0000.0002.00
[SwitchB-isis-1] quit
[SwitchB-Vlan-interface200] isis enable 1
[SwitchC] isis 1
[SwitchC-isis-1] network-entity 10.0000.0000.0003.00
[SwitchC-isis-1] quit
[SwitchC-Vlan-interface100] isis enable 1
[SwitchC-Vlan-interface100] quit
[SwitchD] isis 1
[SwitchD-isis-1] is-level level-2
[SwitchD-isis-1] network-entity 20.0000.0000.0004.00
[SwitchD-isis-1] quit
[SwitchD] interface vlan-interface 100
[SwitchD-Vlan-interface100] isis enable 1
[SwitchD-Vlan-interface100] quit
# Display the IS-IS LSDB of each switch to check the LSP integrity.
[SwitchA] display isis lsdb

--------------------------------
1-53
--------------------------------------------------------------------------
0000.0000.0001.00-00* 0x00000004 0xdf5e 1096 68 0/0/0
0000.0000.0002.00-00 0x00000004 0xee4d 1102 68 0/0/0
0000.0000.0002.01-00 0x00000001 0xdaaf 1102 55 0/0/0
0000.0000.0003.00-00 0x00000009 0xcaa3 1161 111 1/0/0
0000.0000.0003.01-00 0x00000001 0xadda 1112 55 0/0/0
[SwitchB] display isis lsdb

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

--------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000006 0xdb60 988 68 0/0/0
0000.0000.0002.00-00* 0x00000008 0xe651 1189 68 0/0/0
0000.0000.0002.01-00* 0x00000005 0xd2b3 1188 55 0/0/0
0000.0000.0003.00-00 0x00000014 0x194a 1190 111 1/0/0
0000.0000.0003.01-00 0x00000002 0xabdb 995 55 0/0/0
[SwitchC] display isis lsdb

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

--------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000006 0xdb60 847 68 0/0/0
0000.0000.0002.00-00 0x00000008 0xe651 1053 68 0/0/0
0000.0000.0002.01-00 0x00000005 0xd2b3 1052 55 0/0/0
0000.0000.0003.00-00* 0x00000014 0x194a 1051 111 1/0/0
0000.0000.0003.01-00* 0x00000002 0xabdb 854 55 0/0/0
1-54
--------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000012 0xc93c 842 100 0/0/0
0000.0000.0004.00-00 0x00000026 0x331 1173 84 0/0/0
0000.0000.0004.01-00 0x00000001 0xee95 668 55 0/0/0
[SwitchD] display isis lsdb

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

-------------------------------------------------------------------------------
0000.0000.0003.00-00 0x00000013 0xc73d 1003 100 0/0/0
0000.0000.0004.00-00* 0x0000003c 0xd647 1194 84 0/0/0
0000.0000.0004.01-00* 0x00000002 0xec96 1007 55 0/0/0
# Display the IS-IS routing information of each switch. Level-1 switches should have a default route with
the next hop being the Level-1-2 switch. The Level-2 switch should have both routing information of
Level-1 and Level-2.
[SwitchA] display isis route

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

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL Vlan100 Direct D/L/-
10.1.2.0/24 20 NULL Vlan100 10.1.1.1 R/-/-
192.168.0.0/24 20 NULL Vlan100 10.1.1.1 R/-/-
0.0.0.0/0 10 NULL Vlan100 10.1.1.1 R/-/-
[SwitchC] display isis route
1-55
-----------------------------

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

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

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

--------------------------------------------------------------------------
172.16.0.0/16 20 NULL Vlan300 192.168.0.2 R/-/-
[SwitchD] display isis route

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

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

--------------------------------------------------------------------------
10.1.1.0/24 20 NULL Vlan300 192.168.0.1 R/-/-
10.1.2.0/24 20 NULL Vlan300 192.168.0.1 R/-/-
1-56
DIS Election Configuration
As shown in Figure 1-21, Switch A, B, C and Switch D reside in IS-IS area 10 on a broadcast network
(Ethernet). Switch A and Switch B are Level-1-2 switches, Switch C is a Level-1 switch, and Switch D is
a Level-2 switch.
Change the DIS priority of Switch A to make it elected as the Level-1-2 DIS router.
Network diagram
Figure 1-21 Network diagram for DIS selection

2) Enable IS-IS
[SwitchA] isis 1
[SwitchB] isis 1
[SwitchC] isis 1
1-57
[SwitchC-isis-1] is-level level-1
[SwitchD] isis 1
# Display information about IS-IS neighbors of Switch A.

[SwitchA] display isis peer

----------------------------
System Id: 0000.0000.0002
Interface: Vlan-interface100 Circuit Id: 0000.0000.0003.01
System Id: 0000.0000.0003

System Id: 0000.0000.0002

System Id: 0000.0000.0004

# Display information about IS-IS interfaces of Switch A.

[SwitchA] display isis interface

---------------------------------
Interface: Vlan-interface100
# Display information about IS-IS interfaces of Switch C.

[SwitchC] display isis interface
1-58
---------------------------------
001 Up Down 1497 L1/L2 Yes/No
# Display information about IS-IS interfaces of Switch D.

[SwitchD] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 No/Yes
By using the default DIS priority, Switch C is the Level-1 DIS, and Switch D is the Level-2 DIS. The
pseudonodes of Level-1 and Level-2 are 0000.0000.0003.01 and 0000.0000.0004.01 respectively.
3) Configure the DIS priority of Switch A.

[SwitchA-Vlan-interface100] isis dis-priority 100
# Display IS-IS neighbors of Switch A.

[SwitchA] display isis peer

----------------------------
System Id: 0000.0000.0002
System Id: 0000.0000.0003

System Id: 0000.0000.0002

System Id: 0000.0000.0004

1-59
# Display information about IS-IS interfaces of Switch A.
[SwitchA] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 Yes/Yes
After the DIS priority configuration, Switch A becomes the Level-1-2 DIS, and the pseudonode is
0000.0000.0001.01.
# Display information about IS-IS neighbors and interfaces of Switch C.

[SwitchC] display isis peer

----------------------------
System Id: 0000.0000.0002
System Id: 0000.0000.0001

[SwitchC] display isis interface

---------------------------------
# Display information about IS-IS neighbors and interfaces of Switch D.

[SwitchD] display isis peer

----------------------------
System Id: 0000.0000.0001
System Id: 0000.0000.0002

1-60
[SwitchD] display isis interface

---------------------------------
IS-IS-based Graceful Restart Configuration Example
Switch A, Switch B, and Switch C belong to the same IS-IS routing domain, as illustrated in Figure 1-22.
Network diagram
Figure 1-22 Network diagram for IS-IS-based GR configuration
GR restarter
Switch A
Vlan-int100
10.0.0.1/24
10.0.0.2/24 10.0.0.3/24
Switch B Switch C
GR helper GR helper
1) Configure IP addresses of the interfaces on each switch and configure IS-IS.

Follow Figure 1-22 to configure the IP address and subnet mask of each interface. The configuration
procedure is omitted.
Configure IS-IS on the switches, ensuring that Switch A, Switch B and Switch C can communicate with
each other at layer 3 and dynamic route update can be implemented among them with IS-IS. The
configuration procedure is omitted here.
2) Configure IS-IS Graceful Restart.
# Enable IS-IS Graceful Restart on Switch A and configure the Graceful Restart Interval.
[SwitchA] isis 1
[SwitchA-isis-1] graceful-restart
[SwitchA-isis-1] graceful-restart interval 150
[SwitchA-isis-1] return
Configurations for Switch B and Switch C are similar and therefore are omitted here.
After Router A establishes adjacencies with Router B and Router C, they begin to exchange routing
information. Restart IS-IS on Router A, which enters into the restart state and sends connection
1-61
requests to its neighbors through the Graceful Restart mechanism to synchronize the LSDB. Using the
display isis graceful-restart status command can display the IS-IS GR status on Router A.
# Restart Switch A.
<SwitchA> reset isis all 1
Warning : Reset ISIS process? [Y/N]:y
# Check the Graceful Restart status of IS-IS on Switch A.

<SwitchA> display isis graceful-restart status
Restart information for IS-IS(1)
--------------------------------------------------------------------
SA Bit Supported
T3 Timer Status:
Remaining Time: 140
T2 Timer Status:
Remaining Time: 59

SA Bit Supported
T3 Timer Status:
Remaining Time: 140
T2 Timer Status:
Remaining Time: 59
IS-IS Authentication Configuration Example
As shown in the following figure, Switch A, Switch B, Switch C and Switch D reside in the same IS-IS
routing domain.
Switch A, Switch B, and Switch C belong to Area 10, and Switch D belongs to Area 20.
Configure neighbor relationship authentication between neighbors. Configure area authentication in
Area 10 to prevent untrusted routes from entering into the area. Configure routing domain
authentication on Switch C and Switch D to prevent untrusted routes from entering the routing domain.
1-62
Network diagram
Figure 1-23 IS-IS authentication configuration
1) Configure IP addresses for interfaces (Omitted).

2) Configure IS-IS basic functions.
[SwitchA] isis 1
[SwitchB] isis 1
[RouterB--Vlan-interface200] quit
[SwitchC] isis 1
1-63
[SwitchD] isis 1
3) Configure neighbor relationship authentication between neighbors.
# Specify the MD5 authentication mode and password eRq on VLAN-interface 100 of Switch A and on
VLAN-interface 100 of Switch C.
[SwitchA-Vlan-interface100] isis authentication-mode md5 eRg
[SwitchC-Vlan-interface100] isis authentication-mode md5 eRg
# Specify the MD5 authentication mode and password t5Hr on VLAN-interface 200 of Switch B and on
[SwitchB-Vlan-interface200] isis authentication-mode md5 t5Hr
[SwitchC-Vlan-interface200] isis authentication-mode md5 t5Hr
# Specify the MD5 authentication mode and password hSec on VLAN-interface 300 of Switch D and on
[SwitchC-Vlan-interface300] isis authentication-mode md5 hSec
[SwitchD-Vlan-interface300] isis authentication-mode md5 hSec
4) Configure area authentication. Specify the MD5 authentication mode and password 10Sec on
Switch A, Switch B and Switch C.
[SwitchA] isis 1
[SwitchA-isis-1] area-authentication-mode md5 10Sec
[SwitchB] isis 1
[SwitchB-isis-1] area-authentication-mode md5 10Sec
[SwitchC] isis 1
[SwitchC-isis-1] area-authentication-mode md5 10Sec
1-64
5) Configure routing domain authentication. Specify the MD5 authentication mode and password
1020Sec on Switch C and Switch D.
[SwitchC] isis 1
[SwitchC-isis-1] domain-authentication-mode md5 1020Sec
[SwitchD] isis 1
[SwitchD-isis-1] domain-authentication-mode md5 1020Sec
[SwitchD-isis-1] isis 1
1-65
Table of Contents
1 OSPF Configuration 1-1

Introduction to OSPF1-1
Basic Concepts1-2
OSPF Area Partition and Route Summarization 1-4
Classification of OSPF Networks 1-8
DR and BDR1-9
OSPF Packet Formats1-10
Supported OSPF Features1-19
OSPF Configuration Task List 1-22
Configuring OSPF Basic Functions 1-23
Prerequisites1-23
Configuring OSPF Area Parameters1-24
Prerequisites1-25
Configuring OSPF Network Types1-26
Prerequisites1-26
Configuring the OSPF Network Type for an Interface1-26
Configuring an NBMA Neighbor 1-26
Configuring a Router Priority for an OSPF Interface1-27
Configuring OSPF Route Control1-27
Prerequisites1-27
Configuring OSPF Route Summarization1-28
Configuring OSPF Inbound Route Filtering1-28
Configuring ABR Type-3 LSA Filtering1-29
Configuring an OSPF Cost for an Interface1-29
Configuring the Maximum Number of OSPF Routes 1-29
Configuring the Maximum Number of Load-balanced Routes 1-30
Configuring a Priority for OSPF1-30
Configuring OSPF Route Redistribution1-31
Configuring OSPF Network Optimization1-31
Prerequisites1-32
Configuring OSPF Packet Timers 1-32
Specifying an LSA Transmission Delay 1-33
Specifying SPF Calculation Interval 1-33
Specifying the LSA Minimum Repeat Arrival Interval1-34
Specifying the LSA Generation Interval 1-34
Disabling Interfaces from Sending OSPF Packets1-35
Configuring Stub Routers 1-35
Configuring OSPF Authentication 1-36
Adding the Interface MTU into DD Packets1-37
Configuring the Maximum Number of External LSAs in LSDB 1-37
i
Making External Route Selection Rules Defined in RFC1583 Compatible1-37
Logging Neighbor State Changes 1-38
Configuring OSPF Network Management 1-38
Enabling the Advertisement and Reception of Opaque LSAs 1-39
Configuring OSPF Graceful Restart1-39
Configuring the OSPF GR Restarter 1-39
Configuring the OSPF GR Helper 1-40
Triggering OSPF Graceful Restart 1-41
Displaying and Maintaining OSPF 1-42
OSPF Configuration Examples (on Routers)1-43
Configuring OSPF Basic Functions1-43
Configuring an OSPF Stub Area 1-48
Configuring an OSPF NSSA Area1-51
Configuring OSPF DR Election 1-53
Configuring OSPF Virtual links1-57
Configuring OSPF Graceful Restart 1-59
OSPF Configuration Examples (on Switches) 1-60
Configuring OSPF Basic Functions1-61
Configuring an OSPF Stub Area 1-65
Configuring an OSPF NSSA Area1-68
Configuring OSPF DR Election 1-70
Configuring OSPF Virtual Links1-75
OSPF Graceful Restart Configuration Example1-76
Troubleshooting OSPF Configuration 1-78
No OSPF Neighbor Relationship Established 1-78
Incorrect Routing Information 1-78
ii
The support for this feature depends on the specific model of the H3C MSR series routers.
and value ranges of the H3C MSR series routers.
z All the models of the H3C MSR series routers are centralized devices.
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 Configuring OSPF Basic Functions
z Configuring OSPF Area Parameters
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 (on Routers)
z OSPF Configuration Examples (on Switches)
z Troubleshooting OSPF Configuration
routing protocols.
Introduction to OSPF
Unless otherwise noted, OSPF refers to OSPFv2 throughout this document.
1-1
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.
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 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
To run OSPF, a router must have a Router ID, which is a 32-bit unsigned integer, the unique identifier of
the router in the AS.
You may assign a Router ID to an OSPF router manually. If no Router ID is specified, the system
automatically selects one for the router as follows:
z If the loopback interfaces are configured, select the highest IP address among them.
z If no loopback interface is configured, select the highest IP address among addresses of active
interfaces on the router.
OSPF packets
OSPF uses five types of packets:
1-2
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. In
this case, 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.
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 andAdjacency 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.
1-3
OSPF Area Partition and Route Summarization
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.
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
1-4
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.
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.
1-5
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.
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 in other areas nor the 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.
1-6
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.
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 summarization
Route summarization: An ABR or ASBR summarizes routes with the same prefix into a single route and
distribute it to other areas.
Via route summarization, routing information across areas and the size of routing tables on routers will
be reduced, improving calculation speed of routers.
For example, as shown in the following figure, in Area 1 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 Router A, the three routes are
summarized into the route 19.1.0.0/16 that is advertised into Area 0.
Figure 1-6 Route summarization
Router A
19.1.0.0/16
19.1.1.0/24
19.1.2.0/24
Area 0 ABR Router B 19.1.3.0/24
ABR

Area 1
OSPF has two types of route summarization:

1) ABR route summarization
To distribute routing information to other areas, an ABR generates Type-3 LSAs on a per network
segment basis for an attached non-backbone area. If contiguous network segments are available in the
area, you can summarize them into a single network segment. The ABR in the area distributes only the
summary LSA to reduce the scale of LSDBs on routers in other areas.
2) ASBR route summarization
1-7
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 an ABR, the ABR will summarize Type-5 LSAs translated from Type-7
LSAs.
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, packets are sent to multicast addresses (such as
224.0.0.5 and 224.0.0.6).
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.
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.
1-8
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-9
Figure 1-7 DR and BDR in a network
DR BDR
DRother DRother DRother
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 routers 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-8 OSPF packet format
OSPF packet header
OSPF packets are classified into five types that have the same packet header, as shown below.
1-10
Figure 1-9 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-11
Figure 1-10 Hello packet format
Major fields:
z Network Mask: Network mask associated with the routers 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-12
Figure 1-11 DD packet format
0 7 15 31
Version 2 Packet length
Router ID
Area ID
Checksum AuType
Authentication
Authentication
M
Interface MTU Options 0 0 0 0 0 I M
S
DD sequence number
LSA header
...
LSA header
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-13
Figure 1-12 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-13 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-14
Figure 1-14 LSAck packet format
...
LSA header format
All LSAs have the same header, as shown in the following figure.
Figure 1-15 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.
1-15
Formats of LSAs
1) Router LSA
Figure 1-16 Router LSA format
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-16
Figure 1-17 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-18 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
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.
1-17
4) AS external LSA
An AS external LSA originates from an ASBR, describing routing information to a destination outside
the AS.
Figure 1-19 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-18
Figure 1-20 NSSA external LSA format
0 7 15 31
LS age Options 7
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
Network mask
E TOS Metric
Forwarding address
External route tag
...
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.
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.
1-19
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 OSPF, 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.
Before the restart, the GR Restarter negotiates the GR capability with its neighbors. During the restart,
the GR-capable neighbors, known as the GR helpers continue to advertise their adjacencies with the
GR Restarter.
After the restart, the GR Restarter sends an OSPF GR signal to its GR-capable neighbors so that they
will not reset their adjacencies with it. The GR Restarter then restores its neighbor table upon receiving
responses from the neighbors.
After re-establishing neighborships, the GR Restarter will synchronize the LSDB with all adjacent
GR-capable neighbors, update its own routing table and forwarding table based on the new routing
information and remove the stale routes.
TE and DS-TETE
OSPF Traffic Engineering (TE) provides for the establishment and maintenance of Label Switch Paths
(LSPs) of TE.
When establishing Constraint-based Routed LSPs (CR LSPs), MPLS obtains the TE information of
links in the area via OSPF.
OSPF has a new LSA, Opaque LSA, which can be used for carrying TE information.
DiffServ Aware TE (DS-TE) provides for network resource optimization and allocation, flow
classification, and indication of network bandwidth consumption of each flow in a link. TE is
implemented on the classified type (thin granularity summarization type) rather than the summarized
type (thick granularity summarization type) to improve performance and bandwidth utilization.
To support DS-TE application in MPLS, OSPF supports Local Overbooking Multiplier TLV and
Bandwidth Constraint (BC) TLV.
1-20
For OSPF TE configuration, refer to MPLS TE Configuration in the MPLS Volume.
IGP Shortcut and Forwarding Adjacency
IGP Shortcut and Forwarding Adjacency enable OSPF to use an LSP as the outbound interface for a
destination. Without them, OSPF cannot use the LSP as the outbound interface.
Differences between IGP Shortcut and Forwarding Adjacency:
z If Forwarding Adjacency is enabled only, OSPF can also use an LSP as the outbound interface for
a destination
z If LGP Shortcut is enabled only, only the router enabled with it can use LSPs for routing.
For configuration of this feature, refer to MPLS TE Configuration in the MPLS Volume.
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.
For configuration of this feature, refer to BGP&MPLS VPN 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.
1-21
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
z RFC 3630: Traffic Engineering Extensions to OSPF Version 2
OSPF Configuration Task List

Complete the following tasks to configure OSPF:
Task Remarks
Configuring OSPF Basic Functions Required
Configuring OSPF Area Parameters Optional
Configuring the OSPF Network Type for an Interface Optional
Configuring OSPF
Configuring an NBMA Neighbor Optional
Network Types
Configuring a Router Priority for an OSPF Interface 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
1-22
Task Remarks
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
Network Optimization Configuring OSPF Authentication Optional
Adding the Interface MTU into DD Packets Optional
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 the Advertisement and Reception of Opaque LSAs Optional

Configuring the OSPF GR Restarter Optional
Configuring OSPF
Configuring the OSPF GR Helper Optional
Graceful Restart
Triggering OSPF Graceful Restart Optional
Configuring OSPF Basic Functions

You need to enable OSPF, specify an interface and area ID first before performing other tasks.
Prerequisites
Before configuring OSPF, you have configured the link layer protocol, and IP addresses for interfaces,
making neighboring nodes accessible with each other at the network layer.
To ensure OSPF stability, you need to decide on router IDs and configure them manually. Any two
routers in an AS must have different IDs. In practice, the ID of a router is the IP address of one of its
interfaces.
The system supports OSPF multi-process. When a router runs multiple OSPF processes, you need to
specify an 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.
The system supports OSPF multi-instance. You can configure an OSPF process to run in a specified
VPN instance to configure an association between the two.
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-23
Follow these steps to configure OSPF basic functions:
Required
ospf [ process-id | router-id Not enabled by default
Enable OSPF and enter its
router-id | vpn-instance Support for vpn-instance
view
instance-name ] * instance-name varies by
device.
Configure a description for the Optional

description description
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 the Optional

description description
area Not configured by default
Specify a network to enable Required
network ip-address
OSPF on the interface attached
wildcard-mask Not configured by default
to the network
z An OSPF process ID is unique, including the process ID for OSPF multi-instance, which cannot be
the same as any previously configured ID.
z Support for the keyword and argument combination vpn-instance instance-name varies by
device.
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 Area Parameters

Splitting an OSPF AS into multiple areas reduces the number of LSAs in the networks and extends the
OSPF application. For those non-backbone areas residing on the AS boundary, you can configure them
as stub areas to further reduce the size of routing tables on routers in these areas and the number of
LSAs.
A stub area cannot redistribute routes, and for this reason, NSSA was introduced. In NSSA areas,
Type-7 LSAs (NSSA External LSAs) can be advertised. Type 7 LSAs originate from the ASBR in a
NSSA area. When arriving at the ABR in the NSSA area, these LSAs will be translated into type 5 LSAs
for advertisement to other areas.
Non-backbone areas exchange routing information via the backbone area. Therefore, the backbone
and non-backbone areas, including the backbone itself must maintain connectivity.
1-24
If necessary physical links are not available for this connectivity maintenance, 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.
Follow these steps to configure OSPF area parameters:
ospf [ process-id | router-id

Enter OSPF view router-id | vpn-instance
instance-name ] *
Enter area view area area-id Required
Configure the area as a stub Optional

stub [ no-summary ]
area Not configured by default
nssa
Configure the area as an NSSA [ default-route-advertise | Optional
area no-import-route | Not configured by default
no-summary ] *
Specify a cost for the default Optional
route advertised to the stub or default-cost cost
NSSA area Defaults to 1.
vlink-peer router-id [ hello Optional

seconds | retransmit seconds |
Configured on both ends of a
trans-delay seconds | dead
virtual link
Configure a virtual link seconds | simple [ plain |
cipher ] password | { md5 | Note that hello and dead
hmac-md5 } key-id [ plain | parameters must be identical
cipher ] password ] * on both ends of the link.
Optional
Advertise a host route host-advertise ip-address cost
Not advertised by default
z It is required to use the stub command on routers attached to a stub area.

z It is required to use the nssa command on routers attached to an NSSA area.
z Using the default-cost command only takes effect on the ABR of a stub area or the ABR/ASBR of
an NSSA area.
1-25
Configuring OSPF Network Types
OSPF classifies networks into four types upon link layer protocols. Since an NBMA network must be
fully meshed, namely, any two routers in the network must have a virtual link in between. In most cases,
however, the requirement cannot be satisfied, so you need to change the network type using
commands.
For routers having no direct link in between, you can configure the P2MP type for the related interfaces.
If a router in the NBMA network has only a single peer, you can configure the P2P type for the related
interfaces.
In addition, when configuring broadcast and NBMA networks, you can specify for interfaces router
priorities for DR/BDR election. In practice, the routers having higher reliability should become the
DR/BDR.
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
Follow these steps to configure the OSPF network type for an interface:
interface-number
Optional
ospf network-type Not configured by default
Configure a network type { broadcast | nbma | p2mp | The network type of an
p2p } interface depends on the media
type of the interface.
z Configuring a new network type for an interface overwrites the previous one (if any).
z If the two interfaces on a link are both configured as the broadcast, NBMA or P2MP type, they can
not establish the neighbor relationship unless they are on the same network segment.
Configuring an NBMA Neighbor
For NBMA interfaces that cannot broadcast hello packets to find neighbors, you need to specify the IP
addresses and DR priorities of neighbors manually.
Follow these steps to configure a neighbor and its DR priority:
1-26
ospf [ process-id | router-id router-id |

Enter OSPF view
vpn-instance instance-name ] *
Specify an NBMA neighbor and
peer ip-address [ dr-priority dr-priority ] Required
its DR priority
Configuring a Router Priority for an OSPF Interface
For broadcast or NBMA interfaces, you can configure router priorities for DR/BDR election.
Follow these steps to configure a router priority for an OSPF interface:
interface-number
Configure a router priority for Optional

ospf dr-priority priority
the interface The default router priority is 1.
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 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:

z IP addresses for interfaces
z OSPF basic functions
z Corresponding filters if routing information filtering is needed.
1-27
Configuring OSPF Route Summarization
OSPF route summarization includes:

z Configuring route summarization between OSPF areas on an ABR
z Configuring route summarization when redistributing routes into OSPF on an ASBR
Follow these steps to configure route summarization between OSPF areas on an ABR:

Enter OSPF view
Enter OSPF area view area area-id Required
abr-summary ip-address { mask | Required

Configure ABR route
mask-length } [ advertise | Available on an ABR only
summarization
not-advertise ] [ cost cost ] Not configured by default
Follow these steps to configure route summarization when redistributing routes into OSPF on an ASBR:

Enter OSPF view
vpn-instance instance-name ]*
asbr-summary ip-address { mask | Required

Configure ASBR route
mask-length } [ tag tag | not-advertise Available on an ASBR only
summarization
| cost cost ] * Not configured by default
Configuring OSPF Inbound Route Filtering
Follow these steps to configure inbound route filtering:

Enter OSPF view Required
filter-policy { acl-number | ip-prefix Required
Configure inbound route
ip-prefix-name | gateway
filtering Not configured by default
ip-prefix-name } import
Since OSPF is a link state-based interior gateway protocol, routing information is contained in LSAs.
However, OSPF cannot filter LSAs. Using the filter-policy import command is to filter routes
computed by OSPF, and only routes not filtered out are installed into the routing table.
1-28
Configuring ABR Type-3 LSA Filtering
Follow these steps to configure Type-3 LSA filtering on an ABR:

Enter OSPF view
Enter area view area area-id
Configure ABR Type-3 filter { acl-number | ip-prefix Required

LSA filtering ip-prefix-name } { import | export } Not configured by default
Configuring an OSPF Cost for an Interface
Follow these steps to configure an OSPF cost for an interface:
interface-number
Optional
Configure an OSPF By default, an interface computes its cost
ospf cost value
cost for the interface according to the bandwidth.
The cost value defaults to 1 for VLAN interfaces.
Follow these steps to configure a bandwidth reference value:

Enter OSPF view
Configure a bandwidth Optional

bandwidth-reference value
reference value The value defaults to 100 Mbps.
If no OSPF cost is configured for an interface, OSPF computes the cost automatically: Interface OSPF
cost= Bandwidth reference value/Interface bandwidth. If the calculated cost is greater than 65535, the
value of 65535 is used.
Configuring the Maximum Number of OSPF Routes
Follow these steps to configure the maximum number of routes:
1-29

Enter OSPF view
Optional
Configure the maximum maximum-routes { external | inter |
number of OSPF routes intra } number The number varies with
devices.
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
load-balanced routes The default varies by device.
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:
ospf [ process-id | router-id router-id

Enter OSPF view
| vpn-instance instance-name ] *
Optional
The priority of OSPF internal
Configure a priority for preference [ ase ] [ route-policy
routes defaults to 10.
OSPF route-policy-name ] value
The priority of OSPF external
routes defaults to 150.
1-30
Configuring OSPF Route Redistribution
Follow these steps to configure OSPF route redistribution:

Enter OSPF view
import-route protocol [ process-id |
Configure OSPF to Required
all-processes | allow-ibgp ] [ cost
redistribute routes from
cost | type type | tag tag | Not configured by default
another protocol
route-policy route-policy-name ] *
Configure OSPF to filter filter-policy { acl-number | ip-prefix Optional
redistributed routes ip-prefix-name } export [ protocol
before advertisement [ process-id ] ] Not configured by default
default-route-advertise [ always |
cost cost | type type | route-policy
Redistribute a default Optional
route Not redistributed by default
default-route-advertise summary
cost cost
Optional
Configure the default By default, the default cost is 1,
parameters for default upper limit of routes
default { cost cost | limit limit | tag tag
redistributed routes redistributed per time is 1000,
| type type } *
(cost, route number, tag default tag is 1 and default type
and type) of redistributed routes is
Type-2.
z Using the import-route command cannot redistribute a default external route. To do so, you need
to use the default-route-advertise command.
z 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.
z By filtering redistributed routes, OSPF adds only routes, which are not filtered out, into Type-5
LSAs or Type-7 LSAs for advertisement.
z 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 as AS IDs.
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.
1-31
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:

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
The hello interval on P2P, Broadcast
Specify the hello interval ospf timer hello seconds interfaces defaults to 10 seconds and
defaults to 30 seconds on P2MP and
NBMA interfaces.
Optional
Specify the poll interval ospf timer poll seconds
The poll interval defaults to 120 seconds.
Optional
Specify the dead interval ospf timer dead seconds The default dead interval is 40 seconds on
P2P, Broadcast interfaces and 120
seconds on P2MP and NBMA interfaces.
Optional
Specify the ospf timer retransmit
retransmission interval interval The retransmission interval defaults to 5
seconds.
1-32
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:
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
maximum-interval [ minimum-interval By default, the interval is 5
calculation interval(s)
[ incremental-interval ] ] seconds.
1-33
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-interval2n-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:

instance-name ] *
Configure the LSA minimum Optional

lsa-arrival-interval interval
repeat arrival interval Defaults to 1000 milliseconds.
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:

Optional
lsa-generation-interval By default, the maximum interval is
Configure the LSA
maximum-interval [ initial-interval 5 seconds, the minimum interval is 0
generation interval
[ incremental-interval ] ] milliseconds and the incremental
interval is 5000 milliseconds.
1-34
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-interval2n-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:

Enter OSPF view
Disable interfaces from silent-interface { all | interface-type Optional

sending OSPF packets interface-number } Not disabled by default
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.
1-35
Follow these steps to configure a router as a stub router:

Enter OSPF view
Configure the router as Required

stub-router
a stub router Not configured by default
A stub router has nothing to do with a stub area.
Configuring OSPF Authentication
By supporting packet authentication, OSPF receives packets that pass the authentication only, so failed
packets cannot establish neighboring relationships.
Follow these steps to configure OSPF authentication:

Enter OSPF view
Enter area view area area-id
Required
Configure the authentication mode authentication-mode { simple | md5 } Not configured
by default
Exit to OSPF view quit
interface-number
Configure the authentication mode ospf authentication-mode simple
(simple authentication) for the interface [ plain | cipher ] password Optional
ospf authentication-mode { md5 | Not configured
Configure the authentication mode by default
hmac-md5 } key-id [ plain | cipher ]
(MD5 authentication) for the interface
password
The authentication mode and password for all interfaces attached to the same area must be identical.
1-36
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:

instance-name ] *
Specify the maximum number Optional

lsdb-overflow-limit number
of external LSAs in the LSDB No limitation by default
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.
Follow these steps to make them compatible:

Make RFC1583 Optional

rfc1583 compatible
compatible Compatible by default
1-37
Logging Neighbor State Changes

Enter OSPF view
Enable the logging of neighbor Optional

log-peer-change
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.)
Follow these steps to configure OSPF network management:
Optional
Bind OSPF MIB to
ospf mib-binding process-id The first OSPF process is bound
an OSPF process
with OSPF MIB by default.
snmp-agent trap enable ospf

[ process-id ] [ ifauthfail | ifcfgerror |
ifrxbadpkt | ifstatechange |
iftxretransmit | lsdbapproachoverflow Optional
Enable OSPF trap
| lsdboverflow | maxagelsa |
generation Enabled by default
nbrstatechange | originatelsa |
vifcfgerror | virifauthfail | virifrxbadpkt
| virifstatechange | viriftxretransmit |
virnbrstatechange ] *
Enter OSPF view
Enable messages Optional

enable log [ config | error | state ]
logging Not enabled by default
1-38
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 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:

ospf [ process-id | router-id Required
router-id | vpn-instance
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

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:
1-39
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

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 ] *
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
1-40
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-41
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 neighbor display ospf [ process-id ] peer [ verbose |
information [ interface-type interface-number ] [ 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
Display routing table Available in
interface-type interface-number ] [ nexthop
information any view
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
1-42
OSPF Configuration Examples (on Routers)
These examples only cover the commands related to OSPF configuration.
As shown in the following figure, all routers run OSPF. The AS is split into three areas, in which, Router
A and Router B act as ABRs.
After configuration, all routers can learn routes to every network segment in the AS.
Network diagram
Figure 1-21 Network diagram for OSPF basic configuration

2) Configure OSPF basic functions
[RouterA] ospf
[RouterB] ospf
1-43
[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterD] ospf
[RouterD-ospf-1] area 2
3) Verify the above configuration
# Display the OSPF neighbors of Router A.
[RouterA] 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(Ethernet1/0)'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
1-44
# Display OSPF routing information on Router A.

[RouterA] display ospf routing

Routing Tables
Routing for Network

Destination Cost Type NextHop AdvRouter Area
10.2.1.0/24 1 Transit 10.2.1.1 10.2.1.1 0.0.0.1
10.3.1.0/24 2 Inter 10.1.1.2 10.3.1.1 0.0.0.0
10.4.1.0/24 2 Stub 10.2.1.2 10.4.1.1 0.0.0.1
10.5.1.0/24 3 Inter 10.1.1.2 10.3.1.1 0.0.0.0
10.1.1.0/24 1 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 Router A.

[RouterA] 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 1
Sum-Net 10.2.1.0 10.2.1.1 1069 28 8000000F 2
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 1
Area: 0.0.0.1
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 3
Sum-Net 10.3.1.0 10.2.1.1 1069 28 8000000F 2
Sum-Net 10.1.1.0 10.2.1.1 1069 28 8000000F 1
Sum-Asbr 10.3.1.1 10.2.1.1 1069 28 8000000F 1
# Display OSPF routing information on Router D.

[RouterD] display ospf routing
1-45
Routing Tables
Routing for Network

10.2.1.0/24 3 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.3.1.0/24 1 Transit 10.3.1.2 10.3.1.1 0.0.0.2
10.4.1.0/24 4 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.5.1.0/24 1 Stub 10.5.1.1 10.5.1.1 0.0.0.2
10.1.1.0/24 2 Inter 10.3.1.1 10.3.1.1 0.0.0.2
Total Nets: 5
# Ping 10.4.1.1 to check connectivity.

[RouterD] ping 10.4.1.1
Request time out

20.00% packet loss
z All the routers run OSPF, and the AS is divided into three areas.
z Router A and Router B act as ABRs to forward routes between areas.
z Router C is configured as an ASBR to redistribute external routes (static routes). Routing
information is propagated properly in the AS.
1-46
Network diagram
Figure 1-22 Network diagram for OSPF redistributing routes from outside of an AS

2) Configure OSPF basic functions (Refer to Configuring OSPF Basic Functions).
3) Configure OSPF to redistribute routes.
# On Router C, configure a static route destined for network 3.1.2.0/24.
# On Router C, configure OSPF to redistribute the static route.

[RouterC] ospf 1
[RouterC-ospf-1] import-route static
# Display the ABR/ASBR information of Router D.
<RouterD> 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 Router D.

<RouterD> 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
1-47
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 an OSPF Stub Area
The following figure shows an AS is split into three areas, where all routers run OSPF. Router A and
Router B act as ABRs to forward routing information between areas. Router D acts as the ASBR and is
enabled to redistribute static routes.
It is required to configure Area 1 as a Stub area, reducing LSAs to this area without influencing route
reachability.
Network diagram
Figure 1-23 OSPF Stub area configuration

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

[RouterC] display ospf abr-asbr
1-48

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 information on Router C.

[RouterC] 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 Router C resides in a normal OSPF area, its routing table contains an
external route.
4) Configure Area1 as a Stub area

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub
[RouterC] ospf
[RouterC-ospf-1-area-0.0.0.1] stub
1-49
# Display routing information on Router 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
After the area where Router C resides is configured as a Stub area, a default route takes the place of
the external route.
# Filter Type-3 LSAs out the Stub area.

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub no-summary
# Display OSPF routing information on Router 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
Total Nets: 3
1-50
After this configuration, route entries on the stub router are further reduced, containing only the default
external route.
Configuring an OSPF NSSA Area
The following figure shows an AS is split into three areas, where all routers run OSPF. Router A and
Router B act as ABRs to forward routing information between areas.
Configure Area 1 as an NSSA area, and configure Router C as an ASBR to redistribute static routes into
the AS.
Network diagram
Figure 1-24 OSPF NSSA area configuration network diagram

2) Configuring OSPF basic functions (refer to Configuring OSPF Basic Functions).
3) Configure Area 1 as an NSSA area.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa
[RouterC] ospf
[RouterC-ospf-1-area-0.0.0.1] nssa
1-51
It is recommended to configure the nssa command with the keyword default-route-advertise
no-summary on Router A (an ABR) to reduce the routing table size on NSSA routers. On other NSSA
routers, you only need to configure the nssa command.
# Display routing information on Router C


Routing Tables
Routing for Network

10.2.1.0/24 3 Transit 10.2.1.2 10.4.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: 5
4) Configure Router C to redistribute static routes
[RouterC] ospf
[RouterC-ospf-1] import-route static
# Display routing information on Router D.

[RouterD] 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

3.1.2.0/24 1 Type2 1 10.3.1.1 10.2.1.1
1-52
Total Nets: 6
You can see on Router D an external route imported from the NSSA area.
Configuring OSPF DR Election
In the following figure:

z Router A, B, C and D are on the same network, running OSPF.
z Configure Router A as the DR, and configure Router C as the BDR.
Network diagram
Figure 1-25 Network diagram for OSPF DR election configuration

[RouterA] router id 1.1.1.1
[RouterA] ospf
[RouterB] router id 2.2.2.2
[RouterB] ospf
1-53
[RouterC] router id 3.3.3.3
[RouterC] ospf
[RouterD] router id 4.4.4.4
[RouterD] ospf
[RouterD-ospf-1] area 0
# Display neighbor information on Router A.


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
Router D becomes the DR, and Router C becomes the BDR.
1-54
3) Configure router priorities on interfaces
[RouterA-Ethernet1/0] ospf dr-priority 100
[RouterB-Ethernet1/0] ospf dr-priority 0
[RouterC-Ethernet1/0] ospf dr-priority 2
# Display information about neighbors on Router D.

[RouterD] 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-55
In the above output, you can find the priority configuration does not take effect immediately.
4) Restart the OSPF process (omitted)

# Display neighbor information on Router D.
[RouterD] 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

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
Router A becomes the DR, and Router C becomes the BDR.
In the above output, the full neighbor state means an adjacency has been established. The 2-way
neighbor state means the two routers are neither the DR nor the BDR, and they do not exchange LSAs.
# Display OSPF interface information

[RouterA] display ospf interface

Interfaces
1-56
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
[RouterB] display ospf interface

Interfaces
Area: 0.0.0.0
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
In the following figure, Area 2 has no direct connection to Area 0, the backbone, and Area 1 acts as the
Transit Area to connect Area2 to Area0 via a virtual link between Router A and Router B.
After configuration, Router A can learn routes to Area 2.
Network diagram
Figure 1-26 Network diagram for OSPF virtual link configuration

[RouterA] ospf 1 router-id 1.1.1.1
1-57
[RouterB] ospf 1 router-id 2.2.2.2
[RouterBospf-1-area-0.0.0.2] network 172.16.0.0 0.0.255.255
[RouterBospf-1-area-0.0.0.2] quit

Routing Tables
Routing for Network

10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1562 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
Since Area 2 has no direct connection to Area 0, the OSPF routing table of Router A has no route to
Area2.
3) Configure a virtual link

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[RouterB] ospf 1
[RouterB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1
1-58

Routing Tables
Routing for Network

172.16.1.1/16 1563 Inter 192.168.1.2 2.2.2.2 0.0.0.0
10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1562 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3
Router A has learned the route 172.16.1.1/16 to Area 2.
Configuring OSPF Graceful Restart
z Router A, Router B and Router C that belong to the same autonomous system and the same OSPF
routing domain are GR capable.
z Router A acts as the non IETF standard GR Restarter, and Router B and Router C are the GR
Helpers and remain OOB synchronized with Router A through the GR mechanism.
Network diagram
Figure 1-27 Network diagram for OSPF-based GR configuration (on routers)

Router ID: 1.1.1.1
GR restarter
Router A
Eth1/0
192.1.1.1/24
Eth1/0 Eth1/0
192.1.1.2/24 192.1.1.3/24
Router B Router C
GR helper GR helper
Router ID: 2.2.2.2 Router ID: 3.3.3.3
[RouterA] router id 1.1.1.1
[RouterA] ospf 100
[RouterA-ospf-100] enable link-local-signaling
[RouterA-ospf-100] enable out-of-band-resynchronization
[RouterA-ospf-100] graceful-restart
1-59
[RouterA-ospf-100-area-0.0.0.0] return
[RouterB] acl number 2000
[RouterB-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[RouterB-acl-basic-2000] quit
[RouterB] router id 2.2.2.2
[RouterB] ospf 100
[RouterB-ospf-100] enable link-local-signaling
[RouterB-ospf-100] enable out-of-band-resynchronization
[RouterB-ospf-100] graceful-restart help 2000
[RouterC-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[RouterC-acl-basic-2000] quit
[RouterC] router id 3.3.3.3
[RouterC] ospf 100
[RouterC-ospf-100] enable link-local-signaling
[RouterC-ospf-100] enable out-of-band-resynchronization
[RouterC-ospf-100] graceful-restart help 2000
# Perform OSPF Graceful Restart on Router A if all routers function properly after the above
configurations.
<RouterA> reset ospf 100 process graceful-restart
OSPF Configuration Examples (on Switches)
These examples only cover commands for OSPF configuration.
1-60
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.
After configuration, all switches can learn routes to every network segment in the AS.
Network diagram
Figure 1-28 Network diagram for OSPF basic configuration

[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
[SwitchB] ospf
[SwitchB-ospf-1] area 0
# Configure Switch C
1-61
[SwitchC] ospf
[SwitchC-ospf-1] area 1
# Configure Switch D
[SwitchD] ospf
[SwitchD-ospf-1] area 2
# Display information about neighbors on Switch A.
[SwitchA] display ospf peer verbose

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

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
Neighbors

DR: 10.2.1.1 BDR: 10.2.1.2 MTU: 0
# Display OSPF routing information on Switch A.

[SwitchA] display ospf routing

Routing Tables
1-62
Routing for Network
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
# Display the Link State Database on Switch A.

[SwitchA] display ospf lsdb

Link State Database
Area: 0.0.0.0
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
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-63
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
Request time out

20.00% packet loss
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-29 Network diagram for OSPF redistributing routes from outside of an AS

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-64
[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
# Display the ABR/ASBR information of Switch D.
<SwitchD> display ospf abr-asbr


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

3.1.2.0/24 1 Type2 1 10.3.1.1 10.4.1.1
Total Nets: 6
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.
1-65
Network diagram
Figure 1-30 Network diagram for OSPF Stub area configuration

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
# Display ABR/ASBR information on Switch C.

[SwitchC] display ospf abr-asbr


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
1-66
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
[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
1-67
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
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.
1-68
Network diagram
Figure 1-31 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
[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, using the nssa command is ok.
# Display OSPF routing information on Switch C.


Routing Tables
Routing for Network
1-69
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] ip route-static 3.1.3.1 24 11.1.1.1
[SwitchC] ospf
[SwitchC-ospf-1] import-route static
# 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

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.
1-70
Network diagram
Figure 1-32 Network diagram for OSPF DR election configuration

Switch A Switch D
DR
Vlan-int1 Vlan-int1
196.1.1.1/24 196.1.1.4/24
Vlan-int1 Vlan-int1
196.1.1.2/24 196.1.1.3/24
BDR
Switch B Switch C

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


Neighbors

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
Switch D becomes the DR, and Switch C is the BDR.

3) Configure router priorities on interfaces
[RouterA-Vlan-interface1] ospf dr-priority 100
[RouterA-Vlan-interface1] quit
[SwitchB-Vlan-interface1] ospf dr-priority 0
[SwitchC-Vlan-interface1] ospf dr-priority 2
[SwitchC-Vlan-interface] quit
# Display neighbor information on Switch D.
1-72
[SwitchD] display ospf peer verbose

Neighbors

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.
In the above output, you can find the priority configuration does not take effect immediately.
4) Restart OSPF process (omitted)

# Display neighbor information on Switch D.
[SwitchD] display ospf peer verbose

Neighbors

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
1-73
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

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.
# Display OSPF interface information.

[SwitchA] display ospf interface

Interfaces
Area: 0.0.0.0
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
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.
1-74
Configuring OSPF Virtual Links
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 A and Switch B.
After configuration, Switch A can learn routes to Area 2.
Network diagram
Figure 1-33 Network diagram for OSPF virtual link configuration

[SwitchA] ospf 1 router-id 1.1.1.1
[SwitchB] ospf 1 router-id 2.2.2.2
[SwitchBospf-1-area-0.0.0.2] network 172.16.0.0 0.0.255.255
[SwitchBospf-1-area-0.0.0.2] quit

Routing Tables
Routing for Network
1-75
10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1562 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
Since Area 2 has no direct connection to Area 0, the OSPF routing table of Router A has no route to
Area 2.
3) Configure a virtual link

[SwitchA] ospf
[SwitchA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[SwitchB] ospf 1
[SwitchB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1


Routing Tables
Routing for Network

172.16.1.1/16 1563 Inter 192.168.1.2 2.2.2.2 0.0.0.0
10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1562 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3
Switch A has learned the route 172.16.1.1/16 to Area2.
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.
1-76
z Switch A acts as the non IETF standard GR Restarter whereas Switch B and Switch C are the GR
Helpers and remain OOB synchronized with Switch A through the GR mechanism.
Network diagram
Figure 1-34 Network diagram for OSPF-based GR configuration

Router ID: 1.1.1.1
GR restarter
Switch A
Vlan-int100
192.1.1.1/24
192.1.1.2/24 192.1.1.3/24
Switch B Switch C
GR helper GR helper
Router ID: 2.2.2.2 Router ID: 3.3.3.3
[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-Vlan-interface100] ospf dr-priority 0
[SwitchB] router id 2.2.2.2
[SwitchB] ospf 100
[SwitchB-ospf-100] graceful-restart help 2000
1-77
[SwitchC-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[SwitchC-acl-basic-2000] quit
[SwitchC-Vlan-interface100] ip address 192.1.1.3 255.255.255.0
[SwitchC-Vlan-interface100] ospf dr-priority 2
[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, perform OSPF GR on Switch A.
<SwitchA> reset ospf 100 process graceful-restart
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), network type. If the
network type is broadcast or NBMA, at least one interface must have a router priority higher than 0.
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 routers 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 router priority
higher than 0.
Incorrect Routing Information
Symptom
OSPF cannot find routes to other areas.
1-78
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-79
Table of Contents
1 RIP Configuration 1-1

RIP Overview 1-1
Operation of RIP1-1
Operation of RIP1-2
RIP Version 1-3
RIP Message Format1-3
TRIP1-5
Supported RIP Features1-5
Configuring RIP Basic Functions 1-6
Configuring RIP Route Control 1-8
Configuring an Additional Routing Metric 1-8
Configuring RIPv2 Route Summarization1-8
Disabling Host Route Reception 1-9
Configuring Inbound/Outbound Route Filtering1-10
Configuring a Priority for RIP1-11
Configuring RIP Route Redistribution 1-11
Configuring RIP Network Optimization 1-12
Configuring RIP Timers 1-12
Configuring Split Horizon and Poison Reverse 1-12
Configuring the Maximum Number of Load Balanced Routes 1-13
Enabling Zero Field Check on Incoming RIPv1 Messages 1-14
Enabling Source IP Address Check on Incoming RIP Updates1-14
Configuring RIPv2 Message Authentication1-14
Specifying a RIP Neighbor 1-15
Configuring TRIP 1-15
Configuring RIP-to-MIB Binding 1-17
Configuring the RIP Packet Sending Rate 1-17
Displaying and Maintaining RIP 1-17
RIP Configuration Examples (on Routers)1-18
RIP Version Configuration 1-18
Configuring an Additional Metric for a RIP Interface 1-22
RIP Configuration Examples (on Switches) 1-24
Configuring RIP Version 1-24
Configuring an Additional Metric for a RIP Interface 1-28
Troubleshooting RIP 1-30
No RIP Updates Received 1-30
Route Oscillation Occurred 1-30
i
1 RIP Configuration
When configuring RIP, go to these sections for information you are interested in:
z RIP Overview
z Configuring RIP Basic Functions
z Configuring RIP Route Control
z Configuring RIP Network Optimization
z Displaying and Maintaining RIP
z RIP Configuration Examples (on Routers)
RIP Overview
RIP is a simple Interior Gateway Protocol (IGP), mainly used in small-sized networks, such as
academic networks and simple LANs. RIP is not applicable to complex networks.
RIP is still widely used in practical networking due to easier implementation, configuration and
maintenance than OSPF and IS-IS.
Operation of RIP
Introduction
RIP is a distance vector routing protocol, using UDP packets for exchanging information through port
520.
RIP uses a hop count to measure the distance to a destination. The hop count from a router to a directly
connected network is 0. The hop count from a router to a directly connected router is 1. To limit
convergence time, the range of RIP metric value is from 0 to 15. A metric value of 16 (or greater) is
considered infinite, which means the destination network is unreachable. That is why RIP is not suitable
for large-scaled networks.
RIP prevents routing loops by implementing the split horizon and poison reverse functions.
1-1
RIP routing table
A RIP router has a routing table containing routing entries of all reachable destinations, and each
routing entry contains:
z Destination address: IP address of a host or a network.
z Next hop: IP address of the adjacent routers interface to reach the destination.
z Egress interface: Packet outgoing interface.
z Metric: Cost from the local router to the destination.
z Route time: Time elapsed since the routing entry was last updated. The time is reset to 0 every time
the routing entry is updated.
z Route tag: Identifies a route, used in a routing policy to flexibly control routes. For information about
routing policy, refer to Routing Policy Configuration in the IP Routing Volume.
RIP timers
RIP employs four timers, update, timeout, suppress, and garbage-collect.

z The update timer defines the interval between routing updates.
z The timeout timer defines the route aging time. If no update for a route is received within the aging
time, the metric of the route is set to 16 in the routing table.
z The suppress timer defines how long a RIP route stays in the suppressed state. When the metric of
a route is 16, the route enters the suppressed state. In the suppressed state, only routes which
come from the same neighbor and whose metric is less than 16 will be received by the router to
replace unreachable routes.
z The garbage-collect timer defines the interval from when the metric of a route becomes 16 to when
it is deleted from the routing table. During the garbage-collect timer length, RIP advertises the route
with the routing metric set to 16. If no update is announced for that route after the garbage-collect
timer expires, the route will be deleted from the routing table.
Routing loops prevention
RIP is a distance vector (D-V) routing protocol. Since a RIP router advertises its own routing table to
neighbors, routing loops may occur.
RIP uses the following mechanisms to prevent routing loops.
z Counting to infinity. The metric value of 16 is defined as unreachable. When a routing loop occurs,
the metric value of the route will increment to 16.
z Split horizon. A router does not send the routing information learned from a neighbor to the
neighbor to prevent routing loops and save bandwidth.
z Poison reverse. A router sets the metric of routes received from a neighbor to 16 and sends back
these routes to the neighbor to help delete such information from the neighbors routing table.
z Triggered updates. A router advertises updates once the metric of a route is changed rather than
after the update period expires to speed up network convergence.
Operation of RIP
The following procedure describes how RIP works.

1) After RIP is enabled, the router sends request messages to neighboring routers. Neighboring
routers return Response messages including information about their routing tables.
1-2
2) After receiving such information, the router updates its local routing table, and sends triggered
update messages to its neighbors. All routers on the network do the same to keep the latest routing
information.
3) By default, a RIP router sends its routing table to neighbors every 30 seconds.
4) RIP ages out routes by adopting an aging mechanism to keep only valid routes.
RIP Version
RIP has two versions, RIPv1 and RIPv2.

RIPv1, a classful routing protocol, supports message advertisement via broadcast only. RIPv1 protocol
messages do not carry mask information, which means it can only recognize routing information of
natural networks such as Class A, B, C. That is why RIPv1 does not support discontiguous subnets.
RIPv2 is a classless routing protocol. Compared with RIPv1, RIPv2 has the following advantages.
z Supporting route tags. Route tags are used in routing policies to flexibly control routes.
z Supporting masks, route summarization and Classless Inter-Domain Routing (CIDR).
z Supporting designated next hops to select the best next hops on broadcast networks.
z Supporting multicast routing update to reduce resource consumption.
z Supporting plain text authentication and MD5 authentication to enhance security.
RIPv2 has two types of message transmission: broadcast and multicast. Multicast is the default type
using 224.0.0.9 as the multicast address. The interface working in the RIPv2 broadcast mode can also
receive RIPv1 messages.
RIP Message Format
RIPv1 message format
A RIPv1 message consists of a header and up to 25 route entries.

Figure 1-1 shows the format of RIPv1 message.
Figure 1-1 RIPv1 Message Format
z Command: Type of message. 1 indicates request, and 2 indicates response.

z Version: Version of RIP, 0x01 for RIPv1.
z AFI: Address Family Identifier, 2 for IP.
1-3
z IP Address: Destination IP address of the route. It can be a natural network, subnet or a host
address.
z Metric: Cost of the route.
RIPv2 message format
The format of RIPv2 message is similar to RIPv1. Figure 1-2 shows it.
Figure 1-2 RIPv2 Message Format
The differences from RIPv1 are stated as following.

z Version: Version of RIP. For RIPv2 the value is 0x02.
z Route Tag: Route Tag.
z IP Address: Destination IP address. It can be a natural network address, subnet address or host
address.
z Subnet Mask: Mask of the destination address.
z Next Hop: If set to 0.0.0.0, it indicates that the originator of the route is the best next hop; otherwise
it indicates a next hop better than the originator of the route.
RIPv2 authentication
RIPv2 sets the AFI field of the first route entry to 0xFFFF to identify authentication information. See
Figure 1-3.
Figure 1-3 RIPv2 Authentication Message
z Authentication Type: A value of 2 represents plain text authentication, while a value of 3 represents
MD5.
z Authentication: Authentication data, including password information when plain text authentication
is adopted or including key ID, MD5 authentication data length and sequence number when MD5
authentication is adopted.
1-4
z RFC 1723 only defines plain text authentication. For information about MD5 authentication, refer to
RFC 2453 RIP Version 2.
z With RIPv1, you can configure the authentication mode in interface view. However, the
configuration will not take effect because RIPv1 does not support authentication.
TRIP
Triggered RIP (TRIP), a RIP extension for WANs, is mainly used in dial-up networks.
Working mechanism
Routing information is sent in triggered updates rather than in periodic broadcasts to reduce route
management cost on WANs.
z A routing update message is sent when data in the routing table changes or the next hop is
unreachable.
z Since the periodic update delivery is canceled, an acknowledgement and retransmission
mechanism is required to guarantee successful updates transmission on WANs.
Message types
RIP uses three new types of message which are identified by the value of the command field.
z Update request (Type-9): Requests the needed routes from the neighbor.
z Update response (Type-10): Contains the routes requested by the neighbor.
z Update Acknowledge (Type-11): Acknowledges received update responses.
TRIP retransmission mechanism
z If receiving no update responses within a specified interval after sending an update request, a
router sends the request again. If still receiving no update response after the upper limit for sending
requests is reached, the router considers the neighbor unreachable.
z If receiving no update acknowledge within a specified interval after sending an update response, a
router sends the update response again. If still receiving no update acknowledge after the upper
limit for sending update responses is reached, the router considers the neighbor unreachable.
Supported RIP Features
The current implementation supports the following RIP features.

z RIPv1 and RIPv2
z RIP multi-instance. RIP can serve as the IGP running between CE and PE on a BGP/MPLS VPN
network. For related information, refer to BGP&MPLS VPN Configuration in the MPLS Volume.
z TRIP
z RFC 1058: Routing Information Protocol

z RFC 1723: RIP Version 2 - Carrying Additional Information
z RFC 1721: RIP Version 2 Protocol Analysis
1-5
z RFC 1722: RIP Version 2 Protocol Applicability Statement
z RFC 1724: RIP Version 2 MIB Extension
z RFC 2082: RIPv2 MD5 Authentication
z RFC 2091: Triggered Extensions to RIP to Support Demand Circuits
z RFC2453: RIP Version 2
Configuring RIP Basic Functions

Before configuring RIP basic functions, complete the following tasks.

z Configure the link layer protocol.
z Configure an IP address on each interface, and make sure all adjacent routers are reachable to
each other.
Enabling RIP and a RIP interface
Follow these steps to enable RIP:

Required
rip [ process-id ]
Enable a RIP process and Not enabled by default
[ vpn-instance
enter RIP view Support for the vpn-instance
vpn-instance-name ]
vpn-instance-name varies by device.
Enable RIP on the Required
interface attached to the network network-address
specified network Disabled by default
z If you make some RIP configurations in interface view before enabling RIP, those configurations
will take effect after RIP is enabled.
z RIP runs only on the interfaces residing on the specified networks. Therefore, you need to specify
the network after enabling RIP to validate RIP on a specific interface.
z You can enable RIP on all interfaces using the command network 0.0.0.0.
Configuring the interface behavior
Follow these steps to configure the interface behavior:

rip [ process-id ]
Enter RIP view [ vpn-instance
vpn-instance-name ]
1-6
Disable an or all interfaces from Optional
silent-interface { all |
sending routing updates (the
interface-type All interfaces can send routing
interfaces can still receive
interface-number } updates by default.
updates)
interface-number
Enable the interface to receive Optional

rip input
RIP messages Enabled by default
Enable the interface to send Optional

rip output
RIP messages Enabled by default
Configuring a RIP version
You can configure a RIP version in RIP or interface view.

z If neither global nor interface RIP version is configured, the interface sends RIPv1 broadcasts and
can receive RIPv1 broadcast and unicast packets, and RIPv2 broadcast, multicast, and unicast
packets.
z If an interface has no RIP version configured, it uses the global RIP version; otherwise it uses the
RIP version configured on it.
z With RIPv1 configured, an interface sends RIPv1 broadcasts, and can receive RIPv1 broadcasts
and RIPv1 unicasts.
z With RIPv2 configured, a multicast interface sends RIPv2 multicasts and can receive RIPv2
unicasts, broadcasts and multicasts.
z With RIPv2 configured, a broadcast interface sends RIPv2 broadcasts and can receive RIPv1
unicasts, and broadcasts, and RIPv2 broadcasts, multicasts and unicasts.
Follow these steps to configure a RIP version:

rip [ process-id ]
Enter RIP view [ vpn-instance
vpn-instance-name ]
Optional
By default, if an interface has a RIP version
specified, the version takes precedence
Specify a global RIP over the global one. If no RIP version is
version { 1 | 2 }
version specified for an interface, the interface can
send RIPv1 broadcasts, and receive RIPv1
broadcasts, unicasts, RIPv2 broadcasts,
multicasts and unicasts.
interface-number
Specify a RIP version rip version { 1 | 2
Optional
for the interface [ broadcast | multicast ] }
1-7
Configuring RIP Route Control
In complex networks, you need to configure advanced RIP features.
This section covers the following topics:
z Configuring an Additional Routing Metric
z Configuring RIPv2 Route Summarization
z Disabling Host Route Reception
z Advertising a Default Route
z Configuring Inbound/Outbound Route Filtering
z Configuring a Priority for RIP
z Configuring RIP Route Redistribution
Before configuring RIP routing feature, complete the following tasks:
z Configure an IP address for each interface, and make sure all neighboring routers are reachable to
each other.
z Configure RIP basic functions
Configuring an Additional Routing Metric
An additional routing metric can be added to the metric of an inbound or outbound RIP route.
The outbound additional metric is added to the metric of a sent route, and the routes metric in the
routing table is not changed.
The inbound additional metric is added to the metric of a received route before the route is added into
the routing table, and the routes metric is changed. If the sum of the additional metric and the original
metric is greater than 16, the metric of the route will be 16.
Follow these steps to configure additional routing metrics:

Define an inbound additional rip metricin [ route-policy route-policy-name ] Optional

routing metric value 0 by default
Define an outbound additional rip metricout [ route-policy route-policy-name ] Optional

routing metric value 1 by default
Configuring RIPv2 Route Summarization
Route summarization means that subnets in a natural network are summarized into a natural network
that is sent to other networks. This feature can reduce the size of routing tables.
Enabling RIPv2 route automatic summarization
You can disable RIPv2 route automatic summarization if you want to advertise all subnet routes.
Follow these steps to enable RIPv2 route automatic summarization:
1-8
rip [ process-id ] [ vpn-instance
Enter RIP view
vpn-instance-name ]
Enable RIPv2 automatic Optional

summary
route summarization Enabled by default
Advertising a summary route
You can configure RIPv2 to advertise a summary route on the specified interface.
To do so, use the following commands:

Enter RIP view
vpn-instance-name ]
Disable RIPv2 automatic route Required

undo summary
summarization Enabled by default
rip summary-address ip-address { mask |
Advertise a summary route Required
mask-length }
You need to disable RIPv2 route automatic summarization before advertising a summary route on an
interface.
Disabling Host Route Reception
Sometimes a router may receive from the same network many host routes, which are not helpful for
routing and consume a large amount of network resources. In this case, you can disable RIP from
receiving host routes to save network resources.
Follow these steps to disable RIP from receiving host routes:

Enter RIP view
vpn-instance-name ]
Disable RIP from receiving host Required

undo host-route
routes Enabled by default
1-9
RIPv2 can be disabled from receiving host routes, but RIPv1 cannot.
You can configure RIP to advertise a default route with a specified metric to RIP neighbors.
z In RIP view, you can configure all the interfaces of the RIP process to advertise a default route; in
interface view, you can configure a RIP interface of the RIP process to advertise a default route.
The latter takes precedence over the former on the interface.
z If a RIP process is enabled to advertise a default route, to disable an interface of the RIP process
from default route advertisement, you can use the rip default-route no-originate command on the
interface.
Follow these steps to configure RIP to advertise a default route:

Enter RIP view
vpn-instance-name ]
Enable RIP to advertise default-route { only | originate } [ cost Optional

a default route cost ] Not enabled by default
interface-number
Optional
Configure the RIP By default, a RIP interface can
rip default-route { { only | originate }
interface to advertise a advertise a default route if the
[ cost cost ] | no-originate }
default route RIP process is configured with
default route advertisement.
The router enabled to advertise a default route does not receive default routes from RIP neighbors.
Configuring Inbound/Outbound Route Filtering
The device supports route filtering. You can filter routes by configuring the inbound and outbound route
filtering policies by referencing an ACL or IP prefix list. You can also configure the router to receive only
routes from a specified neighbor.
Follow these steps to configure route filtering:
1-10
Enter RIP view rip [ process-id ] [ vpn-instance vpn-instance-name ]
Configure the filter-policy { acl-number | gateway ip-prefix-name | Required

filtering of incoming ip-prefix ip-prefix-name [ gateway ip-prefix-name ] } Not configured
routes import [ interface-type interface-number ] by default
Configure the filter-policy { acl-number | ip-prefix ip-prefix-name } Required

filtering of outgoing export [ protocol [ process-id ] | interface-type Not configured
routes interface-number ] by default
z Using the filter-policy import command filters incoming routes. Routes not passing the filtering
will be neither installed into the routing table nor advertised to neighbors.
z Using the filter-policy export command filters outgoing routes, including routes redistributed with
the import-route command.
Configuring a Priority for RIP
Multiple IGP protocols may run in a router. If you want RIP routes to have a higher priority than those
learned by other routing protocols, you can assign RIP a smaller priority value to influence optimal route
selection.
Follow these steps to configure a priority for RIP:

Enter RIP view
vpn-instance-name ]
preference [ route-policy Optional

Configure a priority for RIP
route-policy-name ] value 100 by default
Configuring RIP Route Redistribution
Follow these steps to configure RIP route redistribution:

Enter RIP view
vpn-instance-name ]
Configure a default Optional

metric for redistributed default cost value The default metric of a redistributed
routes route is 0 by default.
1-11

Redistribute routes from [ process-id ] [ allow-ibgp ] [ cost
another protocol cost | route-policy No redistribution is configured by
route-policy-name | tag tag ] * default.
Configuring RIP Network Optimization

Complete the following tasks before configuring RIP network optimization:
z Configure network addresses for interfaces, and make neighboring nodes reachable to each other;
z Configure RIP basic functions.
Configuring RIP Timers
Follow these steps to configure RIP timers:

Enter RIP view
vpn-instance-name ]
timers { garbage-collect Optional

garbage-collect-value | suppress The default update timer, timeout
Configure values for
suppress-value | timeout timer, suppress timer, and
RIP timers
timeout-value | update garbage-collect timer are 30s, 180s,
update-value } * 120s and 120s respectively.
Based on network performance, you need to make RIP timers of RIP routers identical to each other to
avoid unnecessary traffic or route oscillation.
Configuring Split Horizon and Poison Reverse
If both split horizon and poison reverse are configured, only the poison reverse function takes effect.
Enabling split horizon
The split horizon function disables an interface from sending routes received from the interface to
prevent routing loops between adjacent routers.
Follow these steps to enable split horizon:
1-12
interface-number
Optional
Enable split horizon rip split-horizon
Enabled by default
z In Frame Relay, X.25 and other non-broadcast multi-access (NBMA) networks, split horizon should
be disabled if multiple VCs are configured on the primary and secondary interfaces to ensure route
advertisement. For detailed information, refer to Frame Relay Configuration and LAPB and X.25
z Disabling the split horizon function on a point-to-point link does not take effect.
Enabling poison reverse
The poison reverse function allows an interface to advertise the routes received from it, but the metric of
these routes is set to 16, making them unreachable.
Follow these steps to enable poison reverse:

interface-number
Required
Enable poison reverse rip poison-reverse
Disabled by default
Configuring the Maximum Number of Load Balanced Routes
Follow these steps to configure the maximum number of load balanced routes:

Enter RIP view
vpn-instance-name ]

number of load maximum load-balancing number The default maximum number
balanced routes varies by device.
1-13
Enabling Zero Field Check on Incoming RIPv1 Messages
Some fields in the RIPv1 message must be zero. These fields are called zero fields. You can enable
zero field check on received RIPv1 messages. If such a field contains a non-zero value, the RIPv1
message will not be processed. If you are sure that all messages are trusty, you can disable zero field
check to save CPU resources.
Follow these steps to enable zero field check on incoming RIPv1 messages:

Enter RIP view
vpn-instance-name ]
Enable zero field check on Optional

checkzero
received RIPv1 messages Enabled by default
Enabling Source IP Address Check on Incoming RIP Updates
You can enable source IP address check on incoming RIP updates.

For a message received on an Ethernet interface, RIP compares the source IP address of the message
with the IP address of the interface. If they are not in the same network segment, RIP discards the
message.
For a message received on a serial interface, RIP checks whether the source address of the message
is the IP address of the peer interface. If not, RIP discards the message.
Follow these steps to enable source IP address check on incoming RIP updates:

Enter RIP view
vpn-instance-name ]
Enable source IP address Optional
check on incoming RIP validate-source-address
messages Enabled by default
The source IP address check feature should be disabled if the RIP neighbor is not directly connected.
Configuring RIPv2 Message Authentication
RIPv2 supports two authentication modes: plain text and MD5.

In plain text authentication, the authentication information is sent with the RIP message, which however
cannot meet high security needs.
Follow these steps to configure RIPv2 message authentication:
1-14
rip authentication-mode { md5 { rfc2082
Configure RIPv2 authentication key-string key-id | rfc2453 key-string } | Required
simple password }
Specifying a RIP Neighbor
Usually, RIP sends messages to broadcast or multicast addresses. On non broadcast or multicast links,
you need to manually specify RIP neighbors. If a specified neighbor is not directly connected, you must
disable source address check on incoming updates.
Follow these steps to specify a RIP neighbor:

Enter RIP view
vpn-instance-name ]
Specify a RIP neighbor peer ip-address Required
Disable source address check Required

undo validate-source-address
on incoming RIP updates Not disabled by default
You need not use the peer ip-address command when the neighbor is directly connected; otherwise the
neighbor may receive both the unicast and multicast (or broadcast) of the same routing information.
Configuring TRIP
In a connection oriented network, a router may establish connections to multiple remote devices. In a
WAN, links are created and removed as needed. In such applications, a link created between two nodes
for data transmission is temporary and infrequently.
TRIP should be enabled when it is necessary to exchange routing information through on-demand links
or triggered RIP.
Enabling TRIP
Follow these steps to enable TRIP:

Enable RIP Required
vpn-instance-name ]
1-15
Required
Enable TRIP rip triggered
z Support for the rip triggered command varies by device.

z If RIP is disabled, TRIP is also disabled.
Configuring TRIP retransmission parameters
You can specify the interval and count for retransmitting a request or response as needed.
For two routers on an analog dial-up link, the difference between retransmission intervals on the two
ends must be greater than 50 seconds; otherwise, they cannot become TRIP neighbors.
Follow these steps to configure TRIP retransmission parameters:

Enable RIP and enter its view Required
vpn-instance-name ]
Configure the interval for Required

retransmitting an update trip retransmit timer retransmit-time-value 5 seconds by
request or update response default
Configure the maximum count Optional
trip retransmit count
for retransmitting an update
retransmit-count-value 36 by default
request or update response
The maximum retransmission interval (count interval) for a packet cannot be so long that the router
still resends the packet when its neighbor is down,.
1-16
Configuring RIP-to-MIB Binding
Follow these steps to bind RIP to MIB:

Optional
Bind RIP to MIB rip mib-binding process-id By default, MIB is bound to the RIP
process with the smallest process ID
Configuring the RIP Packet Sending Rate
RIP periodically sends routing information in RIP packets to RIP neighbors.

Sending large numbers of RIP packets at the same time may affect device performance and consume
large network bandwidth. To solve this problem, you can specify the maximum number of RIP packets
that can be sent at the specified interval.
Follow these steps to configure the RIP packet sending rate:

rip [ process-id ]
Enable a RIP process and
[ vpn-instance
enter RIP view
vpn-instance-name ]
Optional
number of RIP packets that can output-delay time count count By default, an interface sends
be sent at the specified interval up to three RIP packets every
20 milliseconds.
Displaying and Maintaining RIP

Display RIP current status and display rip [ process-id | vpn-instance
configuration information vpn-instance-name ]
Display all active routes in RIP
display rip process-id database
database
Available in
Display RIP interface display rip process-id interface [ interface-type any view
information interface-number ]
display rip process-id route [ statistics |
Display routing information
ip-address { mask | mask-length } | peer
about a specified RIP process
ip-address ]
Clear the statistics of a RIP Available in
reset rip process-id statistics
process user view
1-17
Support for vpn-instance vpn-instance-name in the display rip [ process-id | vpn-instance
vpn-instance-name ] command varies with devices.
RIP Configuration Examples (on Routers)

RIP Version Configuration
As shown in Figure 1-4, enable RIPv2 on all interfaces on Router A and Router B.
Network diagram
Figure 1-4 Network diagram for RIP version configuration
1) Configure an IP address for each interface (Omitted)

2) Configure basic RIP functions
[RouterA] rip
[RouterB] rip
# Display the RIP routing table on Router A.

[RouterA] display rip 1 route
Route Flags: R - RIP, T - TRIP
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
--------------------------------------------------------------------------
Peer 1.1.1.2 on Ethernet1/0
Destination/Mask Nexthop Cost Tag Flags Sec
1-18
10.0.0.0/8 1.1.1.2 1 0 RA 9
From the routing table, you can see RIPv1 uses natural mask to advertise routing information.
3) Configure a RIP version
# Configure RIP version 2 on Router A.
[RouterA] rip
[RouterA-rip-1] version 2
[RouterA-rip-1] undo summary
# Configure RIPv2 on Router B.

[RouterB] rip
[RouterB-rip-1] version 2
[RouterB-rip-1] undo summary
# Display the RIP routing table of Router A.

[RouterA] display rip 1 route
--------------------------------------------------------------------------
Peer 1.1.1.2 on Ethernet1/0
10.0.0.0/8 1.1.1.2 1 0 RA 87
10.1.1.0/24 1.1.1.2 1 0 RA 19
10.2.1.0/24 1.1.1.2 1 0 RA 19
From the routing table, you can see RIPv2 uses classless subnet mask.
Since RIPv1 routing information has a long aging time, it will still exist before being aged out after RIPv2
is configured.
As shown in Figure 1-5, two RIP processes are running on Router B, which communicates with Router
A through RIP100 and with Router C through RIP 200.
Configure route redistribution on Router B, letting the two RIP processes redistribute routes from each
other. Set the cost of redistributed routes from RIP 200 to 3. Configure a filtering policy on Router B to
filter out the route 4.1.1.1/24 from RIP200, making the route not advertised to Router A.
1-19
Network diagram
Figure 1-5 Network diagram for RIP route redistribution configuration

2) Configure RIP basic functions
# Enable RIP 100, and configure a RIP version of 2 on Router A.
[RouterA] rip 100
# Enable RIP 100 and RIP 200, configure RIP version as 2 on Router B.
[RouterB] rip 100
[RouterB] rip 200
# Enable RIP 200 and configure RIP version as 2 on Router C.

[RouterC] rip 200
[RouterC-rip-200] version 2
[RouterC-rip-200] undo summary
# Display the routing table of Router A.

1-20
1.1.1.0/24 Direct 0 0 1.1.1.1 Eth1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/1
2.1.1.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
3) Configure RIP route redistribution
# Configure RIP processes 100 and 200 to redistribute routes from each other on Router B.
[RouterB] rip 100
[RouterB-rip-100] default cost 3
[RouterB-rip-100] import-route rip 200
[RouterB] rip 200
[RouterB-rip-200] import-route rip 100
# Display the routing table of Router A.

1.1.1.0/24 Direct 0 0 1.1.1.1 Eth1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/1
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
4.1.1.0/24 RIP 100 4 1.1.1.2 Eth1/0
5.1.1.0/24 RIP 100 4 1.1.1.2 Eth1/0
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) Configure a filtering policy for redistributed routes
# On Router B, define ACL 2000 and reference it to a filtering policy to filter routes redistributed from
RIP 200.
[RouterB-acl-basic-2000] rule deny source 4.1.1.1 0.0.0.255
[RouterB-acl-basic-2000] rule permit
[RouterB] rip 100
[RouterB-rip-100] filter-policy 2000 export rip 200
# Display the routing table on Router A.

1-21
1.1.1.0/24 Direct 0 0 1.1.1.1 Eth1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/1
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
5.1.1.0/24 RIP 100 4 1.1.1.2 Eth1/0
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 Additional Metric for a RIP Interface
z RIPv2 is enabled on all the interfaces of Router A, Router B, Router C, Router D, and Router E.
z Router A has two links to Router D. The link from Router B to Router D is more stable than that from
Router C to Router D. Configure an additional metric for RIP routes received through Ethernet 1/1
on Router A so that Router A prefers the network 1.1.5.0/24 learned from Router B.
Network diagram
Figure 1-6 Network diagram for RIP interface additional metric configuration
1) Configure IP addresses for the interfaces (omitted).

2) Configure RIP basic functions.
[RouterA] rip
[RouterB] rip
1-22
[RouterB] rip
[RouterC-rip-1] version 2
[RouterC-rip-1] undo summary
[RouterD] rip
[RouterD-rip-1] network 1.0.0.0
[RouterD-rip-1] version 2
[RouterD-rip-1] undo summary
# Configure Router E.
[RouterE] rip
[RouterE-rip-1] network 1.0.0.0
[RouterE-rip-1] version 2
[RouterE-rip-1] undo summary
# Display the IP routing table of Router A.

[RouterA] display rip 1 database
1.0.0.0/8, cost 0, ClassfulSumm
1.1.1.0/24, cost 0, nexthop 1.1.1.1, Rip-interface
1.1.3.0/24, cost 1, nexthop 1.1.1.2
1.1.4.0/24, cost 1, nexthop 1.1.2.2
1.1.5.0/24, cost 2, nexthop 1.1.1.2
1.1.5.0/24, cost 2, nexthop 1.1.2.2
The display shows that there are two RIP routes to network 1.1.5.0/24. Their nexthops are Router B
(1.1.1.2) and Router C (1.1.2.2) respectively, with the same cost of 2. Router C is the nexthop router to
reach network 1.1.4.0/24, with a cost of 1.
3) Configure an additional metric for the RIP interface.
# Configure an additional metric of 3 for Ethernet 1/1 on Router A.
[RouterA-Ethernet1/1] rip metricin 3
[RouterA-Ethernet1/1] display ip routing-table
1.1.3.0/24, cost 1, nexthop 1.1.1.2
1.1.4.0/24, cost 4, nexthop 1.1.2.2
1.1.5.0/24, cost 2, nexthop 1.1.1.2
The display shows that there is only one RIP route to network 1.1.5.0/24, with the nexthop as Router B
(1.1.1.2) and a cost of 2. Router C is the nexthop router to reach network 1.1.4.0/24, with a cost of 4.
1-23
RIP Configuration Examples (on Switches)
Configuring RIP Version
As shown in Figure 1-7, enable RIPv2 on all interfaces on Switch A and Switch B.
Network diagram
Figure 1-7 Network diagram for RIP version configuration
1) Configure an IP address for each interface (only the IP address configuration for the VLAN
interfaces is given in the following examples)
[SwitchA] vlan 100
[SwitchB] vlan 100
2) Configure basic RIP functions
[SwitchA] rip
[SwitchA-rip-1] network 192.168.1.0
[SwitchB] rip
[SwitchB-rip-1] network 192.168.1.0
# Display the RIP routing table of Switch A.

[SwitchA] display rip 1 route
1-24
--------------------------------------------------------------------------
Peer 192.168.1.2 on Vlan-interface100
10.0.0.0/8 192.168.1.2 1 0 RA 11
From the routing table, you can find that RIPv1 uses a natural mask.
3) Configure RIP version
# Configure RIPv2 on Switch A.
[SwitchA] rip
[SwitchA-rip-1] version 2
[SwitchA-rip-1] undo summary
# Configure RIPv2 on Switch B.

[SwitchB] rip
[SwitchB-rip-1] version 2
[SwitchB-rip-1] undo summary
# Display the RIP routing table on Switch A.

[SwitchA] display rip 1 route
--------------------------------------------------------------------------
Peer 192.168.1.2 on Vlan-interface100
10.0.0.0/8 192.168.1.2 1 0 RA 50
10.2.1.0/24 192.168.1.2 1 0 RA 16
10.1.1.0/24 192.168.1.2 1 0 RA 16
From the routing table, you can see RIPv2 uses classless subnet mask.
Since RIPv1 routing information has a long aging time, it will still exist until it ages out after RIPv2 is
configured.
As shown in Figure 1-8, two RIP processes are running on Switch B, which communicates with Switch
A through RIP100 and with Switch C through RIP 200.
Configure route redistribution on Switch B, letting the two RIP processes redistribute routes from each
other. Set the cost of redistributed routes from RIP 200 to 3. Configure a filtering policy on Switch B to
filter out the route 4.1.1.1/24 from RIP200, making the route not advertised to Switch A.
1-25
Network diagram
Figure 1-8 Network diagram for RIP route redistribution configuration
1) Configure an IP address for each interface (Omitted).

2) Configure basic RIP functions.
# Enable RIP 100 and specify RIP version 2 on Switch A.
[SwitchA] rip 100
[SwitchA-rip-100] quit
# Enable RIP 100 and RIP 200 and specify RIP version 2 on Switch B.
[SwitchB] rip 100
[SwitchB-rip-100] quit
[SwitchB] rip 200
# Enable RIP 200 and specify RIP version 2 on Switch C.

[SwitchC] rip 200
[SwitchC-rip-200] network 3.0.0.0
[SwitchC-rip-200] version 2
[SwitchC-rip-200] undo summary
# Display the routing table of Switch A.

[SwitchA] display ip routing-table
1-26
1.1.1.0/24 Direct 0 0 1.1.1.1 Vlan100

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Vlan101
2.1.1.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
3) Configure route redistribution
# Configure route redistribution between the two RIP processes on Switch B.
[SwitchB] rip 100
[SwitchB-rip-100] default cost 3
[SwitchB-rip-100] import-route rip 200
[SwitchB] rip 200
[SwitchB-rip-200] import-route rip 100

1.1.1.0/24 Direct 0 0 1.1.1.1 Vlan100

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Vlan101
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
4.1.1.0/24 RIP 100 4 1.1.1.2 Vlan100
5.1.1.0/24 RIP 100 4 1.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) Configure an filtering policy to filter redistributed routes
# Define ACL2000 and reference it to a filtering policy to filter routes redistributed from RIP 200 on
Switch B.
[SwitchB-acl-basic-2000] rule deny source 4.1.1.1 0.0.0.255
[SwitchB-acl-basic-2000] rule permit
[SwitchB] rip 100
[SwitchB-rip-100] filter-policy 2000 export rip 200

1-27
1.1.1.0/24 Direct 0 0 1.1.1.1 Vlan100

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Vlan101
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
5.1.1.0/24 RIP 100 4 1.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
Configuring an Additional Metric for a RIP Interface
z RIP is enabled on all the interfaces of Switch A, Switch B, Switch C, Switch D, and Switch E. The
switches are interconnected through RIPv2.
z Switch A has two links to Switch D. The link from Switch B to Switch D is more stable than that from
Switch C to Switch D. Configure an additional metric for RIP routes received through
VLAN-interface 200 on Switch A so that Switch A prefers the 1.1.5.0/24 network learned from
Switch B.
Network diagram
Figure 1-9 Network diagram for RIP interface additional metric configuration

2) Configure RIP basic functions.
[SwitchA] rip 1
[SwitchA-rip-1] quit
1-28
[SwitchB] rip 1
[SwitchB] rip 1
[SwitchC-rip-1] version 2
[SwitchC-rip-1] undo summary
[SwitchD] rip 1
[SwitchD-rip-1] network 1.0.0.0
[SwitchD-rip-1] version 2
[SwitchD-rip-1] undo summary
# Configure Switch E.
[SwitchE] rip 1
[SwitchE-rip-1] network 1.0.0.0
[SwitchE-rip-1] version 2
[SwitchE-rip-1] undo summary
# Display the IP routing table of Switch A.

[SwitchA] display rip 1 database
1.1.3.0/24, cost 1, nexthop 1.1.1.2
1.1.4.0/24, cost 1, nexthop 1.1.2.2
1.1.5.0/24, cost 2, nexthop 1.1.1.2
1.1.5.0/24, cost 2, nexthop 1.1.2.2
The display shows that there are two RIP routes to network 1.1.5.0/24. Their nexthops are Switch B
(1.1.1.2) and Switch C (1.1.2.2) respectively, with the same cost of 2. Switch C is the nexthop router to
reach network 1.1.4.0/24, with a cost of 1.
3) Configure an additional metric for the RIP interface.
# Configure an additional metric of 3 for VLAN-interface 200 on Switch A.
[SwitchA-Vlan-interface200] rip metricin 3
[SwitchA-Vlan-interface200] display rip 1 database
1.1.3.0/24, cost 1, nexthop 1.1.1.2
1.1.4.0/24, cost 4, nexthop 1.1.2.2
1.1.5.0/24, cost 2, nexthop 1.1.1.2
1-29
The display shows that there is only one RIP route to network 1.1.5.0/24, with the nexthop as Switch B
(1.1.1.2) and a cost of 2. Switch C is the nexthop router to reach network 1.1.4.0/24, with a cost of 4.
Troubleshooting RIP
No RIP Updates Received
Symptom:
No RIP updates are received when the links work well.
Analysis:
After enabling RIP, you must use the network command to enable corresponding interfaces. Make sure
no interfaces are disabled from handling RIP messages.
If the peer is configured to send multicast messages, the same should be configured on the local end.
Solution:
z Use the display current-configuration command to check RIP configuration
z Use the display rip command to check whether some interface is disabled
Route Oscillation Occurred
Symptom:
When all links work well, route oscillation occurs on the RIP network. After displaying the routing table,
you may find some routes appear and disappear in the routing table intermittently.
Analysis:
In the RIP network, make sure all the same timers within the whole network are identical and
relationships between timers are reasonable. For example, the timeout timer value should be greater
than the update timer value.
Solution:
z Use the display rip command to check the configuration of RIP timers
z Use the timers command to adjust timers properly.
1-30
Table of Contents
1 Route Policy Configuration 1-1

Introduction to Route Policy 1-1
Route Policy and Policy Routing 1-1
Filters 1-2
Route Policy Application1-2
Route Policy Configuration Task List 1-3
Defining Filters 1-3
Prerequisites1-3
Defining an IP-prefix List 1-3
Defining an AS Path List1-4
Defining a Community List 1-5
Defining an Extended Community List 1-5
Configuring a Route Policy 1-5
Prerequisites1-6
Creating a Route Policy1-6
Defining if-match Clauses1-6
Defining apply Clauses1-8
Displaying and Maintaining the Route Policy1-10
Route Policy Configuration Example (on Routers) 1-10
Applying a Route Policy to IPv4 Route Redistribution 1-10
Applying a Route Policy to Filter Received BGP Routes 1-14
Route Policy Configuration Example (on Switches) 1-17
Applying a Route Policy to Filter Received BGP Routes 1-21
Troubleshooting Route Policy Configuration 1-24
IPv4 Routing Information Filtering Failure 1-24
IPv6 Routing Information Filtering Failure 1-24
i
1 Route Policy Configuration
A route policy is used on a router for route filtering and attributes modification when routes are received,
advertised, or redistributed.
When configuring route policy, go to these sections for information you are interested in:
z Introduction to Route Policy
z Route Policy Configuration Task List
z Defining Filters
z Configuring a Route Policy
z Displaying and Maintaining the Route Policy
z Route Policy Configuration Example (on Routers)
z Route Policy Configuration Example (on Switches)
z Troubleshooting Route Policy Configuration
Route policy in this chapter involves both IPv4 route policy and IPv6 route policy.
Introduction to Route Policy

Route Policy and Policy Routing
A route policy is used on a router for route filtering and attributes modification when routes are received,
advertised, or redistributed.
Policy routing, also called policy based routing (PBR) is a routing mechanism based on a user-defined
policy.
This chapter describes only route policy configuration and usage; refer to IP Unicast Policy Routing
Configuration in the IP Services Volume for policy routing information.
To configure a route policy, you need to define some filters based on the attributes of routing information,
such as destination address, advertising routers address and so on. The filters can be set beforehand
and then applied to the route policy.
1-1
Filters
There are six types of filters: ACL, IP prefix list, AS path ACL, community list, extended community list
and route policy.
ACL
ACL involves IPv4 ACL and IPv6 ACL. An ACL is configured to match the destinations or next hops of
routing information.
For ACL configuration, refer to ACL configuration in the Security Volume.
IP prefix list
IP prefix list involves IPv4 and IPv6 prefix list.

An IP prefix list is configured to match the destination address of routing information. Moreover, you can
use the gateway option to allow only routing information from certain routers to be received. For
gateway option information, refer to RIP Commands and OSPF Commands in the IP Routing Volume.
An IP prefix list, identified by name, can comprise multiple items. Each item, identified by an index
number, can specify a prefix range to match. An item with a smaller index number is matched first. If one
item is matched, the IP prefix list is passed, and the packet will not go to the next item.
AS-PATH list
An AS-PATH list, configured based on the BGP AS PATH attribute, can only be used to match BGP
Community list
A community list, configured based on the BGP community attribute, can only be used to match BGP
Extended community list
An extended community list, configured based on the BGP extended community attribute (Route-Target
for VPN, and Source of Origin), can only be used to match BGP routing information.
Route policy
A route policy is used to match routing information and modify the attributes of permitted routes. It can
reference the above mentioned filters to define its own match criteria.
A route policy can comprise multiple nodes, which are in logic OR relationship. Each route policy node
is a match unit, and a node with a smaller number is matched first. Once a node is matched, the route
policy is passed and the packet will not go to the next node.
A route policy node comprises a set of if-match and apply clauses. The if-match clauses define the
match criteria. The matching objects are some attributes of routing information. The if-match clauses of
a route policy node is in logical AND relationship. That is, a packet must match all the if-match clauses
of the node to pass it. The apply clauses of the node specify the actions to be taken on the permitted
packets, such as route attribute modification.
Route Policy Application
A route policy is applied on a router to filter routes when they are received, advertised or redistributed
and to modify some attributes of permitted routes.
1-2
Route Policy Configuration Task List
Complete the following tasks to configure a route policy:
Task
Defining an IP-prefix List
Defining an AS Path List
Defining Filters
Defining a Community List
Defining an Extended Community List

Creating a Route Policy
Configuring a Route Policy Defining if-match Clauses
Defining apply Clauses
Defining Filters
Prerequisites
Before configuring this task, you need to decide on:

z IP-prefix list name
z Matching address range
z Extcommunity list sequence number
Defining an IP-prefix List
Define an IPv4 prefix list
Identified by name, an IPv4 prefix list can comprise multiple items. Each item specifies a prefix range to
match and is identified by an index number.
An item with a smaller index number is matched first. If one item is matched, the IP prefix list is passed,
and the routing information will not go to the next item.
Follow these steps to define an IPv4 prefix list:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | Required

Define an IPv4
deny } ip-address mask-length [ greater-equal Not defined by
prefix list
min-mask-length ] [ less-equal max-mask-length ] default.
If all the items are set to the deny mode, no routes can pass the IPv4 prefix list. Therefore, you need to
define the permit 0.0.0.0 0 less-equal 32 item following multiple deny items to allow other IPv4 routing
information to pass.
1-3
For example, the following configuration filters routes 10.1.0.0/16, 10.2.0.0/16 and 10.3.0.0/16, but
allows other routes to pass.
[Sysname] ip ipv6-prefix abc index 10 deny 10.1.0.0 16
[Sysname] ip ipv6-prefix abc index 40 permit 0.0.0.0 0 less-equal 32
Define an IPv6 prefix list
Identified by name, each IPv6 prefix list can comprise multiple items. Each item specifies a prefix range
to match and is identified by an index number.
An item with a smaller index number is matched first. If one item is matched, the IPv6 prefix list is
passed, and the routing information will not go to the next item.
Follow these steps to define an IPv6 prefix list:
ip ipv6-prefix ipv6-prefix-name [ index Required

Define an IPv6 prefix index-number ] { deny | permit } ipv6-address
list prefix-length [ greater-equal min-prefix-length ] Not defined by
[ less-equal max-prefix-length ] default.
If all items are set to the deny mode, no routes can pass the IPv6 prefix list. Therefore, you need to
define the permit :: 0 less-equal 128 item following multiple deny items to allow other IPv6 routing
information to pass.
For example, the following configuration filters routes 2000:1::/48, 2000:2::/48 and 2000:3::/48, but
allows other routes to pass.
[Sysname] ip ip-prefix abc index 10 deny 2000:1:: 48
[Sysname] ip ip-prefix abc index 40 permit :: 0 less-equal 128
Defining an AS Path List
You can define multiple items for an AS path list that is identified by number. The relation between items
is logical OR, that is, if a route matches one of these items, it passes the AS path list.
1-4
Follow these steps to define an AS path list:
ip as-path as-path-number { deny | Required

Define an AS path ACL
permit } regular-expression Not defined by default.
Defining a Community List
You can define multiple items for a community list that is identified by number. During matching, the
relation between items is logic OR, that is, if routing information matches one of these items, it passes
the community list.
Follow these steps to define a community list:
ip community-list basic-comm-list-num
Define a basic { deny | permit } [ community-number-list ] Required to
Define a community list [ internet | no-advertise | no-export | define either;
communi no-export-subconfed ] *
ty list Not defined by
Define an advanced ip community-list adv-comm-list-num default.
community list { deny | permit } regular-expression
Defining an Extended Community List
You can define multiple items for an extended community list that is identified by number. During
matching, the relation between items is logic OR, that is, if routing information matches one of these
items, it passes the extended community list.
Follow these steps to define an extended community list:
ip extcommunity-list Required
Define an extended
ext-comm-list-number { deny |
community list Not defined by default
permit } { rt route-target }&<1-16>
Configuring a Route Policy

A route policy is used to filter routing information, and modify attributes of matching routing information.
The match criteria of a route policy can be configured by referencing filters above mentioned.
A route policy can comprise multiple nodes, and each route policy node contains:
z if-match clauses: Define the match criteria that routing information must satisfy. The matching
objects are some attributes of routing information.
z apply clauses: Specify the actions to be taken on routing informaiton that has satisfied the match
criteria, such as route attibute modification.
1-5
Prerequisites
Before configuring this task, you need to configure:

z Filters
z Routing protocols
You also need to decide on:
z Name of the route policy, and node numbers
z Match criteria
z Attributes to be modified
Creating a Route Policy
Follow these steps to create a route policy:
Create a route policy, specify a node for it route-policy route-policy-name

Required
and enter route policy node view { permit | deny } node node-number
z If a route policy node has the permit keyword specified, routing information matching all the
if-match clauses of the node will be handled using the apply clauses of this node, without needing
to match against the next node. If routing information does not match the node, it will go to the next
node for a match.
z If a route policy node has the deny keyword specified, the apply clauses of the node will not be
executed. When routing information matches all the if-match clauses of the node, it cannot pass
the node, or go to the next node. If route information cannot match all the if-match clauses of the
node, it will go to the next node for a match.
z When a route policy has more than one node, at least one node should be configured with the
permit keyword. If the route policy is used to filter routing information, routing information that does
not meet any node cannot pass the route policy. If all nodes of the route policy are set with the
deny keyword, no routing information can pass it.
Defining if-match Clauses
Follow these steps to define if-match clauses for a route-policy node:
route-policy route-policy-name
Enter route policy node view Required
{ permit | deny } node node-number
1-6
Match IPv4 routing information
if-match acl acl-number Optional
specified in the ACL
Define Not configured
match Match IPv4 routing information by default.
if-match ip-prefix ip-prefix-name
criteria specified in the IP prefix list
for
IPv4 Match IPv4 routing information Optional
if-match ip { next-hop |
routes whose next hop or source is
route-source } { acl acl-number | Not configured
specified in the ACL or IP
ip-prefix ip-prefix-name } by default.
prefix list
Match IPv6 routing information whose if-match ipv6 { address | next-hop | Optional
next hop or source is specified in the route-source } { acl acl-number | Not configured
ACL or IP prefix list prefix-list ipv6-prefix-name } by default.
Match BGP routing information whose Optional

if-match as-path
AS path attribute is specified in the AS Not configured
AS-PATH-number&<1-16>
path list (s) by default.
if-match community Optional

Match BGP routing information whose
{ basic-community-list-number
community attribute is specified in the Not configured
[ whole-match ] |
community list(s) by default.
Optional
Match routes having the specifed cost if-match cost value Not configured
by default.
Match BGP routing information whose Optional
extended community attribute is if-match extcommunity
specified in the extended community ext-comm-list-number&<1-16> Not configured
list(s) by default.
Optional
Match routing information having if-match interface { interface-type
specified outbound interface(s) interface-number }&<1-16> Not configured
by default.
Optional
Match routing information having MPLS
if-match mpls-label Not configured
labels
by default.
if-match route-type { internal |
external-type1 | external-type2 | Optional
Match routing information having the external-type1or2 | is-is-level-1 |
specified route type is-is-level-2 | nssa-external-type1 | Not configured
nssa-external-type2 | by default.
nssa-external-type1or2 } *
Match RIP, OSPF, and IS-IS routing Optional

information having the specified tag if-match tag value Not configured
value by default.
1-7
z The if-match clauses of a route policy node are in logic AND relationship, namely, routing
information has to satisfy all its if-match clauses before being executed with its apply clauses.
z You can specify no or multiple if-match clauses for a route policy node. If no if-match clause is
specified, and the route policy node is in permit mode, all routing information can pass the node. If
it is in deny mode, no routing information can pass it.
z An ACL specified in an if-match clause should be a non-VPN ACL.
z Support for the if-match mpls-label command varies depending on the device model.
z The if-match commands for matching IPv4 destination, next hop and source address are different
from those for matching IPv6 ones.
Defining apply Clauses
Follow these steps to define apply clauses for a route policy:
route-policy route-policy-name Required

Enter route policy node view
{ permit | deny } node node-number Not created by default.
Set the AS-PATH attribute for apply as-path as-number&<1-10> Optional

BGP routing information [ replace ] Not set by default.
Delete the community attribute Optional

apply comm-list comm-list-number
of BGP routing information using Not configured by
delete
the community list default.
apply community { none | additive |
{ community-number&<1-16> | Optional
Set the community attribute for
aa:nn&<1-16> | internet |
BGP routing information Not set by default.
no-export-subconfed | no-export |
no-advertise } * [ additive ] }
Optional
Set a cost for routing information apply cost [ + | - ] value
Not set by default.
Set a cost type for routing apply cost-type [ external | internal | Optional
information type-1 | type-2 ] Not set by default.
apply extcommunity { rt Optional
Set the extended community
{ as-number:nn |
attribute for BGP routing Not set by default.
ip-address:nn } }&<1-16> [ additive ]
1-8
Optional
Not set by default.
apply ip-address next-hop
for IPv4 routes The setting does not
ip-address
apply to redistributed
Set the next routing information.
hop Optional
Not set by default.
for IPv6 routes apply ipv6 next-hop ipv6-address The setting does not
apply to redistributed
Optional
Inject routing information to a apply isis { level-1 | level-1-2 |
specified ISIS level level-2 } Not configured by
default.
Set the local preference for BGP Optional

apply local-preference preference
routing information Not set by default.
Optional
Set MPLS label apply mpls-label
Not set by default.
Set the origin attribute for BGP apply origin { igp | egp as-number | Optional
routing information incomplete } Not set by default.
Set the preference for the Optional

apply preference preference
routing protocol Not set by default.
Set a preferred value for BGP apply preferred-value Optional

routing information preferred-value Not set by default.
Set a tag value for RIP, OSPF or Optional

apply tag value
IS-IS routing information Not set by default.
z Support for the apply mpls-label command varies depending on the device model.
z The difference between IPv4 and IPv6 apply clauses is the command for setting the next hop for
z The apply ip-address next-hop and apply ipv6 next-hop commands do not apply to
redistributed IPv4 and IPv6 routes respectively.
1-9
Displaying and Maintaining the Route Policy
Display BGP AS-PATH list
display ip as-path [ as-path-number ]
information
display ip community-list
Display BGP community list
[ basic-community-list-number |
information
adv-community-list-number ]
Available in any
Display BGP extended display ip extcommunity-list view
community list information [ ext-comm-list-number ]
Display IPv4 prefix list statistics display ip ip-prefix [ ip-prefix-name ]
Display IPv6 prefix list statistics display ip ipv6-prefix [ ipv6-prefix-name ]
Display route policy information display route-policy [ route-policy-name ]
Clear IPv4 prefix list statistics reset ip ip-prefix [ ip-prefix-name ] Available in user
Clear IPv6 prefix list statistics reset ip ipv6-prefix [ ipv6-prefix-name ] view
Route Policy Configuration Example (on Routers)

Applying a Route Policy to IPv4 Route Redistribution
In the following figure, Router B exchanges routing information with Router A using OSPF, and with
Router C using IS-IS.
Configure Router B to redistribute IS-IS routes into the OSPF routing domain, and use a route policy to
set the cost of route 172.17.1.0/24 to 100, and the tag of route 172.17.2.0/24 to 20.
Network diagram
Figure 1-1 Network diagram for route policy application to route redistribution

2) Configure IS-IS.
1-10
[RouterC] isis
[RouterC-isis-1] is-level level-2
[RouterC-Serial2/1] isis enable
[RouterC-Ethernet1/0] isis enable
[RouterB] isis
[RouterB-Serial2/1] isis enable
3) Configure OSPF and route redistribution.
# Configure OSPF on Router A.
[RouterA] ospf
# On Router B, configure OSPF and enable route redistribution from IS-IS.

[RouterB] ospf
[RouterB-ospf-1] import-route isis 1
# Display the OSPF routing table on Router A. The redistributed routes are available.
1-11
Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs

172.17.1.0/24 1 Type2 1 192.168.1.2 192.168.2.2
172.17.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.2.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
Total Nets: 5
4) Configure filtering lists on Router B
# Configure ACL 2002 to allow route 172.17.2.0/24 to pass.
[RouterB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
# Configure IP prefix list prefix-a to allow route 172.17.1.0/24 to pass.

[RouterB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
5) Configure a route policy on Router B
[RouterB] route-policy isis2ospf permit node 10
[RouterB-route-policy] if-match ip-prefix prefix-a
[RouterB-route-policy] apply cost 100
[RouterB-route-policy] quit
[RouterB-route-policy] if-match acl 2002
[RouterB-route-policy] apply tag 20
6) Apply the route policy to route redistribution on Router B.
# On Router B, enable route redistribution from IS-IS and apply the route policy.
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1 route-policy isis2ospf
# Display OSPF routing table information on Router A. The cost of route 172.17.1.0/24 is 100, and the
tag of route 172.17.2.0/24 is 20.

Routing Tables
Routing for Network
1-12
192.168.1.0/24 1 Transit 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs

172.17.1.0/24 100 Type2 1 192.168.1.2 192.168.2.2
172.17.2.0/24 1 Type2 20 192.168.1.2 192.168.2.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.2.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
Total Nets: 5
z In the following figure, both Router A and Router B run RIPng.

z Enable RIPng and configure three static routes on Router A
z On Router A, enable static route redistribution into RIPng and apply a route policy to permit routes
20::/32 and 40::/32 and deny route 30::/32.
z Display RIPng routing table information on Router B to verify the configuration.
Network diagram
Configuraion procedure
# Configure IPv6 addresses for interfaces Ethernet 1/0 and Ethernet 1/1.
[RouterA] ipv6
# Enable RIPng on Ethernet 1/0.

1-13
# Configure three static routes on Router A.

[RouterA] ipv6 route-static 20:: 32 ethernet 1/1
# Configure a route policy.

[RouterA] ip ipv6-prefix a index 10 permit 30:: 32
[RouterA] route-policy static2ripng deny node 0
[RouterA-route-policy] if-match ipv6 address prefix-list a
[RouterA] route-policy static2ripng permit node 10
# Enable RIPng and apply route policy static3ripng to filter redistributed static routes on Router A.
[RouterA] ripng
[RouterA-ripng-1] import-route static route-policy static2ripng
# Configure the IPv6 address of Ethernet 1/0.
[RouterB] ipv6
[RouterB-Ethernet1/0] ipv6 address 10::2 32
# Enable RIPng on the interface.

[RouterB-Ethernet1/0] ripng 1 enable
# Enable RIPng.
[RouterB] ripng
# Display RIPng routing table information.

[RouterB-ripng-1] display ripng 1 route
Route Flags: A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::7D58:0:CA03:1 on Serial2/0

Dest 10::/32,
via FE80::7D58:0:CA03:1, cost 1, tag 0, A, 18 Sec
Dest 20::/32,
Dest 40::/32,
Applying a Route Policy to Filter Received BGP Routes
z In the following figure, all the routers run BGP. Router C establishes eBGP connections with other
routers.
1-14
z Configure a route policy on Router D to reject routes from AS 200.
Network diagram
Figure 1-3 Route policy configuration to filter received BGP routes (on routers)

2) Configure BGP.
[RouterA] bgp 100
[RouterB] bgp 200
[RouterC] bgp 300
[RouterD] bgp 400
[RouterD-bgp] quit
1-15
# Inject routes 4.4.4.4/24, 5.5.5.5/24, and 6.6.6.6/24 on Router A.
# Inject routes 7.7.7.7/24, 8.8.8.8/24, and 9.9.9.9/24 on Router B.

[RouterB-bgp] network 7.7.7.7 24
# Display the BGP routing table information of Router D.

[RouterD-bgp] display bgp routing-table

*> 4.4.4.0/24 1.1.3.1 0 300 100i

*> 5.5.5.0/24 1.1.3.1 0 300 100i
*> 6.6.6.0/24 1.1.3.1 0 300 100i
*> 7.7.7.0/24 1.1.3.1 0 300 200i
*> 8.8.8.0/24 1.1.3.1 0 300 200i
*> 9.9.9.0/24 1.1.3.1 0 300 200i
The routing table information above shows that Router D has learned routes 4.4.4.0/24, 5.5.5.0/24, and
6.6.6.0/24 from AS 100 and 7.7.7.0/24, 8.8.8.0/24, and 9.9.9.0/24 from AS 200.
3) Configure Router D to reject the routes from AS 200.
# Configure AS-PATH list 1 on Router D.
[RouterD] ip as-path 1 permit .*200.*
# Configure a route policy named rt1 on Router D.

[RouterD] route-policy rt1 deny node 1
[RouterD] if-match as-path 1
[RouterD] route-policy rt2 permit node 2
# On Router D, specify route policy rt1 to filter routes received from peer 1.1.3.1.
[RouterD] bgp 400
[RouterD] peer 1.1.3.1 route-policy rt1 import
# Display the BGP routing table information of Router D.


1-16
*> 4.4.4.0/24 1.1.3.1 0 300 100i

*> 5.5.5.0/24 1.1.3.1 0 300 100i
*> 6.6.6.0/24 1.1.3.1 0 300 100i
The display above shows that Router D has learned only routes 4.4.4.0/24, 5.5.5.0/24, and 6.6.6.0/24
from AS 100.
Route Policy Configuration Example (on Switches)

z As shown in the following figure, Switch B exchanges routing information with Switch A using
OSPF, and with Switch C using IS-IS.
z On Switch B, enable route redistribution from IS-IS to OSPF and apply a route policy to set the cost
of route 172.17.1.0/24 to 100, and the tag of route 172.17.2.0/24 to 20.
Network diagram
1) Specify IP addresses for interfaces (omitted).

2) Configure IS-IS.
[SwitchC] isis
[SwitchC-isis-1] is-level level-2
[SwitchC-Vlan-interface200] isis enable
1-17
[SwitchB] isis
[SwitchB-Vlan-interface200] isis enable
3) Configure OSPF and route redistribution
# Configure OSPF on Switch A.
[SwitchA] ospf
# On Switch B, configure OSPF and enable route redistribution from IS-IS.

[SwitchB] ospf
[SwitchB-ospf-1] import-route isis 1
# Display the OSPF routing table on Switch A to view redistributed routes.


Routing Tables
Routing for Network

192.168.1.0/24 1562 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs

172.17.1.0/24 1 Type2 1 192.168.1.2 192.168.2.2
1-18
172.17.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.2.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
Total Nets: 5
4) Configure filtering lists
# Configure ACL 2002 to permit route 172.17.2.0/24.
[SwitchB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
# Configure IP prefix list prefix-a to permit route 172.17.1.0/24.

[SwitchB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
5) Configure a route policy.
[SwitchB] route-policy isis2ospf permit node 10
[SwitchB-route-policy] if-match ip-prefix prefix-a
[SwitchB-route-policy] apply cost 100
[SwitchB-route-policy] quit
[SwitchB-route-policy] if-match acl 2002
[SwitchB-route-policy] apply tag 20
6) Apply the route policy to route redistribution.
# On Switch B, apply the route policy when redistributing routes.
[SwitchB] ospf
[SwitchB-ospf-1] import-route isis 1 route-policy isis2ospf
# Display the OSPF routing table on Switch A. The cost of route 172.17.1.0/24 is 100, the tag of route
172.17.1.0/24 is 20.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs

172.17.1.0/24 100 Type2 1 192.168.1.2 192.168.2.2
172.17.2.0/24 1 Type2 20 192.168.1.2 192.168.2.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.2.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
1-19
Total Nets: 5
z Enable RIPng on Switch A and Switch B.

z On Switch A, configure three static routes, and apply a route policy to static route redistribution to
permit routes 20::0/32 and 40::0/32, and deny route 30::0/32.
z Display RIPng routing table information on Switch B to verify the configuration.
Network diagram
1) Configure Switch A.
# Configure IPv6 addresses for VLAN-interface 100 and VLAN-interface 200.
[SwitchA] ipv6
# Enable RIPng on VLAN-interface 100.

[SwitchA-Vlan-interface100] ripng 1 enable
# Configure three static routes.

[SwitchA] ipv6 route-static 20:: 32 11::2

[SwitchA] ip ipv6-prefix a index 10 permit 30:: 32
[SwitchA] route-policy static2ripng deny node 0
[SwitchA-route-policy] if-match ipv6 address prefix-list a
1-20
[SwitchA] route-policy static2ripng permit node 10
# Enable RIPng and and apply the route policy to static route redistribution.
[SwitchA] ripng
[SwitchA-ripng-1] import-route static route-policy static2ripng
2) Configure Switch B.
# Configure the IPv6 address for VLAN-interface 100.
[SwitchB] ipv6
[SwitchB-Vlan-interface100] ipv6 address 10::2 32
# Enable RIPng on VLAN-interface 100.

[SwitchB-Vlan-interface100] ripng 1 enable
# Enable RIPng.
[SwitchB] ripng
# Display RIPng routing table information.

[SwitchB-ripng-1] display ripng 1 route
----------------------------------------------------------------
Peer FE80::7D58:0:CA03:1 on Vlan-interface 100

Dest 10::/32,
Dest 20::/32,
Dest 40::/32,
Applying a Route Policy to Filter Received BGP Routes
z All the switches run BGP. Switch C establishes eBGP connections with other switches.
z Configure a route policy on Switch D to reject routes from AS 200.
1-21
Network diagram
Figure 1-6 Route policy configuration to filter received BGP routes (on switches)
Swtich A
Vlan-int100
AS 100 1.1.1.1/24
AS 300
1.1.1.2/24 1.1.3.1/24 AS 400
1.1.2.2/24 1.1.3.2/24
Swtich C Swtich D
Vlan-int200
1.1.2.1/24
Swtich B
AS 200

2) Configure BGP.
[SwitchA] bgp 100
[SwitchB] bgp 200
[SwitchC] bgp 300
[SwitchD] bgp 400
[SwitchD-bgp] quit
# On Switch A, inject routes 4.4.4.4/24, 5.5.5.5/24, and 6.6.6.6/24 to BGP.
1-22
# On Switch B, inject routes 7.7.7.7/24, 8.8.8.8/24, and 9.9.9.9/24 to BGP.

[SwitchB-bgp] network 7.7.7.7 24
# Display the BGP routing table information of Switch D.

[SwitchD-bgp] display bgp routing-table

*> 4.4.4.0/24 1.1.3.1 0 300 100i

*> 5.5.5.0/24 1.1.3.1 0 300 100i
*> 6.6.6.0/24 1.1.3.1 0 300 100i
*> 7.7.7.0/24 1.1.3.1 0 300 200i
*> 8.8.8.0/24 1.1.3.1 0 300 200i
*> 9.9.9.0/24 1.1.3.1 0 300 200i
The display above shows that Switch D has learned routes 4.4.4.0/24, 5.5.5.0/24, and 6.6.6.0/24 from
AS 100 and 7.7.7.0/24, 8.8.8.0/24, and 9.9.9.0/24 from AS 200.
3) Configure Switch D to reject routes from AS 200.
# Configure AS_PATH list 1 on Switch D.
[SwitchD] ip as-path 1 permit .*200.*
# Configure a route policy named rt1 on Switch D.

[SwitchD] route-policy rt1 deny node 1
[SwitchD] if-match as-path 1
[SwitchD] route-policy rt2 permit node 2
# On Switch D, specify route policy rt1 to filter routes received from peer 1.1.3.1.
[SwitchD] bgp 400
[SwitchD] peer 1.1.3.1 route-policy rt1 import
# Display the BGP routing table information of Switch D.


1-23
*> 4.4.4.0/24 1.1.3.1 0 300 100i

*> 5.5.5.0/24 1.1.3.1 0 300 100i
*> 6.6.6.0/24 1.1.3.1 0 300 100i
The display above shows that Switch D has learned only routes 4.4.4.0/24, 5.5.5.0/24, and 6.6.6.0/24
from AS 100.
Troubleshooting Route Policy Configuration

IPv4 Routing Information Filtering Failure
Symptom
Filtering routing information failed, while the routing protocol runs normally.
Analysis
At least one item of the IP prefix list should be configured as permit mode, and at least one node in the
Route policy should be configured as permit mode.
Solution
1) Use the display ip ip-prefix command to display IP prefix list information.

2) Use the display route-policy command to display route policy information.
IPv6 Routing Information Filtering Failure
Symptom
Filtering routing information failed, while the routing protocol runs normally.
Analysis
At least one item of the IPv6 prefix list should be configured as permit mode, and at least one node of
the Route policy should be configured as permit mode.
Solution
1) Use the display ip ipv6-prefix command to display IP prefix list information.

2) Use the display route-policy command to display route policy information.
1-24
Table of Contents
1 Static Routing Configuration1-1

Introduction 1-1
Static Route 1-1
Default Route1-2
Application Environment of Static Routing 1-2
Configuring a Static Route 1-3
Detecting Reachability of the Static Routes Nexthop 1-4
Detecting Nexthop Reachability Through BFD 1-4
Detecting Nexthop Reachability Through Track1-5
Displaying and Maintaining Static Routes1-6
Configuration Example (on Routers)1-7
Configuration Example (on Switches)1-9
i

Detecting nexthop
No No No No
reachability through BFD
Detecting nexthop
Yes Yes Yes Yes
reachability through Track
z The MSR series routers support the vpn-instance keyword.
1 Static Routing Configuration
When configuring a static route, go to these sections for information you are interested in:
z Introduction
z Configuring a Static Route
z Detecting Reachability of the Static Routes Nexthop
z Displaying and Maintaining Static Routes
z Configuration Example (on Routers)
z Configuration Example (on Switches)
Introduction
Static Route
A static route is a manually configured. If a networks topology is simple, you only need to configure
static routes for the network to work normally. The proper configuration and usage of static routes can
improve network performance and ensure bandwidth for important network applications.
The disadvantage of using static routes is that they cannot adapt to network topology changes. If a fault
or a topological change occurs in the network, the routes will be unreachable and the network breaks. In
1-1
this case, the network administrator has to modify the static routes manually.
Default Route
If the destination address of a packet fails to match any entry in the routing table, the packet will be
discarded.
After a default route is configured on a router, any packet whose destination IP address matches no
entry in the routing table can be forwarded to a designated upstream router.
A router selects the default route only when it cannot find any matching entry in the routing table.
z If the destination address of a packet fails to match any entry in the routing table, the router selects
the default route to forward the packet.
z If there is no default route and the destination address of the packet fails to match any entry in the
routing table, the packet will be discarded and an ICMP packet will be sent to the source to report
that the destination or the network is unreachable.
Default routes can be configured in two ways:
z The network administrator can configure a default route with both destination and mask being
0.0.0.0. The router forwards any packet whose destination address fails to match any entry in the
routing table to the next hop of the default static route.
z Some dynamic routing protocols, such as OSPF, RIP and IS-IS, can also generate a default route.
For example, an upstream router running OSPF can generate a default route and advertise it to
other routers, which install the default route with the next hop being the upstream router.
Application Environment of Static Routing
Before configuring a static route, you need to know the following concepts:
1) Destination address and mask
In the ip route-static command, an IPv4 address is in dotted decimal format and a mask can be either
in dotted decimal format or in the form of mask length (the digits of consecutive 1s in the mask).
2) Output interface and next hop address
While configuring a static route, you can specify either the output interface or the next hop address
depending on the specific occasion. The next hop address can not be a local interface IP address;
otherwise, the route configuration will not take effect.
In fact, all the route entries must have a next hop address. When forwarding a packet, a router first
searches the routing table for the route to the destination address of the packet. The system can find the
corresponding link layer address and forward the packet only after the next hop address is specified.
When specifying the output interface, note that:
z If the output interface is a NULL0 or loopback interface, there is no need to configure the next hop
address.
z If the output interface is a point-to-point interface, there is no need to configure the next hop
address. You need not change the configuration even if the peers address changes. For example,
a PPP interface obtains the peers IP address through PPP negotiation, so you need only specify
the output interface.
z If the output interface is an NBMA or P2MP interface, which support point-to-multipoint network,
the IP address to link layer address mapping must be established. Therefore, it is recommended to
configure both the next hop IP address and the output interface.
1-2
z You are not recommended to specify a broadcast interface (such as an Ethernet interface, virtual
template, or VLAN interface) as the output interface, because a broadcast interface may have
multiple next hops. If you have to do so, you must specify the corresponding next hop for the output
interface.
3) Other attributes
You can configure different preferences for different static routes so that route management policies can
be applied more flexibly. For example, specifying the same preference for different routes to the same
destination enables load sharing, while specifying different preferences for these routes enables route
backup.
Configuring a Static Route

Before configuring a static route, you need to finish the following tasks:
z Configure the physical parameters for related interfaces
z Configure the link-layer attributes for related interfaces
z Configure the IP addresses for related interfaces
Follow these steps to configure a static route:

ip route-static dest-address { mask | mask-length }
{ next-hop-address | interface-type interface-number
[ next-hop-address ] | vpn-instance
d-vpn-instance-name next-hop-address } Required
[ preference preference-value ] [ tag tag-value ] By default,
[ description description-text ] preference for
Configure a static static routes is 60,
route ip route-static vpn-instance tag is 0, and no
s-vpn-instance-name&<1-6> dest-address { mask | description
mask-length } { next-hop-address [ public ] | information is
interface-type interface-number [ next-hop-address ] configured.
| vpn-instance d-vpn-instance-name
next-hop-address } [ preference preference-value ]
[ tag tag-value ] [ description description-text ]
ip route-static default-preference
preference for static
default-preference-value 60 by default
routes
1-3
z When configuring a static route, the static route does not take effect if you specify the next hop
address first and then configure it as the IP address of a local interface, such as Ethernet interface
and VLAN interface.
z If you do not specify the preference when configuring a static route, the default preference will be
used. Reconfiguring the default preference applies only to newly created static routes.
z You can flexibly control static routes by configuring tag values and using the tag values in the
routing policy.
z The support for VPN instances varies by device.
z If the destination IP address and mask are both configured as 0.0.0.0 with the ip route-static
command, the route is the default route.
Detecting Reachability of the Static Routes Nexthop

If a static route fails due to a topology change or a fault, the connection will be interrupted. To improve
network stability, the system needs to detect reachability of the static routes next hop and switch to a
backup route once the next hop is unreachable.
There are two methods of detecting reachability of the static routes next hop. Note that only one of the
two methods can be used at a time.
Detecting Nexthop Reachability Through BFD
Support for this feature varies with device models.
Bidirectional forwarding detection (BFD) provides a general-purpose, standard, medium- and

protocol-independent fast failure detection mechanism. It can uniformly and quickly detect the failures
of the bidirectional forwarding paths between two routers for upper-layer protocols, such as routing
protocols and Multiprotocol Label Switching (MPLS). For details about BFD, refer to BFD Configuration
in the IP Routing Volume.
After a static route is configured, you can enable BFD to detect the reachability of the static route's
nexthop.
To detect the reachability of the static route's nexthop through BFD, you need to enable BFD first. For
BFD configuration, refer to BFD Configuration in the IP Routing Volume.
1-4
Follow these steps to detect reachability of the static routes nexthop through BFD:

{ next-hop-address bfd { control-packet | echo-packet } |
interface-type interface-number [ next-hop-address [ bfd
{ control-packet | echo-packet } ] ] | vpn-instance
d-vpn-instance-name next-hop-address bfd
{ control-packet | echo-packet } } [ preference
Detect reachability preference-value ] [ tag tag-value ] [ description Required
of the static routes description-text ]
Not
nexthop through ip route-static vpn-instance s-vpn-instance-name&<1-6> configured by
BFD dest-address { mask | mask-length } { next-hop-address bfd default
{ control-packet | echo-packet } [ public ] | interface-type
interface-number [ next-hop-address [ bfd { control-packet |
echo-packet } ] ] | vpn-instance d-vpn-instance-name
next-hop-address bfd { control-packet | echo-packet } }
[ preference preference-value ] [ tag tag-value ]
[ description description-text ]
z To implement BFD in the control-packet mode, the remote end must create a BFD session;
otherwise the BFD function cannot work. To implement BFD in the echo-packet mode, the BFD
function can work without the remote end needing to create any BFD session.
z If a route flap occurs, enabling BFD may worsen the flapping. Be cautious for use of this feature.
Detecting Nexthop Reachability Through Track
Support for this feature varies with device models.
If you specify the nexthop but not outgoing interface when configuring a static route, you can associate
the static route with a track entry to check the static route validity:
z When the track entry is positive, the static route's nexthop is reachable and the static route takes
effect.
z When the track entry is negative, the static route's nexthop is unreachable and the static route is
invalid. For details about track, refer to Track Configuration in the System Volume.
To detect the reachability of a static route's nexthop through a Track entry, you need to create a Track
first. For detailed Track configuration procedure, refer to Track Configuration in the System Volume.
1-5
Follow these steps to detect the reachability of a static route's nexthop through Track:

Enter system
system-view
view
{ next-hop-address | vpn-instance d-vpn-instance-name
next-hop-address } track track-entry-number [ preference
preference-value ] [ tag tag-value ] [ description description-text ] Required
Associate the
static route with Not
ip route-static vpn-instance s-vpn-instance-name&<1-6> configured
a track entry dest-address { mask | mask-length } { next-hop-address track by default
track-entry-number [ public ] | vpn-instance d-vpn-instance-name
next-hop-address track track-entry-number } [ preference
preference-value ] [ tag tag-value ] [ description description-text ]
z To configure this feature for an existing static route, simply associate the static route with a track
entry. For a non-existent static route, configure it and associate it with a Track entry.
z If the track module uses NQA to detect the reachability of the private network static route's nexthop,
the VPN instance number of the static route's nexthop must be identical to that configured in the
NQA test group.
z If a static route needs route recursion, the associated track entry must monitor the nexthop of the
recursive route instead of that of the static route; otherwise, a valid route may be mistakenly
considered invalid.
Displaying and Maintaining Static Routes

Display the current configuration
display current-configuration
information
Display the brief information of the IP
display ip routing-table
routing table Available in
Display the detailed information of the IP any view
display ip routing-table verbose
routing table
display ip routing-table protocol

View information of static routes
static [ inactive | verbose ]
delete [ vpn-instance Available In
Delete all the static routes
vpn-instance-name ] static-routes all system view
1-6
The VPN instance support in the delete [ vpn-instance vpn-instance-name ] static-routes all
command varies by device.

The routers interfaces and the hosts IP addresses and masks are shown in the following figure. Static
routes are required for interconnections between any two hosts.
Network diagram
Figure 1-1 Network diagram for static route configuration
Host B
1.1.6.2/24
Eth1/2
1.1.6.1/24
Eth1/0 Eth1/1
1.1.4.2/30 1.1.5.5/30
Router B
Eth1/1 Eth1/1
1.1.4.1/30 1.1.5.6/30
Eth1/0 Eth1/0
1.1.2.3/24 1.1.3.1/24
Host A Router A Router C Host C
1.1.2.2/24 1.1.3.2/24
1) Configuring IP addresses for interfaces (omitted)

2) Configuring static routes
# Configure a default route on Router A.
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
# Configure two static routes on Router B.

[RouterB] ip route-static 1.1.2.0 255.255.255.0 1.1.4.1
[RouterB] ip route-static 1.1.3.0 255.255.255.0 1.1.5.6
# Configure a default route on Router C.

[RouterC] ip route-static 0.0.0.0 0.0.0.0 1.1.5.5
3) Configure the hosts.
The default gateways for Host A, Host B and Host C are 1.1.2.3, 1.1.6.1 and 1.1.3.1 respectively. The
4) Display the configuration result.
1-7
# Display the IP routing table of Router A.
0.0.0.0/0 Static 60 0 1.1.4.2 Eth1/1

1.1.2.0/24 Direct 0 0 1.1.2.3 Eth1/0
1.1.2.3/32 Direct 0 0 127.0.0.1 InLoop0
1.1.4.0/30 Direct 0 0 1.1.4.1 Eth1/1
1.1.4.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
# Display the IP routing table of Router B.

[RouterB] display ip routing-table
1.1.2.0/24 Static 60 0 1.1.4.1 Eth1/0

1.1.3.0/24 Static 60 0 1.1.5.6 Eth1/1
1.1.4.0/30 Direct 0 0 1.1.4.2 Eth1/0
1.1.4.2/32 Direct 0 0 127.0.0.1 InLoop0
1.1.5.4/30 Direct 0 0 1.1.5.5 Eth1/1
1.1.5.5/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
1.1.6.0/24 Direct 0 0 1.1.6.1 Eth1/2
1.1.6.1/32 Direct 0 0 127.0.0.1 InLoop0
# Use the ping command on Host B to check reachability to Host A, assuming Windows XP runs on the
two hosts.
C:\Documents and Settings\Administrator> ping 1.1.2.2
Pinging 1.1.2.2 with 32 bytes of data:
Reply from 1.1.2.2: bytes=32 time=1ms TTL=128

Ping statistics for 1.1.2.2:

1-8
# Use the tracert command on Host B to check reachability to Host A.
C:\Documents and Settings\Administrator>tracert 1.1.2.2
Tracing route to 1.1.2.2 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 1.1.6.1

2 <1 ms <1 ms <1 ms 1.1.4.1
3 1 ms <1 ms <1 ms 1.1.2.2
Trace complete.

The IP addresses and masks of the switches and hosts are shown in the following figure. Static routes
are required for interconnection between any two hosts.
Network diagram
1) Configuring IP addresses for interfaces (omitted)

2) Configuring static routes
# Configure a default route on Switch A.
[SwitchA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
# Configure two static routes on Switch B.

[SwitchB] ip route-static 1.1.2.0 255.255.255.0 1.1.4.1
[SwitchB] ip route-static 1.1.3.0 255.255.255.0 1.1.5.6
# Configure a default route on Switch C

[SwitchC] ip route-static 0.0.0.0 0.0.0.0 1.1.5.5
1-9
3) Configure the hosts.
The default gateways for the three hosts A, B and C are 1.1.2.3, 1.1.6.1 and 1.1.3.1 respectively. The
4) Display the configuration.
# Display the IP routing table of Switch A.
0.0.0.0/0 Static 60 0 1.1.4.2 Vlan500

1.1.2.0/24 Direct 0 0 1.1.2.3 Vlan300
1.1.2.3/32 Direct 0 0 127.0.0.1 InLoop0
1.1.4.0/30 Direct 0 0 1.1.4.1 Vlan500
1.1.4.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
# Display the IP routing table of Switch B.

[SwitchB] display ip routing-table
1.1.2.0/24 Static 60 0 1.1.4.1 Vlan500

1.1.3.0/24 Static 60 0 1.1.5.6 Vlan600
1.1.4.0/30 Direct 0 0 1.1.4.2 Vlan500
1.1.4.2/32 Direct 0 0 127.0.0.1 InLoop0
1.1.5.4/30 Direct 0 0 1.1.5.5 Vlan600
1.1.5.5/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
1.1.6.0/24 Direct 0 0 192.168.1.47 Vlan100
1.1.6.1/32 Direct 0 0 127.0.0.1 InLoop0
# Use the ping command on Host B to check reachability to Host A, assuming Windows XP runs on the
two hosts.
C:\Documents and Settings\Administrator>ping 1.1.2.2
Pinging 1.1.2.2 with 32 bytes of data:

1-10
Ping statistics for 1.1.2.2:
# Use the tracert command on Host B to check reachability to Host A.

[HostB] tracert 1.1.2.2
Tracing route to 1.1.2.2 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 1.1.6.1

2 <1 ms <1 ms <1 ms 1.1.4.1
3 1 ms <1 ms <1 ms 1.1.2.2
Trace complete.
1-11
Table of Contents
1 IPv6 BGP Configuration1-1

IPv6 BGP Overview 1-1
Configuring IPv6 BGP Basic Functions 1-3
Prerequisites1-3
Specifying an IPv6 BGP Peer 1-3
Injecting a Local IPv6 Route1-3
Configuring a Preferred Value for Routes from a Peer/Peer Group 1-4
Specifying the Source Interface for Establishing TCP Connections 1-4
Allowing the establishment of a Non-Direct EBGP connection 1-5
Configuring a Description for a Peer/Peer Group 1-5
Disabling Session Establishment to a Peer/Peer Group1-6
Logging Peer State Changes 1-6
Prerequisites1-7
Configuring IPv6 BGP Route Redistribution1-7
Advertising a Default Route to a Peer/Peer Group 1-7
Configuring Outbound Route Filtering1-8
Configuring Inbound Route Filtering1-9
Configuring IPv6 BGP and IGP Route Synchronization1-9
Configuring Route Dampening 1-10
Configuring IPv6 BGP Route Attributes 1-10
Prerequisites1-10
Configuring IPv6 BGP Preference and Default LOCAL_PREF and NEXT_HOP Attributes1-11
Configuring the MED Attribute1-11
Configuring the AS_PATH Attribute 1-12
Tuning and Optimizing IPv6 BGP Networks 1-12
Prerequisites1-13
Configuring IPv6 BGP Timers 1-13
Configuring IPv6 BGP Soft Reset 1-14
Configuring the Maximum Number of Load-Balanced Routes1-14
Configuring a Large Scale IPv6 BGP Network 1-15
Prerequisites1-15
Configuring IPv6 BGP Peer Group1-15
Configuring IPv6 BGP Community 1-17
Configuring an IPv6 BGP Route Reflector 1-17
Configuring 6PE 1-18
Configuring Basic 6PE Capabilities1-19
Configuring Optional 6PE Capabilities 1-20
Displaying and Maintaining IPv6 BGP 1-22
Displaying BGP 1-22
Resetting IPv6 BGP Connections 1-23
i
Clearing IPv6 BGP Information 1-23
IPv6 BGP Configuration Examples (on Routers)1-23
IPv6 BGP Basic Configuration 1-23
IPv6 BGP Route Reflector Configuration 1-26
6PE Configuration 1-27
IPv6 BGP Configuration Examples (on Switches) 1-31
IPv6 BGP Basic Configuration 1-32
IPv6 BGP Route Reflector Configuration 1-34
Troubleshooting IPv6 BGP Configuration 1-35
No IPv6 BGP Peer Relationship Established 1-35
ii

6PE Yes Yes Yes Yes
1 IPv6 BGP Configuration
This chapter describes only configuration for IPv6 BGP. For BGP related information, refer to BGP
Configuration in the IP Routing Volume.
When configuring IPv6 BGP, go to these sections for information you are interested in:
z IPv6 BGP Overview
z Configuring IPv6 BGP Basic Functions
z Controlling Route Distribution and Reception
z Configuring IPv6 BGP Route Attributes
z Tuning and Optimizing IPv6 BGP Networks
z Configuring a Large Scale IPv6 BGP Network
z Configuring 6PE
z Displaying and Maintaining IPv6 BGP
z IPv6 BGP Configuration Examples (on Routers)
z IPv6 BGP Configuration Examples (on Switches)
z Troubleshooting IPv6 BGP Configuration
IPv6 BGP Overview

BGP-4 was designed to carry only IPv4 routing information, and thus other network layer protocols such
as IPv6 are not supported.
1-1
To support multiple network layer protocols, IETF extended BGP-4 by introducing Multiprotocol BGP
(MP-BGP), which is defined in RFC 2858 (multiprotocol extensions for BGP-4).
MP-BGP for IPv6 is referred to as IPv6 BGP for short.
IPv6 BGP puts IPv6 network layer information into the attributes of network layer reachable information
(NLRI) and NEXT_HOP.
The NLRI attribute of IPv6 BGP involves:
z MP_REACH_NLRI: Multiprotocol Reachable NLRI, for advertisement of next hop information of
reachable routes.
z MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI, for withdrawal of unreachable routes.
The NEXT_HOP attribute of IPv6 BGP is identified by an IPv6 unicast address or IPv6 local link
address.
IPv6 BGP has the same messaging and routing mechanisms as BGP.

Complete the following tasks to configure IPv6 BGP:
Task Remarks
Specifying an IPv6 BGP Peer Required
Injecting a Local IPv6 Route Optional
Configuring a Preferred Value for Routes from a
Optional
Peer/Peer Group
Specifying the Source Interface for Establishing TCP
Configuring IPv6 BGP Optional
Connections
Basic Functions
Allowing the establishment of a Non-Direct EBGP
Optional
connection
Configuring a Description for a Peer/Peer Group Optional
Disabling Session Establishment to a Peer/Peer Group Optional
Logging Peer State Changes Optional
Configuring IPv6 BGP Route Redistribution Optional
Advertising a Default Route to a Peer/Peer Group Optional
Controlling Route Configuring Outbound Route Filtering Optional

Distribution and Reception Configuring Inbound Route Filtering Optional
Configuring IPv6 BGP and IGP Route Synchronization Optional
Configuring Route Dampening Optional
Configuring IPv6 BGP Preference and Default
Optional
LOCAL_PREF and NEXT_HOP Attributes
Configuring IPv6 BGP
Route Attributes Configuring the MED Attribute Optional
Configuring the AS_PATH Attribute Optional
Configuring IPv6 BGP Timers Optional
Tuning and Optimizing IPv6 Configuring IPv6 BGP Soft Reset Optional
BGP Networks
Configuring the Maximum Number of Load-Balanced
Optional
Routes
1-2
Task Remarks
Configuring IPv6 BGP Peer Group Optional
Configuring a Large Scale
Configuring IPv6 BGP Community Optional
IPv6 BGP Network
Configuring an IPv6 BGP Route Reflector Optional
Configuring Basic 6PE Capabilities Optional
Configuring 6PE
Configuring Optional 6PE Capabilities Optional
Configuring IPv6 BGP Basic Functions

Prerequisites
Before configuring this task, you need to:

z Specify IP addresses for interfaces.
z Enable IPv6.
You need create a peer group before configuring basic functions for it. For related information, refer to
Configuring IPv6 BGP Peer Group.
Specifying an IPv6 BGP Peer
Follow these steps to configure an IPv6 BGP peer:
Optional
Specify a router ID router-id router-id Required if no IP addresses are
configured for any interfaces.
Enter IPv6 address family view ipv6-family
Specify an IPv6 peer and its AS peer ipv6-address as-number Required

number as-number Not configured by default.
Injecting a Local IPv6 Route
Follow these steps to configure advertise a local route into the routing table:
1-3
network ipv6-address prefix-length Required

Inject a local route into the IPv6
[ short-cut | route-policy
BGP routing table Not added by default
route-policy-name ]
Configuring a Preferred Value for Routes from a Peer/Peer Group
Follow these steps to configure a preferred value for routes received from a peer/peer group:
Configure a preferred value for peer { ipv6-group-name | Optional

routes received from a ipv6-address } preferred-value By default, the preferred value
peer/peer group value is 0.
If you both reference a routing policy and use the command peer { ipv6-group-name | ipv6-address }
preferred-value value to set a preferred value for routes from a peer, the routing policy sets a non-zero
preferred value for routes matching it. Other routes not matching the routing policy uses the value set
with the command. If the preferred value in the routing policy is zero, the routes matching it will also use
the value set with the command. For information about using a routing policy to set a preferred value,
refer to the command peer { group-name | ipv4-address | ipv6-address } route-policy
route-policy-name { import | export } in this document, and the command apply preferred-value
preferred-value in Routing Policy Commands of the IP Routing Volume.
Specifying the Source Interface for Establishing TCP Connections
Follow these steps to specify the source interface for establishing TCP connections to a BGP peer or
peer group:
1-4
Required
peer { ipv6-group-name | By default, IPv6 BGP uses the
Specify the source interface for
ipv6-address } outbound interface of the best
establishing TCP connections
connect-interface route to the BGP peer as the
to a BGP peer or peer group
interface-type interface-number source interface for
establishing a TCP connection.
z To improve stability and reliability, you can specify a loopback interface as the source interface for
establishing TCP connections to a BGP peer. By doing so, a connection failure upon redundancy
availability will not affect TCP connection establishment.
z To establish multiple BGP connections to a BGP router, you need to specify on the local router the
respective source interfaces for establishing TCP connections to the peers on the peering BGP
router; otherwise, the local BGP router may fail to establish TCP connections to the peers when
using the outbound interfaces of the best routes as the source interfaces.
Allowing the establishment of a Non-Direct EBGP connection
Follow these steps to allow the establishment of EBGP connection to a non-directly connected
peer/peer group:
Allow the establishment of EBGP peer { ipv6-group-name | Required

connection to a non directly connected ipv6-address } ebgp-max-hop Not configured by
peer/peer group [ hop-count ] default.
In general, direct links should be available between EBGP peers. If not, you can use the peer
ebgp-max-hop command to establish a multi-hop TCP connection in between. However, you need not
use this command for direct EBGP connections with loopback interfaces.
Configuring a Description for a Peer/Peer Group
Follow these steps to configure description for a peer/peer group:
1-5
peer { ipv6-group-name | Optional

Configure a description for a
ipv6-address } description
peer/peer group Not configured by default.
description-text
The peer group to be configured with a description must have been created.
Disabling Session Establishment to a Peer/Peer Group
Follow these steps to disable session establishment to a peer/peer group:
Disable session establishment peer { ipv6-group-name | Optional

to a peer/peer group ipv6-address } ignore Not disabled by default
Logging Peer State Changes
Follow these steps to configure to log on the session and event information of a peer/peer group:
Enable logging of peer changes Optional

log-peer-change
globally Enabled by default.
Enable the state change peer { ipv6-group-name | Optional

logging for a peer or peer group ipv6-address } log-change Enabled by default.
1-6
Refer to BGP Commands in the IP Routing Volume for information about the log-peer-change
command.

The task includes routing information filtering, routing policy application and route dampening.
Prerequisites

z Enable IPv6
z Configure the IPv6 BGP basic functions
Configuring IPv6 BGP Route Redistribution
Follow these steps to configure IPv6 BGP route redistribution:
Enable default route Optional

redistribution into the IPv6 BGP default-route imported
routing table Not enabled by default.
import-route protocol [ process-id ] Required

Enable route redistribution from
[ med med-value | route-policy
another routing protocol Not enabled by default.
If the default-route imported command is not configured, using the import-route command cannot
redistribute any IGP default route.
Advertising a Default Route to a Peer/Peer Group
Follow these steps to advertise a default route to a peer/peer group:
1-7
peer { ipv6-group-name | ipv6-address } Required

Advertise a default route to a
default-route-advertise [ route-policy Not advertised by
peer/peer group
route-policy-name ] default.
With the peer default-route-advertise command executed, the local router advertises a default route
with itself as the next hop to the specified peer/peer group, regardless of whether the default route is
available in the routing table.
Configuring Outbound Route Filtering
Follow these steps to configure outbound route filtering:
filter-policy { acl6-number | Required

Configure the filtering of
ipv6-prefix ipv6-prefix-name }
outgoing routes Not configured by default.
export [ protocol process-id ]
peer { ipv6-group-name | Required
Apply a routing policy to routes
ipv6-address } route-policy
advertised to a peer/peer group Not applied by default.
route-policy-name export
Specify an IPv6 ACL to filer peer { ipv6-group-name | Required
routes advertised to a ipv6-address } filter-policy
peer/peer group acl6-number export Not specified by default.
Specify an AS path ACL to filer peer { ipv6-group-name | Required

routes advertised to a ipv6-address } as-path-acl
peer/peer group as-path-acl-number export Not specified by default.
Specify an IPv6 prefix list to filer peer { ipv6-group-name | Required

routes advertised to a ipv6-address } ipv6-prefix
peer/peer group ipv6-prefix-name export Not specified by default.
IPv6 BGP advertises routes passing the specified policy to peers. Using the protocol argument can filter
only the routes redistributed from the specified protocol. If no protocol is specified, IPv6 BGP filters all
routes to be advertised, including redistributed routes and routes imported with the network command.
1-8
Configuring Inbound Route Filtering
Follow these steps to configure inbound route filtering:

ipv6-prefix ipv6-prefix-name }
filtering Not configured by default.
import
from a peer/peer group Not applied by default.
route-policy-name import
Specify an ACL to filter routes peer { ipv6-group-name | Required
imported from a peer/peer ipv6-address } filter-policy
group acl6-number import Not specified by default.
Specify an AS path ACL to filter peer { ipv6-group-name | Required

routing information imported ipv6-address } as-path-acl
from a peer/peer group as-path-acl-number import Not specified by default.
Specify an IPv6 prefix list to

filter routing information
ipv6-address } ipv6-prefix
imported from a peer/peer Not specified by default.
ipv6-prefix-name import
group
Specify the upper limit of peer { ipv6-group-name | Optional
prefixes allowed to receive from ipv6-address } route-limit limit
a peer/peer group [ percentage ] Unlimited by default.
z Only routes passing the configured filtering can be added into the local IPv6 BGP routing table.
z Members of a peer group can have different inbound route filtering policies.
Configuring IPv6 BGP and IGP Route Synchronization
With this feature enabled and when a non-BGP router is responsible for forwarding packets in an AS,
IPv6 BGP speakers in the AS cannot advertise routing information to outside ASs unless all routers in
the AS know the latest routing information.
By default, when a BGP router receives an IBGP route, it only checks the reachability of the routes next
hop before advertisement. If the synchronization feature is configured, only the IBGP route is advertised
by IGP can the route be advertised to EBGP peers.
1-9
Follow these steps to configure IPv6 BGP and IGP route synchronization:
Enable route synchronization Required

synchronization
between IPv6 BGP and IGP Not enabled by default.
Configuring Route Dampening
dampening [ half-life-reachable Optional

Configure IPv6 BGP route half-life-unreachable reuse suppress
dampening parameters ceiling | route-policy Not configured by
route-policy-name ]* default.
Configuring IPv6 BGP Route Attributes

This section describes how to use IPv6 BGP route attributes to modify BGP routing policy. These
attributes are:
z IPv6 BGP protocol preference
z Default LOCAL_PREF attribute
z MED attribute
z NEXT_HOP attribute
z AS_PATH attribute
Prerequisites
Before configuring this task, you have:

z Enabled IPv6 function
z Configured IPv6 BGP basic functions
1-10
Configuring IPv6 BGP Preference and Default LOCAL_PREF and NEXT_HOP
Attributes
Follow these steps to perform this configuration:
preference Optional
Configure preference values for { external-preference The default preference values
IPv6 BGP external, internal, internal-preference of external, internal and local
local routes local-preference | route-policy routes are 255, 255, 130
route-policy-name } respectively.
Configure the default local Optional

default local-preference value
preference The value defaults to 100.
Required
By default, IPv6 BGP specifies
Advertise routes to a peer/peer the local router as the next hop
peer { ipv6-group-name |
group with the local router as for routes sent to an EBGP
ipv6-address } next-hop-local
the next hop peer/peer group, but not for
routes sent to an IBGP
peer/peer group.
z To make sure an IBGP peer can find the correct next hop, you can configure routes advertised to
the peer to use the local router as the next hop. If BGP load balancing is configured, the local router
specifies itself as the next hop of routes sent to a peer/peer group regardless of whether the peer
next-hop-local command is configured.
z In a third party next hop" network, that is, the two IPv6 EBGP peers reside in a common broadcast
subnet, the router does not specify itself as the next hop for routes sent to the EBGP peer by
default, unless the peer next-hop-local command is configured.
Configuring the MED Attribute
Follow these steps to configure the MED attribute:
Optional
Configure a default MED value default med med-value
Defaults to 0
1-11
Enable the comparison of MED for routes Optional

compare-different-as-med
from different EBGP peers Not enabled by default.
Enable the comparison of MED for routes Optional

bestroute compare-med
from each AS Disabled by default
Enable the comparison of MED for routes bestroute Optional

from confederation peers med-confederation Disabled by default
Configuring the AS_PATH Attribute
Follow these steps to configure the AS_PATH attribute:
Allow the local AS number to

appear in AS_PATH of routes
ipv6-address } allow-as-loop
from a peer/peer group and Not allowed by default
[ number ]
specify the repeat times
Specify a fake AS number for a
ipv6-address } fake-as
peer/peer group Not specified by default.
as-number
Disable IPv6 MBGP from Optional
considering the AS_PATH bestroute as-path-neglect
during best route selection Enabled by default.
Configure to carry only the Optional

public AS number in updates By default, IPv6 BGP updates
ipv6-address } public-as-only
sent to a peer/peer group carry private AS number.
Substitute the local AS number
for the AS number of a peer { ipv6-group-name | Optional
peer/peer group identified in ipv6-address } substitute-as Not substituted by default
the AS_PATH attribute
Tuning and Optimizing IPv6 BGP Networks

This section describes configurations of IPv6 BGP timers, IPv6 BGP connection soft reset and the
maximum number of load balanced routes.
z IPv6 BGP timers
After establishing an IPv6 BGP connection, two routers send keepalive messages periodically to each
other to keep the connection. If a router receives no keepalive message from the peer after the holdtime
elapses, it tears down the connection.
When establishing an IPv6 BGP connection, the two parties compare their holdtimes, taking the shorter
one as the common holdtime. If the holdtime is 0, neither keepalive massage is sent, nor holdtime is
checked.
1-12
z IPv6 BGP connection soft reset
After modifying a route selection policy, you have to reset IPv6 BGP connections to make the new one
take effect, causing a short time disconnection. The current IPv6 BGP implementation supports the
route-refresh feature that enables dynamic IPv6 BGP routing table refresh without needing to
disconnect IPv6 BGP links.
With this feature enabled on all IPv6 BGP routers in a network, when a routing policy modified on a
router, the router advertises a route-refresh message to its peers, which then send their routing
information back to the router. Therefore, the local router can perform dynamic routing information
update and apply the new policy without tearing down connections.
If a peer not supporting route-refresh exists in the network, you need to configure the peer
keep-all-routes command on the router to save all routes from the peer. When the routing policy is
changed, the system will update the IPv6 BGP routing table and apply the new policy.
Prerequisites
Before configuring IPv6 BGP timers, you need to:

z Enable IPv6
z Configure IPv6 BGP basic functions
Configuring IPv6 BGP Timers
Follow these steps to configure IPv6 BGP timers:
Specify keepalive timer keepalive keepalive

interval and holdtime hold holdtime Optional
Configure The keepalive interval
IPv6 BGP peer { ipv6-group-name | defaults to 60 seconds,
Configure keepalive
timers ipv6-address } timer holdtime defaults to 180
interval and holdtime
keepalive keepalive hold seconds.
for a peer/peer group
holdtime
Optional
Configure the interval for sending the ipv6-address } The interval for sending the
same update to a peer/peer group route-update-interval same update to an IBGP peer
interval or an EBGP peer defaults to
15 seconds or 30 seconds
z Timers configured using the timer command have lower priority than timers configured using the
peer timer command.
z The holdtime interval must be at least three times the keepalive interval.
1-13
Configuring IPv6 BGP Soft Reset
Enable route refresh
Follow these steps to enable route refresh:
peer { ipv6-group-name | ipv6-address } Optional

Enable route refresh
capability-advertise route-refresh Enabled by default.
Perform manual soft-reset
Follow these steps to perform manual soft reset:
Save all routes from a peer/peer Optional

peer { ipv6-group-name | ipv6-address }
group, not letting them go through Not saved by
keep-all-routes
the inbound policy default.
refresh bgp ipv6 { all | ipv6-address | Required
Soft-reset BGP connections
group ipv6-group-name | external |
manually
internal } { export | import }
If the peer keep-all-routes command is used, all routes from the peer/peer group will be saved
regardless of whether the filtering policy is available. These routes will be used to generate IPv6 BGP
routes after soft-reset is performed.
Configuring the Maximum Number of Load-Balanced Routes
Follow these steps to configure the maximum number of load balanced routes:
1-14
Required
balance number By default, no load balancing is
number of load balanced routes
enabled.
Configuring a Large Scale IPv6 BGP Network

In a large-scale IPv6 BGP network, configuration and maintenance become no convenient due to too
many peers. In this case, configuring peer groups makes management easier and improves route
distribution efficiency. Peer group includes IBGP peer group, where peers belong to the same AS, and
EBGP peer group, where peers belong to different ASs. If peers in an EBGP group belong to the same
external AS, the EBGP peer group is a pure EBGP peer group, and if not, a mixed EBGP peer group.
In a peer group, all members enjoy a common policy. Using the community attribute can make a set of
IPv6 BGP routers in multiple ASs enjoy the same policy, because sending of community between IPv6
BGP peers is not limited by AS.
To guarantee connectivity between IBGP peers, you need to make them fully meshed, but it becomes
unpractical when there are too many IBGP peers. Using route reflectors or confederation can solve it. In
a large-scale AS, both of them can be used.
Confederation configuration of IPv6 BGP is identical to that of BGP4, so it is not mentioned here. The
following describes:
z Configuring IPv6 BGP peer groups
z Configuring IPv6 BGP community
z Configuring IPv6 BGP route reflectors
Prerequisites
Before configuring IPv6 BGP peer groups, you need to:

z Make peer nodes accessible to each other at the network layer
z Enable BGP and configure a router ID.
Configuring IPv6 BGP Peer Group
Configuring an IBGP peer group
Follow these steps to configure an IBGP group:
Create an IBGP peer group group ipv6-group-name [ internal ] Required

peer ipv6-address group Required
Add a peer into the group ipv6-group-name [ as-number
as-number ] Not added by default
1-15
Creating a pure EBGP peer group
Follow these steps to configure a pure EBGP group:
group ipv6-group-name
Create an EBGP peer group Required
external
Configure the AS number for peer ipv6-group-name Required

the peer group as-number as-number Not configured by default.
Add an IPv6 peer into the peer peer ipv6-address group Required
group ipv6-group-name Not added by default
z To create a pure EBGP peer group, you need to specify an AS number for the peer group.
z If a peer was added into an EBGP peer group, you cannot specify any AS number for the peer
group.
Creating a mixed EBGP peer group
Follow these steps to create a mixed EBGP peer group:
Create an EBGP peer group group ipv6-group-name external Required
Specify the AS number of an peer ipv6-address as-number Required

IPv6 peer as-number Not specified by default.
Add the IPv6 peer into the peer peer ipv6-address group Required
group ipv6-group-name Not added by default
When creating a mixed EBGP peer group, you need to create a peer and specify its AS number that can
be different from AS numbers of other peers, but you cannot specify AS number for the EBGP peer
group.
1-16
Configuring IPv6 BGP Community
Advertise community attribute to a peer/peer group
Follow these steps to advertise community attribute to a peer/peer group:

Advertise community attribute
ipv6-address }
to a peer/peer group Not advertised by default.
advertise-community
Advertise extended community
ipv6-address }
attribute to a peer/peer group Not advertised by default.
advertise-ext-community
Apply a routing policy to routes advertised to a peer/peer group
Follow these steps to apply a routing policy to routes advertised to a peer/peer group:

advertised to a peer/peer group Not applied by default.
z When configuring IPv6 BGP community, you need to configure a routing policy to define the
community attribute, and apply the routing policy to route advertisement.
z For routing policy configuration, refer to Routing Policy Configuration in the IP Routing Volume.
Configuring an IPv6 BGP Route Reflector
Follow these steps to configure an IPv6 BGP route reflector:
1-17
reflector and specify a
ipv6-address } reflect-client Not configured by default.
peer/peer group as a client

between clients Enabled by default.
Optional
route reflector cluster-id By default, a route reflector uses
its router ID as the cluster ID
z In general, since the route reflector forwards routing information between clients, it is not required
to make clients of a route reflector fully meshed. If clients are fully meshed, it is recommended to
disable route reflection between clients to reduce routing costs.
z If a cluster has multiple route reflectors, you need to specify the same cluster ID for these route
reflectors to avoid routing loops.
Configuring 6PE
Support for this feature varies with devices.
IPv6 provider edge (6PE) is a transition technology with which Internet service providers (ISPs) can use
existing IPv4 backbone networks to provide access capability for sparsely populated IPv6 networks,
allowing customer edge (CE) routers in these isolated IPv6 networks to communicate with IPv4 PE
routers.
Work mechanism of 6PE:
IPv6 routing information from users is converted into IPv6 routing information with labels and then is
flooded into IPv4 backbone networks of ISPs through internal border gateway protocol (IBGP) sessions.
When IPv6 packets are forwarded, they will be labeled when entering tunnels of backbone networks.
The tunnels can be GRE tunnels or MPLS LSPs.
IGPs running on ISP networks can be OSPF or IS-IS. Static routing, IGP, or EBGP can be used between
CE and 6PE.
1-18
Figure 1-1 Network diagram for 6PE
The P (Provider) router in the above figure refers to a backbone router in the network of a service
provider. P is not directly connected with a CE and is required to have the basic MPLS capability.
When an ISP wants to utilize the existing IPv4/MPLS network to provide IPv6 traffic switching capability
through MPLS, only the PE routers need to be upgraded. Therefore, it is undoubtedly a high efficient
solution that ISPs use the 6PE technology as an IPv6 transition mechanism. Furthermore, the operation
risk of the 6PE technology is very low.
Before configuring 6PE, you need to:

z Configure the MPLS basic capability for the IPv4 MPLS backbone. For details, refer to MPLS
Basics Configuration in the MPLS Volume;
z Configure the IPv6 BGP peer on the PE devices. For details, refer to Configuring IPv6 BGP Basic
Functions.
z If a peer group is to be specified, you need to create the peer group beforehand in BGP view.
Configuring Basic 6PE Capabilities
Follow these steps to configure the 6PE basic capabilities:
Specify the AS number for the peer { ipv4-group-name | Required

6PE peer or peer group ipv4-address } as-number as-number Not specified by default.
Enable the 6PE peer or peer peer { ipv4-group-name | Required

group ipv4-address } enable Not enabled by default.
Enable exchange of labeled Required

IPv6 routes with the 6PE peer
ipv4-address } label-route-capability Not enabled by default.
or peer group
1-19
Configuring Optional 6PE Capabilities
Follow these steps to configure the 6PE optional capabilities:

Specify the AS number for the
ipv4-address } as-number
6PE peer or peer group Not specified by default.
as-number
Enable the 6PE peer or peer peer { ipv4-group-name | Required

group ipv4-address } enable Not enabled by default.
Optional
Advertise community attribute peer { group-name | ipv4-address }
to the 6PE peer or peer group advertise-community Not advertised by
default.
Advertise extended community Optional

peer { group-name | ipv4-address }
attribute to the 6PE peer or Not advertised by
advertise-ext-community
peer group default.
appear in routes from the peer peer { group-name | ipv4-address } Optional
or peer group and specify the allow-as-loop [ number ] Not allowed by default
repeat times
Specify an AS path ACL to filter peer { group-name | ipv4-address } Optional

routes from or to the 6PE peer as-path-acl as-path-acl-number Not configured by
or peer group { import | export } default.
peer { group-name | ipv4-address } Optional

Advertise a default route to the
default-route-advertise Not advertised by
6PE peer or peer group
[ route-policy route-policy-name ] default.
Configure an inbound or Optional
outbound IPv6 ACL based
filter-policy acl6-number { import | Not configured by
filtering policy for the 6PE peer
export } default.
or peer group
peer ipv4-address group Optional
Add an 6PE peer to an existing
group-name [ as-number
peer group Not added by default
as-number ]
Configure an inbound or Optional
outbound IPv6 prefix list based
ipv6-prefix ipv6-prefix-name Not configured by
filtering policy for the 6PE peer
{ import | export } default.
or peer group
Keep all routes from the 6PE
peer or peer group, including peer { group-name | ipv4-address } Optional
routes not passing the inbound keep-all-routes Not kept by default
filtering policy
Configure the device as a route Optional

reflector and the 6PE peer or Not configured by
reflect-client
peer group as a client default.
1-20
Configure an upper limit of IPv6
address prefixes that can be peer { group-name | ipv4-address } Optional
received from the 6PE peer or route-limit limit [ percentage ] No limitation by default
peer group
Apply a routing policy to routes peer { group-name | ipv4-address } Optional
outgoing or incoming from the route-policy route-policy-name
6PE peer or peer group { import | export } Not applied by default.
Display information about the display bgp ipv6 peer [ group-name Optional
6PE peer or peer group log-info | ipv4-address verbose ] Available in any view
display bgp ipv6 routing-table peer

Display routes from or to the ipv4-address { advertised-routes | Optional
6PE peer or peer group received-routes } [ network-address Available in any view
prefix-length | statistic ]
Perform soft reset on the Optional
refresh bgp ipv6 ipv4-address
inbound or outbound BGP 6PE
{ export | import } Available in user view
connection
Optional
Reset a BGP 6PE connection reset bgp ipv6 ipv4-address
1-21
Displaying and Maintaining IPv6 BGP
Displaying BGP

Display IPv6 BGP peer group
display bgp ipv6 group [ ipv6-group-name ]
information
Display IPv6 BGP advertised
display bgp ipv6 network
routing information
Display IPv6 BGP AS path display bgp ipv6 paths
information [ as-regular-expression ]
display bgp ipv6 peer [ group-name log-info |
Display IPv6 BGP peer/peer
ipv4-address verbose | ipv6-address { log-info |
group information
verbose } | verbose ]
Display IPv6 BGP routing table display bgp ipv6 routing-table [ ipv6-address
information prefix-length ]
Display IPv6 BGP routing
display bgp ipv6 routing-table as-path-acl
information matching an AS
as-path-acl-number
path ACL
Display IPv6 BGP routing display bgp ipv6 routing-table community
information with the specified [ aa:nn<1-13> ] [ no-advertise | no-export |
community attribute no-export-subconfed ]* [ whole-match ]
display bgp ipv6 routing-table

community-list { basic-community-list-number
information matching an IPv6
[ whole-match ] |
BGP community list
Display dampened IPv6 BGP Available in
display bgp ipv6 routing-table dampened any view
routing information
Display IPv6 BGP dampening display bgp ipv6 routing-table dampening
parameter information parameter
information originated from
different-origin-as
different ASs
display bgp ipv6 routing-table flap-info

[ regular-expression as-regular-expression |
Display IPv6 BGP routing flap
as-path-acl as-path-acl-number |
statistics
network-address [ prefix-length
[ longer-match ] ] ]
Display labeled IPv6 BGP
display bgp ipv6 routing-table label
routing information
display bgp ipv6 routing-table peer

Display BGP routing
{ ipv4-address | ipv6-address }
information to or from an IPv4
{ advertised-routes | received-routes }
or IPv6 peer
[ network-address prefix-length | statistic ]
information matching a regular
regular-expression as-regular-expression
expression
display bgp ipv6 routing-table statistic
statistics
1-22
Support for the display bgp ipv6 routing-table label command varies by device.
Resetting IPv6 BGP Connections

refresh bgp ipv6 { ipv4-address | ipv6-address |
Perform soft reset on IPv6 BGP
all | external | group ipv6-group-name | internal }
connections
{ export | import } Available in
reset bgp ipv6 { as-number | ipv4-address | user view
Reset IPv6 BGP connections ipv6-address [ flap-info ] | all | group group-name |
external | internal }
Clearing IPv6 BGP Information

Clear dampened IPv6 BGP
reset bgp ipv6 dampening [ ipv6-address
routing information and release
prefix-length ]
suppressed routes Available in
reset bgp ipv6 flap-info user view
Clear IPv6 BGP route flap
[ ipv6-address/prefix-length | regexp
information
as-path-regexp | as-path-acl as-path-acl-number ]
IPv6 BGP Configuration Examples (on Routers)
Some examples for IPv6 BGP configuration are similar to those of BGP, so refer to BGP Configuration
in the IP Routing Volume for related information.
IPv6 BGP Basic Configuration
In Figure 1-2 are all IPv6 BGP routers. Between Router A and Router B is an EBGP connection. Router
B, Router C and Router D are fully meshed through IBGP connections.
1-23
Network diagram
Figure 1-2 Network diagram for IPv6 BGP basic configuration
AS 65009
S2/2 S2/1
9:3::2/64 9:2::1/64
Router C
S2/1
Router A 10::2/64 S2/1
S2/2 9:2::2/64
S2/1 9:3::1/64
10::1/64
AS 65008 S2/0 S2/0
9:1::1/64 9:1::2/64
Router B Router D
1) Configure IPv6 addresses for interfaces (omitted)

2) Configure IBGP connections
[RouterB] ipv6
[RouterB] bgp 65009
[RouterB-bgp] ipv6-family
[RouterB-bgp-af-ipv6] peer 9:1::2 as-number 65009
[RouterB-bgp-af-ipv6] peer 9:3::2 as-number 65009
[RouterB-bgp-af-ipv6] quit
[RouterB-bgp] quit
[RouterC] ipv6
[RouterC] bgp 65009
[RouterC-bgp] ipv6-family
[RouterC-bgp-af-ipv6] peer 9:3::1 as-number 65009
[RouterC-bgp-af-ipv6] peer 9:2::2 as-number 65009
[RouterC-bgp-af-ipv6] quit
[RouterC-bgp] quit
[RouterD] ipv6
[RouterD] bgp 65009
[RouterD-bgp] ipv6-family
[RouterD-bgp-af-ipv6] peer 9:1::1 as-number 65009
[RouterD-bgp-af-ipv6] peer 9:2::1 as-number 65009
[RouterD-bgp-af-ipv6] quit
[RouterD-bgp] quit
1-24
3) Configure the EBGP connection
[RouterA] ipv6
[RouterA] bgp 65008
[RouterA-bgp] ipv6-family
[RouterA-bgp-af-ipv6] peer 10::1 as-number 65009
[RouterA-bgp-af-ipv6] quit
[RouterA-bgp] quit
[RouterB] bgp 65008
[RouterB-bgp-af-ipv6] peer 10::2 as-number 65009
[RouterB-bgp] quit
# Display IPv6 peer information on Router B.

[RouterB] display bgp ipv6 peer

10::2 4 65008 3 3 0 0 00:01:16 Established

9:3::2 4 65009 2 3 0 0 00:00:40 Established
9:1::2 4 65009 2 4 0 0 00:00:19 Established
# Display IPv6 peer information on Router C.

[RouterC] display bgp ipv6 peer

9:3::1 4 65009 4 4 0 0 00:02:18 Established

9:2::2 4 65009 4 5 0 0 00:01:52 Established
Router A and B established an EBGP connection; Router B, C and D established IBGP connections
with each other.
1-25
IPv6 BGP Route Reflector Configuration
Router B receives an EBGP update and sends it to Router C, which is configured as a route reflector
with two clients: Router B and Router D.
Router B and Router D need not establish an IBGP connection because Router C reflects updates
between them.
Network diagram
Figure 1-3 Network diagram for IPv6 BGP route reflector configuration

2) Configure IPv6 BGP basic functions
[RouterA] ipv6
[RouterA] bgp 100
[RouterA-bgp-af-ipv6] network 1:: 64
[RouterB] ipv6
[RouterB] bgp 200
[RouterB-bgp-af-ipv6] peer 101::1 next-hop-local
[RouterC] ipv6
[RouterC] bgp 200
1-26
[RouterC-bgp] ipv6-family
[RouterC-bgp-af-ipv6] peer 101::2 as-number 200
[RouterC-bgp-af-ipv6] peer 102::2 as-number 200
[RouterD] ipv6
[RouterD] bgp 200
[RouterD-bgp] ipv6-family
[RouterD-bgp-af-ipv6] peer 102::1 as-number 200
3) Configure route reflector
# Configure Router C as a route reflector, Router B and Router D as its clients.
[RouterC-bgp-af-ipv6] peer 101::2 reflect-client
[RouterC-bgp-af-ipv6] peer 102::2 reflect-client
Use the display bgp ipv6 routing-table command on Router B and Router D respectively, you can find
both of them have learned the network 1::/64.
6PE Configuration
z Routers PE 1 and PE 2 support 6PE;

z Routers CE 1 and CE 2 support IPv6;
z Between the PE routers is the IPv4/MPLS network of an ISP. The two PEs establish an IPv4 IBGP
connection inbetween, and the IGP used is OSPF.
z The CEs reside in IPv6 networks. A CE and a PE use IPv6 link-local addresses to exchange
routing information via a static route;
z Connect the two IPv6 networks through the IPv4/MPLS network with the 6PE feature.
Network diagram
Figure 1-4 Network diagram for 6PE configuration (on routers)
1-27
1) Configure CE 1
# Enable IPv6 packet forwarding.
<CE1> system-view
[CE1] ipv6
# Specify IP addresses for interfaces.

[CE1] interface serial 2/0
[CE1-Serial2/0] ipv6 address auto link-local
[CE1-Serial2/0] quit
[CE1] interface loopback0
[CE1-LoopBack0] ipv6 address 1::1/128
[CE1-LoopBack0] quit
# Configure an IPv6 static route to PE 1.

[CE1] ipv6 route-static :: 0 serial2/0
2) Configure PE 1
# Enable IPv6 packet forwarding, MPLS and LDP.
<PE1> system-view
[PE1] ipv6
[PE1] mpls lsr-id 2.2.2.2
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure an IPv6 link-local address for Serial 2/0.

[PE1] interface serial 2/0
[PE1-Serial2/0] ipv6 address auto link-local
[PE1-Serial2/0] quit
# Configure an IP address for Serial 2/1 and enable MPLS and LDP.
[PE1-Serial2/1] ip address 1.1.1.1 16
[PE1-Serial2/1] mpls
[PE1-Serial2/1] mpls ldp
# Configure IP addresses for Loopback 0.

[PE1] interface loopback 0
[PE1-LoopBack0] ip address 2.2.2.2 32
[PE1-LoopBack0] ipv6 address 2::2/128
[PE1-LoopBack0] quit
# Configure IBGP, enable the peers 6PE capabilities, and redistribute IPv6 direct and static routes.
[PE1] bgp 65100
[PE1-bgp] peer 3.3.3.3 as-number 65100
[PE1-bgp] peer 3.3.3.3 connect-interface loopback 0
1-28
[PE1-bgp] ipv6-family
[PE1-bgp-af-ipv6] import-route direct
[PE1-bgp-af-ipv6] import-route static
[PE1-bgp-af-ipv6] peer 3.3.3.3 enable
[PE1-bgp-af-ipv6] peer 3.3.3.3 label-route-capability
[PE1-bgp-af-ipv6] quit
[PE1-bgp] quit
# Configure the static route to CE 1.

[PE1] ipv6 route-static 1::1 128 serial2/0
# Configure OSPF for LSP establishment.

[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
[PE1]
3) Configure PE 2
<PE2> system-view
[PE2] ipv6
[PE2] mpls
[PE2-mpls] lsp-trigger all
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2-Serial2/1] ip address 1.1.1.2 16
[PE2-Serial2/1] mpls
[PE2-Serial2/1] mpls ldp
[PE2-Serial2/0] ipv6 address auto link-local
[PE2-LoopBack0] ipv6 address 3::3/128
# Configure IBGP, enable the peers 6PE capabilities, and redistribute IPv6 direct and static routes.
[PE2] bgp 65100
[PE2-bgp] peer 2.2.2.2 as-number 65100
[PE2-bgp] ipv6-family
[PE2-bgp-af-ipv6] import-route direct
[PE2-bgp-af-ipv6] import-route static
[PE2-bgp-af-ipv6] peer 2.2.2.2 enable
1-29
[PE2-bgp-af-ipv6] peer 2.2.2.2 label-route-capability
[PE2-bgp-af-ipv6] quit
[PE2-bgp] quit
# Configure the static route to CE 2.

[PE1] ipv6 route-static 4::4 128 serial2/0
# Configure OSPF for LSP establishment.

[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
[PE1]
4) Configure CE 2
# Enable IPv6 packet forwarding and specify IP addresses for interfaces.
<CE2> system-view
[CE2] ipv6
[CE2] interface serial 2/0
[CE2-Serial2/0] ipv6 address auto link-local
[CE2-Serial2/0] quit
[CE2] interface loopback 0
[CE2-LoopBack0] ipv6 address 4::4/128
[CE2-LoopBack0] quit
# Configure the static route to PE 2.

[CE2] ipv6 route-static :: 0 serial2/0
Verify the configuration
# Display MPLS LSP information on PE 1.

<PE1> display mpls lsp
--------------------------------------------------------------
LSP Information: BGP IPV6 LSP
--------------------------------------------------------------
FEC : 1::1
In Label : 1024 Out Label : -----
In Interface : ----- OutInterface : -----
Vrf Name :
FEC : 2::2
In Label : 1025 Out Label : -----
In Interface : ----- OutInterface : -----
Vrf Name :
---------------------------------------------------------------
LSP Information: LDP LSP
---------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
3.3.3.3/32 NULL/3 -/S2/1
2.2.2.2/32 3/NULL S2/1/-
1-30
# Display the IPv6 BGP routing table on PE 1.
<PE1> display bgp ipv6 routing-table

h - history, i - internal, s - suppressed, S Stale
*> Network : 1::1 PrefixLen : 128

NextHop : FE80::E142:0:4607:1 LocPrf :
PrefVal : 0 Label : NULL
MED : 0
Path/Ogn: ?
*> Network : 2::2 PrefixLen : 128

NextHop : ::1 LocPrf :
MED : 0
Path/Ogn: ?
*>i Network : 3::3 PrefixLen : 128

NextHop : ::FFFF:3.3.3.3 LocPrf : 100
MED : 0
Path/Ogn: ?
*>i Network : 4::4 PrefixLen : 128

NextHop : ::FFFF:3.3.3.3 LocPrf : 100
MED : 0
Path/Ogn: ?
After the above configuration, you can ping through the IPv6 address 4::4 of CE 2 from CE 1.
IPv6 BGP Configuration Examples (on Switches)
Some examples for IPv6 BGP configuration are similar to those of BGP4, so refer to BGP Configuration
in the IP Routing Volume for related information.
1-31
IPv6 BGP Basic Configuration
In the following figure are all IPv6 BGP switches. Between Switch A and Switch B is an EBGP
connection. Switch B, Switch C and Switch D are fully meshed through IBGP connections.
Network diagram
Figure 1-5 IPv6 BGP basic configuration network diagram

2) Configure IBGP connections
[SwitchB] ipv6
[SwitchB] bgp 65009
[SwitchB-bgp] ipv6-family
[SwitchB-bgp-af-ipv6] peer 9:1::2 as-number 65009
[SwitchB-bgp-af-ipv6] peer 9:3::2 as-number 65009
[SwitchB-bgp-af-ipv6] quit
[SwitchB-bgp] quit
[SwitchC] ipv6
[SwitchC] bgp 65009
[SwitchC-bgp] ipv6-family
[SwitchC-bgp-af-ipv6] peer 9:3::1 as-number 65009
[SwitchC-bgp-af-ipv6] peer 9:2::2 as-number 65009
[SwitchC-bgp-af-ipv6] quit
[SwitchC-bgp] quit
[SwitchD] ipv6
[SwitchD] bgp 65009
1-32
[SwitchD-bgp] ipv6-family
[SwitchD-bgp-af-ipv6] peer 9:1::1 as-number 65009
[SwitchD-bgp-af-ipv6] peer 9:2::1 as-number 65009
[SwitchD-bgp-af-ipv6] quit
[SwitchD-bgp] quit
3) Configure the EBGP connection
[SwitchA] ipv6
[SwitchA] bgp 65008
[SwitchA-bgp] ipv6-family
[SwitchA-bgp-af-ipv6] peer 10::1 as-number 65009
[SwitchA-bgp-af-ipv6] quit
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp-af-ipv6] peer 10::2 as-number 65008
# Display IPv6 peer information on Switch B.

[SwitchB] display bgp ipv6 peer

10::2 4 65008 3 3 0 0 00:01:16 Established

9:3::2 4 65009 2 3 0 0 00:00:40 Established
9:1::2 4 65009 2 4 0 0 00:00:19 Established
# Display IPv6 peer information on Switch C.

[SwitchC] display bgp ipv6 peer

9:3::1 4 65009 4 4 0 0 00:02:18 Established

9:2::2 4 65009 4 5 0 0 00:01:52 Established
Switch A and B has established an EBGP connection; Switch B, C and D have established IBGP
connections with each other.
1-33
IPv6 BGP Route Reflector Configuration
Switch B receives an EBGP update and sends it to Switch C, which is configured as a route reflector
with two clients: Switch B and Switch D.
Switch B and Switch D need not establish an IBGP connection because Switch C reflects updates
between them.
Network diagram
Figure 1-6 Network diagram for IPv6 BGP route reflector configuration
Route
Reflector
101::1/96
Switch C 102::1/96
Vlan-int200 IBGP IBGP
Switch A 100::1/96
Vlan-int100
Vlan-int200 102::2/96
Vlan-int300
100::2/96
101::2/96
AS 100
Switch B AS 200 Switch D
1) Configure IPv6 addresses for VLAN interfaces (omitted)

2) Configure IPv6 BGP basic functions
[SwitchA] ipv6
[SwitchA] bgp 100
[SwitchA-bgp-af-ipv6] network 1:: 64
#Configure Switch B.
[SwitchB] ipv6
[SwitchB] bgp 200
[SwitchB-bgp-af-ipv6] peer 101::1 next-hop-local
[SwitchC] ipv6
[SwitchC] bgp 200
1-34
[SwitchC-bgp] ipv6-family
[SwitchC-bgp-af-ipv6] peer 101::2 as-number 200
[SwitchC-bgp-af-ipv6] peer 102::2 as-number 200
[SwitchD] ipv6
[SwitchD] bgp 200
[SwitchD-bgp] ipv6-family
[SwitchD-bgp-af-ipv6] peer 102::1 as-number 200
3) Configure route reflector
# Configure Switch C as a route reflector, Switch B and Switch D as its clients.
[SwitchC-bgp-af-ipv6] peer 101::2 reflect-client
[SwitchC-bgp-af-ipv6] peer 102::2 reflect-client
Use the display bgp ipv6 routing-table command on Switch B and Switch D respectively, you can find
both of them have learned the network 1::/64.
Troubleshooting IPv6 BGP Configuration

No IPv6 BGP Peer Relationship Established
Symptom
Display BGP peer information using the display bgp ipv6 peer command. The state of the connection
to the peer cannot become established.
Analysis
To become IPv6 BGP peers, any two routers need to establish a TCP session using port 179 and
exchange open messages successfully.
Processing steps
1) Use the display current-configuration command to verify the peers AS number.

2) Use the display bgp ipv6 peer command to verify the peers IPv6 address.
3) If the loopback interface is used, check whether the peer connect-interface command is
configured.
4) If the peer is not directly connected, 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 ipv6 status command to check the TCP connection.
8) Check whether an ACL for disabling TCP port 179 is configured.
1-35
Table of Contents
1 IPv6 IS-IS Configuration1-1

Introduction to IPv6 IS-IS 1-1
Configuring IPv6 IS-IS Basic Functions 1-2
Configuring IPv6 IS-IS Routing Information Control 1-2
Displaying and Maintaining IPv6 IS-IS1-4
IPv6 IS-IS Configuration Example (on Routers) 1-4
IPv6 IS-IS Configuration Example (on Switches) 1-6
i
1 IPv6 IS-IS Configuration
IPv6 IS-IS supports all the features of IPv4 IS-IS except that it advertises IPv6 routing information
instead. This document describes only IPv6 IS-IS exclusive configuration tasks. For other configuration
tasks, refer to IS-IS Configuration in the IP Routing Volume.
When configuring IPv6 IS-IS, go to these sections for information you are interested in:
z Introduction to IPv6 IS-IS
z Configuring IPv6 IS-IS Basic Functions
z Configuring IPv6 IS-IS Routing Information Control
z Displaying and Maintaining IPv6 IS-IS
z IPv6 IS-IS Configuration Example (on Routers)
z IPv6 IS-IS Configuration Example (on Switches)
Introduction to IPv6 IS-IS

The IS-IS routing protocol (Intermediate System-to-Intermediate System intra-domain routing
information exchange protocol) supports multiple network protocols, including IPv6. IS-IS with IPv6
support is called IPv6 IS-IS dynamic routing protocol. The international engineer task force (IETF)
defines two type-length-values (TLVs) and a new network layer protocol identifier (NLPID) to enable
IPv6 support for IS-IS.
TLV is a variable field in the link state PDU or link state packet (LSP). The two TLVs are:
z IPv6 Reachability: Defines the prefix, metric of routing information to indicate the network
reachability, with a type value of 236 (0xEC).
z IPv6 Interface Address: Similar with the IP Interface Address TLV of IPv4, it transforms the 32-bit
IPv4 address to the 128-bit IPv6 address.
NLPID is an 8-bit field with a value of 142 (0x8E), which indicates the network layer protocol packet. If
the IS-IS router supports IPv6, the advertised routing information must be marked with the NLPID.
For information about IS-IS, refer to IS-IS Configuration in the IP Routing Volume.
1-1
Configuring IPv6 IS-IS Basic Functions
You can implement IPv6 inter-networking through configuring IPv6 IS-IS in IPv6 network environment.
Before the configuration, accomplish the following tasks first:

z Enable IPv6 globally
z Configure IP addresses for interfaces, and make sure all neighboring nodes are reachable.
z Enable IS-IS
Follow these steps to configure the basic functions of IPv6 IS-IS:
To do Use command to Remarks

Enable an IS-IS process and Required

isis [ process-id ]
enter IS-IS view Not enabled by default
Configure the network entity Required

network-entity net
title for the IS-IS process Not configured by default
Enable IPv6 for the IS-IS Required

ipv6 enable
process Disabled by default
interface-number
Enable IPv6 for an IS-IS Required

isis ipv6 enable [ process-id ]
process on the interface Disabled by default
Configuring IPv6 IS-IS Routing Information Control

You need to complete the IPv6 IS-IS basic function configuration before configuring this task.
Follow these steps to configure IPv6 IS-IS routing information control:

Enter IS-IS view isis [ process-id ]
1-2
Define the priority for IPv6 IS-IS ipv6 preference { route-policy Optional
routes route-policy-name | preference } * 15 by default
ipv6 summary ipv6-prefix

Configure an IPv6 IS-IS prefix-length [ avoid-feedback | Optional
summary route generate_null0_route | [ level-1 | Not configured by default
level-1-2 | level-2 ] | tag tag ] *
ipv6 default-route-advertise Optional

Generate an IPv6 IS-IS default
[ [ level-1 | level-2 | level-1-2 ] | No IPv6 default route is
route
route-policy route-policy-name ] * defined by default.
ipv6 filter-policy { acl6-number | Optional
Configure IPv6 IS-IS to filter ipv6-prefix ipv6-prefix-name |
incoming routes route-policy route-policy-name } No filtering policy is
import defined by default
ipv6 import-route protocol

Configure IPv6 IS-IS to [ process-id ] [ allow-ibgp ] [ cost Optional
redistribute routes from another cost | [ level-1 | level-2 | level-1-2 ] |
routing protocol route-policy route-policy-name | Not configured by default
tag tag ] *

number of redistributed Level ipv6 import-route limit number The default varies with
1/Level 2 IPv6 routes devices.
ipv6 filter-policy { acl6-number |
Configure the filtering of ipv6-prefix ipv6-prefix-name | Optional
outgoing redistributed routes route-policy route-policy-name } Not configured by default
export [ protocol [ process-id ] ]
ipv6 import-route isisv6 level-2

into level-1 [ filter-policy Optional
Enable route leaking { acl6-number | ipv6-prefix
ipv6-prefix-name | route-policy Not enabled by default
route-policy-name } | tag tag ] *

ipv6 maximum load-balancing
of equal-cost load balanced The default varies by
number
routes device.
z The ipv6 filter-policy export command is usually used in combination with the ipv6 import-route
command. If no protocol is specified for the ipv6 filter-policy export command, routes
redistributed from all routing protocols are filtered before advertisement. If a protocol is specified,
only routes redistributed from the routing protocol are filtered for advertisement.
z For information about ACL, refer to ACL Configuration in the Security Volume.
z For information about routing policy and IPv6 prefix list, refer to Routing Policy Configuration in the
IP Routing Volume.
1-3
Displaying and Maintaining IPv6 IS-IS
Display brief IPv6 IS-IS
display isis brief Available in any view
information
display isis debug-switches

Display the status of the debug
{ process-id | vpn-instance Available in any view
switches
vpn-instance-name }
display isis interface [ verbose ]
Display IS-IS enabled interface
[ process-id | vpn-instance Available in any view
information
vpn-instance-name ]
Display IS-IS license
display isis license Available in any view
information
display isis lsdb [ [ l1 | l2 | level-1 |
level-2 ] | [ [ lsp-id lsp-id | lsp-name
Display LSDB information lspname | local ] | verbose ] * ] * Available in any view
[ process-id | vpn-instance
vpn-instance-name ]
Display IS-IS mesh group display isis mesh-group [ process-id |
Display the mapping table
display isis name-table [ process-id |
between the host name and Available in any view
system ID
display isis peer [ verbose ]
Display IS-IS neighbor
information
vpn-instance-name]
Display IPv6 IS-IS routing display isis route ipv6 [ [ level-1 |
information level-2 ] | verbose ] * [ process-id ]
display isis spf-log [ process-id |
Display SPF log information Available in any view
display isis statistics [ level-1 | level-2 |
Display the statistics of the
level-1-2 ] [ process-id | vpn-instance Available in any view
IS-IS process
vpn-instance-name ]
Clear all IS-IS data structure reset isis all [ process-id | vpn-instance
information vpn-instance-name ]
Clear the IS-IS data information reset isis peer system-id [ process-id |
of a neighbor vpn vpn-instance-name ]
IPv6 IS-IS Configuration Example (on Routers)

As shown in Figure 1-1, Router A, Router B, Router C and Router D, all enabled with IPv6, reside in the
same autonomous system. Configure IPv6 IS-IS on the routers to make them reachable to each other.
Router A and Router B are Level-1 routers, Router D is a Level-2 router, and Router C is a Level-1-2
router. Router A, Router B, and Router C belong to area 10, while Router D is in area 20.
1-4
Network diagram
Figure 1-1 Network diagram for IPv6 IS-IS basic configuration

2) Configure IPv6 IS-IS
[RouterA] isis 1
[RouterA-isis-1] ipv6 enable
[RouterA-Serial2/0] isis ipv6 enable 1
[RouterB] isis 1
[RouterB-isis-1] ipv6 enable
[RouterB-Serial2/0] isis ipv6 enable 1
[RouterC] isis 1
[RouterC-isis-1] ipv6 enable
1-5
[RouterC-Serial2/0] isis ipv6 enable 1
[RouterD] isis 1
[RouterD-isis-1] ipv6 enable
[RouterD-Serial2/0] isis ipv6 enable 1
[RouterD-Ethernet1/0] isis ipv6 enable 1
IPv6 IS-IS Configuration Example (on Switches)

As shown in Figure 1-2, Switch A, Switch B, Switch C and Switch D reside in the same autonomous
system, and all are enabled with IPv6.
Switch A and Switch B are Level-1 switches, Switch D is a Level-2 switch, and Switch C is a Level-1-2
switch. Switch A, Switch B, and Switch C are in area 10, while Switch D is in area 20.
Network diagram
Figure 1-2 Network diagram for IPv6 IS-IS basic configuration
1-6

2) Configure IPv6 IS-IS
[SwitchA] isis 1
[SwitchA-isis-1] is-level level-1
[SwitchA-isis-1] ipv6 enable
[SwitchA-Vlan-interface100] isis ipv6 enable 1
[SwitchB] isis 1
[SwitchB-isis-1] ipv6 enable
[SwitchB-Vlan-interface200] isis ipv6 enable 1
[SwitchC] isis 1
[SwitchC-isis-1] ipv6 enable
[SwitchC-Vlan-interface100] isis ipv6 enable 1
[SwitchD] isis 1
[SwitchD-isis-1] ipv6 enable
1-7
[SwitchD-Vlan-interface300] isis ipv6 enable 1
[SwitchD-Vlan-interface301] isis ipv6 enable 1
1-8
Table of Contents
1 IPv6 OSPFv3 Configuration1-1

Introduction to OSPFv31-1
OSPFv3 Overview 1-1
OSPFv3 Packets 1-1
OSPFv3 LSA Types 1-2
Timers of OSPFv3 1-2
OSPFv3 Features Supported 1-3
Related RFCs 1-3
IPv6 OSPFv3 Configuration Task List 1-4
Enabling OSPFv31-4
Prerequisites1-4
Enabling OSPFv3 1-4
Configuring OSPFv3 Area Parameters1-5
Prerequisites1-5
Configuring an OSPFv3 Stub Area 1-5
Configuring an OSPFv3 Virtual Link1-6
Configuring OSPFv3 Routing Information Control1-6
Prerequisites1-6
Configuring OSPFv3 Route Summarization1-6
Configuring OSPFv3 Inbound Route Filtering 1-7
Configuring an OSPFv3 Cost for an Interface1-7
Configuring the Maximum Number of OSPFv3 Load-balanced Routes 1-8
Configuring a Priority for OSPFv3 1-8
Configuring OSPFv3 Route Redistribution1-9
Tuning and Optimizing OSPFv3 Networks 1-9
Prerequisites1-10
Configuring OSPFv3 Timers 1-10
Configuring a DR Priority for an Interface 1-10
Ignoring MTU Check for DD Packets 1-11
Disable Interfaces from Sending OSPFv3 Packets1-11
Enable the Logging of Neighbor State Changes1-12
Displaying and Maintaining OSPFv3 1-12
OSPFv3 Configuration Examples (on Routers) 1-13
Configuring OSPFv3 Areas 1-13
Configuring OSPFv3 DR Election 1-16
OSPFv3 Configuration Examples (on Switches) 1-19
Configuring OSPFv3 Areas 1-19
Configuring OSPFv3 DR Election 1-23
Troubleshooting OSPFv3 Configuration 1-26
No OSPFv3 Neighbor Relationship Established 1-26
Incorrect Routing Information 1-27
i
1 IPv6 OSPFv3 Configuration
When configuring OSPF, go to these sections for information you are interested in:
z Introduction to OSPFv3
z IPv6 OSPFv3 Configuration Task List
z Enabling OSPFv3
z Configuring OSPFv3 Area Parameters
z Configuring OSPFv3 Routing Information Control
z Tuning and Optimizing OSPFv3 Networks
z Displaying and Maintaining OSPFv3
z OSPFv3 Configuration Examples (on Routers)
z OSPFv3 Configuration Examples (on Switches)
z Troubleshooting OSPFv3 Configuration
Introduction to OSPFv3
OSPFv3 Overview
OSPFv3 is OSPF (Open Shortest Path First) version 3, supporting IPv6 and compliant with RFC2740
(OSPF for IPv6).
The same between OSPFv3 and OSPFv2:
z 32 bits router ID and area ID
z Packets: Hello, DD (Data Description), LSR (Link State Request), LSU (Link State Update), LSAck
(Link State Acknowledgment)
z Mechanism for finding neighbors and establishing adjacencies
z Mechanism for LSA flooding and aging
Differences between OSPFv3 and OSPFv2:
z OSPFv3 runs on a per-link basis, instead of on a per-IP-subnet basis.
z OSPFv3 supports multiple instances per link.
z OSPFv3 identifies neighbors by Router ID, while OSPFv2 by IP address.
OSPFv3 Packets
OSPFv3 has also five types of packets: hello, DD, LSR, LSU, and LSAck.
1-1
The five packets have the same packet header, which different from the OSPFv2 packet header is only
16 bytes in length, has no authentication field, but is added with an Instance ID field to support
multi-instance per link.
Figure 1-1 gives the OSPFv3 packet header.
Figure 1-1 OSPFv3 packet header
Major fields:
z Version #: Version of OSPF, which is 3 for OSPFv3.
z Type: Type of OSPF packet; Types 1 to 5 are hello, DD, LSR, LSU, and LSAck respectively.
z Packet Length: Packet length in bytes, including header.
z Instance ID: Instance ID for a link.
z 0: Reserved. It must be 0.
OSPFv3 LSA Types
OSPFv3 sends routing information in LSAs, which as defined in RFC2740 have the following types:
z Router-LSA: Originated by all routers. This LSA describes the collected states of the router's
interfaces to an area. Flooded throughout a single area only.
z Network-LSA: Originated for broadcast and NBMA networks by the Designated Router. This LSA
contains the list of routers connected to the network. Flooded throughout a single area only.
z Inter-Area-Prefix-LSA: Similar to Type 3 LSA of OSPFv2, originated by ABRs (Area Border
Routers), and flooded throughout the LSA's associated area. Each Inter-Area-Prefix-LSA
describes a route with IPv6 address prefix to a destination outside the area, yet still inside the AS
(an inter-area route).
z Inter-Area-Router-LSA: Similar to Type 4 LSA of OSPFv2, originated by ABRs and flooded
throughout the LSA's associated area. Each Inter-Area-Router-LSA describes a route to ASBR
(Autonomous System Boundary Router).
z AS-external-LSA: Originated by ASBRs, and flooded throughout the AS (except Stub and NSSA
areas). Each AS-external-LSA describes a route to another Autonomous System. A default route
can be described by an AS external LSA.
z Link-LSA: A router originates a separate Link-LSA for each attached link. Link-LSAs have link-local
flooding scope. Each Link-LSA describes the IPv6 address prefix of the link and Link-local address
of the router.
z Intra-Area-Prefix-LSA: Each Intra-Area-Prefix-LSA contains IPv6 prefix information on a router,
stub area or transit area information, and has area flooding scope. It was introduced because
Router-LSAs and Network-LSAs contain no address information now.
Timers of OSPFv3
Timers in OSPFv3 include:

z OSPFv3 packet timer
1-2
z LSA delay timer
z SPF timer
OSPFv3 packet timer
Hello packets are sent periodically between neighboring routers for finding and maintaining neighbor
relationships, or for DR/BDR election. The hello interval must be identical on neighboring interfaces.
The smaller the hello interval, the faster the network convergence speed and the bigger the network
load.
If a router receives no hello packet from a neighbor within a period, it will declare the peer is down. The
period is called the dead interval.
After sending an LSA to its adjacency, a router waits for an acknowledgment from the adjacency. If no
response is received after the retransmission interval elapses, the router will send again the LSA. The
retransmission interval must be longer than the round-trip time of the LSA.
LSA delay time
Each LSA has an age in the local LSDB (incremented by 1 per second), but an LSA does not age on
transmission. You need to add an LSA delay time into the age time before transmission, which is
important for low-speed networks.
SPF timer
Whenever the LSDB changes, an SPF calculation happens. If recalculations become so frequent, a
large amount of resources will be occupied. You can adjust the SPF calculation interval and delay time
to protect networks from being overloaded due to frequent changes.
OSPFv3 Features Supported
z Basic features defined in RFC2740

z OSPFv3 stub area
z OSPFv3 multi-process, which enable a router to run multiple OSPFv3 processes
Related RFCs
z RFC2740: OSPF for IPv6

z RFC2328: OSPF Version 2
1-3
IPv6 OSPFv3 Configuration Task List
Complete the following tasks to configure OSPFv3:
Task Remarks
Enabling OSPFv3 Required
Configuring OSPFv3 Area Configuring an OSPFv3 Stub Area Optional

Parameters Configuring an OSPFv3 Virtual Link Optional
Configuring OSPFv3 Route Summarization Optional

Configuring OSPFv3 Inbound Route Filtering Optional
Configuring an OSPFv3 Cost for an Interface Optional
Configuring OSPFv3 Routing
Information Control Configuring the Maximum Number of OSPFv3
Optional
Load-balanced Routes
Configuring a Priority for OSPFv3 Optional
Configuring OSPFv3 Route Redistribution Optional
Configuring OSPFv3 Timers Optional
Configuring a DR Priority for an Interface Optional

Tuning and Optimizing
Ignoring MTU Check for DD Packets Optional
OSPFv3 Networks
Disable Interfaces from Sending OSPFv3 Packets Optional
Enable the Logging of Neighbor State Changes Optional
Enabling OSPFv3
Prerequisites
z Make neighboring nodes accessible with each other at the network layer.
z Enable IPv6 packet forwarding
Enabling OSPFv3
To enable an OSPFv3 process on a router, you need to enable the OSPFv3 process globally, assign the
OSPFv3 process a router ID, and enable the OSPFv3 process on related interfaces.
A router ID uniquely identifies a router within an AS. Therefore, you need to specify a unique router ID
for each OSPFv3 router within the AS to ensure normal operation. Note that if a router runs multiple
OSPFv3 processes, you need to specify a unique router ID for each process.
An OSPFv3 process ID has only local significance. Therefore, process 1 on a router can exchange
packets with process 2 on another router.
Follow these steps to enable OSPFv3:
Required
Enable an OSPFv3 process
ospfv3 [ process-id ] By default, no OSPFv3 process
and enter its view
is enabled.
1-4
Specify a router ID router-id router-id Required
interface-number
Enable an OSPFv3 process on ospfv3 process-id area area-id Required

the interface [ instance instance-id ] Not enabled by default
Configuring OSPFv3 Area Parameters

The stub area and virtual link features of OSPFv3 are the same as OSPFv2.
Splitting an OSPFv3 AS into multiple areas reduces the number of LSAs and extends OSPFv3
applications. For those non-backbone areas residing on the AS boundary, you can configure them as
stub areas to further reduce the size of routing tables and the number of LSAs.
Non-backbone areas exchange routing information via the backbone area. Therefore, the backbone
and non-backbone areas, including the backbone itself must be contiguous. In practice, necessary
physical links may not be available for such connectivity. You can configure virtual links to address the
problem.
Prerequisites

z Configure OSPFv3 basic functions
Configuring an OSPFv3 Stub Area
Follow these steps to configure an OSPFv3 stub area:
Enter OSPFv3 view ospfv3 [ process-id ]
Enter OSPFv3 area view area area-id
Required
Configure the area as a stub area stub [ no-summary ]
Not configured by default
Specify a cost for the default route Optional

default-cost value
advertised to the stub area Defaults to 1
1-5
z You cannot remove an OSPFv3 area directly. Only when you remove all configurations in area
view and all interfaces attached to the area become down, can the area be removed.
z All the routers attached to a stub area must be configured with the stub command. The keyword
no-summary is only available on the ABR of the stub area.
z If you use the stub command with the keyword no-summary on an ABR, the ABR advertises a
default route in an Inter-Area-Prefix-LSA into the stub area. No AS-external-LSA,
Inter-Area-Prefix-LSA or Inter-Area-Router-LSA is advertised in the area. The stub area of this kind
is also known as a totally stub area.
Configuring an OSPFv3 Virtual Link
You can configure a virtual link to maintain connectivity between a non-backbone area and the
backbone, or in the backbone itself.
Follow these steps to configure a virtual link:
vlink-peer router-id [ hello seconds |

Configure a virtual link retransmit seconds | trans-delay seconds | Required
dead seconds | instance instance-id ] *
Both ends of a virtual link are ABRs that must be configured with the vlink-peer command.
Configuring OSPFv3 Routing Information Control

This section is to configure the control of OSPF routing information advertisement and reception, and
redistribution from other protocols.
Prerequisites

Configuring OSPFv3 Route Summarization
If contiguous network segments exist in an area, you can use the abr-summary command to
summarize them into one network segment on the ABR. The ABR will advertise only the summary route.
1-6
Any LSA falling into the specified network segment will not be advertised, reducing the LSDB size in
other areas.
Follow these steps to configure route summarization:
abr-summary ipv6-address Required

Configure a summary route
prefix-length [ not-advertise ] Not configured by default
The abr-summary command takes effect on ABRs only.
Configuring OSPFv3 Inbound Route Filtering
You can configure OSPFv3 to filter routes that are computed from received LSAs according to some
rules.
Follow these steps to configure OSPFv3 inbound route filtering:
Configure inbound filter-policy { acl-number | ipv6-prefix Required

route filtering ipv6-prefix-name } import Not configured by default
Use of the filter-policy import command can only filter routes computed by OSPFv3. Only routes not
filtered out can be added into the local routing table.
Configuring an OSPFv3 Cost for an Interface
You can configure an OSPFv3 cost for an interface to influence routing calculation.
1-7
Follow these steps to configure an OSPFv3 cost for an interface:
Enter system view System-view
interface-number
Optional
By default, OSPFv3 computes an interfaces
Configure an OSPFv3 ospfv3 cost value
cost according to its bandwidth.
cost for the interface [ instance instance-id ]
The cost value defaults to 1 for VLAN
interfaces of switches.
Configuring the Maximum Number of OSPFv3 Load-balanced Routes
If multiple equal-cost routes to a destination are available, enabling load balancing among these routes
can improve link utilization.
Follow these steps to configure the maximum number of load-balanced routes:
Specify the maximum number maximum load-balancing Optional

of load-balanced routes maximum The default varies by device.
Configuring a Priority for OSPFv3
A router may run multiple routing protocols. The system assigns a priority for each protocol. When these
routing protocols find the same route, the route found by the protocol with the highest priority is
selected.
Follow these steps to configure a priority for OSPFv3:
Optional
Configure a priority for preference [ ase ] [ route-policy By default, the priority of OSPFv3
OSPFv3 route-policy-name ] preference internal routes is 10, and priority of
OSPFv3 external routes is 150.
1-8
Configuring OSPFv3 Route Redistribution
Follow these steps to configure OSPFv3 route redistribution:
Specify a default cost for Optional

default cost value
redistributed routes Defaults to 1
import-route { isisv6 process-id | ospfv3 Required
Redistribute routes from
process-id | ripng process-id | bgp4+
another protocol, or another Not configured by
[ allow-ibgp ] | direct | static } [ cost value |
OSPFv3 process default
type type | route-policy route-policy-name ] *
Optional
default-route-advertise [ always | cost cost |
Inject a default route Not injected by
type type | route-policy route-policy-name ] *
default
filter-policy { acl6-number | ipv6-prefix Optional
ipv6-prefix-name } export [ isisv6 process-id |
Filter redistributed routes Not configured by
ospfv3 process-id | ripng process-id | bgp4+ |
direct | static ] default
z Executing the import-route or default-route-advertise command on a router makes it become an

ASBR,.
z You can only inject and advertise a default route using the default-route-advertise command.
z Since OSPFv3 is a link state routing protocol, it cannot directly filter LSAs to be advertised.
Therefore, you need to filter redistributed routes first, and thus only routes that are not filtered out
can be advertised in LSAs into the routing domain.
z Use of the filter-policy export command filters routes redistributed with the import-route
command. If the import-route command is not configured, executing the filter-policy export
command does not take effect.
Tuning and Optimizing OSPFv3 Networks

This section describes configurations of OSPFv3 timers, interface DR priority, MTU check ignorance for
DD packets, and disabling interfaces from sending OSPFv3 packets.
OSPFv3 timers:
z Packet timer: Specified to adjust topology convergence speed and network load
z LSA delay timer: Specified especially for low-speed links
z SPF timer: Specified to protect networks from being over-loaded due to frequent network changes.
For a broadcast network, you can configure DR priorities for interfaces to affect DR/BDR election.
By disabling an interface from sending OSPFv3 packets, you can make other routers on the network
obtain no information from the interface.
1-9
Prerequisites

Configuring OSPFv3 Timers
Follow these steps to configure OSPFv3 timers:
interface-number
Optional
Configure the hello ospfv3 timer hello seconds
interval [ instance instance-id ] Defaults to 10 seconds on P2P,
broadcast interfaces.
Optional
Configure the dead ospfv3 timer dead seconds
interval [ instance instance-id ] Defaults to 40 seconds on P2P,
broadcast interfaces.
Configure the LSA ospfv3 timer retransmit Optional

retransmission interval interval [ instance instance-id ] Defaults to 5 seconds.
Configure the LSA ospfv3 trans-delay seconds Optional

transmission delay [ instance instance-id ] Defaults to 1 second.
Optional
Configure the SPF spf timers delay-interval
timers hold-interval By default, delay-interval is 5 seconds,
and hold-interval is 10 seconds.
z The dead interval set on neighboring interfaces cannot be too short. Otherwise, a neighbor is easily
considered down.
z The LSA retransmission interval cannot be too short; otherwise, unnecessary retransmissions
occur.
Configuring a DR Priority for an Interface
Follow these steps to configure a DR priority for an interface:
interface-number
1-10
ospfv3 dr-priority priority Optional

Configure a DR priority
[ instance instance-id ] Defaults to 1
The DR priority of an interface determines the interfaces qualification in DR election. Interfaces having
the priority 0 cannot become a DR or BDR.
Ignoring MTU Check for DD Packets
When LSAs are few in DD packets, it is unnecessary to check the MTU in DD packets in order to
improve efficiency.
Follow these steps to ignore MTU check for DD packets:
interface-number
Ignore MTU check for DD ospfv3 mtu-ignore [ instance Required

packets instance-id ] Not ignored by default
Disable Interfaces from Sending OSPFv3 Packets
Follow these steps to disable interfaces from sending OSPFv3 packets:
Disable interfaces from sending silent-interface { interface-type Required

OSPFv3 packets interface-number | all } Not disabled by default
z Multiple OSPFv3 processes can disable the same interface from sending OSPFv3 packets. Using
the silent-interface command disables only the interfaces associated with the current process.
z After an OSPF interface is set to silent, direct routes of the interface can still be advertised in
Intra-Area-Prefix-LSAs via other interfaces, but other OSPFv3 packets cannot be advertised.
Therefore, no neighboring relationship can be established on the interface. This feature can
enhance the adaptability of OSPFv3 networking.
1-11
Enable the Logging of Neighbor State Changes
Enable the logging of neighbor Required

log-peer-change
Displaying and Maintaining OSPFv3

Display OSPFv3 debugging state
display debugging ospfv3
information
Display OSPFv3 process brief
display ospfv3 [ process-id ]
information
display ospfv3 interface [ interface-type
Display OSPFv3 interface information
interface-number | statistic ]
display ospfv3 [ process-id ] lsdb [ [ external
| inter-prefix | inter-router | intra-prefix | link
Display OSPFv3 LSDB information
| network | router ] [ link-state-id ]
[ originate-router router-id ] | total ]
Display OSPFv3 LSDB statistics display ospfv3 lsdb statistic
display ospfv3 [ process-id ] [ area area-id ]
Display OSPFv3 neighbor information peer [ [ interface-type interface-number ]
[ verbose ] | peer-router-id ]
Display OSPFv3 neighbor statistics display ospfv3 peer statistic
display ospfv3 [ process-id ] routing Available
Display OSPFv3 routing table [ ipv6-address prefix-length | in any
information ipv6-address/prefix-length | abr-routes | view
asbr-routes | all | statistics ]
Display OSPFv3 area topology display ospfv3 [ process-id ] topology [ area
information area-id ]
Display OSPFv3 virtual link
display ospfv3 [ process-id ] vlink
information
Display OSPFv3 next hop information display ospfv3 [ process-id ] next-hop
display ospfv3 [ process-id ] request-list

Display OSPFv3 link state request list [ { external | inter-prefix | inter-router | intra-prefix
information | link | network | router } [ link-state-id ]
[ originate-router ip-address ] | statistics ]
display ospfv3 [ process-id ] retrans-list
Display OSPFv3 link state [ { external | inter-prefix | inter-router | intra-prefix
retransmission list information | link | network | router } [ link-state-id ]
[ originate-router ip-address ] | statistics ]
Display OSPFv3 statistics display ospfv3 statistic
1-12
OSPFv3 Configuration Examples (on Routers)
Configuring OSPFv3 Areas
In Figure 1-2, all routers run OSPFv3. The AS is split into three areas, in which, Router B and Router C
act as ABRs to forward routing information between areas.
It is required to configure Area 2 as a stub area to reduce LSAs in the area without affecting route
reachability.
Network diagram
Figure 1-2 OSPFv3 area configuration

2) Configure OSPFv3 basic functions
# Configure Router A
[RouterA] ipv6
[RouterA] ospfv3 1
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit
[RouterA-Ethernet1/0] ospfv3 1 area 1
[RouterA-Serial2/1] ospfv3 1 area 1
[RouterB] ipv6
[RouterB] ospfv3 1
[RouterB-ospf-1] router-id 2.2.2.2
1-13
[RouterB-Serial2/0] ospfv3 1 area 0
[RouterB-Serial2/1] ospfv3 1 area 1
# Configure Router C
[RouterC] ipv6
[RouterC] ospfv3 1
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit
[RouterC-Serial2/0] ospfv3 1 area 0
[RouterC-Serial2/1] ospfv3 1 area 2
[RouterD] ipv6
[RouterD] ospfv3 1
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD-Serial2/1] ospfv3 1 area 2
# Display OSPFv3 neighbor information on Router B.

[RouterB] display ospfv3 peer
OSPFv3 Area ID 0.0.0.0 (Process 1)

----------------------------------------------------------------------
Neighbor ID Pri State Dead Time Interface Instance ID
3.3.3.3 1 Full/Backup 00:00:34 S2/0 0

----------------------------------------------------------------------
1.1.1.1 1 Full/DR 00:00:35 S2/1 0
# Display OSPFv3 neighbor information on Router C.

[RouterC] display ospfv3 peer

----------------------------------------------------------------------
1-14
2.2.2.2 1 Full/DR 00:00:35 S2/0 0

----------------------------------------------------------------------
4.4.4.4 1 Full/Backup 00:00:36 S2/1 0
# Display OSPFv3 routing information on Router D.

[RouterD] display ospfv3 routing
E1 - Type 1 external route, IA - Inter area route, I - Intra area route

E2 - Type 2 external route, * - Selected route
OSPFv3 Router with ID (4.4.4.4) (Process 1)

------------------------------------------------------------------------
*Destination: 2001::/64
Type : IA Cost : 2
NextHop : FE80::F40D:0:93D0:1 Interface: S2/1
*Destination: 2001:1::/64
Type : IA Cost : 3
Type : I Cost : 1
NextHop : directly-connected Interface: S2/1
Type : IA Cost : 4
3) Configure Area 2 as a stub area
[RouterD] ospfv3
[RouterD-ospfv3-1] area 2
[RouterD-ospfv3-1-area-0.0.0.2] stub
# Configure Router C, and specify the cost of the default route sent to the stub area as 10.
[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub
[RouterC-ospfv3-1-area-0.0.0.2] default-cost 10
# Display OSPFv3 routing information on Router D. You can find a default route is added and its cost is
the cost of a direct route plus the configured cost.

E2 - Type 2 external route, * - Seleted route
1-15
------------------------------------------------------------------------
*Destination: ::/0
Type : IA Cost : 11
Type : IA Cost : 2
Type : IA Cost : 3
Type : I Cost : 1
Type : IA Cost : 4
4) Configure Area 2 as a totally stub area to reduce the stub area routing table size.
# Configure Area 2 as a totally stub area on Router C.
[RouterC-ospfv3-1-area-0.0.0.2] stub no-summary
# Display OSPFv3 routing table information on Router D. You can find route entries are reduced. All
non-direct routes are removed except the default route.


------------------------------------------------------------------------
*Destination: ::/0
Type : IA Cost : 11
Type : I Cost : 1
Configuring OSPFv3 DR Election

z The priority of Router A is 100, the highest priority on the network, so it will be the DR.
z The priority of RouterC is 2, the second highest priority on the network, so it will be the BDR.
1-16
z The priority of RouterB is 0, so it cannot become a DR.
z RouterD has the default priority 1.
Network diagram
Figure 1-3 Network diagram for OSPFv3 DR election configuration

[RouterA] ipv6
[RouterA] ospfv3
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit
[RouterA-Ethernet1/0] ospfv3 1 area 0
[RouterB] ipv6
[RouterB] ospfv3
[RouterB-ospfv3-1] router-id 2.2.2.2
[RouterB-ospfv3-1] quit
[RouterB-Ethernet1/0] ospfv3 1 area 0
[RouterC] ipv6
[RouterC] ospfv3
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit
1-17
[RouterC-Ethernet1/0] ospfv3 1 area 0
[RouterD] ipv6
[RouterD] ospfv3
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD-Ethernet1/0] ospfv3 1 area 0
# Display neighbor information on Router A. You can find routers have the same default DR priority 1. In
this case, the router with the highest Router ID is elected as the DR, so Router D is the DR, Router C is
the BDR.
[RouterA] display ospfv3 peer
----------------------------------------------------------------------
2.2.2.2 1 2-Way/DROther 00:00:36 Eth1/0 0
3.3.3.3 1 Full/Backup 00:00:35 Eth1/0 0
4.4.4.4 1 Full/DR 00:00:33 Eth1/0 0
# Display neighbor information on Router D. You can find the neighbor states of Router D are all full.
[RouterD] display ospfv3 peer
----------------------------------------------------------------------
1.1.1.1 1 Full/DROther 00:00:30 Eth1/0 0
2.2.2.2 1 Full/DROther 00:00:37 Eth1/0 0
3.3.3.3 1 Full/Backup 00:00:31 Eth1/0 0
3) Configure DR priorities for interfaces.
# Configure the DR priority of Ethernet 1/0 of Router A as 100.
[RouterA-Ethernet1/0] ospfv3 dr-priority 100
# Configure the DR priority of Ethernet 1/0 as 0 on Router B.

[RouterB-Ethernet1/0] ospfv3 dr-priority 0
# Configure the DR priority of Ethernet 1/0 as 2 on Router C.

[RouterC-Ethernet1/0] ospfv3 dr-priority 2
# Display neighbor information on Router A. You can find DR priorities have been updated, but the DR
and BDR are not changed.
1-18
----------------------------------------------------------------------
2.2.2.2 0 2-Way/DROther 00:00:38 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:32 Eth1/0 0
4.4.4.4 1 Full/DR 00:00:36 Eth1/0 0
# Display neighbor information on Router D. You can find Router D is still the DR.
----------------------------------------------------------------------
1.1.1.1 100 Full/DROther 00:00:33 Eth1/0 0
2.2.2.2 0 Full/DROther 00:00:36 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:40 Eth1/0 0
4) Restart DR/BDR election
# Use the shutdown and undo shutdown commands on interfaces to restart DR/BDR election
(omitted).
# Display neighbor information on Router A. You can find Router C becomes the BDR.
----------------------------------------------------------------------
2.2.2.2 0 Full/DROther 00:00:31 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:39 Eth1/0 0
4.4.4.4 1 Full/DROther 00:00:37 Eth1/0 0
# Display neighbor information on Router D. You can find Router A becomes the DR.
----------------------------------------------------------------------
1.1.1.1 100 Full/DR 00:00:34 Eth1/0 0
2.2.2.2 0 2-Way/DROther 00:00:34 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:32 Eth1/0 0
OSPFv3 Configuration Examples (on Switches)

Configuring OSPFv3 Areas
In the following figure, all switches run OSPFv3. The AS is split into three areas, in which, Switch B and
Switch C act as ABRs to forward routing information between areas.
It is required to configure Area 2 as a stub area to reduce LSAs in the area without affecting route
reachability.
1-19
Network diagram
Figure 1-4 Network diagram for OSPFv3 area configuration

[SwitchA] ipv6
[SwitchA] ospfv3
[SwitchA-ospfv3-1] router-id 1.1.1.1
[SwitchA-ospfv3-1] quit
[SwitchA-Vlan-interface300] ospfv3 1 area 1
[SwitchB] ipv6
[SwitchB] ospfv3
[SwitchB-ospf-1] router-id 2.2.2.2
[SwitchB-Vlan-interface100] ospfv3 1 area 0
[SwitchC] ipv6
[SwitchC] ospfv3
1-20
[SwitchC-ospfv3-1] router-id 3.3.3.3
[SwitchC-ospfv3-1] quit
[SwitchC-Vlan-interface100] ospfv3 1 area 0
[SwitchD] ipv6
[SwitchD] ospfv3
[SwitchD-ospfv3-1] router-id 4.4.4.4
[SwitchD-ospfv3-1] quit
[SwitchD] interface Vlan-interface 400
[SwitchD-Vlan-interface400] ospfv3 1 area 2
# Display OSPFv3 neighbor information on Switch B.

[SwitchB] display ospfv3 peer

----------------------------------------------------------------------
3.3.3.3 1 Full/DR 00:00:39 Vlan100 0

----------------------------------------------------------------------
1.1.1.1 1 Full/Backup 00:00:38 Vlan200 0
# Display OSPFv3 neighbor information on Switch C.

[SwitchC] display ospfv3 peer
----------------------------------------------------------------------
2.2.2.2 1 Full/Backup 00:00:39 Vlan100 0

----------------------------------------------------------------------
4.4.4.4 1 Full/DR 00:00:38 Vlan400 0
# Display OSPFv3 routing table information on Switch D.

[SwitchD] display ospfv3 routing

1-21
------------------------------------------------------------------------
Type : IA Cost : 2
NextHop : FE80::F40D:0:93D0:1 Interface: Vlan400
Type : IA Cost : 3
Type : I Cost : 1
NextHop : directly-connected Interface: Vlan400
Type : IA Cost : 4
3) Configure Area 2 as a stub area
# Configure Switch D
[SwitchD] ospfv3
[SwitchD-ospfv3-1] area 2
[SwitchD-ospfv3-1-area-0.0.0.2] stub
# Configure Switch C, and specify the cost of the default route sent to the stub area as 10.
[SwitchC] ospfv3
[SwitchC-ospfv3-1] area 2
[SwitchC-ospfv3-1-area-0.0.0.2] stub
[SwitchC-ospfv3-1-area-0.0.0.2] default-cost 10
# Display OSPFv3 routing table information on Switch D. You can find a default route is added, and its
cost is the cost of a direct route plus the configured cost.

------------------------------------------------------------------------
*Destination: ::/0
Type : IA Cost : 11
Type : IA Cost : 2
Type : IA Cost : 3
1-22
Type : I Cost : 1
Type : IA Cost : 4
4) Configure Area 2 as a totally stub area
# Configure Area 2 as a totally stub area on Switch C.
[SwitchC-ospfv3-1-area-0.0.0.2] stub no-summary
# Display OSPFv3 routing table information on Switch D. You can find route entries are reduced. All
non-direct routes are removed except the default route.

------------------------------------------------------------------------
*Destination: ::/0
Type : IA Cost : 11
Type : I Cost : 1
Configuring OSPFv3 DR Election

z The priority of Switch A is 100, the highest priority on the network, so it will be the DR.
z The priority of Switch C is 2, the second highest priority on the network, so it will be the BDR.
z The priority of Switch B is 0, so it cannot become the DR.
z Router D has the default priority 1.
1-23
Network diagram
Figure 1-5 Network diagram for OSPFv3 DR election configuration

[SwitchA] ipv6
[SwitchA] ospfv3
[SwitchA-ospfv3-1] router-id 1.1.1.1
[SwitchA-ospfv3-1] quit
[SwitchB] ipv6
[SwitchB] ospfv3
[SwitchB-ospfv3-1] router-id 2.2.2.2
[SwitchB-ospfv3-1] quit
[SwitchC] ipv6
[SwitchC] ospfv3
[SwitchC-ospfv3-1] router-id 3.3.3.3
[SwitchC-ospfv3-1] quit
1-24
[SwitchD] ipv6
[SwitchD] ospfv3
[SwitchD-ospfv3-1] router-id 4.4.4.4
[SwitchD-ospfv3-1] quit
[SwitchD-Vlan-interface200] ospfv3 1 area 0
# Display neighbor information on Switch A. You can find the switches have the same default DR priority
1. In this case, the switch with the highest Router ID is elected as the DR. Therefore, Switch D is the DR,
and Switch C is the BDR.
[SwitchA] display ospfv3 peer
----------------------------------------------------------------------
2.2.2.2 1 2-Way/DROther 00:00:36 Vlan200 0
3.3.3.3 1 Full/Backup 00:00:35 Vlan100 0
4.4.4.4 1 Full/DR 00:00:33 Vlan200 0
# Display neighbor information on Switch D. You can find the neighbor states are all full.
[SwitchD] display ospfv3 peer
----------------------------------------------------------------------
1.1.1.1 1 Full/DROther 00:00:30 Vlan100 0
3.3.3.3 1 Full/Backup 00:00:31 Vlan100 0
3) Configure DR priorities for interfaces.
# Configure the DR priority of VLAN-interface 100 as 100 on Switch A.
[SwitchA] interface Vlan-interface 100
[SwitchA-Vlan-interface100] ospfv3 dr-priority 100
# Configure the DR priority of VLAN-interface 200 as 0 on Switch B.

[SwitchB-Vlan-interface200] ospfv3 dr-priority 0
# Configure the DR priority of VLAN-interface 100 of Switch C as 2.

[SwitchC] interface Vlan-interface 100
[SwitchC-Vlan-interface100] ospfv3 dr-priority 2
# Display neighbor information on Switch A. You can find DR priorities have been updated, but the DR
and BDR are not changed.
----------------------------------------------------------------------
1-25
2.2.2.2 0 2-Way/DROther 00:00:38 Vlan200 0
3.3.3.3 2 Full/Backup 00:00:32 Vlan100 0
4.4.4.4 1 Full/DR 00:00:36 Vlan200 0
# Display neighbor information on Switch D. You can find Switch D is still the DR.
----------------------------------------------------------------------
3.3.3.3 2 Full/Backup 00:00:40 Vlan100 0
4) Restart DR/BDR election
# Use the shutdown and undo shutdown commands on interfaces to restart DR/BDR election
(omitted).
# Display neighbor information on Switch A. You can find Switch C becomes the BDR.
----------------------------------------------------------------------
3.3.3.3 2 Full/Backup 00:00:39 Vlan100 0
# Display neighbor information on Switch D. You can find Switch A becomes the DR.
----------------------------------------------------------------------
1.1.1.1 100 Full/DR 00:00:34 Vlan100 0
2.2.2.2 0 2-Way/DROther 00:00:34 Vlan200 0
3.3.3.3 2 Full/Backup 00:00:32 Vlan100 0
Troubleshooting OSPFv3 Configuration

No OSPFv3 Neighbor Relationship Established
Symptom
No OSPF neighbor relationship can be established.
Analysis
If the physical link and lower protocol work well, check OSPF parameters configured on interfaces. The
two neighboring interfaces must have the same parameters, such as the area ID, network segment and
mask and network type. If the network type is broadcast, at least one interface must have a DR priority
higher than 0.
1-26
Process steps
1) Display neighbor information using the display ospfv3 peer command.

2) Display OSPFv3 interface information using the display ospfv3 interface command.
3) Ping the neighbor routers 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 a broadcast network, at least one interface must have a DR priority higher than 0.
Incorrect Routing Information
Symptom
OSPFv3 cannot find routes to other areas.
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 be associated with the Stub area.
Solution
1) Use the display ospfv3 peer command to display OSPFv3 neighbors.

2) Use the display ospfv3 interface command to display OSPFv3 interface information.
3) Use the display ospfv3 lsdb command to display Link State Database information to check
integrity.
4) Display information about area configuration using the display current-configuration
configuration command. If more than two areas are configured, at least one area is connected to
the backbone.
5) In a Stub area, all routers are configured with the stub command.
6) If a virtual link is configured, use the display ospf vlink command to check the neighbor state.
1-27
Table of Contents
1 IPv6 RIPng Configuration 1-1

Introduction to RIPng 1-1
RIPng Working Mechanism 1-1
RIPng Packet Format 1-2
RIPng Packet Processing Procedure 1-3
Configuring RIPng Basic Functions 1-4
Configuring RIPng Route Control 1-4
Configuring an Additional Routing Metric 1-5
Configuring RIPng Route Summarization 1-5
Configuring a RIPng Route Filtering Policy 1-6
Configuring a Priority for RIPng1-6
Configuring RIPng Route Redistribution 1-6
Tuning and Optimizing the RIPng Network1-7
Configuring RIPng Timers 1-7
Configuring Split Horizon and Poison Reverse 1-8
Configuring Zero Field Check on RIPng Packets1-9
Configuring the Maximum Number of Equal Cost Routes for Load Balancing 1-9
Displaying and Maintaining RIPng 1-9
RIPng Configuration Example (on Routers)1-9
RIPng Configuration Example (on Switches)1-12
i
1 IPv6 RIPng Configuration
When configuring RIPng, go to these sections for information you are interested in:
z Introduction to RIPng
z Configuring RIPng Basic Functions
z Configuring RIPng Route Control
z Tuning and Optimizing the RIPng Network
z Displaying and Maintaining RIPng
z RIPng Configuration Example (on Routers)
z RIPng Configuration Example (on Switches)
Introduction to RIPng
RIP next generation (RIPng) is an extension of RIP-2 for IPv4. Most RIP concepts are applicable in
RIPng.
RIPng for IPv6 made the following changes to RIP:
z UDP port number: RIPng uses UDP port 521 for sending and receiving routing information.
z Multicast address: RIPng uses FF02:9 as the link-local multicast address.
z Destination Prefix: 128-bit destination address prefix.
z Next hop: 128-bit IPv6 address.
z Source address: RIPng uses FE80::/10 as the link-local source address
RIPng Working Mechanism
RIPng is a routing protocol based on the distance vector (D-V) algorithm. RIPng uses UDP packets to
exchange routing information through port 521.
RIPng uses a hop count to measure the distance to a destination. The hop count is referred to as metric
or cost. The hop count from a router to a directly connected network is 0. The hop count between two
1-1
directly connected routers is 1. When the hop count is greater than or equal to 16, the destination
network or host is unreachable.
By default, the routing update is sent every 30 seconds. If the router receives no routing updates from a
neighbor within 180 seconds, the routes learned from the neighbor are considered as unreachable.
Within another 240 seconds, if no routing update is received, the router will remove these routes from
the routing table.
RIPng supports split horizon and poison reverse to prevent routing loops and route redistribution.
Each RIPng router maintains a routing database, including route entries of all reachable destinations. A
route entry contains the following information:
z Destination address: IPv6 address of a host or a network.
z Next hop address: IPv6 address of a neighbor along the path to the destination.
z Egress interface: Outbound interface that forwards IPv6 packets.
z Metric: Cost from the local router to the destination.
z Route time: Time that elapsed since a route entry is last changed. Each time a route entry is
modified, the routing time is set to 0.
z Route tag: Identifies the route, used in a routing policy to control routing information. For
information about routing policy, refer to Routing Policy Configuration in the IP Routing Volume.
RIPng Packet Format
Basic format
A RIPng packet consists of a header and multiple route table entries (RTEs). The maximum number of
RTEs in a packet depends on the IPv6 MTU of the sending interface.
Figure 1-1 shows the packet format of RIPng.
Figure 1-1 RIPng basic packet format

z Command: Type of message. 0x01 indicates Request, 0x02 indicates Response.

z Version: Version of RIPng. It can only be 0x01 currently.
z RTE: Route table entry, 20 bytes for each entry.
RTE format
There are two types of RTEs in RIPng.

z Next hop RTE: Defines the IPv6 address of a next hop
z IPv6 prefix RTE: Describes the destination IPv6 address, route tag, prefix length and metric in the
RIPng routing table.
Figure 1-2 shows the format of the next hop RTE:
1-2
Figure 1-2 Next hop RTE format
IPv6 next hop address is the IPv6 address of the next hop.
Figure 1-3 shows the format of the IPv6 prefix RTE.
Figure 1-3 IPv6 prefix RTE format
0 7 15 31
IPv6 prefix (16 octets)
Route tag Prefix length Metric
z IPv6 prefix: Destination IPv6 address prefix.

z Route tag: Route tag.
z Prefix len: Length of the IPv6 address prefix.
z Metric: Cost of a route.
RIPng Packet Processing Procedure
Request packet
When a RIPng router first starts or needs to update some entries in its routing table, generally a
multicast request packet is sent to ask for needed routes from neighbors.
The receiving RIPng router processes RTEs in the request. If there is only one RTE with the IPv6 prefix
and prefix length both being 0, and with a metric value of 16, the RIPng router will respond with the
entire routing table information in response messages. If there are multiple RTEs in the request
message, the RIPng router will examine each RTE, update its metric, and send the requested routing
information to the requesting router in the response packet.
Response packet
The response packet containing the local routing table information is generated as:
z A response to a request
z An update periodically
z A trigged update caused by route change
After receiving a response, a router checks the validity of the response before adding the route to its
routing table, such as whether the source IPv6 address is the link-local address and whether the port
number is correct. The response packet that failed the check will be discarded.
z RFC2080: RIPng for IPv6

z RFC2081: RIPng Protocol Applicability Statement
1-3
Configuring RIPng Basic Functions
This section presents the information to configure the basic RIPng features.
You need to enable RIPng first before configuring other tasks, but it is not necessary for RIPng related
interface configurations, such as assigning an IPv6 address.

z Enable IPv6 packet forwarding.
z Configure an IP address for each interface, and make sure all nodes are reachable to one another.
Follow these steps to configure the basic RIPng functions:

Create a RIPng process and Required

ripng [ process-id ]
enter RIPng view Not created by default

interface-number
Required
Enable RIPng on the interface ripng process-id enable
Disabled by default
If RIPng is not enabled on an interface, the interface will not send or receive any RIPng route.
Configuring RIPng Route Control

z Configuring RIPng Route Summarization
z Advertising a Default Route
z Configuring a RIPng Route Filtering Policy
z Configuring a Priority for RIPng
z Configuring RIPng Route Redistribution
z Configure an IPv6 address on each interface, and make sure all nodes are reachable to one
another.
z Configure RIPng basic functions
z Define an IPv6 ACL before using it for route filtering. Refer to ACL Configuration in the Security
Volume for related information.
1-4
z Define an IPv6 address prefix list before using it for route filtering. Refer to Routing Policy
Configuration in the IP Routing Volume for related information.
Configuring an Additional Routing Metric
An additional routing metric can be added to the metric of an inbound or outbound RIP route, namely,
the inbound and outbound additional metric.
The outbound additional metric is added to the metric of a sent route. The routes metric in the routing
table is not changed.
The inbound additional metric is added to the metric of a received route before the route is added into
the routing table, so the routes metric is changed.
Follow these steps to configure an inbound/outbound additional routing metric:

interface-number
Specify an inbound routing Optional

ripng metricin value
additional metric 0 by default
Specify an outbound routing Optional

ripng metricout value
additional metric 1 by default
Configuring RIPng Route Summarization
Follow these steps to configure RIPng route summarization:

interface-number
Advertise a summary IPv6 ripng summary-address
Required
prefix ipv6-address prefix-length
Follow these steps to advertise a default route:

interface-number
ripng default-route { only | Required

Advertise a default route
originate } [ cost cost ] Not advertised by default
1-5
With this feature enabled, a default route is advertised through the specified interface regardless of
whether the default route is available in the local IPv6 routing table.
Configuring a RIPng Route Filtering Policy
You can reference a configured IPv6 ACL or prefix list to filter received/advertised routing information as
needed. For filtering outbound routes, you can also specify a routing protocol from which to filter routing
information redistributed.
Follow these steps to configure a RIPng route filtering policy:

Enter RIPng view ripng [ process-id ]

Configure a filter policy to filter
ipv6-prefix ipv6-prefix-name } By default, RIPng does not filter
incoming routes
import incoming routing information.

Configure a filter policy to filter
ipv6-prefix ipv6-prefix-name } By default, RIPng does not filter
outgoing routes
export [ protocol [ process-id ] ] outgoing routing information.
Configuring a Priority for RIPng
Any routing protocol has its own protocol priority used for optimal route selection. You can set a priority
for RIPng manually. The smaller the value is, the higher the priority is.
Follow these steps to configure a RIPng priority:


Optional
preference [ route-policy
Configure a RIPng priority By default, the RIPng priority is
route-policy-name ] preference
100.
Configuring RIPng Route Redistribution
Follow these steps to configure RIPng route redistribution:

1-6
Optional
Configure a default routing
default cost cost The default metric of
metric for redistributed routes
redistributed routes is 0.

Redistribute routes from [ process-id ] [ allow-ibgp ]
another routing protocol [ cost cost | route-policy No route redistribution is
route-policy-name ] * configured by default.
Tuning and Optimizing the RIPng Network

This section describes how to tune and optimize the performance of the RIPng network as well as
applications under special network environments. Before tuning and optimizing the RIPng network,
complete the following tasks:
z Configure a network layer address for each interface
z Configure the basic RIPng functions
z Configuring RIPng Timers
z Configuring Split Horizon and Poison Reverse
z Configuring Zero Field Check on RIPng Packets
z Configuring the Maximum Number of Equal Cost Routes for Load Balancing
Configuring RIPng Timers
You can adjust RIPng timers to optimize the performance of the RIPng network.
Follow these steps to configure RIPng timers:


Optional.
The RIPng timers have the following
timers { garbage-collect defaults:
garbage-collect-value |
Configure RIPng z 30 seconds for the update timer
suppress suppress-value |
timers z 180 seconds for the timeout timer
timeout timeout-value | update
update-value } * z 120 seconds for the suppress timer
z 120 seconds for the garbage-collect
timer
When adjusting RIPng timers, you should consider the network performance and perform unified
configurations on routers running RIPng to avoid unnecessary network traffic increase or route
oscillation.
1-7
Configuring Split Horizon and Poison Reverse
If both split horizon and poison reverse are configured, only the poison reverse function takes effect.
Configure split horizon
The split horizon function disables a route learned from an interface from being advertised through the
same interface to prevent routing loops between neighbors.
Follow these steps to configure split horizon:

interface-number
Enable the split horizon Optional

ripng split-horizon
function Enabled by default
z Generally, you are recommended to enable split horizon to prevent routing loops.
z In frame relay, X.25 and other non-broadcast multi-access (NBMA) networks, split horizon should
be disabled if multiple VCs are configured on the primary interface and secondary interfaces to
ensure route advertisement. For detailed information, refer to Frame Relay Configuration and
LAPB and X.25 Configuration in the Access Volume.
Configuring the poison reverse function
The poison reverse function enables a route learned from an interface to be advertised through the
interface. However, the metric of the route is set to 16. That is to say, the route is unreachable.
Follow these steps to configure poison reverse:

interface-number
Enable the poison reverse Required

ripng poison-reverse
function Disabled by default
1-8
Configuring Zero Field Check on RIPng Packets
Some fields in the RIPng packet must be zero. These fields are called zero fields. With zero field check
on RIPng packets enabled, if such a field contains a non-zero value, the entire RIPng packet will be
discarded. If you are sure that all packets are trusty, you can disable the zero field check to reduce the
CPU processing time.
Follow these steps to configure RIPng zero field check:

Optional
Enable the zero field check checkzero
Enabled by default
Configuring the Maximum Number of Equal Cost Routes for Load Balancing
Follow these steps to configure the maximum number of equal cost RIPng routes for load balancing:


maximum load-balancing
number of equal cost RIPng
number The default varies with devices.
routes for load balancing
Displaying and Maintaining RIPng

Display configuration
display ripng [ process-id ] Available in any view
information of a RIPng process
Display routes in the RIPng
display ripng process-id database Available in any view
database
Display the routing information
display ripng process-id route Available in any view
of a specified RIPng process
Display RIPng interface display ripng process-id interface
information [ interface-type interface-number ]
RIPng Configuration Example (on Routers)

As shown in Figure 1-4, all routers learn IPv6 routing information through RIPng. Configure Router B to
filter the route (3::/64) learnt from Router C, which means the route will not be added to the routing table
of Router B, and Router B will not forward it to Router A.
1-9
Network diagram
Figure 1-4 Network diagram for RIPng configuration
1) Configure the IPv6 address for each interface (Omitted)

2) Configure basic RIPng functions
[RouterA] ripng 1
[RouterA-ripng-1] quit
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterC] ripng 1
[RouterC-ripng-1] quit
[RouterC-Ethernet1/0] ripng 1 enable
1-10
# Display the routing table of Router B.

[RouterB] display ripng 1 route
----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Ethernet1/0

Dest 1::/64,
via FE80::20F:E2FF:FE23:82F5, cost 1, tag 0, A, 6 Sec
Dest 2::/64,
Peer FE80::20F:E2FF:FE00:100 on Ethernet1/1

Dest 3::/64,
via FE80::20F:E2FF:FE00:100, cost 1, tag 0, A, 11 Sec
Dest 4::/64,
Dest 5::/64,
3) Configure Router B to filter incoming and outgoing routes
[RouterB] acl ipv6 number 2000
[RouterB-acl6-basic-2000] rule deny source 3::/64
[RouterB-acl6-basic-2000] rule permit
[RouterB-acl6-basic-2000] quit
[RouterB] ripng 1
[RouterB-ripng-1] filter-policy 2000 import
[RouterB-ripng-1] filter-policy 2000 export
# Display routing tables of Router B and Router A.

[RouterB] display ripng 1 route
----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Ethernet1/0

Dest 1::/64,
Dest 2::/64,
Peer FE80::20F:E2FF:FE00:100 on Ethernet1/1

Dest 4::/64,
Dest 5::/64,
[RouterA] display ripng 1 route
----------------------------------------------------------------
1-11
Peer FE80::20F:E2FF:FE00:1235 on GigabitEthernet0/1
Dest 1::/64,
Dest 4::/64,
Dest 5::/64,
RIPng Configuration Example (on Switches)

As shown in Figure 1-5, all switches run RIPng. Configure Switch B to filter the route (3::/64) learnt from
Switch C, which means the route will not be added to the routing table of Switch B, and Switch B will not
forward it to Switch A.
Network diagram
Figure 1-5 Network diagram for RIPng configuration
1) Configure the IPv6 address for each interface (omitted)

2) Configure basic RIPng functions
[SwitchA] ripng 1
[SwitchA-ripng-1] quit
[SwitchB] ripng 1
[SwitchB-ripng-1] quit
1-12
[SwitchC] ripng 1
[SwitchC-ripng-1] quit
[SwitchC-Vlan-interface101] ripng 1 enable
# Display the routing table of Switch B.

[SwitchB] display ripng 1 route
----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Vlan-interface100

Dest 1::/64,
Dest 2::/64,
Peer FE80::20F:E2FF:FE00:100 on Vlan-interface200

Dest 3::/64,
Dest 4::/64,
Dest 5::/64,

[SwitchA] display ripng 1 route
----------------------------------------------------------------
Peer FE80::200:2FF:FE64:8904 on Vlan-interface100

Dest 1::/64,
via FE80::200:2FF:FE64:8904, cost 1, tag 0, A, 31 Sec
Dest 4::/64,
Dest 5::/64,
Dest 3::/64,
1-13
3) Configure Switch B to filter incoming and outgoing routes.
[SwitchB] acl ipv6 number 2000
[SwitchB-acl6-basic-2000] rule deny source 3::/64
[SwitchB-acl6-basic-2000] rule permit
[SwitchB-acl6-basic-2000] quit
[SwitchB] ripng 1
[SwitchB-ripng-1] filter-policy 2000 import
[SwitchB-ripng-1] filter-policy 2000 export
# Display routing tables of Switch B and Switch A.

[SwitchB] display ripng 1 route
----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Vlan-interface100

Dest 1::/64,
Dest 2::/64,

Dest 4::/64,
Dest 5::/64,
[SwitchA] display ripng 1 route
----------------------------------------------------------------

Dest 1::/64,
Dest 4::/64,
Dest 5::/64,
1-14
Table of Contents
1 IPv6 Static Routing Configuration 1-1

Introduction to IPv6 Static Routing1-1
Features of IPv6 Static Routes1-1
Default IPv6 Route 1-1
Configuring an IPv6 Static Route1-2
Configuration prerequisites 1-2
Configuring an IPv6 Static Route 1-2
Displaying and Maintaining IPv6 Static Routes 1-2
IPv6 Static Routing Configuration Example (on Routers)1-3
IPv6 Static Routing Configuration Example (on Switches) 1-5
i
1 IPv6 Static Routing Configuration
When configuring IPv6 Static Routing, go to these sections for information you are interested in:
z Introduction to IPv6 Static Routing
z Configuring an IPv6 Static Route
z Displaying and Maintaining IPv6 Static Routes
z IPv6 Static Routing Configuration Example (on Routers)
z IPv6 Static Routing Configuration Example (on Switches)
The term router in this document refers to either a router in a generic sense or a Layer 3 switch
running routing protocols.
Introduction to IPv6 Static Routing

Static routes are special routes that are manually configured by network administrators. They work well
in simple networks. Configuring and using them properly can improve the performance of networks and
guarantee enough bandwidth for important applications.
However, static routes also have shortcomings: any topology changes could result in unavailable routes,
requiring the network administrator to manually configure and modify the static routes.
Features of IPv6 Static Routes
Similar to IPv4 static routes, IPv6 static routes work well in simple IPv6 network environments.
Their major difference lies in the destination and next hop addresses. IPv6 static routes use IPv6
addresses whereas IPv4 static routes use IPv4 addresses. Currently, IPv6 static routes do not support
VPN instance.
Default IPv6 Route
The IPv6 static route that has the destination address configured as ::/0 (indicating a prefix length of 0)
is the default IPv6 route. If the destination address of an IPv6 packet does not match any entry in the
1-1
routing table, this default route will be used to forward the packet.
Configuring an IPv6 Static Route

In small IPv6 networks, IPv6 static routes can be used to forward packets. In comparison to dynamic
routes, it helps to save network bandwidth.
z Configuring parameters for the related interfaces

z Configuring link layer attributes for the related interfaces
z Enabling IPv6 packet forwarding
z Ensuring that the neighboring nodes are IPv6 reachable
Configuring an IPv6 Static Route
Follow these steps to configure an IPv6 static route:
To do Use the commands Remarks
ipv6 route-static ipv6-address

Configure an IPv6 static route
prefix-length [ interface-type
with the output interface being
interface-number ] nexthop-address Required
a broadcast or NBMA interface
[ preference preference-value ]
The default
ipv6 route-static ipv6-address preference of IPv6
Configure an IPv6 static route static routes is 60.
prefix-length { interface-type
with the output interface being
interface-number | nexthop-address }
a point-to-point interface
[ preference preference-value ]
While configuring a static route, you can configure either the output interface or the next-hop address
depending on the situations:
z If the output interface is a broadcast interface, such as an Ethernet interface, a VLAN interface, or
an NBMA interface (such as an X.25 interface or frame relay interface), then the next hop address
must be specified.
z If the output interface is a point-to-point interface (such as a serial port), you can specify either the
output interface or the next hop address, but not both.
Displaying and Maintaining IPv6 Static Routes

display ipv6 routing-table
Display IPv6 static route
protocol static [ inactive | Available in any view
information
verbose ]
Remove all IPv6 static routes delete ipv6 static-routes all Available in system view
1-2
Using the undo ipv6 route-static command can delete a single IPv6 static route, while using the
delete ipv6 static-routes all command deletes all IPv6 static routes including the default route.
IPv6 Static Routing Configuration Example (on Routers)

With IPv6 static routes configured, all hosts and routers can interact with each other. The serial ports of
the routers use the IPv6 local link addresses.
Network diagram
Configuraiton procedure
1) Configure IPv6 addresses for all interfaces (Omitted).

2) Configure IPv6 static routes.
# Configure the default IPv6 route on RouterA.
[RouterA] ipv6 route-static :: 0 serial 2/0
# Configure two IPv6 static routes on RouterB.

[RouterB] ipv6 route-static 1:: 64 serial 2/0
[RouterB] ipv6 route-static 3:: 64 serial 2/1
# Configure the default IPv6 route on RouterC.

[RouterC] ipv6 route-static :: 0 serial 2/0
3) Configure the IPv6 addresses of hosts and gateways.
Configure the IPv6 addresses of all the hosts based upon the network diagram, configure the default
gateway of Host A as 1::1, that of Host B as 2::1, and that of Host C as 3::1.
4) Display configuration information
1-3
# Display the IPv6 routing table on RouterA.
[RouterA] display ipv6 routing-table
Routing Table :
Destination : :: Protocol : Static

NextHop : FE80::510A:0:8D7:1 Preference : 60
Interface : S2/0 Cost : 0
Destination : ::1 Protocol : Direct

NextHop : ::1 Preference : 0
Interface : InLoop0 Cost : 0
Destination : 1:: Protocol : Direct

NextHop : 1::1 Preference : 0
Interface : Eth1/0 Cost : 0
Destination : 1::1 Protocol : Direct

Destination : FE80:: Protocol : Direct

NextHop : :: Preference : 0
Interface : NULL0 Cost : 0
# Check connectivity with the ping command.

[RouterA] ping ipv6 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1

0.00% packet loss
1-4
IPv6 Static Routing Configuration Example (on Switches)
With IPv6 static routes configured, all hosts and switches can interact with each other.
Network diagram
Figure 1-2 Network diagram for static routes (on switches)
1) Configure the IPv6 addresses of all VLAN interfaces (Omitted)

2) Configure IPv6 static routes.
# Configure the default IPv6 static route on SwitchA.
[SwitchA] ipv6 route-static :: 0 4::2
# Configure two IPv6 static routes on SwitchB.

[SwitchB] ipv6 route-static 1:: 64 4::1
[SwitchB] ipv6 route-static 3:: 64 5::1
# Configure the default IPv6 static route on SwitchC.

[SwitchC] ipv6 route-static :: 0 5::2
3) Configure the IPv6 addresses of hosts and gateways.
Configure the IPv6 addresses of all the hosts based upon the network diagram, configure the default
gateway of Host A as 1::1, that of Host B as 2::1, and that of Host C as 3::1.
4) Display configuration information
# Display the IPv6 routing table of SwitchA.
[SwitchA] display ipv6 routing-table
Routing Table :
Destination : :: Protocol : Static

NextHop : FE80::510A:0:8D7:1 Preference : 60
1-5
Interface : Vlan-interface200 Cost : 0
Destination : ::1 Protocol : Direct

Destination : 1:: Protocol : Direct

NextHop : 1::1 Preference : 0
Interface : Vlan-interface100 Cost : 0
Destination : 1::1 Protocol : Direct

Destination : FE80:: Protocol : Direct

NextHop : :: Preference : 0
Interface : NULL0 Cost : 0
# Verify the connectivity with the ping command.

[SwitchA] ping ipv6 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1

0.00% packet loss
1-6
Table of Contents
1 Multicast Overview 1-1

Introduction to Multicast 1-1
Comparison of Information Transmission Techniques1-1
Features of Multicast 1-4
Common Notations in Multicast1-5
Advantages and Applications of Multicast1-5
Multicast Models 1-6
Multicast Architecture1-6
Multicast Addresses 1-7
Multicast Protocols 1-10
Multicast Packet Forwarding Mechanism 1-12
Multi-Instance Multicast1-13
Introduction to the Multi-Instance Concept1-13
Multi-Instance Application in Multicast 1-13
i
z The MSR series routers support VPN instances, therefore supporting the vpn-instance keyword.
1 Multicast Overview
This manual chiefly focuses on the IP multicast technology and device operations. Unless otherwise
stated, the term multicast in this document refers to IP multicast.
Introduction to Multicast
As a technique coexisting with unicast and broadcast, the multicast technique effectively addresses the
issue of point-to-multipoint data transmission. By allowing high-efficiency point-to-multipoint data
transmission over a network, multicast greatly saves network bandwidth and reduces network load.
With the multicast technology, a network operator can easily provide new value-added services, such
as live Webcasting, Web TV, distance learning, telemedicine, Web radio, real-time videoconferencing,
and other bandwidth- and time-critical information services.
Comparison of Information Transmission Techniques
Unicast
In unicast, the information source (Source in the figure) needs to send a separate copy of information to
each host (Receiver in the figure) that wants the information, as shown in Figure 1-1.
1-1
Figure 1-1 Unicast transmission
Host A
Receiver
Host B
Source
Host C
Receiver
Host D
IP network Receiver
Packets for Host B Host E

Packets for Host D
Packets for Host E
Assume that Hosts B, D and E need the information. A separate transmission channel needs to be
established from the information source to each of these hosts.
In unicast transmission, the traffic transmitted over the network is proportional to the number of hosts
that need the information. If a large number of users need the information, the information source needs
to send a copy of the same information to each of these users. This means a tremendous pressure on
the information source and the network bandwidth.
As we can see from the information transmission process, unicast is not suitable for batch transmission
of information.
Broadcast
In broadcast, the information source sends information to all hosts on the subnet, even if some hosts do
not need the information, as shown in Figure 1-2.
1-2
Figure 1-2 Broadcast transmission
Assume that only Hosts B, D, and E need the information. If the information is broadcast to the subnet,
Hosts A and C also receive it. In addition to information security issues, this also causes traffic flooding
on the same subnet.
Therefore, broadcast is disadvantageous in transmitting data to specific hosts; moreover, broadcast
transmission is a significant waste of network resources.
Multicast
As discussed above, unicast and broadcast techniques are unable to provide point-to-multipoint data
transmissions with the minimum network consumption.
Multicast can well solve this problem. When some hosts on the network need multicast information, the
information sender, or multicast source, sends only one copy of the information. Multicast distribution
trees are built through multicast routing protocols, and the packets are replicated only on nodes where
the trees branch. Figure 1-3 shows the delivery of a data stream to receiver hosts through multicast.
1-3
Figure 1-3 Multicast transmission
The multicast source (Source in the figure) sends only one copy of the information to a multicast group.
Hosts B, D and E, which are receivers of the information, need to join the multicast group. The routers
on the network duplicate and forward the information based on the distribution of the group members.
Finally, the information is correctly delivered to Hosts B, D, and E.
To sum up, the advantages of multicast are summarized as follows:
z Over unicast: As multicast traffic flows to the node the farthest possible from the source before it is
replicated and distributed, an increase of the number of hosts will not increase the load of the
source and will not remarkably add to network resource usage.
z Over broadcast: As multicast data is sent only to the receivers that need it, multicast uses the
network bandwidth reasonably and enhances network security. In addition, data broadcast is
confined to the same subnet, while multicast is not.
Features of Multicast
Multicast has the following features:

z A multicast group is a multicast receiver set identified by an IP multicast address. Hosts join a
multicast group to become members of the multicast group, before they can receive the multicast
data addressed to that multicast group. Typically, a multicast source does not need to join a
multicast group.
z An information sender is referred to as a multicast source (Source in Figure 1-3). A multicast
source can send data to multiple multicast groups at the same time, and multiple multicast sources
can send data to the same multicast group at the same time.
z All hosts that have joined a multicast group become members of the multicast group (Receivers in
Figure 1-3). The group memberships are dynamic. Hosts can join or leave multicast groups at any
time. Multicast groups are not subject to geographic restrictions.
1-4
z Routers or Layer 3 switches that support Layer 3 multicast are called multicast routers or Layer 3
multicast devices. In addition to providing the multicast routing function, a multicast router can also
manage multicast group memberships on stub subnets with attached group members. A multicast
router itself can be a multicast group member.
For a better understanding of the multicast concept, you can assimilate multicast transmission to the
transmission of TV programs, as shown in Table 1-1.
Table 1-1 An analogy between TV transmission and multicast transmission
Step TV transmission Multicast transmission

A TV station transmits a TV program A multicast source sends multicast data
1
through a channel. to a multicast group.
2 A user tunes the TV set to the channel. A receiver joins the multicast group.
The user starts to watch the TV The receiver starts to receive the
3 program transmitted by the TV station multicast data that the source sends to
via the channel. the multicast group.
The user turns off the TV set or tunes The receiver leaves the multicast group
4
to another channel. or joins another group.
Common Notations in Multicast
Two notations are commonly used in multicast:

z (*, G): Indicates a rendezvous point tree (RPT), or a multicast packet that any multicast source
sends to multicast group G. Here * represents any multicast source, while G represents a
specific multicast group.
z (S, G): Indicates a shortest path tree (SPT), or a multicast packet that multicast source S sends to
multicast group G. Here S represents a specific multicast source, while G represents a specific
multicast group.
For details about the concepts RPT and SPT, see PIM Configuration or IPv6 PIM Configuration in the IP
Multicast Volume.
Advantages and Applications of Multicast
Advantages of multicast
Advantages of the multicast technique include:

z Enhanced efficiency: reduces the CPU load of information source servers and network devices.
z Optimal performance: reduces redundant traffic.
z Distributive application: Enables point-to-multiple-point applications at the price of the minimum
network resources.
Applications of multicast
Applications of the multicast technique include:
1-5
z Multimedia and streaming applications, such as Web TV, Web radio, and real-time video/audio
conferencing.
z Communication for training and cooperative operations, such as distance learning and
telemedicine.
z Data warehouse and financial applications (stock quotes).
z Any other point-to-multiple-point data distribution application.
Multicast Models
Based on how the receivers treat the multicast sources, there are three multicast models: any-source
multicast (ASM), source-filtered multicast (SFM), and source-specific multicast (SSM).
ASM model
In the ASM model, any sender can send information to a multicast group as a multicast source, and
numbers of receivers can join a multicast group identified by a group address and obtain multicast
information addressed to that multicast group. In this model, receivers are not aware of the position of
multicast sources in advance. However, they can join or leave the multicast group at any time.
SFM model
The SFM model is derived from the ASM. From the view of a sender, the two models have the same
multicast membership architecture.
The SFM model functionally extends the ASM model: In the SFM model, the upper layer software
checks the source address of received multicast packets and permits or denies multicast traffic from
specific sources. Therefore, receivers can receive the multicast data from only part of the multicast
sources. From the view of a receiver, multicast sources are not all valid: they are filtered.
SSM model
In the practical life, users may be interested in the multicast data from only certain multicast sources.
The SSM model provides a transmission service that allows users to specify the multicast sources they
are interested in at the client side.
The radical difference between the SSM model and the ASM model is that in the SSM model, receivers
already know the locations of the multicast sources by some other means. In addition, the SSM model
uses a multicast address range that is different from that of the ASM/SFM model, and dedicated
multicast forwarding paths are established between receivers and the specified multicast sources.
Multicast Architecture
IP multicast addresses the following questions:
z Where should the multicast source transmit information to? (multicast addressing)
z What receivers exist on the network? (host registration)
z Where is the multicast source the receivers need to receive multicast data from? (multicast source
discovery)
z How should information be transmitted to the receivers? (multicast routing)
IP multicast falls in the scope of end-to-end service. The multicast architecture involves the following
four parts:
1) Addressing mechanism: Information is sent from a multicast source to a group of receivers through
a multicast address.
1-6
2) Host registration: Receiver hosts are allowed to join and leave multicast groups dynamically. This
mechanism is the basis for group membership management.
3) Multicast routing: A multicast distribution tree (namely a forwarding path tree for multicast data on
the network) is constructed for delivering multicast data from a multicast source to receivers.
4) Multicast applications: A software system that supports multicast applications, such as video
conferencing, must be installed on multicast sources and receiver hosts, and the TCP/IP stack
must support reception and transmission of multicast data.
Multicast Addresses
To allow communication between multicast sources and multicast group members, network-layer
multicast addresses, namely, multicast IP addresses must be provided. In addition, a technique must be
available to map multicast IP addresses to link-layer multicast MAC addresses.
IP multicast addresses
1) IPv4 multicast addresses

Internet Assigned Numbers Authority (IANA) assigned the Class D address space (224.0.0.0 to
239.255.255.255) for IPv4 multicast. The specific address blocks and usages are shown in Table 1-2.
Table 1-2 Class D IP address blocks and description
Address block Description

Reserved permanent group addresses. The IP address 224.0.0.0 is
reserved, and other IP addresses can be used by routing protocols and
224.0.0.0 to for topology searching, protocol maintenance, and so on. Common
224.0.0.255 permanent group addresses are listed in Table 1-3. A packet destined for
an address in this block will not be forwarded beyond the local subnet
regardless of the Time to Live (TTL) value in the IP header.
Globally scoped group addresses. This block includes two types of
224.0.1.0 to designated group addresses:
238.255.255.255 z 232.0.0.0/8: SSM group addresses, and
z 233.0.0.0/8: Glop group addresses.
Administratively scoped multicast addresses. These addresses are
239.0.0.0 to considered to be locally rather than globally unique, and can be reused in
239.255.255.255 domains administered by different organizations without causing
conflicts. For details, refer to RFC 2365.
z The membership of a group is dynamic. Hosts can join or leave multicast groups at any time.
z Glop is a mechanism for assigning multicast addresses between different autonomous systems
(ASs). By filling an AS number into the middle two bytes of 233.0.0.0, you get 255 multicast
addresses for that AS. For more information, refer to RFC 2770.
1-7
Table 1-3 Some reserved multicast addresses
Address Description
224.0.0.1 All systems on this subnet, including hosts and routers
224.0.0.2 All multicast routers on this subnet
224.0.0.3 Unassigned
224.0.0.4 Distance Vector Multicast Routing Protocol (DVMRP) routers
224.0.0.5 Open Shortest Path First (OSPF) routers
224.0.0.6 OSPF designated routers/backup designated routers
224.0.0.7 Shared Tree (ST) routers
224.0.0.8 ST hosts
224.0.0.9 Routing Information Protocol version 2 (RIPv2) routers
224.0.0.11 Mobile agents
224.0.0.12 Dynamic Host Configuration Protocol (DHCP) server/relay agent
224.0.0.13 All Protocol Independent Multicast (PIM) routers
224.0.0.14 Resource Reservation Protocol (RSVP) encapsulation
224.0.0.15 All Core-Based Tree (CBT) routers
224.0.0.16 Designated Subnetwork Bandwidth Management (SBM)

224.0.0.17 All SBMs
224.0.0.18 Virtual Router Redundancy Protocol (VRRP)
2) IPv6 multicast addresses

As defined in RFC 4291, the format of an IPv6 multicast is as follows:
Figure 1-4 IPv6 multicast format
z 0xFF: 8 bits, indicating that this address is an IPv6 multicast address.

z Flags: 4 bits, of which the high-order flag is reserved and set to 0; the definition and usage of the
second bit can be found in RFC 3956; and definition and usage of the third bit can be found in RFC
3306; the low-order bit is the Transient (T) flag. When set to 0, the T flag indicates a
permanently-assigned multicast address assigned by IANA; when set to 1, the T flag indicates a
transient, or dynamically assigned multicast address.
z Scope: 4 bits, indicating the scope of the IPv6 internetwork for which the multicast traffic is intended.
Possible values of this field are given in Table 1-4.
z Group ID: 112 bits, identifying the multicast group. For details about this field, refer to RFC 3306.
1-8
Table 1-4 Values of the Scope field
Value Meaning
0, 3, F Reserved
1 Interface-local scope
2 Link-local scope
4 Admin-local scope
5 Site-local scope
6, 7, 9 through D Unassigned
8 Organization-local scope
E Global scope
Ethernet multicast MAC addresses
When a unicast IP packet is transmitted over Ethernet, the destination MAC address is the MAC
address of the receiver. When a multicast packet is transmitted over Ethernet, however, the destination
address is a multicast MAC address because the packet is directed to a group formed by a number of
receivers, rather than to one specific receiver.
1) IPv4 multicast MAC addresses
As defined by IANA, the high-order 24 bits of an IPv4 multicast MAC address are 0x01005E, bit 25 is 0,
and the low-order 23 bits are the low-order 23 bits of a multicast IPv4 address. The IPv4-to-MAC
mapping relation is shown in Figure 1-5.
Figure 1-5 IPv4-to-MAC address mapping
The high-order four bits of a multicast IPv4 address are 1110, indicating that this address is a multicast
address, and only 23 bits of the remaining 28 bits are mapped to a MAC address, so five bits of the
multicast IPv4 address are lost. As a result, 32 multicast IPv4 addresses map to the same MAC address.
Therefore, in Layer 2 multicast forwarding, a device may receive some multicast data addressed for
other IPv4 multicast groups, and such redundant data needs to be filtered by the upper layer.
2) IPv6 multicast MAC addresses
The high-order 16 bits of an IPv6 multicast MAC address are 0x3333, and the low-order 32 bits are the
low-order 32 bits of a multicast IPv6 address. Figure 1-6 shows an example of mapping an IPv6
multicast address, FF1E::F30E:0101, to a MAC address.
1-9
Figure 1-6 An example of IPv6-to-MAC address mapping
Multicast Protocols
z Generally, we refer to IP multicast working at the network layer as Layer 3 multicast and the
corresponding multicast protocols as Layer 3 multicast protocols, which include IGMP/MLD,
PIM/IPv6 PIM, MSDP, and MBGP/IPv6 MBGP; we refer to IP multicast working at the data link
layer as Layer 2 multicast and the corresponding multicast protocols as Layer 2 multicast protocols,
which include IGMP Snooping/MLD Snooping, and multicast VLAN/IPv6 multicast VLAN.
z IGMP Snooping, IGMP, multicast VLAN, PIM, MSDP, and MBGP are for IPv4, MLD Snooping,
MLD, IPv6 multicast VLAN, IPv6 PIM, and IPv6 MBGP are for IPv6.
This section provides only general descriptions about applications and functions of the Layer 2 and
Layer 3 multicast protocols in a network. For details of these protocols, refer to the related configuration
manuals in the IP Multicast Volume.
Layer 3 multicast protocols
Layer 3 multicast protocols include multicast group management protocols and multicast routing
protocols. Figure 1-7 describes where these multicast protocols are in a network.
1-10
Figure 1-7 Positions of Layer 3 multicast protocols
1) Multicast management protocols

Typically, the internet group management protocol (IGMP) or multicast listener discovery protocol (MLD)
is used between hosts and Layer 3 multicast devices directly connected with the hosts. These protocols
define the mechanism of establishing and maintaining group memberships between hosts and Layer 3
multicast devices.
2) Multicast routing protocols
A multicast routing protocol runs on Layer 3 multicast devices to establish and maintain multicast routes
and forward multicast packets correctly and efficiently. Multicast routes constitute a loop-free data
transmission path from a data source to multiple receivers, namely, a multicast distribution tree.
In the ASM model, multicast routes come in intra-domain routes and inter-domain routes.
z An intra-domain multicast routing protocol is used to discover multicast sources and build multicast
distribution trees within an AS so as to deliver multicast data to receivers. Among a variety of
mature intra-domain multicast routing protocols, protocol independent multicast (PIM) is a popular
one. Based on the forwarding mechanism, PIM comes in two modes dense mode (often referred
to as PIM-DM) and sparse mode (often referred to as PIM-SM).
z An inter-domain multicast routing protocol is used for delivery of multicast information between two
ASs. So far, mature solutions include multicast source discovery protocol (MSDP) and multicast
border gateway protocol (MBGP). MSDP is used to propagate multicast source information among
different ASs, while MBGP is an extension of Multi-protocol Border Gateway Protocol (MP-BGP)
for exchanging multicast routing information among different ASs.
For the SSM model, multicast routes are not divided into inter-domain routes and intra-domain routes.
Since receivers know the position of the multicast source, channels established through PIM-SM are
sufficient for multicast information transport.
Layer 2 multicast protocols
Layer 2 multicast protocols include IGMP Snooping/MLD Snooping and multicast VLAN/IPv6 multicast
VLAN. Figure 1-8 shows where these protocols are in the network.
1-11
Figure 1-8 Position of Layer 2 multicast protocols
Source
Multicast VLAN
/IPv6 Multicast VLAN
IGMP Snooping
/MLD Snooping
Receiver Receiver
IPv4/IPv6 multicast packets
1) IGMP Snooping/MLD Snooping

Running on Layer 2 devices, Internet Group Management Protocol Snooping (IGMP Snooping) and
Multicast Listener Discovery Snooping (MLD Snooping) are multicast constraining mechanisms that
manage and control multicast groups by listening to and analyzing IGMP or MLD messages exchanged
between the hosts and Layer 3 multicast devices, thus effectively controlling the flooding of multicast
data in a Layer 2 network.
2) Multicast VLAN/IPv6 multicast VLAN
In the traditional multicast-on-demand mode, when users in different VLANs on a Layer 2 device need
multicast information, the upstream Layer 3 device needs to forward a separate copy of the multicast
data to each VLAN of the Layer 2 device. With the multicast VLAN or IPv6 multicast VLAN feature
enabled on the Layer 2 device, the Layer 3 multicast device needs to send only one copy of multicast to
the multicast VLAN or IPv6 multicast VLAN on the Layer 2 device. This avoids waste of network
bandwidth and extra burden on the Layer 3 device.
Multicast Packet Forwarding Mechanism

In a multicast model, a multicast source sends information to the host group identified by the multicast
group address in the destination address field of IP multicast packets. Therefore, to deliver multicast
packets to receivers located in different parts of the network, multicast routers on the forwarding path
usually need to forward multicast packets received on one incoming interface to multiple outgoing
interfaces. Compared with a unicast model, a multicast model is more complex in the following aspects.
z To ensure multicast packet transmission in the network, unicast routing tables or multicast routing
tables (for example, MBGP routing table) specially provided for multicast must be used as
guidance for multicast forwarding.
z To process the same multicast information from different peers received on different interfaces of
the same device, every multicast packet is subject to a reverse path forwarding (RPF) check on the
incoming interface. The result of the RPF check determines whether the packet will be forwarded
or discarded. The RPF check mechanism is the basis for most multicast routing protocols to
implement multicast forwarding.
1-12
For details about the RPF mechanism, refer to Multicast Routing and Forwarding Configuration or IPv6
Multicast Routing and Forwarding Configuration in the IP Multicast Volume.
Multi-Instance Multicast
Multi-instance multicast refers to multicast in virtual private networks (VPNs).
Introduction to the Multi-Instance Concept
VPN networks need to be isolated from one another and from the public network. As shown in Figure
1-9, VPN A and VPN B separately access the public network through PE devices.
Figure 1-9 Networking diagram for VPN
VPN A
CE a2
CE b2 CE b3
PE 2
VPN B VPN B
CE b1
CE a1 CE a3
PE 1 Public network PE 3
VPN A VPN A
z The P device belongs to the public network. The CE devices belong to their respective VPNs. Each
CE device serves its own network and maintains only one set of forwarding mechanism.
z The PE devices interface with the public network and the VPN networks, serving multiple networks
at the same time. On each PE device, the information for different networks must be strictly
distinguished and a separate forwarding mechanism must be maintained for each network. On a
PE device, a set of software and hardware that serves the same network forms an instance.
Multiple instances exist on a PE device at the same time, and an instance resides on different PE
devices.
Multi-Instance Application in Multicast
With multi-instance multicast enabled, a PE is able to:
1-13
z Maintain a set of independent multicast forwarding mechanism for each instance, include various
multicast protocols, a list of PIM neighbors and a multicast routing table per instance. Each
instance searches its own forwarding table or routing table to forward multicast data.
z Guarantee the isolation between different VPN instances.
z Implement information exchange and data conversion between the public instance and VPN
instances.
Multi-instance multicast is the basis of multicast over a VPNs network. With multicast VPN, as shown in
Figure 1-9, when a multicast source in VPN A sends a multicast stream to a multicast group, of all
possible receivers on the network for that group, only those belong to VPN A can receive the multicast
stream. The multicast data is multicast both in VPN A and in the public network.
z Only one set of unified multicast service runs on a non-PE device. It is called public instance.
z The configuration made in VPN instance view only takes effect on the VPN instance interface only.
An interface that does not belong to any VPN instance is called public instance interface.
z For more information about multicast VPN, refer to Multicast VPN Configuration in the IP Multicast
Volume.
1-14
Table of Contents
1 Multicast Routing and Forwarding Configuration1-1

Multicast Routing and Forwarding Overview 1-1
Introduction to Multicast Routing and Forwarding1-1
RPF Check Mechanism1-2
Multicast Static Routes 1-4
Application of GRE Tunnel in Multicast Forwarding1-6
Multicast Traceroute 1-6
Configuring Multicast Routing and Forwarding1-7
Enabling IP Multicast Routing 1-8
Configuring Multicast Static Routes 1-9
Configuring a Multicast Routing Policy1-9
Configuring a Multicast Forwarding Range 1-10
Configuring the Multicast Forwarding Table Size1-11
Configuring RPF Check Failure Processing1-12
Tracing a Multicast Path 1-13
Displaying and Maintaining Multicast Routing and Forwarding 1-14
Configuration Examples (On Routers) 1-15
Changing an RPF Route 1-15
Creating an RPF Route 1-17
Configuration Examples (On Switches) 1-19
Changing an RPF Route 1-19
Creating an RPF Route 1-21
Troubleshooting Multicast Routing and Forwarding 1-24
Multicast Static Route Failure1-24
Multicast Data Fails to Reach Receivers1-24
i

VPN multi-instance Yes Yes Yes Yes
Configuring special processing of
No No No No
multicast packets upon RPF check failure
1 Multicast Routing and Forwarding Configuration
When configuring multicast routing and forwarding, go to these sections for information you are
interested in:
z Multicast Routing and Forwarding Overview
z Configuring Multicast Routing and Forwarding
z Displaying and Maintaining Multicast Routing and Forwarding
z Configuration Examples (On Routers)
z Configuration Examples (On Switches)
z Troubleshooting Multicast Routing and Forwarding
z The term "router" in this document refers to a router in a generic sense or a Layer 3 switch running
an IP routing protocol.
z The support for multiple instances depends on the device model.
Multicast Routing and Forwarding Overview

Introduction to Multicast Routing and Forwarding
In multicast implementations, multicast routing and forwarding are implemented by three types of
tables:
z Each multicast routing protocol has its own multicast routing table, such as PIM routing table.
z The information of different multicast routing protocols forms a general multicast routing table.
1-1
z The multicast forwarding table is directly used to control the forwarding of multicast packets.
A multicast forwarding table consists of a set of (S, G) entries, each indicating the routing information for
delivering multicast data from a multicast source to a multicast group. If a router supports multiple
multicast protocols, its multicast routing table will include routes generated by multiple protocols. The
router chooses the optimal route from the multicast routing table based on the configured multicast
routing and forwarding policy and installs the route entry into its multicast forwarding table.
RPF Check Mechanism
A multicast routing protocol relies on the existing unicast routing information, MBGP routes, or multicast
static routes in creating multicast routing entries. When creating multicast routing table entries, a
multicast routing protocol uses the reverse path forwarding (RPF) check mechanism to ensure
multicast data delivery along the correct path. In addition, the RPF check mechanism also helps avoid
data loops caused by various reasons.
RPF check process
The basis for an RPF check is a unicast route, an MBGP route, or a multicast static route.
z A unicast routing table contains the shortest path to each destination subnet,
z An MBGP routing table contains multicast routing information, and
z A multicast static routing table contains the RPF routing information defined by the user through
static configuration.
When performing an RPF check, a router searches its unicast routing table and multicast static routing
table at the same time. The specific process is as follows:
1) The router first chooses an optimal route from the unicast routing table, MBGP routing table, and
multicast static routing table:
z The router automatically chooses an optimal unicast route by searching its unicast routing table,
using the IP address of the packet source as the destination address. The outgoing interface in
the corresponding routing entry is the RPF interface and the next hop is the RPF neighbor. The
router considers the path along which the packet from the RPF neighbor arrived on the RPF
interface to be the shortest path that leads back to the source.
z The router automatically chooses an optimal MBGP route by searching its MBGP routing table,
using the IP address of the packet source as the destination address. The outgoing interface in
the corresponding routing entry is the RPF interface and the next hop is the RPF neighbor.
z The router automatically chooses an optimal multicast static route by searching its multicast static
routing table, using the IP address of the packet source as the destination address. The
corresponding routing entry explicitly defines the RPF interface and the RPF neighbor.
2) Then, the router selects one from these three optimal routes as the RPF route. The selection
process is as follows:
z If configured to use the longest match principle, the router selects the longest match route from the
three; if these three routes have the same mask, the router selects the route with the highest
priority; if the three routes have the same priority, the router selects the RPF route according to the
sequence of multicast static route, MBGP route, and unicast route.
z If not configured to use the longest match principle, the router selects the route with the highest
priority; if the three routes have the same priority, the router selects the RPF route according to the
sequence of multicast static route, MBGP route, and unicast route.
1-2
The above-mentioned packet source can mean different things in different situations:
z For a packet traveling along the shortest path tree (SPT) from the multicast source to the receivers
or the rendezvous point (RP), the packet source for RPF check is the multicast source.
z For a packet traveling along the rendezvous point tree (RPT) from the RP to the receivers, the
packet source for RPF check is the RP.
z For a bootstrap message from the bootstrap router (BSR), the packet source for RPF check is the
BSR.
For details about the concepts of SPT, RPT and BSR, refer to PIM Configuration in the IP Multicast
Volume.
Implementation of RPF check in multicast
Implementing an RPF check on each received multicast data packet would bring a big burden to the
router. The use of a multicast forwarding table is the solution to this issue. When creating a multicast
routing entry and a multicast forwarding entry for a multicast packet, the router sets the RPF interface of
the packet as the incoming interface of the (S, G) entry. Upon receiving an (S, G) multicast packet, the
router first searches its multicast forwarding table:
1) If the corresponding (S, G) entry does not exist in the multicast forwarding table, the packet is
subject to an RPF check. The router creates a multicast routing entry based on the relevant routing
information and installs the entry into the multicast forwarding table, with the RPF interface as the
incoming interface.
z If the interface on which the packet actually arrived is the RPF interface, the RPF check succeeds
and the router forwards the packet to all the outgoing interfaces.
z If the interface on which the packet actually arrived is not the RPF interface, the RPF check fails
and the router discards the packet.
2) If the corresponding (S, G) entry exists, and the interface on which the packet actually arrived is the
incoming interface, the router forwards the packet to all the outgoing interfaces.
3) If the corresponding (S, G) entry exists, but the interface on which the packet actually arrived is not
the incoming interface in the multicast forwarding table, the multicast packet is subject to an RPF
check.
z If the RPF interface is the incoming interface of the (S, G) entry, this means the (S, G) entry is
correct but the packet arrived from a wrong path. The packet is to be discarded.
z If the RPF interface is not the incoming interface, this means the (S, G) entry has expired, and
router replaces the incoming interface with the RPF interface. If the interface on which the packet
arrived in the RPF interface, the router forwards the packet to all the outgoing interfaces; otherwise
it discards the packet.
Some models allow you to configure special processing of packets that have failed an RPF check
instead of simply dropping them. For details, refer to Configuring RPF Check Failure Processing.
1-3
Assume that unicast routes are available in the network, MBGP is not configured, and no multicast
static routes have been configured on Router C, as shown in Figure 1-1. Multicast packets travel along
the SPT from the multicast source to the receivers. The multicast forwarding table on Router C contains
the (S, G) entry, with POS 5/1 as the RPF interface.
Figure 1-1 RPF check process
z When a multicast packet arrives on POS 5/1 of Router C, as the interface is the incoming interface
of the (S, G) entry, the router forwards the packet to all outgoing interfaces.
z When a multicast packet arrives on POS 5/0 of Router C, as the interface is not the incoming
interface of the (S, G) entry, the router performs an RPF check on the packet: The router searches
its unicast routing table and finds that the outgoing interface to Source (the RPF interface) is POS
5/1. This means the (S, G) entry is correct and packet arrived along a wrong path. The RPF check
fails and the packet is discarded.
Multicast Static Routes
A multicast static route is an important basis for RPF check. Depending on the application environment,
a multicast static route has the following two functions:
Changing an RPF route
Typically, the topology structure of a multicast network is the same as that of a unicast network, and
multicast traffic follows the same transmission path as unicast traffic does. By configuring a multicast
static route for a given multicast source, you can change the RPF route so as to create a transmission
path for multicast traffic different from that for unicast traffic.
1-4
Figure 1-2 Changing an RPF route
As shown in Figure 1-2, when no multicast static route is configured, Router Cs RPF neighbor on the
path back to Source is Router A and the multicast information from Source travels along the path from
Router A to Router C, which is the unicast route between the two routers; with a static route configured
on Router C and with Router B as Router Cs RPF neighbor on the path back to Source, the multicast
information from Source travels from Router A to Router B and then to Router C.
Creating an RPF route
When a unicast route is blocked, multicast traffic forwarding is stopped due to lack of an RPF route. By
configuring a multicast static route for a given multicast source, you can create an RPF route so that a
multicast routing entry is created to guide multicast traffic forwarding.
Figure 1-3 Creating an RPF route
As shown in Figure 1-3, the RIP domain and the OSPF domain are unicast isolated from each other.
When no multicast static route is configured, the hosts (Receivers) in the OSPF domain cannot receive
the multicast packets sent by the multicast source (Source) in the RIP domain. After you configure a
multicast static route on Router C and Router D, specifying Router B as the RPF neighbor of Router C
1-5
and specifying Router C as the RPF neighbor of Router D, the receivers can receive multicast data sent
by the multicast source.
z A multicast static route only affects RPF check; it cannot guide multicast forwarding. Therefore, a
multicast static route is also called an RPF static route.
z A multicast static route is effective only on the multicast router on which it is configured, and will not
be advertised throughout the network or redistributed to other routers.
Application of GRE Tunnel in Multicast Forwarding
There may be routers that do not support multicast protocols in a network. As multicast traffic from a
multicast source is forwarded hop by hop by multicast routers along the forwarding tree, when the
multicast traffic is forwarded to a next-hop router that does not support IP multicast, the forwarding path
is blocked. In this case, you can enable multicast traffic forwarding across the unicast subnet where the
non-multicast-capable router resides by establishing a generic routing encapsulation (GRE) tunnel
between the routers at both ends of the unicast subnet.
For details about GRE tunneling, refer to GRE Configuration in the VPN Volume.
Figure 1-4 Multicast data transmission through a GRE tunnel
As shown in Figure 1-4, with a GRE tunnel established between Router A and Router B, Router A
encapsulates multicast data in unicast IP packets, which are then forwarded by unicast routers to
Router B across the GRE tunnel. Then, Router B strips off the unicast IP header and continues
forwarding the multicast data down towards the receivers.
If unicast static routes are configured across the tunnel, any unicast packet can be transmitted through
the tunnel. If you wish the tunnel to be dedicated to multicast traffic delivery, you can configure only a
multicast static route across the tunnel, so that unicast packets cannot be transmitted through this
tunnel.
Multicast Traceroute
The multicast traceroute utility is used to trace the path that a multicast stream flows down from the
first-hop router to the last-hop router.
1-6
Concepts in multicast traceroute
1) Last-hop router: If a router has one of its interfaces connecting to the subnet the given destination
address is on, and if the router is able to forward multicast streams from the given multicast source
onto that subnet, that router is called last-hop router.
2) First-hop router: the router that directly connects to the multicast source.
3) Querier: the router requesting the multicast traceroute.
Introduction to multicast traceroute packets
A multicast traceroute packet is a special IGMP packet, which differs from common IGMP packets in
that its IGMP Type field is set to 0x1F or 0x1E and that its destination IP address is a unicast address.
There are three types of multicast traceroute packets:
z Query, with the IGMP Type field set to 0x1F,
z Request, with the IGMP Type field set to 0x1F, and
z Response, with the IGMP Type field set to 0x1E.
Process of multicast traceroute
1) The querier sends a query to the last-hop router.

2) Upon receiving the query, the last-hop router turns the query packet into a request packet by
adding a response data block containing its interface addresses and packet statistics to the end of
the packet, and forwards the request packet via unicast to the previous hop for the given multicast
source and group.
3) From the last-hop router to the multicast source, each hop adds a response data block to the end of
the request packet and unicasts it to the previous hop.
4) When the first-hop router receives the request packet, it changes the packet type to indicate a
response packet, and then sends the completed packet via unicast to the multicast traceroute
querier.

Complete these tasks to configure multicast routing and forwarding:
Task Remarks
Enabling IP Multicast Routing Required
Configuring Multicast Static Routes Optional
Configuring a Multicast Routing Policy Optional
Configuring a Multicast Forwarding Range Optional
Configuring the Multicast Forwarding Table Size Optional
Configuring RPF Check Failure Processing Optional

Tracing a Multicast Path Optional
Configuring Multicast Routing and Forwarding

Before configuring multicast routing and forwarding, complete the following tasks:
1-7
z Configure a unicast routing protocol so that all devices in the domain are interoperable at the
network layer.
z Enable PIM (PIM-DM or PIM-SM).
Before configuring multicast routing and forwarding, prepare the following data:
z The minimum TTL value required for a multicast packet to be forwarded
z The maximum number of downstream nodes for a single multicast forwarding table entry
z The maximum number of entries in the multicast forwarding table
Enabling IP Multicast Routing
Before configuring any Layer 3 multicast functionality, you must enable IP multicast routing.
Enabling IP multicast routing in the public instance
Follow these steps to enable IP multicast routing in the public instance:

Required
Enable IP multicast routing multicast routing-enable
Disabled by default
Enabling IP multicast routing in a VPN instance
Follow these steps to enable IP multicast routing in a VPN instance:

Create a VPN instance and ip vpn-instance

enter VPN instance view vpn-instance-name
Configure a route distinguisher route-distinguisher Required

(RD) for the VPN instance route-distinguisher No RD is configured by default.
Required
Disabled by default
IP multicast does not support the use of secondary IP address segments. Namely, multicast can be
routed and forwarded only through primary IP addresses, rather than secondary addresses, even if
configured on interfaces.
For details about primary and secondary IP addresses, refer to IP Addressing Configuration in the IP
Services Volume.
1-8
For details about the ip vpn-instance and route-distinguisher commands, refer to MPLS L3VPN
Commands in the MPLS Volume.
Configuring Multicast Static Routes
By configuring a multicast static route for a given multicast source, you can specify an RPF interface or
an RPF neighbor for multicast traffic from that source.
Follow these steps to configure a multicast static route:

ip rpf-route-static [ vpn-instance vpn-instance-name ] Required

Configure a source-address { mask | mask-length } [ protocol
multicast static [ process-id ] ] [ route-policy policy-name ] No multicast static
route { rpf-nbr-address | interface-type interface-number } route configured by
[ preference preference ] [ order order-number ] default.
When configuring a multicast static route, you cannot designate an RPF neighbor by specifying an
interface (by means of the interface-type interface-number command argument combination) if the
interface type of that router is Ethernet, GigabitEthernet, Loopback, RPR, or VLAN-interface; instead,
you can designate an RPF neighbor only by specifying an address (rpf-nbr-address).
Configuring a Multicast Routing Policy
If multiple unicast routes with the same cost exist to the same multicast source, you can configure the
router to determine the RPF route based on the longest match (that is, by mask length).
With the load splitting feature enabled, multicast traffic will be evenly distributed among the equal-cost
routes.
Configuring a multicast routing policy in the public instance
Follow these steps to configure a multicast routing policy in the public instance:

Configure the device to select a Required

multicast longest-match
route based on the longest match Not configured by default
multicast load-splitting Optional

Configuring multicast load splitting
{ source | source-group } Disabled by default
1-9
Configuring a multicast routing policy in a VPN instance
Follow these steps to configure a multicast routing policy in a VPN instance:

Enter VPN instance view ip vpn-instance vpn-instance-name
Configure the device to select a Required

route based on the longest multicast longest-match Not configured by
match default
Configure multicast load multicast load-splitting { source | Optional

splitting source-group } Disabled by default
Configuring a Multicast Forwarding Range
Multicast packets do not travel without a boundary in a network. The multicast data corresponding to
each multicast group must be transmitted within a definite scope. Presently, you can define a multicast
forwarding range by:
z Specifying boundary interfaces, which form a closed multicast forwarding area, or
z Setting the minimum time to live (TTL) value required for a multicast packet to be forwarded.
You can configure a forwarding boundary specific to a particular multicast group on all interfaces that
support multicast forwarding. A multicast forwarding boundary sets the boundary condition for the
multicast groups in the specified range. If the destination address of a multicast packet matches the set
boundary condition, the packet will not be forwarded. Once a multicast boundary is configured on an
interface, this interface can no longer forward multicast packets (including packets sent from the local
device) or receive multicast packets.
You can configure the minimum TTL required for a multicast packet to be forwarded on all interfaces
that support multicast forwarding. Before being forwarded from an interface, every multicast packet
(including multicast packet from the local device) is subject to a TTL check:
z If the TTL value of the packet (already decremented by 1 on this router) is larger than the minimum
TTL value configured on the interface, the packet will be forwarded.
z If the TTL value of the packet is smaller than or equal to the minimum TTL value configured on the
interface, the packet will be discarded.
Follow these steps to configure a multicast forwarding range:

interface-number
multicast boundary Required

Configure a multicast
group-address { mask | No forwarding boundary by
forwarding boundary
mask-length } default
Configure the minimum packet Optional
multicast minimum-ttl
TTL required for a multicast
ttl-value 1 by default
packet to be forwarded
1-10
The support for the multicast minimum-ttl command varies with device models. Refer to your specific
device model.
Configuring the Multicast Forwarding Table Size
The router maintains the corresponding forwarding entry for each multicast packet it receives.
Excessive multicast routing entries, however, can exhaust the routers memory and thus result in lower
router performance. You can set a limit on the number of entries in the multicast forwarding table based
on the actual networking situation and the performance requirements. If the configured maximum
number of multicast forwarding table entries is smaller than the current value, the forwarding entries in
excess will not be immediately deleted; instead they will be deleted by the multicast routing protocol
running on the router. The router will no longer install new multicast forwarding entries until the number
of existing multicast forwarding entries comes down below the configured value.
When forwarding multicast traffic, the router replicates a copy of the multicast traffic for each
downstream node and forwards the traffic, and thus each of these downstream nodes forms a branch of
the multicast distribution tree. You can configure the maximum number of downstream nodes (namely,
the maximum number of outgoing interfaces) for a single entry in the multicast forwarding table to
lessen burden on the router for replicating multicast traffic. If the configured maximum number of
downstream nodes for a single multicast forwarding entry is smaller than the current number, the
downstream nodes in excess will not be deleted immediately; instead they must be deleted by the
multicast routing protocol. The router will no longer install new multicast forwarding entries for newly
added downstream nodes until the number of existing downstream nodes comes down below the
configured value.
Configuring the multicast forwarding table size in the public instance
Follow these steps to configure the multicast forwarding table size in the public instance:

Optional
Configure the maximum The default is the maximum
multicast forwarding-table
number of entries in the number allowed by the system,
route-limit limit
multicast forwarding table of which the specific value
Optional
number of downstream nodes multicast forwarding-table The default is the maximum
for a single multicast forwarding downstream-limit limit number allowed by the system,
entry of which the specific value
depends on the device model..
Configuring the multicast forwarding table size in a VPN instance
Follow these steps to configure the multicast forwarding table size in a VPN instance:
1-11
ip vpn-instance
Enter VPN instance view
vpn-instance-name
Optional
Configure the maximum The default is the maximum
multicast forwarding-table
number of entries in the number allowed by the system,
route-limit limit
depends on the device model
Optional
number of downstream nodes multicast forwarding-table The default is the maximum
for a single route in the downstream-limit limit number allowed by the system,
Configuring RPF Check Failure Processing
The support for this feature depends on the device model.
After a multicast packet fails an RPF check, it may need to be processed differently in different
networking environments instead of being simply dropped.
Flooding the packet to all the ports in the native VLAN
In practice, a multicast packet that failed an RPF check on a VLAN interface may be expected by some
receivers in the VLAN. You can enable flooding multicast packets in the VLAN after RPF failure so that
such receivers can receive them.
Follow these steps to enable flooding packets that failed an RPF check in the native VLAN:


Different device models support this
configuration in different command
interface interface-type views: some models support this
Enter VLAN interface view command in system view, while other
interface-number
devices support this command in
VLAN interface view, but no devices
support this configuration in both
views.
Enable flooding multicast Required
multicast non-rpf-pkt
packets that failed an RPF
broadcast Disabled by default
check in the native VLAN
1-12
After the configuration, use the reset multicast forwarding-table command to clear all the forwarding
entries in the multicast forwarding table; otherwise this configuration cannot take effect.
Passing the packet to the CPU
In the following two cases, a multicast packet that failed the RPF check needs to be passed to the CPU:
z When a multicast packet arrives on an outgoing interface of the corresponding multicast forwarding
entry, the packet will fail the RPF check and needs to be sent to the CPU in order to trigger the
assert mechanism to prune the unwanted branch.
z If the SPT and RPT have different incoming interfaces on the receiver-side DR (the last-hop router),
the multicast traffic will fail the RPF check on the SPT incoming interface during an RPT-to-SPT
switchover before the RPF information is refreshed. If the RPT is pruned at this moment, the
multicast service will be instantaneously interrupted. By passing packets that failed the RPF check
on a non-outgoing interface to the CPU, the router can determine whether the packets that have
failed the RPF check on the SPT interface are expected. If they are, the router initiates an RPT
prune.
For more information about the assert mechanism, DR and RPT-to-SPT switchover, refer to PIM
Configuration in the IP Multicast Volume.
Follow these steps to enable passing packets that failed the RPF check to the CPU:

Enable passing packets that failed multicast non-rpf-pkt Required

the RPF check to the CPU trap-to-cpu Disabled by default
After the configuration, you must use the reset multicast forwarding-table command to clear all the
forwarding entries in the multicast forwarding table; otherwise this configuration cannot take effect.
Tracing a Multicast Path
You can run the mtracert command to trace the path down which the multicast traffic flows from a given
first-hop router to the last-hop router.
mtracert source-address Required

Trace a multicast path
[ [ last-hop-router-address ] group-address ] Available in any view
1-13
Displaying and Maintaining Multicast Routing and Forwarding
display multicast boundary [ vpn-instance
View the multicast boundary vpn-instance-name | all-instance ] Available in
information [ group-address [ mask | mask-length ] ] any view
[ interface interface-type interface-number ]
display multicast [ vpn-instance
vpn-instance-name | all-instance ]
forwarding-table [ source-address [ mask
On a { mask | mask-length } ] | group-address [ mask
Available in
centralized { mask | mask-length } ] | incoming-interface
any view
device { interface-type interface-number | register } |
outgoing-interface { { exclude | include |
View the match } { interface-type interface-number |
multicast register } } | statistics ] * [ port-info ]
forwarding display multicast [ vpn-instance
table vpn-instance-name | all-instance ]
information forwarding-table [ source-address [ mask
{ mask | mask-length } ] | group-address [ mask
On a
{ mask | mask-length } ] | incoming-interface Available in
distributed
{ interface-type interface-number | register } | any view
device
match } { interface-type interface-number |
register } } | statistics | slot slot-number ] *
[ port-info ]
display multicast [ vpn-instance
routing-table [ source-address [ mask { mask |
mask-length } ] | group-address [ mask { mask |
View the multicast routing table Available in
mask-length } ] | incoming-interface
information any view
{ interface-type interface-number | register } |
match } { interface-type interface-number |
register } } ] *
display multicast routing-table

View the information of the [ vpn-instance vpn-instance-name | Available in
multicast static routing table all-instance ] static [ config ] [ source-address any view
{ mask-length | mask } ]
View the RPF route information display multicast [ vpn-instance
Available in
of the specified multicast vpn-instance-name | all-instance ] rpf-info
any view
source source-address [ group-address ]
View the minimum TTL display multicast [ vpn-instance
Available in
required for a multicast packet vpn-instance-name | all-instance ] minimum-ttl
any view
to be forwarded [ interface-type interface-number ]
reset multicast [ vpn-instance
forwarding-table { { source-address [ mask
Clear forwarding entries from Available in
{ mask | mask-length } ] | group-address [ mask
the multicast forwarding table user view
{ mask | mask-length } ] | incoming-interface
{ interface-type interface-number | register } } * |
all }
1-14
reset multicast [ vpn-instance
routing-table { { source-address [ mask { mask
Clear routing entries from the Available in
| mask-length } ] | group-address [ mask { mask |
multicast routing table user view
mask-length } ] | incoming-interface
{ interface-type interface-number | register } } * |
all }
The support for the display multicast minimum-ttl command varies with device models. Refer to your
specific device model.
z The reset command clears the information in the multicast routing table or the multicast forwarding
table, and thus may cause failure of multicast transmission.
z When a routing entry is deleted from the multicast routing table, the corresponding forwarding entry
will also be deleted from the multicast forwarding table.
z When a forwarding entry is deleted from the multicast forwarding table, the corresponding route
entry will also be deleted from the multicast routing table.
Configuration Examples (On Routers)

Changing an RPF Route
z PIM-DM runs in the network. All routers in the network support multicast.
z Router A, Router B and Router C run OSPF.
z Typically, Receiver can receive the multicast data from Source through the path Router A Router
B, which is the same as the unicast route.
z Perform the following configuration so that Receiver can receive the multicast data from Source
through the path Router A Router C Router B, which is different from the unicast route.
1-15
Network diagram
Figure 1-5 Network diagram for RPF route alteration configuration (on routers)
1) Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface as per Figure 1-5. The detailed
configuration steps are omitted here.
Enable OSPF on the routers in the PIM-DM domain. Ensure the network-layer interoperation among the
routers in the PIM-DM domain. Ensure that the routers can dynamically update their routing information
by leveraging the unicast routing protocol. The specific configuration steps are omitted here.
2) Enable IP multicast routing, and enable PIM-DM and IGMP
# Enable IP multicast routing on Router B, enable PIM-DM on each interface, and enable IGMP on the
host-side interface Ethernet 1/0.
[RouterB] multicast routing-enable
[RouterB-Ethernet1/0] igmp enable
[RouterB-Ethernet1/0] pim dm
# Enable IP multicast routing on Router A, and enable PIM-DM on each interface.

1-16
The configuration on Router C is similar to the configuration on Router A. The specific configuration
steps are omitted here.
# Use the display multicast rpf-info command to view the RPF route to Source on Router B.
[RouterB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Ethernet1/2, RPF neighbor: 30.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: igp
Route selection rule: preference-preferred
Load splitting rule: disable
As shown above, the current RPF route on Router B is contributed by a unicast routing protocol and the
RPF neighbor is Router A.
3) Configure a multicast static route
# Configure a multicast static route on Router B, specifying Router C as its RPF neighbor to Source.
[RouterB] ip rpf-route-static 50.1.1.100 24 20.1.1.2
# Use the display multicast rpf-info command to view the information about the RPF route to Source
on Router B.
Referenced route type: multicast static
As shown above, the RPF route on Router B has changed. It is now the configured multicast static route,
and the RPF neighbor is now Router C.
Creating an RPF Route
z PIM-DM runs in the network and all routers in the network support IP multicast.
z Router B and Router C run OSPF, and have no unicast routes to Router A.
z Typically, Receiver can receive the multicast data from Source 1 in the OSPF domain.
z Perform the following configuration so that Receiver can receive multicast data from Source 2,
which is outside the OSPF domain.
1-17
Network diagram
Figure 1-6 Network diagram for creating an RPF route (on routers)
PIM-DM
OSPF domain
Router A Router B Router C
30.1.1.2/24 30.1.1.1/24 20.1.1.1/24
Eth1/1
20.1.1.2/24
50.1.1.1/24 40.1.1.1/24 10.1.1.1/24
Source 2 Source 1 Receiver
50.1.1.100/24 40.1.1.100/24 10.1.1.100/24
Multicast static route

Enable OSPF on Router B and Router C. Ensure the network-layer interoperation among Router B and
Router C. Ensure that the routers can dynamically update their routing information by leveraging the
unicast routing protocol. The specific configuration steps are omitted here.
# Enable IP multicast routing on Router C, enable PIM-DM on each interface, and enable IGMP on the
[RouterC] multicast routing-enable
[RouterC-Ethernet1/0] igmp enable
[RouterC-Ethernet1/0] pim dm
# Enable IP multicast routing on Router A and enable PIM-DM on each interface.

1-18
The configuration on Router B is similar to that on Router A. The specific configuration steps are omitted
here.
# Use the display multicast rpf-info command to view the information of the RPF route to Source 2 on
[RouterC] display multicast rpf-info 50.1.1.100
No information is displayed. This means that no RPF route to Source 2 exists on Router B and Router
C.
# Configure a multicast static route on Router B, specifying Router A as its RPF neighbor on the route to
Source 2.
[RouterB] ip rpf-route-static 50.1.1.100 24 30.1.1.2
# Configure a multicast static route on Router C, specifying Router B as its RPF neighbor on the route to
Source 2.
[RouterC] ip rpf-route-static 50.1.1.100 24 20.1.1.2
# Use the display multicast rpf-info command to view the RPF routes to Source 2 on Router B and
Router C.
[RouterC] display multicast rpf-info 50.1.1.100
As shown above, the RPF routes to Source 2 exist on Router B and Router C. The source for these RPF
routes is the configured multicast static route.
Configuration Examples (On Switches)

Changing an RPF Route
z PIM-DM runs in the network. All switches in the network support multicast.
z Switch A, Switch B and Switch C run OSPF.
z Typically, Receiver can receive the multicast data from Source through the path Switch A Switch
B, which is the same as the unicast route.
1-19
z Perform the following configuration so that Receiver can receive the multicast data from Source
through the path Switch A Switch C Switch B, which is different from the unicast route.
Network diagram
Figure 1-7 Network diagram for RPF route alternation configuration (on switches)

Enable OSPF on the switches in the PIM-DM domain. Ensure the network-layer interoperation among
the switches in the PIM-DM domain. Ensure that the switches can dynamically update their routing
information by leveraging the unicast routing protocol. The specific configuration steps are omitted
here.
# Enable IP multicast routing on Switch B, enable PIM-DM on each interface, and enable IGMP on the
host-side interface VLAN-interface 100.
[SwitchB] multicast routing-enable
[SwitchB-Vlan-interface100] igmp enable
[SwitchB-Vlan-interface100] pim dm
1-20
# Enable IP multicast routing on Switch A, and enable PIM-DM on each interface.
[SwitchA] multicast routing-enable
[SwitchA-Vlan-interface200] pim dm
The configuration on Switch C is similar to the configuration on Switch A. The specific configuration
# Use the display multicast rpf-info command to view the RPF route to Source on Switch B.
[SwitchB] display multicast rpf-info 50.1.1.100
RPF interface: Vlan-interface102, RPF neighbor: 30.1.1.2
Referenced route type: igp
As shown above, the current RPF route on Switch B is contributed by a unicast routing protocol and the
RPF neighbor is Switch A.
# Configure a multicast static route on Switch B, specifying Switch C as its RPF neighbor on the route to
Source.
[SwitchB] ip rpf-route-static 50.1.1.100 24 20.1.1.2
# Use the display multicast rpf-info command to view the information about the RPF route to Source
on Switch B.
As shown above, the RPF route on Switch B has changed. It is now the configured multicast static route,
and the RPF neighbor is now Switch C.
Creating an RPF Route
z PIM-DM runs in the network and all switches in the network support IP multicast.
1-21
z Switch B and Switch C run OSPF, and have no unicast routes to Switch A.
z Typically, Receiver can receive the multicast data from Source 1 in the OSPF domain.
z Perform the following configuration so that Receiver can receive multicast data from Source 2,
which is outside the OSPF domain.
Network diagram
Figure 1-8 Network diagram for creating an RPF route (on switches)
PIM-DM
OSPF domain
Switch A Switch B Switch C
30.1.1.2/24 30.1.1.1/24 20.1.1.1/24
Vlan-int101
Vlan-int300 Vlan-int200 20.1.1.2/24 Vlan-int100
50.1.1.1/24 40.1.1.1/24 10.1.1.1/24
Source 2 Source 1 Receiver
50.1.1.100/24 40.1.1.100/24 10.1.1.100/24
Multicast static route

Enable OSPF on Switch B and Switch C. Ensure the network-layer interoperation among Switch B and
Switch C. Ensure that the switches can dynamically update their routing information by leveraging the
unicast routing protocol. The specific configuration steps are omitted here.
# Enable IP multicast routing on Switch C, enable PIM-DM on each interface, and enable IGMP on the
[SwitchC] multicast routing-enable
[SwitchC-Vlan-interface100] igmp enable
[SwitchC-Vlan-interface100] pim dm
# Enable IP multicast routing on Switch A and enable PIM-DM on each interface.

1-22
The configuration on Switch B is similar to that on Switch A. The specific configuration steps are omitted
here.
# Use the display multicast rpf-info command to view the RPF routes to Source 2 on Switch B and
Switch C.
[SwitchC] display multicast rpf-info 50.1.1.100
No information is displayed. This means that no RPF route to Source 2 exists on Switch B and Switch C.
# Configure a multicast static route on Switch B, specifying Switch A as its RPF neighbor on the route to
Source 2.
[SwitchB] ip rpf-route-static 50.1.1.100 24 30.1.1.2
# Configure a multicast static route on Switch C, specifying Switch B as its RPF neighbor on the route to
Source 2.
[SwitchC] ip rpf-route-static 50.1.1.100 24 20.1.1.2
# Use the display multicast rpf-info command to view the RPF routes to Source 2 on Switch B and
Switch C.
[SwitchC] display multicast rpf-info 50.1.1.100
As shown above, the RPF routes to Source 2 exist on Switch B and Switch C. The source is the
configured static route.
1-23
Troubleshooting Multicast Routing and Forwarding
Multicast Static Route Failure
Symptom
No dynamic routing protocol is enabled on the routers, and the physic status and link layer status of
interfaces are both up, but the multicast static route fails.
Analysis
z If the multicast static route is not configured or updated correctly to match the current network
conditions, the route entry and the configuration information of multicast static routes do not exist in
the multicast routing table.
z If the optimal route is found, the multicast static route may also fail.
Solution
1) In the configuration, you can use the display multicast routing-table static config command to
view the detailed configuration information of multicast static routes to verify that the multicast
static route has been correctly configured and the route entry exists.
2) In the configuration, you can use the display multicast routing-table static command to view the
information of multicast static routes to verify that the multicast static route has been correctly
configured and the route entry exists in the multicast routing table.
3) Check the next hop interface type of the multicast static route. If the interface is not a point-to-point
interface, be sure to specify the next hop address to configure the outgoing interface when you
configure the multicast static route.
4) Check that the multicast static route matches the specified routing protocol. If a protocol was
specified in multicast static route configuration, enter the display ip routing-table command to
check if an identical route was added by the protocol.
5) Check that the multicast static route matches the specified routing policy. If a routing policy was
specified when the multicast static route was configured, enter the display route-policy command
to check the configured routing policy.
Multicast Data Fails to Reach Receivers
Symptom
The multicast data can reach some routers but fails to reach the last hop router.
Analysis
z When a router receives a multicast packet, it decrements the TTL value of the multicast packet by
1 and recalculates the checksum value. The router then forwards the packet to all outgoing
interfaces. If the multicast minimum-ttl command is configured on the outgoing interfaces, the
TTL value of the packet must be greater than the configured minimum TTL value; otherwise, the
packet will be discarded.
z If a multicast forwarding boundary has been configured through the multicast boundary
command, any multicast packet will be kept from crossing the boundary.
1-24
Solution
1) Use the display pim routing-table command to check whether the corresponding (S, G) entries
exist on the router. If so, the router has received the multicast data; otherwise, the router has not
received the data.
2) Enter the display multicast minimum-ttl command to check the configured minimum TTL value
required for multicast packets to be forwarded. Use the undo multicast minimum-ttl command on
the concerned interfaces to restore the required minimum TTL value to the system default, or
configure multicast packets to be sent with a higher TTL value from the multicast source.
3) Use the display multicast boundary command to view the multicast boundary information on the
interfaces. Use the multicast boundary command to change the multicast forwarding boundary
setting.
4) In the case of PIM-SM, use the display current-configuration command to check the BSR and
RP information.
1-25
Table of Contents
1 IGMP Snooping Configuration 1-1

IGMP Snooping Overview1-1
Principle of IGMP Snooping 1-1
Basic Concepts in IGMP Snooping 1-2
How IGMP Snooping Works1-3
Processing of Multicast Protocol Messages1-5
IGMP Snooping Configuration Task List1-6
Configuring Basic Functions of IGMP Snooping1-7
Enabling IGMP Snooping 1-7
Configuring the Version of IGMP Snooping 1-8
Configuring IGMP Snooping Port Functions1-8
Configuring Aging Timers for Dynamic Ports 1-9
Configuring Static Ports1-9
Configuring Simulated Joining1-10
Configuring Fast Leave Processing 1-11
Configuring IGMP Snooping Querier 1-12
Enabling IGMP Snooping Querier 1-12
Configuring IGMP Queries and Responses 1-13
Configuring Source IP Address of IGMP Queries 1-14
Configuring an IGMP Snooping Policy1-15
Configuring a Multicast Group Filter1-15
Configuring Multicast Source Port Filtering 1-16
Configuring the Function of Dropping Unknown Multicast Data1-16
Configuring IGMP Report Suppression 1-17
Configuring Maximum Multicast Groups that Can Be Joined on a Port1-18
Configuring Multicast Group Replacement1-18
Displaying and Maintaining IGMP Snooping1-20
IGMP Snooping Configuration Examples 1-20
Configuring Group Policy and Simulated Joining1-20
Static Router Port Configuration1-23
IGMP Snooping Querier Configuration1-25
Troubleshooting IGMP Snooping Configuration 1-27
Switch Fails in Layer 2 Multicast Forwarding 1-27
Configured Multicast Group Policy Fails to Take Effect 1-28
i

Yes
Configuring multicast Yes
No No Supported by
source port filtering Supported by MIM board
FIC board
Yes
Configuring the
function of dropping No No Supported by MIM board and Yes
unknown multicast data the 30-11 series routers with
XMIM board
1 IGMP Snooping Configuration
When configuring IGMP Snooping, go to the following sections for information you are interested in:
z IGMP Snooping Overview
z IGMP Snooping Configuration Task List
z Displaying and Maintaining IGMP Snooping
z IGMP Snooping Configuration Examples
z Troubleshooting IGMP Snooping Configuration
IGMP Snooping Overview

Internet Group Management Protocol Snooping (IGMP Snooping) is a multicast constraining
mechanism that runs on Layer 2 devices to manage and control multicast groups.
Principle of IGMP Snooping
By analyzing received IGMP messages, a Layer 2 device running IGMP Snooping establishes
mappings between ports and multicast MAC addresses and forwards multicast data based on these
mappings.
As shown in Figure 1-1, when IGMP Snooping is not running on the switch, multicast packets are
broadcast to all devices at Layer 2. When IGMP Snooping is running on the switch, multicast packets for
known multicast groups are multicast to the receivers, rather than broadcast to all hosts, at Layer 2.
1-1
Figure 1-1 Before and after IGMP Snooping is enabled on the Layer 2 device
Multicast packet transmission Multicast packet transmission

without IGMP Snooping when IGMP Snooping runs
Multicast router Multicast router
Source Source
Layer 2 switch Layer 2 switch
Host A Host C Host A Host C

Receiver Receiver Receiver Receiver
Host B Host B
Multicast packets
Basic Concepts in IGMP Snooping
IGMP Snooping related ports
As shown in Figure 1-2, Router A connects to the multicast source, IGMP Snooping runs on Switch A
and Switch B, Host A and Host C are receiver hosts (namely, multicast group members).
Figure 1-2 IGMP Snooping related ports
Receiver
Router A Switch A
Eth1/0 Eth1/1
Eth1/2 Host A
Host B
Eth1/0 Receiver
Source Eth1/1
Switch B Host C
Router port
Member port
Multicast packets
Host D
Ports involved in IGMP Snooping, as shown in Figure 1-2, are described as follows:
z Router port: A router port is a port on an Ethernet switch that leads switch towards a Layer 3
multicast device (DR or IGMP querier). In the figure, Ethernet 1/0 of Switch A and Ethernet 1/0 of
Switch B are router ports. The switch registers all its local router ports in its router port list.
1-2
z Member port: A member port is a port on an Ethernet switch that leads the switch towards multicast
group members. In the figure, Ethernet 1/1 and Ethernet 1/2 of Switch A and Ethernet 1/1 of Switch
B are member ports. The switch registers all the member ports on the local device in its IGMP
Snooping forwarding table.
z Whenever mentioned in this document, a router port is a port on the switch that leads the switch to
a Layer 3 multicast device, rather than a port on a router.
z Unless otherwise specified, router/member ports mentioned in this document include static and
dynamic ports.
z An IGMP-snooping-enabled switch deems that all its ports on which IGMP general queries with the
source IP address other than 0.0.0.0 or PIM hello messages are received to be dynamic router
ports. For details about PIM hello messages, see PIM Configuration of the IP Multicast Volume.
Aging timers for dynamic ports in IGMP Snooping and related messages and actions
Table 1-1 Aging timers for dynamic ports in IGMP Snooping and related messages and actions
Message before
Timer Description Action after expiry
expiry
For each dynamic router port, IGMP general query of
Dynamic The switch removes
the switch sets a timer which the source
router port this port from its router
initialized to the dynamic router address is not 0.0.0.0
aging timer port list.
port aging time. or PIM hello
When a port dynamically joins a
The switch removes
Dynamic multicast group, the switch sets
IGMP membership this port from the IGMP
member port a timer for the port, which is
report Snooping forwarding
aging timer initialized to the dynamic
table.
member port aging time.
The port aging mechanism of IGMP Snooping works only for dynamic ports; a static port will never age
out.
How IGMP Snooping Works
A switch running IGMP Snooping performs different actions when it receives different IGMP messages,
as follows:
1-3
The description about adding or deleting a port in this section is only for a dynamic port. Static ports can
be added or deleted only through the corresponding configurations. For details, see Configuring Static
Ports.
When receiving a general query
The IGMP querier periodically sends IGMP general queries to all hosts and routers (224.0.0.1) on the
local subnet to find out whether active multicast group members exist on the subnet.
Upon receiving an IGMP general query, the switch forwards it through all ports in the VLAN except the
receiving port and performs the following to the receiving port:
z If the receiving port is a dynamic router port existing in its router port list, the switch resets the aging
timer of this dynamic router port.
z If the receiving port is not a dynamic router port existing in its router port list, the switch adds it into
its router port list and sets an aging timer for this dynamic router port.
When receiving a membership report
A host sends an IGMP report to the IGMP querier in the following circumstances:
z Upon receiving an IGMP query, a multicast group member host responds with an IGMP report.
z When intended to join a multicast group, a host sends an IGMP report to the IGMP querier to
announce that it is interested in the multicast information addressed to that group.
Upon receiving an IGMP report, the switch forwards it through all the router ports in the VLAN, resolves
the address of the reported multicast group, and performs the following:
z If no forwarding table entry exists for the reported group, the switch creates an entry, adds the port
as a dynamic member port to the outgoing port list, and starts a member port aging timer for that
port.
z If a forwarding table entry exists for the reported group, but the port is not included in the outgoing
port list for that group, the switch adds the port as a dynamic member port to the outgoing port list,
and starts an aging timer for that port.
z If a forwarding table entry exists for the reported group and the port is included in the outgoing port
list, which means that this port is already a dynamic member port, the switch resets the aging timer
for that port.
A switch does not forward an IGMP report through a non-router port. The reason is as follows: Due to
the IGMP report suppression mechanism, if the switch forwards a report message through a member
port, all the attached hosts listening to the reported multicast address will suppress their own reports
upon receiving this report, and this will prevent the switch from knowing whether the reported multicast
group still has active members attached to that port.
For the description of IGMP report suppression mechanism, refer to IGMP Configuration in the IP
Multicast Volume.
1-4
When receiving a leave message
When an IGMPv1 host leaves a multicast group, the host does not send an IGMP leave message, so
the switch cannot know immediately that the host has left the multicast group. However, as the host
stops sending IGMP reports as soon as it leaves a multicast group, the switch deletes the forwarding
entry for the dynamic member port corresponding to the host from the forwarding table when its aging
timer expires.
When an IGMPv2 or IGMPv3 host leaves a multicast group, the host sends an IGMP leave message to
the multicast router.
When the switch receives an IGMP leave message on a dynamic member port, the switch first checks
whether a forwarding table entry for the group address in the message exists, and, if one exists,
whether the outgoing port list contains the port.
z If the forwarding table entry does not exist or if the outgoing port list does not contain the port, the
switch discards the IGMP leave message instead of forwarding it to any port.
z If the forwarding table entry exists and the outgoing port list contains the port, the switch forwards
the leave message to all router ports in the native VLAN. Because the switch does not know
whether any other hosts attached to the port are still listening to that group address, the switch
does not immediately remove the port from the outgoing port list of the forwarding table entry for
that group; instead, it resets the aging timer for the port.
Upon receiving the IGMP leave message from a host, the IGMP querier resolves the multicast group
address in the message and sends an IGMP group-specific query to that multicast group through the
port that received the leave message. Upon receiving the IGMP group-specific query, the switch
forwards it through all its router ports in the VLAN and all member ports for that multicast group, and
performs the following to the port on which it received the IGMP leave message:
z If any IGMP report in response to the group-specific query is received on the port (suppose it is a
dynamic member port) before its aging timer expires, this means that some host attached to the
port is receiving or expecting to receive multicast data for that multicast group. The switch resets
the aging timer of the port.
z If no IGMP report in response to the group-specific query is received on the port before its aging
timer expires, this means that no hosts attached to the port are still listening to that group address:
the switch removes the port from the outgoing port list of the forwarding table entry for that
multicast group when the aging timer expires.
Processing of Multicast Protocol Messages
With Layer 3 multicast routing enabled, an IGMP Snooping switch processes multicast protocol
messages differently under different conditions, specifically as follows:
1) If only IGMP is enabled, or both IGMP and PIM are enabled on the switch, the switch handles
multicast protocol messages in the normal way.
2) In only PIM is enabled on the switch:
z The switch broadcasts IGMP messages as unknown messages in the VLAN.
z Upon receiving a PIM hello message, the switch will maintain the corresponding dynamic router
port.
3) When IGMP is disabled on the switch:
z If PIM is disabled, the switch deletes all its dynamic member ports and dynamic router ports.
z If PIM is enabled, the switch deletes only its dynamic member ports without deleting its dynamic
router ports.
1-5
On a switch with Layer-3 multicast routing enabled, use the display igmp group port-info command to
view Layer-2 port information.
For details about the display igmp group port-info command, refer to IGMP Commands in the IP
Multicast Volume.
4) When PIM is disabled on the switch:

z If IGMP is disabled, the switch deletes all its dynamic router ports without deleting its dynamic
member ports.
z If IGMP is enabled, the switch maintains all its dynamic member ports and dynamic router ports.
IGMP Snooping is documented in:

z RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping Switches
IGMP Snooping Configuration Task List

Complete these tasks to configure IGMP Snooping:
Task Remarks
Configuring Basic Functions Enabling IGMP Snooping Required

of IGMP Snooping Configuring the Version of IGMP Snooping Optional
Configuring Aging Timers for Dynamic Ports Optional
Configuring IGMP Snooping Configuring Static Ports Optional

Port Functions Configuring Simulated Joining Optional
Configuring Fast Leave Processing Optional
Enabling IGMP Snooping Querier Optional
Configuring IGMP Snooping
Configuring IGMP Queries and Responses Optional
Querier
Configuring Source IP Address of IGMP Queries Optional
Configuring a Multicast Group Filter Optional
Configuring Multicast Source Port Filtering Optional
Configuring the Function of Dropping Unknown
Optional
Configuring an IGMP Multicast Data
Snooping Policy Configuring IGMP Report Suppression Optional
Configuring Maximum Multicast Groups that Can
Optional
Be Joined on a Port
Configuring Multicast Group Replacement Optional
1-6
z Configurations made in IGMP Snooping view are effective for all VLANs, while configurations
made in VLAN view are effective only for ports belonging to the current VLAN. For a given VLAN, a
configuration made in IGMP Snooping view is effective only if the same configuration is not made in
VLAN view.
z Configurations made in IGMP Snooping view are effective for all ports; configurations made in
Ethernet interface view are effective only for the current port; configurations made in Layer 2
aggregate interface view are effect only for the current interface; configurations made in port group
view are effective only for all the ports in the current port group. For a given port, a configuration
made in IGMP Snooping view is effective only if the same configuration is not made in Ethernet
interface view, Layer 2 aggregate interface view or port group view.
z For IGMP Snooping, configurations made on a Layer 2 aggregate interface do not interfere with
configurations made on its member ports; nor do they take part in aggregation calculations.
Configuring Basic Functions of IGMP Snooping

Before configuring the basic functions of IGMP Snooping, complete the following task:
z Configure the corresponding VLANs.
Before configuring the basic functions of IGMP Snooping, prepare the following data:
z Version of IGMP Snooping.
Enabling IGMP Snooping
Follow these steps to enable IGMP Snooping:

Enable IGMP Snooping globally and Required

igmp-snooping
enter IGMP-Snooping view Disabled by default

Required
Enable IGMP Snooping in the VLAN igmp-snooping enable
Disabled by default
1-7
z IGMP Snooping must be enabled globally before it can be enabled in a VLAN.
z After enabling IGMP Snooping in a VLAN, you cannot enable IGMP and/or PIM on the
corresponding VLAN interface.
z When you enable IGMP Snooping in a specified VLAN, this function takes effect for the ports in this
VLAN only.
Configuring the Version of IGMP Snooping
By configuring an IGMP Snooping version, you actually configure the version of IGMP messages that
IGMP Snooping can process.
z IGMP Snooping version 2 can process IGMPv1 and IGMPv2 messages, but not IGMPv3
messages, which will be flooded in the VLAN.
z IGMP Snooping version 3 can process IGMPv1, IGMPv2 and IGMPv3 messages.
Follow these steps to configure the version of IGMP Snooping:

Configure the version of IGMP igmp-snooping version Optional

Snooping version-number Version 2 by default
If you switch IGMP Snooping from version 3 to version 2, the system will clear all IGMP Snooping
forwarding entries from dynamic joins, and will:
z Keep forwarding entries for version 3 static (*, G) joins;
z Clear forwarding entries from version 3 static (S, G) joins, which will be restored when IGMP
Snooping is switched back to version 3.
For details about static joins, Refer to Configuring Static Ports.
Configuring IGMP Snooping Port Functions

Before configuring IGMP Snooping port functions, complete the following tasks:
z Enable IGMP Snooping in the VLAN or enable IGMP on the VLAN interface
z Configure the corresponding port groups.
Before configuring IGMP Snooping port functions, prepare the following data:
z Aging time of dynamic router ports,
1-8
z Aging time of dynamic member ports, and
z Multicast group and multicast source addresses
Configuring Aging Timers for Dynamic Ports
If the switch receives no IGMP general queries or PIM hello messages on a dynamic router port, the
switch removes the port from the router port list when the aging timer of the port expires.
If the switch receives no IGMP reports for a multicast group on a dynamic member port, the switch
removes the port from the outgoing port list of the forwarding table entry for that multicast group when
the aging timer of the port for that group expires.
If multicast group memberships change frequently, you can set a relatively small value for the dynamic
member port aging timer, and vice versa.
Configuring aging timers for dynamic ports globally
Follow these steps to configure aging timers for dynamic ports globally:

Enter IGMP Snooping view igmp-snooping
Configure dynamic router port Optional

router-aging-time interval
aging time 105 seconds by default
Configure dynamic member Optional

host-aging-time interval
port aging time 260 seconds by default
Configuring aging timers for dynamic ports in a VLAN
Follow these steps to configure aging timers for dynamic ports in a VLAN:

Configure dynamic router port igmp-snooping Optional

aging time router-aging-time interval 105 seconds by default
Configure dynamic member igmp-snooping Optional

port aging time host-aging-time interval 260 seconds by default
Configuring Static Ports
If all the hosts attached to a port are interested in the multicast data addressed to a particular multicast
group or the multicast data that a particular multicast source sends to a particular group, you can
configure static (*, G) or (S, G) joining on that port, namely configure the port as a group-specific or
source-and-group-specific static member port.
You can configure a port of a switch to be a static router port, through which the switch can forward all
the multicast traffic it received.
Follow these steps to configure static ports:
1-9
Enter Ethernet interface/Layer interface-number Required
2 aggregate interface view or
port group view port-group manual Use either approach
port-group-name
igmp-snooping static-group Required

Configure the port(s) as static
group-address [ source-ip No static member ports by
member port(s)
source-address ] vlan vlan-id default
Configure the port(s) as static igmp-snooping Required

router port(s) static-router-port vlan vlan-id No static router ports by default
z A static (S, G) join can take effect only if a valid multicast source address is specified and IGMP
Snooping version 3 is currently running.
z A static member port does not respond to queries from the IGMP querier; when static (*, G) or (S, G)
joining is enabled or disabled on a port, the port does not send an unsolicited IGMP report or an
IGMP leave message.
z If IGMP is enabled on the virtual interface of a VLAN on a switch that supports both IGMP Snooping
and IGMP and you want a port in that VLAN to be a static multicast group or source-group member
port, in addition to configuring the port as a static member port, you need to use the igmp
static-group command to configure the VLAN interface to be a static member of the multicast
group or source and group. For details of the igmp static-group command, refer to IGMP
Commands in the IP Multicast Volume.
z Static member ports and static router ports never age out. To remove such a port, you need to use
the corresponding undo command.
Configuring Simulated Joining
Generally, a host running IGMP responds to IGMP queries from the IGMP querier. If a host fails to
respond due to some reasons, the multicast router may deem that no member of this multicast group
exists on the network segment, and therefore will remove the corresponding forwarding path.
To avoid this situation from happening, you can enable simulated joining on a port of the switch, namely
configure the port as a simulated member host for a multicast group. When receiving an IGMP query,
the simulated host gives a response. Thus, the switch can continue receiving multicast data.
A simulated host acts like a real host, as follows:
z When a port is configured as a simulated member host, the switch sends an unsolicited IGMP
report through that port.
z After a port is configured as a simulated member host, the switch responds to IGMP general
queries by sending IGMP reports through that port.
z When the simulated joining function is disabled on a port, the switch sends an IGMP leave
message through that port.
1-10
Follow these steps to configure simulated joining:

Enter Ethernet interface/Layer interface interface-type

port group view Use either approach
port-group manual port-group-name
igmp-snooping host-join Required

Configure simulated (*, G) or
group-address [ source-ip
(S, G) joining Disabled by default
source-address ] vlan vlan-id
z Each simulated host is equivalent to an independent host. For example, when receiving an IGMP
query, the simulated host corresponding to each configuration responds respectively.
z Unlike a static member port, a port configured as a simulated member host will age out like a
dynamic member port.
Configuring Fast Leave Processing
The fast leave processing feature allows the switch to process IGMP leave messages in a fast way.
With the fast leave processing feature enabled, when receiving an IGMP leave message on a port, the
switch immediately removes that port from the outgoing port list of the forwarding table entry for the
indicated group. Then, when receiving IGMP group-specific queries for that multicast group, the switch
will not forward them to that port.
In VLANs where only one host is attached to each port, fast leave processing helps improve bandwidth
and resource usage.
Configuring fast leave processing globally
Follow these steps to configure fast leave processing globally:

Required
Enable fast leave processing fast-leave [ vlan vlan-list ]
Disabled by default
1-11
Configuring fast leave processing on a port or a group of ports
Follow these steps to configure fast leave processing on a port or a group of ports:


igmp-snooping fast-leave [ vlan Required

Enable fast leave processing
vlan-list ] Disabled by default
If fast leave processing is enabled on a port to which more than one host is attached, when one host
leaves a multicast group, the other hosts attached to the port and interested in the same multicast group
will fail to receive multicast data for that group.
Configuring IGMP Snooping Querier

Before configuring IGMP Snooping querier, complete the following task:

z Enable IGMP Snooping in the VLAN.
Before configuring IGMP Snooping querier, prepare the following data:
z IGMP general query interval,
z IGMP last-member query interval,
z Maximum response time to IGMP general queries,
z Source address of IGMP general queries, and
z Source address of IGMP group-specific queries.
Enabling IGMP Snooping Querier
In an IP multicast network running IGMP, a multicast router or Layer 3 multicast switch is responsible for
sending IGMP general queries, so that all Layer 3 multicast devices can establish and maintain
multicast forwarding entries, thus to forward multicast traffic correctly at the network layer. This router or
Layer 3 switch is called IGMP querier.
However, a Layer 2 multicast switch does not support IGMP, and therefore cannot send general queries
by default. By enabling IGMP Snooping on a Layer 2 switch in a VLAN where multicast traffic needs to
be Layer-2 switched only and no multicast routers are present, the Layer 2 switch will act as the IGMP
Snooping querier to send IGMP queries, thus allowing multicast forwarding entries to be established
and maintained at the data link layer.
1-12
Follow these steps to enable IGMP Snooping querier:

Required
Enable IGMP Snooping querier igmp-snooping querier
Disabled by default
It is meaningless to configure an IGMP Snooping querier in a multicast network running IGMP. Although
an IGMP Snooping querier does not take part in IGMP querier elections, it may affect IGMP querier
elections because it sends IGMP general queries with a low source IP address.
For details about IGMP querier, see IGMP Configuration of the IP Multicast Volume.
Configuring IGMP Queries and Responses
You can tune the IGMP general query interval based on actual condition of the network.
Upon receiving an IGMP query (general query or group-specific query), a host starts a timer for each
multicast group it has joined. This timer is initialized to a random value in the range of 0 to the maximum
response time (the host obtains the value of the maximum response time from the Max Response Time
field in the IGMP query it received). When the timer value comes down to 0, the host sends an IGMP
report to the corresponding multicast group.
An appropriate setting of the maximum response time for IGMP queries allows hosts to respond to
queries quickly and avoids bursts of IGMP traffic on the network caused by reports simultaneously sent
by a large number of hosts when the corresponding timers expire simultaneously.
z For IGMP general queries, you can configure the maximum response time to fill their Max
Response time field.
z For IGMP group-specific queries, you can configure the IGMP last-member query interval to fill
their Max Response time field. Namely, for IGMP group-specific queries, the maximum response
time equals to the IGMP last-member query interval.
Configuring IGMP queries and responses globally
Follow these steps to configure IGMP queries and responses globally:

Configure the maximum response max-response-time Optional

time to IGMP general queries interval 10 seconds by default
Configure the IGMP last-member last-member-query-inter Optional

query interval val interval 1 second by default
1-13
Configuring IGMP queries and responses in a VLAN
Follow these steps to configure IGMP queries and responses in a VLAN:

Configure IGMP general query igmp-snooping query-interval Optional

interval interval 60 seconds by default
igmp-snooping max-response-time
response time to IGMP general
queries
Configure the IGMP igmp-snooping Optional

last-member query interval last-member-query-interval interval 1 second by default
In the configuration, make sure that the IGMP general query interval is larger than the maximum
response time for IGMP general queries. Otherwise, multicast group members may be deleted by
mistake.
Configuring Source IP Address of IGMP Queries
Upon receiving an IGMP query whose source IP address is 0.0.0.0 on a port, the switch will not set that
port as a dynamic router port. This may prevent multicast forwarding entries from being correctly
created at the data link layer and cause multicast traffic forwarding failure in the end. When a Layer 2
device acts as an IGMP-Snooping querier, to avoid the aforesaid problem, you are commended to
configure a non-all-zero IP address as the source IP address of IGMP queries.
Follow these steps to configure source IP address of IGMP queries:

Configure the source address igmp-snooping general-query source-ip Optional

of IGMP general queries { current-interface | ip-address } 0.0.0.0 by default
Configure the source IP Optional
igmp-snooping special-query source-ip
address of IGMP group-specific
{ current-interface | ip-address } 0.0.0.0 by default
queries
The source address of IGMP query messages may affect IGMP querier selection within the segment.
1-14
Configuring an IGMP Snooping Policy
Before configuring an IGMP Snooping policy, complete the following task:

z Enable IGMP Snooping in the VLAN or enable IGMP on the desired VLAN interface
Before configuring an IGMP Snooping policy, prepare the following data:
z ACL rule for multicast group filtering
z The maximum number of multicast groups that can pass the ports
Configuring a Multicast Group Filter
On an IGMP Snoopingenabled switch, the configuration of a multicast group allows the service
provider to define restrictions on multicast programs available to different users.
In an actual application, when a user requests a multicast program, the users host initiates an IGMP
report. Upon receiving this report message, the switch checks the report against the configured ACL
rule. If the port on which the report was received can join this multicast group, the switch adds an entry
for this port in the IGMP Snooping forwarding table; otherwise the switch drops this report message.
Any multicast data that has failed the ACL check will not be sent to this port. In this way, the service
provider can control the VOD programs provided for multicast users.
Configuring a multicast group filter globally
Follow these steps to configure a multicast group filter globally:

Required
Configure a multicast group group-policy acl-number No group filter is configured by
filter [ vlan vlan-list ] default, namely hosts can join
any multicast group.
Configuring a multicast group filter on a port or a group of ports
Follow these steps to configure a multicast group filter on a port or a group of ports:

port-group-name
Required
Configure a multicast group igmp-snooping group-policy No filter is configured by
filter acl-number [ vlan vlan-list ] default, namely hosts can join
any multicast group.
1-15
Configuring Multicast Source Port Filtering
The support for this feature depends on the specific product model.
With the multicast source port filtering feature enabled on a port, the port can be connected with
multicast receivers only rather than with multicast sources, because the port will block all multicast data
packets while it permits multicast protocol packets to pass.
If this feature is disabled on a port, the port can be connected with both multicast sources and multicast
receivers.
Configuring multicast source port filtering globally
Follow these steps to configure multicast source port filtering globally:

Enable multicast source port Required

source-deny port interface-list
filtering Disabled by default
Configuring multicast source port filtering on a port or a group of ports
Follow these steps to configure multicast source port filtering on a port or a group of ports:

Enter Ethernet interface view or interface-number Required
Enable multicast source port Required

igmp-snooping source-deny
filtering Disabled by default
Some models of devices, when enabled to filter IPv4 multicast data based on the source ports, are
automatically enabled to filter IPv6 multicast data based on the source ports.
Configuring the Function of Dropping Unknown Multicast Data
Unknown multicast data refers to multicast data for which no entries exist in the IGMP Snooping
forwarding table. When the switch receives such multicast traffic:
1-16
z With the function of dropping unknown multicast data enabled, the switch drops all the unknown
multicast data received.
z With the function of dropping unknown multicast data disabled, the switch floods unknown
multicast data in the VLAN which the unknown multicast data belongs to.
Configuring globally the function of dropping unknown multicast data
Follow these steps to configure globally the function of dropping unknown multicast data:

Enable the function of dropping Required

drop-unknown
unknown multicast data Disabled by default
Configuring the function of dropping unknown multicast data in a VLAN
Follow these steps to configure the function of dropping unknown multicast data in a VLAN:

Enable the function of dropping igmp-snooping Required

unknown multicast data drop-unknown Disabled by default
z The support for the drop-unknown and igmp-snooping drop-unknown commands varies with
product models. Some devices support both commands at the same time, while some other
devices support only one of them. Refer to your specific product model.
z For devices that support both drop-unknown and igmp-snooping drop-unknown commands at
the same time, the configuration made in IGMP Snooping view and the configuration made in
VLAN view are mutually exclusive. Namely, after this function is enabled in IGMP Snooping view, it
cannot be enabled or disabled in VLAN view, and vice versa.
z Some models of devices, when enabled to drop unknown IPv4 multicast data, are automatically
enabled to drop unknown IPv6 multicast data.
z Some models of devices, when enabled to drop unknown multicast data, still forward unknown
multicast data to other router ports in the VLAN.
Configuring IGMP Report Suppression
When a Layer 2 device receives an IGMP report from a multicast group member, the device forwards
the message to the Layer 3 device directly connected with it. Thus, when multiple members of a
multicast group are attached to the Layer 2 device, the Layer 3 device directly connected with it will
receive duplicate IGMP reports from these members.
1-17
With the IGMP report suppression function enabled, within each query cycle, the Layer 2 device
forwards only the first IGMP report per multicast group to the Layer 3 device and will not forward the
subsequent IGMP reports from the same multicast group to the Layer 3 device. This helps reduce the
number of packets being transmitted over the network.
Follow these steps to configure IGMP report suppression:

Enable IGMP report Optional

report-aggregation
suppression Enabled by default
Configuring Maximum Multicast Groups that Can Be Joined on a Port
By configuring the maximum number of multicast groups that can be joined on a port, you can limit the
number of multicast programs on-demand available to users, thus to regulate traffic on the port.
Follow these steps to configure the maximum number of multicast groups allowed on a port or ports:



igmp-snooping group-limit limit [ vlan
number of multicast groups The default depends
vlan-list ]
allowed on the port(s) on the product model.
z When the number of multicast groups a port has joined reaches the maximum number configured,
the system deletes all the forwarding entries persistent to that port from the IGMP Snooping
forwarding table, and the hosts on this port need to join the multicast groups again.
z If you have configured static or simulated joins on a port, however, when the number of multicast
groups on the port exceeds the configured threshold, the system deletes all the forwarding entries
persistent to that port from the IGMP Snooping forwarding table and applies the static or simulated
joins again, until the number of multicast groups joined by the port comes back within the
configured threshold.
Configuring Multicast Group Replacement
For some special reasons, the number of multicast groups that can be joined on the current switch or
port may exceed the number configured for the switch or the port. In addition, in some specific
applications, a multicast group newly joined on the switch needs to replace an existing multicast group
1-18
automatically. A typical example is channel switching, namely, by joining a new multicast group, a user
automatically switches from the current multicast group to the new one.
To address such situations, you can enable the multicast group replacement function on the switch or
certain ports. When the number of multicast groups joined on the switch or a port has joined reaches the
limit:
z If the multicast group replacement feature is enabled, the newly joined multicast group
automatically replaces an existing multicast group with the lowest address.
z If the multicast group replacement feature is not enabled, new IGMP reports will be automatically
discarded.
Configuring multicast group replacement globally
Follow these steps to configure multicast group replacement globally:

Enable multicast group overflow-replace [ vlan Required

replacement vlan-list ] Disabled by default
Configuring multicast group replacement on a port or a group of ports
Follow these steps to configure multicast group replacement on a port or a group of ports:

port-group-name
igmp-snooping Required
Enable multicast group
overflow-replace [ vlan
replacement Disabled by default
vlan-list ]
Be sure to configure the maximum number of multicast groups allowed on a port (refer to Configuring
Maximum Multicast Groups that Can Be Joined on a Port) before enabling multicast group replacement.
Otherwise, the multicast group replacement functionality will not take effect.
1-19
Displaying and Maintaining IGMP Snooping
On a
View IGMP display igmp-snooping group [ vlan Available in
centralized
Snooping vlan-id ] [ verbose ] any view
device
multicast group
information On a distributed display igmp-snooping group [ vlan Available in
device vlan-id ] [ slot slot-number ] [ verbose ] any view
View the statistics information of
Available in
IGMP messages learned by IGMP display igmp-snooping statistics
any view
Snooping
Clear IGMP Snooping multicast reset igmp-snooping group Available in
group information { group-address | all } [ vlan vlan-id ] user view
Clear the statistics information of all
Available in
kinds of IGMP messages learned reset igmp-snooping statistics
user view
by IGMP Snooping
z The reset igmp-snooping group command works only on an IGMP Snoopingenabled VLAN, but
not on a VLAN with IGMP enabled on its VLAN interface.
z The reset igmp-snooping group command cannot clear the IGMP Snooping multicast group
information for static joins.
IGMP Snooping Configuration Examples

Configuring Group Policy and Simulated Joining
z As shown in Figure 1-3, Router A connects to the multicast source through Ethernet 1/1 and to
Switch A through Ethernet 1/0.
z IGMPv2 is required on Router A, IGMP Snooping version 2 is required on Switch A, and Router A
will act as the IGMP querier on the subnet.
z It is required that the receivers, Host A and Host B, attached to Switch A can receive multicast
traffic addressed to multicast group 224.1.1.1 only.
z It is required that multicast data for group 224.1.1.1 can be forwarded through Ethernet 1/2 and
Ethernet 1/3 of Switch A even if Host A and Host B accidentally, temporarily stop receiving
multicast data.
1-20
Network diagram
Figure 1-3 Network diagram for group policy simulated joining configuration
1) Configure IP addresses
Configure an IP address and subnet mask for each interface as per Figure 1-3. The detailed
configuration steps are omitted.
# Enable IP multicast routing, enable PIM-DM on each interface, and enable IGMP on Ethernet 1/0.
# Enable IGMP Snooping globally.
[SwitchA] igmp-snooping
[SwitchA-igmp-snooping] quit
# Create VLAN 100, assign Ethernet 1/0 through Ethernet 1/3 to this VLAN, and enable IGMP Snooping
and the function of dropping unknown multicast traffic in the VLAN.
[SwitchA] vlan 100
[SwitchA-vlan100] port ethernet 1/0 to ethernet 1/3
[SwitchA-vlan100] igmp-snooping enable
[SwitchA-vlan100] igmp-snooping drop-unknown
1-21
# Configure a multicast group filter so that the hosts in VLAN 100 can join only the multicast group
224.1.1.1.
[SwitchA-acl-basic-2001] rule permit source 224.1.1.1 0
[SwitchA-igmp-snooping] group-policy 2001 vlan 100
# Configure Ethernet 1/2 and Ethernet 1/3 as simulated hosts for multicast group 224.1.1.1.
[SwitchA-Ethernet1/2] igmp-snooping host-join 224.1.1.1 vlan 100
[SwitchA-Ethernet1/3] igmp-snooping host-join 224.1.1.1 vlan 100
# View the detailed IGMP Snooping multicast groups information in VLAN 100 on Switch A.
[SwitchA] display igmp-snooping group vlan 100 verbose
Total 1 IP Group(s).
Total 1 IP Source(s).
Total 1 MAC Group(s).
Port flags: D-Dynamic port, S-Static port, C-Copy port

Subvlan flags: R-Real VLAN, C-Copy VLAN
Vlan(id):100.
Router port(s):total 1 port.
Eth1/0 (D) ( 00:01:30 )
IP group(s):the following ip group(s) match to one mac group.
IP group address:224.1.1.1
(0.0.0.0, 224.1.1.1):
Attribute: Host Port
Host port(s):total 2 port.
Eth1/2 (D) ( 00:03:23 )
Eth1/3 (D) ( 00:04:10 )
MAC group(s):
MAC group address:0100-5e01-0101
Eth1/2
Eth1/3
As shown above, Ethernet 1/2 and Ethernet 1/3 of Switch A has joined multicast group 224.1.1.1.
1-22
Static Router Port Configuration
z As shown in Figure 1-4, Router A connects to a multicast source (Source) through Ethernet 1/1,
and to Switch A through Ethernet 1/0.
z IGMPv2 is to run on Router A, and IGMPv2 Snooping is to run on Switch A, Switch B and Switch C,
with Router A acting as the IGMP querier.
z Suppose STP runs on the network. To avoid data loops, the forwarding path from Switch A to
Switch C is blocked under normal conditions, and multicast traffic flows to the receivers, Host A and
Host C, attached to Switch C only along the path of Switch ASwitch BSwitch C.
z Now it is required to configure Ethernet 1/2 that connects Switch A to Switch C as a static router
port, so that multicast traffic can flow to the receivers nearly uninterruptedly along the path of
Switch ASwitch C in the case that the path of Switch ASwitch BSwitch C gets blocked.
If no static router port is configured, when the path of Switch ASwitch BSwitch C gets blocked, at
least one IGMP query-response cycle must be completed before the multicast data can flow to the
receivers along the new path of Switch ASwitch C, namely multicast delivery will be interrupted during
this process.
For details about the Spanning Tree Protocol (STP), refer to MSTP Configuration in the Access
Volume.
Network diagram
Figure 1-4 Network diagram for static router port configuration
Source
Switch A
Eth1/1 Eth1/0
1.1.1.2/24 10.1.1.1/24 Eth1/0
1/2
Eth
Router A
Eth
1.1.1.1/24
1/1
IGMP querier
1/0
Eth
Switch C
Eth
1/0

1/3
Eth
Host C Switch B
Eth
1/2
Receiver
Host B Host A
Receiver
1-23
1) Configure IP addresses
Configure an IP address and subnet mask for each interface as per Figure 1-4. The detailed
configuration steps are omitted.
# Enable IP multicast routing, enable PIM-DM on each interface, and enable IGMP on Ethernet 1/0.
in the VLAN.
[SwitchA] vlan 100
# Configure Ethernet 1/2 to be a static router port.

[SwitchA-Ethernet1/2] igmp-snooping static-router-port vlan 100
[SwitchB] igmp-snooping
[SwitchB-igmp-snooping] quit
# Create VLAN 100, assign Ethernet 1/0 and Ethernet 1/1 to this VLAN, and enable IGMP Snooping in
the VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port ethernet 1/0 ethernet 1/1
[SwitchB-vlan100] igmp-snooping enable
1-24
[SwitchC] igmp-snooping
[SwitchC-igmp-snooping] quit
in the VLAN.
[SwitchC] vlan 100
[SwitchC-vlan100] port ethernet 1/0 to ethernet 1/4
[SwitchC-vlan100] igmp-snooping enable
[SwitchC-vlan100] quit
# View the detailed IGMP Snooping multicast group information in VLAN 100 on Switch A.
[SwitchA] display igmp-snooping group vlan 100 verbose

Vlan(id):100.
Eth1/0 (D) ( 00:01:30 )
Eth1/2 (S)
IP group address:224.1.1.1
(0.0.0.0, 224.1.1.1):
Eth1/1 (D) ( 00:03:23 )
MAC group(s):
MAC group address:0100-5e01-0101
Eth1/1
As shown above, Ethernet 1/2 of Switch A has become a static router port.
IGMP Snooping Querier Configuration
z As shown in Figure 1-5, in a Layer 2only network environment, Switch C is connected to the
multicast source (Source) through Ethernet 1/2. At least one receiver is attached to Switch B and
Switch C respectively.
z IGMPv2 is enabled on all the receivers. Switch A, Switch B, and Switch C run IGMPv2 Snooping.
Switch A acts as the IGMP-Snooping querier.
z Configure a non-all-zero IP address as the source IP address of IGMP queries to ensure normal
creation of multicast forwarding entries.
1-25
Network diagram
Figure 1-5 Network diagram for IGMP Snooping querier configuration
1) Configure switch A
# Create VLAN 100 and add Ethernet 1/0 and Ethernet 1/1 to VLAN 100.
[SwitchA] vlan 100
[SwitchA-vlan100] port ethernet 1/0 ethernet 1/1
# Enable IGMP Snooping in VLAN 100 and configure the IGMP-Snooping querier feature.
[SwitchA-vlan100] igmp-snooping querier
# Set the source IP address of IGMP general queries and group-specific queries to 192.168.1.1.
[SwitchA-vlan100] igmp-snooping general-query source-ip 192.168.1.1
[SwitchA-vlan100] igmp-snooping special-query source-ip 192.168.1.1
[SwitchB] igmp-snooping
[SwitchB-igmp-snooping] quit
# Create VLAN 100, add Ethernet 1/0 through Ethernet 1/2 to VLAN 100, and enable IGMP Snooping in
this VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port ethernet 1/0 to ethernet 1/2
[SwitchB-vlan100] igmp-snooping enable
3) Configuration on Switch C
1-26
[SwitchC] igmp-snooping
[SwitchC-igmp-snooping] quit
# Create VLAN 100, add Ethernet 1/0 through Ethernet 1/2 to VLAN 100, and enable IGMP Snooping in
this VLAN.
[SwitchC] vlan 100
[SwitchC-vlan100] igmp-snooping enable
# View the IGMP message statistics on Switch C.
[SwitchC-vlan100] display igmp-snooping statistics
Received IGMP general queries:3.
Received IGMPv1 reports:0.
Received IGMP leaves:0.
Received IGMPv2 specific queries:0.
Sent IGMPv2 specific queries:0.
Received IGMPv3 reports with right and wrong records:0.
Received IGMPv3 specific queries:0.
Received IGMPv3 specific sg queries:0.
Sent IGMPv3 specific queries:0.
Sent IGMPv3 specific sg queries:0.
Received error IGMP messages:0.
Switch C received IGMP general queries. This means that Switch A works as an IGMP-Snooping
querier.
Troubleshooting IGMP Snooping Configuration

Switch Fails in Layer 2 Multicast Forwarding
Symptom
A switch fails to implement Layer 2 multicast forwarding.
Analysis
IGMP Snooping is not enabled.
Solution
1) Enter the display current-configuration command to view the running status of IGMP Snooping.
2) If IGMP Snooping is not enabled, use the igmp-snooping command to enable IGMP Snooping
globally, and then use igmp-snooping enable command to enable IGMP Snooping in VLAN view.
3) If IGMP Snooping is disabled only for the corresponding VLAN, just use the igmp-snooping
enable command in VLAN view to enable IGMP Snooping in the corresponding VLAN.
1-27
Configured Multicast Group Policy Fails to Take Effect
Symptom
Although a multicast group policy has been configured to allow hosts to join specific multicast groups,
the hosts can still receive multicast data addressed to other multicast groups.
Analysis
z The ACL rule is incorrectly configured.

z The multicast group policy is not correctly applied.
z The function of dropping unknown multicast data is not enabled, so unknown multicast data is
flooded.
z Certain ports have been configured as static member ports of multicasts groups, and this
configuration conflicts with the configured multicast group policy.
Solution
1) Use the display acl command to check the configured ACL rule. Make sure that the ACL rule
conforms to the multicast group policy to be implemented.
2) Use the display this command in IGMP Snooping view or in the corresponding interface view to
check whether the correct multicast group policy has been applied. If not, use the group-policy or
igmp-snooping group-policy command to apply the correct multicast group policy.
3) Use the display current-configuration command to check whether the function of dropping
unknown multicast data is enabled. If not, use the drop-unknown or igmp-snooping
drop-unknown command to enable the function of dropping unknown multicast data.
4) Use the display igmp-snooping group command to check whether any port has been configured
as a static member port of any multicast group. If so, check whether this configuration conflicts with
the configured multicast group policy. If any conflict exists, remove the port as a static member of
the multicast group.
1-28
Table of Contents
1 IGMP Configuration 1-1

IGMP Overview 1-1
IGMP Versions 1-1
Introduction to IGMPv11-2
Enhancements in IGMPv21-3
Enhancements in IGMPv31-4
Introduction to IGMP SSM Mapping1-6
Multi-Instance IGMP 1-7
IGMP Configuration Task List 1-7
Configuring Basic Functions of IGMP 1-8
Enabling IGMP 1-8
Configuring IGMP Versions1-9
Configuring Static Joining1-10
Configuring a Multicast Group Filter1-10
Adjusting IGMP Performance 1-11
Configuring IGMP Message Options1-11
Configuring IGMP Query and Response Parameters 1-12
Configuring IGMP Fast Leave Processing 1-15
Configuring IGMP SSM Mapping1-16
Enabling SSM Mapping 1-16
Configuring SSM Mappings1-16
Displaying and Maintaining IGMP1-17
IGMP Configuration Examples (On Routers)1-18
Basic IGMP Functions Configuration Example 1-18
SSM Mapping Configuration Example 1-20
IGMP Configuration Examples (On Switches)1-24
Basic IGMP Functions Configuration Example 1-24
SSM Mapping Configuration Example 1-26
Troubleshooting IGMP 1-29
No Membership Information on the Receiver-Side Router 1-29
Inconsistent Memberships on Routers on the Same Subnet 1-29
i

Source filtering modes
Yes Yes Yes Yes
(Include/Exclude)
1 IGMP Configuration
When configuring IGMP, go to the following sections for the information you are interested in:
z IGMP Overview
z IGMP Configuration Task List
z IGMP Configuration Examples (On Routers)
z IGMP Configuration Examples (On Switches)
z Troubleshooting IGMP
z The term "router" in this document refers to a router in a generic sense or a Layer 3 switch running
an IP routing protocol.
IGMP Overview
As a TCP/IP protocol responsible for IP multicast group member management, the Internet Group
Management Protocol (IGMP) is used by IP hosts to establish and maintain their multicast group
memberships to immediately neighboring multicast routers.
IGMP Versions
So far, there are three IGMP versions:

z IGMPv1 (documented in RFC 1112)
1-1
All IGMP versions support the Any-Source Multicast (ASM) model. In addition to support of the ASM
model, IGMPv3 can be directly deployed to implement the Source-Specific Multicast (SSM) model,
while IGMPv1 and IGMPv2 need to work with the IGMP SSM mapping function to implement the SSM
model.
For more information about the ASM and SSM models, see Multicast Overview of the IP Multicast
Volume.
Introduction to IGMPv1
IGMPv1 manages multicast group memberships mainly based on the query and response mechanism.
Of multiple multicast routers on the same subnet, all the routers can hear IGMP membership report
messages (often referred to as reports) from hosts, but only one router is needed for sending IGMP
query messages (often referred to as queries). So, a querier election mechanism is required to
determine which router will act as the IGMP querier on the subnet.
In IGMPv1, the designated router (DR) elected by the working multicast routing protocol (such as PIM)
serves as the IGMP querier.
For more information about DR, refer to PIM Configuration in the IP Multicast Volume.
Figure 1-1 IGMP queries and reports
IP network
DR
Router A Router B
Ethernet

(G2) (G1) (G1)
Query
Report
Assume that Host B and Host C are expected to receive multicast data addressed to multicast group G1,
while Host A is expected to receive multicast data addressed to G2, as shown in Figure 1-1. The
1-2
following describes how the hosts join the multicast groups and the IGMP querier (Router B in the figure)
maintains the multicast group memberships:
1) The hosts send unsolicited IGMP reports to the addresses of the multicast groups that they want to
join, without having to wait for the IGMP queries from the IGMP querier.
2) The IGMP querier periodically multicasts IGMP queries (with the destination address of 224.0.0.1)
to all hosts and routers on the local subnet.
3) Upon receiving a query message, Host B or Host C (the delay timer of whichever expires first)
sends an IGMP report to the multicast group address of G1, to announce its membership for G1.
Assume it is Host B that sends the report message. Upon hearing the report from Host B, Host C,
which is on the same subnet with Host B, suppresses its own report for G1, because the IGMP
routers (Router A and Router B) already know that at least one host on the local subnet is
interested in G1. This mechanism, known as IGMP report suppression, helps reduce traffic on the
local subnet.
4) At the same time, because Host A is interested in G2, it sends a report to the multicast group
address of G2.
5) Through the above-mentioned query/report process, the IGMP routers learn that members of G1
and G2 are attached to the local subnet, and the multicast routing protocol (PIM for example)
running on the routers generates (*, G1) and (*, G2) multicast forwarding entries, which will be the
basis for subsequent multicast forwarding, where * represents any multicast source.
6) When the multicast data addressed to G1 or G2 reaches an IGMP router, because the (*, G1) and
(*, G2) multicast forwarding entries exist on the IGMP router, the router forwards the multicast data
to the local subnet, and then the receivers on the subnet receive the data.
As IGMPv1 does not specifically define a Leave Group message, upon leaving a multicast group, an
IGMPv1 host stops sending reports to the address of the multicast group it listened to. If no member of
a multicast group exists on the subnet, the IGMP router will not receive any report addressed to that
multicast group, so the routers will delete the multicast forwarding entries for that multicast group after a
period of time.
Enhancements in IGMPv2
Compared with IGMPv1, IGMPv2 has introduced a querier election mechanism and a leave-group
mechanism.
Querier election mechanism
In IGMPv1, the DR elected by the Layer 3 multicast routing protocol (such as PIM) serves as the querier
among multiple routers on the same subnet.
In IGMPv2, an independent querier election mechanism is introduced. The querier election process is
as follows:
1) Initially, every IGMPv2 router assumes itself as the querier and sends IGMP general query
messages (often referred to as general queries) to all hosts and routers on the local subnet (the
destination address is 224.0.0.1).
2) Upon hearing a general query, every IGMPv2 router compares the source IP address of the query
message with its own interface address. After comparison, the router with the lowest IP address
wins the querier election and all other IGMPv2 routers become non-queriers.
3) All the non-queriers start a timer, known as other querier present timer. If a router receives an
IGMP query from the querier before the timer expires, it resets this timer; otherwise, it assumes the
querier to have timed out and initiates a new querier election process.
1-3
Leave group mechanism
In IGMPv1, when a host leaves a multicast group, it does not send any notification to the multicast
router. The multicast router relies on host response timeout to know whether a group no longer has
members. This adds to the leave latency.
In IGMPv2, on the other hand, when a host leaves a multicast group:
1) This host sends a Leave Group message (often referred to as leave message) to all routers (the
destination address is 224.0.0.2) on the local subnet.
2) Upon receiving the leave message, the querier sends a configurable number of group-specific
queries to the group being left. The destination address field and group address field of the
message are both filled with the address of the multicast group being queried.
3) One of the remaining members, if any on the subnet, of the group being queried should send a
membership report within the maximum response time set in the query messages.
4) If the querier receives a membership report for the group within the maximum response time, it will
maintain the memberships of the group; otherwise, the querier will assume that no hosts on the
subnet are still interested in multicast traffic to that group and will stop maintaining the
memberships of the group.
Enhancements in IGMPv3
The support for the Exclude mode varies with device models.
Built upon and being compatible with IGMPv1 and IGMPv2, IGMPv3 provides hosts with enhanced
control capabilities and provides enhancements of query and report messages.
Enhancements in control capability of hosts
IGMPv3 has introduced source filtering modes (Include and Exclude), so that a host not only can join a
designated multicast group but also can specify to receive or reject multicast data from a designated
multicast source. When a host joins a multicast group:
z If it needs to receive multicast data from specific sources like S1, S2, , it sends a report with the
Filter-Mode denoted as Include Sources (S1, S2, ).
z If it needs to reject multicast data from specific sources like S1, S2, , it sends a report with the
Filter-Mode denoted as Exclude Sources (S1, S2, ).
As shown in Figure 1-2, the network comprises two multicast sources, Source 1 (S1) and Source 2 (S2),
both of which can send multicast data to multicast group G. Host B is interested only in the multicast
data that Source 1 sends to G but not in the data from Source 2.
1-4
Figure 1-2 Flow paths of source-and-group-specific multicast traffic
Source 1
Host A
Receiver
Host B
Source 2
Host C
Packets (S1,G)
Packets (S2,G)
In the case of IGMPv1 or IGMPv2, Host B cannot select multicast sources when it joins multicast group
G. Therefore, multicast streams from both Source 1 and Source 2 will flow to Host B whether it needs
them or not.
When IGMPv3 is running between the hosts and routers, Host B can explicitly express its interest in the
multicast data Source 1 sends to multicast group G (denoted as (S1, G)), rather than the multicast data
Source 2 sends to multicast group G (denoted as (S2, G)). Thus, only multicast data from Source 1 will
be delivered to Host B.
Enhancements in query and report capabilities
1) Query message carrying the source addresses

IGMPv3 supports not only general queries (feature of IGMPv1) and group-specific queries (feature of
IGMPv2), but also group-and-source-specific queries.
z A general query does not carry a group address, nor a source address;
z A group-specific query carries a group address, but no source address;
z A group-and-source-specific query carries a group address and one or more source addresses.
2) Reports containing multiple group records
Unlike an IGMPv1 or IGMPv2 report message, an IGMPv3 report message is destined to 224.0.0.22
and contains one or more group records. Each group record contains a multicast group address and a
multicast source address list.
Group record types include:
z IS_IN: The source filtering mode is Include, namely, the report sender requests the multicast data
from only the sources defined in the specified multicast source list. If the specified multicast source
list is empty, this means that the report sender has left the reported multicast group.
z IS_EX: The source filtering mode is Exclude, namely, the report sender requests the multicast data
from any sources but those defined in the specified multicast source list.
z TO_IN: The filtering mode has changed from Exclude to Include.
z TO_EX: The filtering mode has changed from Include to Exclude.
z ALLOW: The Source Address fields in this Group Record contain a list of the additional sources
that the system wishes to hear from, for packets sent to the specified multicast address. If the
change was to an Include source list, these are the addresses that were added to the list; if the
change was to an Exclude source list, these are the addresses that were deleted from the list.
1-5
z BLOCK: indicates that the Source Address fields in this Group Record contain a list of the sources
that the system no longer wishes to hear from, for packets sent to the specified multicast address.
If the change was to an Include source list, these are the addresses that were deleted from the list;
if the change was to an Exclude source list, these are the addresses that were added to the list.
Introduction to IGMP SSM Mapping
The IGMP SSM mapping feature allows you to configure static IGMP SSM mappings on the last hop
router to provide SSM support for receiver hosts running IGMPv1 or IGMPv2. The SSM model assumes
that the last hop router is aware of the desired multicast sources when receivers join multicast groups.
z When a host running IGMPv3 joins a multicast group, it can explicitly specify one or more multicast
sources in its IGMPv3 report.
z A host running IGMPv1 or IGMPv2, however, cannot specify multicast source addresses in its
report. In this case, you need to configure the IGMP SSM mapping feature to translate the (*, G)
information in the IGMPv1 or IGMPv2 report into (G, INCLUDE, (S1, S2...)) information.
Figure 1-3 Network diagram for IGMP SSM mapping
SSM
IGMPv1 report
IGMPv2 report
Querier
IGMPv3 report
Router A
Receiver Receiver Receiver

Host A (IGMPv1) Host B (IGMPv2) Host C (IGMPv3)
As shown in Figure 1-3, on an SSM network, Host A, Host B and Host C are running IGMPv1, IGMPv2
and IGMPv3 respectively. To provide SSM service for all the hosts while it is infeasible to run IGMPv3 on
Host A and Host B, you need to configure the IGMP SSM mapping feature on Router A.
With the IGMP SSM mapping feature configured, when Router A receives an IGMPv1 or IGMPv2 report,
it checks the multicast group address G carried in the message:
z If G is not in the SSM group range, Router A cannot provide the SSM service but the ASM service.
z If G is in the SSM group range but no IGMP SSM mappings corresponding to the multicast group G
have been configured on Router A, Router A cannot provide SSM service and drops the message.
z If G is in the SSM group range and the IGMP SSM mappings have been configured on Router A for
multicast group G, Router A translates the (*, G) information in the IGMP report into (G, INCLUDE,
(S1, S2...)) information based on the configured IGMP SSM mappings and provides SSM service
accordingly.
1-6
z The IGMP SSM mapping feature does not process IGMPv3 reports.
z For more information about the SSM group range, refer to PIM Configuration in the IP Multicast
Volume.
Multi-Instance IGMP
While IGMP maintains group memberships on a per-interface base, IGMP in a VPN instance handles
protocol packets based on the VPN instance on the interface. Upon receiving an IGMP packet, the
router determines the instance to which the message belongs and handles the message within the
instance. If the IGMP of a VPN instance needs to exchange information with another multicast protocol,
the router informs the other multicast protocol only within the VPN instance.
The following documents describe different IGMP versions:

z RFC 1112: Host Extensions for IP Multicasting
z RFC 2236: Internet Group Management Protocol, Version 2
z RFC 3376: Internet Group Management Protocol, Version 3
IGMP Configuration Task List

Complete these tasks to configure IGMP:
Task Remarks
Enabling IGMP Required
Configuring Basic Functions Configuring IGMP Versions Optional

of IGMP Configuring Static Joining Optional
Configuring a Multicast Group Filter Optional
Configuring IGMP Message Options Optional
Adjusting IGMP Performance Configuring IGMP Query and Response Parameters Optional
Configuring IGMP Fast Leave Processing Optional
Configuring IGMP SSM Enabling SSM Mapping Optional

Mapping Configuring SSM Mappings Optional
1-7
z Configurations performed in IGMP view are effective on all interfaces, while configurations
performed in interface view are effective on the current interface only.
z If a feature is not configured for an interface in interface view, the global configuration performed in
IGMP view will apply to that interface. If a feature is configured in both IGMP view and interface
view, the configuration performed in interface view will be given priority.
Configuring Basic Functions of IGMP

Before configuring the basic functions of IGMP, complete the following tasks:
z Configure any unicast routing protocol so that all devices in the domain are interoperable at the
network layer.
z Configure PIM-DM or PIM-SM
Before configuring the basic functions of IGMP, prepare the following data:
z IGMP version
z Multicast group and multicast source addresses for static group member configuration
z ACL rule for multicast group filtering
Enabling IGMP
First, IGMP must be enabled on the interface on which the multicast group memberships are to be
established and maintained.
Enabling IGMP in the public instance
Follow these steps to enable IGMP in the public instance:

Required
Disabled by default
interface-number
Required
Enable IGMP igmp enable
Disabled by default
1-8
Enabling IGMP in a VPN instance
Follow these steps to enable IGMP in a VPN instance:


Configure an RD for the VPN route-distinguisher Required

instance route-distinguisher No RD is configured by default.
Required
Disabled by default
interface-number
Required
Enable IGMP igmp enable
Disabled by default
z For details about the ip vpn-instance and route-distinguisher commands, see MPLS L3VPN
z For details about the multicast routing-table command, see Multicast Routing and Forwarding
Configuring IGMP Versions
Because the protocol packets of different IGMP versions vary in structure and type, the same IGMP
version should be configured for all routers on the same subnet before IGMP can work properly.
Configuring an IGMP version globally
Follow these steps to configure an IGMP version globally:

Enter public instance IGMP
igmp [ vpn-instance
view or VPN instance IGMP
vpn-instance-name ]
view
Configure an IGMP version Optional

version version-number
globally IGMPv2 by default
Configuring an IGMP version on an interface
Follow these steps to configure an IGMP version on an interface:
1-9
interface-number
Configure an IGMP version on Optional

igmp version version-number
the interface IGMPv2 by default
Configuring Static Joining
After an interface is configured as a static member of a multicast group or a multicast source and group,
it will act as a virtual member of the multicast group to receive multicast data addressed to that multicast
group for the purpose of testing multicast data forwarding.
Follow these steps to configure an interface as a statically connected member of a multicast group or a
multicast source and group:

interface-number
Configure the interface as a Required

igmp static-group
static member of a multicast An interface is not a static member
group-address [ source
group or a multicast source and of any multicast group or multicast
source-address ]
group source and group by default.
z Before you can configure an interface of a PIM-SM device as a static member of a multicast group
or a multicast source and group, if the interface is PIM-SM enabled, it must be a PIM-SM DR; if this
interface is IGMP enabled but not PIM-SM enabled, it must be an IGMP querier. For more
information about PIM-SM and a DR, refer to PIM Configuration in the IP Multicast Volume.
z As a static member of a multicast group or a multicast source and group, the interface does not
respond to the queries from the IGMP querier, nor does it send an unsolicited IGMP membership
report or an IGMP leave group message when it joins or leaves a multicast group or a multicast
source and group. In other words, the interface will not become a real member of the multicast
group or the multicast source and group.
Configuring a Multicast Group Filter
To restrict the hosts on the network attached to an interface from joining certain multicast groups, you
can set an ACL rule on the interface as a packet filter that limits the range of multicast groups the
interface serves.
Follow these steps to configure a multicast group filter:
1-10
interface-number
Required
Configure a multicast group igmp group-policy
filter acl-number [ version-number ] No multicast group filter
configured by default
Adjusting IGMP Performance
For the configuration tasks described in this section:

z Configurations performed in IGMP view are effective on all interfaces, while configurations
performed in interface view are effective on the current interface only.
z If the same feature is configured in both IGMP view and interface view, the configuration performed
in interface view is given priority, regardless of the configuration sequence.
Before adjusting IGMP performance, complete the following tasks:

network layer.
z Configure basic functions of IGMP
Before adjusting IGMP performance, prepare the following data:
z Startup query interval
z Startup query count
z IGMP general query interval
z IGMP queriers robustness variable
z Maximum response time for IGMP general queries
z IGMP last-member query interval
z Other querier present interval
Configuring IGMP Message Options
IGMP queries include group-specific queries and group-and-source-specific queries, and multicast
groups change dynamically, so a device cannot maintain the information for all multicast sources and
groups, For this reason, when receiving a multicast packet but unable to locate the outgoing interface
for the destination multicast group, an IGMP router needs to leverage the Router-Alert option to pass
the multicast packet to the upper-layer protocol for processing. For details about the Router-Alert option,
refer to RFC 2113.
An IGMP message is processed differently depending on whether it carries the Router-Alert option in
the IP header:
1-11
z By default, for the consideration of compatibility, the device does not check the Router-Alert option,
namely it processes all the IGMP messages it received. In this case, IGMP messages are directly
passed to the upper layer protocol, no matter whether the IGMP messages carry the Router-Alert
option or not.
z To enhance the device performance and avoid unnecessary costs, and also for the consideration
of protocol security, you can configure the device to discard IGMP messages that do not carry the
Router-Alert option.
Configuring IGMP packet options globally
Follow these steps to configure IGMP packet options globally:

Enter public instance IGMP view or igmp [ vpn-instance

VPN instance IGMP view vpn-instance-name ]
Configure the router to discard any Optional

IGMP message that does not carry require-router-alert By default, the device does not
the Router-Alert option check the Router-Alert option.
Optional
Enable insertion of the Router-Alert
send-router-alert By default, IGMP messages
option into IGMP messages
carry the Router-Alert option.
Configuring IGMP packet options on an interface
Follow these steps to configure IGMP packet options on an interface:

interface-number
Configure the interface to discard Optional

any IGMP message that does not igmp require-router-alert By default, the device does not
carry the Router-Alert option check the Router-Alert option.
Enable insertion of the Optional

Router-Alert option into IGMP igmp send-router-alert By default, IGMP messages
messages carry the Router-Alert option.
Configuring IGMP Query and Response Parameters
On startup, the IGMP querier sends startup query count IGMP general queries at the startup query
interval, which is 1/4 of the IGMP query interval.
The IGMP querier periodically sends IGMP general queries at the IGMP query interval to determine
whether any multicast group member exists on the network. You can tune the IGMP general query
interval based on actual condition of the network.
Upon receiving an IGMP leave message, the IGMP querier sends last member query count IGMP
group-specific queries at the IGMP last member query interval. IGMP is robust to robustness variable
1-12
minus 1 packet losses on a network. Therefore, a greater value of the robustness variable makes the
IGMP querier more robust, but results in a longer multicast group timeout time.
Upon receiving an IGMP query (general query or group-specific query), a host starts a delay timer for
each multicast group it has joined. This timer is initialized to a random value in the range of 0 to the
maximum response time, which is derived from the Max Response Time field in the IGMP query. When
the timer value comes down to 0, the host sends an IGMP report to the corresponding multicast group.
An appropriate setting of the maximum response time for IGMP queries allows hosts to respond to
queries quickly and avoids bursts of IGMP traffic on the network caused by reports simultaneously sent
by a large number of hosts when the corresponding timers expires simultaneously.
z For IGMP general queries, you can configure the maximum response time to fill their Max
z For IGMP group-specific queries, you can configure the IGMP last member query interval to fill
their Max Response time field. Namely, for IGMP group-specific queries, the maximum response
time equals the IGMP last member query interval.
When multiple multicast routers exist on the same subnet, the IGMP querier is responsible for sending
IGMP queries. If a non-querier router receives no IGMP query from the querier within the other querier
present interval, it will assume the querier to have expired and a new querier election process is
launched; otherwise, the non-querier router will reset its other querier present timer.
Configuring IGMP query and response parameters globally
Follow these steps to configure IGMP query and response parameters globally:

Enter public instance IGMP

igmp [ vpn-instance
view or VPN instance IGMP
vpn-instance-name ]
view
Optional
Configure the startup query
startup-query-interval interval For the system default, see
interval
Note below.
Optional
startup-query-count value For the system default, see
count
Note below.
Configure the IGMP query Optional

timer query interval
Configure the IGMP querier Optional

robust-count robust-value
robustness variable 2 by default
response time for IGMP max-response-time interval
general queries 10 seconds by default
Configure the IGMP last last-member-query-interval Optional

member query interval interval 1 second by default
Optional
Configure the other querier timer other-querier-present
present interval interval For the system default, see
Note below.
1-13
Configuring IGMP query and response parameters on an interface
Follow these steps to configure IGMP query and response parameters on an interface:

interface-number
Optional
Configure the startup query igmp startup-query-interval
interval interval For the system default, see
Note below.
Optional
Configure the startup query igmp startup-query-count
count value For the system default, see
Note below.
Configure the IGMP query Optional

igmp timer query interval
Configure the IGMP querier igmp robust-count Optional

robustness variable robust-value 2 by default
igmp max-response-time
response time for IGMP
general queries
igmp Optional
Configure the IGMP last
last-member-query-interval
member query interval 1 second by default
interval
Optional
Configure the other querier igmp timer
present interval other-querier-present interval For the system default, see
Note below.
z If not statically configured, the startup query interval is 1/4 of the IGMP query interval. By default,
the IGMP query interval is 60 seconds, so the startup query interval = 60 / 4 = 15 (seconds).
z If not statically configured, the startup query count is set to the IGMP querier robustness variable.
By default, the IGMP querier robustness variable is 2, so the startup query count is also 2.
z If not statically configured, the other querier present interval is [ IGMP query interval ] times [ IGMP
robustness variable ] plus [ maximum response time for IGMP general queries ] divided by two. The
default values of these three parameters are 60 (seconds), 2 and 10 (seconds) respectively, so the
other querier present interval = 60 2 + 10 / 2 = 125 (seconds).
z If statically configured, the startup query interval, the startup query count, and the other querier
present interval take the configured values.
1-14
z Make sure that the other querier present interval is greater than the IGMP query interval; otherwise
the IGMP querier may change frequently on the network.
z Make sure that the IGMP query interval is greater than the maximum response time for IGMP
general queries; otherwise, multicast group members may be wrongly removed.
z The configurations of the maximum response time for IGMP general queries, the IGMP last
member query interval and the IGMP other querier present interval are effective only for IGMPv2 or
IGMPv3.
Configuring IGMP Fast Leave Processing
In some applications, such as ADSL dial-up networking, only one multicast receiver host is attached to
a port of the IGMP querier. To allow fast response to the leave messages of the host when it switches
frequently from one multicast group to another, you can enable IGMP fast leave processing on the
IGMP querier.
With fast leave processing enabled, after receiving an IGMP leave message from a host, the IGMP
querier directly sends a leave notification to the upstream without sending IGMP group-specific queries.
Thus, the leave latency is reduced on one hand, and the network bandwidth is saved on the other hand.
Configuring IGMP fast leave processing globally
Follow these steps to configure IGMP fast leave processing globally:

Enter public instance IGMP view or igmp [ vpn-instance

VPN instance IGMP view vpn-instance-name ]
Configure IGMP fast leave fast-leave [ group-policy Required

processing acl-number ] Disabled by default
Configuring IGMP fast leave processing on an interface
Follow these steps to configure IGMP fast leave processing on an interface:

interface-number
Configure IGMP fast leave igmp fast-leave Required

processing [ group-policy acl-number ] Disabled by default
1-15
The IGMP fast leave processing configuration is effective only if the device is running IGMPv2 or
IGMPv3.
Configuring IGMP SSM Mapping

Due to some possible restrictions, some receiver hosts on an SSM network may run IGMPv1 or
IGMPv2. To provide SSM service support for these receiver hosts, you need to configure the IGMP
mapping feature on the last hop router.
Before configuring the IGMP SSM mapping feature, complete the following tasks:
network layer.
z Configure basic functions of IGMP.
Enabling SSM Mapping
Follow these steps to enable the IGMP SSM mapping feature:

interface-number
Enable the IGMP SSM Required

mapping feature igmp ssm-mapping enable
Disabled by default
To ensure SSM service for all hosts on a subnet, regardless of the IGMP version running on the hosts,
enable IGMPv3 on the interface that forwards multicast traffic onto the subnet.
Configuring SSM Mappings
By performing this configuration multiple times, you can map a multicast group to different multicast
sources.
1-16
Follow these steps to configure an IGMP SSM mapping:

Enter public instance or VPN igmp [ vpn-instance

instance IGMP view vpn-instance-name ]
ssm-mapping group-address Required

Configure an IGMP SSM
{ mask | mask-length } No IGMP mappings are
mapping
source-address configured by default.
If IGMPv3 is enabled on a VLAN interface of a switch that supports both IGMP Snooping and IGMP,
and if a port in that VLAN is configured as a simulated host, the simulated host will send IGMPv3 reports
even if you did not specify a multicast source when configuring simulated joining with the
igmp-snooping host-join command. In this case, the corresponding multicast group will not be
created based on the configured IGMP SSM mappings. For details about the igmp-snooping
host-join command, refer to IGMP Snooping Commands in the IP Multicast Volume.
Displaying and Maintaining IGMP

To do... Use the command...
display igmp [ vpn-instance
View IGMP multicast group vpn-instance-name | all-instance ] group Available in
information [ group-address | interface interface-type any view
interface-number ] [ static | verbose ]
View layer 2 port On a centralized display igmp group port-info [ vlan Available in
information device vlan-id ] [ verbose ] any view
about IGMP On a distributed display igmp group port-info [ vlan Available in
multicast groups device vlan-id ] [ slot slot-number ] [ verbose ] any view
View IGMP configuration and vpn-instance-name | all-instance ] Available in
operation information interface [ interface-type any view
interface-number ] [ verbose ]
View information in the IGMP routing Available in
routing-table [ source-address [ mask
table any view
{ mask | mask-length } ] | group-address
[ mask { mask | mask-length } ] ] *
Available in
View IGMP mappings vpn-instance-name | all-instance ]
any view
ssm-mapping group-address
View the multicast group information
created from IGMPv1 and IGMPv2 Available in
ssm-mapping group [ group-address |
reports based on the configured any view
IGMP SSM mappings
1-17
To do... Use the command...
reset igmp [ vpn-instance
vpn-instance-name | all-instance ] group
{ all | interface interface-type
Clear IGMP multicast group Available in
interface-number { all | group-address
information user view
[ mask { mask | mask-length } ]
[ source-address [ mask { mask |
mask-length } ] ] } }
Clear layer 2 port information about reset igmp group port-info { all | Available in
IGMP multicast groups group-address } [ vlan vlan-id ] user view
reset igmp [ vpn-instance
ssm-mapping group { all | interface
Available in
Clear IGMP SSM mappings interface-type interface-number { all |
user view
group-address [ mask { mask |
mask-length } ] [ source-address [ mask
{ mask | mask-length } ] ] } }
z The reset igmp group command cannot clear the IGMP multicast group information of static joins.
z The reset igmp group port-info command cannot clear Layer 2 port information about IGMP
multicast groups of static joins.
z The support for the display igmp group port-info and reset igmp group port-info commands
depends on the specific product model.
The reset igmp group command may cause an interruption of receivers reception of multicast data.
IGMP Configuration Examples (On Routers)

Basic IGMP Functions Configuration Example
z Receivers receive VOD information through multicast. Receivers of different organizations form
stub networks N1 and N2, and Host A and Host C are receivers in N1 and N2 respectively.
z Router A in the PIM network connects to N1, and both Router B and Router C connect to another
stub network, N2.
z Router A connects to N1 through Ethernet 1/0, and to other devices in the PIM network through
POS 5/0.
z Router B and Router C connect to N2 through their respective Ethernet 1/0, and to other devices in
the PIM domain through their respective POS 5/0.
z IGMPv2 is required between Router A and N1. IGMPv2 is also required between the other two
routers and N2, with Router B as the IGMP querier.
1-18
Network diagram
Figure 1-4 Network diagram for basic IGMP functions configuration (on routers)
Ethernet
Ethernet

Configure the IP address and subnet mask of each interface as per Figure 1-4. The detailed
Configure the OSPF protocol for interoperation on the PIM network. Ensure the network-layer
interoperation on the PIM network and dynamic update of routing information among the routers
through a unicast routing protocol. The detailed configuration steps are omitted here.
# Enable IP multicast routing on Router A, enable PIM-DM on each interface, and enable IGMP on
Ethernet 1/0.
[RouterA-Pos5/0] pim dm
# Enable IP multicast routing on Router B, enable PIM-DM on each interface, and enable IGMP on
Ethernet 1/0.
1-19
[RouterB-Pos5/0] pim dm
[RouterB-Pos5/0] quit
# Enable IP multicast routing on Router C, enable PIM-DM on each interface, and enable IGMP on
Ethernet 1/0.
[RouterC] interface pos 5/0
[RouterC-Pos5/0] pim dm
[RouterC-Pos5/0] quit
Use the display igmp interface command to view the IGMP configuration and operation status on
each router interface. For example:
# View IGMP information on Ethernet 1/0 of Router B.
[RouterB] display igmp interface ethernet 1/0
Ethernet1/0(10.110.2.1):
IGMP is enabled
Current IGMP version is 2
Value of query interval for IGMP(in seconds): 60
Value of other querier present interval for IGMP(in seconds): 125
Value of maximum query response time for IGMP(in seconds): 10
Querier for IGMP: 10.110.2.1 (this router)
Total 1 IGMP Group reported
SSM Mapping Configuration Example
z On a PIM-SSM network shown in Figure 1-5, the receiver host receives VOD information through
multicast. The receiver host runs IGMPv2, so it cannot specify the expected multicast sources in its
membership reports.
z It is required to configure the IGMP SSM mapping feature on Router D so that the receiver host will
receive multicast data from Source 1 and Source 3 only.
1-20
Network diagram
Figure 1-5 Network diagram for IGMP SSM mapping configuration (on routers)

Source 1 133.133.1.1/24 Source 3 133.133.3.1/24
Source 2 133.133.2.1/24 Receiver 133.133.4.1/24
Router A Eth1/0 133.133.1.2/24 Router C Eth1/0 133.133.3.2/24
Eth1/1 192.168.1.1/24 Eth1/1 192.168.3.1/24
Eth1/2 192.168.4.2/24 Eth1/2 192.168.2.2/24
Router B Eth1/0 133.133.2.2/24 Router D Eth1/0 133.133.4.2/24
Eth1/1 192.168.1.2/24 Eth1/1 192.168.3.2/24
Eth1/2 192.168.2.1/24 Eth1/2 192.168.4.1/24

Configure OSPF for interoperability among the routers. Ensure the network-layer interoperation in the
PIM-SSM network and dynamic update of routing information among the routers through a unicast
routing protocol. The detailed configuration steps are omitted here.
2) Enable IP multicast routing, enable PIM-SM on each interface, and enable IGMP and IGMP SSM
mapping on the host-side interface.
# Enable IP multicast routing on Router D, enable PIM-SM on each interface and enable IGMPv3 and
IGMP SSM mapping on Ethernet 1/0.
[RouterD] multicast routing-enable
[RouterD-Ethernet1/0] igmp enable
[RouterD-Ethernet1/0] igmp version 3
[RouterD-Ethernet1/0] igmp ssm-mapping enable
[RouterD-Ethernet1/0] pim sm
1-21
# Enable IP multicast routing on Router A, and enable PIM-SM on each interface.

[RouterA-Ethernet1/0] pim sm
The configuration on Router B and Router C is similar to that on Router A.

3) Configure a C-BSR and a C-RP
# Configure C-BSR and C-RP interfaces on Router D.
[RouterD] pim
[RouterD-pim] c-bsr ethernet 1/2
[RouterD-pim] c-rp ethernet 1/2
[RouterD-pim] quit
4) Configure the SSM group range
# Configure the SSM group range 232.1.1.0/24 on Router D.
[RouterD] acl number 2000
[RouterD-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[RouterD-acl-basic-2000] quit
[RouterD] pim
[RouterD-pim] ssm-policy 2000
[RouterD-pim] quit
The configuration on Router A, Router B and Router C is similar to that on Router D.

5) Configure IGMP SSM mappings
# Configure IGMP SSM mappings on Router D.
[RouterD] igmp
[RouterD-igmp] ssm-mapping 232.1.1.1 24 133.133.1.1
[RouterD-igmp] ssm-mapping 232.1.1.1 24 133.133.3.1
[RouterD-igmp] quit
Use the display igmp ssm-mapping command to view the IGMP SSM mappings on the router.
# View the IGMP SSM mapping information for multicast group 232.1.1.1 in the public instance on
Router D.
[RouterD] display igmp ssm-mapping 232.1.1.1
Vpn-Instance: public net
Group: 232.1.1.1
Source list:
1-22
133.133.1.1
133.133.3.1
Use the display igmp ssm-mapping group command to view the multicast group information created
based on the configured IGMP SSM mappings.
# View the multicast group information created based on the configured IGMP SSM mappings in the
public instance on Router D.
[RouterD] display igmp ssm-mapping group
Total 1 IGMP SSM-mapping Group(s).
Interface group report information of VPN-Instance: public net
Ethernet1/0(133.133.4.2):
Total 1 IGMP SSM-mapping Group reported
Group Address Last Reporter Uptime Expires
232.1.1.1 133.133.4.1 00:02:04 off
Use the display pim routing-table command to view the PIM routing table information on each router.
# View the PIM routing table information in the public instance on Router D.
[RouterD] display pim routing-table
Vpn-instance: public net
Total 0 (*, G) entry; 2 (S, G) entry
(133.133.1.1, 232.1.1.1)
Protocol: pim-ssm, Flag:
UpTime: 00:13:25
Upstream interface: Ethernet1/2
Upstream neighbor: 192.168.4.2
RPF prime neighbor: 192.168.4.2
Downstream interface(s) information:
Total number of downstreams: 1
1: Ethernet1/0
Protocol: igmp, UpTime: 00:13:25, Expires: -
(133.133.3.1, 232.1.1.1)
UpTime: 00:13:25
1: Ethernet1/0
1-23
IGMP Configuration Examples (On Switches)
Basic IGMP Functions Configuration Example
z Receivers receive VOD information through multicast. Receivers of different organizations form
stub networks N1 and N2, and Host A and Host C are receivers in N1 and N2 respectively.
z Switch A in the PIM network connects to N1, and both Switch B and Switch C connect to N2.
z Switch A connects to N1 through VLAN-interface 100, and to other devices in the PIM network
through VLAN-interface 101.
z Switch B and Switch C connect to N2 through their respective VLAN-interface 200, and to other
devices in the PIM network through VLAN-interface 201 and VLAN-interface 202 respectively.
z IGMPv2 is required between Switch A and N1. IGMPv2 is also required between the other two
switches and N2, with Switch B as the IGMP querier.
Network diagram
Figure 1-6 Network diagram for basic IGMP functions configuration (on switches)
Ethernet
Ethernet

Configure the OSPF protocol for interoperation on the PIM network. Ensure the network-layer
interoperation on the PIM network and dynamic update of routing information among the switches
through a unicast routing protocol. The detailed configuration steps are omitted here.
# Enable IP multicast routing on Switch A, enable PIM-DM on each interface, and enable IGMP on
VLAN-interface 100.
1-24
[SwitchA-Vlan-interface100] igmp enable
# Enable IP multicast routing on Switch B, enable PIM-DM on each interface, and enable IGMP on
VLAN-interface 200.
# Enable IP multicast routing on Switch C, enable PIM-DM on each interface, and enable IGMP on
VLAN-interface 200.
Carry out the display igmp interface command to view the IGMP configuration and operation status on
each switch interface. For example:
# View IGMP information on VLAN-interface 200 of Switch B.
[SwitchB] display igmp interface vlan-interface 200
Vlan-interface200(10.110.2.1):
IGMP is enabled
Current IGMP version is 2
Value of query interval for IGMP(in seconds): 60
Value of other querier present interval for IGMP(in seconds): 125
Value of maximum query response time for IGMP(in seconds): 10
Querier for IGMP: 10.110.2.1 (this router)
Total 1 IGMP Group reported
1-25
SSM Mapping Configuration Example
z On the PIM-SSM network shown in Figure 1-7, the receiver host receives VOD information through
multicast. The receiver host runs IGMPv2, so it cannot specify the expected multicast sources in its
membership reports.
z It is required to configure the IGMP SSM mapping feature on Switch D so that the receiver host will
receive multicast data from Source 1 and Source 3 only.
Network diagram
Figure 1-7 Network diagram for IGMP SSM mapping configuration (on switches)

Source 1 133.133.1.1/24 Source 3 133.133.3.1/24
Source 2 133.133.2.1/24 Receiver 133.133.4.1/24
Switch A Vlan-int100 133.133.1.2/24 Switch C Vlan-int300 133.133.3.2/24
Vlan-int101 192.168.1.1/24 Vlan-int103 192.168.3.1/24
Vlan-int104 192.168.4.2/24 Vlan-int102 192.168.2.2/24
Switch B Vlan-int200 133.133.2.2/24 Switch D Vlan-int400 133.133.4.2/24
Vlan-int101 192.168.1.2/24 Vlan-int103 192.168.3.2/24
Vlan-int102 192.168.2.1/24 Vlan-int104 192.168.4.1/24

Configure OSPF for interoperability among the switches. Ensure the network-layer interoperation on
the PIM-SSM network and dynamic update of routing information among the switches through a unicast
routing protocol. The detailed configuration steps are omitted here.
2) Enable IP multicast routing, enable PIM-SM on each interface, and enable IGMP and IGMP SSM
mapping on the host-side interface.
# Enable IP multicast routing on Switch D, enable PIM-SM on each interface, and enable IGMPv3 and
IGMP SSM mapping on VLAN-interface 400.
[SwitchD] multicast routing-enable
1-26
[SwitchD-Vlan-interface400] igmp enable
[SwitchD-Vlan-interface400] igmp version 3
[SwitchD-Vlan-interface400] igmp ssm-mapping enable
[SwitchD-Vlan-interface400] pim sm
# Enable IP multicast routing on Switch A, and enable PIM-SM on each interface.

[SwitchA-Vlan-interface100] pim sm
The configuration on Switch B and Switch C is similar to that on Switch A.

# Configure C-BSR and C-RP interfaces on Switch D.
[SwitchD] pim
[SwitchD-pim] c-bsr vlan-interface 104
[SwitchD-pim] c-rp vlan-interface 104
[SwitchD-pim] quit
# Configure the SSM group range 232.1.1.0/24 on Switch D.
[SwitchD] acl number 2000
[SwitchD-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[SwitchD-acl-basic-2000] quit
[SwitchD] pim
[SwitchD-pim] ssm-policy 2000
[SwitchD-pim] quit
The configuration on Switch A, Switch B and Switch C is similar to that on Switch D.

5) Configure IGMP SSM mappings
# Configure IGMP SSM mappings on Switch D.
[SwitchD] igmp
[SwitchD-igmp] ssm-mapping 232.1.1.1 24 133.133.1.1
[SwitchD-igmp] ssm-mapping 232.1.1.1 24 133.133.3.1
[SwitchD-igmp] quit
1-27
Use the display igmp ssm-mapping command to view the IGMP SSM mappings on the switch.
# View the IGMP SSM mapping information for multicast group 232.1.1.1 on Switch D.
[SwitchD] display igmp ssm-mapping 232.1.1.1
Group address: 232.1.1.1
Source list: 133.133.1.1
133.133.3.1
Use the display igmp ssm-mapping group command to view the multicast group information created
based on the configured IGMP SSM mappings.
# View the IGMP multicast group information created based on the IGMP SSM mappings on Switch D.
[SwitchD] display igmp ssm-mapping group
Total 1 IGMP SSM-mapping Group(s).
Interface group report information of VPN-Instance: public net
Vlan-interface400(133.133.4.2):
Total 1 IGMP SSM-mapping Group reported
Group Address Last Reporter Uptime Expires
232.1.1.1 133.133.4.1 00:02:04 off
Use the display pim routing-table command to view the PIM routing table information on each switch.
# View the PIM routing table information on Switch D.
[SwitchD] display pim routing-table
(133.133.1.1, 232.1.1.1)
UpTime: 00:13:25
Upstream interface: Vlan-interface104
1: Vlan-interface400
(133.133.3.1, 232.1.1.1)
UpTime: 00:13:25
1-28
Troubleshooting IGMP
No Membership Information on the Receiver-Side Router
Symptom
When a host sends a report for joining multicast group G, there is no membership information of the
multicast group G on the router closest to that host.
Analysis
z The correctness of networking and interface connections directly affects the generation of group
membership information.
z Multicast routing must be enabled on the router.
z If the igmp group-policy command has been configured on the interface, the interface cannot
receive report messages that fail to pass filtering.
Solution
1) Check that the networking is correct and interface connections are correct.
2) Check that multicast routing is enabled. Carry out the display current-configuration command to
check whether the multicast routing-enable command has been executed. If not, carry out the
multicast routing-enable command in system view to enable IP multicast routing. In addition,
check that IGMP is enabled on the corresponding interfaces.
3) Check that the interface is in normal state and the correct IP address has been configured. Carry
out the display igmp interface command to view the interface information. If no interface
information is output, this means the interface is abnormal. Typically this is because the shutdown
command has been executed on the interface, or the interface connection is incorrect, or no correct
IP address has been configured on the interface.
4) Check that no ACL rule has been configured to restrict the host from joining the multicast group G.
Carry out the display current-configuration interface command to check whether the igmp
group-policy command has been executed. If the host is restricted from joining the multicast
group G, the ACL rule must be modified to allow receiving the reports for the multicast group G.
Inconsistent Memberships on Routers on the Same Subnet
Symptom
Different memberships are maintained on different IGMP routers on the same subnet.
Analysis
z A router running IGMP maintains multiple parameters for each interface, and these parameters
influence one another, forming very complicated relationships. Inconsistent IGMP interface
parameter configurations for routers on the same subnet will surely result in inconsistency of
memberships.
z In addition, although an IGMP router is compatible with a host that is running a different IGMP
version, all routers on the same subnet must run the same version of IGMP. Inconsistent IGMP
versions running on routers on the same subnet will also lead to inconsistency of IGMP
memberships.
1-29
Solution
1) Check the IGMP configuration. Carry out the display current-configuration command to view the
IGMP configuration information on the interfaces.
2) Carry out the display igmp interface command on all routers on the same subnet to check the
IGMP-related timer settings. Make sure that the settings are consistent on all the routers.
3) Use the display igmp interface command to check whether all the routers on the same subnet are
running the same version of IGMP.
1-30
Table of Contents
1 MSDP Configuration1-1
MSDP Overview1-1
Introduction to MSDP 1-1
How MSDP Works1-2
Multi-Instance MSDP1-8
MSDP Configuration Task List1-8
Configuring Basic Functions of MSDP1-8
Enabling MSDP 1-9
Creating an MSDP Peer Connection1-10
Configuring a Static RPF Peer 1-10
Configuring an MSDP Peer Connection 1-11
Configuring MSDP Peer Description 1-11
Configuring an MSDP Mesh Group1-11
Configuring MSDP Peer Connection Control 1-12
Configuring SA Messages Related Parameters 1-12
Configuring SA Message Content 1-13
Configuring SA Request Messages 1-13
Configuring SA Message Filtering Rules1-14
Configuring the SA Cache Mechanism 1-15
Displaying and Maintaining MSDP1-15
MSDP Configuration Examples (On Routers) 1-16
Inter-AS Multicast Configuration Leveraging BGP Routes1-16
Inter-AS Multicast Configuration Leveraging Static RPF Peers 1-22
Anycast RP Configuration 1-25
SA Message Filtering Configuration1-29
MSDP Configuration Examples (On Switches)1-32
Inter-AS Multicast Configuration Leveraging BGP Routes1-32
Inter-AS Multicast Configuration Leveraging Static RPF Peers 1-38
Anycast RP Configuration 1-41
SA Message Filtering Configuration1-45
Troubleshooting MSDP1-48
MSDP Peers Stay in Down State 1-48
No SA Entries in the Routers SA Cache 1-49
Inter-RP Communication Faults in Anycast RP Application1-49
i

VPN
Yes Yes Yes Yes
multi-instance
1 MSDP Configuration
When configuring MSDP, go to these sections for information you are interested in:
z MSDP Overview
z MSDP Configuration Task List
z Displaying and Maintaining MSDP
z MSDP Configuration Examples (On Routers)
z MSDP Configuration Examples (On Switches)
z Troubleshooting MSDP
z The term router in this document refers to a router in a generic sense or a Layer 3 switch running
the MSDP protocol.
z For details about the concepts of designated router (DR), bootstrap router (BSR), candidate-BSR
(C-BSR), rendezvous point (RP), candidate RP (C-RP), shortest path tree (SPT) and rendezvous
point tree (RPT) mentioned in this manual, refer to PIM Configuration in the IP Multicast Volume.
MSDP Overview
Introduction to MSDP
Multicast source discovery protocol (MSDP) is an inter-domain multicast solution developed to address
the interconnection of protocol independent multicast sparse mode (PIM-SM) domains. It is used to
discover multicast source information in other PIM-SM domains.
1-1
In the basic PIM-SM mode, a multicast source registers only with the RP in the local PIM-SM domain,
and the multicast source information of a domain is isolated from that of another domain. As a result, the
RP is aware of the source information only within the local domain and a multicast distribution tree is
built only within the local domain to deliver multicast data from a local multicast source to local receivers.
If there is a mechanism that allows RPs of different PIM-SM domains to share their multicast source
information, the local RP will be able to join multicast sources in other domains and multicast data can
be transmitted among different domains.
MSDP achieves this goal. With MSDP peer relationships established between appropriate routers in the
network, the RPs of different PIM-SM domains are interconnected with one another. Source active (SA)
messages are exchanged between these MSDP peers and thus the multicast source information is
shared among these different domains.
z MSDP is applicable only if the intra-domain multicast protocol is PIM-SM.

z MSDP is meaningful only for the any-source multicast (ASM) model.
How MSDP Works
MSDP peers
With one or more pairs of MSDP peers configured in the network, an MSDP interconnection map is
formed, where the RPs of different PIM-SM domains are interconnected in series. Relayed by these
MSDP peers, an SA message sent by an RP can be delivered to all other RPs.
Figure 1-1 Where MSDP peers are in the network
As shown in Figure 1-1, an MSDP peer can be created on any PIM-SM router. MSDP peers created on
PIM-SM routers that assume different roles function differently.
1) MSDP peers on RPs
z Source-side MSDP peer: the MSDP peer nearest to the multicast source (Source), typically the
source-side RP, like RP 1. The source-side RP creates SA messages and sends the messages to
its remote MSDP peer to notify the MSDP peer of the locally registered multicast source
1-2
information. A source-side MSDP peer must be created on the source-side RP; otherwise it will not
be able to advertise the multicast source information out of the PIM-SM domain.
z Receiver-side MSDP peer: the MSDP peer nearest to the receivers, typically the receiver-side RP,
like RP 3. Upon receiving an SA message, the receiver-side MSDP peer resolves the multicast
source information carried in the message and joins the SPT rooted at the source across the
PIM-SM domain. When multicast data from the multicast source arrives, the receiver-side MSDP
peer forwards the data to the receivers along the RPT.
z Intermediate MSDP peer: an MSDP peer with multicast remote MSDP peers, like RP 2. An
intermediate MSDP peer forwards SA messages received from one remote MSDP peer to other
remote MSDP peers, functioning as a relay of multicast source information.
2) MSDP peers created on common PIM-SM routers (other than RPs)
Router A and Router B are MSDP peers on common multicast routers. Such MSDP peers just forward
received SA messages.
In a PIM-SM network running the BSR mechanism, the RP is dynamically elected from C-RPs. To
enhance network robustness, a PIM-SM network typically has more than one C-RP. As the RP election
result is unpredictable, MSDP peering relationships should be built among all C-RPs so that the winner
C-RP is always on the "MSDP interconnection map, while loser C-RPs will assume the role of common
PIM-SM routers on the MSDP interconnection map.
Implementing inter-domain multicast delivery by leveraging MSDP peers
As shown in Figure 1-2, an active source (Source) exists in the domain PIM-SM 1, and RP 1 has
learned the existence of Source through multicast source registration. If RPs in PIM-SM 2 and PIM-SM
3 also wish to know the specific location of Source so that receiver hosts can receive multicast traffic
originated from it, MSDP peering relationships should be established between RP 1 and RP 3 and
between RP 3 and RP 2 respectively.
1-3
Figure 1-2 MSDP peering relationships
Receiver
DR 2
MSDP peers
Multicast packets
SA message
Join message RP 2
PIM-SM 2
Register message
DR 1
Source
PIM-SM 4
RP 1 RP 3
PIM-SM 1 PIM-SM 3
The process of implementing inter-domain multicast delivery by leveraging MSDP peers is as follows:
1) When the multicast source in PIM-SM 1 sends the first multicast packet to multicast group G, DR 1
encapsulates the multicast data within a register message and sends the register message to RP 1.
Then, RP 1 gets aware of the information related to the multicast source.
2) As the source-side RP, RP 1 creates SA messages and periodically sends the SA messages to its
MSDP peer. An SA message contains the source address (S), the multicast group address (G),
and the address of the RP which has created this SA message (namely RP 1).
3) On MSDP peers, each SA message is subject to a reverse path forwarding (RPF) check and
multicast policybased filtering, so that only SA messages that have arrived along the correct path
and passed the filtering are received and forwarded. This avoids delivery loops of SA messages. In
addition, you can configure MSDP peers into an MSDP mesh group so as to avoid flooding of SA
messages between MSDP peers.
4) SA messages are forwarded from one MSDP peer to another, and finally the information of the
multicast source traverses all PIM-SM domains with MSDP peers (PIM-SM 2 and PIM-SM 3 in this
example).
5) Upon receiving the SA message create by RP 1, RP 2 in PIM-SM 2 checks whether there are any
receivers for the multicast group in the domain.
z If so, the RPT for the multicast group G is maintained between RP 2 and the receivers. RP 2
creates an (S, G) entry, and sends an (S, G) join message hop by hop towards DR 1 at the
multicast source side, so that it can directly join the SPT rooted at the source over other PIM-SM
domains. Then, the multicast data can flow along the SPT to RP 2 and is forwarded by RP 2 to the
receivers along the RPT. Upon receiving the multicast traffic, the DR at the receiver side (DR 2)
decides whether to initiate an RPT-to-SPT switchover process.
z If no receivers for the group exist in the domain, RP 2 does not create an (S, G) entry and does join
the SPT rooted at the source.
1-4
z An MSDP mesh group refers to a group of MSDP peers that have MSDP peering relationships
among one another and share the same group name.
z When using MSDP for inter-domain multicasting, once an RP receives information form a multicast
source, it no longer relies on RPs in other PIM-SM domains. The receivers can override the RPs in
other domains and directly join the multicast source-based SPT.
RPF check rules for SA messages
As shown in Figure 1-3, there are five autonomous systems in the network, AS 1 through AS 5, with IGP
enabled on routers within each AS and BGP or MBGP as the interoperation protocol among different
ASs. Each AS contains at least one PIM-SM domain and each PIM-SM domain contains one ore more
RPs. MSDP peering relationships have been established among different RPs. RP 3, RP 4 and RP 5
are in an MSDP mesh group. On RP 7, RP 6 is configured as its static RPF peer.
If only one MSDP peer exists in a PIM-SM domain, this PIM-SM domain is also called a stub domain.
For example, AS 4 in Figure 1-3 is a stub domain. The MSDP peer in a stub domain can have multiple
remote MSDP peers at the same time. You can configure one or more remote MSDP peers as static
RPF peers. When an RP receives an SA message from a static RPF peer, the RP accepts the SA
message and forwards it to other peers without performing an RPF check.
Figure 1-3 Diagram for RPF check for SA messages
Source
RP 1
RP 5 RP 9 RP 8
(7)
AS 1
(1)
(3)
AS 5
(2) (4)
Mesh group (6)
AS 3
RP 2 RP 3
AS 2 (3) (5)
MSDP peers (4)

RP 4 RP 6 RP 7
Static RPF peers AS 4
SA message
As illustrated in Figure 1-3, these MSDP peers dispose of SA messages according to the following RPF
check rules:
1) When RP 2 receives an SA message from RP 1
1-5
Because the source-side RP address carried in the SA message is the same as the MSDP peer
address, which means that the MSDP peer where the SA is from is the RP that has created the SA
message, RP 2 accepts the SA message and forwards it to its other MSDP peer (RP 3).
2) When RP 3 receives the SA message from RP 2
Because the SA message is from an MSDP peer (RP 2) in the same AS, and the MSDP peer is the next
hop on the optimal path to the source-side RP, RP 3 accepts the message and forwards it to other peers
(RP 4 and RP 5).
3) When RP 4 and RP 5 receive the SA message from RP 3
Because the SA message is from an MSDP peer (RP 3) in the same mesh group, RP 4 and RP 5 both
accept the SA message, but they do not forward the message to other members in the mesh group;
instead, they forward it to other MSDP peers (RP 6 in this example) out of the mesh group.
4) When RP 6 receives the SA messages from RP 4 and RP 5 (suppose RP 5 has a higher IP
address)
Although RP 4 and RP 5 are in the same AS (AS 3) and both are MSDP peers of RP 6, because RP 5
has a higher IP address, RP 6 accepts only the SA message from RP 5.
Because the SA message is from a static RPF peer (RP 6), RP 7 accepts the SA message and forwards
it to other peer (RP 8).
A BGP or MBGP route exists between two MSDP peers in different ASs. Because the SA message is
from an MSDP peer (RP 7) in a different AS, and the MSDP peer is the next hop on the BGP or MBGP
route to the source-side RP, RP 8 accepts the message and forwards it to its other peer (RP 9).
Because RP 9 has only one MSDP peer, RP 9 accepts the SA message.
SA messages from other paths than described above will not be accepted nor forwarded by MSDP
peers.
Implementing intra-domain Anycast RP by leveraging MSDP peers
Anycast RP refers to such an application that enables load balancing and redundancy backup between
two or more RPs within a PIM-SM domain by configuring the same IP address for, and establishing
MSDP peering relationships between, these RPs.
As shown in Figure 1-4, within a PIM-SM domain, a multicast source sends multicast data to multicast
group G, and Receiver is a member of the multicast group. To implement Anycast RP, configure the
same IP address (known as anycast RP address, typically a private address) on Router A and Router B,
configure these interfaces as C-RPs, and establish an MSDP peering relationship between Router A
and Router B.
Usually an Anycast RP address is configured on a logic interface, like a loopback interface.
1-6
Figure 1-4 Typical network diagram of Anycast RP
RP 1 RP 2
Router A Router B
Source Receiver
PIM-SM
MSDP peers
SA message
The work process of Anycast RP is as follows:

1) The multicast source registers with the nearest RP. In this example, Source registers with RP 1,
with its multicast data encapsulated in the register message. When the register message arrives to
RP 1, RP 1 decapsulates the message.
2) Receivers send join messages to the nearest RP to join in the RPT rooted as this RP. In this
example, Receiver joins the RPT rooted at RP 2.
3) RPs share the registered multicast information by means of SA messages. In this example, RP 1
creates an SA message and sends it to RP 2, with the multicast data from Source encapsulated in
the SA message. When the SA message reaches RP 2, RP 2 decapsulates the message.
4) Receivers receive the multicast data along the RPT and directly join the SPT rooted at the multicast
source. In this example, RP 2 forwards the multicast data down the RPT. When Receiver receives
the multicast data from Source, it directly joins the SPT rooted at Source.
The significance of Anycast RP is as follows:
z Optimal RP path: A multicast source registers with the nearest RP so that an SPT with the optimal
path is built; a receiver joins the nearest RP so that an RPT with the optimal path is built.
z Load balancing between RPs: Each RP just needs to maintain part of the source/group information
within the PIM-SM domain and forward part of the multicast data, thus achieving load balancing
between different RPs.
z Redundancy backup between RPs: When an RP fails, the multicast source previously registered
on it or the receivers previous joined it will register with or join another nearest RP, thus achieving
redundancy backup between RPs.
z Be sure to configure a 32-bit subnet mask (255.255.255.255) for the Anycast RP address, namely
configure the Anycast RP address into a host address.
z An MSDP peer address must be different from the Anycast RP address.
1-7
Multi-Instance MSDP
MSDP peering relationship can be built between multicast-enabled interfaces that belong to the same
instance. Through exchanges of SA messages between MSDP peers, the MSDP mechanism makes
VPN multicast transmission between different PIM-SM domains possible.
A multicast router running multiple MSDP instances maintains an independent set of MSDP mechanism
for each instance it supports, including SA cache, peering connection, timers, sending cache, and
cache for exchanging information with PIM, while one instance is isolated from another; therefore,
interoperabitity between MSDP and PIM-SM is available only within the same instance.
MSDP is documented in the following specifications:

z RFC 3618: Multicast Source Discovery Protocol (MSDP)
z RFC 3446: Anycast Rendezvous Point (RP) mechanism using Protocol Independent Multicast
(PIM) and Multicast Source Discovery Protocol (MSDP)
MSDP Configuration Task List

Complete these tasks to configure MSDP:
Task Remarks
Enabling MSDP Required
Configuring Basic Functions
Creating an MSDP Peer Connection Required
of MSDP
Configuring a Static RPF Peer Optional
Configuring MSDP Peer Description Optional
Configuring an MSDP Peer
Configuring an MSDP Mesh Group Optional
Connection
Configuring MSDP Peer Connection Control Optional
Configuring SA Message Content Optional
Configuring SA Messages Configuring SA Request Messages Optional

Related Parameters Configuring SA Message Filtering Rules Optional
Configuring the SA Cache Mechanism Optional
Configuring Basic Functions of MSDP
All the configuration tasks should be carried out on RPs in PIM-SM domains, and each of these RPs
acts as an MSDP peer.
Before configuring the basic functions of MSDP, complete the following tasks:
1-8
network layer.
z Configuring PIM-SM to enable intra-domain multicast forwarding.
Before configuring the basic functions of MSDP, prepare the following data:
z IP addresses of MSDP peers
z Address prefix list for an RP address filtering policy
Enabling MSDP
Enabling MSDP globally in the public instance
Follow these steps to enable MSDP globally in the public instance:

Required
Disabled by default
Enable MSDP and enter public msdp [ vpn-instance Required

instance MSDP view vpn-instance-name ] Disabled by default
Enabling MSDP in a VPN instance


Configure a route-distinguisher route-distinguisher Required
Required
Disabled by default
Enable MSDP and enter VPN msdp [ vpn-instance Required

instance MSDP view vpn-instance-name ] Disabled by default
1-9
Creating an MSDP Peer Connection
An MSDP peering relationship is identified by an address pair, namely the address of the local MSDP
peer and that of the remote MSDP peer. An MSDP peer connection must be created on both devices
that are a pair of MSDP peers.
Follow these steps to create an MSDP peer connection:

Enter public instance MSDP
msdp [ vpn-instance
view or VPN instance MSDP
vpn-instance-name ]
view
peer peer-address Required

Create an MSDP peer
connect-interface No MSDP peer connection
connection
interface-type interface-number created by default
If an interface of the router is shared by an MSDP peer and a BGP/MBGP peer at the same time, we
recommend that you use the IP address of the BGP/MBGP peer as the IP address of the for the MSDP
peer.
Configuring a Static RPF Peer
Configuring static RPF peers avoids RPF check of SA messages.

Follow these steps to configure a static RPF peer:

msdp [ vpn-instance
vpn-instance-name ]
view
Required
static-rpf-peer peer-address
Configure a static RPF peer No static RPF peer configured
[ rp-policy ip-prefix-name ]
by default
If only one MSDP peer is configured on a router, this MSDP will be registered as a static RPF peer.
1-10
Configuring an MSDP Peer Connection
Before configuring MSDP peer connection, complete the following tasks:

network layer.
z Configuring basic functions of MSDP
Before configuring an MSDP peer connection, prepare the following data:
z Description information of MSDP peers
z Name of an MSDP mesh group
z MSDP peer connection retry interval
Configuring MSDP Peer Description
With the MSDP peer description information, the administrator can easily distinguish different MSDP
peers and thus better manage MSDP peers.
Follow these steps to configure description for an MSDP peer:

msdp [ vpn-instance
vpn-instance-name ]
view
Required
Configure description for an peer peer-address description
MSDP peer text No description for MSDP peers
by default
Configuring an MSDP Mesh Group
An AS may contain multiple MSDP peers. You can use the MSDP mesh group mechanism to avoid SA
message flooding among these MSDP peers and optimize the multicast traffic.
On one hand, an MSDP peer in an MSDP mesh group forwards SA messages from outside the mesh
group that have passed the RPF check to the other members in the mesh group; on the other hand, a
mesh group member accepts SA messages from inside the group without performing an RPF check,
and does not forward the message within the mesh group either. This mechanism not only avoids SA
flooding but also simplifies the RPF check mechanism, because BGP or MBGP is not needed to run
between these MSDP peers.
By configuring the same mesh group name for multiple MSDP peers, you can create a mesh group with
these MSDP peers.
Follow these steps to create an MSDP mesh group:

Enter public instance MSDP view msdp [ vpn-instance

or VPN instance MSDP view vpn-instance-name ]
1-11
Required
Create an MSDP peer as a mesh peer peer-address
group member mesh-group name An MSDP peer does not belong
to any mesh group by default
z Before grouping multiple routers into an MSDP mesh group, make sure that these routers are
interconnected with one another.
z If you configure more than one mesh group name on an MSDP peer, only the last configuration is
effective.
Configuring MSDP Peer Connection Control
MSDP peers are interconnected over TCP (port number 639). You can flexibly control sessions
between MSDP peers by manually deactivating and reactivating the MSDP peering connections. When
the connection between two MSDP peers is deactivated, SA messages will no longer be delivered
between them, and the TCP connection is closed without any connection setup retry, but the
configuration information will remain unchanged.
When a new MSDP peer is created, or when a previously deactivated MSDP peer connection is
reactivated, or when a previously failed MSDP peer attempts to resume operation, a TCP connection is
required. You can flexibly adjust the interval between MSDP peering connection retries.
Follow these steps to configure MSDP peer connection control:

Enter public instance MSDP view or VPN msdp [ vpn-instance

instance MSDP view vpn-instance-name ]
Optional
Deactivate an MSDP peer shutdown peer-address
Active by default
Configure the interval between MSDP peer Optional

timer retry interval
connection retries 30 seconds by default
Configuring SA Messages Related Parameters

Before configuring SA message delivery, complete the following tasks:

network layer.
z Configuring basic functions of MSDP
Before configuring SA message delivery, prepare the following data:
z ACL rules for filtering SA request messages
1-12
z ACL rules as SA message creation rules
z ACL rules for filtering SA messages to be received and forwarded
z TTL threshold for multicast packet encapsulation in SA messages
z Maximum number of (S, G) entries learned from the specified MSDP peer that the router can cache
Configuring SA Message Content
Some multicast sources send multicast data at an interval longer than the aging time of (S, G) entries. In
this case, the source-side DR has to encapsulate multicast data packet by packet in register messages
and send them to the source-side RP. The source-side RP transmits the (S, G) information to the
remote RP through SA messages. Then the remote RP joins the source-side DR and builds an SPT.
Since the (S, G) entries have timed out, remote receivers can never receive the multicast data from the
multicast source.
If the source-side RP is enabled to encapsulate register messages in SA messages, when there is a
multicast packet to deliver, the source-side RP encapsulates a register message containing the
multicast packet in an SA message and sends it out. After receiving the SA message, the remote RP
decapsulates the SA message and delivers the multicast data contained in the register message to the
receivers along the RPT.
The MSDP peers deliver SA messages to one another. Upon receiving an SA message, a router
performs RPF check on the message. If the router finds that the remote RP address is the same as the
local RP address, it will discard the SA message. In the Anycast RP application, however, you need to
configure RPs with the same IP address on two or more routers in the same PIM-SM domain, and
configure these routers as MSDP peers to one another. Therefore, a logic RP address (namely the RP
address on the logic interface) that is different from the actual RP address must be designated for SA
messages so that the messages can pass the RPF check.
Follow these steps to configure the SA message content:

Enter public instance MSDP view or msdp [ vpn-instance

VPN instance MSDP view vpn-instance-name ]
Enable encapsulation of a register Optional

encap-data-enable
message Disabled by default
originating-rp Optional
Configure the interface address as
interface-type
the RP address in SA messages PIM RP address by default
interface-number
Configuring SA Request Messages
By default, upon receiving a new Join message, a router does not send an SA request message to any
MSDP peer; instead, it waits for the next SA message from its MSDP peer. This will cause the receiver
to delay obtaining multicast source information. To enable a new receiver to get the currently active
multicast source information as early as possible, you can configure routers to send SA request
messages to the designated MSDP peers upon receiving a Join message of a new receiver.
Follow these steps to configure SA message transmission and filtering:
1-13
Enter public instance MSDP view or msdp [ vpn-instance

VPN instance MSDP view vpn-instance-name ]
Enable the device to send SA peer peer-address Optional

request messages request-sa-enable Disabled by default
peer peer-address Optional

Configure a filtering rule for SA
sa-request-policy [ acl SA request messages are not
request messages
acl-number ] filtered by default
Before you can enable the device to send SA requests, be sure to disable the SA message cache
mechanism.
Configuring SA Message Filtering Rules
By configuring an SA message creation rule, you can enable the router to filter the (S, G) entries to be
advertised when creating an SA message, so that the propagation of messages of multicast sources is
controlled.
By configuring a filtering rule for receiving or forwarding SA messages, you can enable the router to filter
the (S, G) forwarding entries to be advertised when receiving or forwarding an SA message, so that the
propagation of multicast source information is controlled at SA message reception or forwarding.
By configuring a TTL threshold for multicast data packet encapsulation in SA messages, you can control
the multicast data packet encapsulation in SA messages and limit the propagation range of SA
messages:
z Before creating an SA message with an encapsulated multicast data packet, the router checks the
TTL value of the multicast data packet. If the TTL value is less than the threshold, the router does
not create an SA message; if the TTL value is greater than or equal to the threshold, the router
encapsulates the multicast data in an SA message and sends the SA message out.
z Upon receiving an SA message with an encapsulated multicast data packet, the router decrements
the TTL value of the multicast packet by 1 and then checks the TTL value. If the TTL value is less
than the threshold, the router does not forward the SA message to the designated MSDP peer; if
the TTL value is greater than or equal to the threshold, the router re-encapsulates the multicast
data in an SA message and sends the SA message out.
Follow these steps to configure a filtering rule for receiving or forwarding SA messages:

msdp [ vpn-instance
vpn-instance-name ]
view
1-14
Required
Configure an SA message import-source [ acl
creation rule acl-number ] No restrictions on (S, G) entries
by default
Configure a filtering rule for peer peer-address sa-policy Required
receiving or forwarding SA { import | export } [ acl
messages acl-number ] No filtering rule by default
Configure the TTL threshold for Optional

peer peer-address
multicast data packet
minimum-ttl ttl-value 0 by default
encapsulation in SA messages
Configuring the SA Cache Mechanism
To reduce the time spent in obtaining the multicast information, you can enable the SA cache
mechanism to cache (S, G) entries contained in SA messages locally on the router. However, the more
(S, G) entries are cached, the larger memory space of the router is used.
With the SA cache mechanism enabled, when receiving a new (*, G) join message, the router searches
its SA cache first:
z If the corresponding (S, G) entry does not exist in the cache, the router waits for the SA message its
MSDP peer will send in the next cycle;
z If the corresponding (S, G) entry exists in the cache, the router joins the corresponding SPT rooted
at S.
To protect the router effectively against denial of service (DoS) attacks, you can set a limit on the
number of (S, G) entries the router can cache.
Follow these steps to configure the SA message cache:

Enter public instance MSDP view or VPN msdp [ vpn-instance

instance MSDP view vpn-instance-name ]
Optional
Enable the SA cache mechanism cache-sa-enable
Enabled by default
Configure the maximum number of (S, G) Optional
peer peer-address
entries learned from the specified MSDP
sa-cache-maximum sa-limit 8192 by default
peer that the router can cache
Displaying and Maintaining MSDP

display msdp [ vpn-instance
View the brief information of Available in
vpn-instance-name | all-instance ] brief [ state
MSDP peers any view
{ connect | down | listen | shutdown | up } ]
View the detailed information display msdp [ vpn-instance
Available in
about the status of MSDP vpn-instance-name | all-instance ] peer-status
any view
peers [ peer-address ]
1-15
View the (S, G) entry Available in
vpn-instance-name | all-instance ] sa-cache
information in the SA cache any view
[ group-address | source-address | as-number ] *
View the number of (S, G) Available in
vpn-instance-name | all-instance ] sa-count
entries in the SA cache any view
[ as-number ]
Reset the TCP connection with reset msdp [ vpn-instance vpn-instance-name Available in
an MSDP peer | all-instance ] peer [ peer-address ] user view
Clear (S, G) entries in the SA reset msdp [ vpn-instance vpn-instance-name Available in
cache | all-instance ] sa-cache [ group-address ] user view
Clear all statistics information reset msdp [ vpn-instance vpn-instance-name Available in
of an MSDP peer | all-instance ] statistics [ peer-address ] user view
MSDP Configuration Examples (On Routers)

Inter-AS Multicast Configuration Leveraging BGP Routes
z There are two ASs in the network, AS 100 and AS 200 respectively. OSPF is running within each
AS, and BGP is running between the two ASs.
z PIM-SM 1 belongs to AS 100, while PIM-SM 2 and PIM-SM 3 belong to AS 200.
z Each PIM-SM domain has zero or one multicast source and receiver. OSPF runs within each
domain to provide unicast routes.
z It is required that the respective Loopback 0 of Router B, Router C and Router E be configured as
the C-BSR and C-RP of the respective PIM-SM domains.
z It is required that an MSDP peering relationship be established between Router B and Router C
through EBGP, and between Router C and Router E through IBGP.
1-16
Network diagram
Figure 1-5 Network diagram for inter-AS multicast configuration leveraging BGP routes (on routers)
Et
h1
/1
/2
h1
Et
Et
h1
/0
Et
h1
/0
/1
h1
Et
Router A Eth1/0 10.110.1.2/24 Router D Eth1/0 10.110.4.2/24
Eth1/1 10.110.2.1/24 Eth1/1 10.110.5.1/24
Eth1/2 10.110.3.1/24 Router E Eth1/0 10.110.6.1/24
Router B Eth1/0 10.110.1.1/24 S2/0 192.168.3.2/24
POS5/0 192.168.1.1/24 Loop0 3.3.3.3/32
Loop0 1.1.1.1/32 Router F Eth1/0 10.110.6.2/24
Router C Eth1/0 10.110.4.1/24 Eth1/1 10.110.7.1/24
S2/0 192.168.3.1/24 Source 1 10.110.2.100/24
POS5/0 192.168.1.2/24 Source 2 10.110.5.100/24
Loop0 2.2.2.2/32

Configure the IP address and subnet mask for each interface as per Figure 1-5. Detailed configuration
steps are omitted.
Configure OSPF for interconnection between routers in each AS. Ensure the network-layer
interoperation in each AS, and ensure the dynamic update of routing information between the routers
through a unicast routing protocol. Detailed configuration steps are omitted.
2) Enable IP multicast routing, enable PIM-SM and IGMP, and configure a PIM-SM domain border
# Enable IP multicast routing on Router A, enable PIM-SM on each interface, and enable IGMP on the
1-17
The configuration on Router B, Router C, Router D, Router E, and Router F is similar to the
configuration on Router A.
# Configure a PIM domain border on Router B.
[RouterB-Pos5/0] pim bsr-boundary
The configuration on Router C and Router E is similar to the configuration on Router B.

3) Configure C-BSRs and C-RPs
# Configure Loopback 0 as a C-BSR and a C-RP on Router B.
[RouterB] pim
[RouterB-pim] c-bsr loopback 0
[RouterB-pim] c-rp loopback 0
[RouterB-pim] quit

4) Configure BGP and configure mutual route redistribution between BGP and OSPF
# Configure EBGP on Router B, and redistribute OSPF routes.
[RouterB] bgp 100
[RouterB-bgp] quit
# Configure IBGP and EBGP on Router C, and redistribute OSPF routes.

[RouterC] bgp 200
[RouterC-bgp] import-route ospf 1
[RouterC-bgp] quit
# Configure IBGP on Router E, and redistribute OSPF routes.

[RouterE] bgp 200
[RouterE-bgp] router-id 3.3.3.3
[RouterE-bgp] import-route ospf 1
[RouterE-bgp] quit
# Redistribute BGP routing information into OSPF on Router B.

[RouterB] ospf 1
[RouterB-ospf-1] import-route bgp
1-18
5) Configure MSDP peers
# Configure an MSDP peer on Router B.
[RouterB] msdp
[RouterB-msdp] peer 192.168.1.2 connect-interface pos 5/0
[RouterB-msdp] quit
# Configure MSDP peers on Router C.

[RouterC] msdp
[RouterC-msdp] peer 192.168.1.1 connect-interface pos 5/0
[RouterC-msdp] peer 192.168.3.2 connect-interface serial 2/0
[RouterC-msdp] quit
# Configure an MSDP peer on Router E.

[RouterE] msdp
[RouterE-msdp] peer 192.168.3.1 connect-interface serial 2/0
[RouterE-msdp] quit
Carry out the display bgp peer command to view the BGP peering relationships between the routers.
For example:
# View the information about BGP peering relationship on Router B.
[RouterB] display bgp peer

192.168.1.2 4 200 24 21 0 6 00:13:09 Established
# View the information about BGP peering relationship on Router C.

[RouterC] display bgp peer

192.168.1.1 4 100 18 16 0 1 00:12:04 Established

192.168.3.2 4 200 21 20 0 6 00:12:05 Established
# View the information about BGP peering relationships on Router E.

[RouterE] display bgp peer

1-19
192.168.3.1 4 200 16 14 0 1 00:10:58 Established
To view the BGP routing table information on the routers, use the display bgp routing-table command.
For example:
# View the BGP routing table information on Router C.

*> 1.1.1.1/32 192.168.1.1 0 0 100?

*>i 2.2.2.2/32 192.168.3.2 0 100 0 ?
*> 3.3.3.3/32 0.0.0.0 0 0 ?
*> 192.168.1.0 0.0.0.0 0 0 ?
* 192.168.1.1 0 0 100?
*> 192.168.1.1/32 0.0.0.0 0 0 ?
*> 192.168.1.2/32 0.0.0.0 0 0 ?
* 192.168.1.1 0 0 100?
*> 192.168.3.0 0.0.0.0 0 0 ?
* i 192.168.3.2 0 100 0 ?
*> 192.168.3.1/32 0.0.0.0 0 0 ?
*> 192.168.3.2/32 0.0.0.0 0 0 ?
* i 192.168.3.2 0 100 0 ?
When the multicast sources (Source 1 and Source 2) in PIM-SM 1 and PIM-SM 2 send multicast
information, receivers in PIM-SM 1 and PIM-SM 3 can receive the multicast data. You can use the
display msdp brief command to view the brief information of MSDP peering relationships between the
routers. For example:
# View the brief information about MSDP peering relationship on Router B.
[RouterB] display msdp brief
MSDP Peer Brief Information of VPN-Instance: public net
Configured Up Listen Connect Shutdown Down
1 1 0 0 0 0
Peer's Address State Up/Down time AS SA Count Reset Count

192.168.1.2 Up 00:12:27 200 13 0
# View the brief information about MSDP peering relationship on Router C.

[RouterC] display msdp brief
1-20
2 2 0 0 0 0

192.168.3.2 Up 00:15:32 200 8 0
192.168.1.1 UP 00:06:39 100 13 0
# View the brief information about MSDP peering relationships on Router E.

[RouterE] display msdp brief
1 1 0 0 0 0

192.168.3.1 Up 01:07:08 200 8 0
# View the detailed MSDP peer information on Router B.

[RouterB] display msdp peer-status
MSDP Peer Information of VPN-Instance: public net
MSDP Peer 192.168.1.2, AS 200
Description:
Information about connection status:
State: Up
Up/down time: 00:15:47
Resets: 0
Connection interface: Pos5/0 (192.168.1.1)
Number of sent/received messages: 16/16
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 00:17:51
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
Minimum TTL to forward SA with encapsulated data: 0
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Input queue size: 0, Output queue size: 0
Counters for MSDP message:
Count of RPF check failure: 0
Incoming/outgoing SA messages: 0/0
Incoming/outgoing SA requests: 0/0
Incoming/outgoing SA responses: 0/0
Incoming/outgoing data packets: 0/0
1-21
Inter-AS Multicast Configuration Leveraging Static RPF Peers
z PIM-SM 2 and PIM-SM 3 are both stub domains, and BGP or MBGP is not required between these
two domains and PIM-SM 1. Instead, static RPF peers are configured to avoid RPF check on SA
messages.
z It is required that the respective Loopback 0 of Router B, Router C and Router E be configured as
a C-BSR and C-RP of the respective PIM-SM domains.
z It is required that Router C and Router E be configured as static RPF peers of Router B, and Router
B be configured as the only static RPF peer of Router C and Router E, so that any router can
receive SA messages only from its static RPF peer(s) and permitted by the corresponding filtering
policy.
Network diagram
Figure 1-6 Network diagram for inter-AS multicast configuration leveraging static RPF peers (on
routers)
/0
S2
1/
h1
Et
2
/
h1
Et
Et
h1
/0
/0
Et
S2
h1
0 /
1 /
h1
Et

Eth1/1 10.110.2.1/24 Eth1/1 10.110.5.1/24
Eth1/2 10.110.3.1/24 Router E Eth1/0 10.110.6.1/24
Router B Eth1/0 10.110.1.1/24 S2/0 192.168.3.2/24
POS5/0 192.168.1.1/24 Loop0 3.3.3.3/32
S2/0 192.168.3.1/24 Router F Eth1/0 10.110.6.2/24
Loop0 1.1.1.1/32 Eth1/1 10.110.7.1/24
Router C POS5/0 192.168.1.2/24 Source 1 10.110.2.100/24
Eth1/0 10.110.4.1/24 Source 2 10.110.5.100/24
Loop0 2.2.2.2/32
1-22

steps are omitted.
Configure OSPF for interconnection between the routers in each AS. Ensure the network-layer
interoperation in each AS, and ensure the dynamic update of routing information through a unicast
routing protocol among the routers. Detailed configuration steps are omitted.
# Enable IP multicast routing on Router A, enable PIM-SM on each interface, and enable IGMP on the
The configuration on Router B, Router C, Router D, Router E, and Router F is similar to the
configuration on Router A.
# Configure PIM domain borders on Router B.
[RouterB-Serial2/0] pim bsr-boundary

# Configure Loopback 0 as a C-BSR and a C-RP on Router B.
[RouterB] pim
[RouterB-pim] quit

4) Configure static RPF peers
# Configure Router C and Router E as MSDP peers and static RPF peers of Router B.
[RouterB] ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 16 less-equal 32
[RouterB] msdp
1-23
[RouterB-msdp] peer 192.168.3.2 connect-interface serial 2/0
[RouterB-msdp] static-rpf-peer 192.168.3.2 rp-policy list-df
[RouterB-msdp] static-rpf-peer 192.168.1.2 rp-policy list-df
[RouterB-msdp] quit
# Configure Router B as MSDP peer and static RPF peer of Router C.

[RouterC] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32
[RouterC] msdp
[RouterC-msdp] static-rpf-peer 192.168.1.1 rp-policy list-c
[RouterC-msdp] quit
# Configure Router B as MSDP peer and static RPF peer of Router E.

[RouterE] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32
[RouterE] msdp
[RouterE-msdp] peer 192.168.3.1 connect-interface serial 2/0
[RouterE-msdp] static-rpf-peer 192.168.3.1 rp-policy list-c
[RouterE-msdp] quit
Carry out the display bgp peer command to view the BGP peering relationships between the routers. If
the command gives no output information, a BGP peering relationship has not been established
between the routers.
When the multicast source in PIM-SM 1 (Source 1) and the multicast source in PIM-SM 2 (Source 2)
send multicast information, receivers in PIM-SM 1 and PIM-SM 3 can receive the multicast data. You
can use the display msdp brief command to view the brief information of MSDP peering relationships
between the routers. For example:
# View the brief MSDP peer information on Router B.
2 2 0 0 0 0

192.168.3.2 Up 01:07:08 ? 8 0
192.168.1.2 Up 00:16:39 ? 13 0
# View the brief MSDP peer information on Router C.

[RouterC] display msdp brief
1 1 0 0 0 0

192.168.1.1 Up 01:07:09 ? 8 0
# View the brief MSDP peer information on Router E.

[RouterE] display msdp brief
1-24
1 1 0 0 0 0

192.168.3.1 Up 00:16:40 ? 13 0
Anycast RP Configuration
z The PIM-SM domain in this example has multiple multicast sources and receivers. OSPF runs
within the domain to provide unicast routes.
z It is required to configure the anycast RP application so that the receiver-side DRs and the
source-side DRs can initiate a Join message to their respective RPs that are the topologically
nearest to them.
z On Router B and Router D, configure the interface Loopback 10 as a C-BSR, and Loopback 20 as
a C-RP.
z The router ID of Router B is 1.1.1.1, while the router ID of Router D is 2.2.2.2. Set up an MSDP
peering relationship between Router B and Router D.
Network diagram
Figure 1-7 Network diagram for anycast RP application configuration (on routers)
Lo
20
Lo
0
op
op
op
op
Lo
20
Lo
0

Source 1 10.110.5.100/24 Router C POS5/0 192.168.1.2/24
Source 2 10.110.6.100/24 POS5/1 192.168.2.2/24
S2/0 10.110.2.2/24 S2/0 10.110.4.1/24
Router B Eth1/0 10.110.1.1/24 POS5/0 192.168.2.1/24
S2/0 10.110.2.1/24 Loop0 2.2.2.2/32
POS5/0 192.168.1.1/24 Loop10 4.4.4.4/32
Loop0 1.1.1.1/32 Loop20 10.1.1.1/32
Loop10 3.3.3.3/32 Router E Eth1/0 10.110.6.1/24
Loop20 10.1.1.1/32 S2/0 10.110.4.2/24
1-25

steps are omitted.
Configure OSPF for interconnection between the routers in the PIM-SM domain. Ensure the
network-layer interoperation among the routers, and ensure the dynamic update of routing information
through a unicast routing protocol. Detailed configuration steps are omitted.
2) Enable IP multicast routing, and enable PIM-SM and IGMP
# Enable IP multicast routing on Router B, enable PIM-SM on each interface, and enable IGMP on the
[RouterB-Ethernet1/0] pim sm
[RouterB-Serial2/0] pim sm
[RouterB-Pos5/0] pim sm
[RouterB-LoopBack0] pim sm
[RouterB-LoopBack0] quit
The configuration on Router A, Router C, Router D, and Router E is similar to the configuration on
Router B.
# Configure Loopback 10 as a C-BSR and configure Loopback 20 as a C-RP on Router B.
[RouterB] pim
[RouterB-pim] quit
The configuration on Router D is similar to the configuration on Router B.

# Configure an MSDP peer on Loopback 0 of Router B.
[RouterB] msdp
[RouterB-msdp] originating-rp loopback 0
1-26
[RouterB-msdp] peer 2.2.2.2 connect-interface loopback 0
[RouterB-msdp] quit
# Configure an MSDP peer on Loopback 0 of Router D.

[RouterD] msdp
[RouterD-msdp] originating-rp loopback 0
[RouterD-msdp] peer 1.1.1.1 connect-interface loopback 0
[RouterD-msdp] quit
You can use the display msdp brief command to view the brief information of MSDP peering
relationships between the routers.
# View the brief MSDP peer information on Router B.
1 1 0 0 0 0

2.2.2.2 Up 00:10:17 ? 0 0
# View the brief MSDP peer information on Router D.

[RouterD] display msdp brief
1 1 0 0 0 0

1.1.1.1 Up 00:10:18 ? 0 0
To view the PIM routing information on each router, use the display pim routing-table command.
When Source 1 (10.110.5.100/24) sends multicast data to multicast group G (225.1.1.1), Host A joins
multicast group G. By comparing the PIM routing information displayed on Router B with that displayed
on Router D, you can see that Router B acts now as the RP for Source 1 and Host A.
# View the PIM routing information on Router B.
[RouterB] display pim routing-table
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: WC
UpTime: 00:15:04
Upstream interface: Register
Upstream neighbor: NULL
RPF prime neighbor: NULL
1: Ethernet1/0
1-27
(10.110.5.100, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:46:28
Upstream interface: Serial2/0
1: Ethernet1/0
Protocol: pim-sm, UpTime: - , Expires: -
# View the PIM routing information on Router D.

No information is output on Router D.

Host A has left multicast group G, and Source 1 has stopped sending multicast data to multicast group G.
When Source 2 (10.110.6.100/24) sends multicast data to G, Host B joins G. By comparing the PIM
routing information displayed on Router B with that displayed on Router D, you can see that Router D
acts now as the RP for Source 2 and Host B.
# View the PIM routing information on Router B.
[RouterB] display pim routing-table
No information is output on Router B.

# View the PIM routing information on Router D.
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:12:07
1: Ethernet1/0
(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:40:22
1-28
1: Ethernet1/0
SA Message Filtering Configuration
z Three PIM-SM domains exist in the network, and OSPF runs within and among the domains to
provide unicast routing.
z Configure respective Loopback 0 of Router A, Router C and Router D as a C-BSR and C-RP in the
respective PIM-SM domain.
z Set up an MSDP peering relationship between Router A and Router C and between Router C and
Router D.
z Source 1 sends multicast data to multicast groups 225.1.1.0/30 and 226.1.1.0/30, and Source 2
sends multicast data to multicast group 227.1.1.0/30.
z Configure SA message filtering rules so that receivers Host A and Host B can receive only the
multicast data addressed to multicast groups 225.1.1.0/30 and 226.1.1.0/30, while Host can
receive only the multicast data addressed to multicast groups 226.1.1.0/30 and 227.1.1.0/30.
Network diagram
Figure 1-8 Network diagram for SA message filtering configuration (on routers)
PIM-SM 1 PIM-SM 2 PIM-SM 3

Loop0
Eth1/1
Source 2
PO
S5
Receiver /1 Loop0
Router A S2/1
Host A
PO Eth1/1
S Router C
5/1
S2/1
S2/1
/2 Router D
S5 Eth1/1 Eth1/2
PO
Source 1
S2/1 S 5 /1
PO
Eth1/1
Router B
Receiver Receiver
Host B Host C
MSDP peers

Source 1 - 10.110.3.100/24 Router C Eth1/1 10.110.4.1/24
Source 2 - 10.110.6.100/24 S2/1 10.110.5.1/24
Router A Eth1/1 10.110.1.1/24 POS5/1 192.168.1.2/24
S2/1 10.110.2.1/24 POS5/2 192.168.2.2/24
POS5/1 192.168.1.1/24 Loop0 2.2.2.2/32
Loop0 1.1.1.1/32 Router D Eth1/1 10.110.6.1/24
Router B Eth1/1 10.110.3.1/24 Eth1/2 10.110.7.1/24
S2/1 10.110.2.2/24 S2/1 10.110.5.2/24
POS5/1 192.168.2.1/24 Loop0 3.3.3.3/32
1-29

Configure OSPF for interoperation among the routers. Ensure the network-layer interoperation within
and between the PIM-SM domains and ensure dynamic update of routing information among the
routers by leveraging unicast routing. The detailed configuration steps are omitted here.
2) Enable IP multicast routing, PIM-SM and IGMP, and configure a PIM domain border
# On Router A, enable IP multicast routing, enable PIM-SM on each interface, and enable IGMP on the
host-side interface, Ethernet 1/1.
[RouterA-Serial2/1] pim sm
[RouterA-Pos5/1] pim sm
[RouterA-LoopBack0] pim sm
The configuration on Router B, Router C and Router D is similar to the configuration on Router A. The
specific configuration steps are omitted here.
# Configure a PIM domain border on Router C.
[RouterC-Pos5/1] pim bsr-boundary
[RouterC-Pos5/2] pim bsr-boundary
[RouterC-Serial2/1] pim bsr-boundary
The configuration on Router A, Router B and Router D is similar to the configuration on Router C. The
# Configure Loopback 0 on Router A as a C-BSR and a C-RP.
[RouterA] pim
[RouterA-pim] c-bsr loopback 0
[RouterA-pim] c-rp loopback 0
1-30
[RouterA-pim] quit
The configuration on Router C and Router D is similar to the configuration on Router A. The specific
# Configure an MSDP peer on Router A.
[RouterA] msdp
[RouterA-msdp] peer 192.168.1.2 connect-interface pos 5/1
[RouterA-msdp] quit
# Configure MSDP peers on Router C.

[RouterC] msdp
[RouterC-msdp] peer 10.110.5.2 connect-interface serial 2/1
[RouterC-msdp] quit
# Configure an MSDP peer on Router D.

[RouterD] msdp
[RouterD-msdp] peer 10.110.5.1 connect-interface serial 2/1
[RouterD-msdp] quit
5) Configure SA message filtering rules
# Configure an SA message rule on Router C so that Router C will not forward SA messages for
(Source 1, 225.1.1.0/30) to Router D.
[RouterC-acl-adv-3001] rule deny ip source 10.110.3.100 0 destination 225.1.1.0 0.0.0.3
[RouterC-acl-adv-3001] rule permit ip source any destination any
[RouterC-acl-adv-3001] quit
[RouterC] msdp
[RouterC-msdp] peer 10.110.5.2 sa-policy export acl 3001
[RouterC-msdp] quit
# Configure an SA message rule on Router D so that Router D will not create SA messages for Source
2.
[RouterD-acl-basic-2001] rule deny source 10.110.6.100 0
[RouterD] msdp
[RouterD-msdp] import-source acl 2001
[RouterD-msdp] quit
View the (S, G) entries cached in the SA cache on the routers using the display msdp sa-cache
command. For example:
# View the (S, G) entries cached in the SA cache on Router C.
[RouterC] display msdp sa-cache
MSDP Source-Active Cache Information of VPN-Instance: public net
MSDP Total Source-Active Cache - 8 entries
MSDP matched 8 entries
1-31
(Source, Group) Origin RP Pro AS Uptime Expires
(10.110.3.100, 225.1.1.0) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.1) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.2) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.3) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.0) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.1) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.2) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.3) 1.1.1.1 ? ? 02:03:30 00:05:31
# View the (S, G) entries cached in the SA cache on Router D.

[RouterD] display msdp sa-cache

(10.110.3.100, 226.1.1.0) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.1) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.2) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.3) 1.1.1.1 ? ? 00:32:53 00:05:07
MSDP Configuration Examples (On Switches)

Inter-AS Multicast Configuration Leveraging BGP Routes
z It is required that the respective Loopback 0 of Switch B, Switch C and Switch E be configured as
z It is required that an MSDP peering relationship be set up between Switch B and Switch C through
EBGP, and between Switch C and Switch E through IBGP.
1-32
Network diagram
Figure 1-9 Network diagram for inter-AS multicast configuration leveraging BGP routes (on switches)
Vl
an
-in
t4
00
00
t2
-in
an
Vl
Vl
an
-
in Vl
t1 an
03 -i
nt
10
3
00
t3
-in
an
Vl
Vlan-int100 10.110.2.1/24 Vlan-int300 10.110.5.1/24
Vlan-int101 192.168.1.1/24 Loop0 3.3.3.3/32
Loop0 1.1.1.1/32 Switch F Vlan-int105 10.110.6.2/24
Switch C Vlan-int104 10.110.4.1/24 Vlan-int400 10.110.7.1/24
Vlan-int102 192.168.3.1/24 Source 1 10.110.2.100/24
Vlan-int101 192.168.1.2/24 Source 2 10.110.5.100/24
Loop0 2.2.2.2/32

Configure OSPF for interconnection between switches in each AS. Ensure the network-layer
interoperation among each AS, and ensure the dynamic update of routing information between the
switches through a unicast routing protocol. Detailed configuration steps are omitted here.
2) Enable IP multicast routing, enable PIM-SM on each interface, and configure a PIM-SM domain
border
# Enable IP multicast routing on Switch A, enable PIM-SM on each interface, and enable IGMP on the
1-33
The configuration on Switch B, Switch C, Switch D, Switch E, and Switch F is similar to the configuration
on Switch A.
# Configure a PIM domain border on Switch B.
[SwitchB-Vlan-interface101] pim bsr-boundary
The configuration on Switch C and Switch E is similar to the configuration on Switch B.

# Configure Loopback 0 as a C-BSR and a C-RP on Switch B.
[SwitchB] pim
[SwitchB-pim] c-bsr loopback 0
[SwitchB-pim] c-rp loopback 0
[SwitchB-pim] quit

4) Configure BGP for mutual route redistribution between BGP and OSPF
# Configure EBGP on Switch B, and redistribute OSPF routes.
[SwitchB] bgp 100
[SwitchB-bgp] quit
# Configure IBGP and EBGP on Switch C, and redistribute OSPF routes.

[SwitchC] bgp 200
[SwitchC-bgp] import-route ospf 1
[SwitchC-bgp] quit
# Configure IBGP on Switch E, and redistribute OSPF routes.

[SwitchE] bgp 200
[SwitchE-bgp] router-id 3.3.3.3
[SwitchE-bgp] import-route ospf 1
[SwitchE-bgp] quit
# Redistribute BGP routes into OSPF on Switch B.

[SwitchB] ospf 1
[SwitchB-ospf-1] import-route bgp
1-34

# Configure an MSDP peer on Switch B.
[SwitchB] msdp
[SwitchB-msdp] peer 192.168.1.2 connect-interface vlan-interface 101
[SwitchB-msdp] quit
# Configure an MSDP peer on Switch C.

[SwitchC] msdp
[SwitchC-msdp] peer 192.168.1.1 connect-interface vlan-interface 101
[SwitchC-msdp] quit
# Configure MSDP peers on Switch E.

[SwitchE] msdp
[SwitchE-msdp] peer 192.168.3.1 connect-interface vlan-interface 102
[SwitchE-msdp] quit
Carry out the display bgp peer command to view the BGP peering relationships between the switches.
For example:
# View the information about BGP peering relationships on Switch B.
[SwitchB] display bgp peer

192.168.1.2 4 200 24 21 0 6 00:13:09 Established
# View the information about BGP peering relationships on Switch C.

[SwitchC] display bgp peer

192.168.1.1 4 100 18 16 0 1 00:12:04 Established

192.168.3.2 4 200 21 20 0 6 00:12:05 Established
# View the information about BGP peering relationships on Switch E.

[SwitchE] display bgp peer
1-35
192.168.3.1 4 200 16 14 0 1 00:10:58 Established
To view the BGP routing table information on the switches, use the display bgp routing-table
# View the BGP routing table information on Switch C.

*> 1.1.1.1/32 192.168.1.1 0 0 100?

*>i 2.2.2.2/32 192.168.3.2 0 100 0 ?
*> 3.3.3.3/32 0.0.0.0 0 0 ?
*> 192.168.1.0 0.0.0.0 0 0 ?
* 192.168.1.1 0 0 100?
*> 192.168.1.1/32 0.0.0.0 0 0 ?
*> 192.168.1.2/32 0.0.0.0 0 0 ?
* 192.168.1.1 0 0 100?
*> 192.168.3.0 0.0.0.0 0 0 ?
* i 192.168.3.2 0 100 0 ?
*> 192.168.3.1/32 0.0.0.0 0 0 ?
*> 192.168.3.2/32 0.0.0.0 0 0 ?
* i 192.168.3.2 0 100 0 ?
between the switches. For example:
# View the brief information about MSDP peering relationships on Switch B.
[SwitchB] display msdp brief
MSDP Peer Brief Information
1 1 0 0 0 0

192.168.1.2 Up 00:12:27 200 13 0
# View the brief information about MSDP peering relationships on Switch C.

[SwitchC] display msdp brief
1-36
2 2 0 0 0 0

192.168.3.2 Up 00:15:32 200 8 0
192.168.1.1 Up 00:06:39 100 13 0
# View the brief information about MSDP peering relationships on Switch E.

[SwitchE] display msdp brief
1 1 0 0 0 0

192.168.3.1 Up 01:07:08 200 8 0
# View the detailed MSDP peer information on Switch B.

[SwitchB] display msdp peer-status
MSDP Peer 192.168.1.2, AS 200
Description:
Information about connection status:
State: Up
Up/down time: 00:15:47
Resets: 0
Connection interface: Vlan-interface101 (192.168.1.1)
Number of sent/received messages: 16/16
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 00:17:51
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
Minimum TTL to forward SA with encapsulated data: 0
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Input queue size: 0, Output queue size: 0
Counters for MSDP message:
Count of RPF check failure: 0
Incoming/outgoing SA messages: 0/0
Incoming/outgoing SA requests: 0/0
Incoming/outgoing SA responses: 0/0
Incoming/outgoing data packets: 0/0
1-37
Inter-AS Multicast Configuration Leveraging Static RPF Peers
z PIM-SM 2 and PIM-SM 3 are both stub domains, and BGP or MBGP is not required between these
two domains and PIM-SM 1. Instead, static RPF peers are configured to avoid RPF check on SA
messages.
z It is required that the respective loopback 0 of Switch B, Switch C and Switch E be configured as
z It is required that Switch C and Switch E be configured as static RPF peers of Switch B, and Switch
B be configured as the only static RPF peer of Switch C and Switch E, so that any switch can
receive SA messages only from its static RPF peer(s) and permitted by the corresponding filtering
policy.
Network diagram
Figure 1-10 Network diagram for inter-AS multicast configuration leveraging static RPF peers (on
switches)
AS 100 AS 200
PIM-SM 3
Receiver
Vlan-int105
Vlan-int105
02
Switch E Switch F
00
t1
-in
t4
00
-in
an
t2
an
Source 1
Vl
Loop0
-in
Vl
an
Vl
Vlan-int100
Receiver
Vl
an
Switch A
-in V
t1 lan
03 -i
PIM-SM 2
02
t1
-in
an
nt
Vl
10
3
Switch B Switch C Switch D
00
t3
-in
Loop0 Loop0
an
Vl
Source 2
PIM-SM 1
Static RPF peers

Vlan-int100 10.110.2.1/24 Vlan-int300 10.110.5.1/24
Vlan-int101 192.168.1.1/24 Loop0 3.3.3.3/32
Vlan-int102 192.168.3.1/24 Switch F Vlan-int105 10.110.6.2/24
Loop0 1.1.1.1/32 Vlan-int400 10.110.7.1/24
Switch C Vlan-int101 192.168.1.2/24 Source 1 10.110.2.100/24
Vlan-int104 10.110.4.1/24 Source 2 10.110.5.100/24
Loop0 2.2.2.2/32
1-38

Configure OSPF for interconnection between the switches. Ensure the network-layer interoperation in
each AS, and ensure the dynamic update of routing information among the switches through a unicast
routing protocol. Detailed configuration steps are omitted here.
# Enable IP multicast routing on Switch A, enable PIM-SM on each interface, and enable IGMP on the
The configuration on Switch B, Switch C, Switch D, Switch E, and Switch F is similar to the configuration
on Switch A.
# Configure PIM domain borders on Switch B.

# Configure Loopback 0 as a C-BSR and a C-RP on Switch B.
[SwitchB] pim
[SwitchB-pim] quit

4) Configure a static RPF peer
# Configure Switch C and Switch E as a static RPF peers of Switch B.
[SwitchB] ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 16 less-equal 32
[SwitchB] msdp
1-39
[SwitchB-msdp] static-rpf-peer 192.168.3.2 rp-policy list-df
[SwitchB-msdp] static-rpf-peer 192.168.1.2 rp-policy list-df
[SwitchB-msdp] quit
# Configure Switch B as a static RPF peer of Switch C.

[SwitchC] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32
[SwitchC] msdp
[SwitchC-msdp] static-rpf-peer 192.168.1.1 rp-policy list-c
[SwitchC-msdp] quit
# Configure Switch B as a static RPF peer of Switch E.

[SwitchE] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32
[SwitchE] msdp
[SwitchE-msdp] peer 192.168.3.1 connect-interface vlan-interface 102
[SwitchE-msdp] static-rpf-peer 192.168.3.1 rp-policy list-c
[SwitchE-msdp] quit
Carry out the display bgp peer command to view the BGP peering relationships between the switches.
If the command gives no output information, a BGP peering relationship has not been established
between the switches.
between the switches. For example:
# View the brief MSDP peer information on Switch B.
2 2 0 0 0 0

192.168.3.2 Up 01:07:08 ? 8 0
192.168.1.2 Up 00:16:39 ? 13 0
# View the brief MSDP peer information on Switch C.

[SwitchC] display msdp brief
1 1 0 0 0 0

192.168.1.1 Up 01:07:09 ? 8 0
# View the brief MSDP peer information on Switch E.

[SwitchE] display msdp brief
1-40
1 1 0 0 0 0

192.168.3.1 Up 00:16:40 ? 13 0
Anycast RP Configuration
z The PIM-SM domain has multiple multicast sources and receivers. OSPF runs within the domain to
provide unicast routes.
z It is required to configure the anycast RP application so that the receiver-side DRs and the
source-side DRs can initiate a Join message to their respective RPs that are the topologically
nearest to them.
z On Switch B and Switch D, configure the interface Loopback 10 as a C-BSR, and Loopback 20 as
a C-RP.
z The router ID of Switch B is 1.1.1.1, while the router ID of Switch D is 2.2.2.2. Set up an MSDP
peering relationship between Switch B and Switch D.
Network diagram
Figure 1-11 Network diagram for anycast RP configuration (on switches)

Vl a
Vl a
1
4
10
10
n-i
n-i
t
t
-in
-in
n t1
n t1
n
n
Vla
Vla
03
02
Vla
1
10
Vla
4
10
n- i
t
-in
n
t
n t1
-in
-in
n
Vla
n
t
02
10
Vla
3
Lo
20
Lo
0
op
op
op
op
Lo
20
Lo
0

Source 1 10.110.5.100/24 Switch C Vlan-int101 192.168.1.2/24
Source 2 10.110.6.100/24 Vlan-int102 192.168.2.2/24
Vlan-int103 10.110.2.2/24 Vlan-int104 10.110.4.1/24
Vlan-int103 10.110.2.1/24 Loop0 2.2.2.2/32
Vlan-int101 192.168.1.1/24 Loop10 4.4.4.4/32
Loop0 1.1.1.1/32 Loop20 10.1.1.1/32
Loop10 3.3.3.3/32 Switch E Vlan-int400 10.110.6.1/24
Loop20 10.1.1.1/32 Vlan-int104 10.110.4.2/24
1-41

Configure OSPF for interconnection between the switches. Ensure the network-layer interoperation
among the switches, and ensure the dynamic update of routing information between the switches
through a unicast routing protocol. Detailed configuration steps are omitted here.
# Enable IP multicast routing on Switch B, enable PIM-SM on each interface, and enable IGMP on the
[SwitchB-Vlan-interface100] pim sm
[SwitchB] interface Vlan-interface 101
[SwitchB] interface loopback 0
[SwitchB-LoopBack0] pim sm
[SwitchB-LoopBack0] quit
The configuration on Switch A, Switch C, Switch D, and Switch E is similar to the configuration on
Switch B.
# Configure Loopback 10 as a C-BSR and Loopback 20 as a C-RP on Switch B.
[SwitchB] pim
[SwitchB-pim] quit
The configuration on Switch D is similar to the configuration on Switch B.

# Configure an MSDP peer on Loopback 0 of Switch B.
[SwitchB] msdp
[SwitchB-msdp] originating-rp loopback 0
1-42
[SwitchB-msdp] peer 2.2.2.2 connect-interface loopback 0
[SwitchB-msdp] quit
# Configure an MSDP peer on Loopback 0 of Switch D.

[SwitchD] msdp
[SwitchD-msdp] originating-rp loopback 0
[SwitchD-msdp] peer 1.1.1.1 connect-interface loopback 0
[SwitchD-msdp] quit
You can use the display msdp brief command to view the brief information of MSDP peering
relationships between the switches.
# View the brief MSDP peer information on Switch B.
1 1 0 0 0 0

2.2.2.2 Up 00:10:17 ? 0 0
# View the brief MSDP peer information on Switch D.

[SwitchD] display msdp brief
1 1 0 0 0 0

1.1.1.1 Up 00:10:18 ? 0 0
To view the PIM routing information on the switches, use the display pim routing-table command.
When Source 1 (10.110.5.100/24) sends multicast data to multicast group G (225.1.1.1), Host A joins
multicast group G. By comparing the PIM routing information displayed on Switch B with that displayed
on Switch D, you can see that Switch B acts now as the RP for Source 1 and Host A.
# View the PIM routing information on Switch B.
[SwitchB] display pim routing-table
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:15:04
1-43
(10.110.5.100, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:46:28
# View the PIM routing information on Switch D.

No information is output on Switch D.

Host A has left multicast group G. Source 1 has stopped sending multicast data to multicast group G.
When Source 2 (10.110.6.100/24) sends multicast data to G, Host B joins G. By comparing the PIM
routing information displayed on Switch B with that displayed on Switch D, you can see that Switch D
acts now as the RP for Source 2 and Host B.
# View the PIM routing information on Switch B.
[SwitchB] display pim routing-table
No information is output on Switch B.

# View the PIM routing information on Switch D.
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:12:07
(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:40:22
1-44
SA Message Filtering Configuration
z Three PIM-SM domains exist in the network, and OSPF runs within and among the domains to
provide unicast routing.
z Configure respective Loopback 0 of Switch A, Switch C and Switch D as a C-BSR and C-RP in the
respective PIM-SM domain.
z Set up an MSDP peering relationship between Switch A and Switch C and between Switch C and
Switch D.
z Source 1 sends multicast data to multicast groups 225.1.1.0/30 and 226.1.1.0/30, and Source 2
sends multicast data to multicast group 227.1.1.0/30.
z Configure SA message filtering rules so that receivers Host A and Host B can receive only the
multicast data addressed to multicast groups 225.1.1.0/30 and 226.1.1.0/30, while Host can
receive only the multicast data addressed to multicast groups 226.1.1.0/30 and 227.1.1.0/30.
Network diagram
Figure 1-12 Network diagram for SA message filtering configuration (on switches)
Vlan-int102
Loop0
Vlan-int102

Source 1 - 10.110.3.100/24 Switch C Vlan-int300 10.110.4.1/24
Source 2 - 10.110.6.100/24 Vlan-int104 10.110.5.1/24
Switch A Vlan-int100 10.110.1.1/24 Vlan-int101 192.168.1.2/24
Vlan-int102 10.110.2.1/24 Vlan-int103 192.168.2.2/24
Vlan-int101 192.168.1.1/24 Loop0 2.2.2.2/32
Loop0 1.1.1.1/32 Switch D Vlan-int400 10.110.6.1/24
Vlan-int102 10.110.2.2/24 Vlan-int104 10.110.5.2/24
Vlan-int103 192.168.2.1/24 Loop0 3.3.3.3/32
1-45

Configure OSPF for interoperation among the switches. Ensure the network-layer interoperation within
and between the PIM-SM domains and ensure dynamic update of routing information among the
switches by leveraging unicast routing. The detailed configuration steps are omitted here.
2) Enable IP multicast routing, PIM-SM and IGMP, and configure a PIM domain border
# On Switch A, enable IP multicast routing, enable PIM-SM on each interface, and enable IGMP on the
host-side interface, VLAN-interface 100.
[SwitchA] interface loopback 0
[SwitchA-LoopBack0] pim sm
[SwitchA-LoopBack0] quit
The configuration on Switch B, Switch C and Switch D is similar to the configuration on Switch A. The
# Configure a PIM domain border on Switch C.
[SwitchC-Vlan-interface101] pim bsr-boundary
The configuration on Switch A, Switch B and Switch D is similar to the configuration on Switch C. The
# Configure Loopback 0 on Switch A as a C-BSR and a C-RP.
[SwitchA] pim
[SwitchA-pim] c-bsr loopback 0
[SwitchA-pim] c-rp loopback 0
1-46
[SwitchA-pim] quit
The configuration on Switch C and Switch D is similar to the configuration on Switch A. The specific
# Configure an MSDP peer on Switch A.
[SwitchA] msdp
[SwitchA-msdp] peer 192.168.1.2 connect-interface vlan-interface 101
[SwitchA-msdp] quit
# Configure MSDP peers on Switch C.

[SwitchC] msdp
[SwitchC-msdp] quit
# Configure an MSDP peer on Switch D.

[SwitchD] msdp
[SwitchD-msdp] peer 10.110.5.1 connect-interface vlan-interface 104
[SwitchD-msdp] quit
5) Configure SA message filtering rules
# Configure an SA message rule on Switch C so that Switch C will not forward SA messages for (Source
1, 225.1.1.0/30) to Switch D.
[SwitchC-acl-adv-3001] rule deny ip source 10.110.3.100 0 destination 225.1.1.0 0.0.0.3
[SwitchC-acl-adv-3001] rule permit ip source any destination any
[SwitchC-acl-adv-3001] quit
[SwitchC] msdp
[SwitchC-msdp] peer 10.110.5.2 sa-policy export acl 3001
[SwitchC-msdp] quit
# Configure an SA message rule on Switch D so that Switch D will not create SA messages for Source
2.
[SwitchD-acl-basic-2001] rule deny source 10.110.6.100 0
[SwitchD] msdp
[SwitchD-msdp] import-source acl 2001
[SwitchD-msdp] quit
View the (S, G) entries cached in the SA cache on the switches using the display msdp sa-cache
# View the (S, G) entries cached in the SA cache on Switch C.
[SwitchC] display msdp sa-cache
1-47
(10.110.3.100, 225.1.1.0) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.1) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.2) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.3) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.0) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.1) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.2) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.3) 1.1.1.1 ? ? 02:03:30 00:05:31
# View the (S, G) entries cached in the SA cache on Switch D.

[SwitchD] display msdp sa-cache

(10.110.3.100, 226.1.1.0) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.1) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.2) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.3) 1.1.1.1 ? ? 00:32:53 00:05:07
Troubleshooting MSDP
MSDP Peers Stay in Down State
Symptom
The configured MSDP peers stay in the down state.
Analysis
z A TCP connectionbased MSDP peering relationship is established between the local interface
address and the MSDP peer after the configuration.
z The TCP connection setup will fail if there is a consistency between the local interface address and
the MSDP peer address configured on the router.
z If no route is available between the MSDP peers, the TCP connection setup will also fail.
Solution
1) Check that a route is available between the routers. Carry out the display ip routing-table
command to check whether the unicast route between the routers is correct.
2) Check that a unicast route is available between the two routers that will become MSDP peers to
each other.
3) Verify the interface address consistency between the MSDP peers. Use the display
current-configuration command to verify that the local interface address and the MSDP peer
address of the remote router are the same.
1-48
No SA Entries in the Routers SA Cache
Symptom
MSDP fails to send (S, G) entries through SA messages.
Analysis
z The import-source command is used to control sending (S, G) entries through SA messages to
MSDP peers. If this command is executed without the acl-number argument, all the (S, G) entries
will be filtered off, namely no (S, G) entries of the local domain will be advertised.
z If the import-source command is not executed, the system will advertise all the (S, G) entries of
the local domain. If MSDP fails to send (S, G) entries through SA messages, check whether the
import-source command has been correctly configured.
Solution
2) Check that a unicast route is available between the two routers that will become MSDP peers to
each other.
3) Check configuration of the import-source command and its acl-number argument and make sure
that ACL rule can filter appropriate (S, G) entries.
Inter-RP Communication Faults in Anycast RP Application
Symptom
RPs fail to exchange their locally registered (S, G) entries with one another in the Anycast RP
application.
Analysis
z In the Anycast RP application, RPs in the same PIM-SM domain are configured to be MSDP peers
to achieve load balancing among the RPs.
z An MSDP peer address must be different from the anycast RP address, and the C-BSR and C-RP
must be configured on different devices or interfaces.
z If the originating-rp command is executed, MSDP will replace the RP address in the SA
messages with the address of the interface specified in the command.
z When an MSDP peer receives an SA message, it performs RPF check on the message. If the
MSDP peer finds that the remote RP address is the same as the local RP address, it will discard
the SA message.
Solution
2) Check that a unicast route is available between the two routers that will become MSDP peer to
each other.
3) Check the configuration of the originating-rp command. In the Anycast RP application
environment, be sure to use the originating-rp command to configure the RP address in the SA
messages, which must be the local interface address.
4) Verify that the C-BSR address is different from the anycast RP address.
1-49
Table of Contents
1 PIM Configuration1-1
PIM Overview1-1
Introduction to PIM-DM1-2
How PIM-DM Works 1-2
Introduction to PIM-SM1-5
How PIM-SM Works 1-6
Introduction to Administrative Scoping in PIM-SM 1-10
SSM Model Implementation in PIM 1-12
Multi-Instance PIM1-13
Configuring PIM-DM1-13
PIM-DM Configuration Task List 1-13
Enabling PIM-DM 1-14
Enabling State-Refresh Capability 1-15
Configuring State-Refresh Parameters 1-15
Configuring PIM-DM Graft Retry Period1-16
Configuring PIM-SM1-17
PIM-SM Configuration Task List1-17
Enabling PIM-SM1-18
Configuring an RP 1-19
Configuring a BSR1-21
Configuring Administrative Scoping 1-24
Configuring Multicast Source Registration 1-26
Configuring RPT-to-SPT Switchover1-27
Configuring PIM-SSM 1-28
PIM-SSM Configuration Task List 1-28
Enabling PIM-SM1-29
Configuring the SSM Group Range1-30
Configuring PIM Common Features 1-31
PIM Common Feature Configuration Task List 1-31
Configuring a Multicast Data Filter 1-32
Configuring PIM Hello Options 1-32
Configuring PIM Common Timers 1-34
Configuring Join/Prune Message Sizes 1-35
Displaying and Maintaining PIM1-36
PIM Configuration Examples (On Routers)1-37
PIM-DM Configuration Example1-37
PIM-SM Non-Scoped Zone Configuration Example1-40
PIM-SM Admin-scope Zone Configuration Example1-45
i
PIM-SSM Configuration Example1-52
PIM Configuration Examples (On Switches)1-55
PIM-DM Configuration Example1-55
PIM-SM Non-Scoped Zone Configuration Example1-59
PIM-SM Admin-Scope Zone Configuration Example 1-63
PIM-SSM Configuration Example1-70
Troubleshooting PIM Configuration 1-73
Failure of Building a Multicast Distribution Tree Correctly 1-73
Multicast Data Abnormally Terminated on an Intermediate Router 1-74
RPs Unable to Join SPT in PIM-SM1-75
RPT Establishment Failure or Source Registration Failure in PIM-SM1-75
ii

VPN multi-instance Yes Yes Yes Yes
Yes Yes Yes Yes
(Include/Exclude)
1 PIM Configuration
When configuring PIM, go to these sections for information you are interested in:
z PIM Overview
z Configuring PIM-DM
z Configuring PIM-SM
z Configuring PIM-SSM
z Configuring PIM Common Features
z Displaying and Maintaining PIM
z PIM Configuration Examples (On Routers)
z PIM Configuration Examples (On Switches)
z Troubleshooting PIM Configuration
z The term router in this document refers to a router in a generic sense or a Layer 3 switch running
the PIM protocol.
PIM Overview
Protocol Independent Multicast (PIM) provides IP multicast forwarding by leveraging static routes or
unicast routing tables generated by any unicast routing protocol, such as routing information protocol
(RIP), open shortest path first (OSPF), intermediate system to intermediate system (IS-IS), or border
gateway protocol (BGP). Independent of the unicast routing protocols running on the device, multicast
1-1
routing can be implemented as long as the corresponding multicast routing entries are created through
unicast routes. PIM uses the reverse path forwarding (RPF) mechanism to implement multicast
forwarding. When a multicast packet arrives on an interface of the device, it is subject to an RPF check.
If the RPF check succeeds, the device creates the corresponding routing entry and forwards the packet;
if the RPF check fails, the device discards the packet. For more information about RPF, refer to
Multicast Routing and Forwarding Configuration in the IP Multicast Volume.
Based on the implementation mechanism, PIM falls into two modes:
z Protocol Independent MulticastDense Mode (PIM-DM), and
z Protocol Independent MulticastSparse Mode (PIM-SM).
To facilitate description, a network comprising PIM-capable routers is referred to as a PIM domain in

this document.
Introduction to PIM-DM
PIM-DM is a type of dense mode multicast protocol. It uses the push mode for multicast forwarding,
and is suitable for small-sized networks with densely distributed multicast members.
The basic implementation of PIM-DM is as follows:
z PIM-DM assumes that at least one multicast group member exists on each subnet of a network,
and therefore multicast data is flooded to all nodes on the network. Then, branches without
multicast forwarding are pruned from the forwarding tree, leaving only those branches that contain
receivers. This flood and prune process takes place periodically, that is, pruned branches resume
multicast forwarding when the pruned state times out and then data is re-flooded down these
branches, and then are pruned again.
z When a new receiver on a previously pruned branch joins a multicast group, to reduce the join
latency, PIM-DM uses a graft mechanism to resume data forwarding to that branch.
Generally speaking, the multicast forwarding path is a source tree, namely a forwarding tree with the
multicast source as its root and multicast group members as its leaves. Because the source tree is
the shortest path from the multicast source to the receivers, it is also called shortest path tree (SPT).
How PIM-DM Works
The working mechanism of PIM-DM is summarized as follows:

z Neighbor discovery
z SPT building
z Graft
z Assert
Neighbor discovery
In a PIM domain, a PIM router discovers PIM neighbors, maintains PIM neighboring relationships with
other routers, and builds and maintains SPTs by periodically multicasting hello messages to all other
PIM routers (224.0.0.13).
1-2
Every PIM-enabled interface on a router sends hello messages periodically, and thus learns the PIM
neighboring information pertinent to the interface.
SPT establishment
The process of building an SPT is the process of flood and prune.

1) In a PIM-DM domain, when a multicast source S sends multicast data to multicast group G, the
multicast packet is first flooded throughout the domain: The router first performs RPF check on the
multicast packet. If the packet passes the RPF check, the router creates an (S, G) entry and
forwards the data to all downstream nodes in the network. In the flooding process, an (S, G) entry is
created on all the routers in the PIM-DM domain.
2) Then, nodes without receivers downstream are pruned: A router having no receivers downstream
sends a prune message to the upstream node to tell the upstream node to delete the
corresponding interface from the outgoing interface list in the (S, G) entry and stop forwarding
subsequent packets addressed to that multicast group down to this node.
z An (S, G) entry contains the multicast source address S, multicast group address G, outgoing
interface list, and incoming interface.
z For a given multicast stream, the interface that receives the multicast stream is referred to as
upstream, and the interfaces that forward the multicast stream are referred to as downstream.
A prune process is first initiated by a leaf router. As shown in Figure 1-1, a router without any receiver
attached to it (the router connected with Host A, for example) sends a prune message, and this prune
process goes on until only necessary branches are left in the PIM-DM domain. These branches
constitute the SPT.
1-3
Figure 1-1 SPT establishment
The flood and prune process takes place periodically. A pruned state timeout mechanism is provided.
A pruned branch restarts multicast forwarding when the pruned state times out and then is pruned again
when it no longer has any multicast receiver.
Pruning has a similar implementation in PIM-SM.
Graft
When a host attached to a pruned node joins a multicast group, to reduce the join latency, PIM-DM uses
a graft mechanism to resume data forwarding to that branch. The process is as follows:
1) The node that needs to receive multicast data sends a graft message toward its upstream node, as
a request to join the SPT again.
2) Upon receiving this graft message, the upstream node puts the interface on which the graft was
received into the forwarding state and responds with a graft-ack message to the graft sender.
3) If the node that sent a graft message does not receive a graft-ack message from its upstream node,
it will keep sending graft messages at a configurable interval until it receives an acknowledgment
from its upstream node.
Assert
The assert mechanism is used to shutoff duplicate multicast flows onto the same multi-access network,
where more than one multicast routers exists, by electing a unique multicast forwarder on the
multi-access network.
1-4
Figure 1-2 Assert mechanism
As shown in Figure 1-2, after Router A and Router B receive an (S, G) packet from the upstream node,
they both forward the packet to the local subnet. As a result, the downstream node Router C receives
two identical multicast packets, and both Router A and Router B, on their own local interface, receive a
duplicate packet forwarded by the other. Upon detecting this condition, both routers send an assert
message to all PIM routers (224.0.0.13) through the interface on which the packet was received. The
assert message contains the following information: the multicast source address (S), the multicast
group address (G), and the preference and metric of the unicast route to the source. By comparing
these parameters, either Router A or Router B becomes the unique forwarder of the subsequent (S, G)
packets on the multi-access subnet. The comparison process is as follows:
1) The router with a higher unicast route preference to the source wins;
2) If both routers have the same unicast route preference to the source, the router with a smaller
metric to the source wins;
3) If there is a tie in route metric to the source, the router with a higher IP address of the local interface
wins.
Introduction to PIM-SM
PIM-DM uses the flood and prune principle to build SPTs for multicast data distribution. Although an
SPT has the shortest path, it is built with a low efficiency. Therefore the PIM-DM mode is not suitable for
large- and medium-sized networks.
PIM-SM is a type of sparse mode multicast protocol. It uses the pull mode for multicast forwarding,
and is suitable for large- and medium-sized networks with sparsely and widely distributed multicast
group members.
The basic implementation of PIM-SM is as follows:
z PIM-SM assumes that no hosts need to receive multicast data. In the PIM-SM mode, routers must
specifically request a particular multicast stream before the data is forwarded to them. The core
task for PIM-SM to implement multicast forwarding is to build and maintain rendezvous point trees
(RPTs). An RPT is rooted at a router in the PIM domain as the common node, or rendezvous point
(RP), through which the multicast data travels along the RPT and reaches the receivers.
z When a receiver is interested in the multicast data addressed to a specific multicast group, the
router connected to this receiver sends a join message to the RP corresponding to that multicast
group. The path along which the message goes hop by hop to the RP forms a branch of the RPT.
z When a multicast source sends multicast streams to a multicast group, the source-side designated
router (DR) first registers the multicast source with the RP by sending register messages to the RP
1-5
by unicast until it receives a register-stop message from the RP. The arrival of a register message
at the RP triggers the establishment of an SPT. Then, the multicast source sends subsequent
multicast packets along the SPT to the RP. Upon reaching the RP, the multicast packet is
duplicated and delivered to the receivers along the RPT.
Multicast traffic is duplicated only where the distribution tree branches, and this process automatically
repeats until the multicast traffic reaches the receivers.
How PIM-SM Works
The working mechanism of PIM-SM is summarized as follows:

z DR election
z RP discovery
z RPT building
z Multicast source registration
z Switchover from RPT to SPT
z Assert
Neighbor discovery
PIM-SM uses a similar neighbor discovery mechanism as PIM-DM does. For details, refer to Neighbor
discovery.
DR election
PIM-SM also uses hello messages to elect a DR for a multi-access network (such as Ethernet). The
elected DR will be the only multicast forwarder on this multi-access network.
A DR must be elected in a multi-access network, no matter this network connects to multicast sources
or to receivers. The DR at the receiver side sends join messages to the RP; the DR at the multicast
source side sends register messages to the RP.
z A DR is elected on a multi-access subnet by means of comparison of the priorities and IP

addresses carried in hello messages. An elected DR is substantially meaningful to PIM-SM.
PIM-DM itself does not require a DR. However, if IGMPv1 runs on any multi-access network in a
PIM-DM domain, a DR must be elected to act as the IGMPv1 querier on that multi-access network.
z IGMP must be enabled on a device that acts as a DR before receivers attached to this device can
join multicast groups through this DR.
For details about IGMP, refer to IGMP Configuration in the IP Multicast Volume.
1-6
Figure 1-3 DR election
Receiver
DR
DR RP
Source
Receiver
Hello message
Register message
Join message
As shown in Figure 1-3, the DR election process is as follows:

1) Routers on the multi-access network send hello messages to one another. The hello messages
contain the router priority for DR election. The router with the highest DR priority will become the
DR.
2) In the case of a tie in the router priority, or if any router in the network does not support carrying the
DR-election priority in hello messages, the router with the highest IP address will win the DR
election.
When the DR fails, a timeout in receiving hello message triggers a new DR election process among the
other routers.
RP discovery
The RP is the core of a PIM-SM domain. For a small-sized, simple network, one RP is enough for
forwarding information throughout the network, and the position of the RP can be statically specified on
each router in the PIM-SM domain. In most cases, however, a PIM-SM network covers a wide area and
a huge amount of multicast traffic needs to be forwarded through the RP. To lessen the RP burden and
optimize the topological structure of the RPT, each RP serves a different multicast group range.
Therefore, a bootstrap mechanism is needed for dynamic RP election. For this purpose, a bootstrap
router (BSR) should be configured.
As the administrative core of a PIM-SM domain, the BSR collects advertisement messages (C-RP-Adv
messages) from candidate-RPs (C-RPs) and chooses the appropriate C-RP information for each
multicast group to form an RP-set, which is a database of mappings between multicast groups and RPs.
The BSR then floods the RP-set to the entire PIM-SM domain. Based on the information in these
RP-sets, all routers (including the DRs) in the network can calculate the location of the corresponding
RPs.
A PIM-SM domain (or an administratively scoped region) can have only one BSR, but can have multiple
candidate-BSRs (C-BSRs). Once the BSR fails, a new BSR is automatically elected from the C-BSRs
through the bootstrap mechanism to avoid service interruption. Similarly, multiple C-RPs can be
configured in a PIM-SM domain, and the position of the RP corresponding to each multicast group is
calculated through the BSR mechanism.
1-7
A device can act as a C-RP and a C-BSR at the same time.
Figure 1-4 shows the positions of C-RPs and the BSR in the network.
Figure 1-4 BSR and C-RPs
RPT establishment
Figure 1-5 RPT establishment in a PIM-SM domain
As shown in Figure 1-5, the process of building an RPT is as follows:

1) When a receiver joins multicast group G, it uses an IGMP message to inform the directly connected
DR.
2) Upon getting the receiver information, the DR sends a join message, which is hop by hop
forwarded to the RP corresponding to the multicast group.
1-8
3) The routers along the path from the DR to the RP form an RPT branch. Each router on this branch
generates a (*, G) entry in its forwarding table. The * means any multicast source. The RP is the
root, while the DRs are the leaves, of the RPT.
The multicast data addressed to the multicast group G flows through the RP, reaches the corresponding
DR along the established RPT, and finally is delivered to the receiver.
When a receiver is no longer interested in the multicast data addressed to multicast group G, the directly
connected DR sends a prune message, which goes hop by hop along the RPT to the RP. Upon
receiving the prune message, the upstream node deletes the interface connected with this downstream
node from the outgoing interface list and checks whether it itself has receivers for that multicast group.
If not, the router continues to forward the prune message to its upstream router.
Multicast source registration
The purpose of multicast source registration is to inform the RP about the existence of the multicast
source.
Figure 1-6 Multicast source registration
Host A
Source
Receiver
DR RP
Server Host B
Receiver
SPT
Join message
Register message
Host C
Multicast packets
As shown in Figure 1-6, the multicast source registers with the RP as follows:
1) When the multicast source S sends the first multicast packet to multicast group G, the DR directly
connected with the multicast source, upon receiving the multicast packet, encapsulates the packet
in a PIM register message, and sends the message to the corresponding RP by unicast.
2) When the RP receives the register message, it extracts the multicast packet from the register
message and forwards the multicast packet down the RPT, and sends an (S, G) join message hop
by hop toward the multicast source. Thus, the routers along the path from the RP to the multicast
source constitute an SPT branch. Each router on this branch generates an (S, G) entry in its
forwarding table. The multicast source is the root, while the RP is the leaf, of the SPT.
3) The subsequent multicast data from the multicast source travels along the established SPT to the
RP, and then the RP forwards the data along the RPT to the receivers. When the multicast traffic
arrives at the RP along the SPT, the RP sends a register-stop message to the source-side DR by
unicast to stop the source registration process.
1-9
Switchover from RPT to SPT
Initially, multicast traffic flows along an RPT from the RP to the receivers. Because the RPT is not
necessarily the tree that has the shortest path, upon receiving the first multicast packet along the RPT
(by default), or when detecting that the multicast traffic rate reaches a configurable threshold (if so
configured), the receiver-side DR initiates an RPT-to-SPT switchover process, as follows:
1) First, the receiver-side DR sends an (S, G) join message hop by hop to the multicast source. When
the join message reaches the source-side DR, all the routers on the path have installed the (S, G)
entry in their forwarding table, and thus an SPT branch is established.
2) Subsequently, the receiver-side DR sends an RP-bit prune message hop by hop to the RP. Upon
receiving this prune message, the RP sends a prune message toward the multicast source
(suppose only one receiver exists), thus to implement RPT-to-SPT switchover.
After the RPT-to-SPT switchover, multicast data can be directly sent from the source to the receivers.
PIM-SM builds SPTs through RPT-to-SPT switchover more economically than PIM-DM does through
the flood and prune mechanism.
Assert
PIM-SM uses a similar assert mechanism as PIM-DM does. For details, refer to Assert.
Introduction to Administrative Scoping in PIM-SM
Division of PIM-SM domains
Typically, a PIM-SM domain contains only one BSR, which is responsible for advertising RP-set
information within the entire PIM-SM domain. The information for all multicast groups is forwarded
within the network scope administered by the BSR. We call this non-scoped BSR mechanism.
To implement refined management, a PIM-SM domain can be divided into one global scope zone and
multiple administratively scoped zones (admin-scope zones). We call this administrative scoping
mechanism.
The administrative scoping mechanism effectively releases stress on the management in a single-BSR
domain and enables provision of zone-specific services using private group addresses.
Admin-scope zones are divided specific to multicast groups. The boundary of the admin-scope zone is
formed by zone border routers (ZBRs). Each admin-scope zone maintains one BSR, which serves
multicast groups within a specific range. Multicast protocol packets, such as assert messages and
bootstrap messages, for a specific group range cannot cross the admin-scope zone boundary. Multicast
group ranges served by different admin-scope zones can be overlapped. A multicast group is valid only
within its local admin-scope zone, functioning as a private group address.
The global scope zone maintains a BSR, which serves the multicast groups that do not belong to any
admin-scope zone.
Relationship between admin-scope zones and the global scope zone
The global scope zone and each admin-scope zone have their own C-RPs and BSRs. These devices
are effective only in their respective admin-scope zones. Namely, BSR election and RP election are
implemented independently within each admin-scope zone. Each admin-scope zone has its own
boundary. The multicast information cannot cross this border in either direction. A better understanding
of the global scope zone and admin-scope zones should be based on two aspects: geographical space
and group address range.
1-10
1) Geographical space
Admin-scope zones are logical zones specific to particular multicast groups, and each admin-scope
zone must be geographically independent of every other one, as shown in Figure 1-7.
Figure 1-7 Relationship between admin-scope zones and the global scope zone in geographic space
Admin-scope zones are geographically separated from one another. Namely, a router must not serve
different admin-scope zones. In other words, different admin-scope zones contain different routers,
whereas the global scope zone covers all routers in the PIM-SM domain.
2) In terms of multicast group address ranges
Each admin-scope zone serves specific multicast groups. Usually, these addresses have no
intersections; however, they may overlap one another.
Figure 1-8 Relationship between admin-scope zones and the global scope zone in group address
ranges
In Figure 1-8, the group address ranges of admin-scope 1 and 2 have no intersection, whereas the
group address range of admin-scope 3 is a subset of the address range of admin-scope 1. The group
address range of the global scope zone covers all the group addresses other than those of all the
admin-scope zones. That is, the group address range of the global scope zone is G-G1-G2. In other
words, there is a supplementary relationship between the global scope zone and all the admin-scope
zones in terms of group address ranges.
1-11
SSM Model Implementation in PIM
The source-specific multicast (SSM) model and the any-source multicast (ASM) model are two opposite
models. Presently, the ASM model includes the PIM-DM and PIM-SM modes. The SSM model can be
implemented by leveraging part of the PIM-SM technique.
The SSM model provides a solution for source-specific multicast. It maintains the relationships between
hosts and routers through IGMPv3.
In actual application, part of the PIM-SM technique is adopted to implement the SSM model. In the SSM
model, receivers know exactly where a multicast source is located by means of advertisements,
consultancy, and so on. Therefore, no RP is needed, no RPT is required, there is no source registration
process, and there is no need of using the multicast source discovery protocol (MSDP) for discovering
sources in other PIM domains.
Compared with the ASM model, the SSM model only needs the support of IGMPv3 and some subsets
of PIM-SM. The operation mechanism of PIM-SSM can be summarized as follows:
z DR election
z SPT building
Neighbor discovery
PIM-SSM uses the same neighbor discovery mechanism as in PIM-DM and PIM-SM. Refer to Neighbor
discovery.
DR election
PIM-SSM uses the same DR election mechanism as in PIM-SM. Refer to DR election.
Construction of SPT
Whether to build an RPT for PIM-SM or an SPT for PIM-SSM depends on whether the multicast group
the receiver is to join falls in the SSM group range (SSM group range reserved by IANA is 232.0.0.0/8).
Figure 1-9 SPT establishment in PIM-SSM
As shown in Figure 1-9, Host B and Host C are multicast information receivers. They send IGMPv3
report messages denoted as (Include S, G) to the respective DRs to express their interest in the
1-12
information of the specific multicast source S. If they need information from other sources than S, they
send an (Exclude S, G) report. No matter what the description is, the position of multicast source S is
explicitly specified for receivers.
The DR that has received the report first checks whether the group address in this message falls in the
SSM group range:
z If so, the DR sends a subscribe message for channel subscription hop by hop toward the multicast
source S. An (Include S, G) or (Exclude S, G) entry is created on all routers on the path from the DR
to the source. Thus, an SPT is built in the network, with the source S as its root and receivers as its
leaves. This SPT is the transmission channel in PIM-SSM.
z If not, the PIM-SM process is followed: the DR needs to send a (*, G) join message to the RP, and
a multicast source registration process is needed.
z In PIM-SSM, the channel concept is used to refer to a multicast group, and the channel
subscription concept is used to refer to a join message.
z The support of the exclude mode varies with device models.
Multi-Instance PIM
A multicast router running multiple instances maintains an independent set of PIM neighbor table,
multicast routing table, BSR information and RP-set information for each instance.
Upon receiving a multicast data packet, the multicast router determines the VPN instance the data
packet belongs to, and then forwards the packet as per the multicast routing table of that VPN instance
or creates a multicast routing table entry for that VPN instance.
PIM-related specifications are as follows:

z RFC 4601: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
(Revised)
z RFC 3973: Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol
Specification(Revised)
z RFC 4607: Source-Specific Multicast for IP
z draft-ietf-pim-sm-bsr-09: Bootstrap Router (BSR) Mechanism for PIM
z draft-ietf-ssm-overview-05: An Overview of Source-Specific Multicast (SSM)
Configuring PIM-DM
PIM-DM Configuration Task List
Complete these tasks to configure PIM-DM:
Task Remarks
Enabling PIM-DM Required
Enabling State-Refresh Capability Optional
1-13
Task Remarks
Configuring State-Refresh Parameters Optional
Configuring PIM-DM Graft Retry Period Optional
Configuring PIM Common Features Optional
Before configuring PIM-DM, complete the following task:

network layer.
Before configuring PIM-DM, prepare the following data:
z The interval between state-refresh messages
z Minimum time to wait before receiving a new refresh message
z TTL value of state-refresh messages
z Graft retry period
Enabling PIM-DM
With PIM-DM enabled, a router sends hello messages periodically to discover PIM neighbors and
processes messages from the PIM neighbors. When deploying a PIM-DM domain, you are
recommended to enable PIM-DM on all non-border interfaces of the routers.
Enabling PIM-DM globally in the public instance
Follow these steps to enable PIM-DM globally in the public instance:

Required
Disable by default
interface-number
Required
Enable PIM-DM pim dm
Disabled by default
Enabling PIM-DM in a VPN instance
Follow these steps to enable PIM-DM in a VPN instance:
To do... Use the command... Description


(RD) for the VPN instance route-distinguisher Not configured by default
1-14
Required
Disabled by default
interface-number
Required
Enable PIM-DM pim dm
Disabled by default
z All the interfaces in the same VPN instance on the same device must work in the same PIM mode.
z PIM-DM does not work with multicast groups in the SSM group grange.
Enabling State-Refresh Capability
An interface without the state-refresh capability cannot forward state-refresh messages. It is

recommended to keep the state-refresh capability enabled on all routers in the PIM-DM domain.
Follow these steps to enable the state-refresh capability:

interface-number
Optional
Enable state-refresh pim state-refresh-capable
Enabled by default
Configuring State-Refresh Parameters
To avoid the resource-consuming reflooding of unwanted traffic caused by timeout of pruned interfaces,
the router directly connected with the multicast source periodically sends an (S, G) state-refresh
message, which is forwarded hop by hop along the initial multicast flooding path of the PIM-DM domain,
to refresh the prune timer state of all the routers on the path.
A router may receive multiple state-refresh messages within a short time, of which some may be
duplicated messages. To keep a router from receiving such duplicated messages, you can configure
1-15
the time the router must wait before receiving the next state-refresh message. If a new state-refresh
message is received within the waiting time, the router will discard it; if this timer times out, the router
will accept a new state-refresh message, refresh its own PIM-DM state, and reset the waiting timer.
The TTL value of a state-refresh message decrements by 1 whenever it passes a router before it is
forwarded to the downstream node until the TTL value comes down to 0. In a small network, a
state-refresh message may cycle in the network. To effectively control the propagation scope of
state-refresh messages, you need to configure an appropriate TTL value based on the network size.
It is recommended to perform the following configurations on all routers in the PIM domain.
Follow these steps to configure state-refresh parameters:

Enter public instance PIM view pim [ vpn-instance

or VPN instance PIM view vpn-instance-name ]
Configure the interval between Optional

state-refresh-interval interval
state-refresh messages 60 seconds by default
Configure the time to wait Optional
state-refresh-rate-limit
before receiving a new
state-refresh message
Configure the TTL value of Optional

state-refresh-ttl ttl-value
state-refresh messages 255 by default
Configuring PIM-DM Graft Retry Period
In PIM-DM, graft is the only type of message that uses the acknowledgment mechanism. In a PIM-DM
domain, if a router does not receive a graft-ack message from the upstream router within the specified
time after it sends a graft message, the router keeps sending new graft messages at a configurable
interval, namely graft retry period, until it receives a graft-ack from the upstream router.
Follow these steps to configure graft retry period:

interface-number
Optional
Configure graft retry period pim timer graft-retry interval
For the configuration of other timers in PIM-DM, refer to Configuring PIM Common Timers.
1-16
Configuring PIM-SM
PIM-SM Configuration Task List
Complete these tasks to configure PIM-SM:
Task Remarks
Configuring PIM-SM Required
Configuring a static RP Optional
Configuring a C-RP Optional
Configuring an RP
Enabling auto-RP Optional
Configuring C-RP timers globally Optional
Configuring a C-BSR Optional

Configuring a PIM domain border Optional
Configuring a BSR
Configuring global C-BSR parameters Optional
Configuring C-BSR timers Optional
Enabling administrative scoping Optional
Configuring
Configuring an admin-scope zone boundary Optional
Administrative Scoping
Configuring a C-BSR for each zone Optional
Configuring Multicast Source Registration Optional
Configuring RPT-to-SPT Switchover Optional

Before configuring PIM-SM, complete the following task:

network layer.
Before configuring PIM-SM, prepare the following data:
z The IP address of a static RP and an ACL rule defining the range of multicast groups to be served
by the static RP
z C-RP priority and an ACL rule defining the range of multicast groups to be served by each C-RP
z A legal C-RP address range and an ACL rule defining the range of multicast groups to be served
z C-RP-Adv interval
z C-RP timeout
z C-BSR priority
z Hash mask length for RP selection calculation
z An ACL rule defining a legal BSR address range
z BS period
z BS timeout
z An ACL rule for register message filtering
z Register suppression time
z Register probe time
1-17
z The multicast traffic rate threshold, ACL rule, and sequencing rule for RPT-to-SPT switchover
z The interval of checking the traffic rate threshold before RPT-to-SPT switchover
Enabling PIM-SM
With PIM-SM enabled, a router sends hello messages periodically to discover PIM neighbors and
processes messages from the PIM neighbors. When deploying a PIM-SM domain, you are
recommended to enable PIM-SM on all non-border interfaces of the routers.
Enabling PIM-SM globally in the public instance
Follow these steps to enable PIM-SM in the public instance:

Required
Disable by default
interface-number
Required
Enable PIM-SM pim sm
Disabled by default
Enabling PIM-SM in a VPN instance
Follow these steps to enable PIM-SM in a VPN instance:


(RD) for the VPN instance route-distinguisher Not configured by default
Required
Disabled by default
interface-number
Required
Disabled by default
All the interfaces in the same VPN instance on the same router must work in the same PIM mode.
1-18
Configuring an RP
An RP can be manually configured or dynamically elected through the BSR mechanism. For a large
PIM network, static RP configuration is a tedious job. Generally, static RP configuration is just a backup
means for the dynamic RP election mechanism to enhance the robustness and operation manageability
of a multicast network.
Configuring a static RP
If there is only one dynamic RP in a network, manually configuring a static RP can avoid communication
interruption due to single-point failures and avoid frequent message exchange between C-RPs and the
BSR.
Perform this configuration on all the routers in the PIM-SM domain.
Follow these steps to configure a static RP:


static-rp rp-address Required

Configure a static RP
[ acl-number ] [ preferred ] No static RP by default
To enable a static RP to work normally, you must perform this configuration on all the routers in the
PIM-SM domain and specify the same RP address.
Configuring a C-RP
In a PIM-SM domain, you can configure routers that intend to become the RP as C-RPs. The BSR
collects the C-RP information by receiving the C-RP-Adv messages from C-RPs or auto-RP
announcements from other routers and organizes the information into an RP-set, which is flooded
throughout the entire network. Then, the other routers in the network calculate the mappings between
specific group ranges and the corresponding RPs based on the RP-set. We recommend that you
configure C-RPs on backbone routers.
1-19
To guard against C-RP spoofing, you need to configure a legal C-RP address range and the range of
multicast groups to be served on the BSR. In addition, because every C-BSR has a chance to become
the BSR, you need to configure the same filtering policy on all C-BSRs in the PIM-SM domain.
Follow these steps to configure a C-RP:

Enter public instance PIM view
pim [ vpn-instance vpn-instance-name ]
or VPN instance PIM view
c-rp interface-type interface-number Required

Configure an interface to be a [ group-policy acl-number | priority
C-RP priority | holdtime hold-interval | No C-RPs are
advertisement-interval adv-interval ] * configured by default
Configure a legal C-RP Optional

address range and the range of crp-policy acl-number No restrictions by
multicast groups to be served default
z When configuring a C-RP, ensure a relatively large bandwidth between this C-RP and the other
devices in the PIM-SM domain.
z An RP can serve multiple multicast groups or all multicast groups. Only one RP can forward
multicast traffic for a multicast group at a moment.
Enabling auto-RP
Auto-RP announcement and discovery messages are addressed to the multicast group addresses
224.0.1.39 and 224.0.1.40 respectively. With auto-RP enabled on a device, the device can receive
these two types of messages and record the RP information carried in such messages.
Follow these steps to enable auto-RP:


Required
Enable auto-RP auto-rp enable
Disabled by default
Configuring C-RP timers globally
To enable the BSR to distribute the RP-set information within the PIM-SM domain, C-RPs must
periodically send C-RP-Adv messages to the BSR. The BSR learns the RP-set information from the
received messages, and encapsulates its own IP address together with the RP-set information in its
bootstrap messages. The BSR then floods the bootstrap messages to all PIM routers (224.0.0.13) in
the network.
1-20
Each C-RP encapsulates a timeout value in its C-RP-Adv messages. Upon receiving a C_RP-Adv
message, the BSR obtains this timeout value and starts a C-RP timeout timer. If the BSR fails to hear a
subsequent C-RP-Adv message from the C-RP when the timer times out, the BSR assumes the C-RP
to have expired or become unreachable.
The C-RP timers need to be configured on C-RP routers.
Follow these steps to configure C-RP timers globally:


Configure the C-RP-Adv c-rp advertisement-interval Optional

Optional
Configure C-RP timeout time c-rp holdtime interval
For the configuration of other timers in PIM-SM, refer to Configuring PIM Common Timers.
Configuring a BSR
A PIM-SM domain can have only one BSR, but must have at least one C-BSR. Any router can be
configured as a C-BSR. Elected from C-BSRs, the BSR is responsible for collecting and advertising RP
information in the PIM-SM domain.
Configuring a C-BSR
C-BSRs should be configured on routers in the backbone network. When configuring a router as a
C-BSR, be sure to specify a PIM-SM-enabled interface on the router. The BSR election process is
summarized as follows:
z Initially, every C-BSR assumes itself to be the BSR of this PIM-SM domain, and uses its interface
IP address as the BSR address to send bootstrap messages.
z When a C-BSR receives the bootstrap message of another C-BSR, it first compares its own priority
with the other C-BSRs priority carried in message. The C-BSR with a higher priority wins. If there is
a tie in the priority, the C-BSR with a higher IP address wins. The loser uses the winners BSR
address to replace its own BSR address and no longer assumes itself to be the BSR, while the
winner retains its own BSR address and continues assuming itself to be the BSR.
Configuring a legal range of BSR addresses enables filtering of bootstrap messages based on the
address range, thus to prevent a maliciously configured host from masquerading as a BSR. The same
configuration needs to be made on all routers in the PIM-SM domain. The following are typical BSR
spoofing cases and the corresponding preventive measures:
1-21
1) Some maliciously configured hosts can forge bootstrap messages to fool routers and change RP
mappings. Such attacks often occur on border routers. Because a BSR is inside the network
whereas hosts are outside the network, you can protect a BSR against attacks from external hosts
by enabling the border routers to perform neighbor checks and RPF checks on bootstrap
messages and discard unwanted messages.
2) When a router in the network is controlled by an attacker or when an illegal router is present in the
network, the attacker can configure this router as a C-BSR and make it win BSR election to control
the right of advertising RP information in the network. After being configured as a C-BSR, a router
automatically floods the network with bootstrap messages. As a bootstrap message has a TTL
value of 1, the whole network will not be affected as long as the neighbor router discards these
bootstrap messages. Therefore, with a legal BSR address range configured on all routers in the
entire network, all these routers will discard bootstrap messages from out of the legal address
range.
The above-mentioned preventive measures can partially protect the security of BSRs in a network.
However, if a legal BSR is controlled by an attacker, the above-mentioned problem will still occur.
Follow these steps to configure a C-BSR:

Enter public instance or pim [ vpn-instance

VPN instance PIM view vpn-instance-name ]
c-bsr interface-type Required

Configure an interface as
interface-number [ hash-length No C-BSRs are configured by
a C-BSR
[ priority ] ] default.
Optional
Configure a legal BSR
bsr-policy acl-number No restrictions on BSR address
address range
range by default
z Since a large amount of information needs to be exchanged between a BSR and the other devices
in the PIM-SM domain, a relatively large bandwidth should be provided between the C-BSRs and
the other devices in the PIM-SM domain.
z For C-BSRs interconnected via a Generic Routing Encapsulation (GRE) tunnel, multicast static
routes need to be configured to ensure that the next hop to a C-BSR is a GRE interface. For more
information about multicast static routes, refer to Multicast Routing and Forwarding Configuration
in the IP Multicast Volume.
Configuring a PIM domain border
As the administrative core of a PIM-SM domain, the BSR sends the collected RP-Set information in the
form of bootstrap messages to all routers in the PIM-SM domain.
A PIM domain border is a bootstrap message boundary. Each BSR has its specific service scope. A
number of PIM domain border interfaces partition a network into different PIM-SM domains. Bootstrap
messages cannot cross a domain border in either direction
1-22
Perform the following configuration on routers that can become a PIM domain border.
Follow these steps to configure a PIM domain border:

interface-number
Required
Configure a PIM domain border pim bsr-boundary By default, no PIM domain
border is configured.
Configuring global C-BSR parameters
In each PIM-SM domain, a unique BSR is elected from C-BSRs. The C-RPs in the PIM-SM domain
send advertisement messages to the BSR. The BSR summarizes the advertisement messages to form
an RP-set and advertises it to all routers in the PIM-SM domain. All the routers use the same Hash
algorithm to get the RP address corresponding to specific multicast groups.
Perform the following configuration on C-BSR routers.
Follow these steps to configure C-BSR parameters:

Enter public instance or VPN pim [ vpn-instance

instance PIM view vpn-instance-name ]
Configure the Hash mask Optional
length for RP selection c-bsr hash-length hash-length
calculation 30 by default
Optional
Configure the C-BSR priority c-bsr priority priority
By default, the C-BSR priority is 0.
About the Hash mask length and C-BSR priority for RP selection calculation:
z You can configure these parameters at three levels: global configuration level, global scope zone
level, and admin-scope zone level.
z The value of these parameters configured at the global scope zone level or admin-scope zone level
have preference over the global values.
z If you do not configure these parameters at the global scope zone level or admin-scope zone level,
the corresponding global values will be used.
For configuration of C-BSR parameters for an admin-scope zone and global scope zone, see
Configuring a C-BSR for each zone.
1-23
Configuring C-BSR timers
The BSR election winner multicasts its own IP address and RP-Set information through bootstrap
messages within the entire zone it serves. The BSR floods bootstrap messages throughout the network
at the interval of BS (BSR state) period. Any C-BSR that receives a bootstrap message retains the
RP-set for the length of BS timeout, during which no BSR election takes place. If the BSR state times
out and no bootstrap message is received from the BSR, a new BSR election process is triggered
among the C-BSRs.
Follow these steps to configure C-BSR timers:


Optional
Configure the BS period c-bsr interval interval
For the default value, see the note below.
Optional
Configure the BS timeout c-bsr holdtime interval
About the BS period:

z By default, the BS period is determined by this formula: BS period = (BS timeout 10) / 2. The
default BS timeout is 130 seconds, so the default BS period = (130 10) / 2 = 60 (seconds).
z If this parameter is manually configured, the system will use the configured value.
About the BS timeout:
z By default, the BS timeout value is determined by this formula: BS timeout = BS period 2 + 10.
The default BS period is 60 seconds, so the default BS timeout = 60 2 + 10 = 130 (seconds).
In configuration, make sure that the BS period value is smaller than the BS timeout value.
Configuring Administrative Scoping
With administrative scoping disabled, a PIM-SM domain has only one BSR. The BSR manages the
whole network. To manage your network more effectively and specifically, you can partition the PIM-SM
domain into multiple admin-scope zones. Each admin-scope zone maintains a BSR, which serves a
specific multicast group range; while the global scope zone also maintains a BSR, which serves all the
rest multicast groups.
1-24
Enabling administrative scoping
Before configuring an admin-scope zone, you must enable administrative scoping first.
Perform the following configuration on all routers in the PIM-SM domain.
Follow these steps to enable administrative scoping:

Enter public instance or VPN pim [ vpn-instance

instance PIM view vpn-instance-name ]
Required
Enable administrative scoping c-bsr admin-scope
Disabled by default
Configuring an admin-scope zone boundary
The boundary of each admin-scope zone is formed by ZBRs. Each admin-scope zone maintains a BSR,
which serves a specific multicast group range. Multicast protocol packets (such as assert messages
and bootstrap messages) that belong to this range cannot cross the admin-scope zone boundary.
Perform the following configuration on routers that can become a ZBR.
Follow these steps to configure an admin-scope zone boundary:

interface-number
multicast boundary Required

Configure a multicast
group-address { mask | By default, no multicast forwarding
forwarding boundary
mask-length } boundary is configured.
For details about the multicast boundary command, see Multicast Routing and Forwarding
Configuring a C-BSR for each zone
In a network with administrative scoping enabled, group-range-specific BSRs are elected from C-BSRs.
C-RPs in the network send advertisement messages to the specific BSR. The BSR summarizes the
advertisement messages to form an RP-set and advertises it to all routers in the specific admin-scope
zone. All the routers use the same Hash algorithm to get the RP address corresponding to the specific
multicast group.
Perform the following configuration on the routers that may become C-BSRs in each admin-scope zone
or the global scope zone.
Follow these steps to configure a C-BSR for each zone:
1-25

c-bsr group group-address Required

Configure a C-BSR for an { mask | mask-length }
admin-scope zone [ hash-length hash-length | No C-BSRs are configured for a
priority priority ] * admin-scope zone by default
Required
Configure a C-BSR for the c-bsr global [ hash-length
global-scope zone hash-length | priority priority ] * No C-BSRs are configured for the
global-scope zone by default
About the Hash mask length and C-BSR priority for RP selection calculation:
z You can configure these parameters at three levels: global configuration level, global scope zone
level, and admin-scope zone level.
z The value of these parameters configured at the global scope zone level or admin-scope zone level
have preference over the global values.
z If you do not configure these parameters at the global scope zone level or admin-scope zone level,
the corresponding global values will be used.
For configuration of global C-BSR parameters, see Configuring global C-BSR parameters.
Configuring Multicast Source Registration
Within a PIM-SM domain, the source-side DR sends register messages to the RP, and these register
messages have different multicast source or group addresses. You can configure a filtering rule to filter
register messages so that the RP can serve specific multicast groups. If an (S, G) entry is denied by the
filtering rule, or the action for this entry is not defined in the filtering rule, the RP will send a register-stop
message to the DR to stop the registration process for the multicast data.
In view of information integrity of register messages in the transmission process, you can configure the
device to calculate the checksum based on the entire register messages. However, to reduce the
workload of encapsulating data in register messages and for the sake of interoperability, this method of
checksum calculation is not recommended.
When receivers stop receiving multicast data addressed to a certain multicast group through the RP
(that is, the RP stops serving the receivers of that multicast group), or when the RP formally starts
receiving multicast data from the multicast source, the RP sends a register-stop message to the
source-side DR. Upon receiving this message, the DR stops sending register messages encapsulated
with multicast data and starts a register-stop timer. When the register-stop timer expires, the DR sends
a null register message (a register message without encapsulated multicast data) to the RP. If the DR
receives a register-stop message during the register probe time, it will reset its register-stop timer;
otherwise, the DR starts sending register messages with encapsulated data again when the
register-stop timer expires.
1-26
The register-stop timer is set to a random value chosen uniformly from the interval (0.5 times
register_suppression_time, 1.5 times register_suppression_time) minus register_probe_time.
Configure a filtering rule for register messages on all C-RP routers and configure them to calculate the
checksum based on the entire register messages. Configure the register suppression time and the
register probe time on all routers that may become source-side DRs.
Follow these steps to configure register-related parameters:


Optional
Configure a filtering rule for
register-policy acl-number No register filtering rule by
register messages
default
Optional
Configure the device to
calculate the checksum based register-whole-checksum By default, the checksum is
on the entire register messages calculated based on the header
of register messages
Configure the register register-suppression-timeou Optional

suppression time t interval 60 seconds by default
Configure the register probe Optional

probe-interval interval
time 5 seconds by default
Configuring RPT-to-SPT Switchover
In a PIM-SM network, a multicast stream first flows to the receivers down an RPT. However, because an
RPT is not necessarily the tree that has the shortest path, the multicast forwarding path needs to be
switched from the RPT to the SPT when the multicast traffic is large. You can configure a traffic rate
threshold (configurable on routers only, but not on switches) at which the receiver-side DR initiates an
RPT-to-SPT switchover process.
Both the receiver-side DR and the RP can periodically check the passing-by multicast packets (this
function is not available with switches) and thus trigger RPT-to-SPT switchover.
Perform the following configuration on routers that may become receiver-side DRs and on C-RP
routers.
Follow these steps to configure RPT-to-SPT switchover:


1-27
Optional
By default, the device switches
spt-switch-threshold
to the SPT immediately after it
Configure RPT-to-SPT { traffic-rate | infinity }
receives the first multicast
switchover [ group-policy acl-number
packet from the RPT.
[ order order-value] ]
The traffic-rate argument is not
supported on a switch.
Configure the interval of
checking the traffic rate Optional
timer spt-switch interval
threshold before RPT-to-SPT 15 seconds by default
switchover
z The support for the timer spt-switch command depends on the specific device model.
z If the multicast source is learned through MSDP, the device will switch to the SPT immediately after
it receives the first multicast packet from the RPT, no matter how big the traffic rate threshold is set
(this threshold is not configurable on a switch).
Configuring PIM-SSM
The PIM-SSM model needs the support of IGMPv3. Therefore, be sure to enable IGMPv3 on PIM
routers with multicast receivers.
PIM-SSM Configuration Task List
Complete these tasks to configure PIM-SSM:
Task Remarks
Enabling PIM-SM Required
Configuring the SSM Group Range Optional
Before configuring PIM-SSM, complete the following task:

network layer.
Before configuring PIM-SSM, prepare the following data:
1-28
z The SSM group range
Enabling PIM-SM
The SSM model is implemented based on some subsets of PIM-SM. Therefore, a router is PIM-SSM
capable after you enable PIM-SM on it.
When deploying a PIM-SM domain, you are recommended to enable PIM-SM on non-border interfaces
of the routers.
Enabling PIM-SM globally in the public instance
Follow these steps to enable PIM-SM globally in the public instance:

Required
Disable by default
interface-number
Required
Disabled by default
Enabling PIM-SM in a VPN instance
Follow these steps to enable PIM-SM in a VPN instance:


Required
Disabled by default
interface-number
Required
Disabled by default
All the interfaces in the same VPN instance on the same device must work in the same PIM mode.
1-29
Configuring the SSM Group Range
As for whether the information from a multicast source is delivered to the receivers based on the
PIM-SSM model or the PIM-SM model, this depends on whether the group address in the (S, G)
channel subscribed by the receivers falls in the SSM group range. All PIM-SM-enabled interfaces
assume that multicast groups within this address range are using the PIM-SSM model.
Perform the following configuration on all routers in the PIM-SM domain.
Follow these steps to configure an SSM multicast group range:


Configure the SSM group Optional

ssm-policy acl-number
range 232.0.0.0/8 by default
z Make sure that the same SSM group range is configured on all routers in the entire domain.
Otherwise, multicast information cannot be delivered through the SSM model.
z When a member of a multicast group in the SSM group range sends an IGMPv1 or IGMPv2 report
message, the device does not trigger a (*, G) join.
1-30
Configuring PIM Common Features
For the functions or parameters that can be configured in both PIM view and interface view described in
this section:
z Configurations performed in PIM view are effective to all interfaces, while configurations performed
in interface view are effective to the current interface only.
z If the same function or parameter is configured in both PIM view and interface view, the
configuration made in interface view has preference over the configuration made in PIM view,
regardless of the configuration sequence.
PIM Common Feature Configuration Task List
Complete these tasks to configure PIM common features:
Task Remarks
Configuring a Multicast Data Filter Optional
Configuring PIM Hello Options Optional
Configuring PIM Common Timers Optional
Configuring Join/Prune Message Sizes Optional
Before configuring PIM common features, complete the following tasks:

network layer.
z Configure PIM-DM, or PIM-SM, or PIM-SSM.
Before configuring PIM common features, prepare the following data:
z An ACL rule for filtering multicast data
z Priority for DR election (global value/interface level value)
z PIM neighbor timeout time (global value/interface value)
z Prune delay (global value/interface level value)
z Prune override interval (global value/interface level value)
z Hello interval (global value/interface level value)
z Maximum delay between hello message (interface level value)
z Assert timeout time (global value/interface value)
z Join/prune interval (global value/interface level value)
z Join/prune timeout (global value/interface value)
z Multicast source lifetime
z Maximum size of join/prune messages
z Maximum number of (S, G) entries in a join/prune message
1-31
Configuring a Multicast Data Filter
No matter in a PIM-DM domain or a PIM-SM domain, routers can check passing-by multicast data
based on the configured filtering rules and determine whether to continue forwarding the multicast data.
In other words, PIM routers can act as multicast data filters. These filters can help implement traffic
control on one hand, and control the information available to receivers downstream to enhance data
security on the other hand.
Follow these steps to configure a multicast data filter:


Configure a multicast group Required

source-policy acl-number
filter No multicast data filter by default
z Generally, a smaller distance from the filter to the multicast source results in a more remarkable
filtering effect.
z This filter works not only on independent multicast data but also on multicast data encapsulated in
register messages.
Configuring PIM Hello Options
No matter in a PIM-DM domain or a PIM-SM domain, the hello messages sent among routers contain
many configurable options, including:
z DR_Priority (for PIM-SM only): priority for DR election. The device with the highest priority wins the
DR election. You can configure this parameter on all the routers in a multi-access network directly
connected to multicast sources or receivers.
z Holdtime: the timeout time of PIM neighbor reachability state. When this timer times out, if the
router has received no hello message from a neighbor, it assumes that this neighbor has expired or
become unreachable.
z LAN_Prune_Delay: the delay of prune messages on a multi-access network. This option consists
of LAN-delay (namely, prune delay), override-interval, and neighbor tracking flag bit. You can
configure this parameter on all routers in the PIM domain. If different LAN-delay or override-interval
values result from the negotiation among all the PIM routers, the largest value will take effect.
The LAN-delay setting will cause the upstream routers to delay processing received prune messages. If
the LAN-delay setting is too small, it may cause the upstream router to stop forwarding multicast
packets before a downstream router sends a prune override message. Therefore, be cautious when
configuring this parameter.
The override-interval sets the length of time a downstream router is allowed to wait before sending a
prune override message. When a router receives a prune message from a downstream router, it does
not perform the prune action immediately; instead, it maintains the current forwarding state for a period
1-32
of LAN-delay plus override-interval. If the downstream router needs to continue receiving multicast data,
it must send a prune override message within the prune override interval; otherwise, the upstream route
will perform the prune action when the period of LAN-delay plus override-interval time out.
A hello message sent from a PIM router contains a generation ID option. The generation ID is a random
value for the interface on which the hello message is sent. Normally, the generation ID of a PIM router
does not change unless the status of the router changes (for example, when PIM is just enabled on the
interface or the device is restarted). When the router starts or restarts sending hello messages, it
generates a new generation ID. If a PIM router finds that the generation ID in a hello message from the
upstream router has changed, it assumes that the status of the upstream neighbor is lost or the
upstream neighbor has changed. In this case, it triggers a join message for state update.
If you disable join suppression (namely, enable neighbor tracking), the upstream router will explicitly
track which downstream routers are joined to it. The join suppression feature should be enabled or
disabled on all PIM routers on the same subnet.
Configuring hello options globally
Follow these steps to configure hello options globally:


Configure the priority for DR hello-option dr-priority Optional

election priority 1 by default
Configure PIM neighbor Optional

hello-option holdtime interval
Configure the prune delay time Optional

hello-option lan-delay interval
(LAN-delay) 500 milliseconds by default
Configure the prune override hello-option override-interval Optional

interval interval 2,500 milliseconds by default
hello-option Required
Disable join suppression
neighbor-tracking Enabled by default
Configuring hello options on an interface
Follow these steps to configure hello options on an interface:

interface-number
Configure the priority for DR pim hello-option dr-priority Optional

Configure PIM neighbor pim hello-option holdtime Optional

timeout time interval 105 seconds by default
1-33
Configure the prune delay time pim hello-option lan-delay Optional

(LAN-delay) interval 500 milliseconds by default
Configure the prune override pim hello-option Optional

interval override-interval interval 2,500 milliseconds by default
pim hello-option Required

Required
Configure the interface to reject
hello messages without a pim require-genid By default, hello messages
generation ID without Generation_ID are
accepted
Configuring PIM Common Timers
PIM routers discover PIM neighbors and maintain PIM neighboring relationships with other routers by
periodically sending out hello messages.
Upon receiving a hello message, a PIM router waits a random period, which is equal to or smaller than
the maximum delay between hello messages, before sending out a hello message. This avoids
collisions that occur when multiple PIM routers send hello messages simultaneously.
A PIM router periodically sends join/prune messages to its upstream for state update. A join/prune
message contains the join/prune timeout time. The upstream router sets a join/prune timeout timer for
each pruned downstream interface.
Any router that has lost assert election will prune its downstream interface and maintain the assert state
for a period of time. When the assert state times out, the assert losers will resume multicast forwarding.
When a router fails to receive subsequent multicast data from multicast source S, the router does not
immediately delete the corresponding (S, G) entry; instead, it maintains the (S, G) entry for a period of
time, namely the multicast source lifetime, before deleting the (S, G) entry.
Configuring PIM common timers globally
Follow these steps to configure PIM common timers globally:


Optional
Configure the hello interval timer hello interval
Configure the join/prune Optional

timer join-prune interval

holdtime join-prune interval
Optional
Configure assert timeout time holdtime assert interval
1-34
Configure the multicast source Optional

source-lifetime interval
lifetime 210 seconds by default
Configuring PIM common timers on an interface
Follow these steps to configure PIM common timers on an interface:

interface-number
Optional
Configure the hello interval pim timer hello interval
Configure the maximum delay pim triggered-hello-delay Optional

between hello messages interval 5 seconds by default

pim timer join-prune interval
Configure the join/prune pim holdtime join-prune Optional

Optional
Configure assert timeout time pim holdtime assert interval
If there are no special networking requirements, we recommend that you use the default settings.
Configuring Join/Prune Message Sizes
A larger join/prune message size will result in loss of a larger amount of information when a message is
lost; with a reduced join/message size, the loss of a single message will bring relatively minor impact.
By controlling the maximum number of (S, G) entries in a join/prune message, you can effectively
reduce the number of (S, G) entries sent per unit of time.
Follow these steps to configure join/prune message sizes:



jp-pkt-size packet-size
a join/prune message 8,100 bytes by default
1-35
number of (S, G) entries in a jp-queue-size queue-size
join/prune message 1,020 by default
Displaying and Maintaining PIM

View the BSR information
in the PIM-SM domain and display pim [ vpn-instance vpn-instance-name | Available in any
locally configured C-RP all-instance ] bsr-info view
information in effect
View the information of
display pim [ vpn-instance vpn-instance-name | Available in any
unicast routes used by
all-instance ] claimed-route [ source-address ] view
PIM
display pim [ vpn-instance vpn-instance-name |
all-instance ] control-message counters
[ message-type { probe | register |
View the number of PIM Available in any
register-stop } | [ interface interface-type
control messages view
interface-number | message-type { assert | bsr |
crp | graft | graft-ack | hello | join-prune |
state-refresh } ] * ]
View the information about
Available in any
unacknowledged graft display pim grafts
view
messages
View the PIM information
display pim interface [ interface-type Available in any
on an interface or all
interface-number ] [ verbose ] view
interfaces

View the information of all-instance ] join-prune mode { sm [ flags
Available in any
join/prune messages to flag-value ] | ssm } [ interface interface-type
view
send interface-number | neighbor neighbor-address ] *
[ verbose ]
View PIM neighboring Available in any
all-instance ] neighbor [ interface interface-type
information view
interface-number | neighbor-address | verbose ] *
all-instance ] routing-table [ group-address
[ mask { mask-length | mask } ] | source-address
[ mask { mask-length | mask } ] |
View the content of the Available in any
incoming-interface [ interface-type
PIM routing table view
interface-number | register ] | outgoing-interface
{ include | exclude | match } { interface-type
interface-number | register } | mode mode-type |
flags flag-value | fsm ] *
display pim [ vpn-instance vpn-instance-name | Available in any
View the RP information
all-instance ] rp-info [ group-address ] view
reset pim [ vpn-instance vpn-instance-name |
Reset PIM control Available in user
all-instance ] control-message counters
message counters view
[ interface interface-type interface-number ]
1-36
PIM Configuration Examples (On Routers)
PIM-DM Configuration Example
z Receivers receive VOD information through multicast. The receiver groups of different
organizations form stub networks, and one or more receiver hosts exist in each stub network. The
entire PIM domain operates in the dense mode.
z Host A and Host C are multicast receivers in two stub networks N1 and N2.
z Router D connects to the network that comprises the multicast source (Source) through Ethernet
1/0.
z Router A connects to N1 through Ethernet 1/0, and to Router D through Serial 2/0.
z Router B and Router C connect to N2 through their respective Ethernet 1/0, and to Router D
through their respective POS 5/0.
z IGMPv2 is to run between Router A and N1, and between Router B/Router C and N2.
Network diagram
Figure 1-10 Network diagram for PIM-DM configuration (on routers)
N1
Ethernet
/0
S2
/0
N2
S2
Ethernet
PO
S5
Ethernet
/1
PO
S5
/0

S2/0 192.168.1.1/24 S2/0 192.168.1.2/24
Router B Eth1/0 10.110.2.1/24 POS5/0 192.168.2.2/24
POS5/0 192.168.2.1/24 POS5/1 192.168.3.2/24
Router C Eth1/0 10.110.2.2/24
POS5/0 192.168.3.1/24

1-37
Configure the OSPF protocol for interoperation among the routers in the PIM-DM domain. Ensure the
network-layer interoperation in the PIM-DM domain and enable dynamic update of routing information
among the routers through a unicast routing protocol. Detailed configuration steps are omitted here.
# Enable IP multicast routing on Router A, enable PIM-DM on each interface, and enable IGMP on
Ethernet 1/0, which connects Router A to N1.
[RouterA-Serial2/0] pim dm

# Enable IP multicast routing on Router D, and enable PIM-DM on each interface.
[RouterD] multicast routing-enable
[RouterD-Ethernet1/0] pim dm
[RouterD-Serial2/0] pim dm
[RouterD] interface pos 5/0
[RouterD-Pos5/0] pim dm
[RouterD-Pos5/0] quit
[RouterD-Pos5/1] pim dm
Carry out the display pim interface command to view the PIM configuration and running status on
each interface. For example:
# View the PIM configuration information on Router D.
[RouterD] display pim interface
VPN-Instance: public net
Interface NbrCnt HelloInt DR-Pri DR-Address
Eth1/0 0 30 1 10.110.5.1 (local)
Ser2/0 1 30 1 192.168.1.2 (local)
Pos5/0 1 30 1 192.168.2.2 (local)
Pos5/1 1 30 1 192.168.3.2 (local)
Carry out the display pim neighbor command to view the PIM neighboring relationships among the
# Verify the PIM neighboring relationships on Router D.
1-38
[RouterD] display pim neighbor
Total Number of Neighbors = 3
Neighbor Interface Uptime Expires Dr-Priority

192.168.1.1 Ser2/0 00:02:22 00:01:27 1
192.168.2.1 Pos5/0 00:00:22 00:01:29 3
192.168.3.1 Pos5/1 00:00:23 00:01:31 5
Assume that Host A needs to receive the information addressed to multicast group G (225.1.1.1). After
the multicast source S (10.110.5.100/24) sends multicast packets to the multicast group G, an SPT is
established through traffic flooding. Routers on the SPT path (Router A and Router D) have their (S, G)
entries. Host A sends an IGMP report to Router A to join the multicast group G, and a (*, G) entry is
generated on Router A. You can use the display pim routing-table command to view the PIM routing
table information on each router. For example:
# View the PIM routing table information on Router A.
[RouterA] display pim routing-table
(*, 225.1.1.1)
Protocol: pim-dm, Flag: WC
UpTime: 00:04:25
Upstream interface: NULL
1: Ethernet1/0
Protocol: igmp, UpTime: 00:04:25, Expires: never
(10.110.5.100, 225.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:06:14
Upstream interface: Serial2/0,
1: Ethernet1/0
Protocol: pim-dm, UpTime: 00:04:25, Expires: never
The information on Router B and Router C is similar to that on Router A.

# View the PIM routing table information on Router D.
1-39
(10.110.5.100, 225.1.1.1)
Protocol: pim-dm, Flag: LOC ACT
UpTime: 00:03:27
1: Serial2/0
2: Pos5/0
3: Pos5/1
PIM-SM Non-Scoped Zone Configuration Example
entire PIM-SM domain contains only one BSR.
1/0.
z Router A connects to stub network N1 through Ethernet 1/0, and to Router D and Router E through
Serial 2/0 and POS 5/0 respectively.
z Router B and Router C connect to stub network N2 through their respective Ethernet 1/0, and to
Router E through their respective POS 5/0.
z Router E connects to Router A, Router B, Router C and Router D, and its POS 5/2 interface acts as
a C-BSR and a C-RP, with the range of multicast groups served by the C-RP being 225.1.1.0/24.
1-40
Network diagram
Figure 1-11 Network diagram for PIM-SM non-scoped zone configuration (on routers)
N1
Ethernet
/0
S2
N2
/0
S2
Ethernet
Ethernet
S2/0 192.168.1.1/24 S2/0 192.168.1.2/24
POS5/0 192.168.9.1/24 POS5/0 192.168.4.2/24
Router B Eth1/0 10.110.2.1/24 Router E POS5/0 192.168.3.2/24
POS5/0 192.168.2.1/24 POS5/1 192.168.2.2/24
Router C Eth1/0 10.110.2.2/24 POS5/2 192.168.9.2/24
POS5/0 192.168.3.1/24 POS5/3 192.168.4.1/24

Configure the OSPF protocol for interoperation among the routers in the PIM-SM domain. Ensure the
network-layer interoperation in the PIM-SM domain and enable dynamic update of routing information
# Enable IP multicast routing on Router A, enable PIM-SM on each interface, and enable IGMP on
Ethernet 1/0, which connects Router A to the stub network.
1-41
The configuration on Router B and Router C is similar to that on Router A. The configuration on Router
D and Router E is also similar to that on Router A except that it is not necessary to enable IGMP on the
corresponding interfaces on these two routers.
# Configure the service scope of RP advertisements and the positions of the C-BSR and C-RP on
Router E.
[RouterE] acl number 2005
[RouterE-acl-basic-2005] rule permit source 225.1.1.0 0.0.0.255
[RouterE-acl-basic-2005] quit
[RouterE] pim
[RouterE-pim] c-bsr pos 5/2
[RouterE-pim] c-rp pos 5/2 group-policy 2005
[RouterE-pim] quit
# Verify the PIM configuration information on Router A.
[RouterA] display pim interface
Eth1/0 0 30 1 10.110.1.1 (local)
Ser2/0 1 30 1 192.168.1.2
Pos5/0 1 30 1 192.168.9.2
To view the BSR election information and the locally configured C-RP information in effect on a router,
use the display pim bsr-info command. For example:
# View the BSR information and the locally configured C-RP information in effect on Router A.
[RouterA] display pim bsr-info
Elected BSR Address: 192.168.9.2
Priority: 0
Hash mask length: 30
State: Accept Preferred
Scope: Not scoped
Uptime: 00:40:40
Expires: 00:01:42
# View the BSR information and the locally configured C-RP information in effect on Router E.
[RouterE] display pim bsr-info
1-42
Priority: 0
State: Elected
Scope: Not scoped
Uptime: 00:00:18
Next BSR message scheduled at: 00:01:52
Candidate BSR Address: 192.168.9.2
Priority: 0
State: Pending
Scope: Not scoped
Candidate RP: 192.168.9.2(Pos5/2)
Priority: 0
HoldTime: 150
Advertisement Interval: 60
Next advertisement scheduled at: 00:00:48
To view the RP information discovered on a router, use the display pim rp-info command. For
example:
# View the RP information on Router A.
[RouterA] display pim rp-info
PIM-SM BSR RP information:
Group/MaskLen: 225.1.1.0/24
RP: 192.168.9.2
Priority: 0
HoldTime: 150
Uptime: 00:51:45
Expires: 00:02:22
Assume that Host A needs to receive information addressed to multicast group G (225.1.1.1). An RPT
will be built between Router A and Router E. When the multicast source S (10.110.5.100/24) registers
with the RP, an SPT will be built between Router D and Router E. Upon receiving multicast data, Router
A immediately switches from the RPT to the SPT. Routers on the RPT path (Router A and Router E)
have a (*, G) entry, while routers on the SPT path (Router A and Router D) have an (S, G) entry. You can
use the display pim routing-table command to view the PIM routing table information on the routers.
For example:
(*, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:13:46
Upstream interface: Pos5/0
1-43
1: Ethernet1/0
Protocol: igmp, UpTime: 00:13:46, Expires: 00:03:06
(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 00:00:42
1: Ethernet1/0
Protocol: pim-sm, UpTime: 00:00:42, Expires: 00:03:06

(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
Protocol: pim-sm, Flag: SPT LOC ACT
UpTime: 00:00:42
1: Pos5/0
# View the PIM routing table information on Router E.

[RouterE] display pim routing-table
(*, 225.1.1.1)
RP: 192.168.9.2 (local)
UpTime: 00:13:16
1-44
1: Pos5/2
PIM-SM Admin-scope Zone Configuration Example
z Receivers receive VOD information through multicast. The entire PIM-SM domain is divided into
admin-scope zone 1, admin-scope zone 2, and the global scope zone. Router B, Router C, and
Router D are ZBRs of the three domains respectively.
z Source 1 and Source 2 send different multicast information to multicast group 239.1.1.1. Host A
receives the multicast information from Source 1 only, while Host B receives the multicast
information from Source 2 only. Source 3 sends multicast information to multicast group 224.1.1.1.
Host C is a multicast receiver for this multicast group.
z Serial 2/1 of Router B acts as a C-BSR and C-RP of admin-scope zone 1, which serve the multicast
group range 239.0.0.0/8. Serial 2/1 of Router D acts as a C-BSR and C-RP of admin-scope zone 2,
which also serve the multicast group range 239.0.0.0/8. Serial 2/1 of Router F and Router H act as
C-BSRs and C-RPs of the global scope zone, which serve all the multicast groups other than those
in the 239.0.0.0/8 range. Router F has a higher priority.
z IGMPv2 is required between Router A, Router E, Router I and their respective receivers.
1-45
Network diagram
Figure 1-12 Network diagram for PIM-SM admin-scope zone configuration (on routers)
Admin-scope 1
Receiver Eth1/1
Router G
Host A
Source 1 Source 3 S2/1
Eth1/1 Eth1/1 S2/1

S2/1 POS5/2 POS5/2
Router F
S2/1
PO
Router A Router B POS5/1
S5
/1
ZBR
Router C
PO
Router I Router H ZBR POS5/1
S5
/1
S2/1 POS5/1 S2/1 Router D
S2/1 POS5/2 S2/1 ZBR
S2
S2/2
/
Et
2
/
h1
h1
Et
/1
Receiver Source 2
Host C
S2
S2/2
/1
Receiver
Eth1/1
Host B Router E
PIM-SM
Global-scope Admin-scope 2

Router A Eth1/1 192.168.1.1/24 Router D S2/1 10.110.4.2/24
S2/1 10.110.1.1/24 S2/2 10.110.7.1/24
Router B Eth1/1 192.168.2.1/24 POS5/1 10.110.8.1/24
S2/1 10.110.1.2/24 Router E Eth1/1 192.168.4.1/24
POS5/1 10.110.2.1/24 S2/1 10.110.5.2/24
POS5/2 10.110.3.1/24 S2/2 10.110.7.2/24
Router C Eth1/1 192.168.3.1/24 Router F S2/1 10.110.9.1/24
S2/1 10.110.4.1/24 POS5/1 10.110.8.2/24
S2/2 10.110.5.1/24 POS5/2 10.110.3.2/24
POS5/1 10.110.2.2/24 Router G Eth1/1 192.168.5.1/24
POS5/2 10.110.6.1/24 S2/1 10.110.9.2/24
Router H S2/1 10.110.10.1/24 Source 1 - 192.168.2.10/24
POS5/1 10.110.6.2/24 Source 2 - 192.168.3.10/24
Router I Eth1/1 192.168.6.1/24 Source 3 - 192.168.5.10/24
S2/1 10.110.10.2/24

Configure OSPF for interoperation among the routers in the PIM-SM domain. Ensure the network-layer
interoperation among the routers in the PIM-SM domain and enable dynamic update of routing
information among the routers through a unicast routing protocol. Detailed configuration steps are
omitted here.
2) Enable IP multicast routing and administrative scoping, and enable PIM-SM and IGMP
1-46
# Enable IP multicast routing and administrative scoping on Router A, enable PIM-SM on each interface,
and enable IGMP on the host-side interface Ethernet 1/1.
[RouterA] pim
[RouterA-pim] c-bsr admin-scope
[RouterA-pim] quit
The configuration on Router E and Router I is similar to the configuration on Router A.

# On Router B, enable IP multicast routing and administrative scoping, and enable PIM-SM on each
interface.
[RouterB] pim
[RouterB-pim] c-bsr admin-scope
[RouterB-pim] quit
[RouterB-Ethernet1/1] pim sm
[RouterB-Serial2/1] pim sm
The configuration on Router C, Router D, Router F, Router G, and Router H is similar to the
configuration on Router B. The specific configuration steps are omitted here.
3) Configure an admin-scope zone boundary
# On Router B, configure POS 5/1 and POS 5/2 as the boundary of admin-scope zone 1.
[RouterB-Pos5/1] multicast boundary 239.0.0.0 8
[RouterB-Pos5/2] multicast boundary 239.0.0.0 8
# On Router C, configure POS 5/1 and POS 5/2 as the boundary of admin-scope zone 2.
1-47
[RouterC-Pos5/1] multicast boundary 239.0.0.0 8
[RouterC-Pos5/2] multicast boundary 239.0.0.0 8
# On Router D, configure POS 5/1 as the boundary of admin-scope zone 2.

[RouterD-Pos5/1] multicast boundary 239.0.0.0 8
# On Router B, configure the service scope of RP advertisements and configure Serial 2/1 as a C-BSR
and C-RP of admin-scope zone 1.
[RouterB-acl-basic-2001] rule permit source 239.0.0.0 0.255.255.255
[RouterB] pim
[RouterB-pim] c-bsr group 239.0.0.0 8
[RouterB-pim] c-bsr serial 2/1
[RouterB-pim] c-rp serial 2/1 group-policy 2001
[RouterB-pim] quit
# On Router D, configure the service scope of RP advertisements and configure Serial 2/1 as a C-BSR
and C-RP of admin-scope zone 2.
[RouterD-acl-basic-2001] rule permit source 239.0.0.0 0.255.255.255
[RouterD] pim
[RouterD-pim] c-bsr group 239.0.0.0 8
[RouterD-pim] c-bsr serial 2/1
[RouterD-pim] c-rp serial 2/1 group-policy 2001
[RouterD-pim] quit
# On Router F, configure Serial 2/1 as a C-BSR and C-RP in the global scope zone and set their
priorities to 20.
<RouterF> system-view
[RouterF] pim
[RouterF-pim] c-bsr global priority 20
[RouterF-pim] c-bsr serial 2/1
[RouterF-pim] c-rp serial 2/1 priority 20
[RouterF-pim] quit
# On Router H, configure Serial 2/1 as a C-BSR and C-RP in the global scope zone and set their
priorities to 10.
<RouterH> system-view
[RouterH] pim
1-48
[RouterH-pim] c-bsr global priority 10
[RouterH-pim] c-bsr serial 2/1
[RouterH-pim] c-rp serial 2/1 priority 10
[RouterH-pim] quit
To view the BSR election information and the C-RP information on a router, use the display pim
bsr-info command. For example:
# View the BSR information and the locally configured C-RP information on Router B.
[RouterB] display pim bsr-info
Priority: 20
Scope: Global
Uptime: 00:01:45
Expires: 00:01:25
Priority: 0
State: Elected
Scope: 239.0.0.0/8
Uptime: 00:04:54
Priority: 0
State: Elected
Scope: 239.0.0.0/8
Candidate RP: 10.110.1.2(Serial2/1)

Priority: 0
HoldTime: 150
# View the BSR information and the locally configured C-RP information on Router D.
[RouterD] display pim bsr-info
Priority: 20
Scope: Global
Uptime: 00:01:45
Expires: 00:01:25
Priority: 0
1-49
State: Elected
Scope: 239.0.0.0/8
Uptime: 00:03:48
Priority: 0
State: Elected
Scope: 239.0.0.0/8

Priority: 0
HoldTime: 150
# View the BSR information and the locally configured C-RP information on Router F.
[RouterF] display pim bsr-info
Priority: 20
State: Elected
Scope: Global
Uptime: 00:11:11
Priority: 20
State: Elected
Scope: Global

Priority: 20
HoldTime: 150
# View the BSR information and the locally configured C-RP information on Router D.
[RouterH] display pim bsr-info
Priority: 20
Scope: Global
Uptime: 00:10:33
Expires: 00:01:36
1-50
Priority: 10
State: Candidate
Scope: Global

Priority: 10
HoldTime: 150
To view the RP information learned on a router, use the display pim rp-info command.For example:
# View the RP information on Router B.
[RouterB] display pim rp-info
RP: 10.110.9.1
Priority: 10
HoldTime: 150
Uptime: 00:03:39
Expires: 00:01:51
RP: 10.110.10.1
Priority: 20
HoldTime: 150
Uptime: 00:03:39
Expires: 00:01:51
RP: 10.110.1.2 (local)
Priority: 0
HoldTime: 150
Uptime: 00:07:44
Expires: 00:01:51
# View the RP information on Router D.

[RouterD] display pim rp-info
RP: 10.110.9.1
Priority: 10
HoldTime: 150
Uptime: 00:03:42
Expires: 00:01:48
RP: 10.110.10.1
1-51
Priority: 20
HoldTime: 150
Uptime: 00:03:42
Expires: 00:01:48
RP: 10.110.4.2 (local)
Priority: 0
HoldTime: 150
Uptime: 00:06:54
Expires: 00:02:41
# View the RP information on Router F.

[RouterF] display pim rp-info
RP: 10.110.9.1 (local)
Priority: 10
HoldTime: 150
Uptime: 00:00:32
Expires: 00:01:58
RP: 10.110.10.1
Priority: 20
HoldTime: 150
Uptime: 00:00:32
Expires: 00:01:58
PIM-SSM Configuration Example
entire PIM domain operates in the SSM mode.
z Host A and Host C are multicast receivers in two stub networks.
1/0.
z Router A connects to stub network N1 through Ethernet 1/0, and to Router D and Router E through
Serial 2/0 and POS 5/0 respectively.
z Router B and Router C connect to stub network N2 through their respective Ethernet 1/0, and to
Router E through their respective POS 5/0.
z Router E connects to Router A, Router B, Router C and Router D.
z The SSM group range is 232.1.1.0/24.
1-52
Network diagram
Figure 1-13 Network diagram for PIM-SSM configuration (on routers)
N1
Ethernet
/0
S2
N2
/0
S2
Ethernet
Ethernet
S2/0 192.168.1.1/24 S2/0 192.168.1.2/24
POS5/0 192.168.9.1/24 POS5/0 192.168.4.2/24
Router B Eth1/0 10.110.2.1/24 Router E POS5/0 192.168.3.2/24
POS5/0 192.168.2.1/24 POS5/1 192.168.2.2/24
Router C Eth1/0 10.110.2.2/24 POS5/2 192.168.9.2/24
POS5/0 192.168.3.1/24 POS5/3 192.168.4.1/24

Configure the OSPF protocol for interoperation among the routers in the PIM-SM domain. Ensure the
# Enable IP multicast routing on Router A, enable PIM-SM on each interface, and run IGMPv3 on
Ethernet 1/0, which connects Router A to the stub network.
[RouterA-Ethernet1/0] igmp version 3
1-53
D and Router E is also similar to that on Router A except that it is not necessary to enable IGMP on the
# Configure the SSM group range to be 232.1.1.0/24 on Router A.
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[RouterA-acl-basic-2000] quit
[RouterA] pim
[RouterA-pim] ssm-policy 2000
[RouterA-pim] quit
The configuration on Router B, Router C, Router D and Router E is similar to that on Router A.
Use the display pim interface command to view the PIM configuration and running status on each
interface. For example:
# Verify the PIM configuration information on Router A.
[RouterA] display pim interface
Eth1/0 0 30 1 10.110.1.1 (local)
Ser2/0 1 30 1 192.168.1.2
Pos5/0 1 30 1 192.168.9.2
Assume that Host A needs to receive the information a specific multicast source S (10.110.5.100/24)
sends to multicast group G (232.1.1.1). Router A builds an SPT toward the multicast source. Routers on
the SPT path (Router A and Router D) have generated (S, G) entry, while Router E, which is not on the
SPT path, does not have multicast routing entries. You can use the display pim routing-table
command to view the PIM routing table information on each router. For example:
(10.110.5.100, 232.1.1.1)
UpTime: 00:13:25
1-54
1: Ethernet1/0

(10.110.5.100, 232.1.1.1)
Protocol: pim-ssm, Flag: LOC
UpTime: 00:12:05
1: Serial2/0
Protocol: pim-ssm, UpTime: 00:12:05, Expires: 00:03:25
PIM Configuration Examples (On Switches)

PIM-DM Configuration Example
entire PIM domain operates in the dense mode.
z Switch D connects to the network that comprises the multicast source (Source) through
VLAN-interface 300.
z Switch A connects to stub network N1 through VLAN-interface 100, and to Switch D through
VLAN-interface 103.
z Switch B and Switch C connect to stub network N2 through their respective VLAN-interface 200,
and to Switch D through VLAN-interface 101 and VLAN-interface 102 respectively.
z IGMPv2 is to run between Switch A and N1, and between Switch B/Switch C and N2.
1-55
Network diagram
Figure 1-14 Network diagram for PIM-DM configuration (on switches)
N1
Ethernet
03
t1
-in
an
Vl
03
t1
-in
N2
an
Ethernet
Vl
Vl
an
-in
Ethernet
t1
02 Vla
n-
in
t1
02

Vlan-int103 192.168.1.1/24 Vlan-int103 192.168.1.2/24
Vlan-int101 192.168.2.1/24 Vlan-int102 192.168.3.2/24
Switch C Vlan-int200 10.110.2.2/24
Vlan-int102 192.168.3.1/24

Configure the OSPF protocol for interoperation among the switches in the PIM-DM domain. Ensure the
among the switches through a unicast routing protocol. Detailed configuration steps are omitted here.
# Enable IP multicast routing on Switch A, enable PIM-DM on each interface, and enable IGMP on
VLAN-interface 100, which connects Switch A to the stub network.
1-56
# Enable IP multicast routing on Switch D, and enable PIM-DM on each interface.
[SwitchD] multicast routing-enable
[SwitchD-Vlan-interface300] pim dm
Use the display pim interface command to view the PIM configuration and running status on each
interface. For example:
# View the PIM configuration information on Switch D.
[SwitchD] display pim interface
Vlan300 0 30 1 10.110.5.1 (local)
Vlan103 1 30 1 192.168.1.2 (local)
Vlan101 1 30 1 192.168.2.2 (local)
Vlan102 1 30 1 192.168.3.2 (local)
Carry out the display pim neighbor command to view the PIM neighboring relationships among the
switches. For example:
# View the PIM neighboring relationships on Switch D.
[SwitchD] display pim neighbor

192.168.1.1 Vlan103 00:02:22 00:01:27 1
192.168.2.1 Vlan101 00:00:22 00:01:29 3
192.168.3.1 Vlan102 00:00:23 00:01:31 5
Assume that Host A needs to receive the information addressed to multicast group G (225.1.1.1). After
multicast source S (10.110.5.100/24) sends multicast packets to the multicast group G, an SPT is
established through traffic flooding. Switches on the SPT path (Switch A and Switch D) have their (S, G)
entries. Host A sends an IGMP report to Switch A to join the multicast group G, and a (*, G) entry is
generated on Switch A. You can use the display pim routing-table command to view the PIM routing
table information on each switch. For example:
# View the PIM routing table information on Switch A.
[SwitchA] display pim routing-table
1-57
(*, 225.1.1.1)
UpTime: 00:04:25
Protocol: igmp, UpTime: 00:04:25, Expires: never
(10.110.5.100, 225.1.1.1)
UpTime: 00:06:14
Upstream interface: Vlan-interface103,
The information on Switch B and Switch C is similar to that on Switch A.

(10.110.5.100, 225.1.1.1)
UpTime: 00:03:27
1-58
PIM-SM Non-Scoped Zone Configuration Example
entire PIM-SM domain contains only one BSR.
VLAN-interface 300.
z Switch A connects to stub network N1 through VLAN-interface 100, and to Switch D and Switch E
through VLAN-interface 101 and VLAN-interface 102 respectively.
and to Switch E through VLAN-interface 103 and VLAN-interface 104 respectively.
z Switch E connects to Switch A, Switch B, Switch C and Switch D, and its VLAN-interface 102
interface acts a C-BSR and a C-RP, with the range of multicast groups served by the C-RP being
225.1.1.0/24.
Network diagram
Figure 1-15 Network diagram for PIM-SM non- scoped zone configuration (on switches)
N1
Ethernet
01
t1
-in
an
Vl
01
t1
N2
-in
an
Ethernet
Vl
Ethernet

Vlan-int101 192.168.1.1/24 Vlan-int101 192.168.1.2/24
Vlan-int102 192.168.9.1/24 Vlan-int105 192.168.4.2/24
Switch B Vlan-int200 10.110.2.1/24 Switch E Vlan-int104 192.168.3.2/24
Vlan-int103 192.168.2.1/24 Vlan-int103 192.168.2.2/24
Vlan-int104 192.168.3.1/24 Vlan-int105 192.168.4.1/24
1-59

Configure the OSPF protocol for interoperation among the switches in the PIM-SM domain. Ensure the
# Enable IP multicast routing on Switch A, enable PIM-SM on each interface, and enable IGMP on
The configuration on Switch B and Switch C is similar to that on Switch A. The configuration on Switch D
and Switch E is also similar to that on Switch A except that it is not necessary to enable IGMP on the
corresponding interfaces on these two switches.
# Configure the service scope of RP advertisements and the positions of the C-BSR and C-RP on
Switch E.
[SwitchE] acl number 2005
[SwitchE-acl-basic-2005] rule permit source 225.1.1.0 0.0.0.255
[SwitchE-acl-basic-2005] quit
[SwitchE] pim
[SwitchE-pim] c-bsr vlan-interface 102
[SwitchE-pim] c-rp vlan-interface 102 group-policy 2005
[SwitchE-pim] quit
# View the PIM configuration information on Switch A.
[SwitchA] display pim interface
Vlan100 0 30 1 10.110.1.1 (local)
Vlan101 1 30 1 192.168.1.2
1-60
Vlan102 1 30 1 192.168.9.2
To view the BSR election information and the locally configured C-RP information in effect on a switch,
use the display pim bsr-info command. For example:
# View the BSR information and the locally configured C-RP information in effect on Switch A.
[SwitchA] display pim bsr-info
Priority: 0
Scope: Not scoped
Uptime: 00:40:40
Expires: 00:01:42
# View the BSR information and the locally configured C-RP information in effect on Switch E.
[SwitchE] display pim bsr-info
Priority: 0
State: Elected
Scope: Not scoped
Uptime: 00:00:18
Priority: 0
State: Pending
Scope: Not scoped
Candidate RP: 192.168.9.2(Vlan-interface102)

Priority: 0
HoldTime: 150
To view the RP information discovered on a switch, use the display pim rp-info command. For
example:
# View the RP information on Switch A.
[SwitchA] display pim rp-info
RP: 192.168.9.2
Priority: 0
HoldTime: 150
Uptime: 00:51:45
Expires: 00:02:22
Assume that Host A needs to receive information addressed to the multicast group G (225.1.1.1). An
RPT will be built between Switch A and Switch E. When the multicast source S (10.110.5.100/24)
registers with the RP, an SPT will be built between Switch D and Switch E. Upon receiving multicast
1-61
data, Switch A immediately switches from the RPT to the SPT. Switches on the RPT path (Switch A and
Switch E) have a (*, G) entry, while switches on the SPT path (Switch A and Switch D) have an (S, G)
entry. You can use the display pim routing-table command to view the PIM routing table information
on the switches. For example:
(*, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:13:46
(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42

(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42
1-62
# View the PIM routing table information on Switch E.
[SwitchE] display pim routing-table
(*, 225.1.1.1)
RP: 192.168.9.2 (local)
UpTime: 00:13:16
PIM-SM Admin-Scope Zone Configuration Example
z Receivers receive VOD information through multicast. The entire PIM-SM domain is divided into
admin-scope zone 1, admin-scope zone 2, and the global zone. Switch B, Switch C, and Switch D
are ZBRs of these three domains respectively.
z Source 1 and Source 2 send different multicast information to multicast group 239.1.1.1. Host A
receives the multicast information from only Source 1, while Host B receives the multicast
information from only Source 2. Source 3 sends multicast information to multicast group 224.1.1.1.
Host C is a multicast receiver for this multicast group.
z VLAN-interface 101 of Switch B acts as a C-BSR and C-RP of admin-scope zone 1, which serve
the multicast group range 239.0.0.0/8. VLAN-interface 104 of Switch D acts as a C-BSR and C-RP
of admin-scope zone 2, which also serve the multicast group range 239.0.0.0/8. Both
VLAN-interface 109 of Switch F and VLAN-interface 110 of Switch H act as C-BSRs and C-RPs of
the global scope zone, which serve all the multicast groups other than those in the 239.0.0.0/8
range. Switch F has a higher priority.
z IGMPv2 is required between Switch A, Switch E, Switch I and their respective receivers.
1-63
Network diagram
Figure 1-16 Network diagram for PIM-SM admin-scope zone configuration (on switches)
Admin-scope 1
Receiver Vlan-int500
Switch G
Host A
Source 1 Source 3 Vlan-int109

Switch F
Vlan-int101
Vl
an
Switch A Switch B Vlan-int107
-in
t1
ZBR
03 lan
Switch C
V
Switch I Switch H ZBR
-in
Vlan-int107
t1
03
Vlan-int110 Vlan-int106 Vlan-int104 Switch D
Vlan-int110 Vlan-int106 Vlan-int104 ZBR
Vl
an
00
Vl
Vlan-int108
-in
an
t3
in
t1
-in
05
an
t6
00
Vl
Receiver Source 2
Vl
an
Host C
-in
t1
Vlan-int108
05
Receiver
Vlan-int400
Host B Switch E
PIM-SM
Global-scope Admin-scope 2

Vlan-int101 10.110.1.1/24 Vlan-int108 10.110.7.1/24
Vlan-int103 10.110.2.1/24 Vlan-int105 10.110.5.2/24
Vlan-int102 10.110.3.1/24 Vlan-int108 10.110.7.2/24
Switch C Vlan-int300 192.168.3.1/24 Switch F Vlan-int109 10.110.9.1/24
Vlan-int104 10.110.4.1/24 Vlan-int107 10.110.8.2/24
Vlan-int105 10.110.5.1/24 Vlan-int102 10.110.3.2/24
Vlan-int103 10.110.2.2/24 Switch G Vlan-int500 192.168.5.1/24
Vlan-int106 10.110.6.1/24 Vlan-int109 10.110.9.2/24
Switch H Vlan-int110 10.110.10.1/24 Source 1 - 192.168.2.10/24
Vlan-int106 10.110.6.2/24 Source 2 - 192.168.3.10/24
Switch I Vlan-int600 192.168.6.1/24 Source 3 - 192.168.5.10/24
Vlan-int110 10.110.10.2/24

Configure OSPF for interoperation among the switches in the PIM-SM domain. Ensure the
network-layer interoperation among the switches in the PIM-SM domain and enable dynamic update of
routing information among the switches through a unicast routing protocol. Detailed configuration steps
are omitted here.
2) Enable IP multicast routing and administrative scoping, and enable PIM-SM and IGMP
1-64
# Enable IP multicast routing and administrative scoping on Switch A, enable PIM-SM on each interface,
and enable IGMP on the host-side interface VLAN-interface 100.
[SwitchA] pim
[SwitchA-pim] c-bsr admin-scope
[SwitchA-pim] quit
The configuration on Switch E and Switch I is similar to the configuration on Switch A.

# On Switch B, enable IP multicast routing and administrative scoping, and enable PIM-SM on each
interface.
[SwitchB] pim
[SwitchB-pim] c-bsr admin-scope
[SwitchB-pim] quit
The configuration on Switch C, Switch D, Switch F, Switch G, and Switch H is similar to the configuration
on Switch B. The specific configuration steps are omitted here.
3) Configure an admin-scope zone boundary
# On Switch B, configure VLAN-interface 102 and VLAN-interface 103 to be the boundary of
admin-scope zone 1.
[SwitchB-Vlan-interface102] multicast boundary 239.0.0.0 8
[SwitchB-Vlan-interface103] multicast boundary 239.0.0.0 8
1-65
# On Switch C, configure VLAN-interface 103 and VLAN-interface 106 to be the boundary of
admin-scope zone 2.
[SwitchC-Vlan-interface103] multicast boundary 239.0.0.0 8
[SwitchC-Vlan-interface106] multicast boundary 239.0.0.0 8
# On Switch D, configure VLAN-interface 107 to be the boundary of admin-scope zone 2.

[SwitchD-Vlan-interface107] multicast boundary 239.0.0.0 8
# On Switch B, configure the service scope of RP advertisements and configure VLAN-interface 101 as
a C-BSR and C-RP of admin-scope zone 1.
[SwitchB-acl-basic-2001] rule permit source 239.0.0.0 0.255.255.255
[SwitchB] pim
[SwitchB-pim] c-bsr group 239.0.0.0 8
[SwitchB-pim] c-bsr vlan-interface 101
[SwitchB-pim] c-rp vlan-interface 101 group-policy 2001
[SwitchB-pim] quit
# On Switch D, configure the service scope of RP advertisements and configure VLAN-interface 104 as
a C-BSR and C-RP of admin-scope zone 2.
[SwitchD-acl-basic-2001] rule permit source 239.0.0.0 0.255.255.255
[SwitchD] pim
[SwitchD-pim] c-bsr group 239.0.0.0 8
[SwitchD-pim] c-bsr vlan-interface 104
[SwitchD-pim] c-rp vlan-interface 104 group-policy 2001
[SwitchD-pim] quit
# On Switch F, configure VLAN-interface 109 as a C-BSR and C-RP in the global scope zone and set
their priorities to 20.
<SwitchF> system-view
[SwitchF] pim
[SwitchF-pim] c-bsr global priority 20
[SwitchF-pim] c-bsr vlan-interface 109
[SwitchF-pim] c-rp vlan-interface 109 priority 20
[SwitchF-pim] quit
# On Switch H, configure VLAN-interface 110 as a C-BSR and C-RP in the global scope zone and set
their priorities to 10.
1-66
<SwitchH> system-view
[SwitchH] pim
[SwitchH-pim] c-bsr global priority 10
[SwitchH-pim] c-bsr vlan-interface 110
[SwitchH-pim] c-rp vlan-interface 110 priority 10
[SwitchH-pim] quit
To view the BSR election information and the C-RP information on a switch, use the display pim
bsr-info command. For example:
# View the BSR information and the locally configured C-RP information on Switch B.
[SwitchB] display pim bsr-info
Priority: 20
Scope: Global
Uptime: 00:01:45
Expires: 00:01:25
Priority: 0
State: Elected
Scope: 239.0.0.0/8
Uptime: 00:04:54
Priority: 0
State: Elected
Scope: 239.0.0.0/8

Priority: 0
HoldTime: 150
# View the BSR information and the locally configured C-RP information on Switch D.
[SwitchD] display pim bsr-info
Priority: 20
Scope: Global
Uptime: 00:01:45
Expires: 00:01:25
Priority: 0
1-67
State: Elected
Scope: 239.0.0.0/8
Uptime: 00:03:48
Priority: 0
State: Elected
Scope: 239.0.0.0/8

Priority: 0
HoldTime: 150
# View the BSR information and the locally configured C-RP information on Switch F.
[SwitchF] display pim bsr-info
Priority: 20
State: Elected
Scope: Global
Uptime: 00:11:11
Priority: 20
State: Elected
Scope: Global

Priority: 20
HoldTime: 150
# View the BSR information and the locally configured C-RP information on Switch H.
[SwitchH] display pim bsr-info
Priority: 20
Scope: Global
Uptime: 00:10:33
Expires: 00:01:36
Priority: 10
1-68
State: Candidate
Scope: Global

Priority: 10
HoldTime: 150
To view the RP information learned on a switch, use the display pim rp-info command. For example:
# View the RP information on Switch B.
[SwitchB] display pim rp-info
RP: 10.110.9.1
Priority: 10
HoldTime: 150
Uptime: 00:03:39
Expires: 00:01:51
RP: 10.110.10.1
Priority: 20
HoldTime: 150
Uptime: 00:03:39
Expires: 00:01:51
RP: 10.110.1.2 (local)
Priority: 0
HoldTime: 150
Uptime: 00:07:44
Expires: 00:01:51
# View the RP information on Switch D.

[SwitchD] display pim rp-info
RP: 10.110.9.1
Priority: 10
HoldTime: 150
Uptime: 00:03:42
Expires: 00:01:48
RP: 10.110.10.1
Priority: 20
HoldTime: 150
Uptime: 00:03:42
1-69
Expires: 00:01:48
RP: 10.110.4.2 (local)
Priority: 0
HoldTime: 150
Uptime: 00:06:54
Expires: 00:02:41
# View the RP information on Switch F.

[SwitchF] display pim rp-info
RP: 10.110.9.1 (local)
Priority: 10
HoldTime: 150
Uptime: 00:00:32
Expires: 00:01:58
RP: 10.110.10.1
Priority: 20
HoldTime: 150
Uptime: 00:00:32
Expires: 00:01:58
PIM-SSM Configuration Example
VLAN-interface 300.
z Switch A connects to stub network N1 through VLAN-interface 100, and to Switch D and Switch E
and to Switch E through VLAN-interface 103 and VLAN-interface 104 respectively.
z Switch E connects to Switch A, Switch B, Switch C and Switch D.
z The SSM group range is 232.1.1.0/24.
1-70
Network diagram
Figure 1-17 Network diagram for PIM-SSM configuration (on switches)
N1
Ethernet
01
t1
-in
an
Vl
01
t1
N2
-in
an
Ethernet
Vl
Ethernet
Vlan-int101 192.168.1.1/24 Vlan-int101 192.168.1.2/24
Vlan-int102 192.168.9.1/24 Vlan-int105 192.168.4.2/24
Switch B Vlan-int200 10.110.2.1/24 Switch E Vlan-int104 192.168.3.2/24
Vlan-int103 192.168.2.1/24 Vlan-int103 192.168.2.2/24
Vlan-int104 192.168.3.1/24 Vlan-int105 192.168.4.1/24

Configure the OSPF protocol for interoperation among the switches in the PIM-SM domain. Ensure the
# Enable IP multicast routing on Switch A, enable PIM-SM on each interface, and run IGMPv3 on
[SwitchA-Vlan-interface100] igmp version 3
1-71
and Switch E is also similar to that on Switch A except that it is not necessary to enable IGMP on the
# Configure the SSM group range to be 232.1.1.0/24 one Switch A.
[SwitchA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[SwitchA] pim
[SwitchA-pim] ssm-policy 2000
[SwitchA-pim] quit
The configuration on Switch B, Switch C, Switch D and Switch E is similar to that on Switch A.
# View the PIM configuration information on Switch A.
[SwitchA] display pim interface
Vlan100 0 30 1 10.110.1.1 (local)
Vlan101 1 30 1 192.168.1.2
Vlan102 1 30 1 192.168.9.2
Assume that Host A needs to receive the information a specific multicast source S (10.110.5.100/24)
sends to multicast group G (232.1.1.1). Switch A builds an SPT toward the multicast source. Switches
on the SPT path (Switch A and Switch D) have generated an (S, G) entry, while Switch E, which is not
on the SPT path, does not have multicast routing entries. You can use the display pim routing-table
command to view the PIM routing table information on each switch. For example:
(10.110.5.100, 232.1.1.1)
UpTime: 00:13:25
1-72

(10.110.5.100, 232.1.1.1)
UpTime: 00:12:05
Troubleshooting PIM Configuration

Failure of Building a Multicast Distribution Tree Correctly
Symptom
None of the routers in the network (including routers directly connected with multicast sources and
receivers) has multicast forwarding entries. That is, a multicast distribution tree cannot be built correctly
and clients cannot receive multicast data.
Analysis
z When PIM-DM runs on the entire network, multicast data is flooded from the first hop router
connected with the multicast source to the last hop router connected with the clients along the SPT.
When the multicast data is flooded to a router, no matter which router is, it creates (S, G) entries
only if it has a route to the multicast source. If the router does not have a route to the multicast
source, or if PIM-DM is not enabled on the routers RPF interface to the multicast source, the router
cannot create (S, G) entries.
z When PIM-SM runs on the entire network, and when a router is to join the SPT, the router creates
(S, G) entries only if it has a route to the multicast source. If the router does not have a router to the
multicast source, or if PIM-DM is not enabled on the routers RPF interface to the multicast source,
the router cannot create (S, G) entries.
z When a multicast router receives a multicast packet, it searches the existing unicast routing table
for the optimal route to the RPF check object. The outgoing interface of this route will act as the
RPF interface and the next hop will be taken as the RPF neighbor. The RPF interface completely
relies on the existing unicast route, and is independent of PIM. The RPF interface must be
PIM-enabled, and the RPF neighbor must also be a PIM neighbor. If PIM is not enabled on the
router where the RPF interface or the RPF neighbor resides, the establishment of a multicast
distribution tree will surely fail, causing abnormal multicast forwarding.
z Because a hello message does not carry the PIM mode information, a router running PIM is unable
to know what PIM mode its PIM neighbor is running. If different PIM modes are enabled on the RPF
1-73
interface and on the corresponding interface of the RPF neighbor router, the establishment of a
multicast distribution tree will surely fail, causing abnormal multicast forwarding.
z The same PIM mode must run on the entire network. Otherwise, the establishment of a multicast
distribution tree will surely fail, causing abnormal multicast forwarding.
Solution
1) Check unicast routes. Use the display ip routing-table command to check whether a unicast
route exists from the receiver host to the multicast source.
2) Check that PIM is enabled on the interfaces, especially on the RPF interface. Use the display pim
interface command to view the PIM information on each interface. If PIM is not enabled on the
interface, use the pim dm or pim sm command to enable PIM-DM or PIM-SM.
3) Check that the RPF neighbor is a PIM neighbor. Use the display pim neighbor command to view
the PIM neighbor information.
4) Check that PIM and IGMP are enabled on the interfaces directly connecting to the multicast source
and to the receivers.
5) Check that the same PIM mode is enabled on related interfaces. Use the display pim interface
verbose command to check whether the same PIM mode is enabled on the RPF interface and the
corresponding interface of the RPF neighbor router.
6) Check that the same PIM mode is enabled on all the routers in the entire network. Make sure that
the same PIM mode is enabled on all the routers: PIM-SM on all routers, or PIM-DM on all routers.
In the case of PIM-SM, also check that the BSR and RP configurations are correct.
Multicast Data Abnormally Terminated on an Intermediate Router
Symptom
An intermediate router can receive multicast data successfully, but the data cannot reach the last hop
router. An interface on the intermediate router receives data but no corresponding (S, G) entry is
created in the PIM routing table.
Analysis
z When a router receives a multicast packet, it decrements the TTL value of the multicast packet by
1 and recalculates the checksum value. The router then forwards the packet to all outgoing
interfaces. If the multicast minimum-ttl command is configured on the outgoing interfaces, the
TTL value of the packet must be larger than the configured minimum TTL value; otherwise, the
packet will be discarded.
z If a multicast forwarding boundary has been configured through the multicast boundary
command, any multicast packet will be kept from crossing the boundary, and therefore no routing
entry can be created in the PIM routing table.
z In addition, the source-policy command is used to filter received multicast packets. If the multicast
data fails to pass the ACL rule defined in this command, PIM cannot create the route entry, either.
Solution
1) Check the minimum TTL value for multicast forwarding. Use the display current-configuration
command to check the minimum TTL value for multicast forwarding. Increase the TTL value or
remove the multicast minimum-ttl command configured on the interface.
2) Check the multicast forwarding boundary configuration. Use the display current-configuration
command to check the multicast forwarding boundary settings. Use the multicast boundary
command to change the multicast forwarding boundary settings.
1-74
3) Check the multicast filter configuration. Use the display current-configuration command to
check the multicast filter configuration. Change the ACL rule defined in the source-policy
command so that the source/group address of the multicast data can pass ACL filtering.
RPs Unable to Join SPT in PIM-SM
Symptom
An RPT cannot be established correctly, or the RPs cannot join the SPT to the multicast source.
Analysis
z As the core of a PIM-SM domain, the RPs serve specific multicast groups. Multiple RPs can coexist
in a network. Make sure that the RP information on all routers is exactly the same, and a specific
group is mapped to the same RP. Otherwise, multicast forwarding will fail.
z If the static RP mechanism is used, the same static RP command must be executed on all the
routers in the entire network. Otherwise, multicast forwarding will fail.
Solution
1) Check that a route is available to the RP. Carry out the display ip routing-table command to
check whether a route is available on each router to the RP.
2) Check the dynamic RP information. Use the display pim rp-info command to check whether the
RP information is consistent on all routers.
3) Check the configuration of static RPs. Use the display pim rp-info command to check whether the
same static RP address has been configured on all the routers in the entire network.
RPT Establishment Failure or Source Registration Failure in PIM-SM
Symptom
C-RPs cannot unicast advertise messages to the BSR. The BSR does not advertise bootstrap
messages containing C-RP information and has no unicast route to any C-RP. An RPT cannot be
established correctly, or the DR cannot perform source register with the RP.
Analysis
z The C-RPs periodically send C-RP-Adv messages to the BSR by unicast. If a C-RP has no unicast
route to the BSR, the BSR cannot receive C-RP-Adv messages from that C-RP and the bootstrap
message of the BSR will not contain the information of that C-RP.
z In addition, if the BSR does not have a unicast router to a C-RP, it will discard the C-RP-Adv
messages from that C-RP, and therefore the bootstrap messages of the BSR will not contain the
information of that C-RP.
z The RP is the core of a PIM-SM domain. Make sure that the RP information on all routers is exactly
the same, a specific group G is mapped to the same RP, and unicast routes are available to the
RP.
Solution
1) Check whether routes to C-RPs and the BSR are available. Carry out the display ip routing-table
command to check whether routes are available on each router to the RP and the BSR, and
whether a route is available between the RP and the BSR. Make sure that each C-RP has a unicast
route to the BSR, the BSR has a unicast route to each C-RP, and all the routers in the entire
network have a unicast route to the RP.
1-75
2) Check the RP and BSR information. PIM-SM needs the support of the RP and BSR. Use the
display pim bsr-info command to check whether the BSR information is available on each router,
and then use the display pim rp-info command to check whether the RP information is correct.
3) View PIM neighboring relationships. Use the display pim neighbor command to check whether
the normal PIM neighboring relationships have been established among the routers.
1-76
Table of Contents
1 IPv6 Multicast Routing and Forwarding Configuration 1-1

IPv6 Multicast Routing and Forwarding Overview 1-1
Introduction to IPv6 Multicast Routing and Forwarding1-1
RPF Check Mechanism1-2
Configuring IPv6 Multicast Routing and Forwarding1-5
Enabling IPv6 Multicast Routing1-5
Configuring an IPv6 Multicast Routing Policy1-5
Configuring an IPv6 Multicast Forwarding Range1-5
Configuring the IPv6 Multicast Forwarding Table Size 1-6
Configuring RPF Check Failure Processing1-7
Displaying and Maintaining IPv6 Multicast Routing and Forwarding1-9
Troubleshooting IPv6 Multicast Policy Configuration1-10
Abnormal Termination of IPv6 Multicast Data 1-10
i

Configuring special processing of
multicast packets upon RPF No No No No
check failure
1 IPv6 Multicast Routing and Forwarding

Configuration
When configuring IPv6 multicast routing and forwarding, go to the following sections for information you
are interested in:
z IPv6 Multicast Routing and Forwarding Overview
z Configuring IPv6 Multicast Routing and Forwarding
z Displaying and Maintaining IPv6 Multicast Routing and Forwarding
z Troubleshooting IPv6 Multicast Policy Configuration
The term router in this document refers to a router in a generic sense or a Layer 3 switch running an
IPv6 multicast routing protocol.
IPv6 Multicast Routing and Forwarding Overview

Introduction to IPv6 Multicast Routing and Forwarding
In IPv6 multicast implementations, multicast routing and forwarding are implemented by three types of
tables:
Each IPv6 multicast routing protocol has its own multicast routing table, such as IPv6 PIM routing table.
The multicast routing information of different IPv6 multicast routing protocols forms a general IPv6
multicast routing table.
1-1
The IPv6 multicast forwarding table is directly used to control the forwarding of IPv6 multicast packets.
This is the table that guides IPv6 multicast forwarding.
An IPv6 multicast forwarding table consists of a set of (S, G) entries, each indicating the routing
information for delivering multicast data from a multicast source to a multicast group. If a router supports
multiple IPv6 multicast protocols, its IPv6 multicast routing table will include routes generated by these
protocols. The router chooses the optimal route from the IPv6 multicast routing table based on the
configured multicast routing and forwarding policy and installs the route entry into its IPv6 multicast
forwarding table.
RPF Check Mechanism
An IPv6 multicast routing protocol relies on the existing IPv6 unicast routing information or IPv6 MBGP
routes in creating IPv6 multicast routing entries. When creating IPv6 multicast routing table entries, an
IPv6 multicast routing protocol uses the reverse path forwarding (RPF) check mechanism to ensure
IPv6 multicast data delivery along the correct path. In addition, the RPF check mechanism also helps
avoid data loops caused by various reasons.
RPF Check process
The basis for an RPF check is an IPv6 unicast route or an IPv6 MBGP route.
An IPv6 unicast routing table contains the shortest path to each destination subnet;
An IPv6 MBGP routing table contains IPv6 multicast routing information.
When performing an RPF check, a router searches its IPv6 unicast routing table and IPv6 MBGP
routing table at the same time. The specific process is as follows:
The router first chooses an optimal route from the IPv6 unicast routing table and IPv6
MBGP routing table respectively:
The router searches its IPv6 unicast routing table using the IPv6 address of the packet source as the
destination address and automatically selects the optimal route as the RPF route. The outgoing
interface in the corresponding routing entry is the RPF interface and the next hop is the RPF neighbor.
The router considers the path along which the IPv6 multicast packet from the RPF neighbor arrived on
the RPF interface to be the shortest path that leads back to the source.
The router automatically chooses an optimal IPv6 MBGP route by searching its MBGP routing table,
using the IPv6 address of the packet source as the destination address. The outgoing interface in the
corresponding routing entry is the RPF interface and the next hop is the RPF neighbor.
Then, the router selects one from these two optimal routes as the RPF route. The selection
If configured to use the longest match principle, the router selects the longest match route from the two;
if these two routes have the same prefix length, the router selects the route with a higher priority; if these
two routes have the same priority, the router selects the IPv6 MBGP route as the RPF route.
If not configured to use the longest match principle, the router selects the route with a higher priority; if
these two routes have the same priority, the router selects the IPv6 MBGP route as the RPF route.
1-2
The above-mentioned packet source can mean different things in different situations:
z For a packet traveling along the shortest path tree (SPT) from the multicast source to the receivers
or the rendezvous point (RP), the packet source for RPF check is the multicast source.
z For a packet traveling along the rendezvous point tree (RPT) from the RP to the receivers, the
packet source for RPF check is the RP.
z For a bootstrap message from the bootstrap router (BSR), the packet source for RPF check is the
BSR.
For details about the concepts of SPT, RPT, RP and BSR, refer to IPv6 PIM Configuration in the IP
Multicast Volume.
Implementation of the RPF check in IPv6 multicast
Implementing an RPF check on each received IPv6 multicast data packet would bring a big burden to
the router. The use of an IPv6 multicast forwarding table is the solution to this issue. When creating an
IPv6 multicast routing entry and an IPv6 multicast forwarding entry for an IPv6 multicast packet, the
router sets the RPF interface of the packet as the incoming interface of the (S, G) entry. Upon receiving
an (S, G) IPv6 multicast packet, the router first searches its IPv6 multicast forwarding table:
1) If the corresponding (S, G) entry does not exist in the IPv6 multicast forwarding table, the packet is
subject to an RPF check. The router creates an IPv6 multicast routing entry based on the relevant
routing information and installs the entry into the IPv6 multicast forwarding table, with the RPF
interface as the incoming interface.
If the interface on which the packet actually arrived is the RPF interface, the RPF check succeeds and
the router forwards the packet to all the outgoing interfaces.
If the interface on which the packet actually arrived is not the RPF interface, the RPF check fails and the
router discards the packet.
2) If the corresponding (S, G) entry exists, and the interface on which the packet actually arrived is the
incoming interface, the router forwards the packet to all the outgoing interfaces.
3) If the corresponding (S, G) entry exists, but the interface on which the packet actually arrived is not
the incoming interface in the IPv6 multicast forwarding table, the IPv6 multicast packet is subject to
an RPF check.
If the RPF interface is the incoming interface of the (S, G) entry, this means the (S, G) entry is correct
but the packet arrived from a wrong path. The packet is to be discarded.
If the RPF interface is not the incoming interface, this means the (S, G) entry has expired, and router
replaces the incoming interface with the RPF interface. If the interface on which the packet arrived in the
RPF interface, the router forwards the packet to all the outgoing interfaces; otherwise it discards the
packet.
1-3
Some device models allow you to configure special processing of IPv6 multicast packets that have
failed an RPF check instead of simply dropping them. For details, refer to Configuring RPF Check
Failure Processing.
Assume that IPv6 unicast routes are available in the network, IPv6 MBGP is not configured, and IPv6
multicast packets travel along the SPT from the multicast source to the receivers, as shown in Figure
1-1. The IPv6 multicast forwarding table on Router C contains the (S, G) entry, with POS 5/1 as the RPF
interface.
Figure 1-1 RPF check process
z When an IPv6 multicast packet arrives on POS 5/1 of Router C, as the interface is the incoming
interface of the (S, G) entry, the router forwards the packet to all outgoing interfaces.
When an IPv6 multicast packet arrives on POS 5/0 of Router C, as the interface is not the incoming
interface of the (S, G) entry, the router performs an RPF check on the packet: The router searches its
IPv6 unicast routing table and finds that the outgoing interface to Source (the RPF interface) is POS 5/1.
This means the (S, G) entry is correct and packet arrived along a wrong path. The RPF check fails and
the packet is discarded.

Complete these tasks to configure IPv6 multicast routing and forwarding:
Task Remarks
Enabling IPv6 Multicast Routing Required
Configuring an IPv6 Multicast Routing Policy Optional
Configuring an IPv6 Multicast Forwarding Range Optional
Configuring the IPv6 Multicast Forwarding Table Size Optional
Configuring RPF Check Failure Processing Optional
1-4
Configuring IPv6 Multicast Routing and Forwarding
Before configuring IPv6 multicast routing and forwarding, complete the following tasks:
Configure an IPv6 unicast routing protocol so that all devices in the domain are interoperable at the
network layer.
Configure IPv6 PIM-DM or IPv6 PIM-SM.
Before configuring IPv6 multicast routing and forwarding, prepare the following data:
Minimum hop limit value required for an IPv6 multicast packet to be forwarded
Maximum number of downstream nodes for a single entry in the IPv6 multicast forwarding table
Maximum number of entries in the IPv6 multicast forwarding table
Enabling IPv6 Multicast Routing
Before configuring any Layer 3 IPv6 multicast functionality, you must enable IPv6 multicast routing.
Follow these steps to enable IPv6 multicast routing:
To do Use the Command Remarks

Required
Enable IPv6 multicast routing multicast ipv6 routing-enable
Disabled by default
Configuring an IPv6 Multicast Routing Policy
If more than one IPv6 unicast route with the same cost exists when a multicast router selects an
upstream interface, you can configure the router to determine the RPF route based on the longest
match (that is, by prefix length).
With the load splitting feature enabled, IPv6 multicast traffic will be evenly distributed among equal-cost
routes.
Follow these steps to configure an IPv6 multicast routing policy:

Configure the device to select a Optional

route based on the longest multicast ipv6 longest-match In order of routing table entries
match by default
Configure IPv6 multicast load multicast ipv6 load-splitting Optional

splitting {source | source-group } Disabled by default
Configuring an IPv6 Multicast Forwarding Range
IPv6 multicast packets do not travel infinitely in a network. The IPv6 multicast data of each IPv6
multicast group must be transmitted within a definite scope. Presently, you can define an IPv6 multicast
forwarding range by:
1-5
specifying boundary interfaces, which form a closed IPv6 multicast forwarding area, or
setting the minimum hop limit value required for an IPv6 multicast packet to be forwarded.
You can configure the forwarding boundary for a specific IPv6 multicast group on all interfaces that
support IPv6 multicast forwarding. A multicast forwarding boundary sets the boundary condition for the
IPv6 multicast groups in the specified range. If the destination address of an IPv6 multicast packet
matches the set boundary condition, the packet will not be forwarded. Once an IPv6 multicast boundary
is configured on an interface, this interface can no longer forward IPv6 multicast packets (including
those sent from the local device) or receive IPv6 multicast packets.
You can configure the minimum hop limit required for an IPv6 multicast packet to be forwarded on all
interfaces that support IPv6 multicast forwarding. Before being forwarded from an interface, every IPv6
multicast packet (including every IPv6 multicast packet sent from the local device) is subject to a hop
limit check:
If the hop limit value of the packet (already decremented by 1 on this router) is greater than the
minimum hop limit value configured on the interface, the packet will be forwarded.
If the hop limit value of the packet is less than the minimum hop limit value configured on the interface,
the packet will be discarded.
Follow these steps to configure an IPv6 multicast forwarding range:

interface-number
Required
Configure an IPv6 multicast multicast ipv6 boundary
forwarding boundary ipv6-group-address prefix-length No forwarding boundary
by default
Configure the minimum hop
limit value required for an IPv6 multicast ipv6 minimum-hoplimit Required
multicast packet to be hoplimit-value 1 by default
forwarded
The support for the multicast ipv6 minimum-hoplimit command varies with devices.
Configuring the IPv6 Multicast Forwarding Table Size
The router maintains the corresponding forwarding entry for each IPv6 multicast packet it receives.
Excessive IPv6 multicast routing entries, however, can exhaust the routers memory and thus result in
lower router performance. You can set a limit on the number of entries in the IPv6 multicast forwarding
table based on the actual networking situation and the performance requirements. If the configured
maximum number of IPv6 multicast forwarding table entries is smaller than the current value, the
entries in excess will not be immediately deleted; instead they will be deleted by the IPv6 multicast
routing protocol running on the router. The router will no longer install new IPv6 multicast forwarding
1-6
entries until the number of existing IPv6 multicast forwarding entries comes down below the configured
value.
When forwarding IPv6 multicast traffic, the router replicates a copy of the IPv6 multicast traffic for each
downstream node and forwards the traffic, and thus each of these downstream nodes forms a branch of
the IPv6 multicast distribution tree. You can configure the maximum number of downstream nodes
(namely, the maximum number of outgoing interfaces) for a single entry in the IPv6 multicast forwarding
table to lessen burden on the router for replicating IPv6 multicast traffic. If the configured maximum
number of downstream nodes for a single IPv6 multicast forwarding entry is smaller than the current
number, the downstream nodes in excess will not be deleted immediately; instead they must be deleted
by the IPv6 multicast routing protocol. The router will no longer install new IPv6 multicast forwarding
entries for newly added downstream nodes until the number of existing downstream nodes comes
down below the configured value.
Follow these steps to configure the IPv6 multicast forwarding table size:

Optional
Configure the maximum multicast ipv6 The default is the maximum
number of entries in the IPv6 forwarding-table route-limit number allowed by the system,
multicast forwarding table limit of which the specific value
Optional
multicast ipv6 The default is the maximum
number of downstream nodes
forwarding-table number allowed by the system,
for a single IPv6 multicast
downstream-limit limit of which the specific value
forwarding entry
Configuring RPF Check Failure Processing
The support for this feature depends on the device model.
After an IPv6 multicast packet fails an RPF check, it may need to be processed differently in different
networking environments instead of being simply dropped.
Flooding the IPv6 multicast packet to all the ports in the native VLAN
In practice, an IPv6 multicast packet that failed an RPF check on a VLAN interface may be expected by
some receivers in the VLAN. You can enable flooding multicast packets in the VLAN after RPF failure so
that such receivers can receive them.
1-7
Follow these steps to enable flooding IPv6 multicast packets that failed an RPF check in the native
VLAN:


Different device models support this
configuration in different command
interface interface-type views: some models support this
Enter VLAN interface view command in system view, while
interface-number
other devices support this command
in VLAN interface view, but no
devices support this configuration in
both views.
Enable flooding IPv6 multicast Required
multicast ipv6
packets that failed an RPF
non-rpf-pkt broadcast Disabled by default
check in the native VLAN
After the configuration, you must use the reset multicast ipv6 forwarding-table command to clear all
the forwarding entries in the IPv6 multicast forwarding table; otherwise this configuration cannot take
effect.
Passing the packet that to the CPU
In the following two cases, an IPv6 multicast packet that failed the RPF check needs to be passed to the
CPU:
When an IPv6 multicast packet arrives on an outgoing interface of the corresponding IPv6 multicast
forwarding entry, the packet will fail the RPF check and needs to be sent to the CPU in order to trigger
the assert mechanism to prune the unwanted branch.
If the SPT and RPT have different incoming interfaces on the receiver-side DR (the last-hop router), the
IPv6 multicast traffic will fail the RPF check on the SPT incoming interface during an RPT-to-SPT
switchover before the RPF information is refreshed. If the RPT is pruned at this moment, the multicast
service will be instantaneously interrupted. By passing IPv6 packets that failed the RPF check on a
non-outgoing interface to the CPU, the router can determine whether the packets that have failed the
RPF check on the SPT interface are expected. If they are, the router initiates an RPT prune.
For more information about the assert mechanism, DR and RPT-to-SPT switchover, refer to IPv6 PIM
Configuration in the IP Multicast Volume.
Follow these steps to enable passing packets that failed the RPF check to the CPU:

Enable passing packets that multicast ipv6 non-rpf-pkt Required

failed an RPF check to the CPU trap-to-cpu Disabled by default
1-8
After the configuration, you must use the reset multicast ipv6 forwarding-table command to clear all
the forwarding entries in the IPv6 multicast forwarding table; otherwise this configuration cannot take
effect.
Displaying and Maintaining IPv6 Multicast Routing and Forwarding

display multicast ipv6 boundary

Display the IPv6 multicast boundary [ ipv6-group-address [ prefix-length ] | Available in any
information interface interface-type view
interface-number ]
display multicast ipv6

forwarding-table [ ipv6-source-address
[ prefix-length ] | ipv6-group-address
[ prefix-length ] | incoming-interface
On a centralized Available in any
{ interface-type interface-number |
device view
register } | outgoing-interface
{ { exclude | include | match }
Display the { interface-type interface-number |
information of register } } | statistics ] * [ port-info ]
the IPv6 display multicast ipv6
multicast forwarding-table [ ipv6-source-address
forwarding table [ prefix-length ] | ipv6-group-address
[ prefix-length ] | incoming-interface
On a distributed { interface-type interface-number | Available in any
device register } | outgoing-interface view
{ { exclude | include | match }
{ interface-type interface-number |
register } } | statistics | slot slot-number ]
* [ port-info ]
display multicast ipv6 routing-table

[ ipv6-source-address [ prefix-length ] |
ipv6-group-address [ prefix-length ] |
Display the information of the IPv6 incoming-interface { interface-type Available in any
multicast routing table interface-number | register } | view
outgoing-interface { { exclude | include
| match } { interface-type
interface-number | register } } ] *
display multicast ipv6 rpf-info

Display the RPF route information of Available in any
ipv6-source-address
the specified IPv6 multicast source view
[ ipv6-group-address ]
Display the minimum hop limit display multicast ipv6
Available in any
required for an IPv6 multicast minimum-hoplimit [ interface-type
view
packet to be forwarded interface-number ]
reset multicast ipv6 forwarding-table
{ { ipv6-source-address [ prefix-length ] |
Clear forwarding entries from the Available in user
IPv6 multicast forwarding table view
incoming-interface { interface-type
interface-number | register } } * | all }
1-9
reset multicast ipv6 routing-table

{ { ipv6-source-address [ prefix-length ] |
Clear routing entries from the IPv6 Available in user
multicast routing table view
incoming-interface { interface-type
interface-number | register } } * | all }
The support for the display multicast ipv6 minimum-hoplimit command varies with device models.
z The reset command clears the information in the IPv6 multicast routing table or the multicast
forwarding table, and thus may cause transmission failure of IPv6 multicast information.
z When a routing entry is deleted from the IPv6 multicast routing table, the corresponding forwarding
entry will also be deleted from the IPv6 multicast forwarding table.
z When a forwarding entry is deleted from the IPv6 multicast forwarding table, the corresponding
routing entry will also be deleted from the IPv6 multicast routing table.
Troubleshooting IPv6 Multicast Policy Configuration

Abnormal Termination of IPv6 Multicast Data
Symptom
A host sends an MLD report announcing its joining an IPv6 multicast group (G). However, there is no
member information about the IPv6 multicast group (G) on the immediate router. The intermediate
router can receive IPv6 multicast packets successfully, but the packets cannot reach the stub network.
The interface of the intermediate router receives the IPv6 multicast packets, but there is no
corresponding (S, G) entry in the IPv6 PIM routing table.
Analysis
Before forwarding an IPv6 multicast packet, the router decrements the hop limit value in the IPv6 packet
header by 1 and recalculates the checksum. Subsequently, the router forwards the IPv6 multicast
packet to all outgoing interfaces. If the multicast ipv6 minimum-hoplimit command is executed on the
outgoing interfaces, the hop limit value in the IPv6 packet header must be no less than the configured
minimum hop limit value. Otherwise, the packet will be discarded.
The multicast ipv6 boundary command is used to filter IPv6 multicast packets received on an
interface. If an IPv6 multicast packet fails to match the IPv6 ACL rule of this command, IPv6 PIM will
create no routing entry.
In addition, the source-policy command in IPv6 PIM is used to filter received IPv6 multicast packets. If
an IPv6 multicast packet fails to match the IPv6 ACL rule of this command, IPv6 PIM will not create a
routing entry, either.
1-10
Solution
Use the debugging mfib ipv6 command to display the debugging information. If IPv6 multicast
packets are found to have been discarded because of too small hop limit value, use the
display multicast ipv6 minimum-hoplimit command to view the minimum hop limit required
for an IPv6 multicast packet to be forwarded. Use the undo multicast ipv6 minimum-hoplimit
command on the concerned interfaces to restore the default hop limit setting, or configure
multicast packets to be sent with a higher hop limit value from the multicast source.
Use the display current-configuration command to display the IPv6 ACL rule configured on
the multicast forwarding boundary. Change the IPv6 ACL rule used in the multicast ipv6
boundary command so that the source address of the IPv6 multicast packets and the IPv6
multicast group address can both match the IPv6 ACL rule.
Check the configuration of the multicast filter. Use the display current-configuration
command to view the configuration of the IPv6 multicast filter, and change the IPv6 ACL
rule used in the source-policy command so that the source address of the IPv6 multicast
packets and the IPv6 multicast group address can both match the IPv6 ACL rule.
1-11
Table of Contents
1 MLD Snooping Configuration1-1

MLD Snooping Overview 1-1
Introduction to MLD Snooping1-1
Basic Concepts in MLD Snooping1-2
How MLD Snooping Works 1-3
Processing of IPv6 Multicast Protocol Messages 1-5
MLD Snooping Configuration Task List 1-6
Configuring Basic Functions of MLD Snooping 1-7
Enabling MLD Snooping1-7
Configuring the Version of MLD Snooping 1-8
Configuring MLD Snooping Port Functions 1-8
Configuring Aging Timers for Dynamic Ports 1-9
Configuring Static Ports1-9
Configuring Simulated Joining1-10
Configuring Fast Leave Processing 1-11
Configuring MLD Snooping Querier1-12
Enabling MLD Snooping Querier1-12
Configuring MLD Queries and Responses1-13
Configuring Source IPv6 Addresses of MLD Queries 1-14
Configuring an MLD Snooping Policy 1-14
Configuring an IPv6 Multicast Group Filter1-15
Configuring IPv6 Multicast Source Port Filtering1-16
Configuring Dropping Unknown IPv6 Multicast Data 1-16
Configuring MLD Report Suppression1-17
Configuring Maximum Multicast Groups that Can Be Joined on a Port1-18
Configuring IPv6 Multicast Group Replacement 1-19
Displaying and Maintaining MLD Snooping 1-20
MLD Snooping Configuration Examples 1-20
Configuring IPv6 Group Policy and Simulated Joining1-20
Static Router Port Configuration1-23
MLD Snooping Querier Configuration 1-25
Troubleshooting MLD Snooping 1-27
Switch Fails in Layer 2 Multicast Forwarding 1-27
Configured IPv6 Multicast Group Policy Fails to Take Effect1-27
i
Configuring IPv6 Yes

Yes
multicast source No No Supported by FIC
filtering Supported by MIM board
board
Configuring the Yes

function of dropping Supported by MIM board
No No Yes
unknown IPv6 and the 30-11 series
multicast data routers with XMIM board
1 MLD Snooping Configuration
When configuring MLD Snooping, go to these sections for information you are interested in:
z MLD Snooping Overview
z MLD Snooping Configuration Task List
z Displaying and Maintaining MLD Snooping
z MLD Snooping Configuration Examples
z Troubleshooting MLD Snooping
MLD Snooping Overview

Multicast Listener Discovery Snooping (MLD Snooping) is an IPv6 multicast constraining mechanism
that runs on Layer 2 devices to manage and control IPv6 multicast groups.
Introduction to MLD Snooping
By analyzing received MLD messages, a Layer 2 device running MLD Snooping establishes mappings
between ports and multicast MAC addresses and forwards IPv6 multicast data based on these
mappings.
As shown in Figure 1-1, when MLD Snooping is not running, IPv6 multicast packets are broadcast to all
devices at Layer 2. When MLD Snooping runs, multicast packets for known IPv6 multicast groups are
multicast to the receivers at Layer 2.
1-1
Figure 1-1 Before and after MLD Snooping is enabled on the Layer 2 device
IPv6 multicast packet transmission IPv6 multicast packet transmission

without MLD Snooping when MLD Snooping runs
Multicast router Multicast router
Source Source
Layer 2 switch Layer 2 switch
Host A Host C Host A Host C

Receiver Receiver Receiver Receiver
Host B Host B
IPv6 multicast packets
Basic Concepts in MLD Snooping
MLD Snooping related ports
As shown in Figure 1-2, Router A connects to the multicast source, MLD Snooping runs on Switch A
and Switch B, Host A and Host C are receiver hosts (namely, IPv6 multicast group members).
Figure 1-2 MLD Snooping related ports
Receiver
Router A Switch A
Eth1/0 Eth1/1
Eth1/2 Host A
Host B
Eth1/0 Receiver
Source Eth1/1
Switch B Host C
Router port
Member port
IPv6 multicast packets
Host D
Ports involved in MLD Snooping, as shown in Figure 1-2, are described as follows:
z Router port: A router port is a port on the Ethernet switch that leads switch towards the Layer-3
multicast device (DR or MLD querier). In the figure, Ethernet 1/0 of Switch A and Ethernet 1/0 of
Switch B are router ports. The switch registers all its local router ports in its router port list.
1-2
z Member port: A member port (also known as IPv6 multicast group member port) is a port on the
Ethernet switch that leads towards multicast group members. In the figure, Ethernet 1/1 and
Ethernet 1/2 of Switch A and Ethernet 1/1 of Switch B are member ports. The switch registers all
the member ports on the local device in its MLD Snooping forwarding table.
z Whenever mentioned in this document, a router port is a router-connecting port on the switch,
rather than a port on a router.
z Unless otherwise specified, router/member ports mentioned in this document include static and
dynamic ports.
z On an MLD-snooping-enabled switch, the ports that received MLD general queries with the source
address other than 0::0 or IPv6 PIM hello messages are dynamic router ports. For details about
IPv6 PIM hello messages, see IPv6 PIM Configuration of the IP Multicast Volume.
Aging timers for dynamic ports in MLD Snooping
Table 1-1 Aging timers for dynamic ports in MLD Snooping and related messages and actions
Message before
Timer Description Action after expiry
expiry
For each dynamic router port, MLD general query of
The switch removes
Dynamic router the switch sets a timer which the source
this port from its router
port aging timer initialized to the dynamic address is not 0::0 or
port list.
router port aging time. IPv6 PIM hello.
When a port dynamically
joins an IPv6 multicast group, The switch removes
Dynamic
the switch sets a timer for the this port from the MLD
member port MLD report message.
port, which is initialized to the Snooping forwarding
aging timer
dynamic member port aging table.
time.
The port aging mechanism of MLD Snooping works only for dynamic ports; a static port will never age
out.
How MLD Snooping Works
A switch running MLD Snooping performs different actions when it receives different MLD messages,
as follows:
1-3
The description about adding or deleting a port in this section is only for a dynamic port. Static ports can
be added or deleted only through the corresponding configurations. For details, see Configuring Static
Ports.
General queries
The MLD querier periodically sends MLD general queries to all hosts and routers (FF02::1) on the local
subnet to find out whether IPv6 multicast group members exist on the subnet.
Upon receiving an MLD general query, the switch forwards it through all ports in the VLAN except the
port on which it received the MLD query and performs the following:
z If the port on which it the switch received the MLD query is a dynamic router port in its router port
list, the switch resets the aging timer for this dynamic router port.
z If the port is not included in its router port list, the switch adds it into its router port list as a dynamic
router port and sets an aging timer for it.
Membership reports
A host sends an MLD report to the MLD querier in the following circumstances:
z Upon receiving an MLD query, an IPv6 multicast group member host responds with an MLD report.
z When intended to join an IPv6 multicast group, a host sends an MLD report to the MLD querier to
announce that it is interested in the multicast information addressed to that IPv6 multicast group.
Upon receiving an MLD report, the switch forwards it through all the router ports in the VLAN, resolves
the address of the reported IPv6 multicast group, and performs the following to the receiving port:
z If no forwarding table entry exists for the reported IPv6 multicast group, the switch creates an entry,
adds the port as a dynamic member port to the outgoing port list, and starts a member port aging
timer for that port.
z If a forwarding table entry exists for the reported IPv6 multicast group, but the port is not included in
the outgoing port list for that group, the switch adds the port as a dynamic member port to the
outgoing port list, and starts a member port aging timer for that port.
z If a forwarding table entry exists for the reported IPv6 multicast group and the port is included in the
outgoing port list, which means that this port is already a dynamic member port, the switch resets
the member port aging timer for that port.
A switch does not forward an MLD report through a non-router port. The reason is as follows: Due to the
MLD report suppression mechanism, if the switch forwards a report message through a member port,
all the attached hosts listening to the reported IPv6 multicast address will suppress their own reports
upon receiving this report, and this will prevent the switch from knowing whether the reported multicast
group still has active members attached to that port.
For the description of MLD report suppression mechanism, refer to MLD Configuration in the IP
Multicast volume.
1-4
Done messages
When a host leaves an IPv6 multicast group, the host sends an MLD done message to the multicast
router.
When the switch receives an MLD done message on a dynamic member port, the switch first checks
whether a forwarding table entry for the IPv6 multicast group address in the message exists, and, if one
exists, whether the outgoing port list contains the port.
z If the forwarding table entry does not exist or if the outgoing port list does not contain the port, the
switch discards the MLD done message instead of forwarding it to any port.
z If the forwarding table entry exists and the outgoing port list contains the port, the switch forwards
the MLD done message to all router ports in the native VLAN. Because the switch does not know
whether any other hosts attached to the port are still listening to that IPv6 multicast group address,
the switch does not immediately remove the port from the outgoing port list of the forwarding table
entry for that group; instead, it resets the aging timer for the port.
Upon receiving an MLD done message from a host, the MLD querier resolves the IPv6 multicast group
address in the message and sends an MLD multicast-address-specific query to that IPv6 multicast
group address through the port that received the MLD done message. Upon receiving the MLD
multicast-address-specific query, the switch forwards it through all the router ports in the VLAN and all
member ports for that IPv6 multicast group, and performs the following to the receiving port:
z If any MLD report in response to the MLD multicast-address-specific query is received on the port
(suppose it is a dynamic member port) before its aging timer expires, this means that some host
attached to the port is receiving or expecting to receive IPv6 multicast data for that IPv6 multicast
group. The switch resets the aging timer for the port.
z If no MLD report in response to the MLD multicast-address-specific query is received on the port
before its aging timer expires, this means that no hosts attached to the port are still listening to that
IPv6 multicast group address. The switch removes the port from the outgoing port list of the
forwarding table entry for that IPv6 multicast group when the aging timer expires.
Processing of IPv6 Multicast Protocol Messages
With Layer 3 multicast routing enabled, an MLD Snooping switch processes IPv6 multicast protocol
messages differently under different conditions, specifically as follows:
1) If only MLD is enabled, or both MLD and IPv6 PIM are enabled on the switch, the switch handles
IPv6 multicast protocol messages in the normal way.
2) In only IPv6 PIM is enabled on the switch:
z The switch broadcasts MLD messages as unknown messages in the VLAN.
z Upon receiving an IPv6 PIM hello message, the switch will maintain the corresponding dynamic
router port.
3) When MLD is disabled on the switch:
z If IPv6 PIM is disabled, the switch deletes all its dynamic member ports and dynamic router ports.
z If IPv6 PIM is enabled, the switch deletes only its dynamic member ports without deleting its
dynamic router ports.
1-5
On a switch with Layer-3 IPv6 multicast routing enabled, use the display mld group port-info
command to view Layer-2 port information.
For details about the display mld group port-info command, refer to MLD Commands in the IP
Multicast Volume.
4) When IPv6 PIM is disabled on the switch:

z If MLD is disabled, the switch deletes all its dynamic router ports without deleting its dynamic
member ports.
z If MLD is enabled, the switch maintains all its dynamic member ports and dynamic router ports.
MLD Snooping is documented in:

z RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping Switches
MLD Snooping Configuration Task List

Complete these tasks to configure MLD Snooping:
Task Remarks
Configuring Basic Enabling MLD Snooping Required

Functions of MLD Snooping Configuring the Version of MLD Snooping Optional
Configuring Aging Timers for Dynamic Ports Optional
Configuring MLD Snooping Configuring Static Ports Optional

Port Functions Configuring Simulated Joining Optional
Configuring Fast Leave Processing Optional
Enabling MLD Snooping Querier Optional
Configuring MLD Snooping
Configuring MLD Queries and Responses Optional
Querier
Configuring Source IPv6 Addresses of MLD Queries Optional
Configuring an IPv6 Multicast Group Filter Optional
Configuring IPv6 Multicast Source Port Filtering Optional
Configuring Dropping Unknown IPv6 Multicast Data Optional
Configuring an MLD
Snooping Policy Configuring MLD Report Suppression Optional
Configuring Maximum Multicast Groups that Can Be
Optional
Joined on a Port
Configuring IPv6 Multicast Group Replacement Optional
1-6
z Configurations made in MLD Snooping view are effective for all VLANs, while configurations made
in VLAN view are effective only for ports belonging to the current VLAN. For a given VLAN, a
configuration made in MLD Snooping view is effective only if the same configuration is not made in
VLAN view.
z Configurations made in MLD Snooping view are effective for all ports; configurations made in
Ethernet interface view are effective only for the current port; configurations made in Layer 2
aggregate interface view are effect only for the current interface; configurations made in port group
view are effective only for all the ports in the current port group. For a given port, a configuration
made in MLD Snooping view is effective only if the same configuration is not made in Ethernet
interface view, Layer 2 aggregate interface view or port group view.
z For MLD Snooping, configurations made on a Layer 2 aggregate interface do not interfere with
configurations made on its member ports; nor do they take part in aggregation calculations.
Configuring Basic Functions of MLD Snooping

Before configuring the basic functions of MLD Snooping, complete the following tasks:
z Configure the corresponding VLANs
Before configuring the basic functions of MLD Snooping, prepare the following data:
z The version of MLD Snooping
Enabling MLD Snooping
Follow these steps to enable MLD Snooping:

Enable MLD Snooping globally Required

mld-snooping
and enter MLD-Snooping view Disabled by default
Enable MLD Snooping in the Required

mld-snooping enable
VLAN Disabled by default
1-7
z MLD Snooping must be enabled globally before it can be enabled in a VLAN.
z After enabling MLD Snooping in a VLAN, you cannot enable MLD and/or IPv6 PIM on the
corresponding VLAN interface, and vice versa.
z When you enable MLD Snooping in a specified VLAN, this function takes effect for ports in this
VLAN only.
Configuring the Version of MLD Snooping
By configuring the MLD Snooping version, you actually configure the version of MLD messages that
MLD Snooping can process.
z MLD Snooping version 1 can process MLDv1 messages, but cannot analyze and process MLDv2
messages, which will be flooded in the VLAN.
z MLD Snooping version 2 can process MLDv1 and MLDv2 messages.
Follow these steps to configure the version of MLD Snooping:

Configure the version of MLD mld-snooping version Optional

Snooping version-number Version 1 by default
If you switch MLD Snooping from version 2 to version 1, the system will clear all MLD Snooping
forwarding entries from dynamic joins, and will:
z Keep forwarding entries from version 2 static (*, G) joins;
z Clear forwarding entries from version 2 static (S, G) joins, which will be restored when MLD
Snooping is switched back to version 2.
For details about static joins, Refer to Configuring Static Ports.
Configuring MLD Snooping Port Functions

Before configuring MLD Snooping port functions, complete the following tasks:
z Enable MLD Snooping in the VLAN or enable MLD on the desired VLAN interface
z Configure the corresponding port groups
Before configuring MLD Snooping port functions, prepare the following data:
z Aging time of dynamic router ports,
1-8
z Aging timer of dynamic member ports, and
z IPv6 multicast group and IPv6 multicast source addresses
Configuring Aging Timers for Dynamic Ports
If the switch receives no MLD general queries or IPv6 PIM hello messages on a dynamic router port,
the switch removes the port from the router port list when the aging timer of the port expires.
If the switch receives no MLD reports for an IPv6 multicast group on a dynamic member port, the switch
removes the port from the outgoing port list of the forwarding table entry for that IPv6 multicast group
when the port aging timer expires.
If IPv6 multicast group memberships change frequently, you can set a relatively small value for the
dynamic member port aging timer.
Configuring aging timers for dynamic ports globally
Follow these steps to configure aging timers for dynamic ports globally:

Enter MLD Snooping view mld-snooping
Configure dynamic router port Optional

router-aging-time interval
aging time 260 seconds by default
Configure dynamic member Optional

host-aging-time interval
port aging time 260 seconds by default
Configuring aging timers for dynamic ports in a VLAN
Follow these steps to configure aging timers for dynamic ports in a VLAN:

Configure dynamic router port mld-snooping Optional

aging time router-aging-time interval 260 seconds by default
Configure dynamic member mld-snooping Optional

port aging time host-aging-time interval 260 seconds by default
Configuring Static Ports
If all the hosts attached to a port is interested in the IPv6 multicast data addressed to a particular IPv6
multicast group, you can configure that port as a static member port for that IPv6 multicast group.
You can configure a port of a switch to be a static router port, through which the switch can forward all
IPv6 multicast data it received.
1-9
Follow these steps to configure static ports:


interface/Layer 2 interface-number Required
aggregate interface view port-group manual Use either approach
or port group view port-group-name
mld-snooping static-group Required

Configure the port(s) as
ipv6-group-address [ source-ip No static member ports by
static member port(s)
ipv6-source-address ] vlan vlan-id default
Configure the port(s) as mld-snooping static-router-port Required

static router port(s) vlan vlan-id No static router ports by default
z An IPv6 static (S, G) join takes effect only if a valid IPv6 multicast source address is specified and
MLD Snooping version 2 is currently running.
z A static member port does not respond to queries from the MLD querier; when static (*, G) or (S, G)
joining is enabled or disabled on a port, the port does not send an unsolicited MLD report or an
MLD done message.
z If MLD is enabled on the virtual interface of a VLAN on a switch that supports both MLD Snooping
and MLD and you want a port in that VLAN to be a static member port for an IPv6 multicast group
or an IPv6 multicast source and group, in addition to configuring the port as a static member port,
you need to use the mld static-group command to configure the VLAN interface to be a static
member of the IPv6 multicast group or source and group. For details of the mld static-group
command, refer to MLD Commands in the IP Multicast Volume.
z Static member ports and static router ports never age out. To remove such a port, you need to use
the corresponding undo command.
Configuring Simulated Joining
Generally, a host running MLD responds to MLD queries from the MLD querier. If a host fails to respond
due to some reasons, the multicast router will deem that no member of this IPv6 multicast group exists
on the network segment, and therefore will remove the corresponding forwarding path.
To avoid this situation from happening, you can enable simulated joining on a port of the switch, namely
configure the port as a simulated member host for an IPv6 multicast group. When an MLD query is
received, simulated host gives a response. Thus, the switch can continue receiving IPv6 multicast data.
A simulated host acts like a real host, as follows:
z When a port is configured as a simulated member host, the switch sends an unsolicited MLD
report through that port.
z After a port is configured as a simulated member host, the switch responds to MLD general queries
by sending MLD reports through that port.
1-10
z When the simulated joining function is disabled on a port, the switch sends an MLD done message
through that port.
Follow these steps to configure simulated joining:

Enter Ethernet interface/Layer interface interface-type interface-number Required

port group view port-group manual port-group-name Use either approach
mld-snooping host-join Required

Configure simulated joining ipv6-group-address [ source-ip
ipv6-source-address ] vlan vlan-id Disabled by default
z Each simulated host is equivalent to an independent host. For example, when receiving an MLD
query, the simulated host corresponding to each configuration responds respectively.
z Unlike a static member port, a port configured as a simulated member host will age out like a
dynamic member port.
Configuring Fast Leave Processing
The fast leave processing feature allows the switch to process MLD done messages in a fast way. With
the fast leave processing feature enabled, when receiving an MLD done message on a port, the switch
immediately removes that port from the outgoing port list of the forwarding table entry for the indicated
IPv6 multicast group. Then, when receiving MLD done multicast-address-specific queries for that IPv6
multicast group, the switch will not forward them to that port.
In VLANs where only one host is attached to each port, fast leave processing helps improve bandwidth
and resource usage.
Configuring fast leave processing globally
Follow these steps to configure fast leave processing globally:

Required
Enable fast leave processing fast-leave [ vlan vlan-list ]
Disabled by default
Configuring fast leave processing on a port or a group of ports
Follow these steps to configure fast leave processing on a port or a group of ports:

1-11
port-group-name
mld-snooping fast-leave Required

Enable fast leave processing
[ vlan vlan-list ] Disabled by default
If fast leave processing is enabled on a port to which more than one host is connected, when one host
leaves an IPv6 multicast group, the other hosts connected to port and interested in the same IPv6
multicast group will fail to receive IPv6 multicast data addressed to that group.
Configuring MLD Snooping Querier

Before configuring MLD Snooping querier, complete the following task:

z Enable MLD Snooping in the VLAN.
Before configuring MLD Snooping querier, prepare the following data:
z MLD general query interval,
z MLD last-member query interval,
z Maximum response time for MLD general queries,
z Source IPv6 address of MLD general queries, and
z Source IPv6 address of MLD multicast-address-specific queries.
Enabling MLD Snooping Querier
In an IPv6 multicast network running MLD, a multicast router or Layer 3 multicast switch is responsible
for sending periodic MLD general queries, so that all Layer 3 multicast devices can establish and
maintain multicast forwarding entries, thus to forward multicast traffic correctly at the network layer.
This router or Layer 3 switch is called MLD querier.
However, a Layer 2 multicast switch does not support MLD, and therefore cannot send MLD general
queries by default. By enabling MLD Snooping querier on a Layer 2 switch in a VLAN where multicast
traffic needs to be Layer-2 switched only and no Layer 3 multicast devices are present, the Layer 2
switch will act as the MLD querier to send periodic MLD queries, thus allowing multicast forwarding
entries to be established and maintained at the data link layer.
Follow these steps to enable the MLD Snooping querier:

1-12
Enable the MLD Snooping Required

mld-snooping querier
querier Disabled by default
It is meaningless to configure an MLD Snooping querier in an IPv6 multicast network running MLD.
Although an MLD Snooping querier does not take part in MLD querier elections, it may affect MLD
querier elections because it sends MLD general queries with a low source IPv6 address.
For details about MLD querier, see MLD Configuration of the IP Multicast Volume.
Configuring MLD Queries and Responses
You can tune the MLD general query interval based on actual condition of the network.
Upon receiving an MLD query (general query or multicast-address-specific query), a host starts a timer
for each IPv6 multicast group it has joined. This timer is initialized to a random value in the range of 0 to
the maximum response time (the host obtains the value of the maximum response time from the Max
Response Time field in the MLD query it received). When the timer value comes down to 0, the host
sends an MLD report to the corresponding IPv6 multicast group.
An appropriate setting of the maximum response time for MLD queries allows hosts to respond to
queries quickly and avoids bursts of MLD traffic on the network caused by reports simultaneously sent
by a large number of hosts when the corresponding timers expire simultaneously.
z For MLD general queries, you can configure the maximum response time to fill their Max
z For MLD multicast-address-specific queries, you can configure the MLD last-member query
interval to fill their Max Response time field. Namely, for MLD multicast-address-specific queries,
the maximum response time equals to the MLD last-member query interval.
Configuring MLD queries and responses globally
Follow these steps to configure MLD queries and responses globally:

Configure the maximum response time max-response-time Optional

for MLD general queries interval 10 seconds by default
Configure the MLD last-member query last-listener-query-int Optional

interval erval interval 1 second by default
Configuring MLD queries and responses in a VLAN
Follow these steps to configure MLD queries and responses in a VLAN
1-13
mld-snooping query-interval Optional

Configure MLD query interval
mld-snooping max-response-time
response time for MLD general
queries
Configure the MLD mld-snooping Optional

last-member query interval last-listener-query-interval interval 1 second by default
Make sure that the MLD query interval is greater than the maximum response time for MLD general
queries; otherwise undesired deletion of IPv6 multicast members may occur.
Configuring Source IPv6 Addresses of MLD Queries
This configuration allows you to change the source IPv6 address of MLD queries.
Follow these steps to configure source IPv6 addresses of MLD queries:

Configure the source IPv6 mld-snooping general-query Optional

address of MLD general source-ip { current-interface | FE80::02FF:FFFF:FE00:0001
queries ipv6-address } by default
Configure the source IPv6 Optional
mld-snooping special-query
address of MLD
source-ip { current-interface | FE80::02FF:FFFF:FE00:0001
multicast-address-specific
ipv6-address } by default
queries
The source IPv6 address of MLD query messages may affect MLD querier election within the segment.
Configuring an MLD Snooping Policy

Before configuring an MLD Snooping policy, complete the following tasks:
1-14
z Enable MLD Snooping in the VLAN or enable MLD on the desired VLAN interface
Before configuring an MLD Snooping policy, prepare the following data:
z IPv6 ACL rule for IPv6 multicast group filtering
z The maximum number of IPv6 multicast groups that can pass the ports
Configuring an IPv6 Multicast Group Filter
On a MLD Snoopingenabled switch, the configuration of an IPv6 multicast group filter allows the
service provider to define limits of multicast programs available to different users.
In an actual application, when a user requests a multicast program, the users host initiates an MLD
report. Upon receiving this report message, the switch checks the report against the configured ACL
rule. If the port on which the report was received can join this IPv6 multicast group, the switch adds an
entry for this port in the MLD Snooping forwarding table; otherwise the switch drops this report
message. Any IPv6 multicast data that fails the ACL check will not be sent to this port. In this way, the
service provider can control the VOD programs provided for multicast users.
Configuring an IPv6 multicast group filter globally
Follow these steps to configure an IPv6 multicast group globally:

Required
Configure an IPv6 multicast group-policy acl6-number No IPv6 filter configured by
group filter [ vlan vlan-list ] default, namely hosts can join
any IPv6 multicast group.
Configuring an IPv6 multicast group filter on a port or a group of ports
Follow these steps to configure an IPv6 multicast group filer on a port or a group of ports:

port-group-name
Required
Configure an IPv6 multicast mld-snooping group-policy No IPv6 filter configured by
group filter acl6-number [ vlan vlan-list ] default, namely hosts can join
any IPv6 multicast group.
1-15
Configuring IPv6 Multicast Source Port Filtering
The support for this feature depends on the specific device model.
With the IPv6 multicast source port filtering feature enabled on a port, the port can be connected with
IPv6 multicast receivers only rather than with multicast sources, because the port will block all IPv6
multicast data packets while it permits multicast protocol packets to pass.
If this feature is disabled on a port, the port can be connected with both multicast sources and IPv6
multicast receivers.
Configuring IPv6 multicast source port filtering globally
Follow these steps to configure IPv6 multicast source port filtering:

Enable IPv6 multicast source Required

source-deny port interface-list
port filtering Disabled by default
Configuring IPv6 multicast source port filtering on a port or a group of ports
Follow these steps to configure IPv6 multicast source port filtering on a port or a group of ports:


interface view or port
group view Use either approach
Enable IPv6 multicast Required

mld-snooping source-deny
source port filtering Disabled by default
Some models of devices, when enabled to filter IPv6 multicast data based on the source ports, are
automatically enabled to filter IPv4 multicast data based on the source ports.
Configuring Dropping Unknown IPv6 Multicast Data
Unknown IPv6 multicast data refers to IPv6 multicast data for which no forwarding entries exist in the
MLD Snooping forwarding table: When the switch receives such IPv6 multicast traffic:
1-16
z With the function of dropping unknown IPv6 multicast data enabled, the switch drops all unknown
IPv6 multicast data received.
z With the function of dropping unknown IPv6 multicast data disabled, the switch floods unknown
IPv6 multicast data in the VLAN to which the unknown IPv6 multicast data belongs.
Enabling dropping unknown IPv6 multicast data globally
Follow these steps to enable dropping unknown IPv6 multicast data globally:

Enable dropping unknown IPv6 Required

drop-unknown
multicast data Disabled by default
Enabling dropping unknown IPv6 multicast data in a VLAN
Follow these steps to enable dropping unknown IPv6 multicast data in a VLAN:

Enable dropping unknown IPv6 Required

mld-snooping drop-unknown
multicast data Disabled by default
z The support for the drop-unknown and mld-snooping drop-unknown commands varies with
device models. Some devices support both commands at the same time, while some other devices
support only one of them. Refer to your specific device model.
z For devices that support both drop-unknown and mld-snooping drop-unknown commands at
the same time, the configuration made in MLD Snooping view and the configuration made in VLAN
view are mutually exclusive. Namely, after this function is enabled in MLD Snooping view, it cannot
be enabled or disabled in VLAN view, and vice versa.
z Some models of devices, when enabled to drop unknown IPv6 multicast data, are automatically
enabled to drop unknown IPv4 multicast data.
z Some models of devices, when enabled to drop unknown IPv6 multicast data, still forward
unknown IPv6 multicast data to other router ports in the VLAN.
Configuring MLD Report Suppression
When a Layer 2 device receives an MLD report from an IPv6 multicast group member, the Layer 2
device forwards the message to the Layer 3 device directly connected with it. Thus, when multiple
members belonging to an IPv6 multicast group exist on the Layer 2 device, the Layer 3 device directly
connected with it will receive duplicate MLD reports from these members.
1-17
With the MLD report suppression function enabled, within a query interval, the Layer 2 device forwards
only the first MLD report of an IPv6 group to the Layer 3 device and will not forward the subsequent
MLD reports from the same multicast group to the Layer 3 device. This helps reduce the number of
packets being transmitted over the network.
Follow these steps to configure MLD report suppression:

Enable MLD report Optional

report-aggregation
suppression Enabled by default
Configuring Maximum Multicast Groups that Can Be Joined on a Port
By configuring the maximum number of IPv6 multicast groups that can be joined on a port or a group of
ports, you can limit the number of multicast programs available to VOD users, thus to control the traffic
on the port.
Follow these steps configure the maximum number of IPv6 multicast groups that can be joined on a
port or a group of ports:

Enter Ethernet interface/Layer 2 interface-number Required
aggregate interface view or port
group view port-group manual Use either approach
port-group-name
Configure the maximum number of Optional

mld-snooping group-limit limit
IPv6 multicast groups that can be The default depends on
[ vlan vlan-list ]
joined on a port the product model.
z When the number of IPv6 multicast groups that can be joined on a port reaches the maximum
number configured, the system deletes all the forwarding entries persistent to that port from the
MLD Snooping forwarding table, and the hosts on this port need to join IPv6 multicast groups
again.
z If you have configured static or simulated joins on a port, however, when the number of IPv6
multicast groups on the port exceeds the configured threshold, the system deletes all the
forwarding entries persistent to that port from the MLD Snooping forwarding table and applies the
static or simulated joins again, until the number of IPv6 multicast groups joined by the port comes
back within the configured threshold.
1-18
Configuring IPv6 Multicast Group Replacement
For some special reasons, the number of IPv6 multicast groups passing through a switch or port may
exceed the number configured for the switch or the port. In addition, in some specific applications, an
IPv6 multicast group newly joined on the switch needs to replace an existing IPv6 multicast group
automatically. A typical example is channel switching, namely, by joining the new multicast group, a
user automatically switches from the current IPv6 multicast group to the new one.
To address this situation, you can enable the IPv6 multicast group replacement function on the switch
or certain ports. When the number of IPv6 multicast groups a switch or a port has joined exceeds the
limit.
z If the IPv6 multicast group replacement is enabled, the newly joined IPv6 multicast group
automatically replaces an existing IPv6 multicast group with the lowest IPv6 address.
z If the IPv6 multicast group replacement is not enabled, new MLD reports will be automatically
discarded.
Configuring IPv6 multicast group replacement globally
Follow these steps to configure IPv6 multicast group replacement globally:

Enable IPv6 multicast group overflow-replace [ vlan Required

replacement vlan-list ] Disabled by default
Configuring IPv6 multicast group replacement on a port or a group of ports
Follow these steps to configure IPv6 multicast group replacement on a port or a group of ports:

port-group-name
mld-snooping Required
Enable IPv6 multicast group
overflow-replace [ vlan
replacement Disabled by default
vlan-list ]
Be sure to configure the maximum number of IPv6 multicast groups allowed on a port (refer to
Configuring Maximum Multicast Groups that Can Be Joined on a Port) before enabling IPv6 multicast
group replacement. Otherwise, the IPv6 multicast group replacement functionality will not take effect.
1-19
Displaying and Maintaining MLD Snooping
On a centralized display mld-snooping group [ vlan Available in any
View MLD device vlan-id ] [ verbose ] view
Snooping
multicast group display mld-snooping group [ vlan
On a distributed Available in any
information vlan-id ] [ slot slot-number ]
device view
[ verbose ]
View the statistics information of
Available in any
MLD messages learned by MLD display mld-snooping statistics
view
Snooping
reset mld-snooping group
Clear MLD Snooping multicast group Available in user
{ ipv6-group-address | all } [ vlan
information view
vlan-id ]
Clear the statistics information of all
Available in user
kinds of MLD messages learned by reset mld-snooping statistics
view
MLD Snooping
z The reset mld-snooping group command works only on an MLD Snoopingenabled VLAN, but
not on a VLAN with MLD enabled on its VLAN interface.
z The reset mld-snooping group command cannot clear the MLD Snooping multicast group
information for static joins.
MLD Snooping Configuration Examples

Configuring IPv6 Group Policy and Simulated Joining
z As shown in Figure 1-3, Router A connects to the IPv6 multicast source through Ethernet 1/1 and
to Switch A through Ethernet 1/0. Router A is the MLD querier on the subnet.
z MLDv1 is required on Router A, MLD Snooping version 1 is required on Switch A, and Router A will
act as the MLD querier on the subnet.
z It is required that the receivers, Host A and Host B, attached to Switch A can receive IPv6 multicast
traffic addressed to IPv6 multicast group FF1E::101 only.
z It is required that IPv6 multicast data for group FF1E::101 can be forwarded through Ethernet 1/2
and Ethernet 1/3 of Switch A even if Host A and Host B accidentally, temporarily stop receiving
IPv6 multicast data.
1-20
Network diagram
Figure 1-3 Network diagram for IPv6 group policy simulated joining configuration
Receiver
Host A
Source
Eth1/3
Receiver
Eth1/1 Eth1/0
1::2/64 2001::1/64 Eth1/0 Eth1/2
1::1/64 Router A Switch A Eth1/1 Host B

MLD querier
Host C
1) Enable IPv6 forwarding and configure IPv6 addresses

Enable IPv6 forwarding and configure an IPv6 address and prefix length for each interface as per
Figure 1-3. The detailed configuration steps are omitted.
# Enable IPv6 multicast routing, enable IPv6 PIM-DM on each interface, and enable MLDv1 on
Ethernet 1/0.
[RouterA] multicast ipv6 routing-enable
[RouterA-Ethernet1/0] mld enable
[RouterA-Ethernet1/0] pim ipv6 dm
# Enable MLD Snooping globally.
[SwitchA] mld-snooping
[SwitchA-mld-snooping] quit
# Create VLAN 100, assign Ethernet 1/0 through Ethernet 1/3 to this VLAN, and enable MLD Snooping
and the function of dropping IPv6 unknown multicast traffic in the VLAN.
[SwitchA] vlan 100
[SwitchA-vlan100] mld-snooping enable
[SwitchA-vlan100] mld-snooping drop-unknown
1-21
# Configure an IPv6 multicast group filter so that the hosts in VLAN 100 can join only the IPv6 multicast
group FF1E::101
[SwitchA] acl ipv6 number 2001
[SwitchA-acl6-basic-2001] rule permit source ff1e::101 128
[SwitchA-acl6-basic-2001] quit
[SwitchAmld-snooping] group-policy 2001 vlan 100
[SwitchAmld-snooping] quit
# Configure Ethernet 1/2 and Ethernet 1/3 as simulated hosts for IPv6 multicast group FF1E::101.
[SwitchA-Ethernet1/2] mld-snooping host-join ff1e::101 vlan 100
[SwitchA-Ethernet1/3] mld-snooping host-join ff1e::101 vlan 100
# View the detailed MLD Snooping multicast group information in VLAN 100 on Switch A.
[SwitchA] display mld-snooping group vlan 100 verbose

Vlan(id):100.
Eth1/0 (D) ( 00:01:30 )
IP group address:FF1E::101
(::, FF1E::101):
Eth1/2 (D) ( 00:03:23 )
Eth1/3 (D) ( 00:04:10 )
MAC group(s):
MAC group address:3333-0000-1001
Eth1/2
Eth1/3
As shown above, Ethernet 1/2 and Ethernet 1/3 of Switch A have joined IPv6 multicast group
FF1E::101.
1-22
Static Router Port Configuration
z As shown in Figure 1-4, Router A connects to an IPv6 multicast source (Source) through Ethernet
1/1, and to Switch A through Ethernet 1/0.
z MLDv1 is to run on Router A, and MLDv1 Snooping is to run on Switch A, Switch B and Switch C,
with Router A acting as the MLD querier.
z Suppose STP runs on the network. To avoid data loops, the forwarding path from Switch A to
Switch C is blocked under normal conditions, and IPv6 multicast traffic flows to the receivers, Host
A and Host C, attached to Switch C only along the path of Switch ASwitch BSwitch C.
z Now it is required to configure Ethernet 1/2 that connects Switch A to Switch C as a static router
port, so that IPv6 multicast traffic can flow to the receivers nearly uninterruptedly along the path of
Switch ASwitch C in the case that the path of Switch ASwitch BSwitch C gets blocked.
If no static router port is configured, when the path of Switch ASwitch BSwitch C gets blocked, at
least one MLD query-response cycle must be completed before the IPv6 multicast data can flow to the
receivers along the new path of Switch ASwitch C, namely IPv6 multicast delivery will be interrupted
during this process.
For details about the Spanning Tree Protocol (STP), refer to MSTP Configuration in the Access
Volume.
Network diagram
Figure 1-4 Network diagram for static router port configuration
Source
Switch A
Eth1/1 Eth1/0
1::2/64 2001::1/64 Eth1/0
1/2
Eth
Router A
Eth
1::1/64
1/1
MLD querier
1/0
Eth
Switch C
Eth
1/0

1/3
Eth
Host C Switch B
Eth
1/2
Receiver
Host B Host A
Receiver
1-23
1) Enable IPv6 forwarding and configure IPv6 addresses

Enable IPv6 forwarding and configure an IPv6 address and prefix length for each interface as per
Figure 1-4.
# Enable IPv6 multicast routing, enable IPv6 PIM-DM on each interface, and enable MLD on Ethernet
1/0.
in the VLAN.
[SwitchA] vlan 100
# Configure Ethernet 1/2 to be a static router port.

[SwitchA-Ethernet1/2] mld-snooping static-router-port vlan 100
[SwitchB] mld-snooping
[SwitchB-mld-snooping] quit
# Create VLAN 100, assign Ethernet 1/0 and Ethernet 1/1 to this VLAN, and enable MLD Snooping in
the VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port ethernet 1/0 ethernet 1/1
[SwitchB-vlan100] mld-snooping enable
1-24
[SwitchC] mld-snooping
[SwitchC-mld-snooping] quit
in the VLAN.
[SwitchC] vlan 100
[SwitchC-vlan100] mld-snooping enable
[SwitchC-vlan100] quit
# View the detailed MLD Snooping multicast group information in VLAN 100 on Switch A.
[SwitchA] display mld-snooping group vlan 100 verbose

Vlan(id):100.
Eth1/0 (D) ( 00:01:30 )
Eth1/2 (S)
IP group address:FF1E::101
(::, FF1E::101):
Eth1/1 (D) ( 00:03:23 )
MAC group(s):
MAC group address:3333-0000-0101
Eth1/1
As shown above, Ethernet 1/2 of Switch A has become a static router port.
MLD Snooping Querier Configuration
z As shown in Figure 1-5, in a Layer-2-only network environment, Switch C is attached to the

multicast source (Source) through Ethernet 1/2. At least one receiver is connected to Switch B and
Switch C respectively.
z MLDv1 is enabled on all the receivers. Switch A, Switch B, and Switch C run MLDv1 Snooping.
Switch A acts as the MLD Snooping querier.
1-25
Network diagram
Figure 1-5 Network diagram for MLD Snooping querier configuration
1) Configure switch A
# Enable IPv6 forwarding and enable MLD Snooping globally.
[SwitchA] ipv6
# Create VLAN 100 and add Ethernet 1/0 and Ethernet 1/1 to VLAN 100.
[SwitchA] vlan 100
[SwitchA-vlan100] port ethernet 1/0 ethernet 1/1
# Enable MLD Snooping in VLAN 100 and configure the MLD-Snooping querier feature.
[SwitchA-vlan100] mld-snooping querier
[SwitchB] ipv6
[SwitchB] mld-snooping
[SwitchB-mld-snooping] quit
# Create VLAN 100, add Ethernet 1/0 through Ethernet 1/2 into VLAN 100, and enable MLD Snooping
in this VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port ethernet 1/0 to ethernet 1/2
[SwitchB-vlan100] mld-snooping enable
3) Configuration on Switch C
1-26
[SwitchC] ipv6
[SwitchC] mld-snooping
[SwitchC-mld-snooping] quit
# Create VLAN 100, add Ethernet 1/0 through Ethernet 1/2 to VLAN 100, and enable MLD Snooping in
this VLAN.
[SwitchC] vlan 100
[SwitchC-vlan100] mld-snooping enable
# View the MLD message statistics on Switch C.
[SwitchC-vlan100] display mld-snooping statistics
Received MLD general queries:3.
Received MLDv1 specific queries:0.
Received MLDv1 reports:4.
Received MLD dones:0.
Sent MLDv1 specific queries:0.
Received MLDv2 reports:0.
Received MLDv2 reports with right and wrong records:0.
Received MLDv2 specific queries:0.
Received MLDv2 specific sg queries:0.
Sent MLDv2 specific queries:0.
Sent MLDv2 specific sg queries:0.
Received error MLD messages:0.
Switch C received MLD general queries. This means that Switch A works as an MLD-Snooping querier.
Troubleshooting MLD Snooping

Switch Fails in Layer 2 Multicast Forwarding
Symptom
A switch fails to implement Layer 2 multicast forwarding.
Analysis
MLD Snooping is not enabled.
Solution
1) Enter the display current-configuration command to view the running status of MLD Snooping.
2) If MLD Snooping is not enabled, use the mld-snooping command to enable MLD Snooping
globally, and then use mld-snooping enable command to enable MLD Snooping in VLAN view.
3) If MLD Snooping is disabled only for the corresponding VLAN, just use the mld-snooping enable
command in VLAN view to enable MLD Snooping in the corresponding VLAN.
Configured IPv6 Multicast Group Policy Fails to Take Effect
Symptom
Although an IPv6 multicast group policy has been configured to allow hosts to join specific IPv6
multicast groups, the hosts can still receive IPv6 multicast data addressed to other groups.
1-27
Analysis
z The IPv6 ACL rule is incorrectly configured.

z The IPv6 multicast group policy is not correctly applied.
z The function of dropping unknown IPv6 multicast data is not enabled, so unknown IPv6 multicast
data is flooded.
z Certain ports have been configured as static member ports of IPv6 multicasts groups, and this
configuration conflicts with the configured IPv6 multicast group policy.
Solution
1) Use the display acl ipv6 command to check the configured IPv6 ACL rule. Make sure that the
IPv6 ACL rule conforms to the IPv6 multicast group policy to be implemented.
2) Use the display this command in MLD Snooping view or the corresponding interface view to
check whether the correct IPv6 multicast group policy has been applied. If not, use the
group-policy or mld-snooping group-policy command to apply the correct IPv6 multicast group
policy.
3) Use the display current-configuration command to check whether the function of dropping
unknown IPv6 multicast data is enabled. If not, use the drop-unknown or mld-snooping
drop-unknown command to enable the function of dropping unknown IPv6 multicast data.
4) Use the display mld-snooping group command to check whether any port has been configured
as a static member port of any IPv6 multicast group. If so, check whether this configuration
conflicts with the configured IPv6 multicast group policy. If any conflict exists, remove the port as a
static member of the IPv6 multicast group.
1-28
Table of Contents
1 MLD Configuration 1-1

MLD Overview1-1
MLD Versions 1-2
How MLDv1 Works1-2
How MLDv2 Works1-4
MLD Message Types1-5
Introduction to MLD SSM Mapping 1-8
Configuring Basic Functions of MLD1-9
Enabling MLD 1-10
Configuring the MLD Version 1-10
Configuring Static Joining1-11
Configuring an IPv6 Multicast Group Filter1-12
Adjusting MLD Performance 1-12
Configuring MLD Message Options 1-12
Configuring MLD Query and Response Parameters1-13
Configuring MLD Fast Leave Processing1-16
Configuring MLD SSM Mapping 1-17
Enabling MLD SSM Mapping 1-17
Configuring MLD SSM Mappings 1-17
Displaying and Maintaining MLD Configuration1-18
MLD Configuration Examples (On Routers) 1-19
Basic MLD Functions Configuration Example1-19
MLD SSM Mapping Configuration Example1-21
MLD Configuration Examples (On Switches) 1-25
Basic MLD Functions Configuration Example1-25
MLD SSM Mapping Configuration Example1-27
Troubleshooting MLD1-30
No Member Information on the Receiver-Side Router 1-30
Inconsistent Memberships on Routers on the Same Subnet 1-30
i

Yes Yes Yes Yes
(Include/Exclude)
1 MLD Configuration
The term router in this document refers to a router in a generic sense or a Layer 3 switch running the
MLD protocol.
When configuring MLD, go to the following sections for information you are interested in:
z MLD Overview
z Displaying and Maintaining MLD Configuration
z MLD Configuration Examples (On Routers)
z MLD Configuration Examples (On Switches)
z Troubleshooting MLD
MLD Overview
The Multicast Listener Discovery protocol (MLD) is used by an IPv6 router to discover the presence of
multicast listeners on the directly attached subnets. Multicast listeners are nodes wishing to receive
IPv6 multicast packets.
Through MLD, the router can learn whether there are any IPv6 multicast listeners on the directly
connected subnets, put corresponding records in the database, and maintain timers related to IPv6
multicast addresses.
Routers running MLD use an IPv6 unicast link-local address as the source address to send MLD
messages. MLD messages are Internet Control Message Protocol for IPv6 (ICMPv6) messages. All
MLD messages are confined to the local subnet, with a hop count of 1.
1-1
MLD Versions
So far, two MLD versions are available:

z MLDv1 (defined in RFC 2710), which is derived from IGMPv2.
z MLDv2 (defined in RFC 3810), which is derived from IGMPv3.
All MLD versions support the Any-Source Multicast (ASM) model. In addition, MLDv2 can be directly
deployed to implement the Source-Specific Multicast (SSM) model, while MLDv1 needs to work with
the MLD SSM mapping function to implement SSM service.
For more information about the ASM and SSM models, see Multicast Overview in the IP Multicast
Volume.
How MLDv1 Works
MLDv1 implements IPv6 multicast listener management based on the query/response mechanism.
MLDv1 uses two types of query messages:
MLD querier election
Of multiple IPv6 multicast routers on the same subnet, all the routers can hear MLD listener report
messages (often referred to as reports) from hosts, but only one router is needed for sending MLD
query messages (often referred to as queries). So, a querier election mechanism is required to
determine which router will act as the MLD querier on the subnet.
1) Initially, every MLD router assumes itself as the querier and sends MLD general query messages
(often referred to as general queries) to all hosts and routers on the local subnet (the destination
address is FF02::1).
2) Upon hearing a general query, every MLD router compares the source IPv6 address of the query
message with its own interface address. After comparison, the router with the lowest IPv6 address
wins the querier election and all other routers become non-queriers.
3) All the non-queriers start a timer, known as other querier present timer. If a router receives an
MLD query from the querier before the timer expires, it resets this timer; otherwise, it assumes the
querier to have timed out and initiates a new querier election process.
1-2
Joining an IPv6 multicast group
Figure 1-1 MLD queries and reports
IPv6 network
Querier
Router A Router B
Ethernet

(G2) (G1) (G1)
Query
Report
Assume that Host B and Host C are expected to receive IPv6 multicast data addressed to IPv6
multicast group G1, while Host A is expected to receive IPv6 multicast data addressed to G2, as shown
in Figure 1-1. The following describes how the hosts join the IPv6 multicast groups and the MLD querier
(Router B in the figure) maintains the IPv6 multicast group memberships:
1) The hosts send unsolicited MLD reports to the addresses of the IPv6 multicast groups that they
want to join, without having to wait for the MLD queries from the MLD querier.
2) The MLD querier periodically multicasts MLD queries (with the destination address of FF02::1) to
all hosts and routers on the local subnet.
3) Upon receiving a query message, Host B or Host C (the delay timer of whichever expires first)
sends an MLD report to the IPv6 multicast group address of G1, to announce its membership for
G1. Assume it is Host B that sends the report message. Upon hearing the report from Host B, Host
C, which is on the same subnet with Host B, Host C suppresses its own report for G1, because the
MLD routers (Router A and Router B) already know that at least one host on the local subnet is
interested in G1. This mechanism, known as MLD report suppression, helps reduce traffic on the
local subnet.
4) At the same time, because Host A is interested in G2, it sends a report to the IPv6 multicast group
address of G2.
5) Through the above-mentioned query/report process, the MLD routers learn that members of G1
and G2 are attached to the local subnet, and the IPv6 multicast routing protocol (IPv6 PIM for
example) running on the routers generates (*, G1) and (*, G2) multicast forwarding entries, which
will be the basis for subsequent IPv6 multicast forwarding, where * represents any IPv6 multicast
source.
6) When the IPv6 multicast data addressed to G1 or G2 reaches an MLD router, because the (*, G1)
and (*, G2) multicast forwarding entries exist on the MLD router, the router forwards the IPv6
multicast data to the local subnet, and then the receivers on the subnet receive the data.
Leaving an IPv6 multicast group
When a host leaves a multicast group:
1-3
1) This host sends an MLD done message to all IPv6 multicast routers (the destination address is
FF02::2) on the local subnet.
2) Upon receiving the MLD done message, the querier sends a configurable number of
multicast-address-specific queries to the group being left. The destination address field and group
address field of the message are both filled with the address of the IPv6 multicast group being
queried.
3) One of the remaining members, if any on the subnet, of the group being queried should send a
report within the time of the maximum response delay set in the query messages.
4) If the querier receives a report for the group within the maximum response delay time, it will
maintain the memberships of the IPv6 multicast group; otherwise, the querier will assume that no
hosts on the subnet are still interested in IPv6 multicast traffic addressed to that group and will stop
maintaining the memberships of the group.
How MLDv2 Works
The support for the Exclude mode varies with device models.
Compared with MLDv1, MLDv2 provides the following new features:
IPv6 multicast group filtering
MLDv2 has introduced IPv6 multicast source filtering modes (Include and Exclude), so that a host not
only can join a designated IPv6 multicast group but also can explicitly specify to receive or reject IPv6
multicast data from a designated IPv6 multicast source. When a host joins an IPv6 multicast group G:
z If it needs to receive IPv6 multicast data from specific IPv6 multicast sources like S1, S2, , it
sends a report with the Filter-Mode denoted as Include Sources (S1, S2, ).
z If it needs to reject IPv6 multicast data from specific IPv6 multicast sources like S1, S2, , it sends
a report with the Filter-Mode denoted as Exclude Sources (S1, S2, ).
As shown in Figure 1-2, the network comprises two IPv6 multicast sources, Source 1 (S1) and Source
2 (S2), both of which can send IPv6 multicast data to IPv6 multicast group G. Host B is interested only
in the IPv6 multicast data that Source 1 sends to G but not in the data from Source 2.
1-4
Figure 1-2 Flow paths of source-and-group-specific multicast traffic
Source 1
Host A
Receiver
Host B
Source 2
Host C
Packets (S1,G)
Packets (S2,G)
In the case of MLDv1, Host B cannot select IPv6 multicast sources when it joins IPv6 multicast group G.
Therefore, IPv6 multicast streams from both Source 1 and Source 2 will flow to Host B whether it needs
them or not.
When MLDv2 is running on the hosts and routers, Host B can explicitly express its interest in the IPv6
multicast data Source 1 sends to G (denoted as (S1, G)), rather than the IPv6 multicast data Source 2
sends to G (denoted as (S2, G)). Thus, only IPv6 multicast data from Source 1 will be delivered to Host
B.
MLD state
A multicast router running MLDv2 maintains the multicast address state per multicast address per
attached subnet. The multicast address state consists of the following:
z Filter mode: The router keeps tracing the Include or Exclude state.
z List of sources: The router keeps tracing the newly added or deleted IPv6 multicast source.
z Timers: Filter timer (the time the router waits before switching to the Include mode after an IPv6
multicast address times out), source timer (for source recording), and so on.
Receiver host state listening
By listening to the state of receiver hosts, a multicast router running MLDv2 records and maintains
information of hosts joining the source group on the attached subnet.
MLD Message Types
The following descriptions are based on MLDv2 messages.
MLD query message
An MLD querier learns the multicast listening state of neighbor interfaces by sending MLD query
messages. Figure 1-3 shows the format of an MLD query message. The dark blue area in the figure
shows the format of an MLDv1 message.
1-5
Figure 1-3 Format of MLDv2 query message
0 3 4 7 15 31
Type = 130 Code Checksum
Maximum Response Delay Reserved
Multicast Address (128 bits)
Reserved S QRV QQIC Number of Sources (n)
Source Address [1] (128 bits)
...
Source Address [n] (128 bits)
Table 1-1 describes the fields in Figure 1-3.
Table 1-1 Description on fields in an MLDv2 query message
Field Description
Type = 130 Message type. For a query message, this field is set to 130.
Code Initialized to zero

Checksum Standard IPv6 checksum
Maximum response delay allowed before a host sends a
Maximum Response Delay
report message
Reserved Reserved field and initialized to zero
z This field is set to 0 in a general query message.
Multicast Address z It is set to a specific IPv6 multicast address in a
multicast-address-specific query message or
multicast-address-and-source-specific query message.
Flag indicating whether a router updates the timer for
S
suppression after receiving a query message.
QRV Queriers Robustness Variable
QQIC Queriers Query Interval Code
z This field is set to 0 in a general query message or a
multicast-address-specific query message.
Number of Sources
z This field represents the number of source addresses in a
multicast-address-and-source-specific query message
1-6
Field Description
IPv6 multicast source address in a multicast-address-specific
Source Address( i ) query message (i = 1, 2, .., n, where n represents the number
of multicast source addresses.)
MLD report message
A host sends an MLD report message to report the current multicast listening state Figure 1-4 shows
the format of an MLD report message.
Figure 1-4 Format of MLDv2 report message
...
Table 1-2 describes the fields in Figure 1-4.
Table 1-2 Description on fields in an MLDv2 report message
Field Description
Message type. For a report message, this field is set to
Type = 143
143.
The Reserved fields are set to 0 on transmission and
Reserved
ignored on reception.
Checksum Standard IPv6 checksum
This field indicates how many IPv6 multicast address
Number of Multicast Address Records
records are present in this report message.
This field represents information of each IPv6 multicast

address the host listens to on the interface from which
the report message is sent, including record type, IPv6
Multicast Address Record(i)
multicast address, and IPv6 multicast source address
on the sender (i= 1, 2, ... m, where m represents the
number of IPv6 multicast address records).
1-7
Introduction to MLD SSM Mapping
The MLD SSM mapping feature allows you to configure static MLD SSM mappings on the last hop
router to provide SSM support for receiver hosts running MLDv1. The SSM model assumes that the last
hop router is aware of the desired IPv6 multicast sources when receivers join IPv6 multicast groups.
z When a host running MLDv2 joins a multicast group, it can explicitly specify one or more multicast
sources in its MLDv2 report.
z A host running MLDv1, however, cannot specify multicast source addresses in its MLDv1 report. In
this case, you need to configure the MLD SSM mapping feature to translate the (*, G) information
in the MLDv1 report into (G, INCLUDE, (S1, S2...)) information.
Figure 1-5 Network diagram for MLD SSM mapping
IPv6 SSM
MLDv1 report
Querier
MLDv2 report
Router A
Receiver Receiver Receiver

Host A (MLDv1) Host B (MLDv1) Host C (MLDv2)
As shown in Figure 1-5, on an IPv6 SSM network, Host A and Host B are running MLDv1 and Host C is
running MLDv2. To provide SSM service for all the hosts while it is infeasible to run MLDv2 on Host A
and Host B, you need to configure the MLD SSM mapping feature on Router A.
With the MLD SSM mapping feature configured, when Router A receives an MLDv1 report, it checks
the IPv6 multicast group address G carried in the message:
z If G is not in the IPv6 SSM group range, Router A cannot provide the SSM service but the ASM
service.
z If G is in the IPv6 SSM group range but no MLD SSM mappings corresponding to the IPv6
multicast group G have been configured on Router A, Router A cannot provide SSM service and
drops the packet.
z If G is in the IPv6 SSM group range, and the MLD SSM mappings have been configured on Router
A for multicast group G, Router A translates the (*, G) information in the MLD report into (G,
INCLUDE, (S1, S2...)) information based on the configured MLD SSM mappings and provides
SSM service accordingly.
1-8
The MLD SSM mapping feature does not process MLDv2 reports.
For more information about the IPv6 SSM group range, refer to IPv6 PIM Configuration in the IP
Multicast Volume.
MLD-related specifications are described in the following documents:

z RFC 2710: Multicast Listener Discovery (MLD) for IPv6
z RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6
Task Remarks
Enabling MLD Required
Configuring Basic Configuring the MLD Version Option

Functions of MLD Configuring Static Joining Optional
Configuring an IPv6 Multicast Group Filter Optional
Configuring MLD Message Options Optional
Adjusting MLD
Configuring MLD Query and Response Parameters Optional
Performance
Configuring MLD Fast Leave Processing Optional
Configuring MLD Enabling MLD SSM Mapping Optional

SSM Mapping Configuring MLD SSM Mappings Optional
Configurations performed in MLD view are globally effective, while configurations performed in
interface view are effective on the current interface only.
If no configuration is performed in interface view, the global configurations performed in MLD view will
apply to that interface. Configurations performed in interface view take precedence over those
performed in MLD view.
Configuring Basic Functions of MLD

Before configuring the basic functions of MLD, complete the following tasks:
1-9
z Configure any IPv6 unicast routing protocol so that all devices in the domain can be interoperable
at the network layer.
z Configure IPv6 PIM-DM or IPv6 PIM-SM.
In addition, prepare the following data:
z MLD version
z IPv6 multicast group address and IPv6 multicast source address for static group member
configuration
z ACL rule for IPv6 multicast group filtering
Enabling MLD
Enable MLD on the interface on which IPv6 multicast group memberships are to be created and
maintained.
Follow these steps to enable MLD:

Required
Disable by default
interface-number
Required
Enable MLD mld enable
Disabled by default
For details about the multicast ipv6 routing-table command, see IPv6 Multicast Routing and
Forwarding Commands in the IP Multicast Volume.
Configuring the MLD Version
Because MLD message types and formats vary with MLD versions, the same MLD version should be
configured for all routers on the same subnet before MLD can work properly.
Configuring an MLD version globally
Follow these steps to configure an MLD version globally:

Enter MLD view mld
Configure an MLD version Optional

version version-number
globally MLDv1 by default
1-10
Configuring an MLD version on an interface
Follow these steps to configure an MLD version on an interface:

interface-number
Configure an MLD version on Optional

mld version version-number
the interface MLDv1 by default
Configuring Static Joining
After an interface is configured as a static member of an IPv6 multicast group or an IPv6 multicast
source and group, it will act as a virtual member of the IPv6 multicast group to receive IPv6 multicast
data addressed to that IPv6 multicast group for the purpose of testing IPv6 multicast data forwarding.
Follow these steps to configure a static member of an IPv6 multicast group or an IPv6 multicast source
and group:

interface-number
Required
Configure a static member of
mld static-group By default, an interface is not a
an IPv6 multicast group or an
ipv6-group-address [ source static member of any IPv6
IPv6 multicast source and
ipv6-source-address ] multicast group or IPv6
group
multicast source and group.
Before you can configure an interface of an IPv6 PIM-SM device as a static member of an IPv6
multicast group or an IPv6 multicast source and group, if the interface is IPv6 PIM-SM enabled, it must
be an IPv6 PIM-SM DR; if this interface is MLD enabled but not IPv6 PIM-SM enabled, it must be an
MLD querier. For more information about IPv6 PIM-SM and a DR, refer to IPv6 PIM Configuration in the
IP Multicast Volume.
As a static member of an IPv6 multicast group or an IPv6 multicast source and group, an interface does
not respond to the queries from the MLD querier, nor does it send an unsolicited MLD membership
report or a MLD done message when it joins or leaves an IPv6 multicast group or an IPv6 source and
group. In other words, the interface will not become a real member of the IPv6 multicast group or the
IPv6 multicast and source group.
1-11
Configuring an IPv6 Multicast Group Filter
To restrict the hosts on the network attached to an interface from joining certain IPv6 multicast groups,
you can set an IPv6 ACL rule on the interface as a packet filter to limit the range of multicast groups that
the interface serves.
Follow these steps to configure an IPv6 multicast group filter:

interface-number
Required
Configure an IPv6 multicast mld group-policy acl6-number
group filter [ version-number ] By default, no IPv6 multicast
filter is configured.
Adjusting MLD Performance
For the configuration tasks described in this section,

Configurations performed in MLD view are globally effective, while configurations performed in
interface view are effective on the current interface only.
If the same function or parameter is configured in both PIM view and interface view, the configuration
performed in interface view is given priority, regardless of the configuration sequence.
Before adjusting MLD performance, complete the following tasks:

z Configure basic functions of MLD.
In addition, prepare the following data:
z Startup query interval
z Startup query count
z MLD query interval
z MLD querier robustness variable
z Maximum response delay of MLD general query messages
z MLD last listener query interval
z MLD other querier present interval
Configuring MLD Message Options
MLD queries include multicast-address-specific queries and multicast-address-and-source-specific

queries, and IPv6 multicast groups change dynamically, so a device cannot maintain the information for
all IPv6 multicast sources and groups. Therefore, a router may receive IPv6 multicast packets
1-12
addressed to IPv6 multicast groups that have no members on the local subnet. In this case, the
Router-Alert option carried in the IPv6 multicast packets is useful for the router to make a decision. For
details about the Router-Alert option, refer to RFC 2113.
An MLD message is processed differently depending whether it carries the Router-Alert option in the
IPv6 header:
z By default, in consideration of compatibility, the device does not check the Router-Alert option, that
is, it processes all received MLD messages. In this case, the device passes MLD messages to the
upper layer protocol for processing, no matter whether the MLD messages carry the Router-Alert
option or not.
z To enhance the device performance, avoid unnecessary costs, and ensure the protocol security,
you can configure the device to discard MLD messages without the Router-Alert option.
Configuring the Router-Alert option for MLD messages globally
Follow these steps to configure the Router-Alert option for MLD messages globally:

Enter MLD view mld
Optional
discard any MLD message require-router-alert By default, the device does not
without the Router-Alert option check MLD messages for the
Enable the insertion of the Optional

Router-Alert option into MLD send-router-alert By default, MLD messages
Configuring the Router-Alert option on an interface
Follow these steps to configure the Router-Alert option on an interface:

interface-number
Optional
discard any MLD message mld require-router-alert By default, the device does not
without the Router-Alert option check MLD messages for the
Enable the insertion of the Optional

Router-Alert option into MLD mld send-router-alert By default, MLD messages
Configuring MLD Query and Response Parameters
On startup, the MLD querier sends startup query count MLD general queries at the startup query
interval, which is 1/4 of the MLD query interval.
1-13
The MLD querier periodically sends MLD general queries at the MLD query interval to determine
whether any IPv6 multicast group member exists on the network. You can modify the query interval
based on the actual condition of the network.
Upon receiving an MLD done message, the MLD querier sends last listener query count MLD
multicast-address-specific queries at the MLD last listener query interval. MLD is robust to
robustness variable minus 1 packet losses on a network. Therefore, a greater value of the robustness
variable makes the MLD querier more robust, but results in a longer IPv6 multicast group timeout
time.
Upon receiving an MLD query (general query or multicast-address-specific query) message, a host
starts a timer for each IPv6 multicast group it has joined. The timer is initialized to a random value in the
range of 0 to the maximum response delay (the host obtains the maximum response delay from the
Maximum Response Delay field in the MLD query message it received). When the timer value drops to
0, the host sends an MLD membership report message to the corresponding IPv6 multicast group.
Proper setting of the maximum response delay of MLD query messages not only allows hosts to
respond to MLD query messages quickly, but also avoids bursts of MLD traffic on the network caused
by reports simultaneously sent by a large number of hosts when corresponding timers expire
simultaneously.
z For MLD general queries, you can configure the maximum response delay to fill their Maximum
Response Delay field.
z For MLD multicast-address-specific query messages, you can configure the last listener query
interval to fill their Maximum Response Delay field. That is to say, the maximum response time of
MLD general query messages equals the last listener query interval.
When multiple multicast routers exist on the same subnet, the MLD querier is responsible for sending
MLD query messages. If a non-querier router receives no MLD query from the querier within the other
querier present interval, it will assume that the querier has failed and a new querier election process is
launched. Otherwise, the non-querier will reset other querier present timer.
Configuring MLD query and response parameters globally
Follow these steps to configure MLD query and response parameters globally:

Enter MLD view mld
Optional
startup-query-interval interval For the system default, see
interval
Note below.
Optional
startup-query-count value For the system default, see
count
Note below.
Configure the MLD query Optional

timer query interval
interval 125 seconds by default.
Configure the MLD querier Optional

robust-count robust-value
robustness variable 2 times by default
response delay for MLD max-response-time interval
general query messages 10 seconds by default
1-14
Configure the MLD last listener last-listener-query-interval Optional

query interval interval 1 second by default
Optional
Configure the MLD other timer other-querier-present
querier present interval interval For the system default, see
Note below.
Configuring MLD query and response parameters on an interface
Follow these steps to configure MLD query and response parameters on an interface:

interface-number
Optional
Configure the startup query mld startup-query-interval
interval interval For the system default, see
Note below.
Optional
Configure the startup query mld startup-query-count
count value For the system default, see
Note below.
Configure the MLD query Optional

mld timer query interval
interval 125 seconds by default.
Configure the MLD querier mld robust-count Optional

robustness variable robust-value 2 times by default
mld max-response-time
response delay for MLD
general query messages
mld Optional
Configure the MLD last listener
last-listener-query-interval
query interval 1 second by default
interval
Optional
Configure the MLD other mld timer
querier present interval other-querier-present interval For the system default, see
Note below.
1-15
z If not statically configured, the startup query interval is 1/4 of the MLD query interval. By default,
the MLD query interval is 125 seconds, so the startup query interval = 125 / 4 = 31.25 (seconds).
z If not statically configured, the startup query count is set to the MLD querier robustness variable.
By default, the MLD querier robustness variable is 2, so the startup query count is also 2.
z If not statically configured, the other querier present interval is determined by the formula: Other
querier present interval (in seconds) = [ MLD query interval ] times [ MLD querier robustness
variable ] plus [ maximum response delay for MLD general query ] divided by two. The default
values of these three parameters are 125, 2, and 10 respectively, so the other querier present
interval = 125 x 2 + 10 / 2 = 255 (seconds).
z If statically configured, the startup query interval, the startup query count, and the other querier
present interval take the configured values.
Make sure that the other querier present interval is greater than the MLD query interval; otherwise the
MLD querier may frequently change.
Make sure that the MLD query interval is greater than the maximum response delay for MLD general
queries; otherwise, multicast group members may be wrongly removed.
Configuring MLD Fast Leave Processing
In some applications, such as ADSL dial-up networking, only one multicast receiver host is attached to
a port of the MLD querier. To allow fast response to the MLD done messages of the host when it
switches frequently from one IPv6 multicast group to another, you can enable MLD fast leave
processing on the MLD querier.
With fast leave processing enabled, after receiving an MLD done message from a host, the MLD
querier sends a leave notification to the upstream immediately without first sending MLD
multicast-address-specific queries. In this way, the leave latency is reduced on one hand, and the
network bandwidth is saved on the other hand.
Configuring MLD fast leave processing globally
Follow these steps to configure MLD fast leave processing globally:

Enter MLD view mld
Configure MLD fast leave fast-leave [ group-policy Required

processing acl6-number ] Disabled by default.
1-16
Configuring MLD fast leave processing on an interface
Follow these steps to configure MLD fast leave processing on an interface:

interface-number
Configure MLD fast leave mld fast-leave [ group-policy Required

processing acl6-number ] Disabled by default.
Configuring MLD SSM Mapping

Due to some possible restrictions, some receiver hosts on an SSM network may run MLDv1. To provide
SSM service support for these receiver hosts, you need to configure the MLD SSM mapping feature on
the last hop router.
Before configuring the MLD SSM mapping feature, complete the following tasks:
z Configure MLD basic functions
Enabling MLD SSM Mapping
Follow these steps to enable the MLD SSM mapping feature:

interface-number
Enable the MLD SSM mapping Required

mld ssm-mapping enable
feature Disabled by default
To ensure SSM service for all hosts on a subnet, regardless of the MLD version running on the hosts,
enable MLDv2 on the interface that forwards IPv6 multicast traffic onto the subnet.
Configuring MLD SSM Mappings
By performing this configuration multiple times, you can map an IPv6 multicast group to different IPv6
multicast sources.
Follow these steps to configure an MLD SSM mapping:
1-17
Enter MLD view mld
Required
Configure an MLD SSM ssm-mapping ipv6-group-address
mapping prefix-length ipv6-source-address No MLD mappings are
If MLDv2 is enabled on a VLAN interface of a switch that supports both MLD Snooping and MLD, and if
a port in that VLAN is configured as a simulated host, the simulated host will send MLDv2 reports even
if you did not specify an IPv6 multicast source when configuring simulated joining with the
mld-snooping host-join command. In this case, the corresponding IPv6 multicast group will not be
created based on the configured MLD SSM mappings. For details about the mld-snooping host-join
command, refer to MLD Snooping Commands in the IP Multicast Volume.
Displaying and Maintaining MLD Configuration

display mld group

View MLD multicast group [ ipv6-group-address | interface Available in any
information interface-type interface-number ] view
[ static | verbose ]
On a
display mld group port-info [ vlan Available in any
View Layer 2 port centralized
vlan-id ] [ verbose ] view
information about device
MLD multicast On a display mld group port-info [ vlan
groups Available in any
distributed vlan-id ] [ slot slot-number ]
view
device [ verbose ]
View MLD configuration and running display mld interface
Available in any
information on the specified interface [ interface-type interface-number ]
view
or all MLD-enabled interfaces [ verbose ]
display mld routing-table

View the information of the MLD [ ipv6-source-address [ prefix-length ] Available in any
routing table | ipv6-group-address [ prefix-length ] ] view
*
display mld ssm-mapping Available in any
View MLD SSM mappings
ipv6-group-address view
display mld ssm-mapping group

View the IPv6 multicast group
[ ipv6-group-address | interface Available in any
information created based on the
interface-type interface-number ] view
configured MLD SSM mappings
[ verbose ]
reset mld group { all | interface
interface-type interface-number { all |
Clear MLD multicast group Available in user
ipv6-group-address [ prefix-length ]
information view
[ ipv6-source-address
[ prefix-length ] ] } }
1-18
Clear Layer 2 port information about reset mld group port-info { all | Available in user
MLD multicast groups ipv6-group-address } [ vlan vlan-id ] view
reset mld ssm-mapping group { all |
interface-number { all | Available in user
Clear MLD SSM mappings
ipv6-group-address [ prefix-length ] view
[ ipv6-source-address
[ prefix-length ] ] } }
You cannot use the reset mld group command to clear the MLD multicast group information of static
joins.
The reset mld group port-info command cannot clear Layer 2 port information about MLD multicast
groups of static joins.
The support for the display mld group port-info and reset mld group port-info commands varies
with devices.
The reset mld group command cause an interruption of receivers reception of multicast data.
MLD Configuration Examples (On Routers)

Basic MLD Functions Configuration Example
z Receivers receive VOD information in the multicast mode. Receivers of different organizations
form stub networks N1 and N2, and Host A and Host C are multicast receivers in N1 and N2
respectively.
z Router A in the IPv6 PIM network connects to N1, and Router B and Router C connect to N2.
z Router A connects to N1 through Ethernet 1/0, and to other devices in the IPv6 PIM network
through POS 5/0.
z Router B and Router C connect to N2 through their respective Ethernet 1/0, and to other devices in
the IPv6 PIM network through their respective POS 5/0.
z MLDv1 is required between Router A and N1. MLDv1 is also required between the other two
routers (Router B and Router C) and N2, with Router B as the MLD querier.
1-19
Network diagram
Figure 1-6 Network diagram for basic MLD functions configuration (on routers)
Ethernet
Ethernet
1) Enable IPv6 forwarding and configure IPv6 addresses and IPv6 unicast routing
Enable IPv6 forwarding on each router and configure an IPv6 address and prefix length for each
interface as shown in Figure 1-6. The detailed configuration steps are omitted here.
Configure OSPFv3 for interoperation between the routers on the IPv6 PIM network. Ensure the
network-layer interoperation on the IPv6 PIM network and dynamic update of routing information
between the routers through a unicast routing protocol. The detailed configuration steps are omitted
here.
2) Enable the IPv6 multicast routing, and enable IPv6 PIM-DM and MLD
# Enable IPv6 multicast routing on Router A, enable IPv6 PIM-DM on each interface, and enable MLD
on the host-side interface Ethernet 1/0.
[RouterA-Pos5/0] pim ipv6 dm
# Enable IPv6 multicast routing on Router B, enable IPv6 PIM-DM on each interface, and enable MLD
[RouterB] multicast ipv6 routing-enable
1-20
[RouterB-Ethernet1/0] mld enable
[RouterB-Ethernet1/0] pim ipv6 dm
[RouterB-Pos5/0] pim ipv6 dm
# Enable IPv6 multicast routing on Router C, enable IPv6 PIM-DM on each interface, and enable MLD
[RouterC] multicast ipv6 routing-enable
[RouterC-Ethernet1/0] mld enable
[RouterC-Ethernet1/0] pim ipv6 dm
[RouterC-Pos5/0] pim ipv6 dm
Carry out the display mld interface command to display the MLD configuration and running
information on each router interface. Example:
# Display MLD information on Ethernet 1/0 of Router B.
[RouterB] display mld interface ethernet 1/0
Ethernet1/0(FE80::200:5EFF:FE66:5100):
MLD is enabled
Current MLD version is 1
Value of query interval for MLD(in seconds): 125
Value of other querier present interval for MLD(in seconds): 255
Value of maximum query response time for MLD(in seconds): 10
Querier for MLD: FE80::200:5EFF:FE66:5100 (this router)
Total 1 MLD Group reported
MLD SSM Mapping Configuration Example
z On the IPv6 PIM-SSM network shown in Figure 1-7, the receiver host receives VOD information
through multicast. The receiver host runs MLDv1, so it cannot specify the expected IPv6 multicast
sources in its reports.
z It is required to configure the MLD SSM mapping feature on Router D so that the receiver host will
receive IPv6 multicast data from Source 1 and Source 3 only.
1-21
Network diagram
Figure 1-7 Network diagram for MLD SSM mapping configuration (on routers)

Source 1 1001::1/64 Source 3 3001::1/64
Source 2 2001::1/64 Receiver 4001::1/64
Router A Eth1/0 1001::2/64 Router C Eth1/0 3001::2/64
Eth1/1 1002::1/64 Eth1/1 3002::1/64
Eth1/2 1003::1/64 Eth1/2 2002::2/64
Router B Eth1/0 2001::2/64 Router D Eth1/0 4001::2/64
Eth1/1 1002::2/64 Eth1/1 3002::2/64
Eth1/2 2002::1/64 Eth1/2 1003::2/64
Enable IPv6 forwarding on each router and configure an IPv6 address and prefix length for each
interface as shown in Figure 1-7. The detailed configuration steps are not discussed in this document.
Configure OSPF for interoperability among the routers. Ensure the network-layer interoperation among
the routers on the IPv6 PIM-SSM network and dynamic update of routing information among the
routers through a unicast routing protocol. The detailed configuration steps are omitted here.
2) Enable IPv6 multicast routing, enable IPv6 PIM-SM on each interface and enable MLD and MLD
SSM mapping on the host-side interface.
# Enable IPv6 multicast routing on Router D, enable IPv6 PIM-SM on each interface and enable MLD
(version 2) and MLD SSM mapping on Ethernet 1/0.
[RouterD] multicast ipv6 routing-enable
[RouterD-Ethernet1/0] mld enable
[RouterD-Ethernet1/0] mld version 2
[RouterD-Ethernet1/0] mld ssm-mapping enable
[RouterD-Ethernet1/0] pim ipv6 sm
1-22
# Enable IPv6 multicast routing on Router A, and enable IPv6 PIM-SM on each interface.
[RouterA-Ethernet1/0] pim ipv6 sm

# Configure C-BSR and C-RP interfaces on Router D.
[RouterD] pim ipv6
[RouterD-pim6] c-bsr 1003::2
[RouterD-pim6] c-rp 1003::2
[RouterD-pim6] quit
4) Configure the IPv6 SSM group range
# Configure the IPv6 SSM group range FF3E::/64 on Router D.
[RouterD] acl ipv6 number 2000
[RouterD-acl6-basic-2000] rule permit source ff3e:: 64
[RouterD-acl6-basic-2000] quit
[RouterD] pim ipv6
[RouterD-pim6] ssm-policy 2000
[RouterD-pim6] quit
The configuration on Router A, Router B and Router C is similar to that on Router D.

5) Configure MLD SSM mappings
# Configure MLD SSM mappings on Router D.
[RouterD] mld
[RouterD-mld] ssm-mapping ff3e::101 64 1001::1
[RouterD-mld] ssm-mapping ff3e::101 64 3001::1
[RouterD-mld] quit
Use the display mld ssm-mapping command to view MLD SSM mappings on the router.
# View the MLD SSM mapping information for IPv6 multicast group FF3E::101 on Router D.
[RouterD] display mld ssm-mapping ff3e::101
Group: FF3E::101
Source list:
1001::1
3001::1
1-23
Use the display mld ssm-mapping group command to view the IPv6 multicast group information
created based on the configured MLD SSM mappings.
# View the IPv6 multicast group information created based on the configured MLD SSM mappings on
Router D.
[RouterD] display mld ssm-mapping group
Total 1 MLD SSM-mapping Group(s).
Interface group report information
Ethernet1/0(4001::2):
Total 1 MLD SSM-mapping Group reported
Group Address: FF3E::101
Last Reporter: 4001::1
Uptime: 00:02:04
Expires: off
Use the display pim ipv6 routing-table command to view the IPv6 PIM routing table information on
each router.
# View the IPv6 PIM routing table information on Router D.
[RouterD] display pim ipv6 routing-table
(1001::1, FF3E::101)
UpTime: 00:13:25
Upstream neighbor: 1003::1
RPF prime neighbor: 1003::1
1: Ethernet1/0
Protocol: mld, UpTime: 00:13:25, Expires: -
(3001::1, FF3E::101)
UpTime: 00:13:25
1: Ethernet1/0
1-24
MLD Configuration Examples (On Switches)
Basic MLD Functions Configuration Example
z Receivers receive VOD information in the multicast mode. Receivers of different organizations
form stub networks N1 and N2, and Host A and Host C are multicast receivers in N1 and N2
respectively.
z Switch A in the IPv6 PIM network connects to N1, and Switch B and Switch C connect to N2.
z Switch A connects to N1 through VLAN-interface 100, and to other devices in the IPv6 PIM
network through VLAN-interface 101.
z Switch B and Switch C connects to N2 through their own VLAN-interface 200, and to other devices
in the IPv6 PIM network through VLAN-interface 201 and VLAN-interface 202 respectively.
z MLDv1 is required between Switch A and N1. MLDv1 is also required between the other two
switches (Switch B and Switch C) and N2, with Switch B as the MLD querier.
Network diagram
Figure 1-8 Network diagram for basic MLD functions configuration (on switches)
Ethernet
Ethernet
Enable IPv6 forwarding on each switch and configure an IP address and prefix length for each interface
as shown in Figure 1-8. The detailed configuration steps are not discussed in this document.
Configure OSPFv3 for interoperation between the switches. Ensure the network-layer interoperation
among the switches on the IPv6 PIM network and dynamic update of routing information between the
switches through a unicast routing protocol. The detailed configuration steps are omitted here.
2) Enable the IPv6 multicast routing, and enable IPv6 PIM-DM and MLD.
# Enable IPv6 multicast routing on Switch A, enable IPv6 PIM-DM on each interface, and enable MLD
on VLAN-interface 100.
1-25
[SwitchA] multicast ipv6 routing-enable
[SwitchA-Vlan-interface100] mld enable
[SwitchA-Vlan-interface100] pim ipv6 dm
# Enable IPv6 multicast routing on Switch B, enable IPv6 PIM-DM on each interface, and enable MLD
[SwitchB] multicast ipv6 routing-enable
[SwitchB-Vlan-interface200] mld enable
[SwitchB-Vlan-interface200] pim ipv6 dm
[SwitchB-Vlan-interface201] pim ipv6 dm
# Enable IPv6 multicast routing on Switch C, enable IPv6 PIM-DM on each interface, and enable MLD
[SwitchC] multicast ipv6 routing-enable
[SwitchC-Vlan-interface200] mld enable
[SwitchC-Vlan-interface200] pim ipv6 dm
[SwitchC-Vlan-interface202] pim ipv6 dm
Carry out the display mld interface command to display the MLD configuration and running
information on each switch interface. Example:
# Display MLD information on VLAN-interface 200 of Switch B.
[SwitchB] display mld interface vlan-interface 200
Vlan-interface200(FE80::200:5EFF:FE66:5100):
MLD is enabled
Current MLD version is 1
Value of query interval for MLD(in seconds): 125
Value of other querier present interval for MLD(in seconds): 255
Value of maximum query response time for MLD(in seconds): 10
Querier for MLD: FE80::200:5EFF:FE66:5100 (this router)
Total 1 MLD Group reported
1-26
MLD SSM Mapping Configuration Example
z On the IPv6 PIM-SSM network shown in Figure 1-9, the receiver host receives VOD information
through multicast. The receiver runs MLDv1, so it cannot specify the expected IPv6 multicast
sources in its reports.
z It is required that MLD SSM mapping be configured on Switch D so that the receiver host will
receive IPv6 multicast data from Source 1 and Source 3 only.
Network diagram
Figure 1-9 Network diagram for MLD SSM mapping configuration (on switches)

Source 1 1001::1/64 Source 3 3001::1/64
Source 2 2001::1/64 Receiver 4001::1/64
Switch A Vlan-int100 1001::2/64 Switch C Vlan-int300 3001::2/64
Vlan-int101 1002::1/64 Vlan-int103 3002::1/64
Vlan-int104 1003::1/64 Vlan-int102 2002::2/64
Switch B Vlan-int200 2001::2/64 Switch D Vlan-int400 4001::2/64
Vlan-int101 1002::2/64 Vlan-int103 3002::2/64
Vlan-int102 2002::1/64 Vlan-int104 1003::2/64
Enable IPv6 forwarding on each switch and configure an IPv6 address and prefix length for each
interface as shown in Figure 1-9. The detailed configuration steps are omitted.
Configure OSPFv3 for interoperability among the switches. Ensure the network-layer interoperation on
the IPv6 PIM-SSM network and dynamic update of routing information among the switches through a
unicast routing protocol. The detailed configuration steps are omitted here.
2) Enable IPv6 multicast routing, enable IPv6 PIM-SM on each interface and enable MLD and MLD
SSM mapping on the host-side interface.
# Enable IPv6 multicast routing on Switch D, enable IPv6 PIM-SM on each interface, and enable MLD
(version 2) and MLD SSM mapping on VLAN-interface 400.
[SwitchD] multicast ipv6 routing-enable
1-27
[SwitchD-Vlan-interface400] mld enable
[SwitchD-Vlan-interface400] mld version 2
[SwitchD-Vlan-interface400] mld ssm-mapping enable
[SwitchD-Vlan-interface400] pim ipv6 sm
# Enable IPv6 multicast routing on Switch A, and enable IPv6 PIM-SM on each interface.
[SwitchA-Vlan-interface100] pim ipv6 sm

# Configure C-BSR and C-RP interfaces on Switch D.
[SwitchD] pim ipv6
[SwitchD-pim6] c-bsr 1003::2
[SwitchD-pim6] c-rp 1003::2
[SwitchD-pim6] quit
# Configure the IPv6 SSM group range FF3E::/64 on Switch D.
[SwitchD] acl ipv6 number 2000
[SwitchD-acl6-basic-2000] rule permit source ff3e:: 64
[SwitchD-acl6-basic-2000] quit
[SwitchD] pim ipv6
[SwitchD-pim6] ssm-policy 2000
[SwitchD-pim6] quit
The configuration on Switch A, Switch B and Switch C is similar to that on Switch D.

5) Configure MLD SSM mappings
# Configure MLD SSM mappings on Switch D.
[SwitchD] mld
[SwitchD-mld] ssm-mapping ff3e::101 64 1001::1
[SwitchD-mld] ssm-mapping ff3e::101 64 3001::1
[SwitchD-mld] quit
1-28
Use the display mld ssm-mapping command to view MLD SSM mappings on the switch.
# View the MLD SSM mapping information for IPv6 multicast group FF3E::101 on Switch D.
[SwitchD] display mld ssm-mapping ff3e::101
Group: FF3E::101
Source list:
1001::1
3001::1
Use the display mld ssm-mapping group command to view information of the MLD multicast groups
created based on the configured MLD SSM mappings.
# View the IPv6 multicast group information created based on the configured MLD SSM mappings on
Switch D.
[SwitchD] display mld ssm-mapping group
Total 1 MLD SSM-mapping Group(s).
Interface group report information
Vlan-interface400 (4001::2):
Total 1 MLD SSM-mapping Group reported
Group Address: FF3E::101
Last Reporter: 4001::1
Uptime: 00:02:04
Expires: off
Use the display pim ipv6 routing-table command to view the IPv6 PIM routing table information on
each switch.
# View the IPv6 PIM routing table information on Switch D.
[SwitchD] display pim ipv6 routing-table
(1001::1, FF3E::101)
UpTime: 00:13:25
(3001::1, FF3E::101)
UpTime: 00:13:25
1-29
Troubleshooting MLD
No Member Information on the Receiver-Side Router
Symptom
When a host sends a message for joining IPv6 multicast group G, there is no member information of
multicast group G on the immediate router.
Analysis
z The correctness of networking and interface connections directly affects the generation of IPv6
group member information.
z IPv6 multicast routing must be enabled on the router.
z If the mld group-policy command has been configured on an interface, the interface cannot
receive report messages that fail to pass filtering.
Solution
1) Check that the networking is correct and that interface connections are correct.
2) Check that the IPv6 multicast routing is enabled. Carry out the display current-configuration
command to check whether the multicast ipv6 routing-enable command has been executed. If
not, carry out the multicast ipv6 routing-enable command in system view to enable IPv6
multicast routing. In addition, enable MLD on the corresponding interface.
3) Check that the interface is normal and that a correct IPv6 address has been configured. Carry out
the display mld interface command to display the interface information. If no interface
information is output, the interface is abnormal. Typically this is because the shutdown command
has been executed on the interface, or the interface connection is incorrect, or no correct IPv6
address has been configured on the interface.
4) Check that no ACL rule has been configured to restrict the host from joining IPv6 multicast group G.
Carry out the display current-configuration interface command to check whether the mld
group-policy command has been executed. If an IPv6 ACL is configured to restrict the host from
joining IPv6 multicast group G, the ACL must be modified to allow IPv6 multicast group G to
receive report messages.
Inconsistent Memberships on Routers on the Same Subnet
Symptom
Different memberships are maintained on different MLD routers on the same subnet.
Analysis
z A router running MLD maintains multiple parameters for each interface, and these parameters
influence one another, forming very complicated relationships. Inconsistent MLD interface
parameter configurations for routers on the same subnet will surely result in inconsistent MLD
memberships.
z Two MLD versions are currently available. Although routers running different MLD versions are
compatible with hosts, all routers on the same subnet must run the same MLD version.
1-30
Inconsistent MLD versions running on routers on the same subnet will also lead to inconsistent
MLD memberships.
Solution
1) Check MLD configurations. Carry out the display current-configuration command to display the
MLD configuration information on the interface.
2) Carry out the display mld interface command on all routers on the same subnet to check the
MLD timers for consistent configurations.
3) Use the display mld interface command to check that the routers are running the same MLD
version.
1-31
Table of Contents
1 IPv6 PIM Configuration 1-1

IPv6 PIM Overview1-1
Introduction to IPv6 PIM-DM 1-2
How IPv6 PIM-DM Works1-2
Introduction to IPv6 PIM-SM 1-5
How IPv6 PIM-SM Works 1-6
SSM Model Implementation in IPv6 PIM1-11
Configuring IPv6 PIM-DM 1-13
IPv6 PIM-DM Configuration Task List 1-13
Enabling IPv6 PIM-DM 1-13
Enabling State-Refresh Capability 1-14
Configuring State Refresh Parameters 1-14
Configuring IPv6 PIM-DM Graft Retry Period1-15
Configuring IPv6 PIM-SM 1-16
IPv6 PIM-SM Configuration Task List 1-16
Enabling IPv6 PIM-SM 1-17
Configuring an RP 1-17
Configuring a BSR1-20
Configuring IPv6 Multicast Source Registration1-23
Configuring RPT-to-SPT Switchover1-24
Configuring IPv6 PIM-SSM 1-24
IPv6 PIM-SSM Configuration Task List 1-24
Enabling IPv6 PIM-SM 1-25
Configuring the IPv6 SSM Group Range 1-26
Configuring IPv6 PIM Common Features 1-26
IPv6 PIM Common Feature Configuration Task List1-26
Configuring an IPv6 Multicast Data Filter 1-27
Configuring IPv6 PIM Hello Options1-28
Configuring IPv6 PIM Common Timers1-29
Configuring Join/Prune Message Sizes 1-31
Displaying and Maintaining IPv6 PIM 1-31
IPv6 PIM Configuration Examples (On Routers) 1-32
IPv6 PIM-DM Configuration Example1-32
IPv6 PIM-SM Configuration Example1-36
IPv6 PIM-SSM Configuration Example 1-40
IPv6 PIM Configuration Examples (On Switches) 1-43
IPv6 PIM-DM Configuration Example1-43
IPv6 PIM-SM Configuration Example1-47
i
IPv6 PIM-SSM Configuration Example 1-51
Troubleshooting IPv6 PIM Configuration 1-54
Failure of Building a Multicast Distribution Tree Correctly 1-54
IPv6 Multicast Data Abnormally Terminated on an Intermediate Router 1-55
RPs Unable to Join SPT in IPv6 PIM-SM1-56
RPT Establishment Failure or Source Registration Failure in IPv6 PIM-SM 1-56
ii

Yes Yes Yes Yes
(Include/Exclude)
1 IPv6 PIM Configuration
When configuring IPv6 PIM, go to these sections for information you are interested in:
z IPv6 PIM Overview
z Configuring IPv6 PIM-DM
z Configuring IPv6 PIM-SM
z Configuring IPv6 PIM-SSM
z Configuring IPv6 PIM Common Features
z Displaying and Maintaining IPv6 PIM
z IPv6 PIM Configuration Examples (On Routers)
z IPv6 PIM Configuration Examples (On Switches)
z Troubleshooting IPv6 PIM Configuration
The term router in this document refers to a router in a generic sense or a Layer 3 switch running IPv6
PIM.
IPv6 PIM Overview

Protocol Independent Multicast for IPv6 (IPv6 PIM) provides IPv6 multicast forwarding by leveraging
static routes or IPv6 unicast routing tables generated by any IPv6 unicast routing protocol, such as
RIPng, OSPFv3, IS-ISv6, or BGP4+. IPv6 PIM uses an IPv6 unicast routing table to perform reverse
path forwarding (RPF) check to implement IPv6 multicast forwarding. Independent of the IPv6 unicast
routing protocols running on the device, IPv6 multicast routing can be implemented as long as the
corresponding IPv6 multicast routing entries are created through IPv6 unicast routes. IPv6 PIM uses
1-1
the reverse path forwarding (RPF) mechanism to implement IPv6 multicast forwarding. When an IPv6
multicast packet arrives on an interface of the device, it is subject to an RPF check. If the RPF check
succeeds, the device creates the corresponding routing entry and forwards the packet; if the RPF check
fails, the device discards the packet. For more information about RPF, refer to IPv6 Multicast Routing
and Forwarding Configuration in the IP Multicast Volume.
Based on the implementation mechanism, IPv6 PIM falls into two modes:
z Protocol Independent MulticastDense Mode for IPv6 (IPv6 PIM-DM), and
z Protocol Independent MulticastSparse Mode for IPv6 (IPv6 PIM-SM).
To facilitate description, a network comprising IPv6 PIMsupporting routers is referred to as an IPv6

PIM domain in this document.
Introduction to IPv6 PIM-DM
IPv6 PIM-DM is a type of dense mode IPv6 multicast protocol. It uses the push mode for IPv6
multicast forwarding, and is suitable for small-sized networks with densely distributed IPv6 multicast
members.
The basic implementation of IPv6 PIM-DM is as follows:
z IPv6 PIM-DM assumes that at least one IPv6 multicast group member exists on each subnet of a
network, and therefore IPv6 multicast data is flooded to all nodes on the network. Then, branches
without IPv6 multicast forwarding are pruned from the forwarding tree, leaving only those branches
that contain receivers. This flood and prune process takes place periodically, that is, pruned
branches resume IPv6 multicast forwarding when the pruned state times out and then data is
re-flooded down these branches, and then are pruned again.
z When a new receiver on a previously pruned branch joins an IPv6 multicast group, to reduce the
join latency, IPv6 PIM-DM uses the graft mechanism to resume IPv6 multicast data forwarding to
that branch.
Generally speaking, the IPv6 multicast forwarding path is a source tree, namely a forwarding tree with
the IPv6 multicast source as its root and IPv6 multicast group members as its leaves. Because the
source tree is the shortest path from the IPv6 multicast source to the receivers, it is also called shortest
path tree (SPT).
How IPv6 PIM-DM Works
The working mechanism of IPv6 PIM-DM is summarized as follows:

z SPT establishment
z Graft
z Assert
1-2
Neighbor discovery
In an IPv6 PIM domain, a PIM router discovers IPv6 PIM neighbors, maintains IPv6 PIM neighboring
relationships with other routers, and builds and maintains SPTs by periodically multicasting IPv6 PIM
hello messages (hereinafter referred to as hello messages) to all other IPv6 PIM routers.
Every IPv6 PIM enabled interface on a router sends hello messages periodically, and thus learns the
IPv6 PIM neighboring information pertinent to the interface.
SPT establishment
The process of constructing an SPT is the flood and prune process.

1) In an IPv6 PIM-DM domain, an IPv6 multicast source first floods IPv6 multicast packets when it
sends IPv6 multicast data to IPv6 multicast group G: The packet is subject to an RPF check. If the
packet passes the RPF check, the router creates an (S, G) entry and forwards the packet to all
downstream nodes in the network. In the flooding process, an (S, G) entry is created on all the
routers in the IPv6 PIM-DM domain.
2) Then, nodes without downstream receivers are pruned: A router having no down stream receivers
sends a prune message to the upstream node to notify the upstream node to delete the
corresponding interface from the outgoing interface list in the (S, G) entry and stop forwarding
subsequent packets addressed to that IPv6 multicast group down to this node.
z An (S, G) entry contains the multicast source address S, IPv6 multicast group address G, outgoing
interface list, and incoming interface.
z For a given IPv6 multicast stream, the interface that receives the IPv6 multicast stream is referred
to as upstream, and the interfaces that forward the IPv6 multicast stream are referred to as
downstream.
A prune process is first initiated by a leaf router. As shown in Figure 1-1, a router without any receiver
attached to it (the router connected with Host A, for example) sends a prune message, and this prune
process goes on until only necessary branches are left in the IPv6 PIM-DM domain. These branches
constitute the SPT.
1-3
Figure 1-1 SPT establishment in an IPv6 PIM-DM domain
The flood and prune process takes place periodically. A pruned state timeout mechanism is provided.
A pruned branch restarts multicast forwarding when the pruned state times out and then is pruned again
when it no longer has any multicast receiver.
Pruning has a similar implementation in IPv6 PIM-SM.
Graft
When a host attached to a pruned node joins an IPv6 multicast group, to reduce the join latency, IPv6
PIM-DM uses the graft mechanism to resume IPv6 multicast data forwarding to that branch. The
1) The node that needs to receive IPv6 multicast data sends a graft message toward its upstream
node, as a request to join the SPT again.
2) Upon receiving this graft message, the upstream node puts the interface on which the graft was
received into the forwarding state and responds with a graft-ack message to the graft sender.
3) If the node that sent a graft message does not receive a graft-ack message from its upstream node,
it will keep sending graft messages at a configurable interval until it receives an acknowledgment
from its upstream node.
Assert
The assert mechanism is used to shutoff duplicate IPv6 multicast flows onto the same multi-access
network, where more than one multicast routers exists, by electing a unique IPv6 multicast forwarder on
the multi-access network.
1-4
Figure 1-2 Assert mechanism
As shown in Figure 1-2, after Router A and Router B receive an (S, G) IPv6 multicast packet from the
upstream node, they both forward the packet to the local subnet. As a result, the downstream node
Router C receives two identical multicast packets, and both Router A and Router B, on their own local
interface, receive a duplicate IPv6 multicast packet forwarded by the other. Upon detecting this
condition, both routers send an assert message to all IPv6 PIM routers through the interface on which
the packet was received. The assert message contains the following information: the multicast source
address (S), the multicast group address (G), and the preference and metric of the IPv6 unicast route to
the source. By comparing these parameters, either Router A or Router B becomes the unique forwarder
of the subsequent (S, G) IPv6 multicast packets on the multi-access subnet. The comparison process is
as follows:
1) The router with a higher IPv6 unicast route preference to the source wins;
2) If both routers have the same IPv6 unicast route preference to the source, the router with a smaller
metric to the source wins;
3) If there is a tie in the route metric to the source, the router with a higher IPv6 link-local address
wins.
Introduction to IPv6 PIM-SM
IPv6 PIM-DM uses the flood and prune principle to build SPTs for IPv6 multicast data distribution.
Although an SPT has the shortest path, it is built with a low efficiency. Therefore the PIM-DM mode is
not suitable for large-and medium-sized networks.
IPv6 PIM-SM is a type of sparse mode IPv6 multicast protocol. It uses the pull mode for IPv6 multicast
forwarding, and is suitable for large- and medium-sized networks with sparsely and widely distributed
IPv6 multicast group members.
The basic implementation of IPv6 PIM-SM is as follows:
z IPv6 PIM-SM assumes that no hosts need to receive IPv6 multicast data. In the IPv6 PIM-SM
mode, routers must specifically request a particular IPv6 multicast stream before the data is
forwarded to them. The core task for IPv6 PIM-SM to implement IPv6 multicast forwarding is to
build and maintain rendezvous point trees (RPTs). An RPT is rooted at a router in the IPv6 PIM
domain as the common node, or rendezvous point (RP), through which the IPv6 multicast data
travels along the RPT and reaches the receivers.
z When a receiver is interested in the IPv6 multicast data addressed to a specific IPv6 multicast
group, the router connected to this receiver sends a join message to the RP corresponding to that
1-5
IPv6 multicast group. The path along which the message goes hop by hop to the RP forms a
branch of the RPT.
z When a multicast source sends IPv6 multicast streams to an IPv6 multicast group, the source-side
designated router (DR) first registers the multicast source with the RP by sending register
messages to the RP by unicast until it receives a register-stop message from the RP. The arrival a
register message at the RP triggers the establishment of an SPT. Then, the multicast source sends
subsequent IPv6 multicast packets along the SPT to the RP. Upon reaching the RP, the IPv6
multicast packet is duplicated and delivered to the receivers along the RPT.
IPv6 multicast traffic is duplicated only where the distribution tree branches, and this process
automatically repeats until the IPv6 multicast traffic reaches the receivers.
How IPv6 PIM-SM Works
The working mechanism of IPv6 PIM-SM is summarized as follows:

z DR election
z RP discovery
z Embedded RP
z RPT establishment
z IPv6 Multicast source registration
z Switchover from RPT to SPT
z Assert
Neighbor discovery
IPv6 PIM-SM uses the similar neighbor discovery mechanism as IPv6 PIM-DM does. Refer to Neighbor
discovery.
DR election
IPv6 PIM-SM also uses hello messages to elect a DR for a multi-access network (such as an Ethernet).
The elected DR will be the only multicast forwarder on this multi-access network.
In the case of a multi-access network, a DR must be elected, no matter this network connects to IPv6
multicast sources or to receivers. The DR at the receiver side sends join messages to the RP; the DR at
the IPv6 multicast source side sends register messages to the RP.
z A DR is elected on a multi-access subnet by means of comparison of the priorities and IPv6

link-local addresses carried in hello messages.
z MLD must be enabled on a device that acts as a DR before receivers attached to this device can
join IPv6 multicast groups through this DR.
For details about MLD, refer to MLD Configuration in the IP Multicast Volume.
1-6
Figure 1-3 DR election
Receiver
DR
DR RP
Source
Receiver
Hello message
Register message
Join message
As shown in Figure 1-3, the DR election process is as follows:

1) Routers on the multi-access network send hello messages to one another. The hello messages
contain the router priority for DR election. The router with the highest DR priority will become the
DR.
2) In the case of a tie in the router priority, or if any router in the network does not support carrying the
DR-election priority in hello messages, The router with the highest IPv6 link-local address will win
the DR election.
When the DR works abnormally, a timeout in receiving hello message triggers a new DR election
process among the other routers.
RP discovery
The RP is the core of an IPv6 PIM-SM domain. For a small-sized, simple network, one RP is enough for
forwarding IPv6 multicast information throughout the network, and the position of the RP can be
statically specified on each router in the IPv6 PIM-SM domain. In most cases, however, an IPv6
PIM-SM network covers a wide area and a huge amount of IPv6 multicast traffic needs to be forwarded
through the RP. To lessen the RP burden and optimize the topological structure of the RPT, each RP
serves a different IPv6 multicast group range. Therefore, a bootstrap mechanism is needed for dynamic
RP election. For this purpose, a bootstrap router (BSR) should be configured.
As the administrative core of an IPv6 PIM-SM domain, the BSR collects advertisement messages
(C-RP-Adv messages) from candidate-RPs (C-RPs) and chooses the appropriate C-RP information for
each IPv6 multicast group to form an RP-Set, which is a database of mappings between IPv6 multicast
groups and RPs. The BSR then floods the RP-Set to the entire IPv6 PIM-SM domain. Based on the
information in these RP-Sets, all routers (including the DRs) in the network can calculate the location of
the corresponding RPs.
An IPv6 PIM-SM domain can have only one BSR, but can have multiple candidate-BSRs (C-BSRs).
Once the BSR fails, a new BSR is automatically elected from the C-BSRs through the bootstrap
mechanism to avoid service interruption. Similarly, multiple C-RPs can be configured in an IPv6
PIM-SM domain, and the position of the RP corresponding to each IPv6 multicast group is calculated
through the BSR mechanism.
1-7
A device can act as a C-RP and a C-BSR at the same time.
Figure 1-4 shows the positions of C-RPs and the BSR in the network.
Figure 1-4 BSR and C-RPs
Embedded RP
The Embedded RP mechanism allows a router to resolve the RP address from an IPv6 multicast
address so that the IPv6 multicast group is mapped to an RP, which can take the place of the statically
configured RP or the RP dynamically calculated based on the BSR mechanism. The DR does not need
to know the RP address beforehand. The specific process is as follows.
z At the receiver side:
1) A receiver host initiates an MLD report to announce its joining an IPv6 multicast group.
2) Upon receiving the MLD report, the receiver-side DR resolves the RP address embedded in the
IPv6 multicast address, and sends a join message to the RP.
z At the IPv6 multicast source side:
3) The IPv6 multicast source sends IPv6 multicast traffic to the IPv6 multicast group.
4) The source-side DR resolves the RP address embedded in the IPv6 multicast address, and sends
a register message to the RP.
1-8
RPT establishment
Figure 1-5 RPT establishment in an IPv6 PIM-SM domain
As shown in Figure 1-5, the process of building an RPT is as follows:

1) When a receiver joins IPv6 multicast group G, it uses an MLD report message to inform the directly
connected DR.
2) Upon getting the IPv6 multicast group Gs receiver information, the DR sends a join message,
which is hop by hop forwarded to the RP corresponding to the multicast group.
3) The routers along the path from the DR to the RP form an RPT branch. Each router on this branch
generates a (*, G) entry in its forwarding table. The * means any IPv6 multicast source. The RP is
the root, while the DRs are the leaves, of the RPT.
The IPv6 multicast data addressed to the IPv6 multicast group G flows through the RP, reaches the
corresponding DR along the established RPT, and finally is delivered to the receiver.
When a receiver is no longer interested in the IPv6 multicast data addressed to a multicast group G, the
directly connected DR sends a prune message, which goes hop by hop along the RPT to the RP. Upon
receiving the prune message, the upstream node deletes the interface connected with this downstream
node from the outgoing interface list and checks whether it has receivers for that IPv6 multicast group.
If not, the router continues to forward the prune message to its upstream router.
Multicast source registration
The purpose of IPv6 multicast source registration is to inform the RP about the existence of the IPv6
multicast source.
1-9
Figure 1-6 IPv6 multicast source registration
As shown in Figure 1-6, the IPv6 multicast source registers with the RP as follows:
1) When the IPv6 multicast source S sends the first IPv6 multicast packet to IPv6 multicast group G,
the DR directly connected with the multicast source, upon receiving the multicast packet,
encapsulates the packet in a register message, and sends the message to the corresponding RP
by unicast.
2) When the RP receives the register message, it extracts the multicast packet from the register
message and forwards the multicast IPv6 multicast packet down the RPT, and sends an (S, G) join
message hop by hop toward the IPv6 multicast source. Thus, the routers along the path from the
RP to the IPv6 multicast source form an SPT branch. Each router on this branch generates an (S,
G) entry in its forwarding table. The IPv6 multicast source is the root, while the RP is the leaf, of the
SPT.
3) The subsequent IPv6 multicast data from the IPv6 multicast source travels along the established
SPT to the RP, and then the RP forwards the data along the RPT to the receivers. When the IPv6
multicast traffic arrives at the RP along the SPT, the RP sends a register-stop message to the
source-side DR by unicast to stop the source registration process.
Switchover from RPT to SPT
When the receiver-side DR finds that the traffic rate of the IPv6 multicast packets the RP sends to IPv6
multicast group G exceeds a configurable threshold, the RP will initiate an RPT-to-SPT switchover
process, as follows:
1) First, the receiver-side DR sends an (S, G) join message hop by hop to the multicast source S.
When the join message reaches the source-side DR, all the routers on the path have installed the
(S, G) entry in their forwarding table, and thus an SPT branch is established.
2) Subsequently, the receiver-side DR sends an RP-bit prune message containing the RP bit hop by
hop to the RP. Upon receiving this prune message, the RP sends a prune message toward the
IPv6 multicast source (suppose only one receiver exists), thus to implement RPT-to-SPT
switchover.
1-10
After the RPT-to-SPT switchover, IPv6 multicast data can be directly sent from the source to the
receivers. IPv6 PIM-SM builds SPTs through RPT-to-SPT switchover more economically than IPv6
PIM-DM does through the flood and prune mechanism.
Assert
IPv6 PIM-SM uses the similar assert mechanism as IPv6 PIM-DM does. Refer to Assert.
SSM Model Implementation in IPv6 PIM
The source-specific multicast (SSM) model and the any-source multicast (ASM) model are two opposite
models. Presently, the ASM model includes the IPv6 PIM-DM and IPv6 PIM-SM modes. The SSM
model can be implemented by leveraging part of the IPv6 PIM-SM technique.
The SSM model provides a solution for source-specific multicast. It maintains the relationships between
hosts and routers through MLDv2. IPv6 PIM-DM implements IPv6 multicast forwarding by building
SPTs rooted at the IPv6 multicast source through the flood and prune mechanism. Although an SPT
has the shortest path, it is built in a low efficiency. Therefore the IPv6 PIM-DM mod is not suitable for
large- and medium-sized networks.
In actual application, part of the IPv6 PIM-SM technique is adopted to implement the SSM model. In the
SSM model, receivers know exactly where an IPv6 multicast source is located by means of
advertisements, consultancy, and so on. Therefore, no RP is needed, no RPT is required, and is no
source registration process is needed for the purpose of discovering IPv6 multicast sources in other
IPv6 PIM domains.
Compared with the ASM model, the SSM model only needs the support of MLDv2 and some subsets of
IPv6 PIM-SM. The operation mechanism of the SSM model in an IPv6 PIM domain can be summarized
as follows:
z DR election
z SPT building
Neighbor discovery
IPv6 PIM-SSM uses the same neighbor discovery mechanism as in IPv6 PIM-SM. Refer to Neighbor
discovery.
DR election
IPv6 PIM-SSM uses the same DR election mechanism as in IPv6 PIM-SM. Refer to DR election.
SPT building
Whether to build an RPT for IPv6 PIM-SM or an SPT for IPv6 PIM-SSM depends on whether the IPv6
multicast group the receiver is to join falls in the IPv6 SSM group range (the IPv6 SSM group range
reserved by IANA is FF3x::/32, where x represents any legal address scope).
1-11
Figure 1-7 Building an SPT in IPv6 PIM-SSM
As shown in Figure 1-7, Hosts B and C are IPv6 multicast information receivers. They send an MLDv2
report message marked (include S, G) to the respective DRs to announce that they are interested in the
information of the specific IPv6 multicast source S and that sent to the IPv6 multicast group G. If they
need information from other sources than S, they send an (exclude S, G) report. No matter what the
description is, the position of IPv6 multicast source S is explicitly specified for receivers.
The DR that has received the report first checks whether the IPv6 group address in this message falls in
the IPv6 SSM group range:
z If so, the IPv6 PIM-SSM model is built: the DR sends a channel subscription message hop by hop
toward the IPv6 multicast source S. An (include S, G) or (exclude S, G) entry is created on all
routers on the path from the DR to the source. Thus, an SPT is built in the network, with the source
S as its root and receivers as its leaves. This SPT is the transmission channel in IPv6 PIM-SSM.
z If not, the IPv6 PIM-SM process is followed: the DR needs to send a (*, G) join message to the RP,
and an IPv6 multicast source registration process is needed.
z In IPv6 PIM-SSM, the channel concept is used to refer to an IPv6 multicast group, and the
channel subscription concept is used to refer to a join message.
z The support for the Exclude mode varies with device models.
IPv6 PIMrelated specifications are as follows:

z RFC 4601: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
(Revised)
z RFC 3973: Protocol Independent Multicast-Dense Mode(PIM-DM):Protocol Specification(Revised)
z RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
z RFC 4607: Source-Specific Multicast for IP
z draft-ietf-pim-sm-bsr-09: Bootstrap Router (BSR) Mechanism for PIM
1-12
z draft-ietf-ssm-overview-05: An Overview of Source-Specific Multicast (SSM)
Configuring IPv6 PIM-DM

IPv6 PIM-DM Configuration Task List
Complete these tasks to configure IPv6 PIM-DM:
Task Remarks
Enabling IPv6 PIM-DM Required
Enabling State-Refresh Capability Optional
Configuring State Refresh Parameters Optional
Configuring IPv6 PIM-DM Graft Retry Period Optional
Configuring IPv6 PIM Common Features Optional
Before configuring IPv6 PIM-DM, complete the following task:

z Configure any IPv6 unicast routing protocol so that all devices in the domain are interoperable at
the network layer.
Before configuring IPv6 PIM-DM, prepare the following data:
z The interval between state refresh messages
z Minimum time to wait before receiving a new refresh message
z Hop limit value of state-refresh messages
z Graft retry period
Enabling IPv6 PIM-DM
With IPv6 PIM-DM enabled, a router sends hello messages periodically to discover IPv6 PIM neighbors
and processes messages from the IPv6 PIM neighbors. When deploying an IPv6 PIM-DM domain, you
are recommended to enable IPv6 PIM-DM on all non-border interfaces of routers.
Follow these steps to enable IPv6 PIM-DM:

Required
Disable by default
interface-number
Required
Enable IPv6 PIM-DM pim ipv6 dm
Disabled by default
1-13
z All the interfaces of the same device must work in the same IPv6 PIM mode.
z IPv6 PIM-DM cannot be used for IPv6 multicast groups in the IPv6 SSM group range.
Enabling State-Refresh Capability
An interface without the state-refresh capability cannot forward state-refresh messages.

It is recommended to keep the state-refresh capability enabled on all routers in the IPv6 PIM-DM
domain.
Follow these steps to enable the state-refresh capability:

interface-number
Enable the state-refresh pim ipv6 Optional

capability state-refresh-capable Enabled by default
Configuring State Refresh Parameters
To avoid the resource-consuming reflooding of unwanted traffic caused by timeout of pruned interfaces,
the router directly connected with the IPv6 multicast source periodically sends an (S, G) state-refresh
message, which is forwarded hop by hop along the initial flooding path of the IPv6 PIM-DM domain, to
refresh the prune timer state of all the routers on the path.
A router may receive multiple state-refresh messages within a short time, of which some may be
duplicated messages. To keep a router from receiving such duplicated messages, you can configure
the time the router must wait before receiving the next state-refresh message. If a new state-refresh
message is received within the waiting time, the router will discard it; if this timer times out, the router
will accept a new state-refresh message, refresh its own IPv6 PIM-DM state, and reset the waiting timer.
The hop limit value of a state-refresh message decrements by 1 whenever it passes a router before it is
forwarded to the downstream node until the hop limit value comes down to 0. In a small network, a
state-refresh message may cycle in the network. To effectively control the propagation scope of
state-refresh messages, you need to configure an appropriate hop limit value based on the network
size.
It is recommended to perform the following configurations on all routers in the IPv6 PIM domain.
1-14
Follow these steps to configure state-refresh parameters:

Enter IPv6 PIM view pim ipv6
Configure the interval between Optional

state-refresh-interval interval
state-refresh messages 60 seconds by default
Configure the time to wait Optional
state-refresh-rate-limit
before receiving a new
state-refresh message
Configure the hop limit value of state-refresh-hoplimit Optional

state-refresh messages hoplimit-value 255 by default
Configuring IPv6 PIM-DM Graft Retry Period
In IPv6 PIM-DM, graft is the only type of message that uses the acknowledgment mechanism. In an
IPv6 PIM-DM domain, if a router does not receive a graft-ack message from the upstream router within
the specified time after it sends a graft message, the router keeps sending new graft messages at a
configurable interval, namely graft retry period, until it receives a graft-ack from the upstream router.
Follow these steps to configure IPv6 PIM-DM graft retry period:

interface-number
pim ipv6 timer graft-retry Optional

Configure graft retry period
For the configuration of other timers in IPv6 PIM-DM, refer to Configuring IPv6 PIM Common Timers.
1-15
Configuring IPv6 PIM-SM
IPv6 PIM-SM Configuration Task List
Complete these tasks to configure IPv6 PIM-SM:
Task Remarks
Enabling IPv6 PIM-SM Required
Configuring a static RP Optional
Configuring a C-RP Optional
Configuring an RP
Enabling embedded RP Optional
Configuring C-RP timers globally Optional
Configuring a C-BSR Optional
Configuring an IPv6 PIM domain border Optional

Configuring a BSR
Configuring C-BSR parameters globally Optional
Configuring C-BSR timers Optional
Configuring IPv6 Multicast Source Registration Optional

Configuring RPT-to-SPT Switchover Optional
Before configuring IPv6 PIM-SM, complete the following task:

the network layer.
Before configuring IPv6 PIM-SM, prepare the following data:
z The IP address of a static RP and an ACL rule defining the range of IPv6 multicast groups to be
served by the static RP
z C-RP priority and an ACL rule defining the range of IPv6 multicast groups to be served by each
C-RP
z A legal C-RP address range and an ACL rule defining the range of IPv6 multicast groups to be
served
z C-RP-Adv interval
z C-RP timeout
z C-BSR priority
z Hash mask length for RP selection calculation
z An IPv6 ACL rule defining a legal BSR address range
z BS period
z BS timeout
z An IPv6 ACL rule for register message filtering
z Register suppression time
z Register probe time
z The IPv6 multicast traffic rate threshold, IPv6 ACL rule, and sequencing rule for RPT-to-SPT
switchover
1-16
z The interval of checking the IPv6 multicast traffic rate threshold before RPT-to-SPT switchover
Enabling IPv6 PIM-SM
With IPv6 PIM-SM enabled, a router sends hello messages periodically to discover IPv6 PIM neighbors
and processes messages from the IPv6 PIM neighbors. When deploying an IPv6 PIM-SM domain, you
are recommended to enable IPv6 PIM-SM on all non-border interfaces of the routers.
Follow these steps to enable IPv6 PIM-SM:

Required
Disable by default
interface-number
Required
Enable IPv6 PIM-SM pim ipv6 sm
Disabled by default
All the interfaces of the same device must work in the same IPv6 PIM mode.
Configuring an RP
An RP can be manually configured or dynamically elected through the BSR mechanism. For a large
IPv6 PIM network, static RP configuration is a tedious job. Generally, static RP configuration is just a
backup means for the dynamic RP election mechanism to enhance the robustness and operation
manageability of a multicast network.
Configuring a static RP
If there is only one dynamic RP in a network, manually configuring a static RP can avoid communication
interruption due to single-point failures and avoid frequent message exchange between C-RPs and the
BSR.
Perform the following configuration on all the routers in the IPv6 PIM-SM domain.
Follow these steps to configure a static RP:

1-17
static-rp ipv6-rp-address Required

Configure a static RP
[ acl6-number ] [ preferred ] No static RP by default
To enable a static RP to work normally, you must perform this configuration on all routers in the IPv6
PIM-SM domain and specify the same RP address.
Configuring a C-RP
In an IPv6 PIM-SM domain, you can configure routers that intend to become the RP as C-RPs. The
BSR collects the C-RP information by receiving the C-RP-Adv messages from C-RPs or auto-RP
announcements from other routers and organizes the information into an RP-Set, which is flooded
throughout the entire network. Then, the other routers in the network calculate the mappings between
specific group ranges and the corresponding RPs based on the RP-Set. We recommend that you
configure C-RPs on backbone routers.
To guard against C-RP spoofing, you need to configure a legal C-RP address range and the range of
IPv6 multicast groups to be served on the BSR. In addition, because every C-BSR has a chance to
become the BSR, you need to configure the same filtering policy on all C-BSRs in the IPv6 PIM-SM
domain.
Follow these steps to configure a C-RP:

c-rp ipv6-address [ group-policy Required
Configure an interface to be a acl6-number | priority priority | holdtime
C-RP hold-interval | advertisement-interval No C-RPs are
adv-interval ] * configured by default.
Configure a legal C-RP Optional

address range and the range of
crp-policy acl6-number No restrictions by
IPv6 multicast groups to be
served default
z When configuring a C-RP, ensure a relatively large bandwidth between this C-RP and the other
devices in the IPv6 PIM-SM domain.
z An RP can serve multiple IPv6 multicast groups or all IPv6 multicast groups. Only one RP can
forward IPv6 multicast traffic for an IPv6 multicast group at a moment.
1-18
Enabling embedded RP
With the Embedded RP feature enabled, the router can resolve the RP address directly from the IPv6
multicast group address of an IPv6 multicast packets. This RP can replace the statically configured RP
or the RP dynamically calculated based on the BSR mechanism. Thus, the DR does not need to know
the RP address beforehand.
Follow these steps to enable embedded RP:

Optional
Enable embedded RP embedded-rp [ acl6-number ] By default, embedded RP is enabled
for IPv6 multicast groups in the default
embedded RP address scopes.
The default embedded RP address scopes are FF7x::/12 and FFFx::/12. Here x refers to any legal
address scope. For details of the scope field, see Multicast Overview of the IP Multicast Volume.
Configuring C-RP timers globally
To enable the BSR to distribute the RP-Set information within the IPv6 PIM-SM domain, C-RPs must
periodically send C-RP-Adv messages to the BSR. The BSR learns the RP-Set information from the
received messages, and encapsulates its own IPv6 address together with the RP-Set information in its
bootstrap messages. The BSR then floods the bootstrap messages to all IPv6 routers in the network.
Each C-RP encapsulates a timeout value in its C-RP-Adv messages. Upon receiving a C-RP-Adv
message, the BSR obtains this timeout value and starts a C-RP timeout timer. If the BSR fails to hear a
subsequent C-RP-Adv message from the C-RP when the timer times out, the BSR assumes the C-RP
to have expired or become unreachable.
The C-RP timers need to be configured on C-RP routers.
Follow these steps to configure C-RP timers globally:

Configure the C-RP-Adv c-rp advertisement-interval Optional

Optional
Configure C-RP timeout time c-rp holdtime interval
1-19
For the configuration of other timers in IPv6 PIM-SM, refer to Configuring IPv6 PIM Common Timers.
Configuring a BSR
An IPv6 PIM-SM domain can have only one BSR, but must have at least one C-BSR. Any router can be
configured as a C-BSR. Elected from C-BSRs, the BSR is responsible for collecting and advertising RP
information in the IPv6 PIM-SM domain.
Configuring a C-BSR
C-BSRs should be configured on routers in the backbone network. When configuring a router as a
C-BSR, make sure to specify the IPv6 address of an IPv6 PIM-SM enabled interface on the router. The
BSR election process is summarized as follows:
z Initially, every C-BSR assumes itself to be the BSR of this IPv6 PIM-SM domain, and uses its
interface IPv6 address as the BSR address to send bootstrap messages.
z When a C-BSR receives the bootstrap message of another C-BSR, it first compares its own priority
with the other C-BSRs priority carried in the message. The C-BSR with a higher priority wins. If
there is a tie in the priority, the C-BSR with a higher IPv6 address wins. The loser uses the winners
BSR address to replace its own BSR address and no longer assumes itself to be the BSR, while
the winner keeps its own BSR address and continues assuming itself to be the BSR.
Configuring a legal range of BSR addresses enables filtering of bootstrap messages based on the
address range, thus to prevent a maliciously configured host from masquerading as a BSR. The same
configuration needs to be made on all routers in the IPv6 PIM-SM domain. The following are typical
BSR spoofing cases and the corresponding preventive measures:
1) Some maliciously configured hosts can forge bootstrap messages to fool routers and change RP
mappings. Such attacks often occur on border routers. Because a BSR is inside the network
whereas hosts are outside the network, you can protect a BSR against attacks from external hosts
by enabling the border routers to perform neighbor checks and RPF checks on bootstrap
messages and discard unwanted messages.
2) When a router in the network is controlled by an attacker or when an illegal router is present in the
network, the attacker can configure this router as a C-BSR and make it win BSR election to control
the right of advertising RP information in the network. After being configured as a C-BSR, a router
automatically floods the network with bootstrap messages. As a bootstrap message has a hop limit
value of 1, the whole network will not be affected as long as the neighbor router discards these
bootstrap messages. Therefore, with a legal BSR address range configured on all routers in the
entire network, all these routers will discard bootstrap messages from out of the legal address
range.
The above-mentioned preventive measures can partially protect the security of BSRs in a network.
However, if a legal BSR is controlled by an attacker, the above-mentioned problem will also occur.
Follow these steps to complete basic BSR configuration:

1-20
Configure an interface c-bsr ipv6-address Required

as a C-BSR [ hash-length [ priority ] ] No C-BSRs are configured by default.
Configure a legal BSR Optional

bsr-policy acl6-number
address range No restrictions by default
Since a large amount of information needs to be exchanged between a BSR and the other devices in
the IPv6 PIM-SM domain, a relatively large bandwidth should be provided between the C-BSR and the
other devices in the IPv6 PIM-SM domain.
Configuring an IPv6 PIM domain border
As the administrative core of an IPv6 PIM-SM domain, the BSR sends the collected RP-Set information
in the form of bootstrap messages to all routers in the IPv6 PIM-SM domain.
An IPv6 PIM domain border is a bootstrap message boundary. Each BSR has its specific service scope.
A number of IPv6 PIM domain border interfaces partition a network into different IPv6 PIM-SM domains.
Bootstrap messages cannot cross a domain border in either direction.
Perform the following configuration on routers that can become an IPv6 PIM domain border.
Follow these steps to configure an IPv6 PIM border domain:

interface-number
Required
Configuring an IPv6 PIM
pim ipv6 bsr-boundary No IPv6 PIM domain border is configured
domain border
by default
Configuring C-BSR parameters globally
In each IPv6 PIM-SM domain, a unique BSR is elected from C-BSRs. The C-RPs in the IPv6 PIM-SM
domain send advertisement messages to the BSR. The BSR summarizes the advertisement messages
to form an RP-set and advertises it to all routers in the IPv6 PIM-SM domain. All the routers use the
same Hash algorithm to get the RP address corresponding to specific IPv6 multicast groups.
Follow these steps to configure C-BSR parameters globally:

1-21
Configure the Hash mask Optional
length for RP selection c-bsr hash-length hash-length
calculation 126 by default
Optional
Configure the C-BSR priority c-bsr priority priority
0 by default
Configuring C-BSR timers
The BSR election winner multicasts its own IPv6 address and RP-Set information throughout the region
that it serves through bootstrap messages. The BSR floods bootstrap messages throughout the
network at the interval of BS (BSR state) period. Any C-BSR that receives a bootstrap message retains
the RP-set for the length of BS timeout, during which no BSR election takes place. If the BSR state
times out and no bootstrap message is received from the BSR, a new BSR election process is triggered
among the C-BSRs.
Follow these steps to configure C-BSR timers:

Optional
Configure the BS period c-bsr interval interval
Optional
Configure the BS timeout c-bsr holdtime interval
About the BS period:

z By default, the BS period is determined by this formula: BS period = (BS timeout 10) / 2. The
default BS timeout is 130 seconds, so the default BS period = (130 10) / 2 = 60 (seconds).
About the BS timeout:
z By default, the BS timeout value is determined by this formula: BS timeout = BS period 2 + 10.
The default BS period is 60 seconds, so the default BS timeout = 60 2 + 10 = 130 (seconds).
In configuration, make sure that the BS period is smaller than the BS timeout value.
1-22
Configuring IPv6 Multicast Source Registration
Within an IPv6 PIM-SM domain, the source-side DR sends register messages to the RP, and these
register messages have different IPv6 multicast source or IPv6 multicast group addresses. You can
configure a filtering rule to filter register messages so that the RP can serve specific IPv6 multicast
groups. If an (S, G) entry is denied by the filtering rule, or the action for this entry is not defined in the
filtering rule, the RP will send a register-stop message to the DR to stop the registration process for the
IPv6 multicast data.
In view of information integrity of register messages in the transmission process, you can configure the
device to calculate the checksum based on the entire register messages. However, to reduce the
workload of encapsulating data in register messages and for the sake of interoperability, this method of
checksum calculation is not recommended.
When receivers stop receiving data addressed to a certain IPv6 multicast group through the RP (that is,
the RP stops serving the receivers of that IPv6 multicast group), or when the RP formally starts
receiving IPv6 multicast data from the IPv6 multicast source, the RP sends a register-stop message to
the source-side DR. Upon receiving this message, the DR stops sending register messages
encapsulated with IPv6 multicast data and starts a register-stop timer. When the register-stop timer
expires, the DR sends a null register message (a register message without encapsulated multicast data)
to the RP. If the DR receives a register-stop message during the register probe time, it will reset its
register-stop timer; otherwise, the DR starts sending register messages with encapsulated data again
when the register-stop timer expires.
The Register-Stop Timer is set to a random value chosen uniformly from the interval (0.5 times
register_suppression_time, 1.5 times register_suppression_time) minus register_probe_time.
Configure a filtering rule for register messages on all C-RP routers and configure them to calculate the
checksum based on the entire register messages. Configure the register suppression time and the
register probe time on all routers that may become source-side DRs.
Follow these steps to configure register-related parameters:


Optional
Configure a filtering rule for
register-policy acl6-number No register filtering rule by
register messages
default
Configure the device to Optional

calculate the checksum based register-whole-checksum Based on the header of register
on the entire register messages messages by default
Configure the register register-suppression-timeou Optional

suppression time t interval 60 seconds by default
Configure the register probe Optional

probe-interval interval
time 5 seconds by default
1-23
Configuring RPT-to-SPT Switchover
In an IPv6 PIM-SM network, an IPv6 multicast stream first flows to the receivers down an RPT. However,
because an RPT is not necessarily the tree that has the shortest path, the IPv6 multicast forwarding
path needs to be switched from the RPT to the SPT when the IPv6 multicast traffic is large. You can
configure a traffic rate threshold (configurable on routers only, but not on switches) at which the
receiver-side DR initiates an RPT-to-SPT switchover process.
Both the receiver-side DR and the RP can periodically check the passing-by IPv6 multicast packets (this
function is not available with switches) and thus trigger RPT-to-SPT switchover.
Perform the following configuration on routers that may become receiver-side DRs and on C-RP
routers.
Follow these steps to configure RPT-to-SPT switchover:

Optional
spt-switch-threshold By default, the device switches to
{ traffic-rate | infinity } the SPT immediately after it receives
Configure RPT-to-SPT
[ group-policy the first IPv6 multicast packet from
switchover
acl6-number [ order the RPT.
order-value ] ] The traffic-rate argument is not
supported on a switch.
Configure the interval of
checking the IPv6 multicast Optional
timer spt-switch interval
traffic rate threshold before 15 seconds by default
RPT-to-SPT switchover
The support for the timer spt-switch command depends on the specific device model.
Configuring IPv6 PIM-SSM
The IPv6 PIM-SSM model needs the support of MLDv2. Therefore, be sure to enable MLDv2 on IPv6
PIM routers with receivers attached to them.
IPv6 PIM-SSM Configuration Task List
Complete these tasks to configure IPv6 PIM-SSM:
1-24
Task Remarks
Enabling IPv6 PIM-SM Required
Configuring the IPv6 SSM Group Range Optional
Before configuring IPv6 PIM-SSM, complete the following task:

the network layer.
Before configuring IPv6 PIM-SSM, prepare the following data:
z The IPv6 SSM group range
Enabling IPv6 PIM-SM
The SSM model is implemented based on some subsets of IPv6 PIM-SM. Therefore, a router is IPv6
PIM-SSM capable after you enable IPv6 PIM-SM on it.
When deploying an IPv6 PIM-SM domain, you are recommended to enable IPv6 PIM-SM on all
non-border interfaces of routers.
Follow these steps to enable IPv6 PIM-SSM:

Required
Disable by default
interface-number
Required
Enable IPv6 PIM-SM pim ipv6 sm
Disabled by default
All the interfaces of the same device must work in the same IPv6 PIM mode.
1-25
Configuring the IPv6 SSM Group Range
As for whether the information from an IPv6 multicast source is delivered to the receivers based on the
IPv6 PIM-SSM model or the IPv6 PIM-SM model, this depends on whether the group address in the (S,
G) channel subscribed by the receivers falls in the IPv6 SSM group range. All IPv6 PIM-SM-enabled
interfaces assume that IPv6 multicast groups within this address range are using the IPv6 SSM model.
Perform the following configuration on all routers in the IPv6 PIM-SM domain.
Follow these steps to configure the IPv6 SSM group range:

Optional
Configure the IPv6 SSM group
ssm-policy acl6-number FF3x::/32 by default, here x
range
refers to any legal group scope.
z Make sure that the same IPv6 SSM group range is configured on all routers in the entire domain.
Otherwise, IPv6 multicast data cannot be delivered through the IPv6 SSM model.
z When a member of an IPv6 multicast group in the IPv6 SSM group range sends an MLDv1 report
message, the device does not trigger a (*, G) join.
Configuring IPv6 PIM Common Features
For the functions or parameters that can be configured in both IPv6 PIM view and interface view
described in this section:
z Configurations performed in IPv6 PIM view are effective to all interfaces, while configurations
performed in interface view are effective to the current interface only.
z If the same function or parameter is configured in both IPv6 PIM view and interface view, the
configuration made in interface view has preference over the configuration made in PIM view,
regardless of the configuration sequence.
IPv6 PIM Common Feature Configuration Task List
Complete these tasks to configure IPv6 PIM common features:
Task Remarks
Configuring an IPv6 Multicast Data Filter Optional
Configuring IPv6 PIM Hello Options Optional
1-26
Task Remarks
Configuring IPv6 PIM Common Timers Optional
Configuring Join/Prune Message Sizes Optional
Before configuring IPv6 PIM common features, complete the following tasks:
the network layer.
z Configure IPv6 PIM-DM (or IPv6 PIM-SM or IPv6 PIM-SSM).
Before configuring IPv6 PIM common features, prepare the following data:
z An IPv6 ACL rule for filtering IPv6 multicast data
z Priority for DR election (global value/interface level value)
z IPv6 PIM neighbor timeout time (global value/interface value)
z Prune delay (global value/interface level value)
z Prune override interval (global value/interface level value)
z Hello interval (global value/interface level value)
z Maximum delay between hello message (interface level value)
z Assert timeout time (global value/interface value)
z Join/prune interval (global value/interface level value)
z Join/prune timeout (global value/interface value)
z IPv6 multicast source lifetime
z Maximum size of join/prune messages
z Maximum number of (S, G) entries in a join/prune message
Configuring an IPv6 Multicast Data Filter
No matter in an IPv6 PIM-DM domain or an IPv6 PIM-SM domain, routers can check passing-by IPv6
multicast data based on the configured filtering rules and determine whether to continue forwarding the
IPv6 multicast data. In other words, IPv6 PIM routers can act as IPv6 multicast data filters. These filters
can help implement traffic control on one hand, and control the information available to downstream
receivers to enhance data security on the other hand.
Follow these steps to configure an IPv6 multicast data filter:

Configure an IPv6 Required

source-policy acl6-number
multicast group filter No IPv6 multicast data filter by default
1-27
z Generally, a smaller distance from the filter to the IPv6 multicast source results in a more
remarkable filtering effect.
z This filter works not only on independent IPv6 multicast data but also on IPv6 multicast data
encapsulated in register messages.
Configuring IPv6 PIM Hello Options
No matter in an IPv6 PIM-DM domain or an IPv6 PIM-SM domain, the hello messages sent among
routers contain many configurable options, including:
z DR_Priority (for IPv6 PIM-SM only): priority for DR election. The higher the priority is, the easier it is
for the router to win DR election. You can configure this parameter on all the routers in a
multi-access network directly connected to IPv6 multicast sources or receivers.
z Holdtime: the timeout time of IPv6 PIM neighbor reachability state. When this timer times out, if the
router has received no hello message from an IPv6 PIM neighbor, it assumes that this neighbor
has expired or become unreachable.
z LAN_Prune_Delay: the delay of prune messages on a multi-access network. This option consists
of Lan-delay (namely, prune delay), Override-interval, and neighbor tracking flag bit. You can
configure this parameter on all routers in the IPv6 PIM domain. If different LAN-delay or
override-interval values result from the negotiation among all the IPv6 PIM routers, the largest
value will take effect.
The LAN-delay setting will cause the upstream routers to delay processing received prune messages. If
the LAN-delay setting is too small, it may cause the upstream router to stop forwarding IPv6 multicast
packets before a downstream router sends a prune override message. Therefore, be cautious when
configuring this parameter.
The override-interval sets the length of time a downstream router is allowed to wait before sending a
prune override message. When a router receives a prune message from a downstream router, it does
not perform the prune action immediately; instead, it maintains the current forwarding state for a period
of LAN-delay plus override-interval. If the downstream router needs to continue receiving IPv6 multicast
data, it must send a prune override message within the prune override interval; otherwise, the upstream
route will perform the prune action when the period of LAN-delay plus override-interval time out.
A hello message sent from an IPv6 PIM router contains a generation ID option. The generation ID is a
random value for the interface on which the hello message is sent. Normally, the generation ID of an
IPv6 PIM router does not change unless the status of the router changes (for example, when IPv6 PIM
is just enabled on the interface or the device is restarted). When the router starts or restarts sending
hello messages, it generates a new generation ID. If an IPv6 PIM router finds that the generation ID in a
hello message from the upstream router has changed, it assumes that the status of the upstream
neighbor is lost or the upstream neighbor has changed. In this case, it triggers a join message for state
update.
If you disable join suppression (namely, enable neighbor tracking), the upstream router will explicitly
track which downstream routers are joined to it. The join suppression feature should be enabled or
disabled on all IPv6 PIM routers on the same subnet.
1-28
Configuring hello options globally
Follow these steps to configure hello options globally:

Configure the priority for DR hello-option dr-priority Optional

Configure IPv6 PIM neighbor Optional

hello-option holdtime interval
Configure the prune delay time Optional

hello-option lan-delay interval
(LAN-delay) 500 milliseconds by default
Configure the prune override hello-option override-interval Optional

interval interval 2,500 milliseconds by default
hello-option Required
Configuring hello options on an interface
Follow these steps to configure hello options on an interface:

interface-number
Configure the priority for DR pim ipv6 hello-option Optional

election dr-priority priority 1 by default
Configure IPv6 PIM neighbor pim ipv6 hello-option Optional

timeout time holdtime interval 105 seconds by default
Configure the prune delay time pim ipv6 hello-option Optional

(LAN-delay) lan-delay interval 500 milliseconds by default
Configure the prune override pim ipv6 hello-option Optional

interval override-interval interval 2,500 milliseconds by default
pim ipv6 hello-option Required

Configure the interface to reject Required

hello messages without a pim ipv6 require-genid By default, hello messages without
generation ID Generation_ID are accepted.
Configuring IPv6 PIM Common Timers
IPv6 PIM routers discover IPv6 PIM neighbors and maintain IPv6 PIM neighboring relationships with
other routers by periodically sending out hello messages.
1-29
Upon receiving a hello message, an IPv6 PIM router waits a random period, which is equal to or smaller
than the maximum delay between hello messages, before sending out a hello message. This avoids
collisions that occur when multiple IPv6 PIM routers send hello messages simultaneously.
An IPv6 PIM router periodically sends join/prune messages to its upstream for state update. A
join/prune message contains the join/prune timeout time. The upstream router sets a join/prune timeout
timer for each pruned downstream interface.
Any router that has lost assert election will prune its downstream interface and maintain the assert state
for a period of time. When the assert state times out, the assert loser will resume IPv6 multicast
forwarding.
When a router fails to receive subsequent IPv6 multicast data from the IPv6 multicast source S, the
router does not immediately delete the corresponding (S, G) entry; instead, it maintains the (S, G) entry
for a period of time, namely the IPv6 multicast source lifetime, before deleting the (S, G) entry.
Configuring IPv6 PIM common timers globally
Follow these steps to configure IPv6 PIM common timers globally:

Optional
Configure the hello interval timer hello interval

timer join-prune interval

holdtime join-prune interval
Optional
Configure assert timeout time holdtime assert interval
Configure the IPv6 multicast Optional

source-lifetime interval
source lifetime 210 seconds by default
Configuring IPv6 PIM common timers on an interface
Follow these steps to configure IPv6 PIM common timers on an interface:

interface-number
Optional
Configure the hello interval pim ipv6 timer hello interval
Configure the maximum delay pim ipv6 Optional

between hello messages triggered-hello-delay interval 5 seconds by default
Configure the join/prune pim ipv6 timer join-prune Optional

1-30
Configure the join/prune pim ipv6 holdtime join-prune Optional

pim ipv6 holdtime assert Optional

Configure assert timeout time
If there are no special networking requirements, we recommend that you use the default settings.
Configuring Join/Prune Message Sizes
A larger join/prune message size will result in loss of a larger amount of information when a message is
lost; with a reduced join/message size, the loss of a single message will bring relatively minor impact.
By controlling the maximum number of (S, G) entries in a join/prune message, you can effectively
reduce the number of (S, G) entries sent per unit of time.
Follow these steps to configure join/prune message sizes:


jp-pkt-size packet-size
a join/prune message 8,100 bytes by default
number of (S, G) entries in a jp-queue-size queue-size
join/prune message 1,020 by default
Displaying and Maintaining IPv6 PIM

View the BSR information in the
IPv6 PIM-SM domain and
display pim ipv6 bsr-info Available in any view
locally configured C-RP
information in effect
View the information of IPv6
display pim ipv6 claimed-route
unicast routes used by IPv6 Available in any view
[ ipv6-source-address ]
PIM
display pim ipv6 control-message
counters [ message-type { probe |
register | register-stop } | [ interface
View the number of IPv6 PIM
interface-type interface-number | Available in any view
control messages
message-type { assert | bsr | crp | graft
| graft-ack | hello | join-prune |
state-refresh } ] * ]
1-31
View the information about
unacknowledged graft display pim ipv6 grafts Available in any view
messages
display pim ipv6 interface
View the IPv6 PIM information
[ interface-type interface-number ] Available in any view
on an interface or all interfaces
[ verbose ]
display pim ipv6 join-prune mode { sm

[ flags flag-value ] | ssm } [ interface
View the information of
join/prune messages to send
neighbor ipv6-neighbor-address ] *
[ verbose ]
display pim ipv6 neighbor [ interface
View IPv6 PIM neighboring
information
ipv6-neighbor-address | verbose ] *
display pim ipv6 routing-table

[ ipv6-group-address [ prefix-length ] |
ipv6-source-address [ prefix-length ] |
incoming-interface [ interface-type
View the content of the IPv6
interface-number | register ] | Available in any view
PIM routing table
outgoing-interface { include | exclude |
match } { interface-type
interface-number | register } | mode
mode-type | flags flag-value | fsm ] *
display pim ipv6 rp-info
View the RP information Available in any view
[ ipv6-group-address ]
reset pim ipv6 control-message
Reset IPv6 PIM control
counters [ interface interface-type Available in user view
message counters
interface-number ]
IPv6 PIM Configuration Examples (On Routers)

IPv6 PIM-DM Configuration Example
organizations form stub networks, and at least one receiver host exists in each stub network. The
entire IPv6 PIM domain operates in the dense mode.
z Host A and Host C are IPv6 multicast receivers in two stub networks N1 and N2.
z Router D connects to the network that comprises the IPv6 multicast source (Source) through
Ethernet 1/0.
z Router A connects to N1 through Ethernet 1/0, and to Router D through Serial 2/0.
z Router B and Router C connect to N2 through their respective Ethernet 1/0, and to Router D
z MLDv1 is to run between Router A and N1, and between Router B/Router C and N2.
1-32
Network diagram
Figure 1-8 Network diagram for IPv6 PIM-DM configuration (on routers)
N1
Ethernet
/0
S2
/0
N2
S2
Ethernet
PO
S5
Ethernet
1/
PO
S5
/0

Router A Eth1/0 1001::1/64 Router D Eth1/0 4001::1/64
S2/0 1002::1/64 S2/0 1002::2/64
Router B Eth1/0 2001::1/64 POS5/0 2002::2/64
POS5/0 2002::1/64 POS5/1 3001::2/64
Router C Eth1/0 2001::2/64
POS5/0 3001::1/64
Enable IPv6 forwarding on each router and configure the IPv6 address and prefix length for each
interface as per Figure 1-8. Detailed configuration steps are omitted here.
Configure OSPFv3 for interoperation among the routers in the IPv6 PIM-DM domain. Ensure the
network-layer interoperation in the IPv6 PIM-DM domain and enable dynamic update of routing
information among the routers through an IPv6 unicast routing protocol. Detailed configuration steps
are omitted here.
2) Enable IPv6 multicast routing, and enable IPv6 PIM-DM and MLD
# Enable IPv6 multicast routing on Router A, and enable IPv6 PIM-DM on each interface and enable
MLD on Ethernet 1/0, which connects Router A to N1.
[RouterA-Serial2/0] pim ipv6 dm
1-33

# On Router D, enable IPv6 multicast routing and enable IPv6 PIM-DM on each interface.
[RouterD] multicast ipv6 routing-enable
[RouterD-Ethernet1/0] pim ipv6 dm
[RouterD-Serial2/0] pim ipv6 dm
[RouterD-Pos5/0] pim ipv6 dm
[RouterD-Pos5/1] pim ipv6 dm
Carry out the display pim ipv6 interface command to view the IPv6 PIM configuration and running
status on each interface. For example:
# Verify the IPv6 PIM configuration information on Router D.
[RouterD] display pim ipv6 interface
Eth1/0 0 30 1 4001::1
(local)
Ser2/0 0 30 1 1002::2
(local)
Pos5/0 1 30 1 2002::2
(local)
Pos5/1 1 30 1 3001::2
(local)
Carry out the display pim ipv6 neighbor command to view the IPv6 PIM neighboring relationships
among the routers. For example:
# Verify the IPv6 PIM neighboring relationships on Router D.
[RouterD] display pim ipv6 neighbor

1002::1 Ser2/0 00:04:00 00:01:29 1
2002::1 Pos5/0 00:04:16 00:01:29 3
3001::1 Pos5/1 00:03:54 00:01:17 5
Assume that Host A needs to receive information addressed to IPv6 multicast group G (FF0E::101).
Once the IPv6 multicast source S (4001::100/64) sends IPv6 multicast packets to the IPv6 multicast
group G, an SPT is established through traffic flooding. Routers on the SPT path (Router A and Router
D) have their (S, G) entries. Host A sends an MLD report to Router A to join IPv6 multicast group G, and
1-34
a (*, G) entry is generated on Router A. To view the IPv6 PIM routing information on a router, use the
display pim ipv6 routing-table command. For example:
# View the IPv6 PIM multicast routing table information on Router A.
[RouterA] display pim ipv6 routing-table
(*, FF0E::101)
UpTime: 00:01:24
1: Ethernet1/0
Protocol: mld, UpTime: 00:01:20, Expires: never
(4001::100, FF0E::101)
UpTime: 00:01:20
1: Ethernet1/0

# View the IPv6 PIM multicast routing table information on Router D.
(4001::100, FF0E::101)
UpTime: 00:02:19
1: Serial2/0
2: Pos5/0
3: Pos5/1
1-35
IPv6 PIM-SM Configuration Example
entire IPv6 PIM domain operates in the sparse mode.
z Host A and Host C are IPv6 multicast receivers in two stub networks, N1 and N2.
Ethernet 1/0.
z Router A connects to N1 through Ethernet 1/0, and to Router D and Router E through Serial 2/0
and POS 5/0 respectively.
z Router B and Router C connect to N2 through their respective Ethernet 1/0, and to Router E
z Router E connects to Router A, Router B, Router C and Router D, and its POS 5/2 interface acts a
C-BSR and a C-RP, with the range of IPv6 multicast groups served by the C-RP being
FF0E::101/64.
Network diagram
Figure 1-9 Network diagram for IPv6 PIM-SM configuration (on routers)
Receiver
N1
Ethernet
Host A
Router A
Eth1/0
/0
POS5/0
S2
Host B
N2
/0
POS5/2
S2
Receiver
Ethernet
Eth1/0 POS5/3 POS5/1 Eth1/0

Source POS5/0 POS5/0
Router D Router E POS5/0 Router B
Host C
Ethernet
4001::100/64
POS5/0
Eth1/0
IPv6 PIM-SM
Host D
Router C

S2/0 1002::1/64 S2/0 1002::2/64
POS5/0 1003::1/64 POS5/0 4002::1/64
Router B Eth1/0 2001::1/64 Router E POS5/0 3001::2/64
POS5/0 2002::1/64 POS5/1 2002::2/64
Router C Eth1/0 2001::2/64 POS5/2 1003::2/64
POS5/0 3001::1/64 POS5/3 4002::2/64
1-36
Configure OSPFv3 for interoperation among the routers in the IPv6 PIM-SM domain. Ensure the
network-layer interoperation in the IPv6 PIM-SM domain and enable dynamic update of routing
information among the routers through an IPv6 unicast routing protocol. Detailed configuration steps
are omitted here.
2) Enable IPv6 multicast routing, and enable IPv6 PIM-SM and MLD
# Enable IPv6 multicast routing on Router A, enable IPv6 PIM-SM on each interface, and enable MLD
on Ethernet 1/0, which connects Router A to N1.
[RouterA-Serial2/0] pim ipv6 sm
[RouterA-Pos5/0] pim ipv6 sm
D and Router E is also similar to that on Router A except that it is not necessary to enable MLD on the
# Configure the RP service range and the C-BSR and C-RP locations on Router E.
[RouterE] acl ipv6 number 2005
[RouterE-acl6-basic-2005] rule permit source ff0e::101 64
[RouterE-acl6-basic-2005] quit
[RouterE] pim ipv6
[RouterE-pim6] c-bsr 1003::2
[RouterE-pim6] c-rp 1003::2 group-policy 2005
[RouterE-pim6] quit
Carry out the display pim ipv6 interface command to view the IPv6 PIM configuration and running
status on each interface. For example:
# Verify the IPv6 PIM configuration information on Router A.
[RouterA] display pim ipv6 interface
Eth1/0 0 30 1 1001::1
(local)
1-37
Ser2/0 1 30 1 1002::2
Pos5/0 1 30 1 1003::2
To view the BSR election information and the locally configured C-RP information in effect on a router,
use the display pim ipv6 bsr-info command. For example:
# View the BSR information and the locally configured C-RP information in effect on Router A.
[RouterA] display pim ipv6 bsr-info
Elected BSR Address: 1003::2
Priority: 0
Uptime: 00:04:22
Expires: 00:01:46
# View the BSR information on Router E and the locally configured C-RP information in effect.
[RouterE] display pim ipv6 bsr-info
Priority: 0
State: Elected
Uptime: 00:01:10
Candidate BSR Address: 1003::2
Priority: 0
State: Elected
Candidate RP: 1003::2(Pos5/2)

Priority: 0
HoldTime: 130
To view the RP information discovered on a router, use the display pim ipv6 rp-info command. For
example:
# View the RP information on Router A.
[RouterA] display pim ipv6 rp-info
prefix/prefix length: FF0E::101/64
RP: 1003::2
Priority: 0
HoldTime: 130
Uptime: 00:05:19
Expires: 00:02:11
Assume that Host A needs to receive information addressed to IPv6 multicast group G (FF0E::101). An
RPT will be built between Router A and Router E. When the multicast source S (4001::100/64) registers
with the RP, an SPT will be built between Router D and Router E. Upon receiving IPv6 multicast data,
Router A immediately switches from the RPT to the SPT. Routers on the RPT path (Router A and Router
E) have a (*, G) entry, while routers on the SPT path (Router A and Router D) have an (S, G) entry. You
1-38
can use the display pim ipv6 routing-table command to view the PIM routing table information on the
(*, FF0E::101)
RP: 1003::2
UpTime: 00:03:45
Upstream interface: Pos5/0
1: Ethernet1/0
Protocol: mld, UpTime: 00:02:15, Expires: 00:03:06
(4001::100, FF0E::101)
RP: 1003::2
UpTime: 00:02:15
1: Ethernet1/0

(4001::100, FF0E::101)
RP: 1003::2
UpTime: 00:14:44
1: Pos5/0
# View the IPv6 PIM routing table information on Router E.
1-39
[RouterE] display pim ipv6 routing-table
(*, FF0E::101)
RP: 1003::2 (local)
UpTime: 00:16:56
1: Pos5/2
IPv6 PIM-SSM Configuration Example
entire IPv6 PIM domain operates in the SSM mode.
z Host A and Host C are IPv6 multicast receivers in two stub networks, N1 and N2.
Ethernet 1/0.
z Router A connects to N1 through Ethernet 1/0, and to Router D and Router E through Serial 2/0
and POS 5/0 respectively.
z Router B and Router C connect to N2 through their respective Ethernet 1/0, and to Router E
z Router E connects to Router A, Router B, Router C and Router D.
z The SSM group range is FF3E::/64.
1-40
Network diagram
Figure 1-10 Network diagram for IPv6 PIM-SSM configuration (on routers)
Receiver
N1
Ethernet
Host A
Router A
Eth1/0
/0
POS5/0
S2
Host B
N2
/0
POS5/2
S2
Receiver
Ethernet
Eth1/0 POS5/3 POS5/1 Eth1/0

Source POS5/0 POS5/0
Router D Router E POS5/0 Router B
Host C
Ethernet
4001::100/64
POS5/0
Eth1/0
IPv6 PIM-SM
Host D
Router C

S2/0 1002::1/64 S2/0 1002::2/64
POS5/0 1003::1/64 POS5/0 4002::1/64
Router B Eth1/0 2001::1/64 Router E POS5/0 3001::2/64
POS5/0 2002::1/64 POS5/1 2002::2/64
Router C Eth1/0 2001::2/64 POS5/2 1003::2/64
POS5/0 3001::1/64 POS5/3 4002::2/64
Configure OSPFv3 for interoperation among the routers in the IPv6 PIM-SM domain. Ensure the
# Enable IPv6 multicast routing on Router A, and enable IPv6 PIM-SM on each interface, and run
MLDv2 on Ethernet 1/0, which connects Router A to N1.
[RouterA-Ethernet1/0] mld version 2
1-41
[RouterA-Serial2/0] pim ipv6 sm
D and Router E is also similar to that on Router A except that it is not necessary to enable MLD on the
# Configure the IPv6 SSM group range to be FF3E::/64 on Router A.
[RouterA] acl ipv6 number 2000
[RouterA-acl6-basic-2000] rule permit source ff3e:: 64
[RouterA-acl6-basic-2000] quit
[RouterA] pim ipv6
[RouterA-pim6] ssm-policy 2000
[RouterA-pim6] quit
The configuration on Router B, Router C, Router D and Router E is similar to that on Router A.
Use the display pim ipv6 interface command to view the IPv6 PIM configuration and running status on
# Verify the IPv6 PIM configuration information on Router A.
[RouterA] display pim ipv6 interface
Eth1/0 0 30 1 1001::1
(local)
Ser2/0 1 30 1 1002::2
Pos5/0 1 30 1 1003::2
Assume that Host A needs to receive the information a specific IPv6 multicast source S (4001::100/64)
sends to multicast group G (FF3E::101). Router A builds an SPT toward the multicast source. Routers
on the SPT path (Router A and Router D) have generated an (S, G) entry, while Router E, which is not
on the SPT path, does not have multicast routing entries. You can use the display pim ipv6
routing-table command to view the PIM routing table information on each router. For example:
(4001::100, FF3E::101)
UpTime: 00:00:11
1-42
1: Ethernet1/0

(4001::100, FF3E::101)
UpTime: 00:08:02
1: Serial2/0
IPv6 PIM Configuration Examples (On Switches)

IPv6 PIM-DM Configuration Example
entire IPv6 PIM domain operates in the dense mode.
VLAN-interface 300.
z Switch A connects to N1 through VLAN-interface 100, and to Switch D through VLAN-interface
103.
z Switch B and Switch C connect to N2 through their respective VLAN-interface 200, and to Switch D
z MLDv1 is to run between Switch A and N1, and between Switch B/Switch C and N2.
1-43
Network diagram
Figure 1-11 Network diagram for IPv6 PIM-DM configuration (on switches)
N1
Ethernet
03
t1
-in
an
Vl
03
t1
-in
N2
an
Ethernet
Vl
Vl
an
-in
Ethernet
t1
02 Vla
n-
in
t1
02

Switch A Vlan-int100 1001::1/64 Switch D Vlan-int300 4001::1/64
Vlan-int103 1002::1/64 Vlan-int103 1002::2/64
Switch B Vlan-int200 2001::1/64 Vlan-int101 2002::2/64
Vlan-int101 2002::1/64 Vlan-int102 3001::2/64
Switch C Vlan-int200 2001::2/64
Vlan-int102 3001::1/64
Enable IPv6 forwarding on each switch and configure the IPv6 address and prefix length for each
Configure OSPFv3 for interoperation among the switches in the PIM-DM domain. Ensure the
among the switches through an IPv6 unicast routing protocol. Detailed configuration steps are omitted
here.
2) Enable IPv6 multicast routing, and enable IPv6 PIM-DM and MLD
# Enable IPv6 multicast routing on Switch A, enable IPv6 PIM-DM on each interface, and enable MLD
on VLAN-interface 100, which connects Switch A to N1.
1-44

# Enable IPv6 multicast routing on Switch D, and enable IPv6 PIM-DM on each interface.
[SwitchD] multicast ipv6 routing-enable
[SwitchD-Vlan-interface300] pim ipv6 dm
# View the IPv6 PIM configuration information on Switch D.
[SwitchD] display pim ipv6 interface
Vlan300 0 30 1 4001::1
(local)
Vlan103 0 30 1 1002::2
(local)
Vlan101 1 30 1 2002::2
(local)
Vlan102 1 30 1 3001::2
(local)
Use the display pim ipv6 neighbor command to view the IPv6 PIM neighboring relationships among
the switches. For example:
# View the IPv6 PIM neighboring relationships on Switch D.
[SwitchD] display pim ipv6 neighbor

1002::1 Vlan103 00:04:00 00:01:29 1
2002::1 Vlan101 00:04:16 00:01:29 3
3001::1 Vlan102 00:03:54 00:01:17 5
Assume that Host A needs to receive the information addressed to IPv6 multicast group G (FF0E::101).
After IPv6 multicast source S (4001::100/64) sends IPv6 multicast packets to the IPv6 multicast group G,
an SPT is established through traffic flooding. Switches on the SPT path (Switch A and Switch D) have
their (S, G) entries. Host A sends an MLD report to Switch A to join IPv6 multicast group G, and a (*, G)
1-45
entry is generated on Switch A. You can use the display pim IPv6 routing-table command to view the
IPv6 PIM routing table information on each switch. For example:
# View the IPv6 PIM multicast routing table information on Switch A.
[SwitchA] display pim ipv6 routing-table
(*, FF0E::101)
UpTime: 00:01:24
Protocol: mld, UpTime: 00:01:20, Expires: never
(4001::100, FF0E::101)
UpTime: 00:01:20

# View the IPv6 PIM multicast routing table information on Switch D.
(4001::100, FF0E::101)
UpTime: 00:02:19
1-46
IPv6 PIM-SM Configuration Example
entire PIM domain operates in the sparse mode.
z Switch D connects to the network that comprises the IPv6 multicast source (Source) through
VLAN-interface 300.
z Switch A connects to N1 through VLAN-interface 100, and to Switch D and Switch E through
VLAN-interface 101 and VLAN-interface 102 respectively.
z Switch B and Switch C connect to N2 through their respective VLAN-interface 200, and to Switch E
z Switch E connects to Switch A, Switch B, Switch C and Switch D, and its VLAN-interface 102
interface acts a C-BSR and a C-RP, with the range of IPv6 multicast groups served by the C-RP
being FF0E::101/64.
Network diagram
Figure 1-12 Network diagram for IPv6 PIM-SM configuration (on switches)
Receiver
N1
Ethernet
Host A
Switch A
Vlan-int100
01
Vlan-int102
t1
Host B
-in
an
Vl
01
t1
N2
-in
an
Vlan-int102 Receiver
Ethernet
Vl

Source Vlan-int105 Vlan-int103
Switch D Switch E Vlan-int104 Switch B
Host C
Ethernet
4001::100/64
Vlan-int104
Vlan-int200
IPv6 PIM-SM Host D
Switch C

Vlan-int101 1002::1/64 Vlan-int101 1002::2/64
Vlan-int102 1003::1/64 Vlan-int105 4002::1/64
Switch B Vlan-int200 2001::1/64 Switch E Vlan-int104 3001::2/64
Vlan-int103 2002::1/64 Vlan-int103 2002::2/64
Switch C Vlan-int200 2001::2/64 Vlan-int102 1003::2/64
Vlan-int104 3001::1/64 Vlan-int105 4002::2/64
1-47
Configure OSPFv3 for interoperation among the switches in the IPv6 PIM-SM domain. Ensure the
network-layer interoperation in the IPv6 PIM-DM domain and enable dynamic update of routing
information among the switches through an IPv6 unicast routing protocol. Detailed configuration steps
are omitted here.
# Enable IPv6 multicast routing on Switch A, enable IPv6 PIM-SM on each interface, and enable MLD
on VLAN-interface 300, which connects Switch A to N1.
and Switch E is also similar to that on Switch A except that it is not necessary to enable MLD on the
# Configure the RP service range and the C-BSR and C-RP locations on Switch E.
[SwitchE] acl ipv6 number 2005
[SwitchE-acl6-basic-2005] rule permit source ff0e::101 64
[SwitchE-acl6-basic-2005] quit
[SwitchE] pim ipv6
[SwitchE-pim6] c-bsr 1003::2
[SwitchE-pim6] c-rp 1003::2 group-policy 2005
[SwitchE-pim6] quit
# View the IPv6 PIM information on all interfaces of Switch A.
[SwitchA] display pim ipv6 interface
Vlan100 0 30 1 1001::1
(local)
1-48
Vlan101 1 30 1 1002::2
Vlan102 1 30 1 1003::2
To view the BSR election information and the locally configured C-RP information in effect on a switch,
use the display pim ipv6 bsr-info command. For example:
# View the BSR information and the locally configured C-RP information in effect on Switch A.
[SwitchA] display pim ipv6 bsr-info
Priority: 0
Uptime: 00:04:22
Expires: 00:01:46
# View the BSR information and the locally configured C-RP information in effect on Switch E.
[SwitchE] display pim ipv6 bsr-info
Priority: 0
State: Elected
Uptime: 00:01:10
Candidate BSR Address: 1003::2
Priority: 0
State: Elected
Candidate RP: 1003::2(Vlan-interface102)
Priority: 0
HoldTime: 130
To view the RP information discovered on a switch, use the display pim ipv6 rp-info command. For
example:
# View the RP information on Switch A.
[SwitchA] display pim ipv6 rp-info
prefix/prefix length: FF0E::101/64
RP: 1003::2
Priority: 0
HoldTime: 130
Uptime: 00:05:19
Expires: 00:02:11
Assume that Host A needs to receive information addressed to the IPv6 multicast group G (FF0E::101).
An RPT will be built between Switch A and Switch E. When the IPv6 multicast source S (4001::100/64)
registers with the RP, an SPT will be built between Switch D and Switch E. Upon receiving IPv6
multicast data, Switch A immediately switches from the RPT to the SPT. Switches on the RPT path
(Switch A and Switch E) have a (*, G) entry, while switches on the SPT path (Switch A and Switch D)
1-49
have an (S, G) entry. You can use the display pim ipv6 routing-table command to view the PIM
routing table information on the switches. For example:
(*, FF0E::101)
RP: 1003::2
UpTime: 00:03:45
(4001::100, FF0E::101)
RP: 1003::2
UpTime: 00:02:15

# View the IPv6 PIM multicast routing table information on Switch D.
(4001::100, FF0E::101)
RP: 1003::2
UpTime: 00:14:44
# View the IPv6 PIM multicast routing table information on Switch E.
1-50
[SwitchE] display pim ipv6 routing-table
(*, FF0E::101)
RP: 1003::2 (local)
UpTime: 00:16:56
IPv6 PIM-SSM Configuration Example
z Switch D connects to the network that comprises the IPv6 multicast source (Source) through
VLAN-interface 300.
z Switch A connects to N1 through VLAN-interface 100, and to Switch D and Switch E through
VLAN-interface 101 and VLAN-interface 102 respectively.
z Switch B and Switch C connect to N2 through their respective VLAN-interface 200, and to Switch E
z Switch E connects to Switch A, Switch B, Switch C and Switch D.
z The SSM group range is FF3E::/64.
1-51
Network diagram
Figure 1-13 Network diagram for IPv6 PIM-SSM configuration (on switches)
Receiver
N1
Ethernet
Host A
Switch A
Vlan-int100
01
Vlan-int102
t1
Host B
-in
an
Vl
01
t1
N2
-in
an
Ethernet
Vl

Source Vlan-int105 Vlan-int103
Switch D Switch E Vlan-int104 Switch B
Host C
Ethernet
4001::100/64
Vlan-int104
Vlan-int200
IPv6 PIM-SM Host D
Switch C

Vlan-int101 1002::1/64 Vlan-int101 1002::2/64
Vlan-int102 1003::1/64 Vlan-int105 4002::1/64
Switch B Vlan-int200 2001::1/64 Switch E Vlan-int104 3001::2/64
Vlan-int103 2002::1/64 Vlan-int103 2002::2/64
Switch C Vlan-int200 2001::2/64 Vlan-int102 1003::2/64
Vlan-int104 3001::1/64 Vlan-int105 4002::2/64
Configure OSPFv3 for interoperation among the switches in the PIM-SM domain. Ensure the
network-layer interoperation in the IPv6 PIM-SM domain and enable dynamic update of routing
information among the switches through an IPv6 unicast routing protocol. Detailed configuration steps
are omitted here.
# Enable IPv6 multicast routing on Switch A, enable IPv6 PIM-SM on each interface, and run MLDv2 on
VLAN-interface 300, which connects Switch A to N1.
[SwitchA-Vlan-interface100] mld version 2
1-52
and Switch E is also similar to that on Switch A except that it is not necessary to enable MLD on the
# Configure the IPv6 SSM group range to be FF3E::/64 on Switch A.
[SwitchA] acl ipv6 number 2000
[SwitchA-acl6-basic-2000] rule permit source ff3e:: 64
[SwitchA-acl6-basic-2000] quit
[SwitchA] pim ipv6
[SwitchA-pim6] ssm-policy 2000
[SwitchA-pim6] quit
The configuration on Switch B, Switch C, Switch D, and Switch E is similar to that on Switch A.
# View the IPv6 PIM configuration information on Switch A.
[SwitchA] display pim ipv6 interface
Vlan100 0 30 1 1001::1
(local)
Vlan101 1 30 1 1002::2
Vlan102 1 30 1 1003::2
Assume that Host A needs to receive the information a specific IPv6 multicast source S (4001::100/64)
sends to IPv6 multicast group G (FF3E::101). Switch A builds an SPT toward the IPv6 multicast source.
Switches on the SPT path (Switch A and Switch D) have generated an (S, G) entry, while Switch E,
which is not on the SPT path, does not have IPv6 multicast routing entries. You can use the display pim
ipv6 routing-table command to view the IPv6 PIM routing table information on each switch. For
example:
(4001::100, FF3E::101)
UpTime: 00:00:11
1-53

# View the IPv6 PIM multicast routing table information on Switch B.
(4001::100, FF3E::101)
UpTime: 00:08:02
Troubleshooting IPv6 PIM Configuration

Failure of Building a Multicast Distribution Tree Correctly
Symptom
None of the routers in the network (including routers directly connected with IPv6 multicast sources and
receivers) has IPv6 multicast forwarding entries. That is, a multicast distribution tree cannot be built
correctly and clients cannot receive IPv6 multicast data.
Analysis
z An IPv6 PIM routing entry is created based on an IPv6 unicast route, whichever IPv6 PIM mode is
running. Multicast works only when unicast does.
z IPv6 PIM must be enabled on the RPF interface. An RPF neighbor must be an IPv6 PIM neighbor
as well. If IPv6 PIM is not enabled on the RPF interface or the RPF neighbor, the establishment of
a multicast distribution tree will surely fail, resulting in abnormal multicast forwarding.
z IPv6 PIM requires that the same IPv6 PIM mode, namely DM or SM, must run on the entire network.
Otherwise, the establishment of a multicast distribution tree will surely fail, resulting in abnormal
multicast forwarding.
Solution
1) Check IPv6 unicast routes. Use the display ipv6 routing-table command to check whether a
unicast route exists to the IPv6 multicast source or the RP.
2) Check that the RPF interface is IPv6 PIM enabled. Use the display pim ipv6 interface command
to view the IPv6 PIM information on each interface. If IPv6 PIM is not enabled on the interface, use
the pim ipv6 dm or pim ipv6 sm command to enable IPv6 PIM.
1-54
3) Check that the RPF neighbor is an IPv6 PIM neighbor. Use the display pim ipv6 neighbor
command to view the PIM neighbor information.
4) Check that IPv6 PIM and MLD are enabled on the interfaces directly connecting to the IPv6
multicast source and to the receiver.
5) Check that the same IPv6 PIM mode is enabled on related interfaces. Use the display pim ipv6
interface verbose command to check whether the same PIM mode is enabled on the RPF
interface and the corresponding interface of the RPF neighbor router.
6) Check that the same IPv6 PIM mode is enabled on all the routers in the entire network. Use the
display current-configuration command to check the IPv6 PIM mode information on each
interface. Make sure that the same IPv6 PIM mode is enabled on all the routers: IPv6 PIM-SM on
all routers, or IPv6 PIM-DM on all routers.
IPv6 Multicast Data Abnormally Terminated on an Intermediate Router
Symptom
An intermediate router can receive IPv6 multicast data successfully, but the data cannot reach the last
hop router. An interface on the intermediate router receives data but no corresponding (S, G) entry is
created in the IPv6 PIM routing table.
Analysis
z When a router receives an IPv6 multicast packet, it decrements the hop limit value of the IPv6
multicast packet by 1 and recalculates the checksum value. The router then forwards the packet to
all outgoing interfaces. If the multicast ipv6 minimum-hoplimit command is configured on the
outgoing interfaces, the hop limit value of the packet must be larger than the configured minimum
hop limit value; otherwise, the packet will be discarded.
z If an IPv6 multicast forwarding boundary has been configured through the multicast ipv6
boundary command, any IPv6 multicast packet will be kept from crossing the boundary, and
therefore no routing entry can be created in the IPv6 PIM routing table.
z In addition, the source-policy command is used to filter received IPv6 multicast packets. If the
IPv6 multicast data fails to pass the ACL rule defined in this command, IPv6 PIM cannot create the
route entry, either.
Solution
1) Check the minimum hop limit value for IPv6 multicast forwarding. Use the display
current-configuration command to check the minimum hop limit value for multicast forwarding.
Increase the hop limit value or remove the multicast ipv6 minimum-hoplimit command
configured on the interface.
2) Check the IPv6 multicast forwarding boundary configuration. Use the display
current-configuration command to check the IPv6 multicast forwarding boundary settings. Use
the multicast ipv6 boundary command to change the IPv6 multicast forwarding boundary
settings.
3) Check the IPv6 multicast filter configuration. Use the display current-configuration command to
check the IPv6 multicast filter configuration. Change the IPv6 ACL rule defined in the
source-policy command so that the source/group address of the IPv6 multicast data can pass
ACL filtering.
1-55
RPs Unable to Join SPT in IPv6 PIM-SM
Symptom
An RPT cannot be established correctly, or the RPs cannot join the SPT to the IPv6 multicast source.
Analysis
z As the core of an IPv6 PIM-SM domain, the RPs serves specific IPv6 multicast groups. Multiple
RPs can coexist in a network. Make sure that the RP information on all routers is exactly the same,
and a specific group is mapped to the same RP. Otherwise, IPv6 multicast will fail.
z In the case of the static RP mechanism, the same RP address must be configured on all the routers
in the entire network, including static RPs, by means of the static RP command. Otherwise, IPv6
multicast will fail.
Solution
1) Check that a route is available to the RP. Carry out the display ipv6 routing-table command to
check whether a route is available on each router to the RP.
2) Check the dynamic RP information. Use the display pim ipv6 rp-info command to check whether
the RP information is consistent on all routers. In the case of inconsistent RP information, configure
consistent RP address on all the routers.
3) Check the static RP configuration. Carry out the display pim ipv6 rp-info command to check
whether the same RP address has been configured on all the routers throughout the network.
RPT Establishment Failure or Source Registration Failure in IPv6 PIM-SM
Symptom
C-RPs cannot unicast advertise messages to the BSR. The BSR does not advertise bootstrap
messages containing C-RP information and has no unicast route to any C-RP. An RPT cannot be
established correctly, or the DR cannot perform source register with the RP.
Analysis
z C-RPs periodically send advertisement messages to the BSR by unicast. If a C-RP does not have
a route to the BSR, the BSR will be unable to receive the advertisements from the C-RP, and
therefore the bootstrap messages of the BSR will not contain the information about that C-RP.
z The RP is the core of an IPv6 PIM-SM domain. Make sure that the RP information on all routers is
exactly the same, a specific group is mapped to the same RP, and a unicast route is available to
the RP.
Solution
1) Check whether routes to C-RPs, the RP and the BSR are available. Carry out the display ipv6
routing-table command to check whether routes are available on each router to the RP and the
BSR, and whether a route is available between the RP and the BSR. Make sure that each C-RP
has a unicast route to the BSR, the BSR has a unicast route to each C-RP, and all the routers in the
entire network have a unicast route to the RP.
2) Check the RP and BSR information. IPv6 PIM-SM needs the support of the RP and BSR. Use the
display pim ipv6 bsr-info command to check whether the BSR information is available on each
router, and then use the display pim ipv6 rp-info command to check whether the RP information
is correct.
1-56
3) View the IPv6 PIM neighboring relationships. Use the display pim ipv6 neighbor command to
check whether the normal neighboring relationships have been established among the routers.
1-57
Table of Contents
1 Multicast VPN Configuration 1-1

Multicast VPN Overview1-1
Introduction to MPLS L3VPN 1-1
Introduction to Multicast VPN 1-2
Introduction to MD-VPN1-3
How MD-VPN Works1-7
Share-MDT Establishment 1-7
Share-MDT-Based Deliver of Multicast Protocol Packets1-9
Share-MDT-Based Delivery of Multicast Data Packets1-11
MDT Switchover 1-13
Multi-AS MD VPN 1-14
MD-VPN Configuration Task List 1-15
Configuring MD-VPN1-15
Enabling IP Multicast Routing in a VPN Instance 1-16
Configuring a Share-Group and an MTI Binding1-16
Configuring MDT Switchover Parameters 1-17
Enabling Switch-Group Reuse Logging 1-18
Displaying and Maintaining MD-VPN1-18
MD-VPN Configuration Examples (On Routers)1-19
Single-AS MD VPN configuration1-19
Multi-AS MD VPN Configuration 1-31
MD VPN Configuration Examples (On Switches) 1-44
Single-AS MD VPN Configuration 1-44
Multi-AS MD VPN Configuration 1-57
Troubleshooting MD-VPN Configuration1-71
Unable to Establish a Share-MDT1-71
Unable to Build an MVRF 1-71
i
1 Multicast VPN Configuration
When configuring multicast VPN, go to the following sections for the information you are interested in:
z Multicast VPN Overview
z How MD-VPN Works
z MD-VPN Configuration Task List
z Displaying and Maintaining MD-VPN
z MD-VPN Configuration Examples (On Routers)
z Troubleshooting MD-VPN Configuration
Multicast VPN Overview

Introduction to MPLS L3VPN
For details about MPLS L3VPN, refer to MPLS L3VPN Configuration in the MPLS Volume.
Multicast VPN is a technique that implements multicast delivery in MPLS L3VPN networks. An MPLS
L3VPN is a virtual private network (VPN) implemented based on the extension technologies of the
Border Gateway Protocol (BGP) and Multiprotocol Label Switching (MPLS). It comprises a set of
customer sites that are interconnected only by means of an MPLS provider backbone network. The
VPN can be regarded as a set of policies that control the interconnections between these sites.
1-1
Figure 1-1 Typical application of MPLS L3VPNs
VPN A VPN B
Site 1 Site 2
PE 1
CE 1 CE 2
CPE
layer
Edge
layer
P1 P2
VPN B VPN A
Core
Site 6 Site 3
CE 6 layer CE 3
PE 3 P3 PE 2
CE 5 CE 4
VPN A VPN B
Site 5 Site 4
As shown in Figure 1-1, VPN A comprises Site 1, Site 3 and Site 5, while VPN B comprises Site 2, Site
4 and Site 6. A VPN involves the following three types of devices:
z Provider (P) device: device in the core of the provider backbone network. A P device does not
directly interface with CE devices, but it implements MPLS forwarding.
z Provider edge (PE) device: edge device in the provider backbone network. Directly interfacing with
one or more CE devices, a PE device processes VPN routing as a main MPLS L3VPN
implementer.
z Customer edge (CE) device: edge device on a customer network. A CE device can be a router, a
switch, or a host, that implements route distribution on the customer network.
In an MPLS L3VPN environment, between any two sites that belong to the same VPN, packets are
transmitted labeled across the public network. The PE device at the entrance to the provider backbone
attaches two labels to the packets, one inner label and the other outer label:
z Outer label: the label used for switching within the backbone, representing a label switched path
(LSP) from the local PE to the peer PE. With this label, a packet can arrive to the peer PE along the
LSP.
z Inner label: The inner label represents an LSP between two CE devices interconnected over the
backbone network. It identifies the site to which the packet belongs. The PE forwards the packet to
the target CE based on the inner label.
Introduction to Multicast VPN
Figure 1-2 shows an example of multicast over an MPLS VPNs network, which carries three
independent multicast services the public instance, VPN instance A, and VPN instance B. A PE
multicast device at the edge of the public network supports multiple instances, equivalent to multiple
independent multicast devices. Each instance corresponds to a plane, and all these planes are isolated
from one another. For example, Figure 1-1, shows three instances are running on PE1: They are the
1-2
public instance, VPN instance A, and VPN instance B. These three instances can be regarded as three
independent virtual devices, which are PE 1, PE 1, and PE 1, each virtual device corresponding to a
plane, as shown in Figure 1-2.
Figure 1-2 Multicast in multiple VPN instances
With multicast VPN, when a multicast source in VPN A sends a multicast stream to a multicast group, of
all possible receivers on the network for that group, only those belong to VPN A, namely in Site 1, Site
3 or Site 5, can receive the multicast stream. The stream is multicast in these sites and in the public
network.
The prerequisites for implementing multicast VPN are as follows:
1) The support for VPN instance based multicast within each site,
2) The support for public instance based multicast within the public network, and
3) PE devices that support multi-instance multicast:
z Interfacing with sites and supporting VPN instance based multicast,
z Interfacing with the public network and supporting public instance based multicast, and
z Supporting information exchange and data conversion between the public instance and the VPN
instances.
Introduction to MD-VPN
For details about the concepts of Protocol Independent Multicast (PIM), bootstrap router (BSR),
candidate-BSR (C-BSR), rendezvous point (RP), candidate RP (C-RP), shortest path tree (SPT) and
rendezvous point tree (RPT), refer to PIM Configuration in the IP Multicast Volume.
1-3
Comware implements multicast VPN by means of the multicast domain (MD) method. This multicast
VPN implementation is referred to as MD-VPN.
The most significant advantage of MD-VPN is that it requires only the PE devices to support multiple
instances. Multicast VPN can be implemented without upgrading any CE devices and P devices, and
without changing the original PIM configuration of the CE devices and the P device. In other words, the
MD-VPN solution is transparent to the CE devices and the P device.
Basic concepts in MD-VPN
The basic concepts involved in MD-VPN are described in Table 1-1.
Table 1-1 Basic concepts in MD-VPN
Concept Description
An MD is a set of interconnected MVRFs. Each MD uniquely
Multicast domain (MD) corresponds to a multicast-capable VPN, and all the PE devices
interfacing with this VPN belong to this MD.
An MDT is a multicast distribution tree between all PE devices in
Multicast distribution tree (MDT) the same VPN. There are two kinds of MDTs: share-MDT and
switch-MDT.
An MT is a tunnel that interconnects all MVRFs in the MD for
Multicast tunnel (MT)
delivering private network traffic within the MD.
An MTI is the entrance to or exit of an MT, equivalent to an
entrance to or exit of an MD. An MTI handles only multicast
packets but not unicast packets. An MTI is automatically created
with the configuration of a share-group and MTI binding for a
Multicast tunnel interface (MTI)
VPN instance. An MVRF uses the MTI to access the MD. In the
perspective of an MVRF, an MTI is like a LAN interface, while the
MD is like a LAN network, to which all the PE devices are
attached.
With Layer 3 multicast enabled, a VPN instance also maintains
its multicast routing and forwarding table. The unicast routing and
forwarding table and the multicast router and forwarding table for
Multicast VPN routing and the same VPN instance are referred to as an MVRF in general.
forwarding (MVRF) MVRFs on different PEs join the same MD and are
interconnected by means of the multicast tunnel (MT)
automatically established in the MD to enable multicast service
between different sites and form a multicast VPN network.
In the public network, each MD is assigned an independent
multicast address, called share-group. A share-group is the
Share-group
unique identifier of an MD in the public network. It is used to build
a share-MDT corresponding to the MD in the public network.
A share-MDT is an MDT that uses a share-group as its group
address. In a VPN, the share-MDT is uniquely identified by the
Share-multicast distribution tree share-group. A share-MDT is automatically created after
(Share-MDT) configuration and will always exist in the public network,
regardless of the presence of any actual multicast services in the
public network or the VPN.
A switch-MDT is an MDT that uses a switch-group as it group
address. At MDT switchover, PE devices with receivers
Switch-multicast distribution tree
downstream join a switch-group, forming a switch-MDT, along
(Switch-MDT)
which the ingress PE forward multicast traffic of a specific VPN in
the public network.
1-4
Concept Description
When the multicast traffic of a VPN reaches or exceeds a
threshold, the ingress PE device assigns it an independent
multicast address called switch-group, and notifies the other PE
Switch-group
devices that they should use that address to forward the
multicast traffic for that VPN. This initiates a switchover to the
switch-MDT.
At MDT switchover, an address (namely, switch-group address)
is chosen from the switch-group-pool. The multicast packets for
the VPN that enter the public network at the PE device are to be
Switch-group-pool
encapsulated using that address. The switch-group-pool of a
VPN must not overlap that of another VPN, and must not contain
the share-group of another VPN.
VPN routing and forwarding Each VPN instance maintains its unicast routing and forwarding
(VRF) table, which is referred to as VRF.
Introduction to MD-VPN
Main points in the implementation of MD-VPN are as follows:

1) The public network of the service provider supports multicast. The PE devices need to support the
public instance and multiple VPN instances, each instance running PIM independently. Private
network multicast traffic between the PE devices and the CE devices is transmitted on a
per-VPN-instance basis, while the public network multicast traffic between the PE devices and the
P devices is transmitted through the public instance.
2) Logically, an MD defines the transmission range of the multicast traffic of a specific VPN over the
public network; physically, an MD identifies all the PE devices that support that VPN in the public
network. Different VPN instances correspond to different MDs. As shown in Figure 1-2, the ellipse
area in the center of each VPN instance plane represents an MD, which serves that particular VPN.
All the private network multicast traffic in that VPN is transmitted within that MD.
3) Inside an MD, all the private traffic is transmitted through the MT. The process of multicast traffic
transmission through an MT is as follows: the local PE device encapsulates the private network
data into a public network packet, which is then forwarded in the public network, and the remote
PE device decapsulates the packet to turn it back into a private packet.
4) The local PE device sends out private network data through the MTI, and the remote PE devices
receive the private data through the MTI. As shown in Figure 1-3, an MD can be thought of as a
private data transmission pool, and an MTI can be thought of an entrance/exit of the pool. The local
PE device puts the private data into the transmission pool (the MD) through the entrance (MTI),
and the transmission pool automatically duplicates the private data and transmits the data to each
exit (MTI) of the transmission pool, so that any remote PE device that needs the data can get it
from the respective exit (MTI).
1-5
Figure 1-3 Relationship between PIM in the public instance and an MD in a VPN instance
5) Each VPN instance is assigned a unique share-group address. The private network data is
transparent to the public network. A PE device encapsulates any private network multicast packet
within a normal public network multicast packet, no matter what multicast group the private
network packet is destined for and whether it is a protocol packet or a data packet, and uses the
share-group as the public network multicast group for the packet. Then, the PE sends the public
network multicast packet onto the public network.
6) A share-group corresponds to a unique MD; for each share-group, a unique share-MDT is
constructed by leveraging the public network resources for multicast data forwarding. All the
private network multicast packets transmitted in this VPN are forwarded along this share-MDT, no
matter at which PE device they entered the public network.
7) A share-group is assigned a unique switch-group-pool for MDT switchover. When the rate of a
private network multicast stream that entered the public network at a PE device exceeds the
switchover threshold, the PE chooses an idle address (namely, switch-group) from the
switch-group-pool, and encapsulates the multicast packets for that VPN using that address.
8) All the ingress PE devices in the network monitor the forwarding rate on the share-MDT. When the
rate of a VPN multicast stream that entered the public network at a specific PE device exceeds the
threshold, the PE device initiates an MDT switchover message to the downstream along the
share-MDT, so that a switch-MDT is built using the switch-group between that PE device and the
remote PE devices with receivers downstream. Then, after a switch-delay period has passed, an
MDT switchover process takes place: all private network multicast packets that have entered the
public network at that PE device are encapsulated into public network multicast packets using the
switch-group, instead of using the share-group, so that they are switched from the share-MDT to
the switch-MDT.
z There is a one-to-one relationship between VPN, MD, MTI, share-group, and switch-group-pool.
z For more detailed description about MDT switchover, refer to MDT Switchover.
1-6
PIM neighboring relationships in MD-VPN
Figure 1-4 PIM neighboring relationships in MD-VPN
CE 1
PE-P neighbors
PE-PE neighbors
PE-CE neighbors
PE 1
CE 3 PE 3 PE 2 CE 2
MD
PIM neighboring relationships are established between two or more directly interconnected devices on
the same subnet. As shown in Figure 1-4, there are three types of PIM neighboring relationships in
MD-VPN, as follows:
z PE-P neighboring relationship: PIM neighboring relationship established between the public
instance interface on a PE device and an interface on the P device across the link.
z PE-PE neighboring relationship: PIM neighboring relationship established after a VPN instance on
a PE device receives a PIM hello from a VPN instance on a remote PE device through an MTI.
z PE-CE neighboring relationship: PIM neighboring relationship established between a
VPN-instance-associated interface on a PE device and an interface on a peer CE device.
The protocols/standards related to multicast VPN are as follows:

z RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)
z draft-rosen-vpn-mcast-08: Multicast in MPLS/BGP IP VPNs
How MD-VPN Works

Share-MDT Establishment
For a VPN instance, multicast data transmission in the public network is transparent. The seamless
connection for VPN data transmission is completed at the MTI on the ingress PE device. All that is
known to the VPN instance is that the VPN data is sent out the MTI and then the remote site can
receive the data through the MTI. Actually, when the remote site receives the multicast data, the data
transmission has come through a complicated process, that is, the MDT transmission process.
The multicast routing protocol running in the public network can be either PIM-SM or PIM-DM. The
process of creating a share-MDT is different in these two PIM modes.
1-7
Share-MDT establishment in a PIM-SM network
Figure 1-5 Share-MDT establishment in a PIM-SM network
As shown in Figure 1-5, the process of establishing a share-MDT in a PIM-SM network is as follows:
1) The public instance on PE 1 initiates a join to the public network RP, with the share-group address
as the multicast group address in the join message, and a (*, 239.1.1.1) state entry is created on
each device along the path in the public network. The join process initiated by PE 2 and PE 3 is
similar. Finally, an RPT is established in the MD, with the public network RP as the root and PE 1,
PE 2 and PE 3 as leaves.
2) The public instance on PE 1 registers the multicast source with the public network RP, with the
IBGP interface address (namely the interface address used to establish the IBGP peer) as the
multicast source address and the share-group address as the multicast group address in the
register message, and a (11.1.1.1, 239.1.1.1) state entry is created on each device along the path
in the public network. The register process initiated by PE 2 and PE 3 is similar. Finally, three SPTs
between the PE devices and the RP are established in the MD.
In the PIM-SM network, the RPT, namely the (*, 239.1.1.1) tree, and the three independent SPTs
constitute a share-MDT.
1-8
Share-MDT establishment in a PIM-DM network
Figure 1-6 Share-MDT establishment in a PIM-DM network
As shown in Figure 1-6, PIM-DM is running in the public network. The share-MDT establishment is as
follows: PE 1 initiates a flood-prune process in the entire public network, with the IBGP interface
address as the multicast source address, and the share-group address as the multicast group address,
of which all the other PE devices that are running VPN instance A (PE 2 and PE 3) are group members,
so that a (11.1.1.1, 239.1.1.1) state entry is created on each device along the path in the public network.
This forms an SPT with PE 1 as the root, and PE 2 and PE 3 as leaves. The flood-prune process
initiated by PE 2 and PE 3 is similar. Finally, three independent SPTs are established in the MD.
In the PIM-DM network, these independent SPTs constitute a share-MDT.
Characteristics of a share-MDT
As discussed above, a share-MDT is characterized as follows, no matter what PIM mode is running in
the public network:
z All PE devices that support this VPN instance (PE 1, PE 2, and PE 3 in this example) join the
share-MDT.
z All VPN multicast packets that belong to this VPN, including protocol packets and data packets,
are forwarded along the share-MDT to every PE device in the public network, even if they have no
active receivers downstream.
Share-MDT-Based Deliver of Multicast Protocol Packets
Where a multicast source and the receivers are located in different sites of a VPN, multicast protocol
packets must be transmitted across the public network. Protocol packets are encapsulated into normal
multicast data packets for the public network on the local PE device, transmitted along the share-MDT,
and then decapsulated on the remote PE device to go into the normal protocol procedure. Finally a
distribution tree is established across the public network.
1-9
All interfaces that belong to the same VPN, including those interfaces with VPN instance bindings and
the MTI on PE devices, must run the same PIM mode.
1) If PIM-DM is running in the VPNs network, a flood-prune process needs to be initiated across the
public network to create SPTs.
2) On a VPNs network running PIM-SM:
z If the receivers and the VPN RP are in different sites, joins need to be initiated across the public
network to establish an RPT.
z If the multicast source and the VPN RP are in different sites, registrations need to be initiated
across the public network to establish SPTs.
The following example explains how multicast protocol packets are delivered based on the share-MDT
while PIM-SM is running in both the public network and the VPNs network, with receivers and the VPN
RP located in different sites.
As shown in Figure 1-7, PIM-SM is running in both the public network and the VPNs network, Receiver
for the VPN multicast group G (225.1.1.1) in Site 2 is attached to CE 2, while CE 1 of Site 1 acts as the
RP for group G (225.1.1.1); the share-group address used to forward public network data is 239.1.1.1.
Figure 1-7 Transmission of multicast protocol packets
IBGP: 11.1.3.1/24
PE 3
Source
Receiver
RP
P
CE 1 PE 1 MD PE 2 CE 2
Site 1 IBGP: 11.1.1.1/24 IBGP: 11.1.2.1/24 Site 2
S: 192.1.1.1/24 Public instance IBGP peers

G: 255.1.1.1 VPN instance join (*, 255.1.1.1)
Share-Group: 239.1.1.1 Public instance join (11.1.2.1, 239.1.1.1)
The work process of multicast protocol packets is as follows:

1) Receiver sends an IGMP membership report for multicast group G to CE 2. CE 2 creates a local (*,
225.1.1.1) state entry and sends a join message to the VPN RP (CE 1).
1-10
2) Upon receiving the join message from CE 2, the VPN instance on PE 2 creates a (*, 225.1.1.1)
state entry with the upstream interface being the MTI, and then PE 2 processes the join message.
Now, the VPN instance on PE 2 considers that the join message has been sent out the MTI.
3) PE 2 encapsulates the join message by means of Generic Routing Encapsulation (GRE), with its
IBGP interface address as the multicast source address and the share-group address as the
multicast group address, to convert it into a normal, public network multicast data packet (11.1.2.1,
239.1.1.1), and then passes the packet to the public instance on PE 2 to have it forwarded to the
public network.
4) The multicast data packet (11.1.2.1, 239.1.1.1) is forwarded to the public instance on all the PE
devices along the share-MDT. Upon receiving this packet, every PE device decapsulates it to turn
it back into a join message to be sent to the VPN RP. Then, each PE device checks the join
message. If any PE device finds that the VPN RP is in the site it interfaces with, it passes the join
message to the VPN instance on it; otherwise, it discards the join message.
5) When receiving the join message, the VPN instance on PE 1 considers that it received the
message from the MTI. PE 1 creates a local (*, 225.1.1.1) state entry, with the downstream
interface being the MTI and the upstream interface being the one that leads to CE 1. At the same
time, it sends a join message to CE 1, which is the VPN RP.
6) Upon receiving the join message from the VPN instance on PE 1, CE 1 creates a local (*, 225.1.1.1)
state entry or updates the entry if it already exists. By now, the construction of an RPT across the
public network is completed.
For details about GRE, refer to GRE Configuration in the VPN Volume.
Share-MDT-Based Delivery of Multicast Data Packets
After the share-MDT is established, the private network multicast data flows to the receivers in each site
along the distribution tree. The private network multicast packets are encapsulated into normal public
network multicast packets on the local PE device, transmitted along the share-MDT, and then
decapsulated on the remote PE device and transmitted in the private network.
1) If PIM-DM is running in the VPNs network, the customer multicast traffic flows along the SPTs
across the public network.
2) On a VPNs network running PIM-SM (before RPT-to-SPT switchover only):
z If the receivers and the VPN RP are in different sites, the customer multicast traffic flows along the
RPT across the public network.
z If the multicast source and the VPN RP are in different sites, the customer multicast traffic flows
along the SPTs across the public network.
1-11
z For detailed description of RPT-to-SPT switchover, refer to PIM Configuration in the IP Multicast
Volume.
z The following example explains how multicast data packets are delivered based on the share-MDT
while PIM-DM is running in both the public network and the VPNs network.
As shown in Figure 1-8, PIM-DM is running in both the public network and the VPNs network, Receiver
of the VPN multicast group G (225.1.1.1) in Site 2 is attached to CE 2, and Source in Site 1 sends
multicast data to multicast group G); the share-group address used to forward public network multicast
data is 239.1.1.1.
Figure 1-8 Delivery of multicast data packets
The private network multicast traffic is delivered across the public network as follows.
1) Source sends customer multicast data (192.1.1.1, 225.1.1.1) to CE 1.
2) CE 1 forwards the private network multicast data along an SPT to CE 1, and the VPN instance on
PE 1 checks the MVRF. If the outgoing interface list of the forwarding entry contains an MTI, PE 1
processes the private network multicast data.. Now, the VPN instance on PE 1 considers that the
private network multicast data has been sent out the MTI.
3) PE 1 encapsulates the multicast data by means of GRE, with its IBGP interface address as the
multicast source address and the share-group address as the multicast group address, to convert
it into a normal, public network multicast data packet (11.1.1.1, 239.1.1.1), and then passes the
packet to the public instance on PE 1 to have it forwarded to the public network.
4) The multicast data packet (11.1.1.1, 239.1.1.1) is forwarded to the public instance on all the PE
devices along the share-MDT. Upon receiving this packet, every PE device decapsulates it to turn
it back into a private network multicast data packet, and passes it to the corresponding VPN
instance. If any PE has a downstream interface for an SPT, it forwards the private network
multicast packet down the SPT; otherwise, it discards the packet.
1-12
5) The VPN instance on PE 2 searches the MVRF and finally delivers the private network multicast
data to Receiver. By now, the process of transmitting a private network multicast packet across the
public network is completed.
MDT Switchover
Switching from share-MDT to switch-MDT
When a multicast data packet of a VPN is transmitted through the share-MDT in the public network, the
packet is forwarded to all PE devices that support that VPN instance, no matter whether any active
receivers exist in the attached sites. When the rate of the customer multicast traffic of that VPN is high,
multicast data may get flooded in the public network, causing bandwidth waste and extra burden on the
PE devices.
To optimize multicast transmission, the MD solution establishes a dedicated switch-MDT between the
PE devices with private network multicast receivers and multicast sources for any large-traffic private
network multicast stream before it enters the public network. Then, the multicast stream is switched
from the share-MDT to the switch-MDT, to deliver the multicast data to only those receivers that need it.
The process of share-MDT to switch-MDT switchover is as follows:
1) The source-side PE (PE 1 in this example) device periodically checks the forwarding rate of the
VPN multicast traffic. Share-MDT to switch-MDT switchover takes place only when the following
criteria are both met:
z The private network multicast data has passed the filtering by an ACL rule for share-MDT to
switch-MDT switchover, and
z The traffic rate of the private network multicast stream has exceeded the switchover threshold and
stayed higher than the threshold for a certain length of time (namely, the switch-delay period).
2) PE 1 chooses an idle switch-group address from the switch-group-pool and sends an MDT
switchover message to all the other PE devices down the share-MDT. This message contains the
private network multicast source address, the private network multicast group address and the
switch-group address.
3) Each PE device that receives this message checks whether it interfaces with a private network that
has receivers of that VPN multicast stream. If so, it joins the switch-MDT rooted at PE 1; otherwise,
it caches the message and will join the switch-MDT when it has attached receivers.
4) After sending the MDT switchover message, PE 1 waits a certain length of time and then starts
using the switch-group address to encapsulate the private network multicast data, so that the
multicast data is forwarded down the switch-MDT.
5) After the multicast traffic is switched from the share-MDT to the switch-MDT, PE 1 continues
sending MDT switchover messages periodically, so that subsequent PE devices with attached
receivers can join the switch-MDT. When a downstream PE device has no longer active receivers
attached to it, it leaves the switch-MDT.
For a given VPN instance, the share-MDT and the switch-MDT are both forwarding tunnels in the same
MD. A share-MDT is uniquely identified by a share-group address, while a switch-MDT is uniquely
identified by a switch-group address. Each share-group is uniquely associated with a set of
switch-group addresses, namely a switch-group-pool.
1-13
Backward switching from switch-MDT to share-MDT
After the private network multicast traffic is switched to the switch-MDT, the multicast traffic conditions
may change and no longer meet the aforesaid switchover criterion. In this case, PE 1, as in the
example above, initiates a backward MDT switchover process. When any of the following criteria is met,
the multicast traffic is switched from the switch-MDT back to the share-MDT:
z The traffic rate of the private network multicast data has fallen below the switchover threshold and
stayed lower than the threshold for a certain length of time (namely, the switch-holddown period).
z The associated switch-group-pool is changed and the switch-group address for encapsulating the
private network multicast data is out of the new address pool.
z The ACL rule for controlling the switching of private network multicast traffic from the share-MDT to
the switch-MDT is changed and the private network multicast data fails to pass the new ACL rule.
Multi-AS MD VPN
If nodes of a VPNs network are allocated in multiple autonomous systems (ASs), these VPN nodes
must be interconnected. Two approaches are available to implement multi-AS VPN:
VRF-to-VRF PE interconnectivity
As shown in Figure 1-9, a VPNs network involves two ASs, AS 1 and AS 2. PE 3 and PE 4 are the
autonomous system boundary router (ASBR) for AS 1 and AS 2 respectively. PE 3 and PE 4 are
interconnected through their respective VPN instance and treat each other as a CE device.
Figure 1-9 VRF-to-VRF PE interconnectivity
In the VRF-to-VRF interconnectivity approach, a separate MD needs to be established within each AS,
and VPN multicast traffic between different ASs is transmitted between these MDs.
Because only VPN multicast traffic is forwarded between ASBRs, different PIM modes can run within
different ASs. However, the same PIM mode must run on all interfaces that belong to the same VPN
(including interfaces with VPN bindings on ASBRs).
1-14
Multi-hop EBGP interconnectivity
As shown in Figure 1-10, a VPNs network involves two ASs, AS 1 and AS 2. PE 3 and PE 4 are the
autonomous system boundary router (ASBR) for AS 1 and AS 2 respectively. PE 3 and PE 4 are
interconnected through their respective public network instance and treat each other as a P device.
Figure 1-10 Multi-hop EBGP interconnectivity
ASBR ASBR
PE 1' P1 PE 3 PE 4 P2 PE 2'
AS 1 AS 2
Public instasnce
MTI MTI
CE 1 PE 1" PE 2" CE 2
MT
MD
VPN instasnce
In the multi-hop EBGP interconnectivity approach, only one MD needs to be established for all the ASs,
and public network multicast traffic between different ASs is transmitted within this MD.
MD-VPN Configuration Task List

Complete these tasks to configure MD-VPN:
Task Remarks
Enabling IP Multicast Routing in a VPN Instance Required
Configuring a Share-Group and an MTI Binding Required
Configuring MDT Switchover Parameters Optional
Enabling Switch-Group Reuse Logging Optional
Configuring MD-VPN
Before configuring MD-VPN, complete the following tasks:

z Configure any unicast routing protocol to provide intra-domain interoperability at the network layer.
z Configure MPLS L3VPN.
z Enable PIM (PIM-DM or PIM-SM).
Before configuring MD-VPN, prepare the following data:
z VPN instance names and route distinguishers (RDs)
z Share-group addresses and an MTI numbers
z Address ranges of switch-group-pools and ACL rules for MDT switchover
z Switch-delay period
z Switch-holddown period
1-15
Enabling IP Multicast Routing in a VPN Instance
Before configuring any MD-VPN functionality for a VPN, you must enable IP multicast routing in the
VPN instance.
Follow these steps to enable IP multicast routing in a VPN instance:

Required
Configure an RD for the VPN route-distinguisher
instance route-distinguisher No RD is configured for a VPN
instance by default.
Required
Disabled by default
z For details about the ip vpn-instance and route-distinguisher commands, refer to MPLS L3VPN
z For details about the multicast routing-enable command, refer to Multicast Routing and
Configuring a Share-Group and an MTI Binding
By running multiple instances on each PE device, you enable the PE device to work for multiple VPNs.
You need to configure the same share-group address for the same VPN instance on different PE
devices. With a share-group and an MTI number configured, the system automatically creates an MTI,
binds the share-group address to the MTI and binds the MTI to the current VPN instance.
Follow these steps to configure a share-group and an MTI binding:

ip vpn-instance
vpn-instance-name
multicast-domain share-group Required

Configure a share-group
group-address binding mtunnel No share-group address or MTI
address and an MTI binding
mtunnel-number binding is configured.
1-16
z After a BGP peer is configured with the peer connect-interface command, the MTI interface
automatically obtains the connect-interface address and uses it as its own IP address. This IP
address cannot be used in the VPNs network any more; otherwise the MTI interface will fail to
obtain an IP address. When configuring multiple BGP peers on the same device, you must specify
the same connect-interface address for these BGP peers; otherwise the MTI interface will also
fail to obtain an IP address, either. For details about the peer connect-interface command, refer
to BGP Commands in the IP Routing Volume.
z The MTI interface becomes up only after it obtains an IP address. On some devices, in addition,
you need first to use the service-loopback group command to configure a multicast-tunnel type
service loopback group before an MTI interface can be brought up. For details about the
service-loopback group command, refer to Service Lookback Commands in the Access Volume.
Configuring MDT Switchover Parameters
In some cases, the traffic rate of the customer network multicast data may fluctuate around the MDT
switchover threshold. To avoid frequent switching of multicast traffic between the share-MDT and the
switch-MDT:
z MDT switchover does not take place immediately after the multicast traffic rate exceeds the
switchover threshold, but it takes place after a switch-delay period has passed, during which the
traffic rate must keep higher than the switchover threshold;
z Likewise, a backward switching does not take place immediately after the multicast traffic rate
comes back below the MDT switchover threshold, but it takes place after a switch-holddown period
has passed, during which the traffic rate must keep lower than the switchover threshold.
Follow these steps to configure MDT switchover parameters:
ip vpn-instance
vpn-instance-name
Required
multicast-domain
By default, no switch-group-pool is
Configure the switch-group-pool
configured and multicast traffic is
switch-group-pool address switch-group-pool { mask |
never switched to a switch-MDT.
range and the switchover mask-length } [ threshold
criteria threshold-value | acl The threshold threshold-value
acl-number ] * command option is not supported on
a switch.
Configure the switch-delay multicast-domain Optional

period switch-delay switch-delay 5 seconds by default
1-17
Configure the multicast-domain Optional

switch-holddown period holddown-time interval 60 seconds by default
Enabling Switch-Group Reuse Logging
For a given VPN, if the number of private network multicast streams to be switched to switch-MDTs
exceeds the number of addresses in the switch-group-pool, the VPN instance on the source-side PE
device can reuse the addresses in the address pool. With switch-group reuse logging enabled, the
address reuse information will be logged.
Follow these steps to enable the switch-group reuse logging:

ip vpn-instance
vpn-instance-name
Enable the switch-group reuse multicast-domain log Required

logging switch-group-reuse Disabled by default
Displaying and Maintaining MD-VPN

View the share-group
display multicast-domain vpn-instance Available in
information of the specified
vpn-instance-name share-group any view
VPN instance in the MD
display multicast-domain vpn-instance

View the switch-group vpn-instance-name switch-group receive [ brief |
information received by the [ active | group group-address | sender Available in
specified VPN instance in source-address | vpn-source-address [ mask any view
the MD { mask-length | mask } ] | vpn-group-address [ mask
{ mask-length | mask } ] ] * ]
display multicast-domain vpn-instance
View the switch-group
vpn-instance-name switch-group send [ group
information sent by the Available in
group-address | reuse interval | vpn-source-address
specified VPN instance in any view
[ mask { mask-length | mask } ] | vpn-group-address
the MD
[ mask { mask-length | mask } ] ] *
1-18
The support for the display multicast-domain vpn-instance switch-group receive and display
multicast-domain vpn-instance switch-group send commands depends on the specific device
model.
MD-VPN Configuration Examples (On Routers)

Single-AS MD VPN configuration
The network requirements for single-AS MD-VPN configuration are listed in the table below:
Item Network requirements
z In VPN a, S 1 is a multicast source, and R 1, R 2 and R 3 are receivers.
z In VPN b, S 2 is a multicast source, and R 4 is a receiver.
Multicast
sources and z For VPN a, the share-group address is 239.1.1.1, and the range of its
receivers switch-group-pool addresses is 225.2.2.0 to 225.2.2.15.
z For VPN b, the share-group address is 239.2.2.2, and the range of its
switch-group-pool addresses is 225.4.4.0 to 225.4.4.15.
z PE 1: Ethernet 1/2 and Ethernet 1/3 belong to VPN instance a; Ethernet 1/1
and Loopback 1 belong to the public instance.
PE interfaces
z PE 2: Ethernet 1/2 belongs to VPN instance b; Ethernet 1/3 belongs to VPN
and VPN
instance a; Ethernet 1/1 and Loopback 1 belong to the public instance.
instances they
belong to z PE 3: Ethernet 1/2 belongs to VPN instance a; Ethernet 1/3 and Loopback 2
belongs to VPN instance b; Ethernet 1/1 and Loopback 1 belong to the public
instance.
z Configure OSPF in the public network, and configure RIP between the PE
devices and the CE devices.
Unicast routing
z Establish BGP peer connections between PE 1, PE 2 and PE 3 on their
protocols and
respective Loopback 1 interface and exchange all private network routes
MPLS
between them.
z Configure MPLS in the public network.
z Enable IP multicast routing on the P router.
z Enable IP multicast routing in the public instance on PE 1, PE 2, and PE 3.
IP multicast
z Enable IP multicast routing in VPN instance a on PE 1, PE 2, and PE 3.
routing
z Enable IP multicast routing in VPN instance b on PE 2 and PE 3.
z Enable IP multicast routing on CE a1, CE a2, CE a3, CE b1, and CE b2.
z Run IGMPv2 on Ethernet 1/2 of PE 1.
IGMP
z Run IGMPv2 on Ethernet 1/1 of CE a2, CE a3, and CE b2.
z Enable PIM-SM on all interfaces of the P router.
z Enable PIM-SM on all public and private network interfaces of PE 1, PE 2, and
PE 3.
z Enable PIM-SM on all interfaces of CE a1, CE a2, CE a3, CE b1, and CE b2.
PIM z Configure Loopback 1 of P as a public network C-BSR and C-RP (to work for
all multicast groups).
z Configure Loopback 1 of CE a2 as a C-BSR and a C-RP for VPN a (to work for
z Configure Loopback 2 of PE 3 as a C-BSR and a C-RP for VPN b (to work for
1-19
Network diagram
Figure 1-11 Network diagram for single-AS MD-VPN configuration (on routers)
VPN a
Loop1
Eth
S2 VPN b 1/1
R2 CE a2
Eth
Eth 1/2 1/3 VPN a
1/1 Eth
Loop1
Eth
1/2 Eth
CE b1 1/3 Eth1/1
Eth 1/3
1/2 Eth R3
Loop1 Loop1
Eth Eth1 1/2 h1/2 CE a3

PE 2 1/1 /2 Eth Et
Eth1/1
R1 Eth Eth1/3
1/2 1/1 Eth Et
Eth Eth1
/1 P PE 3 1/3 h1/2
S1 R4
Loop2
Eth
1/1 1/2 h1/3 PE 1
Eth Et CE b2 Eth1/1
Public
CE a1 Loop1
VPN b
VPN a

S1 10.110.7.2/24 PE 3 Eth1/1 192.168.8.1/24
S2 10.110.8.2/24 Eth1/2 10.110.5.1/24
R1 10.110.1.2/24 Eth1/3 10.110.6.1/24
R2 10.110.9.2/24 Loop1 1.1.1.3/32
R3 10.110.10.2/24 Loop2 33.33.33.33/32
R4 10.110.11.2/24 CE a1 Eth1/1 10.110.7.1/24
P Eth1/1 192.168.6.2/24 Eth1/2 10.110.2.2/24
Eth1/2 192.168.7.2/24 CE a2 Eth1/1 10.110.9.1/24
Eth1/3 192.168.8.2/24 Eth1/2 10.110.4.2/24
Loop1 2.2.2.2/32 Eth1/3 10.110.12.1/24
PE 1 Eth1/1 192.168.6.1/24 Loop1 22.22.22.22/32
Eth1/2 10.110.1.1/24 CE a3 Eth1/1 10.110.10.1/24
Eth1/3 10.110.2.1/24 Eth1/2 10.110.5.2/24
Loop1 1.1.1.1/32 Eth1/3 10.110.12.2/24
PE 2 Eth1/1 192.168.7.1/24 CE b1 Eth1/1 10.110.8.1/24
Eth1/2 10.110.3.1/24 Eth1/2 10.110.3.2/24
Eth1/3 10.110.4.1/24 CE b2 Eth1/1 10.110.11.1/24
Loop1 1.1.1.2/32 Eth1/2 10.110.6.2/24
1) Configure PE 1
# Configure a Router ID, enable IP multicast routing in the public instance, configure an MPLS label
switching router (LSR) ID, and enable the Label Distribution Protocol (LDP) capability.
<PE1> system-view
[PE1] router id 1.1.1.1
[PE1] multicast routing-enable
[PE1] mpls
[PE1-mpls] quit
1-20
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Create VPN instance a, configure an RD for it, and create an ingress route and an egress route for it.
[PE1] ip vpn-instance a
[PE1-vpn-instance-a] route-distinguisher 100:1
[PE1-vpn-instance-a] vpn-target 100:1 export-extcommunity
[PE1-vpn-instance-a] vpn-target 100:1 import-extcommunity
# Enable IP multicast routing in VPN instance a, configure a share-group address, associate an MTI
with the VPN instance, and define the switch-group-pool address range.
[PE1-vpn-instance-a] multicast routing-enable
[PE1-vpn-instance-a] multicast-domain share-group 239.1.1.1 binding mtunnel 0
[PE1-vpn-instance-a] multicast-domain switch-group-pool 225.2.2.0 28
[PE1-vpn-instance-a] quit
# Configure an IP address, and enable PIM-SM and LDP capability on the public network interface
Ethernet 1/1.
[PE1] interface ethernet 1/1
[PE1-Ethernet1/1] ip address 192.168.6.1 24
[PE1-Ethernet1/1] pim sm
[PE1-Ethernet1/1] mpls
[PE1-Ethernet1/1] mpls ldp
[PE1-Ethernet1/1] quit
# Bind Ethernet 1/2 to VPN instance a, configure an IP address and enable IGMP and PIM-SM on the
interface.
[PE1-Ethernet1/2] ip binding vpn-instance a
[PE1-Ethernet1/2] igmp enable
# Bind Ethernet 1/3 to VPN instance a, configure an IP address and enable PIM-SM on the interface.
# Configure an IP address for Loopback 1, and enable PIM-SM.

[PE1-LoopBack1] pim sm
# Configure BGP.
[PE1] bgp 100
[PE1-bgp] group vpn-g internal
[PE1-bgp] peer vpn-g connect-interface loopback 1
1-21
[PE1-bgp] peer 1.1.1.2 group vpn-g
[PE1bgp] ipv4-family vpn-instance a
[PE1-bgp-a] import-route rip 2
[PE1-bgp-a] import-route direct
[PE1-bgp-a] quit
[PE1bgp] ipv4-family vpnv4
[PE1bgp-af-vpnv4] peer vpn-g enable
[PE1-bgp-af-vpnv4] peer 1.1.1.2 group vpn-g
[PE1bgp-af-vpnv4] peer 1.1.1.3 group vpn-g
[PE1bgp-af-vpnv4] quit
[PE1bgp] quit
The interface MTI 0 will automatically obtain an IP address after BGP peer configuration on PE 1. This
address is the loopback interface address specified in the BGP peer configuration. The PIM mode
running on MTI 0 is the same as the PIM mode running on all the interfaces in VPN instance a.
# Configure OSPF.
[PE1] ospf 1
[PE1-ospf-1] area 0.0.0.0
[PE1-ospf-1] quit
# Configure RIP.
[PE1] rip 2 vpn-instance a
[PE1-rip-2] network 10.0.0.0
[PE1-rip-2] import-route bgp
[PE1-rip-2] return
2) Configure PE 2
# Configure a Router ID, enable IP multicast routing in the public instance, configure an MPLS LSR ID,
and enable the LDP capability.
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Create VPN instance b, configure an RD for it, and create an ingress route and an egress route for it.
[PE2] ip vpn-instance b
[PE2-vpn-instance-b] route-distinguisher 200:1
[PE2-vpn-instance-b] vpn-target 200:1 export-extcommunity
[PE2-vpn-instance-b] vpn-target 200:1 import-extcommunity
# Enable IP multicast routing in VPN instance b, configure a share-group address, associate an MTI
1-22
[PE2-vpn-instance-b] multicast routing-enable
[PE2-vpn-instance-b] multicast-domain share-group 239.2.2.2 binding mtunnel 1
[PE2-vpn-instance-b] multicast-domain switch-group-pool 225.4.4.0 28
[PE2-vpn-instance-b] quit
Ethernet 1/1.
# Bind Ethernet 1/2 to VPN instance b, configure an IP address and enable PIM-SM on the interface.
[PE2-Ethernet1/2] ip binding vpn-instance b

# Configure BGP.
[PE2] bgp 100
1-23
[PE2-bgp-a] quit
[PE2bgp] ipv4-family vpn-instance b
[PE2-bgp-b] import-route rip 3
[PE2-bgp-b] import-route direct
[PE2-bgp-b] quit
[PE2bgp] quit
running on MTI 1 is the same as the PIM mode running on all the interfaces in VPN instance b.
# Configure OSPF.
[PE2] ospf 1
[PE2-ospf-1] quit
# Configure RIP.
[PE2-rip-2] quit
[PE2] rip 3 vpn-instance b
[PE2-rip-3] return
3) Configure PE 3
<PE3> system-view
[PE3] mpls
1-24
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
# Create VPN instance b, configure an RD for it, and create an ingress route and an egress route for it.
Ethernet 1/1.
1-25

# Bind Loopback 2 to VPN instance b, configure an IP address and enable PIM-SM on the interface.
[PE3-LoopBack2] ip binding vpn-instance b
# Configure Loopback 2 as a C-BSR and C-RP for VPN b.

[PE3] pim vpn-instance b
[PE3-pim-b] c-bsr loopback 2
[PE3-pim-b] c-rp loopback 2
[PE3-pim-b] quit
# Configure BGP.
[PE3] bgp 100
[PE3-bgp-a] quit
[PE3-bgp-b] quit
[PE3bgp] quit
running on MTI 1 is the same as the PIM mode running on all the interfaces in VPN instance b.
# Configure OSPF.
[PE3] ospf 1
1-26
[PE3-ospf-1] quit
# Configure RIP.
[PE3-rip-2] quit
[PE3-rip-3] return
4) Configuring the R router
# Enable IP multicast routing, configure an MPLS LSR ID, and enable the LDP capability in the public
instance.
<P> system-view
[P] multicast routing-enable
[P] mpls lsr-id 2.2.2.2
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
Ethernet 1/1.
[P] interface ethernet 1/1
[P-Ethernet1/1] ip address 192.168.6.2 24
[P-Ethernet1/1] pim sm
[P-Ethernet1/1] mpls
[P-Ethernet1/1] mpls ldp
[P-Ethernet1/1] quit
# Configure an IP address, enable PIM-SM and LDP capability on the public network interface Ethernet
1/2.
# Configure an IP address, enable PIM-SM and LDP capability on the public network interface Ethernet
1/3.
1-27
# Configure an IP address for Loopback 1 and enable PIM-SM on the interface.

[P] interface loopback 1
[P-LoopBack1] ip address 2.2.2.2 32
[P-LoopBack1] pim sm
[P-LoopBack1] quit
# Configure Loopback 1 as a C-BSR and C-RP for the public instance.

[P] pim
[P-pim] c-bsr loopback 1
[P-pim] c-rp loopback 1
[P-pim] quit
# Configure OSPF.
[P] ospf 1
[P-ospf-1] area 0.0.0.0
[P-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
5) Configure CE a1
# Enable IP multicast routing.
<CEa1> system-view
[CEa1] multicast routing-enable
# Configure an IP address and enable PIM-SM on Ethernet 1/1.

[CEa1] interface ethernet 1/1
[CEa1-Ethernet1/1] ip address 10.110.7.1 24
[CEa1-Ethernet1/1] pim sm
[CEa1-Ethernet1/1] quit

# Configure RIP.
[CEa1] rip 2
[CEa1-rip-2] network 10.0.0.0
6) Configure CE b1
<CEb1> system-view
[CEb1] multicast routing-enable

[CEb1] interface ethernet 1/1
[CEb1-Ethernet1/1] ip address 10.110.8.1 24
1-28
[CEb1-Ethernet1/1] pim sm
[CEb1-Ethernet1/1] quit

# Configure RIP.
[CEb1] rip 3
[CEb1-rip-3] network 10.0.0.0
7) Configure CE a2
<CEa2> system-view
# Configure an IP address, and enable IGMP and PIM-SM on Ethernet 1/1.

[CEa2-Ethernet1/1] igmp enable


# Configure an IP address for Loopback 1 and enable PIM-SM on the interface.

[CEa2] interface loopback 1
[CEa2-LoopBack1] ip address 22.22.22.22 32
[CEa2-LoopBack1] pim sm
[CEa2-LoopBack1] quit
# Configure Loopback 1 as a BSR and RP for VPN a.

[CEa2] pim vpn-instance a
[CEa2-pim-a] c-bsr loopback 1
[CEa2-pim-a] c-rp loopback 1
[CEa2-pim-a] quit
# Configure RIP.
[CEa2] rip 2
1-29
8) Configure CE a3
<CEa3> system-view



# Configure RIP.
[CEa3] rip 2
9) Configure CE b2
<CEb2> system-view

[CEb2-Ethernet1/1] igmp enable

# Configure RIP.
[CEb2] rip 3
1-30
To view the share-group information of a VPN instance, use the display multicast-domain
vpn-instance share-group command.
# View the share-group information of VPN instance a on PE 1.
<PE1> display multicast-domain vpn-instance a share-group
MD local share-group information for VPN-Instance: a
Share-group: 239.1.1.1
MTunnel address: 1.1.1.1

# View the share-group information of VPN instance b on PE 2.

<PE2> display multicast-domain vpn-instance b share-group
MD local share-group information for VPN-Instance: b


Multi-AS MD VPN Configuration
The network requirements for multi-AS MD-VPN configuration are listed in the table below:

z In VPN a, S 1 is a multicast source, and R 2 is a receiver.
Multicast sources and z For VPN a, the share-group address is 239.1.1.1, and the range of
receivers its switch-group-pool addresses is 225.1.1.0 to 225.1.1.15.
z For VPN b, the share-group address is 239.4.4.4, and the range of
its switch-group-pool addresses is 225.4.4.0 to 225.4.4.15.
1-31
z PE 1: Ethernet 1/2 belongs to VPN instance a; Ethernet 1/3 belongs
to VPN instance b; Ethernet 1/1 and Loopback 1 belong to the public
network instance.
z PE 2: Ethernet 1/1, Ethernet 1/2, Loopback 1 and Loopback 2 belong
PE interfaces and VPN to the public network instance.
instances they belong to z PE 3: Ethernet 1/1, Ethernet 1/2, Loopback 1 and Loopback 2 belong
to the public network instance.
z PE 4: Ethernet 1/2 belongs to VPN instance a; Ethernet 1/3 belongs
to VPN instance b; Ethernet 1/1 and Loopback 1 belong to the public
network instance.
z Configure OSPF separately in AS 100 and AS 200, and configure
OSPF between the PEs and CEs.
Unicast routing protocols z Establish BGP peer connections between PE 1, PE 2, PE 3 and PE 4
and MPLS on their respective Loopback 1 interface and exchange all private
network routes between them.
z Configure MPLS separately in AS 100 and AS 200.
z Enable IP multicast routing in the public instance on PE 1, PE 2, PE
3 and PE 4.
IP multicast routing z Enable IP multicast routing in VPN instance a on PE 1 and PE 4.
z Enable IP multicast routing on CE a1, CE a2, CE b1, and CE b2.
z Run IGMPv2 on Ethernet 1/1 of CE a2.
IGMP
z Run IGMPv2 on Ethernet 1/1 of CE b2.
z Enable PIM-SM on all public network interfaces of PE 2 and PE 3.
z Enable PIM-SM on all public and private network interfaces of PE 1
and PE 4.
z Enable PIM-SM on all interfaces of CE a1, CE a2, CE b1, and CE b2.
PIM z Configure Loopback 2 of PE 2 and PE 3 as a C-BSR and a C-RP for
their respective AS (to work for all multicast groups).
z Configure Loopback 0 of CE a1 as a C-BSR and a C-RP for VPN a
(to work for all multicast groups).
z Configure Loopback 0 of CE b1 as a C-BSR and a C-RP for VPN b
(to work for all multicast groups).
z Establish an MSDP peering relationship between PE 2 and PE 3 on
MSDP
their respective Loopback 1.
1-32
Network diagram
Figure 1-12 Network diagram for multi-AS MD-VPN configuration
Loop0 Loop0
S1 R1
Eth1/1
CE a1 CE b2 Eth1/1
Eth1/2
Eth1/2
VPN a VPN b
Eth1/2 1 Lo 1 Lo
Eth1/3
op op
2 op op
2
Lo Lo
1
Lo
op
op
Lo
1
PE 1 PE 4
Eth1/3
Eth1/2
PE 2 PE 3
ASBR ASBR
AS 100 AS 200
Eth1/2
Eth1/2
S2 R2
Eth1/1 Eth1/1
CE b1 CE a2
VPN b VPN a

S1 10.11.5.2/24 R1 10.11.8.2/24
S2 10.11.6.2/24 R2 10.11.7.2/24
PE 1 Eth1/1 10.10.1.1/24 PE 3 Eth1/1 10.10.2.1/24
Eth1/2 10.11.1.1/24 Eth1/2 192.168.1.2/24
Eth1/3 10.11.2.1/24 Loop1 1.1.1.3/32
Loop1 1.1.1.1/32 Loop2 22.22.22.22/32
PE 2 Eth1/1 10.10.1.2/24 PE 4 Eth1/1 10.10.2.2/24
Eth1/2 192.168.1.1/24 Eth1/2 10.11.3.1/24
Loop1 1.1.1.2/32 Eth1/3 10.11.4.1/32
Loop2 11.11.11.11/32 Loop2 1.1.1.4/32
CE a1 Eth1/1 10.11.5.1/24 CE b1 Eth1/1 10.11.6.1/24
Eth1/2 10.11.1.2/24 Eth1/2 10.11.2.2/24
Loop0 2.2.2.2/32 CE b2 Eth1/1 10.11.8.1/24
CE a2 Eth1/1 10.11.7.1/24 Eth1/2 10.11.4.2/24
Eth1/2 10.11.3.2/24 Loop0 3.3.3.3/32
1) Configure PE 1
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
1-33
# Create VPN instance a, configure an RD for it, and create an ingress route and an egress route for it;
enable IP multicast routing in VPN instance a, configure a share-group address, associate an MTI with
the VPN instance, and define the switch-group-pool address range.
# Create VPN instance b, configure an RD for it, and create an ingress route and an egress route for it;
enable IP multicast routing in VPN instance b, configure a share-group address, associate an MTI with
Ethernet 1/1.

1-34
# Configure BGP.
[PE1] bgp 100
[PE1-bgp] group pe1-pe2 internal
[PE1-bgp] peer pe1-pe2 label-route-capability
[PE1-bgp] peer pe1-pe2 connect-interface loopback 1
[PE1-bgp] peer 1.1.1.2 group pe1-pe2
[PE1-bgp] group pe1-pe4 external
[PE1-bgp] peer pe1-pe4 as-number 200
[PE1-bgp] peer pe1-pe4 ebgp-max-hop 255
[PE1-bgp-a] import-route ospf 2
[PE1-bgp-a] quit
[PE1-bgp-b] import-route ospf 3
[PE1-bgp-b] quit
[PE1bgp-af-vpnv4] peer 1.1.1.4 enable
[PE1bgp] quit
With BGP peers configured on PE 1, the interfaces MTI 0 and MTI 1 will automatically obtain IP
addresses, which are the loopback interface addresses specified in the BGP peer configuration. The
PIM mode running on MTI 0 is the same as on the interfaces in VPN instance a, and the PIM mode
running on MTI 1 is the same as on the interfaces in VPN instance b.
# Configure OSPF.
[PE1] ospf 1
[PE1-ospf-1] quit
[PE1] ospf 2 vpn-instance a
[PE1-ospf-2] import-route bgp
[PE1-ospf-2] quit
[PE1] ospf 3 vpn-instance b
1-35
[PE1-ospf-3] quit
2) Configure PE 2
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
Ethernet 1/1.
# Configure an IP address, and enable PIM-SM and MPLS on the public network interface Ethernet 1/2.


# Configure Loopback 2 as a C-BSR and a C-RP for the public network instance.
[PE2] pim
[PE2-pim] c-bsr loopback 2
[PE2-pim] c-rp loopback 2
[PE2-pim] quit
# Configure a BSR message boundary.

[PE2-Ethernet1/2] pim bsr-boundary
1-36
# Establish an MSDP peering relationship.

[PE2] msdp
[PE2-msdp] encap-data-enable
[PE2-msdp] peer 1.1.1.3 connect-interface loopback 1

[PE2] ip route-static 1.1.1.3 32 ethernet 1/2 192.168.1.2
# Configure BGP.
[PE2] bgp 100
[PE2-bgp] import-route ospf 1
[PE2-bgp] peer pe2-pe1 route-policy map2 export
[PE2bgp] quit
# Configure OSPF.
[PE2] ospf 1
[PE2-ospf-1] quit

[PE2] route-policy map1 permit node 10
[PE2-route-policy] apply mpls-label
[PE2-route-policy] quit
[PE2-route-policy] if-match mpls-label
3) Configure PE 3
<PE3> system-view
1-37
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
Ethernet 1/1.
# Configure an IP address, and enable PIM-SM and MPLS on the public network interface Ethernet 1/2.


[PE3] pim
[PE3-pim] quit

[PE3-Ethernet1/2] pim bsr-boundary

[PE3] msdp

[PE3] ip route-static 1.1.1.2 32 ethernet 1/2 192.168.1.1
1-38
# Configure BGP.
[PE3] bgp 200
[PE3bgp] quit
# Configure OSPF.
[PE3] ospf 1
[PE3-ospf-1] quit

4) Configure PE 4
<PE4> system-view
[PE4] mpls
[PE4-mpls] quit
[PE4] mpls ldp
[PE4-mpls-ldp] quit
1-39
Ethernet 1/1.

# Configure BGP.
1-40
[PE4] bgp 100
[PE4-bgp-a] quit
[PE4-bgp-b] quit
[PE4bgp] quit
# Configure OSPF.
[PE4] ospf 1
[PE4-ospf-1] quit
[PE4-ospf-2] quit
[PE4-ospf-3] quit
5) Configure CE a1.
1-41
<CEa1> system-view



# Configure Loopback 1 as a C-BSR and a C-RP for VPN a.

[CEa1-pim-a] quit
# Configure OSPF.
[CEa1] ospf 1
[CEa1-ospf-1] area 0.0.0.0
[CEa1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[CEa1-ospf-1-area-0.0.0.0] quit
[CEa1-ospf-1] quit
6) Configure CE b1.
<CEb1> system-view


# Configure OSPF.
1-42
[CEb1] ospf 1
[CEb1-ospf-1] area 0.0.0.0
[CEb1-ospf-1-area-0.0.0.0] network 10.11.0.0 0.0.255.255
[CEb1-ospf-1-area-0.0.0.0] quit
[CEb1-ospf-1] quit
7) Configure CE a2.
<CEa2> system-view
# Configure an IP address and enable IGMP and PIM-SM on Ethernet 1/1.


# Configure OSPF.
[CEa2] ospf 1
[CEa2-ospf-1] quit
8) Configure CE b2.
<CEb2> system-view
# Configure an IP address and enable IGMP and PIM-SM on Ethernet 1/1.

[CEb2-Ethernet1/1] igmp enable


[CEb2] interface loopback 1
[CEb2-LoopBack1] ip address 3.3.3.3 32
1-43
[CEb2-LoopBack1] pim sm
[CEb2-LoopBack1] quit
# Configure Loopback 1 as a C-BSR and a C-RP for VPN b.

[CEb2] pim vpn-instance b
[CEb2-pim-b] c-bsr loopback 1
[CEb2-pim-b] c-rp loopback 1
[CEb2-pim-b] quit
# Configure OSPF.
[CEb2] ospf 1
[CEb2-ospf-1] quit



MD VPN Configuration Examples (On Switches)

Single-AS MD VPN Configuration
The network requirements for single-AS MD-VPN configuration are listed in the table below:
1-44
z In VPN a, S 1 is a multicast source, and R 1, R 2 and R3 are receivers.
Multicast sources and z For VPN a, the share-group address is 239.1.1.1, and the
receivers switch-group-pool address range is 225.2.2.0 to 225.2.2.15.
z For VPN b, the share-group address is 239.2.2.2, and the
switch-group-pool address range is 225.4.4.0 to 225.4.4.15.
z PE 1: VLAN-interface 11 and VLAN-interface 20 belong to VPN
instance a; VLAN-interface 12 and Loopback 1 belong to the public
network instance.
PE interfaces and VPN z PE 2: VLAN-interface 13 belongs to VPN instance b; VLAN-interface
instances they belong 14 belongs to VPN instance a; VLAN-interface 15 and Loopback 1
to belong to the public network instance.
z PE 3: VLAN-interface 17 belongs to VPN instance a; VLAN-interface
18 and Loopback 2 belong to VPN instance b; VLAN-interface 19 and
Loopback 1 belong to the public network instance.
z Configure OSPF in the public network, and configure RIP between the
PEs and CEs.
Unicast routing z Establish BGP peer connections between PE 1, PE 2 and PE 3 on their
protocols and MPLS respective Loopback 1 interface and exchange all private network
routes between them.
z Configure MPLS in the public network.
z Enable IP multicast routing on the P device.
z Enable IP multicast routing in the public instance on PE 1, PE 2, and
PE 3.
IP multicast routing z Enable IP multicast routing in VPN instance a on PE 1, PE 2, and PE 3.
z Enable IP multicast routing on CE a1, CE a2, CE a3, CE b1, and CE
b2.
z Run IGMPv2 on VLAN-interface 20 of PE 1.
IGMP z Run IGMPv2 on VLAN-interface 40 of CE a2, VLAN-interface 50 of CE
a3, and VLAN-interface 60 of CE b2.
z Enable PIM-SM on all interfaces of the P device.
z Enable PIM-SM on all public and private network interfaces of PE 1, PE
2 and PE 3.
z Enable PIM-SM on all interfaces of CE a1, CE a2, CE a3, CE b1, and
CE b2.
PIM z Configure Loopback 1 of P as a C-BSR and a C-RP for the public
network (to work for all multicast groups).
z Configure Loopback 1 of CE a2 as a C-BSR and a C-RP for VPN a (to
work for all multicast groups).
z Configure Loopback 2 of PE 3 as a C-BSR and a C-RP for VPN b (to
1-45
Network diagram
Table 1-2 Network diagram for single-AS MD VPN configuration (on switches)
VPN a
Loop1
Vla
n-i
S2 VPN b R2 nt4
0 CE a2
n t14 Vla VPN a

Vlan-int30 n-i n-i
Loop1 Vla n t16
Vla
n-i Vla R3
n n-i
CE b1 Vla t13 t14 nt1
n-i -in 6
nt1
3 V lan
Loop1 Loop1 Vlan-int50
Vla 7
PE 2 Vla n-i nt1 int17 CE a3
n-i n
nt1 t15 n-i -
5 Vlan-int19 Vla Vlan
R1 Vla Vlan-int19
n-i 2 Vla Vlan
nt2 nt1 12 PE 3 -
0 l an-i n-int P n-i
nt1 int18
S1
V Vla 8
Loop2 Vlan-int60
1 1 PE 1
CE a1 nt1 -int1 CE b2
n-i n
Vla Vla Public R4
Vlan-int10
Loop1
VPN b
VPN a

S1 10.110.7.2/24 PE 3 Vlan-int19 192.168.8.1/24
S2 10.110.8.2/24 Vlan-int17 10.110.5.1/24
R1 10.110.1.2/24 Vlan-int18 10.110.6.1/24
R2 10.110.9.2/24 Loop1 1.1.1.3/32
R3 10.110.10.2/24 Loop2 33.33.33.33/32
R4 10.110.11.2/24 CE a1 Vlan-int10 10.110.7.1/24
P Vlan-int12 192.168.6.2/24 Vlan-int11 10.110.2.2/24
Vlan-int15 192.168.7.2/24 CE a2 Vlan-int40 10.110.9.1/24
Vlan-int19 192.168.8.2/24 Vlan-int14 10.110.4.2/24
Loop1 2.2.2.2/32 Vlan-int16 10.110.12.1/24
PE 1 Vlan-int12 192.168.6.1/24 Loop1 22.22.22.22/32
Vlan-int20 10.110.1.1/24 CE a3 Vlan-int50 10.110.10.1/24
Vlan-int11 10.110.2.1/24 Vlan-int17 10.110.5.2/24
Loop1 1.1.1.1/32 Vlan-int16 10.110.12.2/24
PE 2 Vlan-int15 192.168.7.1/24 CE b1 Vlan-int30 10.110.8.1/24
Vlan-int13 10.110.3.1/24 Vlan-int13 10.110.3.2/24
Vlan-int14 10.110.4.1/24 CE b2 Vlan-int60 10.110.11.1/24
Loop1 1.1.1.2/32 Vlan-int18 10.110.6.2/24
1) Configure PE 1
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
1-46
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Create VPN instance a, configure a RD for it, and create an egress route and an ingress route for it.
VLAN-interface 12.
[PE1] interface vlan-interface 12
[PE1-Vlan-interface12] ip address 192.168.6.1 24
[PE1-Vlan-interface12] pim sm
[PE1-Vlan-interface12]] mpls
[PE1-Vlan-interface12] mpls ldp
[PE1-Vlan-interface12] quit
# Bind VLAN-interface 20 to VPN instance a, configure an IP address and enable IGMP and PIM-SM
on the interface.
[PE1-Vlan-interface20] ip binding vpn-instance a
[PE1-Vlan-interface20] igmp enable
# Bind VLAN-interface 11 to VPN instance a, configure an IP address and enable PIM-SM on the
interface.

# Configure BGP.
[PE1] bgp 100
1-47
[PE1-bgp-a] quit
[PE1bgp] quit
With BGP peers configured on PE 1, the interfaces MTI 0 will automatically obtain an IP address, which
is the loopback interface address specified in the BGP peer configuration. The PIM mode running on
MTI 0 is the same as on the interfaces in VPN instance a.
# Configure OSPF.
[PE1] ospf 1
[PE1-ospf-1] quit
# Configure RIP
[PE1-rip-2] return
2) Configure PE 2
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Create VPN instance b, configure a RD for it, and create an egress route and an ingress route for it.
1-48
VLAN-interface 15.
[PE2-Vlan-interface15] mpls
# Bind VLAN-interface 13 to VPN instance b, configure an IP address and enable PIM-SM on the
interface.
[PE2-Vlan-interface13] ip binding vpn-instance b
interface.

1-49
# Configure BGP.
[PE2] bgp 100
[PE2-bgp-a] quit
[PE2-bgp-b] quit
[PE2bgp] quit
# Configure OSPF.
[PE2] ospf 1
[PE2-ospf-1] quit
# Configure RIP
[PE2-rip-2] quit
[PE2-rip-3] return
3) Configure PE 3
<PE3> system-view
1-50
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
# Create VPN instance b, configure a RD for it, and create an egress route and an ingress route for it.
VLAN-interface 19.
interface.
interface.
1-51

# Bind Loopback 2 to VPN instance b, configure an IP address and enable PIM-SM on the interface.
[PE3-LoopBack2] ip binding vpn-instance b

[PE3] pim vpn-instance b
[PE3-pim-b] c-bsr loopback 2
[PE3-pim-b] c-rp loopback 2
[PE3-pim-b] quit
# Configure BGP.
[PE3] bgp 100
[PE3-bgp-a] quit
[PE3-bgp-b] quit
[PE3bgp] quit
1-52
# Configure OSPF.
[PE3] ospf 1
[PE3-ospf-1] quit
# Configure RIP
[PE3-rip-2] quit
[PE3-rip-3] return
4) Configure P:
# Enable IP multicast routing in the public instance, configure an MPLS LSR ID, and enable the LDP
capability.
<P> system-view
[P] multicast routing-enable
[P] mpls lsr-id 2.2.2.2
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
VLAN-interface 12.
[P] interface vlan-interface 12
[P-Vlan-interface12] ip address 192.168.6.2 24
[P-Vlan-interface12] pim sm
[P-Vlan-interface12] mpls
[P-Vlan-interface12] mpls ldp
[P-Vlan-interface12] quit
VLAN-interface 15.
VLAN-interface 19.
1-53

[P] interface loopback 1
[P-LoopBack1] ip address 2.2.2.2 32
[P-LoopBack1] pim sm
[P-LoopBack1] quit
[P] pim
[P-pim] c-bsr loopback 1
[P-pim] c-rp loopback 1
[P-pim] quit
# Configure OSPF.
[P] ospf 1
[P-ospf-1] area 0.0.0.0
5) Configure CE a1.
<CEa1> system-view
# Configure an IP address for VLAN-interface 10 and enable PIM-SM on the interface.

[CEa1] interface vlan-interface 10
[CEa1-Vlan-interface10] ip address 10.110.7.1 24
[CEa1-Vlan-interface10] pim sm
[CEa1-Vlan-interface10] quit

# Configure RIP
[CEa1] rip 2
6) Configure CE b1.
<CEb1> system-view
1-54
[CEb1] interface vlan-interface 30
[CEb1-Vlan-interface30] ip address 10.110.8.1 24
[CEb1-Vlan-interface30] pim sm
[CEb1-Vlan-interface30] quit

# Configure RIP
[CEb1] rip 3
7) Configure CE a2.
<CEa2> system-view
# Configure an IP address for VLAN-interface 40 and enable IGMP and PIM-SM on the interface.
[CEa2-Vlan-interface40] igmp enable




[CEa2-pim-a] quit
# Configure RIP
1-55
[CEa2] rip 2
8) Configure CE a3.
<CEa3> system-view


# Configure RIP
[CEa3] rip 2
9) Configure CE b2.
<CEb2> system-view
[CEb2-Vlan-interface60] igmp enable

# Configure RIP
[CEb2] rip 3
1-56




Multi-AS MD VPN Configuration
The network requirements for multi-AS MD-VPN configuration are listed in the table below:

z In VPN a, S 1 is a multicast source, and R 2 is a receiver.
Multicast sources z For VPN a, the share-group address is 239.1.1.1, and the range of its
and receivers switch-group-pool addresses is 225.1.1.0 to 225.1.1.15.
z For VPN b, the share-group address is 239.4.4.4, and the range of its
switch-group-pool addresses is 225.4.4.0 to 225.4.4.15.
1-57
z PE 1: VLAN-interface 11 belongs to VPN instance b; VLAN-interface 12
belongs to VPN instance a; VLAN-interface 2 and Loopback 1 belong to
the public network instance.
z PE 2: VLAN-interface 2, VLAN-interface 3, Loopback 1 and Loopback 2
PE interfaces and belong to the public network instance.
VPN instances they
belong to z PE 3: VLAN-interface 3, VLAN-interface 4, Loopback 1 and Loopback 2
belong to the public network instance.
z PE 4: VLAN-interface 13 belongs to VPN instance a; VLAN-interface 14
belongs to VPN instance b; VLAN-interface 4 and Loopback 1 belong to
the public network instance.
z Configure OSPF separately in AS 100 and AS 200, and configure OSPF
between the PEs and CEs.
Unicast routing
z Establish BGP peer connections between PE 1, PE 2, PE 3 and PE 4 on
protocols and
their respective Loopback 1 interface and exchange all private network
MPLS
routes between them.
z Configure MPLS separately in AS 100 and AS 200.
z Enable IP multicast routing in the public instance on PE 1, PE 2, PE 3 and
PE 4.
IP multicast routing z Enable IP multicast routing in VPN instance a on PE 1 and PE 4.
z Enable IP multicast routing on CE a1, CE a2, CE b1, and CE b2.
z Run IGMPv2 on VLAN-interface 30 of CE a2.
IGMP
z Run IGMPv2 on VLAN-interface 40 of CE b2.
z Enable PIM-SM on all public network interfaces of PE 2 and PE 3.
z Enable PIM-SM on all public and private network interfaces of PE 1 and
PE 4.
z Enable PIM-SM on all interfaces of CE a1, CE a2, CE b1, and CE b2.
PIM z Configure Loopback 2 of PE 2 and PE 3 as a C-BSR and a C-RP for their
respective AS (to work for all multicast groups).
z Configure Loopback 0 of CE a1 as a C-BSR and a C-RP for VPN a (to
z Configure Loopback 0 of CE b1 as a C-BSR and a C-RP for VPN b (to
z Establish an MSDP peering relationship between PE 2 and PE 3 on their
MSDP
respective Loopback 1.
1-58
Network diagram
Figure 1-13 Network diagram for multi-AS MD-VPN configuration
Loop0 Loop0
S1 R1
Vlan-int10 CE a1 CE b2 Vlan-int40
Vlan-int14
Vlan-int11
VPN a VPN b
Vlan-int11
Vlan-int14
1 Lo 1 Lo
op op
2 op op
2
Lo Lo
1
Lo
op
op
Lo
1
PE 1 Vlan-int2 Vlan-int3 Vlan-int4 PE 4

Vlan-int12
Vlan-int13
PE 2 PE 3
ASBR ASBR
AS 100 AS 200
Vlan-int12
Vlan-int13
S2 R2
CE b1 CE a2
VPN b VPN a

S1 10.11.5.2/24 R1 10.11.8.2/24
S2 10.11.6.2/24 R2 10.11.7.2/24
PE 1 Vlan-int2 10.10.1.1/24 PE 3 Vlan-int4 10.10.2.1/24
Vlan-int11 10.11.1.1/24 Vlan-int3 192.168.1.2/24
Vlan-int12 10.11.2.1/24 Loop1 1.1.1.3/32
Loop1 1.1.1.1/32 Loop2 22.22.22.22/32
PE 2 Vlan-int2 10.10.1.2/24 PE 4 Vlan-int4 10.10.2.2/24
Vlan-int3 192.168.1.1/24 Vlan-int13 10.11.3.1/24
Loop1 1.1.1.2/32 Vlan-int14 10.11.4.1/32
Loop2 11.11.11.11/32 Loop2 1.1.1.4/32
CE a1 Vlan-int10 10.11.5.1/24 CE b1 Vlan-int20 10.11.6.1/24
Vlan-int11 10.11.1.2/24 Vlan-int12 10.11.2.2/24
Loop0 2.2.2.2/32 CE b2 Vlan-int40 10.11.8.1/24
CE a2 Vlan-int30 10.11.7.1/24 Vlan-int14 10.11.4.2/24
Vlan-int13 10.11.3.2/24 Loop0 3.3.3.3/32
1) Configure PE 1
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
1-59
VLAN-interface 2.
interface.
interface.
1-60
# Configure BGP.
[PE1] bgp 100
[PE1-bgp-a] quit
[PE1-bgp-b] quit
[PE1bgp] quit
# Configure OSPF.
[PE1] ospf 1
[PE1-ospf-1] quit
[PE1-ospf-2] quit
1-61
[PE1-ospf-3] quit
2) Configure PE 2
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
VLAN-interface 2.
# Configure an IP address, and enable PIM-SM and MPLS capability on the public network interface
VLAN-interface 3.


[PE2] pim
[PE2-pim] quit

1-62
[PE2-Vlan-interface3] pim bsr-boundary

[PE2] msdp

[PE2] ip route-static 1.1.1.3 32 vlan-interface 3 192.168.1.2
# Configure BGP.
[PE2] bgp 100
[PE2bgp] quit
# Configure OSPF.
[PE2] ospf 1
[PE2-ospf-1] quit

3) Configure PE 3
<PE3> system-view
1-63
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
VLAN-interface 4.
# Configure an IP address, and enable PIM-SM and MPLS capability on the public network interface
VLAN-interface 3.


[PE3] pim
[PE3-pim] quit

[PE3-Vlan-interface3] pim bsr-boundary

[PE3] msdp
1-64

[PE3] ip route-static 1.1.1.2 32 vlan-interface 3 192.168.1.1
# Configure BGP.
[PE3] bgp 200
[PE3bgp] quit
# Configure OSPF.
[PE3] ospf 1
[PE3-ospf-1] quit

4) Configure PE 4
<PE4> system-view
[PE4] mpls
[PE4-mpls] quit
[PE4] mpls ldp
1-65
[PE4-mpls-ldp] quit
VLAN-interface 4.
interface.
interface.
1-66
# Configure BGP.
[PE4] bgp 100
[PE4-bgp-a] quit
[PE4-bgp-b] quit
[PE4bgp] quit
# Configure OSPF.
[PE4] ospf 1
[PE4-ospf-1] quit
[PE4-ospf-2] quit
1-67
[PE4-ospf-3] quit
5) Configure CE a1.
<CEa1> system-view




[CEa1-pim-a] quit
# Configure OSPF.
[CEa1] ospf 1
[CEa1-ospf-1] quit
6) Configure CE b1.
<CEb1> system-view

1-68

# Configure OSPF.
[CEb1] ospf 1
[CEb1-ospf-1] quit
7) Configure CE a2.
<CEa2> system-view

# Configure OSPF.
[CEa2] ospf 1
[CEa2-ospf-1] quit
8) Configure CE b2.
<CEb2> system-view
[CEb2-Vlan-interface40] igmp enable

1-69

[CEb2] interface loopback 1
[CEb2-LoopBack1] ip address 3.3.3.3 32
[CEb2-LoopBack1] pim sm
[CEb2-LoopBack1] quit

[CEb2] pim vpn-instance b
[CEb2-pim-b] c-bsr loopback 1
[CEb2-pim-b] c-rp loopback 1
[CEb2-pim-b] quit
# Configure OSPF.
[CEb2] ospf 1
[CEb2-ospf-1] quit



1-70
Troubleshooting MD-VPN Configuration
Unable to Establish a Share-MDT
Symptom
A share-MDT cannot be established. PIM adjacencies cannot be established between the same VPN
instances interfaces on different PE devices.
Analysis
z On different PE devices, the same share-group must be configured for the same VPN instance. A
share-group address uniquely identifies a share-MDT. If different share-group addresses have
been configured for a VPN instance on different PE devices, a share-MDT cannot be established
for that VPN instance on different PE devices.
z The same PIM mode must run on all the interfaces of the same VPN instance and on all the
interfaces of the P router; otherwise, a share-MDT cannot be correctly built for the VPN instance
and PIM adjacencies cannot be established between the VPN instance on the local PE device and
the same VPN instance on the remote PE device.
z BGP and unicast route configurations are prerequisites for the MTI interface of a VPN instance on
a PE device to obtain an IP address automatically. Without an IP address correctly obtained by the
MTI, PIM adjacencies cannot be established between the same VPN instances interfaces on
different PE devices after PIM is enabled on the MTI.
Solution
1) Check the share-group address: Use the display multicast-domain vpn-instance share-group
command to verify that the same share-group address has been configured for the same VPN
instance on different PE devices.
2) Check the running PIM mode: Use the display pim interface command to verify that the same
PIM mode is running on all the interfaces of the VPN instance and all the interfaces of the P router.
3) Check unicast routes. Use the display ip routing-table command to verify that a unicast route
exists from the VPN instance on the local PE device to the same VPN instance on each remote PE
device.
4) Check BGP peer configuration: Use the display bgp peer command to verify that the BGP peer
connections have been correctly configured.
Unable to Build an MVRF
Symptom
A VPN instance cannot create an MVRF correctly.
Analysis
z If PIM-SM is running in the VPN instance, the BSR information for the VPN instance is required;
otherwise, the VPN instances MVRF cannot be correctly established.
z If PIM-SM is running in the VPN instance, the RP information for the VPN instance is required. If a
unicast route to the RP is not available, this means that a PIM adjacency has not been correctly
established between the public instance and the VPN instance, and thus VPN instance cannot
correctly establish its MVRF.
z The customer DR must have a route to the private network RP.
1-71
Solution
1) Use the display pim bsr-info command to check whether the BSR information exists in the public
instance and VPN instance. If not, check whether a unicast route exists to the BSR.
2) Use the display pim rp-info command to view the RP information. If no RP information is
available, check whether a unicast route exists to the RP. Use the display pim neighbor
command to check whether the PIM adjacencies have correctly established in the public network
and the private network.
3) Use the ping command to check the connectivity between the private network DR and the private
network RP.
1-72
Table of Contents
1 MBGP Configuration 1-1

MBGP Overview1-1
Protocols and Standards1-2
MBGP Configuration Task List1-2
Configuring MBGP Basic Functions1-3
Prerequisites1-3
Controlling Route Advertisement and Reception1-3
Prerequisites1-3
Configuring MBGP Route Redistribution1-3
Configuring MBGP Route Summarization1-4
Advertising a Default Route to an IPv4 MBGP Peer or Peer Group 1-5
Configuring Outbound MBGP Route Filtering 1-5
Configuring Inbound MBGP Route Filtering 1-6
Configuring MBGP Route Dampening 1-7
Configuring MBGP Route Attributes 1-7
Prerequisites1-8
Configuring MBGP Route Preferences 1-8
Configuring the Default Local Preference 1-8
Configuring the Next Hop Attribute1-9
Configuring the AS-PATH Attribute 1-9
Tuning and Optimizing MBGP Networks 1-10
Prerequisites1-10
Configuring MBGP Soft Reset1-10
Configuring the Maximum Number of MBGP Routes for Load Balancing 1-11
Configuring a Large Scale MBGP Network1-12
Prerequisites1-12
Configuring IPv4 MBGP Peer Groups1-12
Configuring MBGP Community 1-12
Configuring an MBGP Route Reflector 1-13
Displaying and Maintaining MBGP 1-14
Displaying MBGP 1-14
Resetting MBGP Connections1-15
Clearing MBGP Information 1-15
MBGP Configuration Example (on Routers) 1-15
MBGP Configuration Example (on Switches) 1-19
i
1 MBGP Configuration
The term router refers to a router or a Layer 3 switch in this document.
When configuring MBGP, go to these sections for information you are interested in:
z MBGP Overview
z MBGP Configuration Task List
z Configuring MBGP Basic Functions
z Controlling Route Advertisement and Reception
z Configuring MBGP Route Attributes
z Tuning and Optimizing MBGP Networks
z Configuring a Large Scale MBGP Network
z Displaying and Maintaining MBGP
z MBGP Configuration Example (on Routers)
z MBGP Configuration Example (on Switches)
MBGP Overview
BGP-4 is capable of carrying routing information for IPv4 only. IETF defined multiprotocol BGP
extensions to carry routing information for multiple network layer protocols.
For a network, the multicast topology may be different from the unicast topology. To meet the
requirement, the multiprotocol BGP extensions enable BGP to carry the unicast Network Layer
Reachability Information (NLRI) and multicast NLRI separately, and the multicast NLRI is used to
perform reverse path forwarding (RPF) exclusively. In this way, route selection for a destination through
the unicast routing table and through the multicast routing table will have different results, ensuring
normal unicast and multicast routing.
Multi-protocol BGP is defined in RFC 2858 (Multiprotocol Extensions for BGP-4).
Multi-protocol BGP for IP multicast is referred to as Multicast BGP (MBGP) for short.
1-1
z This document covers configuration tasks related to multiprotocol BGP for IP multicast only. For
information about BGP, refer to BGP Configuration in the IP Routing Volume.
z For information about RPF, refer to Multicast Routing and Forwarding in the IP Multicast Volume.

z RFC2858: Multiprotocol Extensions for BGP-4
z RFC3392: Capabilities Advertisement with BGP-4
z draft-ietf-idmr-bgp-mcast-attr-00: BGP Attributes for Multicast Tree Construction
MBGP Configuration Task List

Complete the following tasks to configure MBGP:
Task Remarks
Configuring MBGP Basic Functions Required
Configuring MBGP Route Redistribution Optional
Configuring MBGP Route Summarization Optional
Controlling Route Advertising a Default Route to an IPv4 MBGP

Optional
Advertisement and Peer or Peer Group
Reception Configuring Outbound MBGP Route Filtering Optional
Configuring Inbound MBGP Route Filtering Optional
Configuring MBGP Route Dampening Optional
Configuring MBGP Route Preferences

Configuring the Default Local Preference
Configuring MBGP
Configuring the MED Attribute Optional
Route Attributes
Configuring the Next Hop Attribute
Configuring the AS-PATH Attribute
Tuning and Configuring MBGP Soft Reset Optional

Optimizing MBGP Configuring the Maximum Number of MBGP
Networks Optional
Routes
Configuring IPv4 MBGP Peer Groups Optional
Configuring a
Large Scale Configuring MBGP Community Optional
MBGP Network
Configuring an MBGP Route Reflector Optional
1-2
Configuring MBGP Basic Functions
Prerequisites
Before configuring MBGP, make sure neighboring nodes can access each other at the network layer.
Follow these steps to configure MBGP basic functions:

Specify a peer or peer group
ip-address } as-number
and its AS number Not specified by default.
as-number
Enter IPv4 MBGP address
ipv4-family multicast Required
family view
Enable a peer or peer group peer { group-name | Required

created in IPv4 unicast view ip-address } enable Not enabled by default
Specify a preferred value for peer { group-name | Optional
routes from an IPv4 MBGP ip-address } preferred-value
peer or peer group value The default preferred value is 0.
Controlling Route Advertisement and Reception

Prerequisites
You need to configure MBGP basic functions before configuring this task.
Configuring MBGP Route Redistribution
MBGP can advertise routing information in the local AS to neighboring ASs. It redistributes such routing
information from IGP into its routing table rather than learns the information by itself.
Follow these steps to configure MBGP route redistribution:

ipv4-family multicast
family view
1-3
Enable default route
default-route imported
redistribution
import-route protocol
Redistribute routes from [ process-id [ med med-value | At least one of these
another routing protocol route-policy approaches is required.
route-policy-name ] * ] No route redistribution is
network ip-address [ mask |
Inject a network into the MBGP mask-length ] [ short-cut |
routing table route-policy
route-policy-name ]
z The Origin attribute of routes redistributed into the MBGP routing table with the import-route
command is Incomplete.
z The Origin attribute of routes injected into the MBGP routing table with the network command is
IGP.
z The networks to be injected must exist in the local IP routing table, and using a route policy makes
route control more flexible.
Configuring MBGP Route Summarization
To reduce the routing table size on medium and large MBGP networks, you need to configure route
summarization on peers. MBGP supports two summarization modes: automatic and manual.
z Automatic summarization: Summarizes subnets redistributed from IGP. With the feature
configured, MBGP advertises only summary natural networks rather than subnets. The default
routes and routes injected with the network command are not summarized.
z Manual summarization: Summarizes MBGP local routes. A manual summary route has a higher
priority than an automatic one.
Follow these steps to configure MBGP route summarization:
Enter IPv4 MBGP address family view ipv4-family multicast
1-4
Enable automatic
summary automatic Required
route summarization
No route
aggregate ip-address { mask | summarization is
Configure mask-length } [ as-set | configured by default.
MBGP route attribute-policy
Choose either as
summarization Configure manual route-policy-name |
needed; if both are
route summarization detail-suppressed |
configured, the manual
origin-policy route-policy-name
route summarization
| suppress-policy
takes effect.
Advertising a Default Route to an IPv4 MBGP Peer or Peer Group
Follow these steps to advertise a default route to an MBGP peer or peer group:

family view

Advertise a default route to an
MBGP peer or peer group
route-policy-name ] default
next hop being itself to the specified MBGP peer or peer group, regardless of whether the default route
is available in the routing table.
Configuring Outbound MBGP Route Filtering
If several filtering policies are configured, they are applied in the following sequence:
z filter-policy export
z peer filter-policy export
z peer as-path-acl export
z peer ip-prefix export
z peer route-policy export
Only the routes that have passed all the configured policies can be advertised.
1-5
Follow these steps to configure BGP route distribution filtering policies:

family view
filter-policy { acl-number | ip-prefix

Configure the filtering of ip-prefix-name } export [ direct | isis
redistributed routes process-id | ospf process-id | rip process-id |
static ]
Apply a route policy to
peer { group-name | peer-address }
advertisements to an IPv4 At least one of
route-policy route-policy-name export
MBGP peer/peer group these approaches
is required. No
Reference an ACL to filter
peer { group-name | ip-address } filter-policy outbound route
advertisements to an IPv4
acl-number export filtering is
MBGP peer/peer group
configured by
Reference an AS path ACL to default
peer { group-name | ip-address } as-path-acl
filer route advertisements to an
as-path-acl-number export
IPv4 MBGP peer/peer group
Reference an IP prefix list to
peer { group-name | ip-address } ip-prefix
filer route advertisements to an
ip-prefix-name export
IPv4 MBGP peer/peer group
Configuring Inbound MBGP Route Filtering
By configuring MBGP route reception filtering policies, you can filter out unqualified routes from an
MBGP peer or peer group.
If several filtering policies are configured, they are applied in the following sequence:
z filter-policy import
z peer filter-policy import
z peer as-path-acl import
z peer ip-prefix import
z peer route-policy import
Only the routes that have passed all the configured policies can be advertised.
Follow these steps to configure MBGP route reception filtering policies:

family view
1-6
filter-policy { acl-number |
Filter incoming routes using an
ip-prefix ip-prefix-name }
ACL or IP prefix list
import
Reference a route policy to peer { group-name |
routes from an IPv4 MBGP ip-address } route-policy
peer/peer group policy-name import
At least one of these
Reference an ACL to filter peer { group-name | approaches is required.
routing information from an ip-address } filter-policy
IPv4 MBGP peer/peer group acl-number import No inbound route filtering is
Reference an AS path ACL to peer { group-name |
filter routing information from ip-address } as-path-acl
an IPv4 MBGP peer/peer group as-path-acl-number import
Reference an IP prefix list to peer { group-name |
filter routing information from ip-address } ip-prefix
an IPv4 MBGP peer/peer group ip-prefix-name import
peer { group-name |
of routes that can be received
ip-address } route-limit limit The number is unlimited by
from an IPv4 MBGP peer/peer
[ percentage ] default.
group
Members of a peer group can have different route reception filtering policies from the peer group.
Configuring MBGP Route Dampening
By configuring MBGP route dampening, you can suppress unstable routes from being added to the
MBGP routing table or being advertised to MBGP peers.

family view
dampening
[ half-life-reachable Required
Configure BGP route
half-life-unreachable reuse
dampening parameters Not configured by default
suppress ceiling | route-policy
Configuring MBGP Route Attributes

You can modify MBGP route attributes to affect route selection.
1-7
Prerequisites
Before configuring this task, you need to configure MBGP basic functions.
Configuring MBGP Route Preferences
You can reference a route policy to set preferences for routes matching it. Routes not matching it use
the default preferences.
Follow these steps to configure MBGP route preferences:

family view
preference Optional
Configure preferences for { external-preference The default preferences of
external, internal, local MBGP internal-preference multicast eBGP, iBGP, and
routes local-preference | route-policy local BGP routes are 255, 255,
route-policy-name } and 130 respectively.
Follow these steps to configure the default local preference:

family view
Configure the default local Optional

default local-preference value
preference 100 by default.
When other conditions of routes to a destination are identical, the route with the smallest MED is
selected.
1-8

default med med-value
MED value 0 by default.
of the MED of routes compare-different-as-med
from different ASs Not enabled by default
Configure
the MED Enable the comparison Optional
attribute of the MED of routes bestroute compare-med
from each AS Not enabled by default
Enable the comparison

of the MED of routes bestroute Optional
from confederation med-confederation Not enabled by default
peers
Configuring the Next Hop Attribute
You can use the peer next-hop-local command to specify the local router as the next hop of routes
sent to a multicast iBGP peer/peer group. If load balancing is configured, the router specifies itself as
the next hop of route advertisements to the multicast iBGP peer/peer group regardless of whether the
peer next-hop-local command is configured.
In a third party next hop" network, that is, the local router has two multicast eBGP peers in a broadcast
network, the router does not specify itself as the next hop of routing information sent to the eBGP peers
unless the peer next-hop-local command is configured.
Follow these steps to specify the router as the next hop of routes sent to a peer/peer group:

family view
Optional
By default, the next hop of
Specify the router as the next routes sent to a multicast eBGP
peer { group-name |
hop of routes sent to a peer/peer group is the
ip-address } next-hop-local
peer/peer group advertising router, while that of
routes sent to a multicast iBGP
peer/peer group is not.
Configuring the AS-PATH Attribute
In general, MBGP checks whether the AS_PATH attribute of a route from a peer contains the local AS
number. If yes, it discards the route to avoid routing loops.
1-9
Follow these steps to configure the AS-PATH attribute:
Specify the maximum Optional

number of times the peer { group-name | By default, the local AS
local AS number can ip-address } allow-as-loop number can not appear
appear in routes from [ number ] in routes from a
the peer/peer group peer/peer group.
Configure Optional
Disable BGP from
the By default, BGP
considering the
AS_PATH bestroute as-path-neglect considers AS_PATH
AS_PATH during best
attribute during best route
route selection
selection.
Configure updates to a Optional

peer/peer group to not peer { group-name | By default, BGP updates
keep private AS ip-address } public-as-only carry private AS
numbers numbers.
Tuning and Optimizing MBGP Networks

This task involves resetting MBGP connections and configuring load balancing.
Prerequisites
You need to configure BGP basic functions before configuring this task.
Configuring MBGP Soft Reset
After modifying a route selection policy, you have to reset MBGP connections to make it take effect,
causing short time disconnections.
After the route-refresh capability is enabled on all MBGP routers in a network, when a route selection
policy is modified on a router, the local router can perform dynamic route updates without tearing down
MBGP connections.
If the peer does not support route-refresh, you can save all route updates from the peer. When the route
selection policy changes, you can refresh the MBGP routing table and apply the new policy without
tearing down MBGP connections.
Soft reset through route-refresh
If the peer is enabled with route-refresh, when the MBGP route selection policy is modified on a router,
the router advertises a route-refresh message to its MBGP peers, which resend their routing
information to the router after receiving the message. Therefore, the local router can perform dynamic
route update and apply the new policy without tearing down MBGP connections.
Follow these steps to configure MBGP soft reset through route-refresh:
1-10
Enable BGP route refresh for a peer { group-name | ip-address } Optional

peer/peer group capability-advertise route-refresh Enabled by default
Perfomr a manual soft reset
If the peer does not support route-refresh, you can use the peer keep-all-routes command to save all
the route updates from the peer, and then use the refresh bgp ipv4 multicast command to soft-reset
MBGP connections to refresh the MBGP routing table and apply the new policy without tearing down
MBGP connections.
Follow these steps to configure MBGP manual soft reset

Disable BGP route-refresh and Optional

peer { group-name | ip-address }
multi-protocol extensions for a
capability-advertise conventional Enabled by default
peer/peer group
family view
Keep all original routes from a
peer/peer group regardless of peer { group-name | ip-address } Required
whether they pass the inbound keep-all-routes Not kept by default
filtering policies
refresh bgp ipv4 multicast { all |
Soft-reset MBGP connections
ip-address | group group-name | Optional
manually
external | internal } { export | import }
Configuring the Maximum Number of MBGP Routes for Load Balancing
Follow these steps to configure the number of MBGP routes for load balancing:

family view
Configure the maximum Required

number of MBGP routes for balance number By default, no load balancing is
load balancing configured.
1-11
Configuring a Large Scale MBGP Network
Prerequisites
Before configuring this task, you need to make peering nodes accessible to each other at the network
layer.
Configuring IPv4 MBGP Peer Groups
In a large-scale MBGP network, configuration and maintenance become difficult due to large numbers
of MBGP peers. You can configure peer groups to make management easier and improve route
distribution efficiency.
Follow these steps to configure an IPv4 MBGP peer group:
group group-name [ external | Required

Create a BGP peer group
internal ] Not created by default.
peer ip-address group Required

Add a peer into the peer group group-name [ as-number
as-number ] No peer is added by default.

family view
Enable the IPv4 unicast peer
peer group-name enable Required
group
Add an IPv4 MBGP peer to the peer ip-address group Required

peer group group-name Not configured by default.
z To configure an MBGP peer group, you need to enable the corresponding IPv4 BGP unicast peer
group in IPv4 MBGP address family view.
z Before adding an MBGP peer to an MBGP peer group, you need to add the corresponding IPv4
unicast peer to the IPv4 BGP peer group.
Configuring MBGP Community
The community attribute can be advertised between MBGP peers in different ASs. Routers in the same
community share the same policy.
You can reference a route policy to modify the community attribute for routes sent to a peer. In addition,
you can define extended community attributes as needed.
Follow these steps to configure MBGP community:
1-12
Advertise the Advertise the community peer { group-name |

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

Apply a route policy to routes advertised to
ip-address } route-policy Not configured by
an MBGP peer/peer group
route-policy-name export default.
z When configuring MBGP community, you need to reference a route policy to define the specific
community attributes, and apply the route policy for route advertisement.
z For route policy configuration, refer to Route policy Configuration in the IP Routing Volume.
Configuring an MBGP Route Reflector
To guarantee the connectivity between multicast iBGP peers in an AS, you need to make them fully
meshed. But this becomes unpractical when there are large numbers of multicast iBGP peers.
Configuring route reflectors can solve this problem.
Follow these steps to configure an MBGP route reflector:

family view
peer { group-name |
reflector and specify an MBGP
peer-address } reflect-client Not configured by default.
peer/peer group as its client

between clients Enabled by default.
Optional
Configure the cluster ID of the By default, a route reflector
reflector cluster-id cluster-id
route reflector uses its router ID as the cluster
ID.
1-13
z In general, it is not required that clients of a route reflector be 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 of the route reflector 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 to avoid routing loops.
Displaying and Maintaining MBGP

Displaying MBGP

Display the IPv4 MBGP routing display ip multicast routing-table
table [ verbose]
Display the IPv4 MBGP routing
display ip multicast routing-table
information matching the
ip-address [ mask-length | mask ] Available in any view
specified destination IP
[ longer-match ] [ verbose ]
address
Display MBGP peer group display bgp multicast group
information [ group-name ]
Display the advertised
display bgp multicast network Available in any view
networks
display bgp multicast paths

Display AS path information Available in any view
[ as-regular-expression ]
display bgp multicast peer [ ip-address
Display MBGP peer/peer group
{ log-info | verbose } | group-name Available in any view
information
log-info | verbose ]
display bgp multicast routing-table

Display MBGP routing
[ ip-address [ { mask | mask-length } Available in any view
information
[ longer-prefixes ] ] ]
information matching the AS Available in any view
as-path-acl as-path-acl-number
path ACL
Display MBGP CIDR routing display bgp multicast routing-table
information cidr

Display MBGP routing community[ aa:nn&<1-13> ]
information matching the [ no-advertise | no-export | Available in any view
specified BGP community no-export-subconfed ] *
[ whole-match ]

Display MBGP routing community-list
information matching an MBGP { basic-community-list-number Available in any view
community list [ whole-match ] |
1-14
Display MBGP dampened display bgp multicast routing-table
routing information dampened
Display MBGP dampening display bgp multicast routing-table
parameter information dampening parameter
information originating from Available in any view
different-origin-as
different ASs
flap-info [ regular-expression
Display IPv4 MBGP routing flap
as-regular-expression | as-path-acl Available in any view
statistics
as-path-acl-number | ip-address [ { mask |
mask-length } [ longer-match ] ] ]
Display IPv4 MBGP routing
peer ip-address { advertised-routes |
information sent to or received Available in any view
received-routes } [ network-address
from an MBGP peer
[ mask | mask-length ] | statistic ]
Display IPv4 MBGP routing display bgp multicast routing-table
information matching an AS regular-expression Available in any view
regular expression as-regular-expression
Display IPv4 MBGP routing display bgp multicast routing-table
statistics statistic
Resetting MBGP Connections

reset bgp ipv4 multicast { all |
Reset specified MBGP
as-number | ip-address | group Available in user view
connections
group-name | external | internal }
Clearing MBGP Information

Clear dampened routing
reset bgp ipv4 multicast dampening Available in user
information and release
[ ip-address [ mask | mask-length ] ] view
suppressed routes
reset bgp ipv4 multicast flap-info [ regexp
Clear MBGP route flap Available in user
as-path-regexp | as-path-acl as-path-acl-number
statistics view
| ip-address [ mask | mask-length ] ]
MBGP Configuration Example (on Routers)

As shown in the following figure:

z PIM-SM 1 is in AS 100 and PIM-SM 2 is in AS 200. OSPF is the IGP in the two ASs, and MBGP
runs between the two ASs to exchange multicast route information.
1-15
z The multicast source belongs to PIM-SM 1, and the receiver belongs to PIM-SM 2.
z It is required that the respective Loopback 0 of Router A and Router B be configured as the C-BSR
and C-RP of the respective PIM-SM domains.
z It is required that Router A and Router B establish an MSDP peer relationship through MBGP.
Network diagram
Figure 1-1 Network diagram for MBGP configuration
/1
S2
S2
/0
1/0
/0
S2
S2
Eth
/1
Source - 10.110.1.100/24 Router C Eth1/0 10.110.2.1/24
Router A Eth1/0 10.110.1.1/24 S2/0 192.168.4.1/24
POS5/0 192.168.1.1/24 S2/1 192.168.2.2/24
Loop0 1.1.1.1/32 Loop0 3.3.3.3/32
Router B POS5/0 192.168.1.2/24 Router D S2/0 192.168.3.2/24
S2/0 192.168.2.1/24 S2/1 192.168.4.2/24
S2/1 192.168.3.1/24 Loop0 4.4.4.4/32
Loop0 2.2.2.2/32
1) Configure IP addresses for router interfaces as shown in the above figure (omitted).
2) Configure OSPF (omitted).
3) Enable IP multicast routing, PIM-SM and IGMP, and configure a PIM-SM domain border.
# Enable IP multicast routing on Router A, and enable PIM-SM on each interface.
The configuration on Router B and Router D is similar to the configuration on Router A.

# Enable IP multicast routing on Router C, enable PIM-SM on each interface, and enable IGMP on the
host-side interface Ethernet1/0.
1-16
[RouterC-Serial2/0] pim sm
[RouterC-Serial2/1] pim sm
[RouterC-Ethernet1/0] pim sm
# Configure a PIM domain border on Router A.

[RouterA-Pos5/0] pim bsr-boundary
# Configure a PIM domain border on Router B.

# Configure the C-BSR and C-RP on Router A.
[RouterA-LoopBack0] pim sm
[RouterA] pim
[RouterA-pim] c-bsr loopback 0
[RouterA-pim] c-rp loopback 0
[RouterA-pim] quit
# Configure the C-BSR and C-RP on Router B.

[RouterB-LoopBack0] ip address 2.2.2.2 32
[RouterB] pim
[RouterB-pim] quit
5) Configure BGP, specify the MBGP peer and enable direct route redistribution.
# On Router A, configure the MBGP peer and enable direct route redistribution.
[RouterA] bgp 100
[RouterA-bgp] import-route direct
1-17
[RouterA-bgp] ipv4-family multicast
[RouterA-bgp-af-mul] peer 192.168.1.2 enable
[RouterA-bgp-af-mul] import-route direct
[RouterA-bgp-af-mul] quit
[RouterA-bgp] quit
# On Router B, configure the MBGP peer and enable route redistribution from OSPF.
[RouterB] bgp 200
[RouterB-bgp] ipv4-family multicast
[RouterB-bgp-af-mul] peer 192.168.1.1 enable
[RouterB-bgp-af-mul] import-route ospf 1
[RouterB-bgp-af-mul] quit
[RouterB-bgp] quit
6) Configure MSDP peer
# Specify the MSDP peer on Router A.
[RouterA] msdp
[RouterA-msdp] peer 192.168.1.2 connect-interface pos 5/0
[RouterA-msdp] quit
# Specify the MSDP peer on Router B.

[RouterB] msdp
[RouterB-msdp] quit
You can use the display bgp multicast peer command to display MBGP peers on each router. For
example,
# Display MBGP peers on Router B.
[RouterB] display bgp multicast peer

192.168.1.1 4 100 56 56 0 0 00:40:54 Established
You can use the display msdp brief command to display MSDP peers on a router. For example,
Display brief information about MSDP peers on Router B.
1 1 0 0 0 0
192.168.1.1 Up 00:07:17 100 1 0
1-18
MBGP Configuration Example (on Switches)

z PIM-SM 1 is in AS 100 and PIM-SM 2 is in AS 200. OSPF is the IGP in the two ASs, and MBGP
runs between the two ASs to exchange multicast route information.
z The multicast source belongs to PIM-SM 1, and the receiver belongs to PIM-SM 2.
z It is required that the respective Loopback 0 of Switch A and Switch B be configured as the C-BSR
and C-RP of the respective PIM-SM domains.
z Router A and Router B establishes an MSDP peer relationship through MBGP.
Network diagram
Figure 1-2 Network diagram for MBGP configuration
Vla
03
n-i
nt1
nt1
n-i
02
Vla
03
00
Vla
nt1
nt2
n-i
n-i
n-i
nt1
Vla
Vla
02

Source - 10.110.1.100/24 Switch C Vlan-int200 10.110.2.1/24
Switch A Vlan-int100 10.110.1.1/24 Vlan-int102 192.168.2.2/24
Vlan-int101 192.168.1.1/24 Vlan-int104 192.168.4.1/24
Loop0 1.1.1.1/32 Loop0 3.3.3.3/32
Switch B Vlan-int101 192.168.1.2/24 Switch D Vlan-int103 192.168.3.2/24
Vlan-int102 192.168.2.1/24 Vlan-int104 192.168.4.2/24
Vlan-int103 192.168.3.1/24 Loop0 4.4.4.4/32
Loop0 2.2.2.2/32
1) Configure IP addresses for interfaces as shown in the above figure (omitted).

2) Configure OSPF (omitted).
3) Enable IP multicast routing, PIM-SM and IGMP, and configure a PIM-SM domain border.
# Enable IP multicast routing on Switch A, and enable PIM-SM on each interface.
1-19
The configuration on Switch B and Switch D is similar to the configuration on Switch A.

# Enable IP multicast routing on Switch C, enable PIM-SM on each interface, and enable IGMP on the
[SwitchC-Vlan-interface102] pim sm
# Configure a PIM domain border on Switch A.

[SwitchA-Vlan-interface101] pim bsr-boundary
# Configure a PIM domain border on Switch B.

4) Configure Loopback 0 and the position of C-BSR, and C-RP.
# Configure Loopback 0 and configure it as the C-BSR and C-RP on Switch A.
[SwitchA-LoopBack0] ip address 1.1.1.1 32
[SwitchA-LoopBack0] pim sm
[SwitchA] pim
[SwitchA-pim] c-bsr loopback 0
[SwitchA-pim] c-rp loopback 0
[SwitchA-pim] quit
# Configure Loopback 0 and configure it as the C-BSR and C-RP on Switch B.

[SwitchB-LoopBack0] ip address 2.2.2.2 32
[SwitchB] pim
[SwitchB-pim] quit
1-20
5) Configure BGP, specify the MBGP peer and enable direct route redistribution.
# On Switch A, configure the MBGP peer and enable direct route redistribution.
[SwitchA] bgp 100
[SwitchA-bgp] import-route direct
[SwitchA-bgp] ipv4-family multicast
[SwitchA-bgp-af-mul] peer 192.168.1.2 enable
[SwitchA-bgp-af-mul] import-route direct
[SwitchA-bgp-af-mul] quit
[SwitchA-bgp] quit
# On Switch B, configure the MBGP peer and enable route redistribution from OSPF.
[SwitchB] bgp 200
[SwitchB-bgp] ipv4-family multicast
[SwitchB-bgp-af-mul] peer 192.168.1.1 enable
[SwitchB-bgp-af-mul] import-route ospf 1
[SwitchB-bgp-af-mul] quit
[SwitchB-bgp] quit
6) Configure MSDP peer
# Specify the MSDP peer on Switch A.
[SwitchA] msdp
[SwitchA-msdp] peer 192.168.1.2 connect-interface vlan-interface 101
[SwitchA-msdp] quit
# Specify the MSDP peer on Switch B.

[SwitchB] msdp
[SwitchB-msdp] quit
You can use the display bgp multicast peer command to display MBGP peers on a switch. For
example, display MBGP peers on Switch B.
[SwitchB] display bgp multicast peer

192.168.1.1 4 100 56 56 0 0 00:40:54 Established
You can use the display msdp brief command to display MSDP peers on a switch. For example,
display brief information about MSDP peers on Switch B.
1-21
1 1 0 0 0 0
192.168.1.1 Up 00:07:17 100 1 0
1-22
Table of Contents
1 IPv6 MBGP Configuration1-1

IPv6 MBGP Overview 1-1
IPv6 MBGP Configuration Task List 1-2
Configuring IPv6 MBGP Basic Functions 1-2
Configuring an IPv6 MBGP Peer1-3
Configuring a Preferred Value for Routes from a Peer/Peer Group 1-3
Injecting a Local IPv6 MBGP Route 1-4
Configuring IPv6 MBGP Route Redistribution 1-4
Advertising a Default Route to a Peer or Peer Group 1-5
Configure Outbound IPv6 MBGP Route Filtering1-5
Configuring Inbound IPv6 MBGP Route Filtering1-6
Configuring IPv6 MBGP Route Dampening 1-6
Configuring IPv6 MBGP Route Attributes 1-7
Configuring IPv6 MBGP Route Preferences 1-7
Configuring the Default Local Preference 1-8
Configuring the NEXT_HOP Attribute 1-8
Configuring the AS_PATH Attribute 1-9
Tuning and Optimizing IPv6 MBGP Networks 1-9
Configuring IPv6 MBGP Soft Reset 1-10
Configuring the Maximum Number of Equal-Cost Routes for Load-Balancing1-11
Configuring a Large Scale IPv6 MBGP Network 1-11
Configuring an IPv6 MBGP Peer Group1-11
Configuring IPv6 MBGP Community 1-12
Configuring an IPv6 MBGP Route Reflector 1-13
Displaying and Maintaining IPv6 MBGP 1-14
Displaying IPv6 MBGP 1-14
Resetting IPv6 MBGP Connections 1-15
Clearing IPv6 MBGP Information 1-15
IPv6 MBGP Configuration Example (on Routers)1-15
IPv6 MBGP Configuration Example (on Switches)1-18
i
1 IPv6 MBGP Configuration
When configuring IPv6 MBGP, go to these sections for information you are interested in:
z IPv6 MBGP Overview
z IPv6 MBGP Configuration Task List
z Displaying and Maintaining IPv6 MBGP
z IPv6 MBGP Configuration Example (on Routers)
z IPv6 MBGP Configuration Example (on Switches)
This chapter describes only configuration for IPv6 MBGP. For IPv6 BGP related information, refer to
IPv6 BGP Configuration in the IP Routing Volume.
IPv6 MBGP Overview

BGP-4 is capable of carrying routing information for IPv4 only. IETF defined multi-protocol BGP
extensions to carry routing information for multiple network layer protocols.
For an IPv6 network, the IPv6 multicast topology need be different from the IPv6 unicast topology. To
meet the requirement, the multi-protocol BGP extensions enable IPv6 BGP to carry the IPv6 unicast
Network Layer Reachability Information (NLRI) and IPv6 multicast NLRI separately, and the multicast
NLRI is used to perform reverse path forwarding (RPF) exclusively. In this way, route selection for a
destination through the IPv6 unicast routing table and through the IPv6 multicast routing table will have
different results, ensuring the normal unicast and multicast operation across ASs.
Multi-protocol BGP is defined in RFC 2858 (Multiprotocol Extensions for BGP-4).
Multi-protocol BGP for IPv6 multicast is referred to as IPv6 multicast BGP (IPv6 MBGP).
1-1
This document covers configuration tasks related to multi-protocol BGP for IPv6 multicast only. For
BGP related information, refer to BGP Configuration in the IP Routing Volume.
For information about RPF, refer to Multicast Routing and Forwarding in the IP Multicast Volume.
IPv6 MBGP Configuration Task List

Complete the following tasks to configure IPv6 MBGP:
Task Remarks
Configuring IPv6 Configuring an IPv6 MBGP Peer Required

MBGP Basic Configuring a Preferred Value for Routes from a
Functions Optional
Peer/Peer Group
Injecting a Local IPv6 MBGP Route Optional
Configuring IPv6 MBGP Route Redistribution

Controlling Route Advertising a Default Route to a Peer or Peer Group Optional
Distribution and
Reception Configure Outbound IPv6 MBGP Route Filtering Optional
Configuring Inbound IPv6 MBGP Route Filtering Optional
Configuring IPv6 MBGP Route Dampening Optional
Configuring IPv6 MBGP Route Preferences
Configuring the Default Local Preference Optional
Configuring IPv6
MBGP Route Configuring the MED Attribute
Attributes
Configuring the NEXT_HOP Attribute Optional
Configuring the AS_PATH Attribute Optional
Tuning and Configuring IPv6 MBGP Soft Reset Optional

Optimizing IPv6 Configuring the Maximum Number of Equal-Cost Routes
MBGP Networks Optional
for Load-Balancing
Configuring an IPv6 MBGP Peer Group Optional
Configuring a Large
Scale IPv6 MBGP Configuring IPv6 MBGP Community Optional
Network
Configuring an IPv6 MBGP Route Reflector Optional
Configuring IPv6 MBGP Basic Functions

IPv6 MBGP is an application of multi-protocol BGP. Therefore, before configuring IPv6 MBGP, you need
to
z Enable IPv6
z Configure network layer addresses for interfaces
1-2
z Complete BGP basic configuration
Configuring an IPv6 MBGP Peer
Follow these steps to configure an IPv6 MBGP peer

Enable BGP and enter BGP Required

bgp as-number
view Not enabled by default
Specify a IPv6 BGP peer and peer ipv6-address as-number Required

its AS number as-number Not configured by default
family view
Required
Enable the IPv6 MBGP peer peer ipv6-address enable
Not enabled by default.
Configuring a Preferred Value for Routes from a Peer/Peer Group
Follow these steps to configure a preferred value for routes from a peer/peer group:

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

routes received from the IPv6 ipv6-address } preferred-value The preferred value defaults to
MBGP peer/peer group value 0.
If you both reference a route policy and use the command peer { ipv6-group-name | ipv6-address }
preferred-value value to set a preferred value for routes from a peer, the route policy sets a non-zero
preferred value for routes matching it. Other routes not matching the route policy uses the value set with
the command. If the preferred value in the route policy is zero, the routes matching it will also use the
value set with the command. For information about using a route policy to set a preferred value, refer to
the peer { ipv6-group-name | ipv6-address } route-policy route-policy-name { import | export }
command and the apply preferred-value preferred-value command in Route Policy Commands in the
IP Routing Volume.
1-3

z Enable IPv6.
z Configure the IPv6 MBGP basic functions.
Injecting a Local IPv6 MBGP Route
Follow these steps to inject a local IPv6 MBGP route:


family view
network ipv6-address Required

Inject a network to the IPv6
prefix-length [ route-policy
MBGP routing table Not injected by default
route-policy-name | short-cut ]
Configuring IPv6 MBGP Route Redistribution
Follow these steps to configure IPv6 MBGP route redistribution:
To do Use the command Description

Enter the MBGP multicast
address family view
Enable default route Optional

redistribution into the IPv6 default-route imported By default, default route
MBGP routing table redistribution is not allowed.
import-route protocol
Enable route redistribution from [ process-id ] [ med med-value | Required
another routing protocol route-policy Not enabled by default
If the default-route imported command is not configured, using the import-route command cannot
redistribute any IGP default route.
1-4
Advertising a Default Route to a Peer or Peer Group
Follow these steps to advertise a default route to a peer or peer group

family view
peer { ipv6-group-name | ipv6-address } Required

Advertise a default route to an
IPv6 MBGP peer or peer group
route-policy-name ] default
next hop being itself to the specified IPv6 MBGP peer/peer group, regardless of whether the default
route is available in the routing table.
Configure Outbound IPv6 MBGP Route Filtering
Follow these steps to configure outbound IPv6 MBGP route filtering:


family view
filter-policy { acl6-number | Use any of the commands.
Configure the filtering of
ipv6-prefix ipv6-prefix-name } No filtering is configured by
outgoing routes
export [ protocol process-id ] default.
Specify an IPv6 ACL to filer peer { ipv6-group-name | You can configure filter policies
routes advertised to a ipv6-address } filter-policy as needed. If you configure
peer/peer group acl6-number export multiple filter policies, they will
be applied in the following
Specify an AS path ACL to filter peer { ipv6-group-name | order:
IPv6 MBGP routing information ipv6-address } as-path-acl
advertised to a peer/peer group as-path-acl-number export z filter-policy export
z peer filter-policy export
Specify an IPv6 prefix list to filer peer { ipv6-group-name | z peer as-path-acl export
routes advertised to a ipv6-address } ipv6-prefix z peer ipv6-prefix export
peer/peer group ipv6-prefix-name export
z peer route-policy export
A filter policy can be applied
only after the previous one is
Apply a route policy to routes passed; routing information can
advertised to a peer/peer group be advertised only after
passing all the filter policies
configured.
1-5
z Members of an IPv6 MBGP peer group must have the same outbound route filtering policy as the
peer group.
z IPv6 BGP advertises redistributed routes passing the specified policy to the IPv6 MBGP peer.
Configuring Inbound IPv6 MBGP Route Filtering
Follow these steps to configure IPv6 MBGP inbound route filtering:


family view
filter-policy { acl6-number | Use any of the commands
ipv6-prefix ipv6-prefix-name } By default, advertised routes
filtering
import are not filtered.
peer { ipv6-group-name | You can configure a filtering
Apply a route policy to routes
ipv6-address } route-policy policy as needed.
from a peer/peer group
route-policy-name import If several filtering policies are
configured, they are applied in
Specify an IPv6 ACL to filter the following sequence:
ipv6-address } filter-policy
routes from a peer/peer group filter-policy import
acl6-number import z
z peer filter-policy import

Specify an AS path ACL to filter peer { ipv6-group-name |
z peer as-path-acl import
IPv6 BGP routing information ipv6-address } as-path-acl
from a peer/peer group as-path-acl-number import z peer ip-prefix import
z peer route-policy import
A filter policy can be applied
peer { ipv6-group-name | only after the previous one is
Specify an IPv6 prefix list to filer
ipv6-address } ipv6-prefix passed; routing information can
routes from a peer/peer group
ipv6-prefix-name import be received only after passing
all the filter policies configured.
Specify the upper limit of peer { ipv6-group-name | Optional

prefixes that can be imported ipv6-address } route-limit limit The number is unlimited by
from a peer/peer group [ percentage ] default.
A peer can has an inbound route filtering policy different from that of the peer group it belongs to. That
is, peer group members can have different inbound route filtering policies.
Configuring IPv6 MBGP Route Dampening
Follow these steps to configure IPv6 MBGP route dampening parameters:
1-6
family view
dampening [ half-life-reachable Optional

Configure IPv6 MBGP route
half-life-unreachable reuse suppress ceiling Not configured by
dampening parameters
| route-policy route-policy-name ]* default
Configuring IPv6 MBGP Route Attributes

This section describes how to use IPv6 MBGP route attributes to affect IPv6 MBGP route selection.
IPv6 MBGP route attributes involve:
z IPv6 MBGP protocol preference
z Default LOCAL_PREF attribute
z MED attribute
z NEXT_HOP attribute
z AS_PATH attribute

z Enable IPv6
z Configure the IPv6 MBGP basic functions
Configuring IPv6 MBGP Route Preferences
Follow these steps to configure IPv6 MBGP route preferences:


family view
preference Optional
Configure preferences for { external-preference The default preference values
external, internal, local IPv6 internal-preference of external, internal and local
MBGP routes local-preference | route-policy routes are 255, 255, and 130,
route-policy-name } respectively.
1-7
Follow these steps to configure the default local preference:

family view
Optional
Set the default local preference default local-preference value By default, the default local
preference is 100.


family view
Optional
Configure a default MED value default med med-value By default, the default
med-value is 0.
Enable the comparison of the Optional
MED for routes from different compare-different-as-med
ASs Not enabled by default

bestroute compare-med
MED for routes from each AS Disabled by default
MED for routes from bestroute med-confederation
confederation peers Disabled by default
Configuring the NEXT_HOP Attribute
You can use the peer next-hop-local command to specify the local router as the next hop of routes
sent to an IPv6 multicast iBGP peer/peer group. If load balancing is configured, the router specifies itself
as the next hop of routes sent to the IPv6 multicast iBGP peer/peer group regardless of whether the
peer next-hop-local command is configured.
In a third party next hop" network, that is, the local router has two IPv6 multicast eBGP peers in a
broadcast network, the router does not specify itself as the next hop of routes sent to the EBGP peers
by default.
Follow these steps to specify the router as the next hop of routes sent to a peer/peer group:
1-8
family view
Optional
By default, IPv6 MBGP
Configure the router as the next specifies the local router as the
hop of routes sent to the next hop for routes sent to an
ipv6-address } next-hop-local
peer/peer group eBGP peer/peer group, but not
for routes sent to an iBGP
peer/peer group.
Configuring the AS_PATH Attribute
Follow these steps to configure the AS_PATH attribute:


family view
appear in the AS-PATH of
routes from a peer/peer group
and specify the number of
ipv6-address } allow-as-loop
times that the local AS number Not allowed by default
[ number ]
can appear in the AS-PATH of
routes from the peer/peer
group
Disable IPv6 MBGP from Optional
considering the AS_PATH bestroute as-path-neglect
during best route selection Enabled by default
Optional
Configure updates to a
peer { ipv6-group-name | By default, outbound IPv6
peer/peer group to carry only
ipv6-address } public-as-only MBGP updates can carry
the public AS number
private AS numbers.
Tuning and Optimizing IPv6 MBGP Networks

Before tuning and optimizing an OSPF network, perform the following tasks:
z Enable IPv6
z Configure the IPv6 MBGP basic functions
1-9
Configuring IPv6 MBGP Soft Reset
After modifying a route selection policy, you have to reset IPv6 MBGP connections to make it take effect,
causing short time disconnections.
After the route-refresh capability is enabled on all IPv6 MBGP routers in a network, when a route
selection policy is modified on a router, the local router can perform dynamic route updates without
tearing down IPv6 MBGP connections.
If the peer does not support route-refresh, you can save all route updates from the peer. When the route
selection policy changes, you can refresh the IPv6 MBGP routing table and apply the new policy without
Soft reset through route-refresh
If the peer is enabled with route-refresh, when the IPv6 MBGP route selection policy is modified on a
router, the router advertises a route-refresh message to its IPv6 MBGP peers, which resend their
routing information to the router after receiving the message. Therefore, the local router can perform
dynamic route update and apply the new policy without tearing down IPv6 MBGP connections.
Follow these steps to configure IPv6 MBGP soft reset through route-refresh:


Enable IPv6 BGP route refresh
ipv6-address } capability-advertise
for a peer/peer group Enabled by default
route-refresh
Perform a manual soft-reset
If the peer does not support route-refresh, you can use the peer keep-all-routes command to save all
the route updates from the peer, and then use the refresh bgp ipv6 multicast command to soft-reset
IPv6 MBGP connections to refresh the IPv6 MBGP routing table and apply the new policy without
Follow these steps to perform a manual soft-reset

family view
Keep all routes from a
peer/peer group regardless of peer { ipv6-group-name | Required
whether they pass the inbound ipv6-address } keep-all-routes Not kept by default
filtering policy
1-10
refresh bgp ipv6 multicast

Soft-reset IPv6 MBGP { all | ipv6-address | group
Optional
connections manually ipv6-group-name | external |
internal } { export | import }
Configuring the Maximum Number of Equal-Cost Routes for Load-Balancing
Follow these steps to configure the maximum number of equal-cost routes for load-balancing:

family view
Configure the maximum Required

number of equal-cost routes for balance number By default, load balancing is
load balancing disabled.
Configuring a Large Scale IPv6 MBGP Network

Before configuring the following tasks, you need to configure IPv6 MBGP basic functions.
Configuring an IPv6 MBGP Peer Group
For easy management and configuration, you can organize some IPv6 MBGP peers having the same
route update policy into a group, known as a peer group. A policy configured for a peer group applies to
all the members in the group.
Follow these steps to configure an IPv6 MBGP peer group:

group ipv6-group-name
Create an IPv6 BGP peer group Required
[ external | internal ]
peer ipv6-address group Required

Add a peer to the peer group ipv6-group-name By default, no peer is
[ as-number as-number ] added.
Enable the configured IPv6 unicast

peer ipv6-group-name
BGP peer group to create the IPv6 Required
enable
MBGP peer group
1-11
Required
Add the IPv6 MBGP peer into the peer peer ipv6-address group
group ipv6-group-name By default, no peer is
added.
z To create an IPv6 MBGP peer group, you need to enable an existing IPv6 unicast peer group in
IPv6 MBGP address family view.
z Before adding an IPv6 MBGP peer to the IPv6 MBGP peer group, you need to add the
corresponding IPv6 BGP unicast peer to the corresponding IPv6 BGP unicast peer group.
Configuring IPv6 MBGP Community
A peer group allows a group of peers to share the same policy, while a community allows a group of
IPv6 MBGP routers in multiple ASs to share the same policy. The community attribute is propagated
among IPv6 MBGP peers and not restricted to AS boundaries.
You can reference a route policy to modify the community attribute for routes sent to a peer. In addition,
you can define extended community attributes as needed.
Follow these steps to advertise the community attribute to an IPv6 MBGP peer/peer group:


family view
Required
Advertise the community peer { ipv6-group-name |
attribute to an IPv6 MBGP ipv6-address } By default, no community
peer/peer group advertise-community attribute is advertised to any
peer group/peer.
Required
Advertise the extended peer { ipv6-group-name | By default, no extended
community attribute to an IPv6 ipv6-address } community attribute is
MBGP peer/peer group advertise-ext-community advertised to any peer/peer
group.
Apply a route policy to routes peer { ipv6-group-name | Required
sent to an IPv6 MBGP ipv6-address } route-policy
peer/peer group route-policy-name export Not configured by default
1-12
z You need to configure a route policy to define the community attribute, and apply the policy to
outgoing routes.
z For route policy configuration, refer to Route Policy Configuration in the IP Routing Volume.
Configuring an IPv6 MBGP Route Reflector
To guarantee connectivity between IPv6 multicast iBGP peers, you need to make them fully meshed,
but it becomes unpractical when there are too many IPv6 multicast iBGP peers. Using route reflectors
can solve the problem.
Follow these steps to configure an IPv6 BGP route reflector:

family view
Configure the router as a route
reflector and specify an IPv6 peer { ipv6-group-name | Required
MBGP peer/peer group as its ipv6-address } reflect-client Not configured by default
client

between clients Enabled by default
Optional
route reflector cluster-id By default, a route reflector uses
its router ID as the cluster ID.
z The clients of a route reflector should not be fully meshed, and the route reflector reflects the routes
of a client to the other clients. If the clients are fully meshed, you need to disable route reflection
between clients to reduce routing costs.
z If a cluster has multiple route reflectors, you need to specify the same cluster ID for these route
reflectors to avoid routing loops.
1-13
Displaying and Maintaining IPv6 MBGP
Displaying IPv6 MBGP

Display the IPv6 MBGP peer display bgp ipv6 multicast group Available in any
group information [ ipv6-group-name ] view
Available in any
information injected with the display bgp ipv6 multicast network
view
network command
Display the IPv6 MBGP AS display bgp ipv6 multicast paths Available in any
path information of routes [ as-regular-expression ] view
display bgp ipv6 multicast peer

Display IPv6 MBGP peer/peer [ group-name log-info | ipv4-address Available in any
group information verbose | ipv6-address { log-info | view
verbose } ]
Display IPv6 MBGP routing display bgp ipv6 multicast routing-table Available in any
table information [ ipv6-address prefix-length ] view
display bgp ipv6 multicast routing-table Available in any
information matching a AS path
as-path-acl as-path-acl-number view
ACL
display bgp ipv6 multicast routing-table

community [ aa:nn<1-13> ] [ no-advertise | Available in any
information with the specified
no-export | no-export-subconfed ]* view
community attribute
[ whole-match ]

Display routing information community-list
Available in any
matching an IPv6 MBGP { basic-community-list-number
view
community list [ whole-match ] |
Display IPv6 MBGP dampened display bgp ipv6 multicast routing-table Available in any
routing information dampened view
Display IPv6 MBGP dampening display bgp ipv6 multicast routing-table Available in any
parameter information dampening parameter view
information originated from
different-origin-as view
different ASs

flap-info [ regular-expression
Display IPv6 MBGP routing flap Available in any
as-regular-expression | as-path-acl
statistics view
as-path-acl-number | network-address
[ prefix-length [ longer-match ] ] ]
Display the IPv6 MBGP routes display bgp ipv6 multicast routing-table
received from or advertised to peer { ipv4-address | ipv6-address } Available in any
the IPv6 MBGP peer or peer { advertised-routes | received-routes } view
group [ network-address prefix-length | statistic ]
Display IPv6 multicast routing
information matching an AS
regular-expression as-regular-expression view
regular expression
Display IPv6 MBGP routing display bgp ipv6 multicast routing-table Available in any
statistics statistic view
1-14
Display the IPv6 MBGP routing display ipv6 multicast routing-table Available in any
table information [ verbose ] view
Display the multicast routing display ipv6 multicast routing-table
Available in any
information of the specified ipv6-address prefix-length [ longer-match ]
view
destination address [ verbose ]
Resetting IPv6 MBGP Connections
When an IPv6 MBGP route policy is changed, you can make the new configuration effective by resetting
the IPv6 MBGP connections.
reset bgp ipv6 multicast { as-number |
Reset specified IPv6 Available in user
ipv6-address [ flap-info ] | all | group
MBGP connections view
ipv6-group-name | external | internal }
Clearing IPv6 MBGP Information

Clear dampened IPv6 MBGP
reset bgp ipv6 multicast dampening Available in user
routing information and release
[ ipv6-address prefix-length ] view
suppressed routes
reset bgp ipv6 multicast flap-info

Clear IPv6 MBGP route flap [ ipv6-address/prefix-length | regexp Available in user
statistics as-path-regexp | as-path-acl view
as-path-acl-number ]
IPv6 MBGP Configuration Example (on Routers)


z IPv6 PIM-SM 1 is in AS 100 and IPv6 PIM-SM 2 is in AS 200. OSPFv3 is the IGP in the two ASs,
and IPv6 MBGP runs between the two ASs to exchange IPv6 multicast route information.
z The multicast source belongs to IPv6 PIM-SM 1, and the receiver belongs to IPv6 PIM-SM 2.
z It is required that the respective POS 5/0 of Router A and Router B be configured as the C-BSR
and C-RP of the respective IPv6 PIM-SM domains.
1-15
Network diagram
Figure 1-1 Network diagram for IPv6 MBGP configuration
AS 100 AS 200
Router A Router B
POS5/0 POS5/0
Receiver
/1
S2
Eth1/0
S2
/0
1/0
/0
S2
Source
S2
Eth
/1
S2/1 S2/0
IPv6 PIM-SM 1
Router D Router C
IPv6 PIM-SM 2
IPv6 MBGP peers

Source - 1002::100/64 Router C Eth1/0 3002::1/64
Router A Eth1/0 1002::1/64 S2/0 3001::1/64
POS5/0 1001::1/64 S2/1 2001::2/64
Router B POS5/0 1001::2/64 Router D S2/0 2002::2/64
S2/0 2001::1/64 S2/1 3001::2/64
S2/1 2002::1/64
1) Configure IPv6 addresses for router interfaces as shown in the above figure (omitted).
2) Configure OSPFv3 for the routers to learn routes from each other in each AS (omitted).
3) Enable IPv6 multicast routing, IPv6 PIM-SM and MLD, and configure an IPv6 PIM-SM domain
border.
# Enable IPv6 multicast routing on Router A, and enable PIM-SM on each interface.
The configuration on Router B and Router D is similar to the configuration on Router A.

# Enable IPv6 multicast routing on Router C, enable IPv6 PIM-SM on each interface, and enable MLD
on the host-side interface Ethernet1/0.
[RouterC] multicast ipv6 routing-enable
[RouterC-Serial2/0] pim ipv6 sm
1-16
[RouterC-Serial2/1] pim ipv6 sm
[RouterC-Ethernet1/0] pim ipv6 sm
[RouterC-Ethernet1/0] mld enable
# Configure an IPv6 PIM domain border on Router A.

[RouterA-Pos5/0] pim ipv6 bsr-boundary
# Configure an IPv6 PIM domain border on Router B.

[RouterB-Pos5/0] pim ipv6 bsr-boundary
4) Configure the position of C-BSR and C-RP.
# Configure the position of C-BSR and C-RP on Router A.
[RouterA] pim ipv6
[RouterA-pim6] c-bsr 1001::1
[RouterA-pim6] c-rp 1001::1
[RouterA-pim6] quit
# Configure the position of C-BSR and C-RP on Router B.

[RouterB] pim ipv6
[RouterB-pim6] c-bsr 1001::2
[RouterB-pim6] c-rp 1001::2
[RouterB-pim6] quit
5) Configure BGP, and specify the IPv6 MBGP peer.
# On Router A, configure the IPv6 MBGP peer.
[RouterA] ipv6
[RouterA] bgp 100
[RouterA-bgp-af-ipv6] import-route direct
[RouterA-bgp-af-ipv6] quit
[RouterA-bgp] ipv6-family multicast
[RouterA-bgp-af-ipv6-mul] peer 1001::2 enable
[RouterA-bgp-af-ipv6-mul] import-route direct
[RouterA-bgp-af-ipv6-mul] quit
[RouterA-bgp] quit
# On Router B, configure the IPv6 MBGP peers and redistribute OSPF routes.
[RouterB] ipv6
[RouterB] bgp 200
1-17
[RouterB-bgp-af-ipv6] import-route ospfv3 1
[RouterB-bgp] ipv6-family multicast
[RouterB-bgp-af-ipv6-mul] peer 1001::1 enable
[RouterB-bgp-af-ipv6-mul] import-route ospfv3 1
[RouterB-bgp-af-ipv6-mul] quit
[RouterB-bgp] quit
You can use the display bgp ipv6 multicast peer command to display IPv6 MBGP peers on each
router. For example, display IPv6 MBGP peers on Router B.
[RouterB] display bgp ipv6 multicast peer

1001::1 4 100 56 56 0 0 00:40:54 Established
IPv6 MBGP Configuration Example (on Switches)


z IPv6 PIM-SM 1 is in AS 100 and IPv6 PIM-SM 2 is in AS 200. OSPFv3 is the IGP in the two ASs,
and IPv6 MBGP runs between the two ASs to exchange IPv6 multicast route information.
z The IPv6 multicast source belongs to IPv6 PIM-SM 1 and the receiver belongs to IPv6 PIM-SM 2.
z It is required that the respective VLAN-interface 101 of Switch A and Switch B be configured as the
C-BSR and C-RP of the respective IPv6 PIM-SM domains.
1-18
Network diagram
Figure 1-2 Network diagram for IPv6 MBGP configuration
AS 100 AS 200
Switch A Switch B
Vla
03
n-i
nt1
nt1
n-i
02
Vla
3
t10
00
Vla
nt2
n
n-i
n-i
Source
n-i
n
Vla
t10
Vla
2
Vlan-int104
Vlan-int104
IPv6 PIM-SM 1
Switch D Switch C
IPv6 PIM-SM 2
IPv6 MBGP peers

Source - 1002::100/64 Switch C Vlan-int200 3002::1/64
Switch A Vlan-int100 1002::1/64 Vlan-int102 2001::2/64
Vlan-int101 1001::1/64 Vlan-int104 3001::1/64
Switch B Vlan-int101 1001::2/64 Switch D Vlan-int103 2002::2/64
Vlan-int102 2001::1/64 Vlan-int104 3001::2/64
Vlan-int103 2002::1/64
1) Configure IPv6 addresses for interfaces as shown in the above figure (omitted).
2) Configure OSPFv3 (omitted).
3) Enable IPv6 multicast routing, IPv6 PIM-SM and MLD, and configure an IPv6 PIM-SM domain
border.
# Enable IPv6 multicast routing on Switch A, and enable IPv6 PIM-SM on each interface.
The configuration on Switch B and Switch D is similar to the configuration on Switch A.

# Enable IPv6 multicast routing on Switch C, enable IPv6 PIM-SM on each interface, and enable MLD
on the host-side interface VLAN-interface 200.
[SwitchC] multicast ipv6 routing-enable
[SwitchC-Vlan-interface102] pim ipv6 sm
1-19
[SwitchC-Vlan-interface200] mld enable
# Configure an IPv6 PIM domain border on Switch A.

[SwitchA-Vlan-interface101] pim ipv6 bsr-boundary
# Configure an IPv6 PIM domain border on Switch B.

[SwitchB-Vlan-interface101] pim ipv6 bsr-boundary
4) Configure the position of C-BSR and C-RP.
# Configure the position of C-BSR and C-RP on Switch A.
[SwitchA] pim ipv6
[SwitchA-pim6] c-bsr 1001::1
[SwitchA-pim6] c-rp 1001::1
[SwitchA-pim6] quit
# Configure the position of C-BSR and C-RP on Switch B.

[SwitchB] pim ipv6
[SwitchB-pim6] c-bsr 1001::2
[SwitchB-pim6] c-rp 1001::2
[SwitchB-pim6] quit
5) Configure BGP, specify the IPv6 MBGP peer and enable direct route redistribution.
# On Switch A, configure the IPv6 MBGP peer and enable direct route redistribution.
[SwitchA] ipv6
[SwitchA] bgp 100
[SwitchA-bgp-af-ipv6] import-route direct
[SwitchA-bgp-af-ipv6] quit
[SwitchA-bgp] ipv6-family multicast
[SwitchA-bgp-af-ipv6-mul] peer 1001::2 enable
[SwitchA-bgp-af-ipv6-mul] import-route direct
[SwitchA-bgp-af-ipv6-mul] quit
[SwitchA-bgp] quit
# On Switch B, configure the IPv6 MBGP peers and redistribute OSPF routes.
[SwitchB] ipv6
[SwitchB] bgp 200
1-20
[SwitchB-bgp-af-ipv6] import-route ospfv3 1
[SwitchB-bgp-af-ipv6] quit
[SwitchB-bgp] ipv6-family multicast
[SwitchB-bgp-af-ipv6-mul] peer 1001::1 enable
[SwitchB-bgp-af-ipv6-mul] import-route ospfv3 1
[SwitchB-bgp-af-ipv6-mul] quit
[SwitchB-bgp] quit
You can use the display bgp ipv6 multicast peer command to display IPv6 MBGP peers on a switch.
For example, display IPv6 MBGP peers on Switch B.
[SwitchB] display bgp ipv6 multicast peer

1001::1 4 100 56 56 0 0 00:40:54 Established
1-21
Table of Contents
1 MPLS Basics Configuration 1-1

MPLS Overview 1-2
Basic Concepts of MPLS1-2
Architecture of MPLS1-5
MPLS and Routing Protocols 1-6
Applications of MPLS 1-6
MPLS Configuration Basics 1-8
Label Distribution and Management1-8
PHP 1-9
MPLS MTU 1-9
TTL Processing in MPLS1-10
Inspecting an MPLS LSP1-11
LDP Overview 1-11
Basic Concepts of LDP1-11
LDP Label Distribution1-12
Fundamental Operation of LDP1-13
LDP Loop Detection 1-15
LDP GR 1-15
Configuring MPLS Basic Capability 1-16
Configuring PHP 1-17
Configuring the MPLS MTU of an Interface 1-18
Configuring a Static LSP 1-19
Configuring MPLS LDP 1-20
MPLS LDP Configuration Task List1-20
Configuring MPLS LDP Capability 1-20
Configuring Local LDP Session Parameters 1-21
Configuring Remote LDP Session Parameters1-22
Configuring the Policy for Triggering LSP Establishment 1-23
Configuring the Label Distribution Control Mode 1-23
Configuring LDP Loop Detection1-24
Configuring LDP MD5 Authentication1-24
Enabling MTU Signaling 1-25
Configuring LDP Instances 1-25
i
Configuring LDP GR 1-26
Restarting MPLS LDP Gracefully 1-27
Configuring MPLS IP TTL Processing 1-27
Configuring MPLS IP TTL Propagation 1-28
Specifying the Type of the Paths for ICMP Responses 1-28
Configuring MPLS Fast Forwarding1-29
Configuring MPLS Statistics 1-30
Enabling MPLS Statistics 1-30
Setting the Interval for Reporting Statistics 1-30
Inspecting an MPLS LSP 1-31
Enabling MPLS Trap 1-31
Displaying and Maintaining MPLS 1-31
Resetting LDP Sessions1-31
Displaying MPLS Operation 1-32
Displaying MPLS LDP Operation 1-33
Clearing MPLS Statistics 1-33
MPLS Configuration Examples 1-34
Example for Configuring LDP Sessions (On Routers) 1-34
Example for Configuring LDP Sessions (On Switches) 1-38
Example for Configuring LDP to Establish LSPs (On Routers)1-41
Example for Configuring LDP to Establish LSPs (On Switches)1-43
ii

Configuring MPLS fast forwarding Yes Yes Yes Yes
Setting the interval for reporting
Yes Yes Yes Yes
statistics
z Refer to the description on command support in the command manual of this module for detailed
description of the MPLS statistics function.
1 MPLS Basics Configuration
When performing MPLS basics configuration, go to these sections for information you are interested in:
z MPLS Overview
z MPLS Configuration Basics
z LDP Overview
z Configuring MPLS Basic Capability
z Configuring PHP
z Configuring the MPLS MTU of an Interface
z Configuring a Static LSP
z Configuring MPLS LDP
z Configuring LDP Instances
z Configuring LDP GR
z Configuring MPLS IP TTL Processing
z Configuring MPLS Fast Forwarding
z Configuring MPLS Statistics
z Inspecting an MPLS LSP
z Enabling MPLS Trap
z Displaying and Maintaining MPLS
z MPLS Configuration Examples
1-1
z For detailed information about VPN, refer to MPLS L2VPN Configuration and MPLS L3VPN
Configuration in the MPLS Volume.
z For detailed information about MPLS TE, refer to MPLS TE Configuration in the MPLS Volume.
z For detailed information about QoS, refer to the QoS Volume.
MPLS Overview
Multiprotocol Label Switching (MPLS), originating in Internet Protocol version 4 (IPv4), was initially
proposed to improve forwarding speed. However, its core technology can be extended to multiple
network protocols, such as Internet Protocol version 6 (IPv6), Internet Packet Exchange (IPX), and
Connectionless Network Protocol (CLNP). That is what the term multiprotocol means.
MPLS integrates both Layer 2 fast switching and Layer 3 routing and forwarding, satisfying the
networking requirements of various new applications.
For details about the MPLS architecture, refer to RFC 3031 Multiprotocol Label Switching
Architecture.
Basic Concepts of MPLS
FEC
As a forwarding technology based on classification, MPLS groups packets to be forwarded in the same
manner into a class called a forwarding equivalence class (FEC). That is, packets of the same FEC are
handled in the same way on an MPLS network.
The classification of FECs is very flexible. It can be based on any combination of source address,
destination address, source port, destination port, protocol type and Virtual Private Network (VPN). For
example, in traditional IP forwarding using the longest match algorithm, all packets to the same
destination belong to the same FEC.
Label
A label is a short, fixed length identifier for identifying a FEC. A FEC may correspond to multiple labels in
scenarios where, for example, load sharing is required, while a label can only represent a single FEC.
A label is carried in the header of a packet. It does not contain any topology information and is local
significant.
A label is four octets, or 32 bits, in length. Figure 1-1 illustrates its format.
1-2
Figure 1-1 Format of a label
A label consists of four fields:

z Label: Label value of 20 bits. Used as the pointer for forwarding.
z Exp: For QoS, three bits in length.
z S: Flag for indicating whether the label is at the bottom of the label stack, one bit in length. 1
indicates that the label is at the bottom of the label stack. This field is very useful when there are
multiple levels of MPLS labels.
z TTL: Time to live (TTL) for the label. Eight bits in length. This field has the same meaning as that for
an IP packet.
Similar to the VPI/VCI in ATM and the DLCI in frame relay, an MPLS label functions as a connection
identifier. If the link layer protocol has a label field like VPI/VCI in ATM or DLCI in frame relay, the MPLS
label is encapsulated in that field. Otherwise, it is inserted between the data link layer header and the
network layer header as a shim. As such, an MPLS label can be supported by any link layer protocol.
Figure 1-2 shows the place of a label in a packet.
Figure 1-2 Place of a label in a packet
Currently, the device does not support the cell mode.
LSR
A Label switching router (LSR) is a fundamental component on an MPLS network. All LSRs support
MPLS.
LSP
A Label switched path (LSP) is the path along which a FEC travels through an MPLS network. Along an
LSP, two neighboring LSRs are called upstream LSR and downstream LSR respectively. In Figure 1-3,
R2 is the downstream LSR of R1, while R1 is the upstream LSR of R2.
1-3
Figure 1-3 Diagram for an LSP
An LSP is a unidirectional path from the ingress of the MPLS network to the egress. It functions like a
virtual circuit in ATM or frame relay. Each node of an LSP is an LSR.
Label distribution protocol
A label distribution protocol is a protocol used by MPLS for control. It has the same functions as a
signaling protocol on a traditional network. It classifies FECs, distributes labels, and establishes and
maintains LSPs.
MPLS supports multiple label distribution protocols of either of the following two types:
z Those dedicated for label distribution, such as Label Distribution Protocol (LDP) and
Constraint-based Routing using LDP (CR-LDP).
z Those existing protocols that are extended to support label distribution, such as Border Gateway
Protocol (BGP) and Resource Reservation Protocol (RSVP).
In addition, you can configure static LSPs.
z For information about CR-LDP and RSVP, refer to MPLS TE Configuration in the MPLS Volume.
z For information about BGP, refer to BGP Configuration in the IP Routing Volume.
LSP tunneling
MPLS supports LSP tunneling.

An LSR and its downstream LSR on an LSP are not necessarily on a path provided by the routing
protocol. That is, MPLS supports establishing an LSP along a path different from that established by the
routing protocol. Such an LSP is called an LSP tunnel, and the two LSRs are respectively the start point
and end point of the LSP tunnel. For example, the LSP <R2R21R22R3> in Figure 1-3 is a tunnel
between R2 and R3. This tunneling technology does not use the traditional network layer encapsulation
tunneling technology.
If the path that a tunnel traverses is exactly the hop-by-hop route established by the routing protocol, the
tunnel is called a hop-by-hop routed tunnel. Otherwise, the tunnel is called an explicitly routed tunnel.
Multi-level label stack
MPLS allows a packet to carry multiple levels of labels organized as a last-in first-out (LIFO) stack,
which is called a label stack. A packet with multiple levels of labels can travel along more than one level
of LSP tunnel. The ingress and egress of each tunnel perform Push and Pop operations respectively on
the top of a stack.
1-4
MPLS has no limit to the depth of a label stack. For a label stack with a depth of m, the label at the
bottom is of level 1, while the label at the top has a level of m. An unlabeled packet can be considered
as a packet with an empty label stack, that is, a label stack whose depth is 0.
Architecture of MPLS
Structure of the MPLS network
As shown in Figure 1-4, the element of an MPLS network is LSR. LSRs in the same routing or
administrative domain form an MPLS domain.
In an MPLS domain, LSRs residing at the domain border and connected with other networks are label
edge routers (LERs), while those within the MPLS domain are core LSRs. All core LSRs, which can be
routers running MPLS or ATM-LSRs upgraded from ATM switches, use MPLS to communicate, while
LERs interact with devices outside the domain that use traditional IP technologies.
Each packet entering an MPLS network is labeled on the ingress LER and then forwarded along an LSP
to the egress LER. All the intermediate LSRs are called transit LSRs.
Figure 1-4 Structure of the MPLS network
LSP
Egress
Ingress
IP network
IP network
Transit
The following describes how MPLS operates:

1) First, the LDP protocol and the traditional routing protocol (such as OSPF and ISIS) work together
on each LSR to establish the routing table and the label information base (LIB) for intended FECs.
2) Upon receiving a packet, the ingress LER completes the Layer 3 functions, determines the FEC to
which the packet belongs, labels the packet, and forwards the labeled packet to the next hop along
the LSP.
3) After receiving a packet, each transit LSR looks up its Label Forwarding Information Base (LFIB)
for the next hop according to the label of the packet, swaps the label, and then forwards the packet
to the next hop. None of the transit LSRs performs Layer 3 processing.
4) When the egress LER receives the packet, it removes the label of the packet and IP forwards the
packet.
Obviously, MPLS is not a service or application, but actually a tunneling technology and a routing and
switching technology platform that combines label switching with Layer 3 routing. This platform not only
supports multiple upper layer protocols and services, but also secures transmission of information to a
certain degree.
1-5
Structure of an LSR
Figure 1-5 Structure of an LSR
As shown in Figure 1-5, an LSR consists of two planes:

z Control plane: Implements label distribution and routing, establishes the LFIB, and builds and tears
LSPs.
z Forwarding plane: Forwards packets according to the LFIB.
An LER forwards both labeled packets and IP packets on the forwarding plane and therefore uses both
the LFIB and the FIB. An ordinary LSR only needs to forward labeled packets and therefore uses only
the LFIB.
MPLS and Routing Protocols
When establishing an LSP hop by hop, LDP uses the information in the routing tables of the LSRs along
the path to determine the next hop. The information in the routing tables is provided by routing protocols
such as IGPs and BGP. LDP only uses the routing information indirectly; it has no direct relationship
with routing protocols.
On the other hand, existing protocols such as BGP and RSVP can be extended to support label
distribution.
In MPLS applications, it may be necessary to extend some routing protocols. For example,
MPLS-based VPN applications requires that BGP be extended to propagate VPN routing information,
and MPLS-based Traffic Engineering (TE) requires that OSPF or IS-IS be extended to carry link state
information.
Applications of MPLS
By integrating both Layer 2 fast switching and Layer 3 routing technologies, MPLS features improved
route lookup speed. However, with the development of the application specific integrated circuit (ASIC)
technology, route lookup speed is no longer the bottleneck hindering network development. This makes
MPLS not so outstanding in improving forwarding speed.
1-6
Nonetheless, MPLS can easily implement the seamless integration between IP networks and Layer 2
networks of ATM, frame relay, and the like, and offer better solutions to Quality of Service (QoS), TE,
and VPN applications thanks to the following advantages.
MPLS-based VPN
Traditional VPNs depend on tunneling protocols such as GRE, L2TP, and PPTP to transport data
between private networks across public networks, while an LSP itself is a tunnel over public networks.
Therefore, implementation of VPN using MPLS holds natural advantages.
An MPLS-based VPN uses LSPs to connect geographically dispersed branches of an organization to
form a united network. MPLS-based VPN also supports the interconnection between VPNs.
Figure 1-6 MPLS-based VPN
VPN 3
CE 3
PE 3
MPLS backbone
VPN 1 VPN 2
CE 1 PE 1 PE 2 CE 2
Figure 1-6 shows the basic structure of an MPLS-based VPN. Two of the fundamental components are
customer edge device (CE) and service provider edge router (PE). A CE can be a router, switch, or host.
All PEs are on the backbone network.
PEs are responsible for establishing LSPs between them, managing VPN users, and advertising routes
among different branches of the same VPN. Route advertisement among PEs is usually implemented
by LDP or extended BGP.
MPLS-based VPN supports IP address multiplexing between branches and interconnection between
VPNs. Compared with a traditional route, a VPN route requires the branch and VPN identification
information. Therefore, it is necessary to extend BGP to carry VPN routing information.
MPLS-based TE
MPLS-based TE and the Diff-serv feature allow not only high network utilization, but also different levels
of services based on traffic precedence, providing voice and video streams with services of low delay,
low packet loss, and stable bandwidth guarantee.
As TE is more difficult to be implemented on an entire network, the Diff-serv model is often adopted in
practical networking schemes to implement QoS.
The Diff-serv model maps a service to a certain service class at the network edge according to the QoS
requirement of the service. The DS field (derived from the ToS field) in the IP packet identifies the
service class uniquely. Then, each node in the backbone network performs the preset service policies
according to the field to ensure the corresponding QoS.
1-7
The QoS classification in Diff-Serv is very similar to the MPLS label distribution mechanism. In fact, the
MPLS-based Diff-Serv is implemented by integrating the DS distribution into the MPLS label
distribution.
MPLS Configuration Basics

Label Distribution and Management
In MPLS, the label that an LSR uses for an FEC is assigned by the downstream LSR. The downstream
LSR then informs the upstream LSR of the assignment. That is, labels are advertised in the upstream
direction.
Label advertisement mode
Two label advertisement modes are available:

z Downstream on demand (DoD): In this mode, an LSR distributes a label binding to another LSR
only when it receives a label request from the LSR.
z Downstream unsolicited (DU): In this mode, an LSR does not wait for any label request before
distributing a label binding.
An upstream LSR and its downstream LSR must use the same label advertisement mode; otherwise,
no LSP can be established normally. For more information, refer to LDP Label Distribution.
Currently, the device supports only the DU mode.
Label distribution control mode
There are two label distribution control modes:

z Independent: In this mode, an LSR can advertise label bindings upstream at anytime. A
consequence of this mode is that an LSR may have advertised a label binding to the upstream LSR
when it receives a binding from its downstream LSR.
z Ordered: In this mode, an LSR advertises its label binding for a FEC upstream only when it
receives a label binding from the next hop for the FEC or it is the egress of the FEC.
Label retention mode
Label retention mode dictates how to process a received label binding that is not useful at the moment.
There are two label retention modes:
z Liberal: In this mode, an LSR keeps any received label binding regardless of whether the binding is
from its next hop for the FEC or not.
z Conservative: In this mode, an LSR keeps only label bindings that are from its next hops for the
FECs.
In liberal mode, an LSR can adapt to route changes quickly; while in conservative mode, there are less
label bindings for an LSR to advertise and keep.
The conservative label retention mode is usually used together with the DoD mode on LSRs with limited
label spaces.
1-8
Currently, the device supports only the liberal mode.
Basic concepts for label switching
z Next hop label forwarding entry (NHLFE): Operation to be performed on the label, which can be
Push or Swap.
z FEC to NHLFE mapping (FTN): Mapping of a FEC to an NHLFE at the ingress node.
z Incoming label mapping (ILM): Mapping of each incoming label to a set of NHLFEs. The operations
performed for each incoming label can be Null or Pop.
Label switching process
Each packet is classified into a certain FEC at the ingress LER. Packets of the same FEC travel along
the same path in the MPLS domain, that is, the same LSP. For each incoming packet, an LSR examines
the label, uses the ILM to map the label to an NHLFE, replaces the old label with a new label, and then
forwards the labeled packet to the next hop.
PHP
As described in Architecture of MPLS, each transit LSR on an MPLS network forwards an incoming
packet based on the label of the packet, while the egress removes the label from the packet and
forwards the packet based on the network layer destination address.
In fact, on a relatively simple MPLS application network, the label of a packet is useless for the egress,
which only needs to forward the packet based on the network layer destination address. In this case,
the penultimate hop popping (PHP) feature can pop the label at the penultimate node, relieving the
egress of the label operation burden and improving the packet processing capability of the MPLS
network.
MPLS MTU
When an MPLS label stack is inserted between the header and payload of a frame, the frame may
exceed the allowed length of the data link layer and cannot be forwarded, although the network layer
packet is smaller than the interface MTU. To address this issue, the device supports configuring MPLS
MTUs for interfaces. Once enabled with MPLS, an interface compares the length of an MPLS packet
against the MPLS MTU. If the packet is larger than the MPLS MTU but allows fragmentation, it
fragments and forwards the packet. If the packet is larger than the MPLS MTU but does not allow
fragmentation, it discards the packet directly.
1-9
z MPLS packets carrying L2VPN packets are always forwarded, even if they are larger than the
MPLS MTU. However, whether the forwarding will succeed depends on the actual forwarding
capacity of the interface.
z On some devices, MPLS packets carrying IPv6 packets are always forwarded, even if they are
larger than the MPLS MTU. However, whether the forwarding will succeed depends on the actual
forwarding capacity of the interface.
TTL Processing in MPLS
MPLS TTL processing involves two aspects: IP TTL propagation and ICMP response path.
IP TTL propagation
An MPLS label contains an 8-bit long TTL field, which has the same meaning as that of an IP packet.
According to RFC 3031 Multiprotocol Label Switching Architecture, when an LSR labels a packet, it
copies the TTL value of the original IP packet or the lower level label to the TTL field of the newly added
label. When an LSR forwards a labeled packet, it decrements the TTL value of the label at the stack top
by 1. When an LSR pops a label, it copies the TTL value of the label at the stack top back to the TTL field
of the IP packet or the lower level label.
TTL can be used not only to prevent routing loops, but to implement the tracert function:
z With IP TTL propagation enabled at ingress, whenever a packet passes a hop along the LSP, its IP
TTL gets decremented by 1. Therefore, the result of tracert will reflect the path along which the
packet has traveled.
z With IP TTL propagation disabled at ingress, the IP TTL of a packet does not decrement when the
packet passes a hop along the LSP, and the result of tracert does not show the hops within the
MPLS backbone, as if the ingress and egress were connected directly.
z Within an MPLS domain, TTL propagation always occurs between the multi-level labels.
z The TTL value of a transmitted local packet is always copied regardless of whether IP TTL
propagation is enabled or not. This ensures that the local administrator can tracert for network test.
z For network security, the structure of the MPLS backbone may need to be hidden in an MPLS VPN
application. In this case, TTL propagation is not allowed for private network packets at ingress.
ICMP response
On an MPLS VPN, P routers cannot route VPN packets carried by MPLS. When the TTL of an MPLS
packet expires, an ICMP response will be generated and transported along the LSP until it reaches the
destination router of the LSP, where it is forwarded by IP routing. Such processing increases the
network traffic and the packet forwarding delay.
1-10
For description and configuration of P routers, refer to MPLS L3VPN Configuration and MPLS L2VPN
Configuration in the MPLS Volume.
For an MPLS packet with only one level of label, the ICMP response message travels along the IP route
when the TTL expires.
Inspecting an MPLS LSP
In MPLS, the MPLS control plane is responsible for establishing an LSP. However, it cannot detect the
error when an LSP fails to forward data. This brings difficulty to network maintenance.
MPLS LSP ping and traceroute can be used to detect errors in LSPs and locate nodes with failures in
time. Similar to IP ping and traceroute, MPLS LSP ping and traceroute use MPLS echo requests and
MPLS echo replies to check the availability of LSPs. The MPLS echo request message carries the FEC
information of the LSP to be detected, and is sent along the LSP like other data packets of the FEC.
Thus, the LSP can be checked.
z MPLS LSP ping is a tool for checking the validity and availability of an LSP. It uses messages
called MPLS echo requests. In a ping operation, MPLS echo requests are forwarded along an LSP
to the egress, where the control plane confirms that the LSR is the egress of the FEC and responds
with MPLS echo replies. If the ping initiator receives the replies, the LSP is considered perfect for
forwarding data.
z MPLS LSP traceroute is a tool for locating LSP errors. By sending MPLS echo requests to the
control plane of each transit LSR, it can determine whether the LSR is really a transit node on the
LSP.
The destination address in the IP header of an MPLS echo request is set to an address on 127.0.0.0/8
(a loopback address of the LSR) and the TTL is set to 1, so as to prevent further forwarding of the
request when the request reaches the egress.
LDP Overview
Basic Concepts of LDP
The LDP protocol dictates the messages to be used in label distribution and the related processes.
Using LDP, LSRs can map network layer routing information to data link layer switching paths directly
and further establish LSPs. LSPs can be established between both neighboring LSRs and LSRs that
are not directly connected, making label switching possible at all transit nodes on the network.
1-11
For detailed description about LDP, refer to RFC 3036 LDP Specification.
LDP peer
Two LSRs with an LDP session established between them and using LDP to exchange label bindings
are called LDP peers, each of which obtains the label bindings of its peer over the LDP session between
them.
LDP session
LDP sessions are used to exchange messages for label binding and releasing.
LDP sessions come in two categories:
z Local LDP session: Established between two directly connected LSRs.
z Remote LDP session: Established between two indirectly connected LSRs.
LDP message type
There are four types of LDP messages:

z Discovery message: Used to declare and maintain the presence of LSRs on a network.
z Session message: Used to establish, maintain, and terminate sessions between LDP peers.
z Advertisement message: Used to create, alter, or remove label bindings.
z Notification message: Used to provide advisory information and to notify errors.
For reliable transport of LDP messages, TCP is used for LDP session messages, advertisement
messages, and notification messages, while UDP is used only for discovery messages.
Label space and LDP identifier
A scope of labels that can be assigned to LDP peers is called a label space. A label space can be per
interface or per platform. A per interface label space is interface-specific, while a per platform label
space is for an entire LSR.
An LDP identifier is used to identify an LSR label space. It is a six-byte numerical value in the format of
<LSR ID>:<Label space ID>, where LSR ID is four-byte long. A label space ID of 1 means that the label
space is per interface, a label space ID of 0 means that the label space is per platform.
Currently, only per platform label space is supported.
LDP Label Distribution
Figure 1-7 illustrates how LDP distributes labels.
1-12
Figure 1-7 Label distribution
Ingress Egress
LSR A LSR B LSR C LSR D
LSR E LSR F LSR G
Label request
Label mapping LSR H
LSP1 LER
LSP2
In Figure 1-7, B is the upstream LSR of C along LSP 1.

As described previously, there are two label advertisement modes. The main difference between them
is whether the downstream advertises the bindings unsolicitedly or on demand.
The following details the advertisement process in each of the two modes.
DoD mode
In DoD mode, an upstream LSR sends a label request message containing the description of a FEC to
its downstream LSR. After receiving the message, the downstream LSR assigns a label to the FEC,
encapsulates the binding information in a label mapping message and sends the message to the
upstream LSR. However, the time when the downstream LSR sends label binding information depends
on the label distribution control mode that it uses:
z In ordered mode, a downstream LSR sends label binding information only after it receives that of its
downstream LSR.
z In independent mode, a downstream LSR sends label binding information immediately after it
receives a label request message, no matter whether it has received the label binding information
of its downstream LSR or not.
Usually, an upstream LSR selects its downstream LSR based on the information in its routing table. In
Figure 1-7, all LSRs along LSP 1 work in ordered mode, while LSR F along LSP 2 works in independent
mode.
DU mode
In DU mode, an LSR advertises label binding information to all its neighboring LSRs unsolicitedly after
the LDP sessions are established. An LSR receiving the label binding information determines how to
process the label binding information based on its label retention mode and routing table information.
Fundamental Operation of LDP
LDP goes through four phases in operation: discovery, session establishment and maintenance, LSP
establishment and maintenance, and session termination.
1-13
Discovery
In this phase, an LSR wanting to establish a session sends Hello messages to its neighboring LSRs
periodically, announcing its presence. This way, LSRs can automatically find their peers without manual
configuration.
LDP provides two discovery mechanisms:
z Basic discovery mechanism
The basic discovery mechanism is used to discover local LDP peers, that is, LSRs directly connected at
link layer, and to further establish local LDP sessions.
Using this mechanism, an LSR periodically sends LDP link Hello messages in the form of UDP packets
out its interfaces to the multicast address known as all routers on this subnet. An LDP link Hello
message carries information about the LDP identifier of a given interface and some other information.
Receipt of an LDP link Hello message on an interface indicates that a potential LDP peer is connected
to the interface at link layer.
z Extended discovery mechanism
The extended discovery mechanism is used to discover remote LDP peers, that is, LSRs that are not
directly connected at link layer, and to further establish remote LDP sessions.
Using this mechanism, an LSR periodically sends LDP targeted Hello messages in the form of UDP
packets to a given IP address.
An LDP targeted Hello message carries information about the LDP identifier of a given LSR and some
other information. Receipt of an LDP targeted Hello message on an LSR indicates that a potential LDP
peer is connected to the LSR at network layer.
At the end of the discovery phase, Hello adjacency is established between LSRs, and LDP is ready to
initiate session establishment.
Session establishment and maintenance
In this phase, LSRs pass through two steps to establish sessions between them:
1) Establishing transport layer connections (that is, TCP connections) between them.
2) Initializing sessions and negotiating session parameters such as the LDP version, label distribution
mode, timers, and label spaces.
After establishing sessions between them, LSRs send Hello messages and Keepalive messages to
maintain those sessions.
LSP establishment and maintenance
Establishing an LSP is to bind FECs with labels and notify adjacent LSRs of the bindings. This is
implemented by LDP. The following gives the primary steps when LDP works in DU mode and ordered
mode:
1) When the network topology changes and an LER finds in its routing table a new destination
address that does not correspond to any existing FEC, the LER creates a new FEC for the
destination address.
2) If the LER has upstream LSRs and has at least one free label, it assigns a label to the FEC and
sends the label binding information to the upstream LSRs.
3) Upon receiving the label binding information, an upstream LSR records the binding. Then, if the
LSR which sent the binding information is the next hop of the FEC, it adds an entry in its LFIB,
assigns a label to the FEC, and sends the new label binding information to its own upstream LSRs.
1-14
4) When the ingress LER receives the label binding message, it adds an entry in its LFIB. Thus, an
LSP is established for the FEC, and packets of the FEC can be label switched along the LSP.
Session termination
LDP checks Hello messages to determine adjacency and checks Keepalive messages to determine the
integrity of sessions.
LDP uses different timers for adjacency and session maintenance:
z Hello timer: LDP peers periodically send Hello messages to indicate that they intend to keep the
Hello adjacency. If an LSR does not receive any Hello message from its peer in a Hello interval, it
removes the Hello adjacency.
z Keepalive timer: LDP peers keep LDP sessions by periodically sending Keepalive messages over
LDP session connections. If an LSR does not receive any Keepalive message from its peer during
a Keepalive interval, it closes the connection and terminates the LDP session.
LDP Loop Detection
LSPs established in an MPLS domain may be looping. The LDP loop detection mechanism can detect
looping LSPs and prevent LDP messages from looping forever.
For the LDP loop detection mechanism to work, all LSRs must have the same LDP loop detection
configuration. However, establishing an LDP session does not require that the LDP loop detection
configuration on the LDP peers be the same.
LDP loop detection can be in either of the following two modes:
Maximum hop count
A label request message or label mapping message may contain information about its hop count, which
increments by 1 for each hop. When this value reaches the specified limit, LDP considers that a loop is
present and the attempt to establish an LSP fails.
Path vector
A label request message or label mapping message may contain path information in the form of path
vector list. When such a message reaches an LSR, the LSR checks the path vector list of the message
to see whether its MPLS LSR ID is in the list. If either of the following cases occurs, the attempt to
establish an LSP fails:
z The MPLS LSR ID of the LSR is already in the path vector list.
z The hop count of the path reaches the specified limit.
If the LSR does not find its MPLS LSR ID in the path vector list, it adds the ID into the list.
LDP GR
For details about Graceful Restart (GR), refer to GR Configuration in the System Volume.
1-15
During MPLS LDP session establishment, the LDP peers need to perform Fault Tolerance (FT) and GR
capability negotiation. Only when both devices support GR, can the established session be FT/GR
capable. To support GR, a GR device must backup the FECs and label information.
When an LDP session is GR capable:
1) Whenever the GR restarter restarts, a GR helper will detect that the related LDP session is down
and will keep its neighborship with the GR restarter and retain information about the session until
the reconnect timer times out.
2) If the GR helper receives a session request from the GR restarter before the reconnect timer times
out, it retains the LSP and label information of the session and restores the session with the GR
restarter. Otherwise, it deletes all LSP and label information associated with the session.
3) After the session recovers, the GR restarter and helper activate the neighbor liveness timers and
recovery timers, restore all LSP information related to the session, and send to each other label
mapping and label request messages.
4) Upon receipt of the mapping messages from each other, the GR restarter and helper delete the
LSP stale flag. After the neighbor liveness timer and recovery timer time out, the GR restarter and
helper will delete all LSP information of the session.
To summarize, during a GR recover, the LSP information is preserved for the forwarding plane and
therefore MPLS packets can be forwarded without interruption.
Configuring MPLS Basic Capability

You need to configure MPLS basic capability on all routers for MPLS forwarding within an MPLS domain,
and to configure MPLS basic capability before configuring any other MPLS features.
Currently, these types of interfaces support MPLS capability: serial interface, async interface, Layer 3
Ethernet interface (Ethernet interface, GE interface, and XGE interface), ATM interface, POS interface,
Layer 3 virtual Ethernet interface, Layer 3 aggregate interface, virtual template, Mp-group interface,
MFR interface, tunnel interface, VLAN interface, and RPR logical interface. Whether tunnel interfaces
support MPLS capability depends on the device model.
Before configuring MPLS basic capability, be sure to complete these tasks:

z Configuring physical parameters on relevant interfaces,
z Configuring link layer attributes on relevant interfaces,
z Assigning IP addresses to relevant interfaces,
z Configuring static routes or an IGP protocol, ensuring that LSRs can reach each other at Layer 3.
1-16
MPLS basic capability can be configured on LSRs even when LSRs cannot reach each other. However,
you need to configure the mpls ldp transport-address command in this case. For details about the
command, refer to MPLS Basics Commands in the MPLS Volume.
Follow these steps to configure MPLS basic capability:
Required
Configure the MPLS LSR ID mpls lsr-id lsr-id
Not configured by default
Enable MPLS globally and Required

mpls
enter MPLS view Not enabled by default
interface-number
Required
Enable MPLS for the interface mpls
An MPLS LSR ID is in the format of an IP address and must be unique within an MPLS domain. You are
recommended to use the IP address of a loopback interface on an LSR as the MPLS LSR ID.
Configuring PHP
Configure PHP on an egress and select the type of labels for the egress to distribute based on whether
the penultimate hop supports PHP.
Before configuring PHP, be sure to complete the following task:

z Configuring MPLS basic capability on all LSRs.
According to RFC 3032 MPLS Label Stack Encoding:
1-17
z A label value of 0 represents an IPv4 explicit null label and is valid only when it appears at the
bottom of a label stack. It indicates that the label of the packet must be popped out on the current
node, and that the next node will perform IP forwarding.
z A label value of 3 represents an implicit null label and never appears in the label stack. When an
LSR finds that it is assigned an implicit null label, it directly performs a pop operation, rather than
substitutes the implicit null label for the original label at the stack top.
Follow these steps to configure PHP:
Enter MPLS view mpls
Optional
Configure the egress to
By default, an egress supports PHP and
support PHP and specify label advertise
distributes to the penultimate hop an
the type of the label to be { explicit-null |
implicit null label.
distributed to the implicit-null | non-null }
penultimate hop Note that you must reset LDP sessions
for the configuration to take effect.
Configuring the MPLS MTU of an Interface

Before configuring the MPLS MTU of an interface, be sure to complete the following task:
z Enabling MPLS capability on the interface.
Follow these steps to configure the MPLS MTU of an interface:
interface-number
Required
Configure the MPLS MTU of By default, the MPLS MTU of
mpls mtu value
the interface an interface equals the
interface MTU.
If the MPLS MTU of an interface is greater than the interface MTU, data forwarding may fail on the
interface.
1-18
Configuring a Static LSP
An LSP can be static or dynamic. A static LSP is manually configured, while a dynamic LSP is
established by MPLS LDP.
For a static LSP to work, all LSRs along the LSP must be configured properly.
Static LSPs can be used in MPLS L2VPN.
For configuration of MPLS L2VPN, refer to MPLS L2VPN Configuration in the MPLS Volume.
Before configuring a static LSP, be sure to complete these tasks:

z Determining the ingress, transit LSRs, and egress for the static LSP,
z Configuring MPLS basic capability on all the LSRs.
Follow these steps to configure a static LSP:
static-lsp ingress lsp-name destination

dest-addr { mask | mask-length } { nexthop
Configure a static LSP taking
next-hop-addr | outgoing-interface Optional
the current LSR as the ingress
interface-type interface-number } out-label
out-label
static-lsp transit lsp-name
incoming-interface interface-type
interface-number in-label in-label
the current LSR as a transit Optional
{ nexthop next-hop-addr |
LSR
outgoing-interface interface-type
interface-number } out-label out-label
static-lsp egress lsp-name

incoming-interface interface-type Optional
the current LSR as the egress
interface-number in-label in-label
1-19
z Support for the outgoing-interface keyword depends on the device model.
z The value of the next-hop-addr argument cannot be any local public network IP address.
z If you specify the next hop when configuring a static LSP, and the address of the next hop is
present in the routing table, you also need to specify the next hop when configuring the static IP
route.
z If you specify the outgoing interface for a static LSP, you also need to specify the outgoing interface
when configuring the static IP route.
z For information about configuring a static IP route, refer to Static Routing Configuration in the IP
Routing Volume.
Configuring MPLS LDP

Before configuring LDP, be sure to complete the following task:

z Configuring MPLS basic capability.
MPLS LDP Configuration Task List
Complete the following tasks to configure LDP:
Task Remarks
Configuring MPLS LDP Capability Required
Configuring Local LDP Session Parameters Optional
Configuring Remote LDP Session Parameters Optional
Configuring the Policy for Triggering LSP Establishment Optional
Configuring the Label Distribution Control Mode Optional
Configuring LDP Loop Detection Optional
Configuring LDP MD5 Authentication Optional
Enabling MTU Signaling Optional
Configuring MPLS LDP Capability
Follow these steps to configure MPLS LDP capability:
Enable LDP capability globally Required

mpls ldp
and enter MPLS LDP view Not enabled by default
1-20
Optional
Configure the LDP LSR ID lsr-id lsr-id MPLS LSR ID of the LSR by
default
interface-number
Enable LDP capability for the Required

mpls ldp
interface Not enabled by default
z Currently, these types of interfaces support LDP capability: serial interface, async interface, Layer
3 Ethernet interface (Ethernet interface, GE interface, and XGE interface), ATM interface, POS
interface, Layer 3 virtual Ethernet interface, Layer 3 aggregate interface, virtual template,
Mp-group interface, MFR interface, tunnel interface, VLAN interface, virtual dial template (that is,
dialer), and RPR logical interface. Whether tunnel interfaces support MPLS capability depends on
the device model.
z Disabling LDP on an interface terminates all LDP sessions on the interface. As a result, all LSPs
using the sessions will be deleted.
z Usually, you do not need to configure the LDP LSR ID, which defaults to the MPLS LSR ID. In
some VPN applications (for example, MPLS L3VPN applications), however, you need to ensure
that different LDP instances have different LDP LSR IDs if the address spaces overlap. Otherwise,
the TCP connections cannot be established normally.
Configuring Local LDP Session Parameters
You can configure a local session transport address to be the IP address of an interface or a specified IP
address.
Follow these steps to configure local LDP session parameters:
interface-number
mpls ldp timer hello-hold Optional

Set the link Hello timer
value 15 seconds by default
mpls ldp timer Optional

Set the link Keepalive timer
keepalive-hold value 45 seconds by default
Optional
Configure the LDP transport mpls ldp transport-address
address { ip-address | interface } MPLS LSR ID of the LSR by
default
1-21
If you configure an LDP transport address by specifying an IP address, the specified IP address must
be the IP address of an interface on the device. Otherwise, the LDP sessions cannot be established.
Configuring Remote LDP Session Parameters
Configure a remote session transport address by specifying an IP address.

Follow these steps to configure remote LDP session parameters:
Create a remote peer entity and

mpls ldp remote-peer
enter MPLS LDP remote peer Required
remote-peer-name
view
Configure the remote peer IP
remote-ip ip-address Required
address
mpls ldp timer hello-hold Optional

Set the targeted Hello timer
value 45 seconds by default
Set the targeted Keepalive mpls ldp timer Optional

timer keepalive-hold value 45 seconds by default
Optional
Configure the transport mpls ldp transport-address
address ip-address MPLS LSR ID of the LSR by
default
In the current implementation, LDP itself does not send any label information through remote sessions,
and remote sessions are used only to transfer messages for L2VPNs. For applications of remote
sessions, refer to information about Martini MPLS L2VPN configuration in MPLS L2VPN Configuration
of the MPLS Volume.
1-22
z If Hello adjacency exists between two peers, no remote adjacency can be established between
them. If remote adjacency exists between two peers, you can configure local adjacency for them.
However, the local adjacency can be established only when the transport address and keepalive
settings of the two peers match respectively, in which case the remote adjacency will be removed.
That is, only one remote session or local session can exist between two LSRs, and the local
session takes precedence over the remote session.
z The remote peer IP address to be configured must be different from all existing remote peer IP
addresses. Otherwise, the configuration fails.
z The IP address specified as the LDP transport address must be the IP address of an interface on
the device.
Configuring the Policy for Triggering LSP Establishment
You can specify the routes that are allowed to trigger the establishment of LSPs:
z All static and IGP routes.
z Static and IGP routes permitted by an IP address prefix list.
Follow these steps to configure the policy for triggering LSP establishment:
Optional
Configure the LSP lsp-trigger { all | ip-prefix By default, only local loopback
establishment triggering policy prefix-name } addresses with 32-bit masks
can trigger LDP to establish
LSPs.
z For an LSP to be established, an exactly matching routing entry must exist on the LSR. With
loopback addresses using 32-bit masks, only exactly matching host routing entries can trigger LDP
to establish LSPs.
z For information about IP address prefix list, refer to Routing Policy Configuration in the IP Routing
Volume.
Configuring the Label Distribution Control Mode
Follow these steps to configure the LDP label distribution control mode:
1-23
Enable LDP capability globally

mpls ldp Required
and enter MPLS LDP view
Optional
Ordered by default
Specify the label distribution label-distribution
control mode { independent | ordered } Note that you need to reset
LDP sessions for this command
to take effect.
Enable label readvertisement Optional

du-readvertise
for DU mode Enabled by default
Set the interval for label Optional

du-readvertise timer value
readvertisement in DU mode 30 seconds by default
Configuring LDP Loop Detection
Follow these steps to configure LDP loop detection:

mpls ldp Required
Required
Enable loop detection loop-detect
Disabled by default
Optional
Set the maximum hop count hops-count hop-number
32 by default
Set the maximum path vector Optional

path-vectors pv-number
length 32 by default
Changing the loop detection configurations does not affect existing LSPs.
You need to enable loop detection before enabling LDP capability on any interface.
Configuring LDP MD5 Authentication
To improve the security of LDP sessions, you can configure MD5 authentication for the underlying TCP
connections.
1-24
Follow these steps to configure LDP MD5 authentication:

mpls ldp Required
Enable LDP MD5 Required
md5-password { cipher |
authentication and set the
plain } peer-lsr-id password Disabled by default
password
Enabling MTU Signaling
For correct path MTU detection, an IP router needs to know the MTU of each connected link.
LDP can automatically calculate the minimum MTU of all interfaces along an LSP. At ingress, MPLS
controls the sizes of MPLS packets to be forwarded based on the calculated minimum MTU, so that all
forwarded packets are smaller than the minimum MTU and therefore not dropped by a transit LSR.
Follow these steps to enable MTU signaling:

mpls ldp Required
Optional
Enable MTU signaling mtu-signalling
Enabled by default
Enabling/disabling MTU signaling will cause all sessions and the LSPs based on the sessions to be
removed and then reestablished.
Configuring LDP Instances

LDP instances are for carriers carrier networking applications of MPLS L3VPN. You need to configure
LDP capability for existing VPN instances.
Except for the command for the LDP GR feature, all commands available in MPLS LDP view can be
configured in MPLS LDP VPN instance view.
Before configuring LDP instances, be sure to complete these tasks:

z Configuring VPN instances,
z Configuring MPLS basic capability,
z Configuring MPLS LDP capability.
1-25
Usually, you do not need to configure the LDP LSR ID, which defaults to the MPLS LSR ID. In some
VPN applications (for example, MPLS L3VPN applications), however, you need to ensure that different
LDP instances have different LDP LSR IDs if the address spaces overlap. Otherwise, the TCP
connections cannot be established normally.
Follow these steps to configure LDP instances:
Enable LDP capability for a

mpls ldp vpn-instance
VPN instance and enter MPLS Required
vpn-instance-name
LDP VPN instance view
Optional
Configure the LDP LSR ID for
lsr-id lsr-id MPLS LSR ID of the LSR by
the VPN instance
default
z Configurations in MPLS LDP VPN instance view affect only LDP-enabled interfaces bound to the
VPN instances, while configurations in MPLS LDP view do not affect interfaces bound to VPN
instances. When configuring the transport address of an LDP instance, you need to use the IP
address of the interface bound to the VPN instance.
z By default, LDP adjacencies on a private network are established using addresses of the
LDP-enabled interfaces, while those on the public network are established using the LDP LSR ID.
Configuring LDP GR
Before configuring LDP GR, be sure to complete this task:

z Configuring MPLS LDP capability on each device to be the GR restarter or a GR helper.
The device can act as both a GR restarter and a GR helper.
Follow these steps to configure LDP GR:
1-26
Enter MPLS LDP view mpls ldp
Required
Enable MPLS LDP GR graceful-restart
Disabled by default
graceful-restart timer Optional

Set the FT reconnect timer
reconnect timer 300 seconds by default
Set the LDP neighbor liveness graceful-restart timer Optional

timer neighbor-liveness timer 120 seconds by default
graceful-restart timer Optional

Set the LDP recovery timer
recovery timer 300 seconds by default
During MPLS LDP GR, a GR helper takes the lesser one between its LDP neighbor liveness time and
the GR restarters FT reconnect time as its FT reconnect interval, and takes the lesser one between its
LDP recovery time and that of the GR restarter as its LDP recovery interval.
After configuring GR parameters, you need to restart MPLS LDP by using the reset mpls ldp command
to bring the configurations into effect.
Restarting MPLS LDP Gracefully
To test MPLS LDP GR without main/backup switchover, you can restart MPLS LDP gracefully. You are
not recommended to perform this operation in normal cases.
Follow these steps to restart MPLS LDP gracefully:

Required
Restart MPLS LDP gracefully graceful-restart mpls ldp
Configuring MPLS IP TTL Processing

Before configuring MPLS IP TTL propagation, be sure to complete this task:

z Configuring MPLS basic capability.
1-27
Configuring MPLS IP TTL Propagation
Follow these steps to configure IP TTL propagation of MPLS:
Enter MPLS view mpls Required
Optional
Enable MPLS IP TTL
ttl propagate { public | vpn } Enabled for only public network
propagation
packets by default
z The ttl propagate command affects only the propagation of the IP TTL to the TTL in an MPLS label.
At egress, the system uses the smaller one between the IP TTL and MPLS TTL as the TTL of the IP
packet and decrements the value by 1.
z If you enable MPLS IP TTL propagation for VPN packets on one LSR, you are recommended to do
so on all related PEs as well, guaranteeing that you can get the same result when tracerting from
those PEs.
Specifying the Type of the Paths for ICMP Responses
ICMP responses can use two kinds of paths: IP route and LSP.
For MPLS packets with one-level of labels, you can configure MPLS to send back ICMP responses
along IP routes instead of LSPs when the TTL expires.
In MPLS, an IP router generally maintains public network routes only, and MPLS packets with one-level
of labels carry public network payload. Therefore, you can configure this function.
In MPLS VPN, for autonomous system border routers (ASBRs) and SPEs in Hierarchy of VPN (HoVPN)
applications (including SPEs in applications with recursions), MPLS packets that carry VPN packets
may have only one-level of labels. To tracert the VPN packets on public networks in this case, you need
to:
z Configure the ttl propagate vpn command on all relevant PEs to allow IP TTL propagation of VPN
packets.
z Configure the undo ttl expiration pop command on the ASBRs and SPEs to assure that ICMP
responses can travel along the original LSPs.
z SPE refers to superstratum PE or service provider-end PE.

z For details about HoVPN, refer to MPLS L3VPN Configuration in the MPLS Volume.
Follow these steps to specify the type of the paths for ICMP responses:
1-28
Specify that ICMP responses Optional

travel along the IP route when Configure one of them as
ttl expiration pop
the TTL of an MPLS packet required.
expires
By default, ICMP response
Specify that ICMP responses messages of an MPLS packet
travel along the LSP when the undo ttl expiration pop with a one-level label stack
TTL of an MPLS packet expires travel along the IP route.
Configuring MPLS Fast Forwarding
MPLS fast forwarding is designed to improve MPLS forwarding efficiency. With MPLS fast forwarding,
the first packet of a data stream is forwarded based on the normal MPLS forwarding process, during
which period a fast forwarding entry, including the link layer header for the packet, is recorded in the fast
forwarding cache. All subsequent packets of the data stream are then forwarded based on the fast
forwarding entry, using the link layer header for the first packet. This greatly improves MPLS forwarding
efficiency.
MPLS fast forwarding depends on IP fast forwarding; it works when IP fast forwarding is enabled, and
stops working when IP fast forwarding is disabled.
For information about IP fast forwarding, refer to Fast Forwarding Configuration in the IP Services
Volume.
Follow these steps to configure MPLS fast forwarding:
interface-number
Optional
Enable fast forwarding in the ip fast-forwarding [ inbound |
inbound or outbound direction outbound ] Enabled in both directions by
default
1-29
Configuring MPLS Statistics
Enabling MPLS Statistics
Follow these steps to enable MPLS statistics:
mpls statistics enable

{ interface interface-type Required
Enable MPLS statistics
interface-number | lsp in-label Disabled by default
in-label | tunnel token token }
Setting the Interval for Reporting Statistics
To view LSP statistics, you need to set the interval for collecting statistics at first.
Follow these steps to set the interval for collecting statistics:
Required
Set the interval for collecting 0 seconds by default, meaning
statistics interval interval-time
statistics that the system does not collect
statistics.
1-30
Inspecting an MPLS LSP
ping lsp [ -a source-ip | -c count | -exp exp-value | -h
Check the validity and ttl-value | -m wait-time | -r reply-mode | -s packet-size | -t
Available in any
reachability of an time-out | -v ] * { ipv4 dest-addr mask-length
view
MPLS LSP [ destination-ip-addr-header ] | te interface-type
interface-number }
tracert lsp [-a source-ip | -exp exp-value | -h ttl-value | -r
Locate an MPLS LSP reply-mode |-t time-out ] * { ipv4 dest-addr mask-length Available in any
error [ destination-ip-addr-header ] | te interface-type view
interface-number }
Enabling MPLS Trap

With the MPLS trap function enabled, trap packets of the notifications level will be generated to report
critical MPLS events. Such trap packets will be sent to the information center of the device. Whether
and where the packets will then be output depend on the configurations of the information center. For
information on how to configure the information center, refer to Information Center Configuration in the
System Volume.
Follow these steps to enable the MPLS trap function:
Required
Enable the MPLS trap function snmp-agent trap enable mpls
Disabled by default
For detailed information about the snmp-agent trap enable mpls command, refer to the snmp-agent
trap enable command in SNMP Commands of the System Volume.
Displaying and Maintaining MPLS

Resetting LDP Sessions
If you change any LDP session parameters when the sessions are up, the LDP sessions will not be able
to function normally. In this case, you need to reset LDP sessions so that the LDP peers renegotiate
parameters and establish new sessions. Use one of the following commands to reset LDP sessions:

reset mpls ldp [ all | [ vpn-instance
Reset LDP sessions Available in user view
vpn-instance-name ] [ fec mask | peer peer-id ] ]
1-31
Displaying MPLS Operation

Display information about one
display mpls interface [ interface-type
or all interfaces with MPLS Available in any view
enabled
On a
Display centralized display mpls ilm [ label ] [ include text ] Available in any view
information device
about ILM On a
entries display mpls ilm [ label ] [ slot
distributed Available in any view
slot-number ] [ include text ]
device
Display information about display mpls label { label-value1 [ to
specified labels or all labels label-value2 ] | all }
display mpls lsp [ incoming-interface
[ outgoing-interface interface-type
interface-number ] [ in-label
in-label-value ] [ out-label
Display information about LSPs out-label-value ] [ asbr | [ vpn-instance Available in any view
vpn-instance-name ] [ protocol { bgp |
bgp-ipv6 | crldp | ldp | rsvp-te | static |
static-cr } ] ] [ egress | ingress | transit ]
[ { exclude | include } dest-addr
mask-length ] [ verbose ]
On a
display mpls nhlfe [ token ] [ include
Display centralized Available in any view
text ]
information device
about NHLFE On a
entries display mpls nhlfe [ token ] [ slot
distributed Available in any view
slot-number ] [ include text ]
device
Display LSP statistics display mpls lsp statistics Available in any view
display mpls static-lsp [ lsp-name
Display information about static
lsp-name ] [ { include | exclude } Available in any view
LSPs
dest-addr mask-length ] [ verbose ]
display mpls route-state [ vpn-instance
Display LSP-related route
vpn-instance-name ] [ dest-addr Available in any view
information
mask-length ]
Display statistics for all LSPs or
display mpls statistics lsp { all | index |
the LSP with a specified index Available in any view
lsp-name }
or name
Display MPLS statistics for one display mpls statistics interface

or all interfaces { interface-type interface-number | all }
Display statistics for all LSPs or

display mpls statistics lsp [ in-label
the LSP with a specified Available in any view
in-label ]
incoming label
Display statistics for one or all display mpls statistics tunnel [ token
public tunnels token ]
Display information about display mpls fast-forwarding cache

MPLS fast forwarding entries [ verbose ]
1-32
Support for the display mpls statistics lsp, display mpls statistics interface, display mpls
statistics lsp in-label, and display mpls statistics tunnel commands depends on the device model.
Displaying MPLS LDP Operation

Display information about display mpls ldp [ all [ verbose ] [ | { begin | Available in any
LDP exclude | include } regular-expression ] ] view
display mpls ldp interface [ all [ verbose ] |

Display information about [ vpn-instance vpn-instance-name ] Available in any
LDP-enabled interfaces [ interface-type interface-number | verbose ] ] [ | view
{ begin | exclude | include } regular-expression ]
display mpls ldp peer [ all [ verbose ] |
Display information about [ vpn-instance vpn-instance-name ] [ peer-id | Available in any
LDP session peers verbose ] ] [ | { begin | exclude | include } view
display mpls ldp remote-peer [ remote-name
Display information about Available in any
remote-peer-name ] [ | { begin | exclude | include }
remote LDP peers view
display mpls ldp session [ all [ verbose ] |
Display information about [ vpn-instance vpn-instance-name ] [ peer-id | Available in any
LDP sessions verbose ] ] [ | { begin | exclude | include } view
display mpls ldp lsp [ all | [ vpn-instance
vpn-instance-name ] [ dest-addr mask-length ] ] [ |
LSPs established by LDP view
{ begin | exclude | include } regular-expression ]
Display information about display mpls ldp cr-lsp [ vpn-instance
Available in any
CR-LSPs established by vpn-instance-name [ lspid lsr-id lsp-id ] ] [ | { begin
view
CR-LDP | exclude | include } regular-expression ]
display mpls ldp vpn-instance

vpn-instance-name [ | { begin | exclude | include }
a specified LDP instance view
Clearing MPLS Statistics

Clear MPLS statistics for one or reset mpls statistics interface
all MPLS interfaces { interface-type interface-number | all }
Clear MPLS statistics for all
reset mpls statistics lsp { index | all |
LSPs or the LSP with a Available in user view
name lsp-name }
specified index or name
Clear statistics for all LSPs or
reset mpls statistics lsp [ in-label
the LSP with a specified Available in user view
in-label ]
incoming label
1-33
Clear statistics for all public
reset mpls statistics tunnel [ token
network tunnels or the one with Available in user view
token ]
a specified LSP token
Clear information in the MPLS
reset mpls fast-forwarding cache Available in user view
fast forwarding cache
Support for the reset commands that are for clearing MPLS statistics depends on the device model.
MPLS Configuration Examples

Example for Configuring LDP Sessions (On Routers)
z Router A, Router B, and Router C support MPLS and use OSPF as the IGP for the MPLS
backbone.
z Local LDP sessions are established between Router A and Router B as well as between Router B
and Router C, while a remote LDP session is established between Router A and Router C.
Network diagram
Figure 1-8 Network diagram for configuring LDP sessions on routers
1) Configure the IP addresses of the interfaces

Configure the IP addresses and masks of the interfaces including the loopback interfaces as required in
Figure 1-8. The following gives only the configuration procedure for Router A.
[Sysname] sysname RouterA
1-34
2) Configure the routes for OSPF to advertise.
[RouterA] ospf
[RouterB] ospf
[RouterB-ospf-1-area-0.0.0.0] return
[RouterC] ospf
[RouterC-ospf-1-area-0.0.0.0] return
After completing the above configurations, you will see that every router has learned the routes to other
routers if you execute the display ip routing-table command. The following takes Router A as an
example:
1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.9/32 OSPF 10 1563 10.1.1.2 S1/0
3.3.3.9/32 OSPF 10 3125 10.1.1.2 S1/0
10.1.1.0/24 Direct 0 0 10.1.1.1 S1/0
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.1.1.2/32 Direct 0 0 10.1.1.2 S1/0
20.1.1.0/24 OSPF 10 3124 10.1.1.2 S1/0
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
Now, OSPF adjacency should have been established between Router A and Router B and between
Router B and Router C respectively. If you execute the display ospf peer verbose command, you will
find that the neighbors are in the state of Full. The following takes Router A as an example:
1-35
Neighbors
Area 0.0.0.0 interface 10.1.1.1(Serial1/0)'s neighbors
State: Full Mode:Nbr is Master Priority: 1
DR: None BDR: None MTU: 1500
3) Configure MPLS basic capability and enable LDP
[RouterA] mpls lsr-id 1.1.1.9
[RouterA] mpls
[RouterA-mpls] quit
[RouterA] mpls ldp
[RouterA-mpls-ldp] quit
[RouterA-Serial1/0] mpls
[RouterA-Serial1/0] mpls ldp
[RouterB] mpls lsr-id 2.2.2.9
[RouterB] mpls
[RouterB-mpls] quit
[RouterB] mpls ldp
[RouterB-mpls-ldp] quit
[RouterB-Serial1/0] mpls
[RouterB-Serial1/0] mpls ldp
[RouterB-Serial1/1] mpls
[RouterB-Serial1/1] mpls ldp
[RouterC] mpls lsr-id 3.3.3.9
[RouterC] mpls
[RouterC-mpls] quit
[RouterC] mpls ldp
[RouterC-mpls-ldp] quit
[RouterC-Serial1/0] mpls
[RouterC-Serial1/0] mpls ldp
After completing the above configurations, local sessions should have been established between
Router A and Router B and between Router B and Router C. You can execute the display mpls ldp
1-36
session command to check whether the local sessions have been established, or use the display
mpls ldp peer command to check the peers. The following takes Router A as an example:
[RouterA] display mpls ldp session
LDP Session(s) in Public Network
Total number of sessions: 1
----------------------------------------------------------------
Peer-ID Status LAM SsnRole FT MD5 KA-Sent/Rcv
----------------------------------------------------------------
2.2.2.9:0 Operational DU Passive Off Off 5/5
----------------------------------------------------------------
LAM : Label Advertisement Mode FT : Fault Tolerance
[RouterA] display mpls ldp peer
LDP Peer Information in Public network
Total number of peers: 1
-----------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
----------------------------------------------------------------
2.2.2.9:0 2.2.2.9 Serial1/0
----------------------------------------------------------------
4) Configure the remote LDP session
[RouterA] mpls ldp remote-peer peerc
[RouterA-mpls-ldp-remote-peerc] remote-ip 3.3.3.9
[RouterA-mpls-ldp-remote-peerc] quit
[RouterC] mpls ldp remote-peer peera
[RouterC-mpls-ldp-remote-peera] remote-ip 1.1.1.9
[RouterC-mpls-ldp-remote-peera] quit
After completing the above configurations, you will find by issuing the following commands on Router A
that the remote LDP session with Router C is already established:
[RouterA] display mpls ldp session
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
[RouterA] display mpls ldp peer
-----------------------------------------------------------------
-----------------------------------------------------------------
1-37
2.2.2.9:0 2.2.2.9 Serial1/0
3.3.3.9:0 3.3.3.9 Remote Peer : peerc
-----------------------------------------------------------------
Example for Configuring LDP Sessions (On Switches)
z Switch A, Switch B, and Switch C support MPLS and use OSPF as the IGP for the MPLS
backbone.
z Local LDP sessions are established between Switch A and Switch B as well as between Switch B
and Switch C, while a remote LDP session is required between Switch A and Switch C.
Network diagram
Figure 1-9 Network diagram for configuring LDP sessions on switches
1) Configure the IP addresses of the interfaces

Configure the IP addresses and masks of the interfaces including the VLAN interfaces and loopback
interfaces as required in Figure 1-9. The detailed configuration procedure is omitted here.
2) Configure the routes for OSPF to advertise
[Sysname] sysname SwitchA
[SwitchA] ospf
[Sysname] sysname SwitchB
[SwitchB] ospf
1-38
[Sysname] sysname SwitchC
[SwitchC] ospf
After completing the above configurations, you will see that every switch has learned the routes to other
switches if you execute the display ip routing-table command. The following takes Switch A as an
example:
1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.9/32 OSPF 10 1563 10.1.1.2 Vlan1
3.3.3.9/32 OSPF 10 3125 10.1.1.2 Vlan1
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan1
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.1.1.2/32 Direct 0 0 10.1.1.2 Vlan1
20.1.1.0/24 OSPF 10 3124 10.1.1.2 Vlan1
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
Now, OSPF adjacency should have been established between Switch A and Switch B and between
Switch B and Switch C respectively. If you execute the display ospf peer verbose command, you will
find that the neighbors are in the state of Full. The following takes Switch A as an example:
OSPF Process 1 with Switch ID 1.1.1.9
Neighbors
State: Full Mode:Nbr is Master Priority: 1
DR: None BDR: None MTU: 1500
3) Configure MPLS basic capability and enable LDP
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] quit
[SwitchA] mpls ldp
[SwitchA-mpls-ldp] quit
1-39
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls ldp
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] quit
[SwitchB] mpls ldp
[SwitchB-mpls-ldp] quit
[SwitchB-Vlan-interface1] mpls
[SwitchB-Vlan-interface1] mpls ldp
[SwitchB-Vlan-interface2] mpls ldp
[SwitchC] mpls lsr-id 1.1.1.9
[SwitchC] mpls
[SwitchC-mpls] quit
[SwitchC] mpls ldp
[SwitchC-mpls-ldp] quit
[SwitchC-Vlan-interface1] mpls
[SwitchC-Vlan-interface1] mpls ldp
After completing the above configurations, local sessions should have been established between
Switch A and Switch B and between Switch B and Switch C. You can execute the display mpls ldp
session command to check whether the local sessions have been established, or use the display
mpls ldp peer command to check the peers. The following takes Switch A as an example:
[SwitchA] display mpls ldp session
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
[SwitchA] display mpls ldp peer
-----------------------------------------------------------------
----------------------------------------------------------------
1-40
2.2.2.9:0 2.2.2.9 Vlan-interface1
----------------------------------------------------------------
4) Configure the remote LDP session
[SwitchA] mpls ldp remote-peer peerc
[SwitchA-mpls-ldp-remote-peerc] remote-ip 3.3.3.9
[SwitchA-mpls-ldp-remote-peerc] quit
[SwitchC] mpls ldp remote-peer peera
[SwitchC-mpls-ldp-remote-peera] remote-ip 1.1.1.9
[SwitchC-mpls-ldp-remote-peera] quit
After completing the above configurations, you will find by issuing the following commands on Switch A
that the remote LDP session with Switch C is already established:
[SwitchA] display mpls ldp session
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
[SwitchA] display mpls ldp peer
-----------------------------------------------------------------
-----------------------------------------------------------------
2.2.2.9:0 2.2.2.9 Vlan-interface1
3.3.3.9:0 3.3.3.9 Remote Peer : peerc
-----------------------------------------------------------------
Example for Configuring LDP to Establish LSPs (On Routers)
On the network in Figure 1-8, an LSP is required from Router A to Router C. Check the validity and
reachability of the LSP.
Network diagram
See Figure 1-8.
1) Configure LDP sessions. Refer to Example for Configuring LDP Sessions (On Routers).
2) Configure the LSP establishment triggering policy for LDP to establish LSPs.
1-41
For LDP to establish an LSP, LDP sessions are required between neighboring routers along the LSP. In
Figure 1-8, an LDP LSP can be established from Router A to Router C provided that local LDP sessions
exist between Router A and Router B, and between Router B and Router C; no remote LDP session is
required between Router A and Router C.
[RouterA] mpls
[RouterA-mpls] lsp-trigger all
[RouterA-mpls] return
[RouterB] mpls
[RouterB-mpls] lsp-trigger all
[RouterB-mpls] quit
[RouterC] mpls
[RouterC-mpls] lsp-trigger all
[RouterC-mpls] quit
After completing the above configurations, you will see that the LSPs have been established if you
execute the display mpls ldp lsp command. The following takes Router A as an example:
<RouterA> display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------
SN DestAddress/Mask In/OutLabel Next-Hop In/Out-Interface
------------------------------------------------------------------
1 1.1.1.9/32 3/NULL 127.0.0.1 Ser1/0/InL0
2 2.2.2.9/32 NULL/3 10.1.1.2 -------/Ser1/0
3 3.3.3.9/32 NULL/1025 10.1.1.2 -------/Ser1/0
4 20.1.1.0/24 NULL/3 10.1.1.2 -------/Ser1/0
-------------------------------------------------------------------
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
# Check the validity and reachability of the LSP.

<RouterA> ping lsp ipv4 3.3.3.9 32
LSP PING FEC: LDP IPV4 PREFIX 3.3.3.9/32 : 100 data bytes, press CTRL_C to break
Reply from 20.1.1.2: bytes=100 Sequence=1 time = 2 ms
--- FEC: LDP IPV4 PREFIX 3.3.3.9/32 ping statistics ---

1-42
0.00% packet loss
Example for Configuring LDP to Establish LSPs (On Switches)
On the network in Figure 1-9, an LSP is required between Switch A and Switch C. Check the validity and
reachability of the LSP.
Network diagram
See Figure 1-9.
1) Configure LDP sessions. Refer to Example for Configuring LDP Sessions (On Switches).
2) Configure the LSP establishment triggering policy for LDP to establish LSPs.
For LDP to establish an LSP, LDP sessions are required between neighboring routers along the LSP. In
Figure 1-9, an LDP LSP can be established from Switch A to Switch C provided that local LDP sessions
exist between Switch A and Switch B, and between Switch B and Switch C; no remote LDP session is
required between Switch A and Switch C.
[SwitchA] mpls
[SwitchA-mpls] lsp-trigger all
[SwitchA-mpls] return
[SwitchB] mpls
[SwitchB-mpls] lsp-trigger all
[SwitchB-mpls] quit
[SwitchC] mpls
[SwitchC-mpls] lsp-trigger all
[SwitchC-mpls] quit
After completing the above configurations, you will see that the LSPs have been established if you
execute the display mpls ldp lsp command. The following takes Switch A as an example:
<SwitchA> display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------
SN DestAddress/Mask In/OutLabel Next-Hop In/Out-Interface
------------------------------------------------------------------
1 1.1.1.9/32 3/NULL 127.0.0.1 Vlan1/InLoop0
2 2.2.2.9/32 NULL/3 10.1.1.2 ----/Vlan1
1-43
3 3.3.3.9/32 NULL/1025 10.1.1.2 ----/Vlan1
4 20.1.1.0/24 NULL/3 10.1.1.2 ----/Vlan1
-------------------------------------------------------------------
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
# Check the validity and reachability of the LSP.

<SwitchA> ping lsp ipv4 3.3.3.9 32
LSP PING FEC: LDP IPV4 PREFIX 3.3.3.9/32 : 100 data bytes, press CTRL_C to break
--- FEC: LDP IPV4 PREFIX 3.3.3.9/32 ping statistics ---

0.00% packet loss
1-44
Table of Contents
1 MPLS TE Configuration 1-1

MPLS TE Overview1-1
Traffic Engineering and MPLS TE1-2
Basic Concepts of MPLS TE 1-3
MPLS TE Implementation 1-3
CR-LSP 1-4
CR-LDP 1-5
RSVP-TE 1-5
Traffic Forwarding1-10
Automatic Bandwidth Adjustment1-11
CR-LSP Backup 1-12
Fast Reroute1-12
DiffServ-Aware TE1-13
MPLS TE Configuration Task List1-14
Configuring MPLS TE Basic Capabilities1-15
Creating MPLS TE Tunnel over Static CR-LSP1-16
Configuring MPLS TE Tunnel with Dynamic Signaling Protocol1-17
Configuring RSVP-TE Advanced Features1-23
Tuning CR-LSP Setup1-27
Tuning MPLS TE Tunnel Setup 1-30
Configuration Procedures1-30
Configuring Traffic Forwarding1-32
Configuration Procedures1-32
Configuring Traffic Forwarding Tuning Parameters1-35
Configuring Automatic Bandwidth Adjustment1-38
Configuring CR-LSP Backup 1-39
i
Configuring FRR 1-39
Displaying and Maintaining MPLS TE1-42
Displaying and Maintaining MPLS TE 1-42
Resetting Automatic Bandwidth Adjustment 1-44
MPLS TE Configuration Examples 1-45
MPLS TE Using Static CR-LSP Configuration Example (on Routers)1-45
MPLS TE Using Static CR-LSP Configuration Example (on Switches) 1-49
MPLS TE Tunnel Using RSVP-TE Configuration Example (on Routers) 1-53
MPLS TE Using RSVP-TE Configuration Example (on Switches)1-60
RSVP-TE GR Configuration Example (on Routers)1-67
RSVP-TE GR Configuration Example (on Switches) 1-69
MPLS TE Using CR-LDP Configuration Example (on Routers)1-71
MPLS TE Using CR-LDP Configuration Example (on Switches) 1-78
CR-LSP Backup Configuration Example (on Routers)1-86
CR-LSP Backup Configuration Example (on Switches)1-89
FRR Configuration Example (on Routers)1-92
FRR Configuration Example (on Switches)1-102
MPLS TE in MPLS L3VPN Configuration Example (on Routers) 1-111
MPLS TE in MPLS L3VPN Configuration Example (on Switches) 1-119
Troubleshooting MPLS TE1-128
ii

Forwarding traffic along MPLS TE tunnels
Yes Yes Yes Yes
using policy routing
Forwarding traffic along MPLS TE tunnels
Yes Yes Yes Yes
through automatic route advertisement
Configuring automatic bandwidth
Yes Yes Yes Yes
adjustment
Resetting automatic bandwidth
Yes Yes Yes Yes
adjustment
1 MPLS TE Configuration
When configuring Multiprotocol Label Switching Traffic Engineering (MPLS TE), go to these sections for
information you are interested in:
z MPLS TE Overview
z MPLS TE Configuration Task List
z Displaying and Maintaining MPLS TE
z MPLS TE Configuration Examples
z Troubleshooting MPLS TE
MPLS TE Overview
z Traffic Engineering and MPLS TE
z Basic Concepts of MPLS TE
z MPLS TE Implementation
z CR-LSP
z CR-LDP
z RSVP-TE
z Traffic Forwarding
z Automatic Bandwidth Adjustment
1-1
z CR-LSP Backup
z Fast Reroute
z DiffServ-Aware TE
Traffic Engineering and MPLS TE
Traffic engineering
Network congestion is one of the major problems that can degrade your network backbone
performance. It may occur either when network resources are inadequate or when load distribution is
unbalanced. Traffic Engineering (TE) is intended to avoid the latter situation where partial congestion
may occur as the result of inefficient resource allocation.
TE can make best utilization of network resources and avoid non-even load distribution by real-time
monitoring traffic and traffic load on each network elements to dynamically tune traffic management
attributes, routing parameters and resources constraints.
The performance objectives associated with TE can be either of the following:
z Traffic oriented. These are performance objectives that enhance Quality of Service (QoS) of traffic
streams, such as minimization of packet loss, minimization of delay, maximization of throughput
and enforcement of service level agreement (SLA).
z Resource oriented. These are performance objectives that optimize resources utilization.
Bandwidth is a crucial resource on networks. Efficiently managing it is one major task of TE.
1) TE solution
As existing Interior Gateway Protocols (IGPs) are topology-driven and consider only network
connectivity, they fail to present some dynamic factors such as bandwidth and traffic characteristics.
This IGP disadvantage can be repaired by using an overlay model, such as IP over ATM or IP over FR.
An overlay model provides a virtual topology above the physical network topology for a more scalable
network design. It also provides better traffic and resources control support for implementing a variety of
traffic engineering policies.
Despite all the benefits, overlay models are not suitable for implementing traffic engineering in
large-sized backbones because of their inadequacy in extensibility. In this sense, MPLS TE is a better
traffic engineering solution for its extensibility and ease of implementation.
MPLS TE
MPLS is better than IGPs in implementing traffic engineering for the following:
z MPLS supports explicit LSP routing.
z LSP routing is easy to manage and maintain compared with traditional packet-by-packet IP
forwarding.
z Constraint-based Routed Label Distribution Protocol (CR-LDP) is suitable for implementing a
variety of traffic engineering policies.
z MPLS TE uses less system resources compared with other traffic engineering implementations.
MPLS TE combines the MPLS technology and traffic engineering. It delivers these benefits:
z Reserve resources by establishing LSP tunnels to specific destinations. This allows traffic to
bypass congested nodes to achieve appropriate load distribution.
z When network resources are insufficient, MPLS TE allows bandwidth-hungry LSPs or critical user
traffic to occupy the bandwidth for lower priority LSP tunnels.
1-2
z In case an LSP tunnel fails or congestion occurs on a network node, MPLS TE can provide route
backup and Fast Reroute (FRR).
With MPLS TE, a network administrator can eliminate network congestion simply by creating some
LSPs and congestion bypass nodes. Special offline tools are also available for the traffic analysis
performed when the number of LSPs is large.
Basic Concepts of MPLS TE
LSP tunnel
On an LSP, the nodes make forwarding decision for labeled packets based on label. The traffic thus is
transparent to the transits nodes on the LSP. In this sense, an LSP can be regarded as a tunnel.
MPLS TE tunnel
Reroute and transmission over multiple paths may involve multiple LSP tunnels. A set of such LSP
tunnels is called a traffic engineered tunnel (TE tunnel).
MPLS TE Implementation
MPLS TE mainly accomplishes two functions:

z Static Constraint-based Routed LSP (CR-LSP) processing to create and remove static CR-LSPs.
The bandwidth of LSPs must be configured manually.
z Dynamic CR-LSP processing to handle three types of CR-LSPs: basic CR-LSPs, backup CR-LSPs
and fast rerouted CR-LSPs.
Static CR-LSP processing is simple, while dynamic CR-LSP processing involves four phrases:
advertising TE attributes, calculating paths, establishing paths, and forwarding packets.
Advertising TE attributes
MPLS TE must be aware of dynamic TE attributes of each link on the network. This is achieved by
extending link state-based IGPs such as OSPF and IS-IS.
OSPF and IS-IS extensions add to link states such TE attributes as link bandwidth, color, among which
maximum reservable link bandwidth and non-reserved bandwidth with a particular priority are most
important.
Each node collects the TE attributes of all links on all routers within the local area or at the same level to
build up a TE database (TEDB).
Calculating paths
Link state-based routing protocols use Shortest Path First (SPF) to calculate the shortest path to each
network node.
In MPLS TE, the Constraint-based Shortest Path First (CSPF) algorithm is used. It is derived from SPF
and makes calculation based on two conditions:
z Constraints on the LSP to be set up with respect to bandwidth, color, preemption/holding priority,
explicit path and other constraints. They are configured at the LSP ingress.
z TEDB
What CSPF does to identify the shortest path to an LSP egress is first pruning TE attribute incompliant
links from the TEDB and then performing SPF calculation
1-3
Establishing paths
When setting up LSP tunnels, you may use two types of signaling: CR-LDP and RSVP-TE. Both can
carry constraints such as LSP bandwidth, some explicit route information, and color and deliver the
same function.
They are different in that CR-LDP establishes LSPs using TCP while RSVP-TE using raw IP.
RSVP is a well-established technology in terms of its architecture, protocol procedures and support to
services; while CR-LDP is an emerging technology with better scalability.
Both CR-LDP and RSVP-TE are supported on your device.
Forwarding packets
Packets are forwarded over established tunnels.
CR-LSP
Unlike ordinary LSPs established based on routing information, CR-LSPs are established based on
criteria such as bandwidth, selected path, and QoS parameters in addition to routing information.
The mechanism setting up and managing constraints is called Constraint-based Routing (CR).
CR-LSP involves these concepts:
z Strict and loose explicit routes
z Traffic characteristics
z Preemption
z Route pinning
z Administrative group and affinity attribute
z Reoptimization
Strict and loose explicit routes
An LSP is called a strict explicit route if all LSRs along the LSP are specified.
An LSP is called a loose explicit route if the downstream LSR selection conditions rather than LSRs are
defined.
Traffic characteristics
Traffic is described in terms of peak rate, committed rate, and service granularity.
The peak and committed rates describe the bandwidth constraints of a path while the service granularity
specifies a constraint on the delay variation that the CR-LDP MPLS domain may introduce to a path's
traffic.
Preemption
CR-LDP signals the resources required by a path on each hop of the route. If a route with sufficient
resources cannot be found, existing paths may be rerouted to reallocate resources to the new path.
This is called path preemption.
Two priorities, setup priority and holding priority, are assigned to paths for making preemption decision.
Both setup and holding priorities range from 0 to 7, with a lower numerical number indicating a higher
priority.
For a new path to preempt an existing path, the setup priority of the new path must be greater than the
holding priority of the existing path. To initiate a preemption, the Resv message of RSVP-TE is sent.
1-4
To avoid flapping caused by improper preemptions between CR-LSPs, the setup priority of a CR-LSP
should not be set higher than its holding priority.
Route pinning
Route pinning prevents an established CR-LSP from changing upon route changes.
If a network does not run IGP TE extension, the network administrator will be unable to identify from
which part of the network the required bandwidth should be obtained when setting up a CR-LSP. In this
case, loose explicit route (ER-hop) with required resources is used. The CR-LSP thus established
however, may change when the route changes, for example, when a better next hop becomes available.
If this is undesirable, the network administrator can set up the CR-LSP using route underpinning to
make it a permanent path.
Administrative group and affinity attribute
The affinity attribute of an MPLS TE tunnel identifies the properties of the links that the tunnel can use.
Together with the link administrative group, it decides which links the MPLS TE tunnel can use.
Reoptimization
Traffic engineering is a process of allocating/reallocating network resources. You may configure it to

meet desired QoS.
Normally, service providers use some mechanism to optimize CR-LSPs for best use of network
resources. They can do this manually but CR-LSP measurement and tuning are required. Alternatively,
they can use MPLS TE where CR-LSPs are dynamically optimized.
Dynamic CR-LSP optimization involves periodic calculation of paths that traffic trunks should traverse. If
a better route is found for an existing CR-LSP, a new CR-LSP will be established to replace the old one,
and services will be switched to the new CR-LSP.
CR-LDP
Constraint-based Routed Label Distribution Protocol (CR-LDP) is an extension to LDP. It is used in

MPLS TE to create an explicit path with resource reservation between the ingress node and the egress
node.
When initiating an LSP at the ingress, CR-LDP appends some constraints in the label request message.
RSVP-TE

z Overview
z Basic concepts of RSVP-TE
z Make-before-break
z RSVP-TE messages
z Setting up an LSP tunnel
z RSVP refresh mechanism
z PSB, RSB and BSB timeouts
z RSVP-TE GR
1-5
Overview
Currently, two QoS models are available: Integrated Service (IntServ) and Differentiated Service
(DiffServ).
Resource Reservation Protocol (RSVP) is designed for IntServ. It reserves resources on each node
along a path. RSVP operates at the transport layer but does not participate in data transmission. It is an
Internet control protocol similar to ICMP.
The following are features of RSVP:
z Unidirectional
z Receiver oriented. The receiver initiates resource reservation requests and is responsible for
maintaining the reservation information.
z Using soft state mechanism to maintain resource reservation information.
Extended RSVP can support MPLS label distribution and allow resource reservation information to be
transmitted with label bindings. This extended RSVP is called RSVP-TE, which is operating as a
signaling protocol for LSP tunnel setup in MPLS TE.
Basic concepts of RSVP-TE
1) Soft state
Soft state is a mechanism used in RSVP-TE to periodically refresh the resource reservation state on a
node. The resource reservation state includes the path state and the reservation state. The path state is
generated and refreshed by the Path message, and the reservation state is generated and refreshed by
the Resv message. A state is to be removed if no refresh messages are received for it in certain interval.
2) Resource reservation style
Each LSP set up using RSVP-TE is assigned a resource reservation style. During an RSVP session,
the receiver decides which reservation style can be used for this session and thus which LSPs can be
used.
Currently, two reservation styles are available:
z Fixed-filter style (FF) where resources are reserved for individual senders and cannot be shared
among senders on the same session.
z Shared-explicit style (SE) where resources are reserved for senders on the same session and
shared among them.
At present, SE is only used for make-before-break because multiple LSPs cannot be present on the
same session.
Make-before-break
Make-before-break is a mechanism to change MPLS TE tunnel attributes with minimum data loss and
without extra bandwidth.
1-6
Figure 1-1 Diagram for make-before-break
Figure 1-1 presents a scenario where a path Router A Router B Router C Router D is
established with 30 Mbps reserved bandwidth between Router A and Router D. The remaining
bandwidth is then 30 Mbps.
If 40 Mbps path bandwidth is requested, the remaining bandwidth of the Router A Router B Router
C Router D path will be inadequate. The problem cannot be addressed by selecting another path,
Router A Router E Router C Router D, because the bandwidth of the Router C Router D link
is inadequate.
To address the problem, you may use the make-before-break mechanism. It allows the new path to
share the bandwidth of the original path at the Router C Router D link. Upon creation of the new path,
traffic is switched to the new path and the previous path is torn down. This helps avoid traffic interruption
effectively.
RSVP-TE messages
RSVP-TE uses RSVP messages with extensions. The following are RSVP messages:
z Path messages: transmitted along the path of data transmission downstream by each RSVP
sender to save path state information on each node along the path.
Resv messages: sent by each receiver upstream towards senders to request resource reservation
and to create and maintain reservation state on each node along the reverse of data transmission
path.
z PathTear messages: sent downstream immediately once created to remove the path state and
related reservation state on each node along the path.
z ResvTear messages: sent upstream immediately once created to remove the reservation state on
each node along the path.
z PathErr messages: sent upstream to report Path message processing errors to senders. They do
not affect the state of the nodes along the path.
z ResvErr messages: sent downstream to notify the downstream nodes that error occurs during
Resv message processing or reservation error occurs as the result of preemption.
z ResvConf messages: sent to receivers to confirm Resv messages.
z Hello messages: sent between any two directly connected RSVP neighbors to set up and maintain
the neighbor relationship that has local significance on the link.
The TE extension to RSVP adds new objects to the Path message and the Resv message. These
objects carry not only label bindings but also routing constraints, supporting CR-LSP and FRR.
z New objects added to the Path message include LABEL_REQUEST, EXPLICIT_ROUTE,
RECORD_ROUTE, and SESSION_ATTRIBUTE.
z New objects added to the Resv message include LABEL and RECORD_ROUTE
1-7
The LABEL_REQUEST object in the Path message requests the label bindings for an LSP. It is also
saved in the path state block. The node receiving LABEL_REQUEST advertises the label binding using
the LABEL object in the Resv message to the upstream node, thus accomplishing label advertisement
and transmission.
Setting up an LSP tunnel
Figure 1-2 shows how to set up a LSP tunnel with RSVP:

Figure 1-2 Set up an LSP tunnel
The following is a simplified procedure for setting up an LSP tunnel with RSVP:
1) The ingress LSR sends a Path message that carries the label request information, and then
forwards the message along the path calculated by CSPF hop-by-hop towards the egress LSR.
2) After receiving the Path message, the egress generates a Resv message carrying the reservation
information and label and then forwards the message towards the ingress along the reverse
direction of the path along which the Path message travels. The LSRs that the Resv message
traverses along the path reserve resources as required.
3) When the ingress LSR receives the Resv message, LSP is established.
As resources are reserved on the LSRs along the path for the LSP established using RSVP-TE,
services transmitted on the LSP are guaranteed.
RSVP refresh mechanism
RSVP maintains path and reservation state by periodically retransmitting two types of messages: Path
and Resv. These periodically retransmitted Path and Resv messages are called refresh messages.
They are sent along the path that the last Path or Resv message travels to synchronize state between
RSVP neighbors and recover lost RSVP messages.
When many RSVP sessions are present, periodically sent refresh messages become a network burden.
In addition, for some delay sensitive applications, the refreshing delay they must wait for recovering lost
RSVP messages may be unbearable. As tuning refresh intervals is not adequate to address the two
problems, the refreshing mechanism was extended in RFC 2961 RSVP Refresh Overhead Reduction
Extensions as follows to address the problems:
1) Message_ID extension
RSVP itself uses Raw IP to send messages. The Message_ID extension mechanism defined in RFC
2961 adds objects that can be carried in RSVP messages. Of them, the Message_ID object and the
Message_ID_ACK object are used to acknowledge RSVP messages, thus improving transmission
reliability.
On an interface enabled with the Message_ID mechanism, you may configure RSVP message
retransmission. After the interface sends an RSVP message, it waits for acknowledgement. If no ACK is
received before the initial retransmission interval (Rf seconds for example) expires, the interface
resends the message. After that, the interface resends the message at an exponentially increased
retransmission interval equivalent to (1 + Delta) Rf seconds.
2) Summary refresh extension
1-8
Send summary refreshes (Srefreshes) rather than retransmit standard Path or Resv messages to
refresh related RSVP state. This reduces refresh traffic and allows nodes to make faster processing.
To use summary refresh, you must use the Message_ID extension. Only states advertised using
MESSAGE_ID included Path and Resv messages can be refreshed using summary refreshes.
PSB, RSB and BSB timeouts
To create an LSP tunnel, the sender sends a Path message with a LABEL_REQUEST object. After
receiving this Path message, the receiver assigns a label for the path and puts the label binding in the
LABEL object in the returned Resv message.
The LABEL_REQUEST object is stored in the path state block (PSB) on the upstream nodes, while the
LABEL object is stored in the reservation state block (RSB) on the downstream nodes. The state stored
in the PSB or RSB object times out and is removed after the number of consecutive non-refreshing
times exceeds the PSB or RSB timeout keep-multiplier.
You may sometimes want to store the resource reservation state for a reservation request that does not
pass the admission control on some node. This however should not prevent the resources reserved for
the request from being used by other requests. To handle this situation, the node transits to the
blockade state and a blockade state block (BSB) is created on each downstream node. When the
number of non-refreshing times exceeds the blockade multiplier, the state in the BSB is removed.
RSVP-TE GR
For introduction to Graceful Restart (GR), refer to GR Overview in the System Volume.
The RSVP-TE GR function depends on the extended hello capability of RSVP-TE. A GR-capable
device advertises its GR capability and relevant time parameters to its neighbors by extended RSVP
Hello packets. If a device and all its neighbors have the RSVP GR capability and have exchanged GR
parameters, each of them can function as the GR helper of another device, allowing data to be
forwarded without interruption when the GR restarter is rebooting.
A GR helper considers that a GR restarter is rebooting when it receives no Hello packets from the
restarter in a specified period of time. When a GR restarter is rebooting, the GR helpers retain soft state
information about the GR restarter and keep sending Hello packets periodically to the GR restarter until
the restart timer expires.
If a GR helper and the GR restarter reestablish a Hello session before the restart timer expires, the
recovery timer is started and signaling packet exchanging is triggered to restore the original soft state.
Otherwise, all RSVP soft state information and forwarding entries relevant to the neighbor will be
removed. If the recovery timer expires, soft state information and forwarding entries that are not
restored during the GR restarting process will be removed.
1-9
z A distributed device that supports primary-secondary switchover, if configured with RSVP-TE GR,
can act as a GR restarter and a GR helper at the same time.
z Distributed devices that do not support primary-secondary switchover and centralized devices, on
the contrary, can act as only GR helpers when they are configured with RSVP-TE GR.
Traffic Forwarding
For traffic to travel along an LSP tunnel, you need to make configuration after creating the MPLS TE
tunnel. Otherwise, traffic will be IP routed.
Even when an MPLS TE tunnel is available, traffic is IP routed if you do not configure it to travel the
tunnel. For traffic to be routed along an MPLS TE tunnel, you can use static routing, policy routing, or
automatic route advertisement.
Static routing
Static routing is the easiest way to route traffic along an MPLS TE tunnel. You only need to manually
create a route that reaches the destination through the tunnel interface.
For more information about static routing, refer to the Static Routing Configuration in the IP Routing
Volume.
Policy routing
You can also use policy routing to route traffic over an MPLS TE tunnel. In this approach, you need to
create a policy that specifies the MPLS TE tunnel interface as the output interface for traffic that
matches certain criteria defined in the referenced ACL.
This policy should be applied to the incoming interface.
For more information about policy routing, refer to the IP Unicast Policy Routing Configuration in the IP
Services Volume.
Automatic route advertisement
You can use automatic route advertisement to advertise MPLS TE tunnel interface routes to IGPs,
allowing traffic to be routed down MPLS TE tunnels.
Two approaches are available to automatic route advertisement: IGP shortcut and forwarding
adjacency.
1-10
OSPF and IS-IS support both approaches where TE tunnels are considered point-to-point links and TE
tunnel interfaces can be set as outgoing interfaces.
IGP shortcut, also known as autoroute announce, considers a TE tunnel as a logical interface directly
connected to the destination when computing IGP routes on the ingress of the TE tunnel.
IGP shortcut and forwarding adjacency are different in that in the forwarding adjacency approach,
routes with TE tunnel interfaces as outgoing interfaces are advertised to neighboring devices but not in
the IGP shortcut approach. Therefore, TE tunnels are visible to other devices in the forwarding
adjacency approach but not in the IGP shortcut approach.
Figure 1-3 IGP shortcut and forwarding adjacency
Router B
20 Router C
10
Router A
10
10 20
10
Router D Router E
As shown in Figure 1-3, a TE tunnel is present between Router D and Router C. With IGP shortcut
enabled, the ingress node Router D can use this tunnel when calculating IGP routes. This tunnel,
however, is invisible to Router A; therefore, Router A cannot use this tunnel to reach Router C. With
forwarding adjacency enabled, Router A can known the presence of the TE tunnel and thus forward
traffic to Router C to Router D though this tunnel.
The configuration of IGP shortcut and forwarding adjacency is broken down into tunnel configuration
and IGP configuration. When making tunnel configuration on a TE tunnel interface, consider the
following:
z The tunnel destination address should be in the same area where the tunnel interface is located.
z The tunnel destination address should be reachable through intra-area routing.
Automatic Bandwidth Adjustment
As users cannot estimate accurately how much traffic they need to transmit though service provider
networks, they are more willing to pay for used bandwidth. Therefore, a service provider should be able
to create TE tunnels from CR-LSPs with initially requested bandwidth for users, and automatically tune
the bandwidth resources assigned to these CR-LSPs when user services increase.
Traffic engineering thus must be able to dynamically allocate resources without interrupting services
when network environment changes.
Automatic bandwidth adjustment of MPLS TE fulfills this function. It can dynamically tune TE tunnel
bandwidth based on measured service traffic.
1-11
CR-LSP Backup
CR-LSP backup provides end-to-end path protection for the entire LSP without time limitation. This is
different from Fast Reroute (FRR) which provides quick but temporary per-link or per-node protection
on an LSP.
In the same TE tunnel, the LSP used to back up a primary LSP is called a secondary LSP. When the
ingress of a TE tunnel detects that the primary LSP is unavailable, it switches traffic to the secondary
LSP and after the primary LSP becomes available, switches traffic back. This is how LSP path
protection is achieved.
Two approaches are available for CR-LSP backup:
z Hot backup where a secondary CR-LSP is created immediately after a primary CR-LSP is created.
MPLS TE switches traffic to the secondary CR-LSP after the primary CR-LSP fails.
z Standard backup where a secondary CR-LSP is created to take over after the primary CR-LSP
fails.
Fast Reroute

z Overview
z Basic concepts
z Protection
z Deploying FRR
Overview
Fast Reroute (FRR) provides a quick per-link or per-node protection on an LSP.

In this approach, once a link or node fails on a path, FRR comes up to reroute the path to a new link or
node to bypass the failed link or node. This can happen as fast as 50 milliseconds thus minimizing data
loss.
Once a link or node on an LSP configured with FRR fails, traffic is switched to the protection link and the
headend of the LSP starts attempting to set up a new LSP.
Basic concepts
The following are concepts that FRR involves throughout this document:
z Primary LSP: The protected LSP.
z Bypass LSP: An LSP used to protect the primary LSP.
z Point of local repair (PLR): The ingress of the bypass LSP. It must be located on the primary LSP
but must not be the egress.
z Merge point (MP): The egress of the bypass LSP. It must be located on the primary LSP but must
not be the ingress.
Protection
FRR provides link protection and node protection for an LSP as follows:
z Link protection, where the PLR and the MP are connected through a direct link and the primary
LSP traverses this link. When the link fails, traffic is switched to the bypass LSP. As shown in
Figure 1-4, the primary LSP is Router A Router B Router C Router D, and the bypass LSP
is Router B Router F Router C.
1-12
Figure 1-4 FRR link protection
z Node protection, where the PLR and the MP are connected through a device and the primary LSP
traverses this device. When the device fails, traffic is switched to the bypass LSP. As shown in
Figure 1-5, the primary LSP is Router A Router B Router C Router D Router E, and the
bypass LSP is Router B Router F Router D. Router C is the protected device.
Figure 1-5 FRR node protection
Deploying FRR
When configuring the bypass LSP, make sure the protected link or node is not on the bypass LSP.
As bypass LSPs are pre-established, FRR requires extra bandwidth. When network bandwidth is
insufficient, you are recommended to use FRR for crucial interfaces or links only.
DiffServ-Aware TE
Diff-Serv is a model that provides differentiated QoS guarantees based on class of service.
MPLS TE is a traffic engineering solution that focuses on optimizing network resources allocation.
DiffServ-aware TE (DS-TE) combines them to optimize network resources allocation at a per-service
class level. For traffic trunks which are distinguished by class of service, this means varied bandwidth
constraints.
Essentially, what DS-TE does is to map traffic trunks with LSPs, making each traffic trunk traverse the
constraints-compliant path.
DS-TE involves two concepts:
z Class type (CT): The set of traffic trunks crossing a link that is governed by a specific set of
Bandwidth constraints. CT is used for purposes of link bandwidth allocation, constraint based
routing, and admission control. A given traffic trunk belongs to the same CT on all links.
1-13
z Bandwidth constraints (BCs): Different BC models can be created to control CTs. A BC model is
broken down into maximum number of BCs (MaxBC), and mappings between BCs and CTs.
Currently, DiffServ-Aware TE is not supported.
z RFC 2702 Requirements for Traffic Engineering Over MPLS

z RFC 3212 Constraint-Based LSP Setup using LDP
z RFC 2205 Resource ReSerVation Protocol
z RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels
z RFC 2961 RSVP Refresh Overhead Reduction Extensions
z RFC 3564 Requirements for Support of Differentiated Service-aware MPLS Traffic Engineering
MPLS TE Configuration Task List

Complete the following tasks to configure MPLS TE:
Task Remarks
Configuring MPLS TE Basic Capabilities Required
Configuring Creating MPLS TE Tunnel over Static CR-LSP Required

an MPLS TE Use either
tunnel Configuring MPLS TE Tunnel with Dynamic Signaling Protocol approach
Configuring RSVP-TE Advanced Features Optional
Tuning CR-LSP Setup Optional
Tuning MPLS TE Tunnel Setup Optional
Forwarding traffic along MPLS TE

tunnels using static routes
Forwarding traffic along MPLS TE Required
Configuring Traffic Forwarding tunnels using policy routing
Use any approach
Forwarding traffic along MPLS TE
tunnels through automatic route
advertisement
Configuring Traffic Forwarding Tuning Parameters Optional
Configuring Automatic Bandwidth Adjustment Optional

Configuring CR-LSP Backup Optional
Configuring FRR Optional
1-14
Configuring MPLS TE Basic Capabilities
MPLS TE basic capabilities are essential to MPLS TE feature configurations. After configuring the basic
capabilities, you need to make other configurations in order to use MPLS TE depending on the actual
requirements.
Before the configuration, do the following:

z Configure static routing or IGPs to make sure all LSRs are reachable.
z Configure MPLS basic capabilities.
For configuration information about MPLS basic capability, refer to MPLS Basics Configuration in the
MPLS Volume.
Follow these steps to configure MPLS TE basic capabilities:

Required
Enable global MPLS TE mpls te
Disabled by default
Enter the interface view of an interface interface-type

MPLS TE link interface-number
Required
Enable interface MPLS TE mpls te
Disabled by default
Create a tunnel interface and interface tunnel

Required
enter its view tunnel-number
Assign an IP address to the ip address ip-address
Required
tunnel interface netmask
Set the tunnel protocol to MPLS
tunnel-protocol mpls te Required
TE
Configure the destination
destination ip-address Required
address of the tunnel
Configure the tunnel ID of the
mpls te tunnel-id tunnel-id Required
tunnel
Submit the current tunnel
mpls te commit Required
configuration
1-15
z Depending on the MPLS TE signaling protocol a tunnel uses, the basic capabilities you configured
in this section may be inadequate for the tunnel to work and you may need to make extra
configurations.
z For information about tunnel interfaces, refer to Tunneling Configuration in the IP Services Volume.
Creating MPLS TE Tunnel over Static CR-LSP

Creating MPLS TE tunnels over static CR-LSPs does not involve configuration of tunnel constraints or
the issue of IGP TE extension or CSPF. What you need to do is to create a static CR-LSP and a TE
tunnel using static signaling and then associate them.
Despite its ease of configuration, the application of MPLS TE tunnels over static CR-LSPs is restricted
because they do not accept bandwidth constraints and cannot dynamically adapt to network changes.
Static CR-LSPs are special static LSPs. They share the same constraints and use the same label space
spanning 16 to 1023.
Before making the configuration, do the following:

z Configure static routing or an IGP protocol to make sure that all LSRs are reachable.
z Configure MPLS TE basic capabilities.
Follow these steps to create an MPLS TE tunnel over a CR-LSP:

Enter the interface view of an
interface tunnel tunnel-number
MPLS TE tunnel
Configure the tunnel to use
mpls te signal-protocol static Required
static CR-LSP
Submit the current tunnel
configuration
1-16
static-cr-lsp ingress tunnel-name

destination dest-addr { nexthop
next-hop-addr | outgoing-interface
At the ingress
interface-type interface-number } Required
out-label out-label-value [ bandwidth
[ bc0 | bc1 ] bandwidth-value ] Use any of the
commands
Create a static static-cr-lsp transit tunnel-name depending on the
CR-LSP on incoming-interface interface-type location of your
your device interface-number in-label in-label-value device in the
depending on On the transit { nexthop next-hop-addr | network.
its location in node outgoing-interface interface-type Support for the
the network interface-number } out-label outgoing-interface,
out-label-value [ bandwidth [ bc0 | bc1 ] lsrid, and tunnel-id
bandwidth-value ] keywords depends
static-cr-lsp egress tunnel-name on the device model.
incoming-interface interface-type
At the egress
interface-number in-label in-label-value
[ lsrid ingress-lsr-id tunnel-id tunnel-id ]
z The tunnel-name argument specifies the name of the MPLS TE tunnel carried over the static
CR-LSP.
z The tunnel-name argument in the static-cr-lsp ingress command is case sensitive. Suppose you
create a tunnel interface with the interface tunnel 2 command. To specify it for the tunnel-name in
the static-cr-lsp ingress command, you must input its name in the form of Tunnel2. Otherwise,
your tunnel establishment attempt will fail. This restriction however does not apply to transit and
egress nodes.
z The next hop address cannot be a local public address when configuring the static CR-LSP on the
ingress or a transit node.
z On a device supporting MPLS OAM, ID of the ingress node and tunnel ID are required to configure
the device to act as the egress.
Configuring MPLS TE Tunnel with Dynamic Signaling Protocol

Dynamic signaling protocol can adapt the path of a TE tunnel to network changes and implement
redundancy, FRR, and other advanced features.
The following describes how to create an MPLS TE tunnel with a dynamic signaling protocol:
z Configure MPLS TE properties for links and advertise them through IGP TE extension to form a
TEDB.
z Configure tunnel constraints.
z Use the CSPF algorithm to calculate a preferred path based on the TEDB and tunnel constraints.
z Establish the path by using the signaling protocol RSVP-TE or CR-LDP.
1-17
To form a TEDB, you must configure the IGP TE extension for the nodes on the network to send TE
LSAs. If the IGP TE extension is not configured, the CR-LSP is created based on IGP routing rather
than computed by CSPF.
Before making the configuration, do the following:

z Configure static routing or an IGP protocol to make sure that all LSRs are reachable.
z Configure MPLS TE basic capabilities.
Complete the following tasks to configure an MPLS TE tunnel using a dynamic signaling protocol:
Task Remarks
Configuring MPLS TE properties for a link Optional
Configuring CSPF Optional

Configuring OSPF TE Required when CSPF is configured
Choose one depending on the IGP protocol
Configuring IS-IS TE used.
Configuring an MPLS TE explicit path Optional
Configuring MPLS TE tunnel constraints Optional
Establishing an MPLS TE tunnel with CR-LDP Optional

Use either approach.
Establishing an MPLS TE tunnel with RSVP-TE By default, RSVP-TE is used for establishing an
MPLS TE tunnel.
Configuring MPLS TE properties for a link
Follow these steps to configure MPLS TE properties for a link:

Enter interface view of MPLS

TE link
Configure maximum link mpls te max-link-bandwidth
Optional
bandwidth bandwidth-value [ bc1 bc1-bandwidth ]
Configure maximum reservable mpls te max-reservable-bandwidth
Optional
bandwidth of the MPLS TE link bandwidth-value [ bc1 bc1-bandwidth ]
1-18
Configuring CSPF
Follow these steps to configure CSPF:
Required
Enable CSPF on your device mpls te cspf
Disabled by default
Configuring OSPF TE
Configure OSPF TE if the routing protocol is OSPF and a dynamic signaling protocol is used for MPLS
TE tunnel setup.
The OSPF TE extension uses Opaque Type 10 LSAs to carry TE attributes of links. Before configuring
OSPF TE, you need to enable the opaque capability of OSPF. In addition, for TE LSAs to be generated,
at least one neighbor must be in full state.
Follow these steps to configure OSPF TE:

Enter OSPF view ospf [ process-id ]
Enable the opaque LSA Required

Enter OSPF area view area area-id Required
Enable MPLS TE in the OSPF Required

mpls-te enable
area Disabled by default
Exit to OSPF view quit
For more information about OSPF opaque LSA, refer to OSPF Configuration in the IP routing volume.
Configuring IS-IS TE
Configure IS-IS TE if the routing protocol is IS-IS and a dynamic signaling protocol is used for MPLS TE
tunnel setup. In case both OSPF TE and IS-IS TE are available, OSPF TE takes priority.
The IS-IS TE extension uses the sub-TLV of IS reachability TLV (type 22) to carry TE attributes. Before
configuring IS-IS TE, you need to configure the IS-IS wide metric style, which can be wide, compatible,
or wide-compatible.
1-19
z According to RFC 3784, the length of the IS reachability TLV (type 22) may reach the maximum of
255 octets in some cases.
z For an IS-IS LSP to carry this type of TLV and to be flooded normally on all interfaces with IS-IS
enabled, the MTU of any IS-IS enabled interface, including 27 octets of LSP header and two octets
of TLV header, cannot be less than 284 octets. If an LSP must also carry the authentication
information, the minimum MTU needs to be recalculated according to the packet structure.
In a word, with the TE feature, the MTU of any interface with IS-IS enabled is recommended to be equal
to or greater than 512 octets to guarantee that IS-IS LSPs can be flooded on the network.
Follow these steps to configure IS-IS TE:

Enter IS-IS view isis [ process-id ]
wide-compatible | Required
Configure the wide metric
{ compatible | By default, IS-IS uses narrow
attribute of IS-IS
narrow-compatible } metric style.
traffic-eng [ level-1 | level-2 | Required

Enable IS-IS TE
level-1-2 ] Disabled by default
Optional
te-set-subtlv { bw-constraint By default, the bw-constraint
Configure the TLV type of the parameter is carried in sub-TLV
value | lo-multiplier value |
sub-TLV carrying DS-TE 252; the lo-multiplier
unreserved-bw-sub-pool
parameters parameter in sub-TLV 253; and
value }
the unreserved-bw-sub-pool
parameter in sub-TLV 251.
z For more information about IS-IS, refer to IS-IS Configuration in the IP Routing Volume.
z IS-IS TE does not support secondary IP address advertisement. With IS-IS TE enabled on an
interface configured with multiple IP addresses, IS-IS TE advertises only the primary IP address of
the interface through the sub-TLV of IS reachability TLV (type 22). You are recommended to avoid
enabling IS-IS TE on an interface configured with secondary IP addresses.
Configuring an MPLS TE explicit path
An explicit path is a set of nodes. The relationship between any two neighboring nodes on an explicit
path can be either of the following:
z Strict: where the two nodes are directly connected.
z Loose: where the two nodes have devices in between.
1-20
When inserting nodes to an explicit path or modifying nodes on it, you may configure the include
keyword to have the established LSP traverse the specified nodes or the exclude keyword to have the
established LSP bypass the specified nodes.
Follow these steps to configure an MPLS TE explicit path:

Create an explicit path for
explicit-path path-name
MPLS TE tunneling and enter Required
[ disable | enable ]
its view
Optional
By default, the include
add hop ip-address1 [ include keyword and the strict keyword
Add a node to the explicit path [ loose | strict ] | exclude ] apply. In other words, the
{ after | before } ip-address2 explicit path traverses the
specified node and the next
node is a strict node.
Required
The next hop is a strict node by
Specify a next hop IP address next hop ip-address [ include default.
on the explicit path [ loose | strict ] | exclude ] Repeat this step to define a
sequential set of the hops that
the explicit path traverses.
Optional
By default, the include
Modify the IP address of modify hop ip-address1 keyword and the strict keyword
current node on the explicit ip-address2 [ [ include [ loose | apply. In other words, the
path strict ] | exclude ] explicit path traverses the
specified node and the next
node is a strict node.
Remove a node from the
delete hop ip-address Optional
explicit path
specified or all nodes on the list hop [ ip-address ] Optional
explicit path
Configuring MPLS TE tunnel constraints
Follow these steps to configure MPLS TE tunnel constraints:

Enter MPLS TE tunnel interface interface tunnel

view tunnel-number
Optional
Assign bandwidth to the MPLS mpls te bandwidth [ bc0 |
TE tunnel bc1 ] bandwidth No bandwidth is assigned by
default.
Specify a path for the tunnel to mpls te path { dynamic | Optional

use and set the preference of explicit-path pathname } By default, a tunnel uses the
the path preference value dynamically calculated path.
1-21
Submit current tunnel
configuration
Establishing an MPLS TE tunnel with CR-LDP
Follow these steps to establish an MPLS TE tunnel with CR-LDP:


view tunnel-number
Set the signaling protocol for Required
setting up MPLS TE tunnels to mpls te signal-protocol crldp
CR-LDP RSVP-TE applies by default.

configuration
Establishing an MPLS TE tunnel with RSVP-TE
Follow these steps to establish an MPLS TE tunnel with RSVP-TE:

Enable RSVP-TE on your Required

mpls rsvp-te
device Disabled by default
Enter interface view of MPLS interface interface-type

TE link interface-number
Enable RSVP-TE on the Required

mpls rsvp-te
interface Disabled by default

view tunnel-number
Set the signaling protocol for Optional
mpls te signal-protocol
setting up the MPLS TE tunnel
rsvp-te RSVP-TE applies by default.
to RSVP-TE
configuration
1-22
To use RSVP-TE as the signaling protocol for setting up the MPLS TE tunnel, you must enable both
MPLS TE and RSVP-TE on the interface for the tunnel to use.
Configuring RSVP-TE Advanced Features

RSVP-TE adds new objects in Path and Resv messages to support CR-LSP setup. RSVP-TE provides
many configurable options with respect to reliability, network resources, and other advanced features of
MPLS TE.
Before performing the configuration tasks in this section, be aware of each configuration objective and
its impact on your network.
Before configuring RSVP-TE advanced features, do the following:

z Configure MPLS basic capabilities
z Configure MPLS TE basic capabilities
z Establish an MPLS TE tunnel with RSVP-TE
Configuring RSVP-TE advanced features involves these tasks:

z Configuring RSVP reservation style
z Configuring RSVP state timers
z Configuring the RSVP refreshing mechanism
z Configuring the RSVP Hello extension
z Configuring RSVP-TE resource reservation confirmation
z Configuring RSVP authentication
Configuring RSVP reservation style
Each LSP set up using RSVP-TE is assigned a resource reservation style. During an RSVP session,
the receiver decides which reservation style can be used for this session and thus which LSPs can be
used.
Currently, two reservation styles are available:
z Fixed-filter style (FF) where resources are reserved for individual senders and cannot be shared
among senders on the same session.
z Shared-explicit style (SE) where resources are reserved for senders on the same session and
shared among them.
Follow these steps to configure RSVP reservation style:


view tunnel-number
1-23
Optional
Configure the resources
mpls te resv-style { ff | se } The default resource
reservation style for the tunnel
reservation style is SE.
configuration
In current MPLS TE applications, the SE style is mainly used for make-before-break, while the FF style
is rarely used.
Configuring RSVP state timers
Follow these steps to configure RSVP state timers:

Optional
Configure the path/reservation
mpls rsvp-te timer refresh The default path/reservation
state refresh interval of the
timevalue state refresh interval is 30
node
seconds.
Configure the keep multiplier mpls rsvp-te keep-multiplier Optional

for PSB and RSB number The default is 3.
Optional
Configure the blockade timeout mpls rsvp-te
multiplier blockade-multiplier number The default blockade timeout
multiplier is 4.
Configuring the RSVP refreshing mechanism
To enhance reliability of RSVP message transmission, the Message_ID extension mechanism is used
to acknowledge RSVP messages. The Message_ID extension mechanism is also referred to as the
reliability mechanism throughout this document.
After you enable RSVP message acknowledgement on an interface, you may enable retransmission.
To use summary refresh (Srefresh), you must use the Message_ID extension. Only states advertised
using MESSAGE_ID included Path and Resv messages can be refreshed using summary refreshes.
Follow these steps to configure RSVP refreshing mechanism:

Enter interface view of MPLS
TE link
1-24
Enable the reliability
mpls rsvp-te reliability Optional
mechanism of RSVP-TE
mpls rsvp-te timer retransmission Optional

Enable retransmission { increment-value [ increment-value ] |
retransmit-value [ retrans-timer-value ] } * Disabled by default
Optional
Enable summary refresh mpls rsvp-te srefresh
Disabled by default
Configuring the RSVP Hello extension
Follow these steps to configure the RSVP hello extension:

Enable global RSVP hello Required

mpls rsvp-te hello
extension Disabled by default

number of consecutive hellos By default, the link is
mpls rsvp-te hello-lost times
that should be lost before the considered failed if three
link is considered failed. consecutive hellos are lost.
mpls rsvp-te timer hello Optional

Configure the hello interval
timevalue The default is 3 seconds.

Enable interface RSVP hello Required

mpls rsvp-te hello
RSVP hello extension detects the reachability of RSVP neighboring nodes. It is defined in RFC 3209.
Configuring RSVP-TE resource reservation confirmation
Follow these steps to configure RSVP-TE resource reservation confirmation:

1-25
Enable resource reservation Required

mpls rsvp-te resvconfirm
confirmation Disabled by default
z Reservation confirmation is initiated by the receiver, which sends the Resv message with an object
requesting reservation confirmation.
z Receiving the ResvConf message does not mean resource reservation is established. It only
indicates that resources are reserved on the farthest upstream node where the Resv message
arrived and the resources can be preempted.
Configuring RSVP authentication
RSVP adopts hop-by-hop authentication to prevent fake resource reservation requests from occupying
network resources.
It requires that the interfaces at the two ends of a link must share the same authentication key to
exchange RSVP messages.
Follow these steps to configure RSVP authentication:


mpls rsvp-te authentication
Enable RSVP authentication Required
{ cipher | plain } auth-key
FRR and RSVP authentication cannot run at the same time.
Configuring RSVP-TE GR
The RSVP-TE GR function depends on the extended hello capability of RSVP-TE. Be sure to enable
the extended hello capability of RSVP-TE before configuring RSVP-TE GR.
Follow these steps to configure RSVP-TE GR on each device to act as the GR restarter or a GR helper:
Enable global RSVP hello Required

mpls rsvp-te hello
1-26
Required
Enable MPLS RSVP-TE GR mpls rsvp-te graceful-restart
Disabled by default
mpls rsvp-te timer Optional
Set the RSVP-TE GR restart
graceful-restart restart
restart-time
mpls rsvp-te timer Optional
Set the RSVP-TE GR recovery
graceful-restart recovery
recovery-time

Enable RSVP hello extension Required

mpls rsvp-te hello
for the interface Disabled by default
Tuning CR-LSP Setup

A CR-LSP is established through the signaling protocol based on the path calculated by CSPF using
TEDB and constraints. MPLS TE can affect CSPF calculation in many ways to determine the path that a
CR-LSP can traverse.
The configuration tasks described in this section are about CSPF of MPLS TE. They must be used in
conjunction with CSPF and the dynamic signal protocol (CR-LDP or RSVP-TE). Before performing
them, be aware of each configuration objective and its impact on your system.
Tuning CR-LSP setup involves these tasks:

z Configuring the tie breaker in CSPF
z Configuring route pinning
z Configuring administrative group and affinity attribute
z Configuring CR-LSP reoptimization
Configuring the tie breaker in CSPF
CSPF only calculates the shortest path to the end of a tunnel. If multiple paths are present with the
same metric, only one of them is selected. Tie breakers include largest currently available bandwidth,
least currently available bandwidth, or random selection.
Follow these steps to configure CSPF tie-breaking method:

Configure the tie breaker used Optional
when multiple paths are mpls te tie-breaking
present in a CSPF calculation { least-fill | most-fill | random } The random keyword applies
on the current node by default.
1-27

view tunnel-number
Configure the tie breaker used Optional
when multiple paths are mpls te tie-breaking
present in a CSPF calculation { least-fill | most-fill | random } The random keyword applies
for the current tunnel by default.

configuration
For a tunnel, the tie breaker configured in MPLS TE tunnel interface view is preferred to the one
configured in MPLS view. If no tie breaker is configured in MPLS TE tunnel interface view, the one
configured in MPLS view applies.
Configuring route pinning
Route pinning cannot be used together with reoptimization or automatic bandwidth adjustment.
Follow these steps to configure route pinning:


view tunnel-number
Required
Enable route pinning mpls te route-pinning
Disabled by default
mpls te commit Required.
configuration
Configuring administrative group and affinity attribute
The affinity attribute of an MPLS TE tunnel identifies the properties of the links that the tunnel can use.
Together with the link administrative group, it decides which links the MPLS TE tunnel can use. This is
done by ANDing the 32-bit affinity attribute with the 32-bit link administrative group attribute. When
doing that, a 32-bit mask is used. The affinity bits corresponding to the 1s in the mask are do care bits
which must be considered while those corresponding to the 0s in the mask are dont care bits.
For a link to be used by a TE tunnel, at least one considered affinity bit and its corresponding
administrative group bit must be set to 1.
Suppose the affinity of an MPLS TE tunnel is 0xFFFFFFFF and the mask is 0x0000FFFF. For a link to
be used by the tunnel, the leftmost 16 bits of its administrative group attribute can be 0s or 1s, but at
least one of the rest bits must be 1.
The affinity of an MPLS TE tunnel is configured at the first node on the tunnel and then signaled to the
rest nodes through CR-LDP or RSVP-TE.
1-28
The associations between administrative groups and affinities may vary by vendor.
Follow these steps to configure the administrative group and affinity attribute:


Assign the link to a link mpls te link administrative Optional

administrative group group value The default is 0x00000000.

view tunnel-number
Optional
Configure the affinity attribute mpls te affinity property The default affinity attribute is
of the MPLS TE tunnel properties [ mask mask-value ] 0x00000000, and the default
mask is 0x00000000.
configuration
Configuring CR-LSP reoptimization
Dynamic CR-LSP optimization involves periodic calculation of paths that traffic trunks should traverse. If
a better route is found for an existing CR-LSP, a new CR-LSP will be established to replace the old one,
and services will be switched to the new CR-LSP.
Follow these steps to configure CR-LSP reoptimization:


view tunnel-number
Enable reoptimization for the mpls te reoptimization Required

MPLS TE tunnel [ frequency seconds ] Disabled by default
configuration
Exit to user view return
Perform reoptimization on all
MPLS TE tunnels with mpls te reoptimization Optional
reoptimization enabled
1-29
Tuning MPLS TE Tunnel Setup
This section only covers the configuration tasks for tuning MPLS TE tunnel setup.
The configurations described in this section need to be used together with the dynamic signaling
protocol CR-LDP or RSVP-TE.
Before performing them, be aware of each configuration objective and its impact on your system.
Configuration Procedures
Tuning MPLS TE tunnel setup involves these tasks:

z Configuring loop detection
z Configuring route and label recording
z Configuring tunnel setup retry
z Assigning priorities to a tunnel
Configuring loop detection
Follow these steps to configure loop detection:

interface tunnel
Enter MPLS TE tunnel interface view
tunnel-number
Enable the system to perform loop Required

mpls te loop-detection
detection when setting up a tunnel Disabled by default
Submit current tunnel configuration mpls te commit Required
Configuring route and label recording
Follow these steps to configure route and label recording:

Enter MPLS TE tunnel interface
interface tunnel tunnel-number
view
Record routes mpls te record-route Required
Enable the system
Use either of the
to record routes or
Record routes commands.
label bindings
when setting up and label mpls te record-route label Both route recording and
the tunnel bindings label binding recording
are disabled by default.
Submit current tunnel configuration mpls te commit Required
1-30
The mpls te record-route label command is not supported when the signaling protocol is CR-LDP.
Configuring tunnel setup retry
You may configure the system to attempt setting up a tunnel multiple times until it is established
successfully or until the number of attempts reaches the upper limit.
Follow these steps to configure tunnel setup retry:


view tunnel-number
Configure maximum number of Optional

mpls te retry times
tunnel setup retries The default is 5.
Configure the tunnel setup retry Optional

mpls te timer retry seconds
interval The default is 2 seconds.
configuration
Assigning priorities to a tunnel
Two priorities, setup priority and holding priority, are assigned to paths for MPLS TE to make
preemption decision. For a new path to preempt an existing path, the setup priority of the new path must
be greater than the holding priority of the existing path.
To avoid flapping caused by improper preemptions between CR-LSPs, the setup priority of a CR-LSP
should not be set higher than its holding priority.
Follow these steps to assign priorities to a tunnel:


view tunnel-number
Optional
mpls te priority setup-priority
Assign priorities to the tunnel The default setup and holding
[ hold-priority ]
priorities are 7.
configuration
1-31
Configuring Traffic Forwarding
Before configuring traffic forwarding, do the following:

z Configure MPLS TE tunnels
Configuration Procedures
Configuring traffic forwarding involves these tasks:

z Forwarding traffic along MPLS TE tunnels using static routes
z Forwarding traffic along MPLS TE tunnels using policy routing
z Forwarding traffic along MPLS TE tunnels through automatic route advertisement
Forwarding traffic along MPLS TE tunnels using static routes
Follow these steps to create static routes for routing traffic along an MPLS TE tunnel:

Create a static route
interface-type interface-number [ gateway-address ] |
for forwarding traffic
vpn-instance d-vpn-instance-name Required
along an MPLS TE
gateway-address } [ preference preference-value ]
tunnel
[ tag tag-value ] [ description description-text ]
The interface-type argument in the ip route-static command must be tunnel. In addition, the preference
value must be set.
For more information about static routing, refer to Static Routing Commands in the IP Routing Volume.
Forwarding traffic along MPLS TE tunnels using policy routing
Follow these steps to configure policy routing for forwarding traffic along an MPLS TE tunnel:
1-32
acl number acl-number Required

Create and enter the view of an
[ match-order { auto | The default ACL rule match
advanced IPv4 ACL
config } ] order is config.
rule [ rule-id ] { deny | permit }
protocol [ destination
{ dest-addr dest-wildcard | any }
| destination-port operator
port1 [ port2 ] | dscp dscp |
established | fragment |
icmp-type { icmp-type
icmp-code | icmp-message } |
Define an ACL rule logging | precedence Required
precedence | reflective |
source { sour-addr
sour-wildcard | any } |
source-port operator port1
[ port2 ] | time-range
time-name | tos tos |
vpn-instance
vpn-instance-name ] *
policy-based-route Required
Create a policy node and enter
policy-name { permit | deny } You may create multiple policy
policy-based-route view
node node-number nodes in one policy
Reference the ACL that target
if-match acl acl-number Required
traffic should match
Specify the output interface to apply output-interface tunnel
Required
be the tunnel interface number1 [ tunnel number2 ]
Enable policy
ip local policy-based-route
routing
policy-name
globally
Enable policy Required
routing interface interface-type
Enable policy Configure either command.
interface-number
routing for an
interface ip policy-based-route
policy-name
For more information about configuring policy routing, refer to ACL Commands in the Security Volume
and IP Unicast Policy Routing Commands in the IP Services Volume.
1-33
Forwarding traffic along MPLS TE tunnels through automatic route advertisement
Automatic route advertisement is available depending on your device.
Two approaches, IGP shortcut and forwarding adjacency, are available to automatic route
advertisement to advertise MPLS TE tunnel interface routes to IGPs, allowing traffic to be routed down
MPLS TE tunnels.
In either approach, TE tunnels are considered point-to-point links and TE tunnel interfaces can be set
as outgoing interfaces.
IGP shortcut and forwarding adjacency are different in that in the forwarding adjacency approach,
routes with TE tunnel interfaces as outgoing interfaces are advertised to neighboring devices but not in
the IGP shortcut approach. Therefore, TE tunnels are visible to other devices in the forwarding
adjacency approach but not in the IGP shortcut approach.
You may assign a metric, either absolute or relative, to TE tunnels for the purpose of path calculation in
either approach. If it is absolute, the metric is directly used for path calculation. If it is relative, the cost of
the corresponding IGP path must be added to the metric before it can be used for path calculation.
Note that you need to enable OSPF or IS-IS on the tunnel interface of the MPLS TE tunnel before
configuring automatic route advertisement.
1) Configure IGP shortcut
Follow these steps to configure IGP shortcut:


view tunnel-number
Required
MPLS TE tunnels are not
Configure the IGP to take the
considered in the enhanced SPF
MPLS TE tunnels in up state mpls te igp shortcut
calculation of IGP.
into account when performing [ isis | ospf ]
enhanced SPF calculation If no IGP type is specified, the
configuration applies to both OSPF
and ISIS by default.
Optional
mpls te igp metric
Assign a metric to the MPLS TE The metrics of TE tunnels equal the
{ absolute | relative }
tunnel metrics of their corresponding IGP
value
routes by default.
configuration
Enable the IGP shortcut enable Required

function traffic-adjustment Disabled by default
1-34
2) Configure forwarding adjacency
You need to create a bi-directional MPLS TE tunnel and enable forwarding adjacency at both ends of
the tunnel to make forwarding adjacency take effect.
Follow these steps to configure forwarding adjacency:


view tunnel-number
Required
Enable IGP to advertise the
mpls te igp advertise Routes of MPLS TE tunnels are
route of the MPLS TE tunnel to
[ hold-time value ] not advertised to IGP neighbors
IGP neighbors.
by default.
Optional
Assign a metric to the MPLS TE mpls te igp metric { absolute | The metrics of TE tunnels equal
tunnel relative } value the metrics of their
corresponding IGP routes by
default.
configuration
enable traffic-adjustment Required

Enable forwarding adjacency
advertise Disabled by default
Configuring Traffic Forwarding Tuning Parameters

In MPLS TE, you may configure traffic forwarding tuning parameters such as the failed link timer and
flooding thresholds to change paths that IP or MPLS traffic flows traverse or to define type of traffic that
may travel down a TE tunnel.
The configurations described in this section are used in conjunction with CSPF and the dynamic
signaling protocol CR-LDP or RSVP-TE.
Configuring traffic forwarding tuning parameters involves these tasks:

z Configuring the failed link timer
z Configuring flooding thresholds
z Configuring the link metric used for routing a tunnel
z Configuring the traffic flow type of a tunnel
1-35
Configuring the failed link timer
A CSPF failed link timer starts once a link goes down. If IGP removes or modifies the link before the
timer expires, CSPF will update information about the link in TEDB and stops the timer. If IGP does not
remove or modify the link before the timer expires, the state of the link in TEDB will change to up.
Follow these steps to configure failed link timer:

Configure the CSPF failed link mpls te cspf timer failed-link Optional
timer timer-interval The default is 10 seconds.
Configuring flooding thresholds
After bandwidths of links regulated by MPLS TE change, CSPF may need to recalculate paths. This
tends to be resource consuming as recalculation involves IGP flooding. To reduce recalculations and
flood only significant changes, you may configure the following two IGP flooding thresholds in
percentages:
z Up threshold. When the percentage of available-bandwidth increase to the maximum reservable
bandwidth exceeds the threshold, the change is flooded.
z Down threshold. When the percentage of available-bandwidth decrease to the maximum
reservable bandwidth exceeds the threshold, the change is flooded.
Follow these steps to configure flooding thresholds:

Enter MPLS TE tunnel interface interface interface-type

Configure the up/down mpls te bandwidth change Optional

thresholds for IGP to flood thresholds { down | up } Both up and down flooding
bandwidth changes percent thresholds are 10 by default.
configuration
Configuring the link metric used for routing a tunnel
For an MPLS TE link, you may assign it a TE metric. This TE metric or the IGP metric of the link is used
for routing MPLS TE tunnels, depending on which metric type is specified.
Follow these steps to configure the link metric used for routing a tunnel:

1-36
Configure the link metric type Optional

mpls te path metric-type { igp
used for routing TE tunnels TE metrics of links are used by
| te }
without metric type default.

view tunnel-number
Configure the link metric type mpls te path metric-type { igp Optional
used for routing the tunnel | te } TE metric is used by default.
mpls te commit Optional
configuration

Optional
Assign a TE metric to the link mpls te metric value If no TE metric is assigned to
the link, IGP metric is used as
the TE metric by default.
z The metric type configured in MPLS TE tunnel interface view takes priority over the one configured
in MPLS view.
z If you do not configure the mpls te path metric-type command in MPLS TE tunnel interface view,
the configuration in MPLS view takes effect.
Configuring the traffic flow type of a tunnel
Follow these steps to configure the traffic flow type of a tunnel:


view tunnel-number
mpls te vpn-binding { acl Optional

Configure the traffic flow type of
acl-number | vpn-instance Traffic flow types of TE tunnels
the TE tunnel
vpn-instance-name } are not restricted by default.
configuration
1-37
Configuring Automatic Bandwidth Adjustment
The configurations described in this section are used in conjunction with CSPF and the dynamic
signaling protocol CR-LDP or RSVP-TE.
Follow these steps to configure automatic bandwidth adjustment:


Enable automatic bandwidth Required
adjustment, and configure
mpls te timer auto-bandwidth Automatic bandwidth
output rate sampling for
[ seconds ] adjustment is disabled by
automatically bandwidth tuned
TE tunnels default.

view tunnel-number
mpls te auto-bandwidth Required

adjustment [ frequency
Configure automatic bandwidth Automatic bandwidth
seconds ] [ max-bw
adjustment for the TE tunnel adjustment is disabled on TE
max-bandwidth | min-bw
min-bandwidth ]* tunnels by default.
mpls te auto-bandwidth
Configure the interval for collect-bw [ frequency Required
polling the output rate of the TE seconds ] [ max-bw Output rate polling is disabled
tunnel max-bandwidth | min-bw on TE tunnels by default.
min-bandwidth ]*
configuration
The sampling interval configured in MPLS view applies to all MPLS TE tunnels. The output rates of all
MPLS TE tunnels are recorded every sampling interval to calculate the actual average bandwidth of an
MPLS TE tunnel in one sampling interval.
Once the mpls te auto-bandwidth adjustment frequency command you configured in MPLS TE
tunnel interface view takes effect, an adjustment frequency timer starts. Upon expiration of this timer,
MPLS TE resizes the tunnel bandwidth using the maximum tunnel output rate sampled before the
expiration of the timer as the bandwidth constraint to set up a new LSP tunnel. If the setup attempt
succeeds, traffic will be switched to the new LSP tunnel and the old LSP tunnel will be cleared. If the
setup attempt fails, traffic travels the existing LSP tunnel.
1-38
Configuring CR-LSP Backup
CR-LSP backup provides end-to-end path protection to protect the entire LSP.
Before configuring CR-LSP backup, do the following:

z Configure MPLS TE tunnels
Follow these steps to configure CR-LSP backup:

Enter system view of the
system-view
ingress node

view tunnel-number
Required
Configure the backup mode mpls te backup { hot-standby
used by the TE tunnel | ordinary } Tunnel backup is disabled by
default.
configuration
CR-LSP backup should be configured at the ingress node of a tunnel. The system routes the primary
LSP and backup LSP automatically. You do not need to configure them.
Configuring FRR
The FRR feature is not supported when the signaling protocol is CR-LDP.
As mentioned earlier, Fast Reroute (FRR) provides quick but temporary per-link or per-node local
protection on an LSP.
FRR uses bypass tunnels to protect primary tunnels. As bypass tunnels are pre-established, they
require extra bandwidth and are usually used to protect crucial interfaces or links only.
You can define which type of LSP can use bypass LSPs, and whether a bypass LSP provides
bandwidth protection as well as the sum of protected bandwidth.
1-39
The bandwidth of a bypass LSP is to protect its primary LSPs. To guarantee that a primary LSP can
always bind with the bypass LSP successfully, make sure that the bandwidth assigned to the bypass
LSP is not less than the total bandwidth needed by all protected LSPs.
Normally, bypass tunnels only forward data traffic when protected primary tunnels fail. To allow a
bypass tunnel forward data traffic while protecting the primary tunnel, you need to ensure that bypass
tunnels are available with adequate bandwidth.
A bypass tunnel cannot be used for services like VPN at the same time.
Before configuring FRR, do the following:

z Configure IGP, ensuring that all LSRs are reachable
z Establish an MPLS TE tunnel with RSVP-TE
z Set up primary LSPs
Configuring FRR involves these tasks:

z Enabling FRR on the headend of a primary LSP
z Configuring a bypass tunnel on its PLR
z Configuring node protection
z Configuring the FRR polling timer
Enabling FRR on the headend of a primary LSP
Follow these steps to enable FRR on the headend of a primary LSP:

Enter tunnel interface view of interface tunnel

the primary LSP tunnel-number
Required
Enable FRR mpls te fast-reroute
Disabled by default
configuration
Configuring a bypass tunnel on its PLR
After a tunnel is specified to protect an interface, its corresponding LSP becomes a bypass LSP. Setting
up a bypass LSP must be manually performed on its headend, also called point of local repair (PLR),
which must be a part of the primary LSP but must not be the tail of the primary LSP.
Configuring a bypass LSP is the same as configuring a common LSP except that you cannot configure
the FRR attribute on a bypass LSP. In other words, an LSP cannot be both primary and bypass. In
addition, nested LSP protection is not allowed.
When specifying a bypass tunnel for an interface, make sure that:
z The bypass tunnel is up.
1-40
z The protected interface is not its own outgoing interface.
Up to three bypass tunnels can be specified for a protected interface. The best-fit algorithm is used to
determine which of them should be used in case failure occurs.
Your device has restriction on links that use the same bypass tunnel so that their total bandwidth does
not exceeds a specified value.
Follow these steps to configure a bypass tunnel on its PLR:

Enter interface view of the interface tunnel

bypass tunnel tunnel-number
Required
z For node protection, this is
Specify the destination address the LSR ID of the next hop
destination ip-address router of PLR.
of the bypass tunnel
z For link protection, this is the
LSR ID of the next hop
device of PLR.
Configure the bandwidth and mpls te backup bandwidth Required
type of LSP that the bypass { bandwidth | { bc0 | bc1 } Bandwidth is not protected by
tunnel can protect { bandwidth | un-limited } } default.
configuration
Enter interface view of the
outgoing interface of the
interface-number
protected LSP
mpls te fast-reroute
Bind the bypass tunnel with the
bypass-tunnel tunnel Required
protected interface
tunnel-number
Bypass tunnels do not protect bandwidth by default. This can defeat your attempts to binding a primary
LSP to a bypass tunnel. Therefore, when configuring a bypass tunnel, you must configure the
bandwidth that it is intended to protect with the mpls te backup bandwidth command.
Configuring node protection
To use FRR for node protection, you need to perform the tasks in this section on the PLR and the
protected node. If you only need to protect links, skip this section.
Follow these steps to configure node protection:

1-41

mpls rsvp-te hello
on current node Disabled by default
Enter the view of the interface
directly connected to the
interface-number
protected node or PLR

mpls rsvp-te hello
on the interface Disabled by default
RSVP hello extension is configured to detect node failures caused by problems such as signaling error
other than failures caused by link failures.
Configuring the FRR polling timer
The protection provided by FRR is temporary. Once a protected LSP becomes available again or a new
LSP is established, traffic will be switched to the protected or new LSP. After this switchover, the PLR
polls available bypass tunnels for the best one at the regular interval specified by the FRR polling timer:
Follow these steps to configure the FRR polling timer:

Enter system view of the PLR
system-view
node
Optional
mpls te timer fast-reroute
Configure the FRR polling timer The FRR polling timer is 300
[ second ]
seconds by default.
Displaying and Maintaining MPLS TE

Displaying and Maintaining MPLS TE

display explicit-path [ pathname ] Available in any view
explicit paths
display mpls static-cr-lsp [ lsp-name
Display information about static
lsp-name ] [ { include | exclude } Available in any view
CR-LSPs
ip-address prefix-length ] [ verbose ]
display mpls rsvp-te [ interface
[ interface-type interface-number ] [ |
Display RSVP-TE configuration Available in any view
regular-expression ] ]
1-42
display mpls rsvp-te established

Display global or interface [ interface interface-type
RSVP-TE information interface-number ] [ | { begin | exclude |
display mpls rsvp-te peer [ interface
interface-type interface-number ] [ |
Display RSVP-TE neighbors Available in any view
display mpls rsvp-te request

Display information about [ interface interface-type
RSVP requests interface-number ] [ | { begin | exclude |
display mpls rsvp-te reservation

RSVP resource reservation interface-number ] [ | { begin | exclude |
display mpls rsvp-te psb-content

Display information about { ingress-lsr-id lspid tunnel-id
RSVP-TE PSB egress-lsr-id } [ | { begin | exclude |
display mpls rsvp-te rsb-content
{ ingress-lsr-id Ispid tunnel-id
egress-lsr-id nexthop-address } [ | Available in any view
RSVP-TE RSB
display mpls rsvp-te sender
RSVP sender messages interface-number ] [ | { begin | exclude |
display mpls rsvp-te statistics

Display statistics about
{ global | interface [ interface-type Available in any view
RSVP-TE
interface-number ] }
display mpls te cspf tedb { all | area
Display criteria-compliant area-id | interface ip-address |
information about CSPF-based network-lsa | node [ mpls-lsr-id ] } [ | Available in any view
TEDB { begin | exclude | include }
Display information about the display mpls te link-administration
CR-LSPs carried on the admission-control [ interface Available in any view
specified or all links interface-type interface-number ]
Display bandwidths allocated to display mpls te link-administration
the specified or all MPLS bandwidth-allocation [ interface Available in any view
TE-enabled interfaces interface-type interface-number ]
display mpls te tunnel [ destination
dest-addr ] [ lsp-id lsr-id lsp-id ] [ lsr-role
{ all | egress | ingress | remote |
Display information bout MPLS transit } ] [ name name ]
TE tunnels [ { incoming-interface |
outgoing-interface | interface }
[ verbose ]
Display the path attributes of display mpls te tunnel path [ lsp-id
MPLS TE tunnels on this node lsr-id lsp-id | tunnel-name tunnel-name ]
1-43
Display tunnel statistics display mpls te tunnel statistics Available in any view
Display statistics about MPLS display mpls te tunnel-interface

TE tunnels tunnel number
Display the information of the
display ospf [ process-id ]
specified or all OSPF Available in any view
traffic-adjustment
processes about traffic tuning.
Display information about display ospf [ process-id ] mpls-te
OSPF TE [ area area-id ] [ self-originated ]
display isis traffic-eng

Display the latest TE advertisements [ level-1 | level-1-2 |
information advertised by IS-IS level-2 ] [ lsp-id lsp-id | local ] Available in any view
TE [ process-id | vpn-instance
vpn-instance-name ]
display isis traffic-eng link [ level-1 |
Display information about TE level-1-2 | level-2 ] [ verbose ]
links for IS-IS [ process-id | vpn-instance
vpn-instance-name ]
display isis traffic-eng network

Display information about TE [ level-1 | level-1-2 | level-2 ]
networks for IS-IS [ process-id | vpn-instance
vpn-instance-name ]
display isis traffic-eng statistics

Display statistics about TE for
IS-IS
vpn-instance-name ]
Display information about display isis traffic-eng sub-tlvs
sub-TLVs for the IS-IS TE [ process-id | vpn-instance Available in any view
extension vpn-instance-name ]
Display information about display tunnel-info { tunnel-id | all |
tunnels statistics }
reset mpls rsvp-te statistics { global |
Clear the statistics about
interface [ interface-type Available in user view
RSVP-TE
interface-number ]
Support for the display mpls te tunnel statistics command depends on the device model.
Resetting Automatic Bandwidth Adjustment
1-44
Reset automatic bandwidth reset mpls te auto-bandwidth
adjustment adjustment timers
When resetting the automatic bandwidth adjustment function, the system clears information about
output rate sampling and the remaining time for next bandwidth optimization.
MPLS TE Configuration Examples

MPLS TE Using Static CR-LSP Configuration Example (on Routers)
z Router A, Router B, and Router C run IS-IS.

z Establish a TE tunnel using a static CR-LSP between Router A and Router C.
Network diagram
Figure 1-6 Set up MPLS TE tunnels using static CR-LSPs (on routers)
Loop0
2.2.2.2/32
Eth1/0 Eth1/0
2.1.1.2/24 3.2.1.1/24
Router B
Eth1/0 Eth1/0
2.1.1.1/24 3.2.1.2/24
Router A Router C
Loop0 Loop0
1.1.1.1/32 3.3.3.3/32
1) Assign IP addresses and masks to interfaces (see Figure 1-6)

Omitted
2) Enable IS-IS to advertise host routes with LSR IDs as destinations
[RouterA] isis 1
[RouterA-isis-1] network-entity 00.0005.0000.0000.0001.00
[RouterA-LoopBack0] isis enable 1
1-45
[RouterB] isis 1
[RouterB-isis-1] network-entity 00.0005.0000.0000.0002.00
[RouterB-LoopBack0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] network-entity 00.0005.0000.0000.0003.00
[RouterC-LoopBack0] isis enable 1
[RouterC-LoopBack0] quit
Perform the display ip routing-table command on each router. You can see that all nodes learnt the
host routes of other nodes with LSR IDs as destinations. Take Router A for example:
1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/0
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.2/32 ISIS 15 10 2.1.1.2 Eth1/0
3.2.1.0/24 ISIS 15 20 2.1.1.2 Eth1/0
3.3.3.3/32 ISIS 15 20 2.1.1.2 Eth1/0
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
3) Configure MPLS TE basic capabilities
[RouterA] mpls
[RouterA-mpls] mpls te
[RouterA-mpls] quit
1-46
[RouterA-Ethernet1/0] mpls
[RouterA-Ethernet1/0] mpls te
[RouterB] mpls
[RouterB-mpls] mpls te
[RouterB-mpls] quit
[RouterB-Ethernet1/0] mpls
[RouterB-Ethernet1/0] mpls te
[RouterC] mpls
[RouterC-mpls] mpls te
[RouterC-mpls] quit
[RouterC-Ethernet1/1] mpls
[RouterC-Ethernet1/1] mpls te
4) Configure an MPLS TE tunnel
# Configure an MPLS TE tunnel on Router A.
[RouterA-Tunnel0] tunnel-protocol mpls te
[RouterA-Tunnel0] mpls te tunnel-id 10
[RouterA-Tunnel0] mpls te signal-protocol static
[RouterA-Tunnel0] mpls te commit
5) Create a static CR-LSP
# Configure Router A as the ingress node of the static CR-LSP.
[RouterA] static-cr-lsp ingress tunnel0 destination 3.3.3.3 nexthop 2.1.1.2 out-label 20
# Configure Router B as the transit node on the static CR-LSP.

[RouterB] static-cr-lsp transit tunnel0 incoming-interface ethernet 1/0 in-label 20 nexthop
3.2.1.2 out-label 30
# Configure Router C as the egress node of the static CR-LSP.

[RouterC] static-cr-lsp egress tunnel0 incoming-interface ethernet 1/1 in-label 30
1-47
Perform the display interface tunnel command on Router A. You can find that the tunnel interface is
up.
[RouterA] display interface tunnel
Encapsulation is TUNNEL, aggregation ID not set
Tunnel source unknown, destination 3.3.3.3
Tunnel protocol/transport CR_LSP
0 input error
0 output error
Perform the display mpls te tunnel command on each router to verify information about the MPLS TE
tunnel.
[RouterA] display mpls te tunnel
LSP-Id Destination In/Out-If Name
1.1.1.1:1 3.3.3.3 -/Eth1/0 Tunnel0
[RouterB] display mpls te tunnel
- - Eth1/0/Eth1/1 Tunnel0
[RouterC] display mpls te tunnel
- - Eth1/1/- Tunnel0
Perform the display mpls lsp command or the display mpls static-cr-lsp command on each router to
verify information about the static CR-LSP.
[RouterA] display mpls lsp
-------------------------------------------------------------------
LSP Information: STATIC CRLSP
-------------------------------------------------------------------
3.3.3.3/32 NULL/20 -/Eth1/0
[RouterB] display mpls lsp
------------------------------------------------------------------
------------------------------------------------------------------
-/- 20/30 Eth1/0/Eth1/1
[RouterC] display mpls lsp
------------------------------------------------------------------
------------------------------------------------------------------
1-48
-/- 30/NULL Eth1/0/-
[RouterA] display mpls static-cr-lsp
total statics-cr-lsp : 1
Name FEC I/O Label I/O If Stat
Tunnel0 3.3.3.3/32 NULL/20 -/Eth1/0 Up
[RouterB] display mpls static-cr-lsp
Tunnel0 -/- 20/30 Eth1/0/Eth1/1 Up
[RouterC] display mpls static-cr-lsp
Tunnel0 -/- 30/NULL Eth1/1/- Up
On an MPLS TE tunnel configured using a static CR-LSP, traffic is forwarded directly based on label at
the transit nodes and egress node. Therefore, it is normal that the FEC field in the sample output is
empty on Router B and Router C.
7) Create a static route for routing MPLS TE tunnel traffic.

[RouterA] ip route-static 3.2.1.2 24 tunnel 0 preference 1
Perform the display ip routing-table command on Router A. You can find a static route entry with
interface Tunnel 0 as the outgoing interface.
MPLS TE Using Static CR-LSP Configuration Example (on Switches)
z Switch A, Switch B, and Switch C run IS-IS.

z Establish a TE tunnel using a static CR-LSP between Switch A and Switch C.
Network diagram
Figure 1-7 Set up MPLS TE tunnels using static CR-LSPs (on switches)
Loop0
2.2.2.2/32
Vlan-int1 Vlan-int2
2.1.1.2/24 3.2.1.1/24
Switch B
Vlan-int1 Vlan-int2
2.1.1.1/24 3.2.1.2/24
Switch A Switch C
Loop0 Loop0
1.1.1.1/32 3.3.3.3/32
1-49

Omitted
[SwitchA] isis 1
[SwitchA-isis-1] network-entity 00.0005.0000.0000.0001.00
[SwitchA-LoopBack0] isis enable 1
[SwitchB] isis 1
[SwitchB-isis-1] network-entity 00.0005.0000.0000.0002.00
[SwitchB-LoopBack0] isis enable 1
[SwitchC] isis 1
[SwitchC-isis-1] network-entity 00.0005.0000.0000.0003.00
[SwitchC] interface loopback 0
[SwitchC-LoopBack0] isis enable 1
[SwitchC-LoopBack0] quit
Perform the display ip routing-table command on each switch. You can see that all nodes learnt the
host routes of other nodes with LSR IDs as destinations. Take Switch A for example:
1-50
1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Vlan1
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.2/32 ISIS 15 10 2.1.1.2 Vlan1
3.2.1.0/24 ISIS 15 20 2.1.1.2 Vlan1
3.3.3.3/32 ISIS 15 20 2.1.1.2 Vlan1
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
3) Configure MPLS TE basic capabilities
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] quit
[SwitchA-Vlan-interface1] mpls te
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] quit
[SwitchB-Vlan-interface1] mpls te
[SwitchC] mpls
[SwitchC-mpls] mpls te
[SwitchC-mpls] quit
[SwitchC-Vlan-interface2] mpls te
4) Configure an MPLS TE tunnel
# Configure an MPLS TE tunnel on Switch A.
[SwitchA-Tunnel0] tunnel-protocol mpls te
1-51
[SwitchA-Tunnel0] mpls te tunnel-id 10
[SwitchA-Tunnel0] mpls te signal-protocol static
[SwitchA-Tunnel0] mpls te commit
5) Create a static CR-LSP
# Configure Switch A as the ingress node of the static CR-LSP.
[SwitchA] static-cr-lsp ingress Tunnel0 destination 3.3.3.3 nexthop 2.1.1.2 out-label 20
# Configure Switch B as the transit node of the static CR-LSP.

[SwitchB] static-cr-lsp transit tunnel0 incoming-interface Vlan-interface1 in-label 20
nexthop 3.2.1.2 out-label 30
# Configure Switch C as the egress node of the static CR-LSP.

[SwitchC] static-cr-lsp egress tunnel0 incoming-interface Vlan-interface2 in-label 30
Perform the display interface tunnel command on Switch A. You can find that the tunnel interface is
up.
[SwitchA] display interface tunnel
0 input error
0 output error
Perform the display mpls te tunnel command on each switch to verify information about the MPLS TE
tunnel.
[SwitchA] display mpls te tunnel
1.1.1.1:1 3.3.3.3 -/Vlan1 Tunnel0
[SwitchB] display mpls te tunnel
- - Vlan1/Vlan2 Tunnel0
[SwitchC] display mpls te tunnel
- - Vlan2/- Tunnel0
Perform the display mpls lsp command or the display mpls static-cr-lsp command on each switch to
verify information about the static CR-LSP.
[SwitchA] display mpls lsp
1-52
-------------------------------------------------------------------
-------------------------------------------------------------------
3.3.3.3/32 NULL/20 -/Vlan1
[SwitchB] display mpls lsp
------------------------------------------------------------------
------------------------------------------------------------------
-/- 20/30 Vlan1/Vlan2
[SwitchC] display mpls lsp
------------------------------------------------------------------
------------------------------------------------------------------
-/- 30/NULL Vlan1/-
[SwitchA] display mpls static-cr-lsp
Tunnel0 3.3.3.3/32 NULL/20 -/Vlan1 Up
[SwitchB] display mpls static-cr-lsp
Tunnel0 -/- 20/30 Vlan1/Vlan2 Up
[SwitchC] display mpls static-cr-lsp
Tunnel0 -/- 30/NULL Vlan2/- Up
On an MPLS TE tunnel configured using a static CR-LSP, traffic is forwarded directly based on label at
the transit nodes and egress node. Therefore, it is normal that the FEC field in the sample output is
empty on Switch B and Switch C.
7) Create a static route for routing MPLS TE tunnel traffic.

[SwitchA] ip route-static 3.2.1.2 24 tunnel 0 preference 1
Perform the display ip routing-table command on Switch A. You can find a static route entry with
interface Tunnel 0 as the outgoing interface.
MPLS TE Tunnel Using RSVP-TE Configuration Example (on Routers)
Router A, Router B, Router C, and Router D are running IS-IS and all of them are Level-2 routers.
1-53
Use RSVP-TE to create a TE tunnel with 2000 kbps of bandwidth from Router A to Router D, ensuring
that the maximum bandwidth of each link that the tunnel traverses is 10000 kbps and the maximum
reservable bandwidth is 5000 kbps.
Network diagram
Figure 1-8 Set up MPLS TE tunnels using RSVP-TE (on routers)

Router A Loop0 1.1.1.9/32 Router C Loop0 3.3.3.9/32
Eth 1/0 10.1.1.1/24 Eth 1/0 30.1.1.1/24
Router B Loop0 2.2.2.9/32 POS 5/0 20.1.1.2/24
Eth 1/0 10.1.1.2/24 Router D Loop0 4.4.4.9/32
POS 5/1 20.1.1.1/24 Eth 1/0 30.1.1.2/24

Omitted
[RouterA] isis 1
[RouterA-isis-1] network-entity 00.0005.0000.0000.0001.00
[RouterA-Ethernet1/0] isis circuit-level level-2
[RouterA-LoopBack0] isis enable 1
[RouterA-LoopBack0] isis circuit-level level-2
[RouterB] isis 1
[RouterB-isis-1] network-entity 00.0005.0000.0000.0002.00
1-54
[RouterB-Ethernet1/0] isis circuit-level level-2
[RouterB-POS5/0] isis enable 1
[RouterB-POS5/0] isis circuit-level level-2
[RouterB-POS5/0] quit
[RouterB-LoopBack0] isis enable 1
[RouterB-LoopBack0] isis circuit-level level-2
[RouterC] isis 1
[RouterC-isis-1] network-entity 00.0005.0000.0000.0003.00
[RouterC-Ethernet1/0] isis circuit-level level-2
[RouterC-POS5/0] isis enable 1
[RouterC-POS5/0] isis circuit-level level-2
[RouterC-POS5/0] quit
[RouterC-LoopBack0] isis enable 1
[RouterC-LoopBack0] isis circuit-level level-2
[RouterC-LoopBack0] quit
[RouterD] isis 1
[RouterD-isis-1] network-entity 00.0005.0000.0000.0004.00
[RouterD-Ethernet1/0] isis circuit-level level-2
[RouterD] interface loopback 0
[RouterD-LoopBack0] isis enable 1
[RouterD-LoopBack0] isis circuit-level level-2
[RouterD-LoopBack0] quit
Perform the display ip routing-table command on each router. You can see that all nodes learnt the
host routes of other nodes with LSR IDs as destinations. Take Router A for example:
1-55
1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.9/32 ISIS 15 10 10.1.1.2 Eth1/0
3.3.3.9/32 ISIS 15 20 10.1.1.2 Eth1/0
4.4.4.9/32 ISIS 15 30 10.1.1.2 Eth1/0
10.1.1.0/24 Direct 0 0 10.1.1.1 Eth1/0
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 ISIS 15 20 10.1.1.2 Eth1/0
30.1.1.0/24 ISIS 15 30 10.1.1.2 Eth1/0
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
3) Configure MPLS TE basic capabilities, and enable RSVP-TE and CSPF
[RouterA] mpls
[RouterA-mpls] mpls te
[RouterA-mpls] mpls rsvp-te
[RouterA-mpls] mpls te cspf
[RouterA-mpls] quit
[RouterA-Ethernet1/0] mpls
[RouterA-Ethernet1/0] mpls te
[RouterA-Ethernet1/0] mpls rsvp-te
[RouterB] mpls
[RouterB-mpls] mpls te
[RouterB-mpls] mpls rsvp-te
[RouterB-mpls] mpls te cspf
[RouterB-mpls] quit
[RouterB-Ethernet1/0] mpls rsvp-te
[RouterB-POS5/0] mpls
[RouterB-POS5/0] mpls te
[RouterB-POS5/0] mpls rsvp-te
[RouterC] mpls
[RouterC-mpls] mpls te
[RouterC-mpls] mpls rsvp-te
1-56
[RouterC-mpls] mpls te cspf
[RouterC-mpls] quit
[RouterC-Ethernet1/0] mpls
[RouterC-Ethernet1/0] mpls te
[RouterC-Ethernet1/0] mpls rsvp-te
[RouterC-POS5/0] mpls
[RouterC-POS5/0] mpls te
[RouterC-POS5/0] mpls rsvp-te
[RouterD] mpls lsr-id 4.4.4.9
[RouterD] mpls
[RouterD-mpls] mpls te
[RouterD-mpls] mpls rsvp-te
[RouterD-mpls] mpls te cspf
[RouterD-mpls] quit
[RouterD-Ethernet1/0] mpls
[RouterD-Ethernet1/0] mpls te
[RouterD-Ethernet1/0] mpls rsvp-te
4) Configure IS-IS TE
[RouterA] isis 1
[RouterA-isis-1] cost-style wide
[RouterA-isis-1] traffic-eng level-2
[RouterB] isis 1
[RouterB-isis-1] cost-style wide
[RouterB-isis-1] traffic-eng level-2
[RouterC] isis 1
[RouterC-isis-1] cost-style wide
[RouterC-isis-1] traffic-eng level-2
[RouterD] isis 1
[RouterD-isis-1] cost-style wide
[RouterD-isis-1] traffic-eng level-2
1-57
5) Configure MPLS TE attributes of links
# Configure maximum link bandwidth and maximum reservable bandwidth on Router A.
[RouterA-Ethernet1/0] mpls te max-link-bandwidth 10000
[RouterA-Ethernet1/0] mpls te max-reservable-bandwidth 5000
# Configure maximum link bandwidth and maximum reservable bandwidth on Router B.

[RouterB-Ethernet1/0] mpls te max-link-bandwidth 10000
[RouterB-Ethernet1/0] mpls te max-reservable-bandwidth 5000
[RouterB-POS5/0] mpls te max-link-bandwidth 10000
[RouterB-POS5/0] mpls te max-reservable-bandwidth 5000
# Configure maximum link bandwidth and maximum reservable bandwidth on Router C.

[RouterC-Ethernet1/0] mpls te max-link-bandwidth 10000
[RouterC-Ethernet1/0] mpls te max-reservable-bandwidth 5000
[RouterC-POS5/0] mpls te max-link-bandwidth 10000
[RouterC-POS5/0] mpls te max-reservable-bandwidth 5000
# Configure maximum link bandwidth and maximum reservable bandwidth on Router D.

[RouterD-Ethernet1/0] mpls te max-link-bandwidth 10000
[RouterD-Ethernet1/0] mpls te max-reservable-bandwidth 5000
6) Create an MPLS TE tunnel
# Create an MPLS TE tunnel on Router A.
[RouterA-Tunnel1] tunnel-protocol mpls te
[RouterA-Tunnel1] mpls te tunnel-id 10
[RouterA-Tunnel1] mpls te signal-protocol rsvp-te
[RouterA-Tunnel1] mpls te bandwidth 2000
[RouterA-Tunnel1] mpls te commit
Perform the display interface tunnel command on Router A. You can find that the tunnel interface is
up.
[RouterA] display interface tunnel
1-58
0 input error
0 output error
Perform the display mpls te tunnel-interface command on Router A to verify information about the
MPLS TE tunnel.
[RouterA] display mpls te tunnel-interface
Tunnel Name : Tunnel1
Tunnel Desc : Tunnel1 Interface
Tunnel State Desc : CR-LSP is Up
Tunnel Attributes :
LSP ID : 1.1.1.9:3
Session ID : 10
Admin State : UP Oper State : UP
Ingress LSR ID : 1.1.1.9 Egress LSR ID: 4.4.4.9
Signaling Prot : RSVP Resv Style : SE
Class Type : CLASS 0 Tunnel BW : 2000 kbps
Reserved BW : 2000 kbps
Setup Priority : 7 Hold Priority: 7
Affinity Prop/Mask : 0x0/0x0
Explicit Path Name : -
Tie-Breaking Policy : None
Metric Type : None
Record Route : Disabled Record Label : Disabled
FRR Flag : Disabled BackUpBW Flag: Not Supported
BackUpBW Type : - BackUpBW : -
Route Pinning : Disabled
Retry Limit : 5 Retry Interval: 10 sec
Reopt : Disabled Reopt Freq : -
Back Up Type : None
Back Up LSPID : -
Auto BW : Disabled Auto BW Freq : -
Min BW : - Max BW : -
Current Collected BW: -
Interfaces Protected: -
VPN Bind Type : NONE
VPN Bind Value : -
Car Policy : Disabled
1-59
Tunnel Group : Primary
Primary Tunnel : -
Backup Tunnel : -
Group Status : -
Oam Status : Up
Perform the display mpls te cspf tedb all command on Router A to view information about links in
TEDB.
[RouterA] display mpls te cspf tedb all
Maximum Node Supported: 128 Maximum Link Supported: 256
Current Total Node Number: 4 Current Total Link Number: 6
Id MPLS LSR-Id IGP Process-Id Area Link-Count
1 3.3.3.9 ISIS 1 Level-2 2
2 2.2.2.9 ISIS 1 Level-2 2
3 4.4.4.9 ISIS 1 Level-2 1
4 1.1.1.9 ISIS 1 Level-2 1
8) Create a static route for routing MPLS TE tunnel traffic
[RouterA] ip route-static 30.1.1.2 24 tunnel 1 preference 1
Perform the display ip routing-table command on Router A. You can find a static route entry with
interface Tunnel1 as the outgoing interface.
MPLS TE Using RSVP-TE Configuration Example (on Switches)
Switch A, Switch B, Switch C, and Switch D are running IS-IS and all of them are Level-2 devices.
Use RSVP-TE to create a TE tunnel with 2000 kbps of bandwidth from Switch A to Switch D, ensuring
that the maximum bandwidth of each link that the tunnel traverses is 10000 kbps and the maximum
reservable bandwidth is 5000 kbps.
Network diagram
Figure 1-9 Set up MPLS TE tunnels using RSVP-TE (on switches)
Loop0 Loop0
Vlan-int1 Vlan-int3
Switch A Switch D
Loop0 Loop0
Vlan-int1 Vlan-int3
Vlan-int2
Vlan-int2
Switch B Switch C

Switch A Loop0 1.1.1.9/32 Switch D Loop0 4.4.4.9/32
Vlan-int1 10.1.1.1/24 Vlan-int3 30.1.1.2/24
Switch B Loop0 2.2.2.9/32 Switch C Loop0 3.3.3.9/32
Vlan-int1 10.1.1.2/24 Vlan-int3 30.1.1.1/24
Vlan-int2 20.1.1.1/24 Vlan-int2 20.1.1.2/24
1-60

Omitted
[SwitchA] isis 1
[SwitchA-isis-1] network-entity 00.0005.0000.0000.0001.00
[SwitchA-Vlan-interface1] isis circuit-level level-2
[SwitchA-LoopBack1] isis enable 1
[SwitchA-LoopBack1] isis circuit-level level-2
[SwitchB] isis 1
[SwitchB-isis-1] network-entity 00.0005.0000.0000.0002.00
[SwitchB-Vlan-interface1] isis circuit-level level-2
[SwitchB-Vlan-interface2] isis circuit-level level-2
[SwitchB-LoopBack0] isis enable 1
[SwitchB-LoopBack0] isis circuit-level level-2
[SwitchC] isis 1
[SwitchC-isis-1] network-entity 00.0005.0000.0000.0003.00
[SwitchC-Vlan-interface3] isis circuit-level level-2
1-61
[SwitchC-Vlan-interface2] isis circuit-level level-2
[SwitchC] interface loopback 0
[SwitchC-LoopBack0] isis enable 1
[SwitchC-LoopBack0] isis circuit-level level-2
[SwitchC-LoopBack0] quit
[SwitchD] isis 1
[SwitchD-isis-1] network-entity 00.0005.0000.0000.0004.00
[SwitchD-Vlan-interface3] isis circuit-level level-2
[SwitchD] interface loopback 0
[SwitchD-LoopBack0] isis enable 1
[SwitchD-LoopBack0] isis circuit-level level-2
[SwitchD-LoopBack0] quit
Perform the display ip routing-table command on each switch. You can see that all nodes learnt the
host routes of other nodes with LSR IDs as destinations. Take Switch A for example:
1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.9/32 ISIS 15 10 10.1.1.2 Vlan1
3.3.3.9/32 ISIS 15 20 10.1.1.2 Vlan1
4.4.4.9/32 ISIS 15 30 10.1.1.2 Vlan1
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan1
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 ISIS 15 20 10.1.1.2 Vlan1
30.1.1.0/24 ISIS 15 30 10.1.1.2 Vlan1
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
3) Configure MPLS TE basic capabilities, and enable RSVP-TE and CSPF.
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] mpls te cspf
[SwitchA-mpls] quit
[SwitchA-Vlan-interface1] mpls te
1-62
[SwitchA-Vlan-interface1] mpls rsvp-te
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] mpls rsvp-te
[SwitchB-mpls] mpls te cspf
[SwitchB-mpls] quit
[SwitchB-Vlan-interface1] mpls rsvp-te
[SwitchB-Vlan-interface2] mpls rsvp-te
[SwitchC] mpls
[SwitchC-mpls] mpls te
[SwitchC-mpls] mpls rsvp-te
[SwitchC-mpls] mpls te cspf
[SwitchC-mpls] quit
[SwitchC-Vlan-interface3] mpls rsvp-te
[SwitchC-Vlan-interface2] mpls rsvp-te
[SwitchD] mpls lsr-id 4.4.4.9
[SwitchD] mpls
[SwitchD-mpls] mpls te
[SwitchD-mpls] mpls rsvp-te
[SwitchD-mpls] mpls te cspf
[SwitchD-mpls] quit
[SwitchD-Vlan-interface3] mpls
[SwitchD-Vlan-interface3] mpls te
1-63
[SwitchD-Vlan-interface3] mpls rsvp-te
4) Configure IS-IS TE
[SwitchA] isis 1
[SwitchA-isis-1] cost-style wide
[SwitchA-isis-1] traffic-eng level-2
[SwitchB] isis 1
[SwitchB-isis-1] cost-style wide
[SwitchB-isis-1] traffic-eng level-2
[SwitchC] isis 1
[SwitchC-isis-1] cost-style wide
[SwitchC-isis-1] traffic-eng level-2
[SwitchD] isis 1
[SwitchD-isis-1] cost-style wide
[SwitchD-isis-1] traffic-eng level-2
5) Configure MPLS TE attributes of links
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch A.
[SwitchA-Vlan-interface1] mpls te max-link-bandwidth 10000
[SwitchA-Vlan-interface1] mpls te max-reservable-bandwidth 5000
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch B.

[SwitchB-Vlan-interface1] mpls te max-link-bandwidth 10000
[SwitchB-Vlan-interface1] mpls te max-reservable-bandwidth 5000
[SwitchB-Vlan-interface2] mpls te max-link-bandwidth 10000
[SwitchB-Vlan-interface2] mpls te max-reservable-bandwidth 5000
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch C.

[SwitchC-Vlan-interface3] mpls te max-link-bandwidth 10000
[SwitchC-Vlan-interface3] mpls te max-reservable-bandwidth 5000
1-64
[SwitchC-Vlan-interface2] mpls te max-link-bandwidth 10000
[SwitchC-Vlan-interface2] mpls te max-reservable-bandwidth 5000
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch D.

[SwitchD-Vlan-interface3] mpls te max-link-bandwidth 10000
[SwitchD-Vlan-interface3] mpls te max-reservable-bandwidth 5000
6) Create an MPLS TE tunnel
# Create an MPLS TE tunnel on Switch A.
[SwitchA-Tunnel1] tunnel-protocol mpls te
[SwitchA-Tunnel1] mpls te tunnel-id 10
[SwitchA-Tunnel1] mpls te signal-protocol rsvp-te
[SwitchA-Tunnel1] mpls te bandwidth 2000
[SwitchA-Tunnel1] mpls te commit
Perform the display interface tunnel command on Switch A. You can find that the tunnel interface is
up.
[SwitchA] display interface tunnel
0 input error
0 output error
Perform the display mpls te tunnel-interface command on Switch A to verify information about the
MPLS TE tunnel.
[SwitchA] display mpls te tunnel-interface
Tunnel Name : Tunnel1
Tunnel Desc : Tunnel1 Interface
Tunnel State Desc : CR-LSP is Up
Tunnel Attributes :
LSP ID : 1.1.1.9:3
Session ID : 10
1-65
Admin State : UP Oper State : UP
Ingress LSR ID : 1.1.1.9 Egress LSR ID: 4.4.4.9
Signaling Prot : RSVP Resv Style : SE
Class Type : CLASS 0 Tunnel BW : 2000 kbps
Reserved BW : 2000 kbps
Setup Priority : 7 Hold Priority: 7
Affinity Prop/Mask : 0x0/0x0
Explicit Path Name : -
Tie-Breaking Policy : None
Metric Type : None
Record Route : Disabled Record Label : Disabled
FRR Flag : Disabled BackUpBW Flag: Not Supported
BackUpBW Type : - BackUpBW : -
Route Pinning : Disabled
Retry Limit : 5 Retry Interval: 10 sec
Reopt : Disabled Reopt Freq : -
Back Up Type : None
Back Up LSPID : -
Auto BW : Disabled Auto BW Freq : -
Min BW : - Max BW : -
Current Collected BW: -
Interfaces Protected: -
VPN Bind Type : NONE
VPN Bind Value : -
Car Policy : Disabled
Tunnel Group : Primary
Primary Tunnel : -
Backup Tunnel : -
Group Status : -
Oam Status : Up
Perform the display mpls te cspf tedb all command on Switch A to view information about links in
TEDB.
[SwitchA] display mpls te cspf tedb all
Maximum Node Supported: 128 Maximum Link Supported: 256
Current Total Node Number: 4 Current Total Link Number: 6
Id MPLS LSR-Id IGP Process-Id Area Link-Count
1 3.3.3.9 ISIS 1 Level-2 2
2 2.2.2.9 ISIS 1 Level-2 2
3 4.4.4.9 ISIS 1 Level-2 1
4 1.1.1.9 ISIS 1 Level-2 1
8) Create a static route for routing MPLS TE tunnel traffic
[SwitchA] ip route-static 30.1.1.2 24 tunnel 1 preference 1
Perform the display ip routing-table command on Switch A. You can find a static route entry with
interface Tunnel1 as the outgoing interface.
1-66
RSVP-TE GR Configuration Example (on Routers)
z Router A, Router B and Router C are running IS-IS. All of them are Level-2 devices and support
RSVP hello extension.
z Use RSVP-TE to create a TE tunnel from Router A to Router C.
z Router A, Router B and Router C are RSVP-TE neighbors. With GR capability, each of them can
provide GR helper support when another is GR restarting.
Network diagram
Figure 1-10 Configure RSVP-TE GR (on routers)

Omitted
Omitted
3) Configure MPLS TE basic capabilities, and enable RSVP-TE and RSVP hello extension

20080928-3com MSR Series Routers Operation Manual-6W100 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

20080928-3com MSR Series Routers Operation Manual-6W100 PDF

Transféré par

Droits d'auteur :

Formats disponibles

3Com MSR Series Routers

Manual Version: 6W100

UNITED STATES GOVERNMENT LEGEND

End of Life Statement

Regulated Materials Statement

Environmental Statement about the Documentation

italic Command arguments are in italic.

Means a complementary description.

Means techniques helpful for you to make configuration with ease.

Functional Modules Index

MPLS&VPN MPLS Basics MPLS TE MPLS L2VPN MPLS L3VPN

Security NAT PKI PORTAL Rsh

IPX Volume IPX

Voice RADIUS Call Services

Table 1-2 Features in access volume

Operation and command

Introduction to WAN interfaces such as

Dynamic Route Backup

Table 1-3 Features in IP services volume

Operation and command

In a specific network, IP parameters need to be

UDP Helper functions to relay UDP broadcast

URPF Configuration Unicast reverse path finding, used to prevent the

sFlow Configuration Sampled Flow (sFlow) is a traffic monitoring

Table 1-4 Features in IP routing volume

Operation and command

IPv6 IPv6 OSPFv3 Configuration z Configuring OSPFv3 basic functions

IPv6 Static Routing Special routes that are manually configured by

Table 1-5 Features in IP multicast volume

Feature Operation and command manual Feature description

Table 1-6 Features in MPLS&VPN volume

Operation and command

Table 1-7 Features in QoS volume

Operation and command

Table 1-8 Features in security volume

Operation and command

Rsh Configuration Users can use the Rsh command to execute

z Configuring Many-to-many NAT

Table 1-9 Features in system volume

Operation and command

NTP Configuration z Configuring the operation modes of NTP

CPE WAN Management Protocol is a technology

Table 1-10 Features in IPX volume

Feature Operation and command manual Feature description

Table 1-11 Features in voice volume

Feature Operation and command manual Feature description

Table 1-12 Features in OAA volume

Feature Operation and command manual Feature description

Return to Functional Modules Index

Table 1-13 Features in WLAN volume

Feature Operation and command manual Feature description

WLAN WLAN Service Configuration z WLAN client connectivity to

General Layer 2 forwarding is

1 ATM and DSL Interface Configuration1-1

Interface MSR 20-1X MSR 20 MSR 30 MSR 50

ATM OC-3c/STM-1 No No Yes Yes

1 ATM and DSL Interface Configuration

ATM and DSL Interface

ATM interfaces available for the low-end and mid-range routers

The interfaces are available depending on your device model.

ATM interface features

The ATM interfaces support:

Configuring an IMA Group