3com Switch 4510G Family: Configuration Guide

3Com Switch 4510G Family
Configuration Guide
Switch 4510G 24-Port
Switch 4510G 48-Port
Product Version:
Release 2202
Manual Version:
6W100-20100112
www.3com.com
3Com Corporation
350 Campus Drive, Marlborough,
MA, USA 01752 3064
Downloaded from www.Manualslib.com manuals search engine

Copyright 2010, 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 Switch 4510G Family Configuration Guide is organized as follows:
Volume Features
00-Product
Product Overview Acronyms
Overview
Ethernet Port Link Aggregation Port Isolation MSTP
Isolate-User-VL
01-Access LLDP VLAN Voice VLAN
AN
Volume
BPDU
GVRP QinQ Port Mirroring
Tunneling
ARP Attack
IP Addressing ARP Proxy ARP
Defense
DHCP Relay
02-IP Services DHCP Overview DHCP Client DHCP Snooping
Agent
Volume
IP Performance
BOOTP Client DNS UDP Helper
Optimization
IPv6 Basics Dual Stack sFlow

IP Routing
03-IP Routing Static Routing RIP IPv6 Static Routing
Overview
Volume
RIPng Policy Routing
Mulitcast Overview IGMP Snooping Multicast VLAN MLD Snooping
04-Multicast
Volume IPv6 Multicast
VLAN
QoS Traffic Policing,
QoS Overview Configuration Priority Mapping Traffic Shaping,
Approaches and Line Rate
05-QoS Volume Congestion
Traffic Filtering Priority Marking Traffic Redirecting
Management
Class-Based
Traffic Mirroring User Profile Appendix
Accounting
EAD Fast
AAA 802.1X HABP
Deployment
MAC
06-Security Port Security IP Source Guard SSH2.0
Authentication
Volume
SFTP PKI SSL Public Key
ACL Application for

ACL Overview IPv4 ACL IPv6 ACL
Packet Filtering
07-High Smart Link Monitor Link RRPP DLDP

Availability Connectivity
Volume Ethernet OAM Track
Fault Detection

Volume Features
Logging In Logging In User Interface
Logging In to an
Through the Through Configuration
Ethernet Switch
Console Port Telnet/SSH Examples
Logging in Through
Web-based Specifying
Logging In Controlling Login
Network Source for
Through NMS Users
Management Telnet Packets
System
Basic System Device File System
FTP
Configuration Management Management
08-System TFTP HTTP HTTPS SNMP
Volume
MAC Address
MAC Information
MIB Style RMON Table
Configuration
Management
System
Information
Maintaining and Hotfix NQA
Center
Debugging
Cluster
NTP IRF IPC
Management
Automatic
Configuration
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
<> Button names are inside angle brackets. For example, click <OK>.
Window names, menu items, data table and field names are inside
[]
square brackets. For example, pop up the [New User] window.
Multi-level menus are separated by forward slashes. 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 a complementary description.
Related Documentation
In addition to this manual, each 3com Switch 4510G documentation set includes the following:
Manual Description
3Com Switch 4510G Family Command Provide detailed descriptions of command line interface
Reference Guide (CLI) commands, that you require to manage your switch.
3Com Switch 4510G Family Getting This guide provides all the information you need to install
Started Guide and use the 3Com Switch 4510G Family.
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.

1 Product Features
Introduction to Product
The 3Com Switches 4510G are Gigabit Ethernet switching products and have abundant service
features. They are designed as distribution and access devices for intranets and metropolitan area
networks (MANs). They can also be used for connecting server groups in data centers.
The 3Com Switches 4510G support the innovative Intelligent Resilient Framework (IRF) technology.
With IRF, multiple 4510G switches can be interconnected as a logical entity to form a new intelligent
network featuring high availability, scalability, and manageability.
Feature Lists
The Switch 4510G supports abundant features and the related documents are divided into the volumes
as listed in Table 1-1.
Table 1-1 Feature list
Volume Features
00-Product
Product Overview Acronyms
Overview
Ethernet Port Link Aggregation Port Isolation MSTP
Isolate-User-VL
01-Access LLDP VLAN Voice VLAN
AN
Volume
BPDU
GVRP QinQ Port Mirroring
Tunneling
ARP Attack
IP Addressing ARP Proxy ARP
Defense
DHCP Relay
02-IP Services DHCP DHCP Client DHCP Snooping
Agent
Volume
IP Performance
BOOTP Client DNS UDP Helper
Optimization
IPv6 Basics Dual Stack sFlow

IP Routing
03-IP Routing Static Routing RIP IPv6 Static Routing
Overview
Volume
RIPng Policy Routing
Mulitcast Overview IGMP Snooping Multicast VLAN MLD Snooping
04-Multicast
Volume IPv6 Multicast
VLAN
1-1

Volume Features
QoS Traffic Policing,
QoS Overview Configuration Priority Mapping Traffic Shaping,
Approaches and Line Rate
05-QoS Volume Congestion
Traffic Filtering Priority Marking Traffic Redirecting
Management
Class-Based
Traffic Mirroring User Profile Appendix
Accounting
EAD Fast
AAA 802.1X HABP
Deployment
MAC
06-Security Port Security IP Source Guard SSH2.0
Authentication
Volume
SFTP PKI SSL Public Key
ACL Application for

ACL Overview IPv4 ACL IPv6 ACL
Packet Filtering
07-High Smart Link Monitor Link RRPP DLDP

Availability Connectivity
Volume Ethernet OAM Track
Fault Detection
Logging In Logging In User Interface
Logging In to an
Through the Through Configuration
Ethernet Switch
Console Port Telnet/SSH Examples
Logging in Through
Web-based Specifying
Logging In Controlling Login
Network Source for
Through NMS Users
Management Telnet Packets
System
Basic System Device File System
FTP
Configuration Management Management
08-System TFTP HTTP HTTPS SNMP
Volume
MAC Address
MAC Information
MIB Style RMON Table
Configuration
Management
System
Information
Maintaining and Hotfix NQA
Center
Debugging
Cluster
NTP IRF IPC
Management
Automatic
Configuration
1-2

2 Features
The following sections provide an overview of the main features of each module supported by the
Switch 4510G.
Access Volume
Table 2-1 Features in Access volume
Features Description
This document describes:
z Combo Port Configuration
z Basic Ethernet Interface Configuration
z Configuring Flow Control on an Ethernet Interface
z Configuring the Suppression Time of Physical-Link-State Change on
an Ethernet Interface
z Configuring Loopback Testing on an Ethernet Interface
z Configuring a Port Group
Ethernet Port
z Configuring an Auto-negotiation Transmission Rate
z Configuring Storm Suppression
z Setting the Interval for Collecting Ethernet Interface Statistics
z Enabling Forwarding of Jumbo Frames
z Enabling Loopback Detection on an Ethernet Interface
z Configuring the MDI Mode for an Ethernet Interface
z Testing the Cable on an Ethernet Interface
z Configuring the Storm Constrain Function on an Ethernet Interface
Link aggregation aggregates multiple physical Ethernet ports into one
logical link. This document describes:
z Basic Concepts of Link Aggregation
Link aggregation z Configuring a Static Aggregation Group
z Configuring a Dynamic Aggregation Group
z Configuring an Aggregate Interface
z Configuring a Load Sharing Mode for Load-Sharing Link Aggregation
Groups
The port isolation feature allows you to isolate different ports within the
same VLAN. This document describes:
Port Isolation
z Introduction to Port Isolation
z Configuring the Isolation Group
MSTP is used to eliminate loops in a LAN. It is compatible with STP and
RSTP. This document describes:
MSTP
z Introduction to MSTP
z Configuring MSTP
2-1

LLDP enables a device to maintain and manage its own and its immediate
neighbors device information, based on which the network management
system detects and determines the conditions of the communications
links. This document describes:
LLDP
z Introduction to LLDP
z Performing Basic LLDP Configuration
z Configuring CDP Compatibility
z Configuring LLDP Trapping
Using the VLAN technology, you can partition a LAN into multiple logical
LANs. This document describes:
z Introduction to VLAN
VLAN
z Types of VLAN
z Isolate-user-vlan configuration
z Introduction and Configuration of Voice VLAN
An isolate-user-VLAN adopts a two-tier VLAN structure. In this approach,
two types of VLANs, isolate-user-VLAN and secondary VLAN, are
Isolate-User-VLAN configured on the same device. This document describes:
Configuration z Overview
z Configuring Isolate-User-VLAN
z Displaying and Maintaining Isolate-User-VLAN
A voice VLAN is configured specially for voice traffic. After assigning the
ports connecting to voice devices to a voice VLAN, you can configure
quality of service (QoS) parameters for the voice traffic, thus improving
Voice VLAN transmission priority and ensuring voice quality. This document describes:
Configuration
z Overview
z Configuring a Voice VLAN
z Displaying and Maintaining Voice VLAN
GVRP is a GARP application. This document describes:
GVRP z GARP/GVRP overview

z GVRP configuration
z GARP Timers configuration
As defined in IEEE802.1Q, 12 bits are used to identify a VLAN ID, so a
device can support a maximum of 4094 VLANs. The QinQ feature
extends the VLAN space by allowing Ethernet frames to travel across the
service provider network with double VLAN tags. This document
QinQ describes:
z Introduction to QinQ
z Configuring basic QinQ
z Configuring Selective QinQ
z Configuring the TPID Value in VLAN Tags
BPDU tunneling enables transparently transmission of customer network
BPDU frames over the service provider network. This document
BPDU Tunneling describes:
z Introduction to BPDU Tunneling
z Configuring BPDU Tunneling
Port mirroring copies packets passing through a port to another port
connected with a monitoring device for packet analysis to help implement
network monitoring and troubleshooting. This document describes:
Port Mirroring
z Port Mirroring overview
z Local port mirroring configuration
z Remote port mirroring configuration
2-2

IP Services Volume
Table 2-2 Features in the IP Services volume
An IP address is a 32-bit address allocated to a network interface on a
device that is attached to the Internet. This document describes:
IP Address
z Introduction to IP addresses
z IP address configuration
Address Resolution Protocol (ARP) is used to resolve an IP address into a
data link layer address. This document describes:
z ARP Overview
ARP
z Configuring ARP
z Configuring Gratuitous ARP
z Proxy ARP and Local Proxy ARP configuration
If a host sends an ARP request for the MAC address of another host that
actually resides on another network , the device in between must be able
to respond to the request with the MAC address of the receiving interface
Proxy ARP to allow Layer 3 communication between the two hosts. This is achieved
by proxy ARP. This document describes:
z Proxy ARP Overview
z Configuring Proxy ARP
Currently, ARP attacks and viruses are threatening LAN security. The
device can provide multiple features to detect and prevent such attacks.
z Configuring ARP Source Suppression
z Configuring ARP Defense Against IP Packet Attacks
ARP Attack Defense
z Configuring ARP Active Acknowledgement
z Configuring Source MAC Address Based ARP Attack Detection
z Configuring ARP Packet Source MAC Address Consistency Check
z Configuring ARP Packet Rate Limit
z Configuring ARP Detection
DHCP is built on a client-server model, in which the client sends a
configuration request and then the server returns a reply to send
configuration parameters such as an IP address to the client. This
document describes:
DHCP Overview z Introduction to DHCP
z DHCP Address Allocation
z DHCP Message Format
z DHCP Options
z Protocols and Standards
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
DHCP Relay Agent centralized management and cost reduction. This document describes:
z Introduction to DHCP Relay Agent
z Configuring the DHCP Relay Agent
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
DHCP Client server. This document describes:
z Introduction to DHCP Client
z Enabling the DHCP Client on an Interface
2-3

As a DHCP security feature, DHCP snooping can ensure DHCP clients to
obtain IP addresses from authorized DHCP servers and record IP-to-MAC
mappings of DHCP clients.This document describes:
DHCP Snooping
z DHCP Snooping Overview
z Configuring DHCP Snooping Basic Functions
z Configuring DHCP Snooping to Support Option 82
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. This document describes:
BOOTP Client
z Introduction to BOOTP Client
z Configuring an Interface to Dynamically Obtain an IP Address Through
BOOTP
Used in the TCP/IP application, Domain Name System (DNS) is a
distributed database which provides the translation between domain name
DNS and the IP address. This document describes:
z Configuring the DNS Client
z Configuring the DNS Proxy
In some network environments, you need to adjust the IP parameters to
achieve best network performance. This document describes:
IP Performance z Enabling Reception and Forwarding of Directed Broadcasts to a
Optimization Directly Connected Network
z Configuring TCP Attributes
z Configuring ICMP to Send Error Packets
UDP Helper functions as a relay agent that converts UDP broadcast
packets into unicast packets and forwards them to a specified server. This
UDP Helper document describes:
z UDP Helper overview
z UDP Helper configuration
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). This document describes:
z IPv6 overview
z Basic IPv6 functions configuration
IPv6 Basics
z IPv6 NDP configuration
z PMTU discovery configuration
z IPv6 TCP properties configuration
z ICMPv6 packet sending configuration
z IPv6 DNS Client configuration
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. This document
Dual Stack describes:
z Dual stack overview
z Dual stack configuration
Based on packet sampling, Sampled Flow (sFlow) is a traffic monitoring
technology mainly used to collect and analyze traffic statistics. This
sFlow document describes:
z sFlow Overview
z sFlow Configuration
2-4

IP Routing Volume
Table 2-3 Features in the IP Routing volume
IP Routing Overview z Introduction to IP routing and routing table
z Routing protocol overview
A static route is manually configured by the administrator. The proper
configuration and usage of static routes can improve network
performance and ensure bandwidth for important network applications.
Static Routing This document describes:
z Static route configuration
z Detecting Reachability of the Static Routes Nexthop
Routing Information Protocol (RIP) is a simple Interior Gateway Protocol
(IGP), mainly used in small-sized networks. This document describes:
RIP z RIP basic functions configuration
z RIP advanced functions configuration
z RIP network optimization configuration
Static routes are special routes that are manually configured by network
administrators. Similar to IPv4 static routes, IPv6 static routes work well in
IPv6 Static Routing simple IPv6 network environments. This document describes:
z IPv6 static route configuration
RIP next generation (RIPng) is an extension of RIP-2 for IPv4. RIPng for
IPv6 is IPv6 RIPng. This document describes:
RIPng z Configuring RIPng Basic Functions
z Configuring RIPng Route Control
z Tuning and Optimizing the RIPng Network
Policy routing is to make forwarding decisions based on user-defined
policies. Different from the normal destination-based routing, policy
routing can make routing decisions based on the source address and
Policy Routing other criteria in addition to the destination IP address.
The Switch 4510G implements policy routing through QoS policies. For
details about traffic classification, traffic behavior and QoS policy
configuration commands, refer to QoS Commands in the QoS Volume.
Multicast Volume
Table 2-4 Features in Multicast volume
This document describes the main concepts in multicast:
z Introduction to Multicast
Multicast Overview z Multicast Models
z Multicast Architecture
z Multicast Packets Forwarding Mechanism
2-5

Running at the data link layer, IGMP Snooping is a multicast control
mechanism on the Layer 2 Ethernet switch and it is used for multicast
group management and control. This document describes:
IGMP Snooping z Configuring Basic Functions of IGMP Snooping
z Configuring IGMP Snooping Port Functions
z Configuring IGMP Snooping Querier
z Configuring IGMP Snooping Policy
Multicast VLAN Multicast VLAN configuration
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. This document describes:
MLD Snooping z Configuring Basic Functions of MLD Snooping
z Configuring MLD Snooping Port Functions
z Configuring MLD Snooping Querier
z Configuring MLD Snooping Policy
IPv6 Multicast VLAN IPv6 Multicast VLAN configuration
QoS Volume
Table 2-5 Features in the QoS ACL volume
For network traffic, the Quality of Service (QoS) involves bandwidth, delay,
and packet loss rate during traffic forwarding process. This document
describes:
QoS Overview
z Introduction to QoS
z Introduction to QoS Service Models
z QoS Techniques Overview
Two approaches are available for you to configure QoS: policy-based and
QoS Configuration non policy-based. This document describes:
Approaches z QoS Configuration Approach Overview
z Configuring a QoS Policy
The priorities of a packet determine its transmission priority. There are two
types of priority: priorities carried in packets and priorities locally assigned
for scheduling only.
Priority Mapping When a packet enters the device from a port, the device assigns a set of
QoS priority parameters to the packet based on a certain priority and
sometimes may modify its priority, according to certain rules depending on
device status. This process is called priority mapping.
Traffic Policing, Traffic z Traffic Policing, Traffic Shaping, and Line Rate Overview
Shaping, and Line z Configuring Traffic Policing
Rate z Configuring GTS
z Configuring the Line Rate
2-6

The key to congestion management is how to define a dispatching policy
for resources to decide the order of forwarding packets when congestion
occurs. This document describes:
Congestion
z Configuring SP Queuing
Management
z Configure WRR Queuing
z Configuring WFQ Queuing
z Configuring SP+WRR Queues
This document describes how to filter in or filter out a class of traffic by
Traffic Filtering
associating the class with a traffic filtering action.
This document describes how to marking the priority of the packets by
Priority Marking associating a class with a behavior configured with the priority marking
action
Traffic redirecting is the action of redirecting the packets matching the
Traffic Redirecting specific match criteria to a certain location for processing. This document
describes how to configure traffic redirecting.
Traffic mirroring is the action of copying the specified packets to the
Traffic Mirroring specified destination for packet analyzing and monitoring. This document
describes how to configure traffic mirroring.
Class-Based Class-based accounting collects statistics on a per-traffic class basis. This
Accounting document describes how to configure class-based accounting.
User profile provides a configuration template to save predefined
configurations. This document describes:
User Profile z Creating a User Profile
z Configuring a User Profile
z Enabling a User Profile
Appendix z Acronym
z Default Priority Mapping Tables
z Introduction to Packet Precedences
Security Volume
Table 2-6 Features in the Security volume
Authentication, Authorization and Accounting (AAA) provide a uniform
framework used for configuring these three security functions to
implement the network security management. This document describes:
AAA z Introduction to AAA, RADIUS and HWTACACS
z AAA configuration
z RADIUS configuration
z HWTACACS configuration
IEEE 802.1X (hereinafter simplified as 802.1X) is a port-based network
access control protocol that is used as the standard for LAN user access
authentication. This document describes:
802.1X
z 802.1X overview
z 802.1X configuration
z 802.1X Guest-VLAN configuration
2-7

In conjunction with 802.1X, EAD Fast Deployment can have an access
switch to force all attached devices to download and install the EAD client
EAD Fast Deployment before permitting them to access the network. This document describes:
z EAD Fast Deployment overview
z EAD Fast Deployment configuration
On an HABP-capable switch, HABP packets can bypass 802.1X
authentication and MAC authentication, allowing communication among
HABP switches in a cluster. This document describes:
z Introduction to HABP
z HABP configuration
MAC authentication provides a way for authenticating users based on
ports and MAC addresses; it requires no client software to be installed on
MAC Authentication the hosts. This document describes:
z RADIUS-Based MAC Authentication
z Local MAC Authentication
Port security is a MAC address-based security mechanism for network
access controlling. It is an extension to the existing 802.1X authentication
and MAC authentication. This document describes:
z Enabling Port Security
Port Security z Setting the Maximum Number of Secure MAC Addresses
z Setting the Port Security Mode
z Configuring Port Security Features
z Configuring Secure MAC Addresses
z Ignoring Authorization Information from the Server
By filtering packets on a per-port basis, IP source guard prevents illegal
packets from traveling through, thus improving the network security. This
IP Source Guard document describes:
z Configuring a Static Binding Entry
z Configuring Dynamic Binding Function
SSH ensures secure login to a remote device in a non-secure network
environment. By encryption and strong authentication, it protects the
device against attacks. This document describes:
SSH2.0
z Configuring Asymmetric Keys
z Configuring the Device as an SSH Server
z Configuring the Device as an SSH Client
SFTP uses the SSH connection to provide secure data transfer. This
document describes:
SFTP z SFTP Overview
z Configuring an SFTP Server
z Configuring an SFTP Client
The Public Key Infrastructure (PKI) is a hierarchical framework designed
for providing information security through public key technologies and
PKI
digital certificates and verifying the identities of the digital certificate
owners. This document describes PKI related configuration.
Secure Sockets Layer (SSL) is a security protocol providing secure
SSL connection service for TCP-based application layer protocols, this
document describes SSL related configuration.
Public Key
This document describes Public Key Configuration.
Configuration
2-8

ACLs are sets of rules (or sets of permit or deny statements) that decide
what packets can pass and what should be rejected based on matching
ACL Overview
criteria. This document provides the introduction of IPv4 ACL and IPv6
ACL.
z Creating a Time Range
IPv4 ACL z Configuring a Basic IPv4 ACL
z Configuring an Advanced IPv4 ACL
z Configuring an Ethernet Frame Header ACL
z Copying an IPv4 ACL
IPv6 ACL z Configuring a Basic IPv6 ACL
You can apply an ACL to the inbound or outbound direction of an
ethernet interface or VLAN interface to filter received or sent packets
such as Ethernet frames, IPv4 packets, and IPv6 packets. This document
ACL Application for describes:
Packet Filtering z Filtering Ethernet Frames
z Filtering IPv4 Packets
z Configuring Packet Filtering Statistics Function
High Availability Volume

Table 2-7 Features in the High Availability volume
Smart Link is a solution for active-standby link redundancy backup and
rapid transition in dual-uplink networking. This document describes:
Smart Link z Smart Link Overview
z Configuring a Smart Link Device
z Configuring an Associated Device
Monitor link is a port collaboration function used to enable a device to be
aware of the up/down state change of the ports on an indirectly connected
Monitor Link link. This document describes:
z Monitor Link Overview
z Configuring Monitor Link
2-9

RRPP is a link layer protocol designed for Ethernet rings. RRPP can
prevent broadcast storms caused by data loops when an Ethernet ring is
healthy, and rapidly restore the communication paths between the nodes
after a link is disconnected on the ring. This document describes:
z RRPP overview
z Creating an RRPP Domain
z Configuring Control VLANs
RRPP
z Configuring Protected VLANs
z Configuring RRPP Rings
z Configuring RRPP Ports
z Configuring RRPP Nodes
z Activating an RRPP Domain
z Configuring RRPP Timers
z Configuring an RRPP Ring Group
In the use of fibers, link errors, namely unidirectional links, are likely to
occur. DLDP is designed to detect such errors. This document describes:
z DLDP Introduction
z Enabling DLDP
z Setting DLDP Mode
DLDP
z Setting the Interval for Sending Advertisement Packets
z Setting the DelayDown Timer
z Setting the Port Shutdown Mode
z Configuring DLDP Authentication
z Resetting DLDP State
Ethernet OAM is a tool monitoring Layer-2 link status. It helps network
administrators manage their networks effectively. This document
describes:
Ethernet OAM z Ethernet OAM overview
z Configuring Basic Ethernet OAM Functions
z Configuring Link Monitoring
z Enabling OAM Loopback Testing
Connectivity fault detection is an end-to-end, per-VLAN link-layer OAM
mechanism for link connectivity detection, fault verification, and fault
location. This document describes:
Connectivity Fault z Connectivity Fault Detection Overview
Detection z Basic Configuration Tasks
z Configuring CC on MEPs
z Configuring LB on MEPs
z Configuring LT on MEPs
The track module is used to implement collaboration between different
modules through established collaboration objects. The detection
modules trigger the application modules to perform certain operations
through the track module. This document describes:
Track z Track Overview
z Configuring Collaboration Between the Track Module and the
Detection Modules
z Configuring Collaboration Between the Track Module and the
Application Modules
2-10

System Volume
Table 2-8 Features in the System volume
Switch supports two types of user interfaces. This document describes:
z Supported User Interfaces
Logging In to an
Ethernet Switch z Users and User Interfaces
z User Interface Number
z Common User Interface Configuration
To log in through the Console port is the most common way to log in to a
switch. It is also the prerequisite to configure other login methods. This
document describes:
Logging In Through the z Introduction
Console Port z Setting Up the Connection to the Console Port
z Console Port Login Configuration
z Configuring Command Authorization
z Configuring Command Accounting
You can telnet to a remote switch to manage and maintain the switch. To
achieve this, you need to configure both the switch and the Telnet
terminal properly. This document describes:
Logging In Through
z Introduction
Telnet/SSH
z Logging In Through SSH
z Configuring Command Authorization
z Configuring Command Accounting
User Interface z User Authentication Configuration Example
Configuration Examples z Command Authorization Configuration Example
z Command Accounting Configuration Example
An switch 4510G has a built-in Web server. You can log in to an switch
4510G through a Web browser and manage and maintain the switch
intuitively by interacting with the built-in Web server. This document
Logging in Through describes:
Web-based Network
z Introduction
Management System
z Web Server Configuration
z Displaying Web Users
z Configuration Example
You can also log in to a switch through an NMS (network management
station), and then configure and manage the switch through the agent
Logging In Through module on the switch. This document describes:
NMS
z Introduction
z Connection Establishment Using NMS
To improve security and make it easier to manage services, you can
specify source IP addresses/interfaces for Telnet clients. This document
describes:
Specifying Source for
Telnet Packets z Introduction
z Specifying Source IP address/Interface for Telnet Packets
z Displaying the source IP address/Interface Specified for Telnet
Packets
2-11

Multiple ways are available for controlling different types of login users.
z Introduction
Controlling Login Users
z Controlling Telnet Users
z Controlling Network Management Users by Source IP Addresses
z Controlling Web Users by Source IP Addresses
Basic system configuration involves the configuration of device name,
system clock, welcome message, user privilege levels and so on. This
Basic System document describes:
Configuration z Configuration display
z Basic configurations
z CLI features
Through the device management function, you can view the current
condition of your device and configure running parameters. This
document describes:
z Device management overview
z Configuring the Exception Handling Method
z Rebooting a device
Device Management
z Configuring the scheduled automatic execution function
z Upgrading Device Software
z Disabling Boot ROM Access
z Configuring a detection interval
z Clearing the 16-bit interface indexes not used in the current system
z Identifying and diagnosing pluggable transceivers
A major function of the file system is to manage storage devices, mainly
including creating the file system, creating, deleting, modifying and
File System renaming a file or a directory and opening a file. This document
Management describes:
z File system management
z Configuration File Management
The File Transfer Protocol (FTP) is an application layer protocol for
sharing files between server and client over a TCP/IP network. This
document describes:
FTP Configuration
z FTP Overview
z Configuring the FTP Client
z Configuring the FTP Server
The Trivial File Transfer Protocol (TFTP) provides functions similar to
those provided by FTP, but it is less complex than FTP in interactive
TFTP Configuration access interface and authentication. This document describes:
z TFTP Overview
z Configuring the TFTP Client
Hypertext Transfer Protocol (HTTP) is used for transferring web page
HTTP Configuration information across the Internet. This document describes the HTTP
configuration.
The Secure HTTP (HTTPS) refers to the HTTP protocol that supports the
HTTPS Configuration Security Socket Layer (SSL) protocol. This document describes the
HTTPS configuration.
2-12

Simple network management protocol (SNMP) offers a framework to
monitor network devices through TCP/IP protocol suite. This document
describes:
SNMP z SNMP overview
z Basic SNMP function configuration
z SNMP log configuration
z Trap configuration
3Com private MIB involves two styles, 3Com compatible MIB and 3Com
new MIB. To implement NMSs flexible management of the device, the
device allows you to configure MIB style, that is, you can switch between
MIB Style
the two styles of MIBs. However, you need to ensure that the MIB style of
the device is the same as that of the NMS. This document describes the
MIB style configuration.
RMON provides an efficient means of monitoring subnets and allows
SNMP to monitor remote network devices in a more proactive and
RMON effective way. This document describes:
z RMON overview
z RMON configuration
A switch maintains a MAC address table for fast forwarding packets. This
document describes:
z MAC address table overview
MAC Address Table
Management z Configuring MAC Address Entries
z Disabling MAC Address Learning on a VLAN
z Configuring MAC Address Aging Timer
z Configuring the MAC Learning Limit
To monitor a network, you need to monitor users joining and leaving the
MAC Information network. This document describes:
Configuration z Overview
z Configuring MAC Information
For the majority of protocols and features supported, the system provides
corresponding debugging information to help users diagnose errors. This
System Maintenance document describes:
and Debugging
z Maintenance and debugging overview
z Maintenance and debugging configuration
As the system information hub, Information Center classifies and
manages all types of system information. This document describes:
z Information Center Overview
z Setting to Output System Information to the Console
z Setting to Output System Information to a Monitor Terminal
Information Center z Setting to Output System Information to a Log Host
z Setting to Output System Information to the Trap Buffer
z Setting to Output System Information to the Log Buffer
z Setting to Output System Information to the SNMP Module
z Configuring Synchronous Information Output
z Disabling a Port from Generating Link Up/Down Logging Information
Hotfix is a fast, cost-effective method to fix software defects of the device
without interrupting the running services. This document describes:
z Hotfix Overview
Hotfix z One-Step Patch Installation
z Step-by-Step Patch Installation
z Step-by-Step Patch Uninstallation
z One-Step Patch Uninstallation
2-13

NQA analyzes network performance, services and service quality by
sending test packets to provide you with network performance and
service quality parameters. This document describes:
z NQA Overview
z Configuring the NQA Server
z Enabling the NQA Client
NQA z Creating an NQA Test Group
z Configuring an NQA Test Group
z Configuring the Collaboration Function
z Configuring Trap Delivery
z Configuring the NQA Statistics Function
z Configuring Optional Parameters Common to an NQA Test Group
z Scheduling an NQA Test Group
Network Time Protocol (NTP) is the TCP/IP that advertises the accurate
time throughout the network. This document describes:
z NTP overview
NTP z Configuring the Operation Modes of NTP
z Configuring Optional Parameters of NTP
z Configuring Access-Control Rights
z Configuring NTP Authentication
A cluster is a group of network devices. Cluster management is to
implement management of large numbers of distributed network devices.
z Cluster Management Overview
z Configuring the Management Device
Cluster Management
z Configuring the Member Devices
z Configuring Access Between the Management Device and Its
Member Devices
z Adding a Candidate Device to a Cluster
z Configuring Advanced Cluster Functions
Intelligent Resilient Framework (IRF) allows you to build an IRF, namely
a united device, by interconnecting multiple devices through IRF ports.
You can manage all the devices in the IRF by managing the united
device. This document describes:
IRF
z IRF Overview
z IRF Working Process
z Configuring IRF
z Logging In to an IRF
Inter-Process Communication (IPC) is a reliable communication
IPC mechanism among different nodes. This document introduces the
operation for Enabling IPC Performance Statistics.
Automatic configuration enables a device to automatically obtain and
execute the configuration file when it starts up without loading the
configuration file. This document describes:
Automatic Configuration
z Introduction to Automatic Configuration
z Typical Networking of Automatic Configuration
z How Automatic Configuration Works
2-14

Appendix A Acronyms
#ABCDEFGHIKLMNOPQRSTUVWXZ
Acronyms Full spelling
# Return
10GE Ten-GigabitEthernet
A Return
AAA Authentication, Authorization and Accounting
ABC Activity Based Costing
ABR Area Border Router
AC Alternating Current
ACK ACKnowledgement
ACL Access Control List
ADSL Asymmetric Digital Subscriber Line
AFI Address Family Identifier
ALG Application Layer Gateway

AM accounting management
ANSI American National Standard Institute
AP Access Point
ARP Address Resolution Protocol
AS Autonomous System
ASBR Autonomous System Border Router
ASCII American Standard Code for Information Interchange
ASE Application service element
ASIC Application Specific Integrated Circuit

ASM Any-Source Multicast
ASN Auxiliary Signal Network
AT Advanced Technology
AT Adjacency Table
ATM Asynchronous Transfer Mode
AUX Auxiliary (port)
B Return
BC Bearer Control
BDR Backup Designated Router

BFD Bidirectional Forwarding Detection
A-1

BGP Border Gateway Protocol
BIMS Branch Intelligent Management System
BOOTP Bootstrap Protocol
BPDU Bridge Protocol Data Unit

BRI Basic Rate Interface
BSR Bootstrap Router
BT BitTorrent
BT Burst Tolerance
C Return
CA Call Appearance
CA Certificate Authority
CAR Committed Access Rate
CBS Committed Burst Size

CBQ Class Based Queuing
CBR Constant Bit Rate
CBT Core-Based Tree
International Telephone and Telegraph Consultative
CCITT
Committee
CE Customer Edge
CFD Connectivity Fault Detection
CFM Configuration File Management
CHAP Challenge Handshake Authentication Protocol
CIDR Classless Inter-Domain Routing
CIR Committed Information Rate
CIST Common and Internal Spanning Tree
CLNP Connectionless Network Protocol
CPOS Channelized POS

CPU Central Processing Unit
CQ Custom Queuing
CRC Cyclic Redundancy Check
CR-LSP Constraint-based Routing LSP
CR-LDP Constraint-based Routing LDP
CSMA/CD Carrier Sense Multiple Access/Collision Detect
CSNP Complete SNP
CSPF Constraint Shortest Path First
CST Common Spanning Tree

CT Call Transfer
A-2

CV Connectivity Verification
D Return
DAR Deeper Application Recognition
DCE Data Circuit-terminal Equipment

DD Database Description
DDN Digital Data Network
DHCP Dynamic Host Configuration Protocol
DIS Designated IS
DLCI Data Link Connection Identifier
DLDP Device Link Detection Protocol
DNS Domain Name System
DoD Downstream on Demand
DoS Denial of Service

DR Designated Router
DSCP Differentiated Services Codepoint Priority
DSP Digital Signal Processor
DTE Data Terminal Equipment
DU Downstream Unsolicited
D-V Distance Vector Routing Algorithm
DVMRP Distance Vector Multicast Routing Protocol
DWDM Dense Wavelength Division Multiplexing
E Return
EACL Enhanced ACL
EAD Endpoint Admission Defense
EAP Extensible Authentication Protocol
EAPOL Extensible Authentication Protocol over LAN
EBGP External Border Gateway Protocol
EBS Excess Burst Size

EGP Exterior Gateway Protocol
ES End System
ES-IS End System-Intermediate System

F Return
FCoE Fabric Channel over Ethernet
FC Forwarding Class
FCS Frame Check Sequence
FDDI Fiber Distributed Data Interface
A-3

FDI Forward Defect Indication
FEC Forwarding Equivalence Class
FFD Fast Failure Detection
FG Forwarding Group
FIB Forwarding information base
FIFO First In First Out
FQDN Full Qualified Domain Name
FR Frame Relay
FRR Fast ReRoute
FRTT Fairness Round Trip Time
FT Functional Test
FTP File Transfer Protocol
G Return
GARP Generic Attribute Registration Protocol
GE Gigabit Ethernet
GR Graceful Restart
GRE Generic Routing Encapsulation
GTS Generic Traffic Shaping
GVRP GARP VLAN Registration Protocol
H Return
HA High Availability
HABP HW Authentication Bypass Protocol
HDLC High-level Data Link Control
HEC Header Error Control
HoPE Hiberarchy of PE
HoVPN Hiberarchy of VPN
HQoS Hierarchical Quality of Service
HSB Hot Standby

HTTP Hyper Text Transport Protocol
H-VPLS Hiberarchy of VPLS
HVRP Hierarchy VLAN Register Protocol

HUAWEI Terminal Access Controller Access Control
HWTACACS
System
I Return
IA Incoming Access
IANA Internet Assigned Number Authority

IBGP Internal BGP
A-4

IBM International Business Machines
ICMP Internet Control Message Protocol
ICMPv6 Internet Control Message Protocol for IPv6
ID IDentification/IDentity
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IGMP-Snooping Internet Group Management Protocol Snooping
IGP Interior Gateway Protocol
ILM Incoming Label Map
ILS Internet Locator Service
IN Intelligent Network
IP Internet Protocol
IPng IP Next Generation
IPSec IP Security
IPTN IP Phone Telephony Network
IPv6 Internet protocol version 6
IPX Internet Packet Exchange
IRF Intelligent Resilient Framework
IS Intermediate System
ISATAP Intra-Site Automatic Tunnel Addressing Protocol
ISDN Integrated Services Digital Network
Intermediate System-to-Intermediate System intra-domain
IS-IS
routing information exchange protocol
ISO International Organization for Standardization
ISP Internet service provider
ISSU In Service Software Upgrade

IST Internal Spanning Tree
International Telecommunication Union -
ITU-T
Telecommunication Standardization Sector
K Return
KB Kilobyte
KEK Key-encrypting key
L Return
L2TP Layer 2 Tunneling Protocol
L2VPN Layer 2 VPN
L3VPN Layer 3 VPN
A-5

LACP Link Aggregation Control Protocol
LACPDU Link Aggregation Control Protocol Data Unit
LAN Local Area Network
LCP Link Control Protocol

LDAP Lightweight Directory Access Protocol
LDP Label Distribution Protocol
LER Label Edge Router
LFIB Label Forwarding Information Base
LIB Label Information Base
LLC Link Layer Control
LLDP Link Layer Discovery Protocol
LOC Loss of continuity
LOG Call Logging

LR Line Rate
LRTT Loop Round Trip Time
LSA Link State Advertisement
LSAck Link State Acknowledgment
LSDB Link State Database
LSP Label Switch Path
LSPAGENT Label Switched Path AGENT
LSPDU Link State Protocol Data Unit
LSPM Label Switch Path Management
LSR Link State Request
LSR Label Switch Router
LSR-ID Label Switch Router Identity
LSU Link State Update
M Return
MAC Media Access Control
MAN Metropolitan Area Network
MaxBC Max Bandwidth Constraints
MBGP Multiprotocol Border Gateway Protocol

MD Multicast Domain
MDI Medium Dependent Interface
MDT Multicast Distribution Tree

MED multi-exit discrimination (MED)
MIB Management Information Base
A-6

MLD Multicast Listener Discovery Protocol
MLD-Snooping Multicast Listener Discovery Snooping
MMC Meet-Me Conference
MODEM MOdulator-DEModulator
MP Multilink PPP
MP-BGP Multiprotocol extensions for BGP-4
MPE Middle-level PE
MP-group Multilink Point to Point Protocol group
MPLS Multiprotocol Label Switching
MPLSFW Multi-protocol Label Switch Forward
MPM Multicast Port Management
MSC Mobile Switching Center
MSDP Multicast Source Discovery Protocol

MSOH Multiplex Section Overhead
MSTI Multi-Spanning Tree Instance
MSTP Multiple Spanning Tree Protocol
MT Multicast Tunnel
MTBF Mean Time Between Failure
MTI Multicast Tunnel Interface
MTU Maximum Transmission Unit
MVRF Multicast VPN Routing and Forwarding
N Return
NAPT Network Address Port Translation
NAS Network Access Server
NAT Net Address Translation
NBMA Non Broadcast Multi-Access
NBT NetBIOS over TCP/IP
NCP Network Control Protocol

ND Neighborhood discovery
NDA NetStream Data Analyzer
NDC Network Data Collector

NDP Neighbor Discovery Protocol
NetBIOS Network Basic Input/Output System
NHLFE Next Hop Label Forwarding Entry

NLPID Network Layer Protocol Identifier
NLRI Network Layer Reachable Information
A-7

NMS Network Management Station
NPDU Network Protocol Data Unit
NPE Network Provider Edge
NQA Network Quality Analyzer

NSAP Network Service Access Point
NSC NetStream Collector
N-SEL NSAP Selector
NSSA Not-So-Stubby Area
NTDP Neighbor Topology Discovery Protocol
NTP Network Time Protocol
O Return
OAM Operation Administration and Maintenance
OAMPDU OAM Protocol Data Units

OC-3 OC-3
OID Object Identifier
OL Optical Line
OSI Open Systems Interconnection
OSPF Open Shortest Path First
P Return
P2MP Point to MultiPoint
P2P Point To Point
PAP Password Authentication Protocol
PCB Printed Circuit Board
PCM Pulse Code Modulation
PD Powered Device
PDU Protocol Data Unit
PE Provider Edge
PHP Penultimate Hop Popping

PHY Physical layer
PIM Protocol Independent Multicast
PIM-DM Protocol Independent Multicast-Dense Mode

PIM-SM Protocol Independent Multicast-Sparse Mode
PIR Peak Information Rate
PKCS Public Key Cryptography Standards

PKI Public Key Infrastructure
PMTU Path MTU
A-8

PoE Power over Ethernet
POP Point Of Presence
POS Packet Over SDH
PPP Point-to-Point Protocol

PPTP Point to Point Tunneling Protocol
PPVPN Provider-provisioned Virtual Private Network
PQ Priority Queuing
PRC Primary Reference Clock
PRI Primary Rate Interface
PS Protection Switching
PSE Power Sourcing Equipment
PSNP Partial SNP
PVC Permanent Virtual Channel

PW Pseudo wires
Q Return
QACL QoS/ACL
QinQ 802.1Q in 802.1Q
QoS Quality of Service
QQIC Querier's Query Interval Code
QRV Querier's Robustness Variable
R Return
RA Registration Authority
RADIUS Remote Authentication Dial in User Service
RAM random-access memory
RD Routing Domain
RD Router Distinguisher
RED Random Early Detection
RFC Request For comments

RIP Routing Information Protocol
RIPng RIP next generation
RM Route management
RMON Remote Monitoring
ROM Read Only Memory
RP Rendezvous Point
RPC Remote Procedure Call
RPF Reverse Path Forwarding
A-9

RPR Resilient Packet Ring
RPT Rendezvous Point Tree
RRPP Rapid Ring Protection Protocol
RSB Reservation State Block

RSOH Regenerator Section Overhead
RSTP Rapid Spanning Tree Protocol
RSVP Resource ReserVation Protocol
RTCP Real-time Transport Control Protocol
RTE Route Table Entry
RTP Real-time Transport Protocol
RTP Real-time Transport Protocol
S Return
SA Source Active
SBM Subnetwork Bandwidth Management
SCFF Single Choke Fairness Frame
SD Signal Degrade
SDH Synchronous Digital Hierarchy
SETS Synchronous Equipment Timing Source
SF Sampling Frequency
SFM Source-Filtered Multicast
SFTP Secure FTP
Share-MDT Share-Multicast Distribution Tree
SIP Session Initiation Protocol
Site-of-Origin Site-of-Origin
SLA Service Level Agreement
SMB Standby Main Board
SMTP Simple Mail Transfer Protocol
SNAP Sub Network Access Point

SNMP Simple Network Management Protocol
SNP Sequence Number Packet
SNPA Subnetwork Points of Attachment

SOH Section Overhead
SONET Synchronous Optical NETwork
SOO Site-of-Origin
SP Strict Priority Queueing
SPE Superstratum PE/Sevice Provider-end PE
A-10

SPF Shortest Path First
SPT Shortest Path Tree
SSH Secure Shell
SSM Synchronization Status Marker

SSM Source-Specific Multicast
ST Shared Tree
STM-1 SDH Transport Module -1
STM-16 SDH Transport Module -16
STM-16c SDH Transport Module -16c
STM-4c SDH Transport Module -4c
STP Spanning Tree Protocol
SVC Signalling Virtual Connection
Switch-MDT Switch-Multicast Distribution Tree
T Return
TA Terminal Adapter
TACACS Terminal Access Controller Access Control System
TDM Time Division Multiplexing
TCP Transmission Control Protocol
TE Traffic Engineering
TEDB TE DataBase
TFTP Trivial File Transfer Protocol
TLS Transparent LAN Service
TLV Type-Length-Value
ToS Type of Service
TPID Tag Protocol Identifier
TRIP Trigger RIP
TS Traffic Shaping
TTL Time to Live

TTY True Type Terminal
U Return
UDP User Datagram Protocol
UPE Underlayer PE or User-end PE
URL Uniform Resource Locators
URPF Unicast Reverse Path Forwarding

USM User-Based Security Model
A-11

V Return
VBR Variable Bit Rate
VCI Virtual Channel Identifier
VE Virtual Ethernet
VFS Virtual File System
VLAN Virtual Local Area Network
VLL Virtual Leased Lines
VOD Video On Demand
VoIP Voice over IP
VOS Virtual Operate System
VPDN Virtual Private Dial-up Network
VPDN Virtual Private Data Network
VPI Virtual Path Identifier

VPLS Virtual Private Local Switch
VPN Virtual Private Network
VRID Virtual Router ID
VRRP Virtual Router Redundancy Protocol
VSI Virtual Switch Interface
VT Virtual Tributary
VTY Virtual Type Terminal
W Return
WAN Wide Area Network
WFQ Weighted Fair Queuing
WINS Windows Internet Naming Service
WLAN wireless local area network
WRED Weighted Random Early Detection
WRR Weighted Round Robin
WTR Wait-to-Restore
WWW World Wide Web
X Return
XGE Ten-GigabitEthernet
Z Return
ZBR Zone Border Router
A-12

Table of Contents
1 Ethernet Port Configuration 1-1

Ethernet Port Configuration 1-1
Combo Port Configuration1-1
Basic Ethernet Interface Configuration1-2
Configuring Flow Control on an Ethernet Interface 1-3
Configuring the Suppression Time of Physical-Link-State Change on an Ethernet Interface 1-3
Configuring Loopback Testing on an Ethernet Interface1-4
Configuring a Port Group1-4
Configuring an Auto-negotiation Transmission Rate1-5
Configuring Storm Suppression 1-6
Setting the Interval for Collecting Ethernet Interface Statistics 1-7
Enabling Forwarding of Jumbo Frames 1-7
Enabling Loopback Detection on an Ethernet Interface1-8
Configuring the MDI Mode for an Ethernet Interface 1-9
Testing the Cable on an Ethernet Interface1-10
Configuring the Storm Constrain Function on an Ethernet Interface 1-10
Displaying and Maintaining an Ethernet Interface 1-12
2 Link Aggregation Configuration 2-1

Overview 2-1
Basic Concepts of Link Aggregation 2-1
Link Aggregation Modes2-4
Load Sharing Mode of an Aggregation Group 2-5
Link Aggregation Configuration Task List 2-5
Configuring an Aggregation Group 2-6
Configuring a Static Aggregation Group2-6
Configuring a Dynamic Aggregation Group2-7
Configuring an Aggregate Interface 2-8
Configuring the Description of an Aggregate Interface 2-8
Enabling LinkUp/LinkDown Trap Generation for an Aggregate Interface 2-8
Shutting Down an Aggregate Interface 2-9
Configuring a Load Sharing Mode for Load-Sharing Link Aggregation Groups 2-9
Displaying and Maintaining Link Aggregation2-10
Link Aggregation Configuration Examples2-11
Layer 2 Static Aggregation Configuration Example 2-11
Layer 2 Dynamic Aggregation Configuration Example 2-12
Layer 2 Aggregation Load Sharing Mode Configuration Example2-13
3 Port Isolation Configuration 3-1

Introduction to Port Isolation 3-1
Configuring the Isolation Group 3-1
Assigning a Port to the Isolation Group3-1
Displaying and Maintaining Isolation Groups3-2
Port Isolation Configuration Example3-2

4 MSTP Configuration 4-1
Overview 4-1
Introduction to STP 4-1
Why STP 4-1
Protocol Packets of STP4-1
Basic Concepts in STP4-2
How STP works 4-3
Introduction to RSTP4-9
Introduction to MSTP 4-10
Why MSTP 4-10
Basic Concepts in MSTP4-11
How MSTP Works 4-14
Implementation of MSTP on Devices 4-15
Protocols and Standards 4-15
MSTP Configuration Task List 4-15
Configuring MSTP4-17
Configuring an MST Region 4-17
Configuring the Root Bridge or a Secondary Root Bridge 4-18
Configuring the Work Mode of an MSTP Device 4-19
Configuring the Priority of a Device4-19
Configuring the Maximum Hops of an MST Region4-20
Configuring the Network Diameter of a Switched Network 4-20
Configuring Timers of MSTP 4-21
Configuring the Timeout Factor4-22
Configuring the Maximum Port Rate 4-23
Configuring Ports as Edge Ports 4-23
Configuring Path Costs of Ports 4-24
Configuring Port Priority 4-26
Configuring the Link Type of Ports 4-27
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets4-27
Enabling the Output of Port State Transition Information4-28
Enabling the MSTP Feature 4-29
Performing mCheck4-29
Configuring Digest Snooping4-30
Configuring No Agreement Check4-32
Configuring Protection Functions 4-34
Enabling BPDU Dropping 4-37
Displaying and Maintaining MSTP 4-38
MSTP Configuration Example4-38
5 LLDP Configuration5-1
Overview 5-1
Background 5-1
Basic Concepts5-1
Operating Modes of LLDP5-5
How LLDP Works 5-6
LLDP Configuration Task List 5-6
Performing Basic LLDP Configuration 5-7
ii

Enabling LLDP5-7
Setting LLDP Operating Mode 5-7
Setting the LLDP Re-Initialization Delay 5-8
Enabling LLDP Polling5-8
Configuring the TLVs to Be Advertised 5-8
Configuring the Management Address and Its Encoding Format 5-9
Setting Other LLDP Parameters5-10
Setting an Encapsulation Format for LLDPDUs5-10
Configuring CDP Compatibility 5-11
Configuration Prerequisites 5-11
Configuring CDP Compatibility5-12
Configuring LLDP Trapping 5-12
Displaying and Maintaining LLDP 5-13
LLDP Configuration Examples5-13
Basic LLDP Configuration Example 5-13
CDP-Compatible LLDP Configuration Example5-16
6 VLAN Configuration 6-1

Introduction to VLAN 6-1
VLAN Overview 6-1
VLAN Fundamentals 6-2
Types of VLAN 6-3
Configuring Basic VLAN Settings 6-3
Configuring Basic Settings of a VLAN Interface 6-4
Port-Based VLAN Configuration 6-5
Introduction to Port-Based VLAN 6-5
Assigning an Access Port to a VLAN 6-6
Assigning a Trunk Port to a VLAN6-8
Assigning a Hybrid Port to a VLAN 6-9
MAC-Based VLAN Configuration6-10
Introduction to MAC-Based VLAN6-10
Configuring a MAC Address-Based VLAN 6-11
Protocol-Based VLAN Configuration6-12
Introduction to Protocol-Based VLAN6-12
Configuring a Protocol-Based VLAN 6-12
IP Subnet-Based VLAN Configuration 6-14
Introduction6-14
Configuring an IP Subnet-Based VLAN 6-14
Displaying and Maintaining VLAN6-15
VLAN Configuration Example 6-16
7 Isolate-User-VLAN Configuration 7-1

Overview 7-1
Configuring Isolate-User-VLAN7-1
Displaying and Maintaining Isolate-User-VLAN7-3
Isolate-User-VLAN Configuration Example7-3
8 Voice VLAN Configuration8-1

Overview 8-1
OUI Addresses 8-1
iii

Voice VLAN Assignment Modes 8-2
Security Mode and Normal Mode of Voice VLANs 8-3
Configuring a Voice VLAN 8-4
Setting a Port to Operate in Automatic Voice VLAN Assignment Mode 8-4
Setting a Port to Operate in Manual Voice VLAN Assignment Mode 8-5
Displaying and Maintaining Voice VLAN8-6
Voice VLAN Configuration Examples 8-6
Automatic Voice VLAN Mode Configuration Example 8-6
Manual Voice VLAN Assignment Mode Configuration Example8-8
9 GVRP Configuration 9-1

Introduction to GVRP 9-1
GARP9-1
GVRP9-4
GVRP Configuration Task List 9-4
Configuring GVRP Functions9-4
Configuring GARP Timers 9-5
Displaying and Maintaining GVRP9-6
GVRP Configuration Examples9-7
GVRP Configuration Example I9-7
GVRP Configuration Example II9-8
GVRP Configuration Example III9-9
10 QinQ Configuration 10-1

Introduction to QinQ 10-1
Background 10-1
QinQ Mechanism and Benefits10-1
QinQ Frame Structure 10-2
Implementations of QinQ10-3
Modifying the TPID in a VLAN Tag 10-3
QinQ Configuration Task List10-5
Configuring Basic QinQ 10-5
Enabling Basic QinQ 10-5
Configuring Selective QinQ10-5
Configuring Selective QinQ Based on Ports 10-6
Configuring Selective QinQ through QoS Policies 10-6
Configuring the TPID Value in VLAN Tags 10-7
QinQ Configuration Examples 10-8
Basic QinQ Configuration Example10-8
Selective QinQ Configuration Example (Port-Based Configuration)10-10
Selective QinQ Configuration Example (QoS Policy-Based Configuration)10-13
11 BPDU Tunneling Configuration11-1

Introduction to BPDU Tunneling 11-1
Background 11-1
BPDU Tunneling Implementation 11-2
Configuring BPDU Tunneling11-3
iv

Enabling BPDU Tunneling11-4
Configuring Destination Multicast MAC Address for BPDUs 11-5
BPDU Tunneling Configuration Examples 11-5
BPDU Tunneling for STP Configuration Example11-5
BPDU Tunneling for PVST Configuration Example 11-6
12 Port Mirroring Configuration 12-1

Introduction to Port Mirroring 12-1
Classification of Port Mirroring 12-1
Implementing Port Mirroring 12-1
Configuring Local Port Mirroring 12-3
Configuring Remote Port Mirroring 12-4
Configuring a Remote Source Mirroring Group (on the Source Device)12-4
Configuring a Remote Destination Mirroring Group (on the Destination Device) 12-6
Displaying and Maintaining Port Mirroring 12-7
Port Mirroring Configuration Examples 12-7
Local Port Mirroring Configuration Example 12-7
Remote Port Mirroring Configuration Example 12-8

1 Ethernet Port Configuration
Ethernet Port Configuration
GE and 10GE ports on the Switch 4510G Family are numbered in the following format: interface type
A/B/C.
z A: Number of a member device in an IRF. If no IRF is formed, this value is 1.
z B: Slot number on the device. A value of 0 represents the slot where the fixed ports of the device
are located; a value of 1 represents the slot where the ports of interface expansion card 1 are
located; a value of 2 represents the slot where the ports of interface expansion card 2 are located.
z C: Number of a port on a slot.
For more information about interface expansion card, see 3Com Switch 4510G Family Getting Started
Guide.
Combo Port Configuration
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.
Configuring Combo port state
Follow these steps to configure the state of a Combo port:
To do Use the command Remarks

Enter system view system-view
interface interface-type
Enter Ethernet interface view
interface-number
Optional
Enable a specified Combo port undo shutdown By default, of the two ports in a
Combo port, the one with a
smaller port ID is enabled.
1-1

In case of a 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.
Basic Ethernet Interface 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 Gigabit 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:

Enter Ethernet interface interface-type

interface view interface-number
Optional
Set the description By default, the description of an interface
description text is the interface name followed by the
string
interface string, GigabitEthernet1/0/1
Interface for example.
Optional
auto by default.
Set the duplex mode duplex { auto | full | half } The optical interface of an SFP port and
the electrical interface of an Ethernet port
whose port rate is configured as 1000
Mbps do not support the half keyword.
Optional
The optical interface of an SFP port does
Set the transmission
speed { 10 | 100 | 1000 | auto } not support the 10 or 100 keyword.
rate
By default, the port speed is in the
auto-negotiation mode.
1-2

Optional
By default, an Ethernet interface is in up
Shut down the
shutdown state.
Ethernet interface
To bring up an Ethernet interface, use
the undo shutdown command.
z 10GE ports can be displayed only when 10GE interface module expansion cards are available on
the device.
z 10GE ports do not support the duplex command or the speed command.
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:

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
1-3

Required
Configure the up/down
suppression time of link-delay delay-time By default, the physical-link-state
physical-link-state changes change suppression time is not
configured.
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:
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
loopback { external | Optional

Enable loopback testing
internal } Disabled by default.
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 a Port Group
The devices allow you to configure some functions on multiple interfaces at a time by assigning the
interfaces to a port group in addition to configuring them on a per-interface basis. This is helpful when
you have to configure a feature in the same way on multiple interfaces.
A port group is created manually and the settings you made on it apply to all group member interfaces.
Note that even though the settings are made on the port group, they are saved on an interface basis
rather than on a port group basis. Thus, you can only view the settings in the view of each interface
with the display current-configuration command or the display this command.
1-4

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
group-member interface-list Required
port 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. With auto-negotiation rate configured, you can enable
the Ethernet port to negotiate only part of the transmission rates within its capacity.
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 of GigabitEthernet 1/0/4, which provides access
to the external network for the server group, is 1000 Mbps too. If you do not specify an
auto-negotiation range, the transmission rate on GigabitEthernet 1/0/1, GigabitEthernet 1/0/2 and
GigabitEthernet 1/0/3 through negotiation with the servers is 1000 Mbps, which may cause congestion
on the egress port GigabitEthernet 1/0/4. To solve the problem, you can specify the auto-negotiation
transmission rate on GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3 to 100
Mbps.
Follow these steps to configure an auto-negotiation transmission rate:

Enter Ethernet port view
interface-number
Configure the auto-negotiation
speed auto [ 10 | 100 | 1000 ] * Optional
transmission rate range
1-5

z This function is available for auto-negotiation-capable Gigabit Layer-2 Ethernet electrical ports
only..
z If you repeatedly use the speed and the speed auto commands to configure the transmission
rate on a port, only the latest configuration takes effect.
Configuring Storm Suppression
You can use the following commands to suppress the broadcast, multicast, and unknown unicast traffic.
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.
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 storm suppression ratios for one or multiple Ethernet interfaces:

Enter Use either command.

Ethernet If configured in Ethernet interface
interface interface-number
interface view, this feature takes effect on the
view
view or port current port only; if configured in port
group view Enter port port-group manual group view, this feature takes effect on
group view port-group-name all ports in the port group.
Optional
Set the broadcast storm broadcast-suppression By default, all broadcast traffic is
suppression ratio { ratio | pps max-pps } 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 { ratio | pps max-pps } allowed to pass through an interface,
that is, multicast traffic is not
suppressed.
1-6

Optional
Set the unknown unicast unicast-suppression By default, all unknown unicast traffic
storm suppression ratio { ratio | pps max-pps } is allowed to pass through an
interface, that is, unknown unicast
traffic is not 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.
Setting the Interval for Collecting Ethernet Interface Statistics
Follow these steps to configure the interval for collecting interface statistics:


Configure the interval Optional

for collecting flow-interval interval The default interval for collecting
interface statistics interface statistics is 300 seconds.
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, the system does not drop all the jumbo frames.
Instead, it continues to process jumbo frames with a size greater than the standard Ethernet frame size
and yet within the specified parameter range.
In interface configuration mode (Ethernet interface view/port-group view), you can enable jumbo
frames that can pass through the Ethernet interface.
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.
Follow these steps to enable the forwarding of jumbo frames:

Enable the port-group manual Use any command.

forwarding of In port-group port-group-name By default, the device
jumbo view
jumboframe enable allows jumbo frames with
1-7

frames interface interface-type the length of 9,216 bytes
In Ethernet interface-number to pass through all Layer 2
interface view Ethernet interfaces.
jumboframe enable
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.
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
loopback-detection per-vlan Enabled only in the default
all the VLANs to which trunk or
enable VLAN(s) with trunk port or
hybrid ports belong
hybrid ports
1-8

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 MDI Mode for an Ethernet Interface
10-Gigabit Ethernet ports and optical interfaces of SFP ports do 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
z Normal mode
z Auto mode
An Ethernet interface is composed of eight pins. By default, each pin has its particular role. For
example, pin 1 and pin 2 are used for transmitting signals; pin 3 and pin 6 are used for receiving
signals. You can change the pin roles through setting the MDI mode. For an Ethernet interface in
normal mode, the pin roles are not changed. For an Ethernet interface in across mode, pin 1 and pin 2
are used for receiving signals; pin 3 and pin 6 are used for transmitting signals. To enable normal
communication, you should connect the local transmit pins to the remote receive pins. Therefore, you
should configure the MDI mode depending on the cable types.
z Normally, the auto mode is recommended. The other two modes are useful only when the device
cannot determine the cable type.
z When straight-through cables are used, the local MDI mode must be different from the remote
MDI mode.
z When crossover cables are used, the local MDI mode must be the same as the remote MDI mode,
or the MDI mode of at least one end must be set to auto.
Follow these steps to configure the MDI mode for an Ethernet interface:

interface-number
1-9

Optional
Configure the MDI mode for Defaults to auto. That is, the
mdi { across | auto | normal } Ethernet interface determines
the Ethernet interface
the physical pin roles (transmit
or receive) through negotiation.
Testing the Cable on an Ethernet Interface
z 10-Gigabit Ethernet ports and optical interfaces of SFP ports do not support this feature.
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
Configuring the Storm Constrain Function on an Ethernet Interface
The storm constrain function suppresses packet storms in an Ethernet. With this function enabled on
an interface, the system detects the 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) when the traffic detected exceeds the threshold.
Alternatively, you can configure the storm suppression function to control a specific type of traffic. As
the function and the storm constrain function are mutually exclusive, do not enable them at the same
time on an Ethernet interface. For example, with broadcast storm suppression ratio set on an Ethernet
interface, do not enable the storm constrain function for broadcast traffic on the interface. Refer to
Configuring Storm Suppression for information about the storm suppression function.
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.
1-10

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 traffic. 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 } { pps | kbps | Required
threshold and the upper ratio } 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.
1-11

z For network stability sake, configure the interval for generating traffic statistics to a value that is
not shorter than the default.
z The storm constrain function, after being enabled, requires a complete statistical period (specified
by the storm-constrain interval command) to collect traffic data, and analyzes the data in the next
period. Thus, it is normal that a period longer than one statistic period is waited for a control action
to happen if you enable the function while the packet storm is present. However, the action will be
taken within two periods.
z The storm constrain function is applicable to multicast packets, and broadcast packets; and you
can specify the upper and lower threshold for any of the three types of packets.
Displaying and Maintaining an Ethernet Interface

Display the current state of an display interface
interface and the related [ interface-type Available in any view
information [ interface-number ] ]
display brief interface
[ interface-type
Display the summary of an
[ interface-number ] ] [ | { begin Available in any view
interface
| exclude | include }
regular-expression ]
Display information about display packet-drop interface
discarded packets on an [ interface-type Available in any view
interface [ interface-number ] ]
Display summary information
display packet-drop
about discarded packets on all Available in any view
summary
interfaces
reset counters interface
Clear the statistics of an
[ interface-type Available in user view
interface
[ interface-number ] ]
reset packet-drop interface
Clear the statistics of discarded
[ interface-type Available in user view
packets on an interface
Display the Combo ports and
the corresponding display port combo Available in any view
optical/electrical ports
Display the information about a
display port-group manual
manual port group or all the Available in any view
[ all | name port-group-name ]
port groups
Display the information about
display loopback-detection Available in any view
the loopback function
display storm-constrain
Display the information about [ broadcast | multicast ]
Available in any view
storm constrain [ interface interface-type
interface-number ]
1-12

2 Link Aggregation Configuration
When configuring link aggregation, go to these sections for information you are interested in:
z Overview
z Link Aggregation Configuration Task List
z Configuring an Aggregation Group
z Configuring an Aggregate Interface
z Configuring a Load Sharing Mode for Load-Sharing Link Aggregation Groups
z Displaying and Maintaining Link Aggregation
z Link Aggregation Configuration Examples
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 numbered the same is created automatically depending on the type of the
aggregate interface:
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.
The current device only supports Layer 2 aggregation groups.
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:
2-1

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 the state of a member port is determined, refer to Static aggregation mode and Dynamic
aggregation mode.
IEEE 802.3ad LACP protocol
The IEEE 802.3ad Link Aggregation Control Protocol (LACP) enables the dynamic aggregation of
physical links and uses link aggregation control protocol data units (LACPDUs) for information
exchange between LACP-enabled devices. With the usage of expansion fields in LACPDUs, LACP
can deliver extended functions in addition to its basic functions.
1) Basic LACP functions
Basic LACP functions are achieved with the basic fields in LACPDUs, which cover information
including system LACP priority, system MAC address, port LACP priority, port number, and operational
key. With LACP enabled on a port, LACP sends the above information of the port to its peer via
LACPDUs. Upon receiving an LACPDU, the peer compares the received information with the
information received on other ports. This allows the two systems to reach an agreement on which link
aggregation member ports should be placed in the selected state.
2) Extended LACP functions
By using expansion fields in LACPDUs, you can expand the functions of LACP. For example, by
defining a new Type/Length/Value (TLV) data field among the expansion fields of the LACPDUs, you
can deliver the LACP multi-active detection (MAD) mechanism in an Intelligent Resilient Framework
(IRF).
z Switches of the Switch 4510G Family that support extended LACP functions can function as both
member devices and intermediate devices in LACP MAD implementation.
z For details about IRF, member devices, intermediate devices, and the LACP MAD mechanism,
see IRF in the System Volume.
Marker protocol
During a session, if member ports are added to or removed from a dynamic link aggregation group,,
service traffic will need to be redistributed among all the new member ports of the link aggregation
group. The Marker protocol can be employed to quickly redistribute service traffic within link
aggregation groups and ensure the orderly transmission of data frames. The process is as follows:
z The device stops transmitting service traffic and starts a timer during which no data frames will
be transmitted on the links.
z The local end uses the Marker protocol to send a Marker Protocol Data Unit (PDU).
2-2

z When a Marker Response Protocol Data Unit (PDU) is received from the peer or the timer
expires, the device starts to redistribute service traffic on all the new link aggregation member
ports in selected state.
Currently, the Switch 4510G Family support returning Marker Response PDUs only after dynamic link
aggregation member ports receive Marker PDUs.
Operational key
When aggregating ports, link aggregation control automatically assigns each port an operational key
based on the port attributes, including the configurations of the port rate, duplex mode and link state.
In a link aggregation group, all member ports in the selected state have the same operation key.
Class-two configurations
Class-two configurations are listed in Table 2-1. In an aggregation group, if the configurations of a
member port are different from the class-two configurations, that member port cannot be a selected
port.
Table 2-1 Class-two configurations
Type Considerations
Port isolation Whether a port has joined an isolation group
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
Permitted VLAN IDs, default VLAN, link type (trunk, hybrid, or access), IP
VLAN
subnet-based VLAN configuration, protocol-based VLAN configuration, tag mode
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
z Some configurations are called class-one configurations. Such configurations, for example, GVRP
and MSTP, can be configured on aggregate interfaces and member ports but are not considered
during operational key calculation.
z The change of a class-two configuration setting may affect the select state of link aggregation
member ports and thus the ongoing service. To prevent unconsidered change, a message
warning of the hazard will be displayed when you attempt to change a class-two setting, upon
which you can decide whether to continue your change operation.
2-3

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 aggregation mode
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 port attributes 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.
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 can 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.
Dynamic aggregation mode
LACP is enabled on member ports in a dynamic aggregation group.

In a dynamic 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 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:
2-4

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, that is, the port with smaller port number, is selected
as the reference port.
z If a port (in up state) is with the same port attributes and class-two configuration as the reference
port, and the peer port of the port is with the same port attributes and class-two configurations as
the peer port of 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 static and dynamic aggregation modes:

z In an aggregation group, the port to be a selected port must be the same as the reference port in
port attributes, and class-two configurations. To keep these configurations consistent, you should
configure the port manually.
z Because changing a port attribute or class-two configuration setting of a port may cause the select
state of the port and other member ports to change and thus affects services, you are
recommended to do that with caution.
Load Sharing Mode of an Aggregation Group
The link aggregation groups created on the Switch 4510G Family always operate in load sharing mode,
even when they contain only one member port.
Link Aggregation Configuration Task List

Complete the following tasks to configure link aggregation:
Task Remarks
Configuring an Configuring a Static Aggregation Group Required

Aggregation Group Configuring a Dynamic Aggregation Group Perform either of the tasks
Configuring an Configuring the Description of an Aggregate

Optional
Aggregate Interface Interface
2-5

Task Remarks
Enabling LinkUp/LinkDown Trap Generation
Optional
for an Aggregate Interface
Shutting Down an Aggregate Interface Optional
Configuring a Load Sharing Mode for Load-Sharing Link Aggregation

Optional
Groups
Configuring an Aggregation Group
z The following ports cannot be assigned to an aggregation group: Stack ports, RRPP-enabled
ports, MAC address authentication-enabled ports, port security-enabled ports, IP source
guard-enabled ports, and 802.1x-enabled ports.
z You are recommended not to assign reflector ports of port mirroring to an aggregation group. For
details about reflector ports, refer to Port Mirroring Configuration in the Access Volume.
Configuring a Static Aggregation Group
Follow these steps to configure a Layer 2 static aggregation group:
To do... Use the command... Remarks

Required
Create a Layer 2
aggregate interface and When you create a Layer 2
interface bridge-aggregation aggregate interface, a Layer 2
enter the Layer 2
interface-number static aggregation group
aggregate interface
view numbered the same is created
automatically.
Exit to system view quit
Enter Ethernet interface interface interface-type

view interface-number Required
Repeat the two steps to assign
Assign the Ethernet multiple Ethernet interfaces to
interface to the port link-aggregation group number the aggregation group.
aggregation group
2-6

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.
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 Aggregation Group
Follow these steps to configure a Layer 2 dynamic 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.
Required
Create a Layer 2
interface When you create a Layer 2 aggregate
aggregate interface and
bridge-aggregation interface, a Layer 2 static aggregation
enter the Layer 2
interface-number group numbered the same is created
aggregate interface view
automatically.
Configure the Required
aggregation group to link-aggregation mode
work in dynamic dynamic By default, an aggregation group
aggregation mode works in static aggregation mode.

Enter Layer 2 Ethernet interface interface-type
interface view interface-number Required
Repeat the two steps to assign
Assign the Ethernet multiple Ethernet interfaces to the
port link-aggregation group
interface to the aggregation group.
number
aggregation group
Optional
By default, the LACP priority of a port
is 32768.
Assign the port a LACP lacp port-priority
priority port-priority Changing the LACP priority of a port
may affect the selected/unselected
state of the ports in the dynamic
aggregation group.
2-7

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.
Configuring an Aggregate Interface

You can perform the following configurations for an aggregate interface:
z Configuring the Description of an Aggregate Interface
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 Layer 2 aggregate interface bridge-aggregation

Optional
Configure the description of By default, the description of an
description text interface is interface-name
the aggregate interface
Interface, such as
Bridge-Aggregation1 Interface.
Enabling LinkUp/LinkDown Trap Generation for an Aggregate Interface
To enable an aggregate interface to generate linkUp/linkDown trap messages when the state of the
interface changes, you should enable linkUp/linkDown trap generation on the aggregate interface.
Follow these steps to enable linkUp/linkDown trap generation for an aggregate interface:

Optional
snmp-agent trap enable
Enable the trap function By default, linkUp/linkDown
[ standard [ linkdown | linkup ]
globally trap generation is enabled
*]
globally and on all interfaces.
Enter aggregate interface interface bridge-aggregation

view interface-number
2-8

Enable linkUp/linkDown trap Optional
generation for the aggregate enable snmp trap updown
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. 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:


Required
Shut down the aggregate
shutdown By default, aggregate interfaces
interface
are up.
After shutting down an aggregate interface, you are recommended not to use the shutdown command
and then the undo shutdown command on the member interfaces of the corresponding link
aggregation group. Otherwise, the member interfaces may be brought up.
Configuring a Load Sharing Mode for Load-Sharing Link

Aggregation Groups
The hash algorithm is adopted to calculate load sharing for load-sharing link aggregation groups. Hash
keys used for calculation could be service port numbers, IP addresses, MAC addresses, incoming
ports, or any combinations of them. One hash key or a combination of multiple hash keys represents a
load sharing mode. You can change the load sharing mode of a link aggregation group for different
types of traffic as needed. For example, for Layer 3 traffic, you can use IP addresses as hash keys for
load sharing calculation.
You can configure a global load sharing mode for all link aggregation groups or a load sharing mode
specific to a link aggregation group as needed.
Configuring the global load sharing mode for link aggregation groups
Follow these steps to configure the global load sharing mode for link aggregation groups:

2-9

Optional
By default, the hash keys
for Layer 2 packets are
source/destination MAC
link-aggregation load-sharing mode addresses, and those for
Configure the global link { destination-ip | destination-mac | Layer-3 packets are
aggregation load sharing destination-port | ingress-port | source/destination IP
mode source-ip | source-mac | addresses.
source-port } * After you configure this
command, the load
sharing modes in all link
aggregation groups
change accordingly
Configuring a load sharing mode for a link aggregation group
Follow these steps to configure a load sharing mode specific to a link aggregation group:


Required
By default, the load
sharing mode of an
aggregation group is the
Configure the load link-aggregation load-sharing mode
global load sharing mode.
sharing mode for the { destination-ip | destination-mac |
aggregation group source-ip | source-mac } * After you configure this
command, the load
sharing modes in current
link aggregation group
change accordingly.
Displaying and Maintaining Link Aggregation

Display the local system ID display lacp system-id Available in any view
display link-aggregation
Display the global or
load-sharing mode [ interface
aggregation group-specific Available in any view
[ bridge-aggregation
load sharing mode
interface-number ] ]
Display link aggregation details member-port [ interface-type
of ports interface-number [ to interface-type
interface-number ] ]
Display the summary
information of all aggregation Available in any view
summary
groups
2-10

display link-aggregation verbose
Display detailed information of
[ bridge-aggregation Available in any view
aggregation groups
reset lacp statistics [ interface
Clear the LACP statistics of
interface-type interface-number [ to Available in user view
ports
interface-type interface-number ] ]
Clear the statistics of the
[ bridge-aggregation Available in user view
specified aggregate interfaces
Link Aggregation Configuration Examples

Layer 2 Static Aggregation Configuration Example
Network requirements
As shown in Figure 2-1, Device A and Device B are connected through their respective Ethernet ports
GigabitEthernet1/0/1 to GigabitEthernet1/0/3.
Aggregate the ports on each device to form a static link aggregation group, thus balancing outgoing
traffic across the member ports. In addition, perform load sharing based on source and destination
MAC addresses.
Figure 2-1 Network diagram for Layer 2 static aggregation
Configuration procedure
1) Configure Device A
# Configure the device to perform load sharing based on source and destination MAC addresses for
link aggregation groups.
<DeviceA> system-view
[DeviceA] link-aggregation load-sharing mode source-mac destination-mac
# Create Layer 2 aggregate interface Bridge-aggregation 1.

[DeviceA] interface bridge-aggregation 1
[DeviceA-Bridge-Aggregation1] quit
# Assign Layer 2 Ethernet interfaces GigabitEthernet1/0/1 through GigabitEthernet1/0/3 to aggregation

group 1.
[DeviceA] interface GigabitEthernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] port link-aggregation group 1
2-11

[DeviceA-GigabitEthernet1/0/1] quit
2) Configure Device B
Follow the same configuration procedure performed on Device A to configure Device B.
Layer 2 Dynamic Aggregation Configuration Example
As shown in Figure 2-2, Device A and Device B are connected through their respective Ethernet ports
GigabitEthernet1/0/1 to GigabitEthernet1/0/3.
Aggregate the ports on each device to form a dynamic link aggregation group, thus balancing outgoing
traffic across the member ports. In addition, perform load sharing based on source and destination
MAC addresses.
Figure 2-2 Network diagram for Layer 2 dynamic aggregation
# Configure the device to perform load sharing based on source and destination MAC addresses for
link aggregation groups.
[DeviceA] link-aggregation load-sharing mode source-mac destination-mac
# Create a Layer 2 aggregate interface Bridge-Aggregation 1 and configure the interface to work in
dynamic aggregation mode.
[DeviceA-Bridge-Aggregation1] link-aggregation mode dynamic
# Assign Layer 2 Ethernet interfaces GigabitEthernet 1/0/1 through GigabitEthernet 1/0/3 to

aggregation group 1.
[DeviceA- GigabitEthernet1/0/1] quit
2-12

Follow the same configuration procedure performed on Device A to configure Device B.
Layer 2 Aggregation Load Sharing Mode Configuration Example
As shown in Figure 2-3, Device A is connection to Device B by their Ethernet ports GigabitEthernet
1/0/1 through GigabitEthernet 1/0/4.
Configure the global load sharing mode and aggregation group-specific load sharing mode to enable
aggregation group 1 to use source MAC-based load sharing mode and aggregation group 2 to use
destination MAC-based load sharing mode.
Figure 2-3 Network diagram for Layer 2 aggregation load sharing mode configuration
GE1/0/1
GE1/0/4
GE1/0/2
GE1/0/3
GE1/0/1
GE1/0/2
GE1/0/3
GE1/0/4
# Configure the global link aggregation load sharing mode as the source MAC-based load sharing
mode.
[DeviceA] link-aggregation load-sharing mode source-mac
# Create Layer 2 aggregate interface Bridge-aggregation 1.

# Assign ports GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to aggregation group 1.

[DeviceA] interface gigabitethernet 1/0/1
# Create a Layer 2 aggregate interface Bridge-Aggregation 2 and configure the load sharing mode of
aggregation group 2 as the destination MAC-based load sharing mode.
2-13

[DeviceA-Bridge-Aggregation2] link-aggregation load-sharing mode destination-mac
# Assign ports GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 to aggregation group 2.

The configuration on Device B is similar to the configuration on Device A.
2-14

3 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
z Displaying and Maintaining Isolation Groups
z Port Isolation Configuration Example
Introduction to Port Isolation

Usually, Layer 2 traffic isolation is achieved by assigning ports to different VLANs. To save VLAN
resources, port isolation is introduced to isolate ports within a VLAN, allowing for great flexibility and
security.
Currently:
z Switch 4510G Family support only one isolation group that is created automatically by the system
as isolation group 1. You can neither remove the isolation group nor create other isolation groups
on such devices.
z There is no restriction on the number of ports assigned to an isolation group.
z Layer 2 traffic can be exchanged between a port inside an isolation group and a port outside the
isolation group, but not between ports inside the isolation group.
Configuring the Isolation Group

Assigning a Port to the Isolation Group
Follow these steps to add a port to the isolation group:

Enter Ethernet interface interface-type Required

interface view interface-number Use one of the commands.
Enter Layer-2 interface z In Ethernet interface view, the
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 Required
the isolation group as an port-isolate enable No ports are added to the isolation group
isolated port or ports by default.
3-1

Displaying and Maintaining Isolation Groups
Display the isolation group
display port-isolate group Available in any view
information
Port Isolation Configuration Example

z Users Host A, Host B, and Host C are connected to GigabitEthernet 1/0/1, GigabitEthernet 1/0/2,
and GigabitEthernet 1/0/3 of Device.
z Device is connected to the Internet through GigabitEthernet 1/0/4.
z GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, GigabitEthernet1/0/3 and GigabitEthernet1/0/4
belong to the same VLAN. It is desired that Host A, Host B, and Host C cannot communicate with
one another at Layer 2, but can access the Internet.
Figure 3-1 Networking diagram for port isolation configuration
# Add ports GigabitEthernet 1/0/1, GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 to the isolation
group.
<Device> system-view
[Device] interface GigabitEthernet 1/0/1
[Device-GigabitEthernet1/0/1] port-isolate enable
[Device-GigabitEthernet1/0/1] quit
# Display the information about the isolation group.

<Device> display port-isolate group
Port-isolate group information:
3-2

Uplink port support: NO
Group ID: 1
Group members:
GigabitEthernet1/0/1 GigabitEthernet1/0/2 GigabitEthernet1/0/3
3-3

4 MSTP Configuration
When configuring MSTP, go to these sections for information you are interested in:
z Overview
z Introduction to STP
z Introduction to RSTP
z Introduction to MSTP
z MSTP Configuration Task List
z Configuring MSTP
z Displaying and Maintaining MSTP
z MSTP Configuration Example
Overview
As a Layer 2 management protocol, the Spanning Tree Protocol (STP) eliminates Layer 2 loops by
selectively blocking redundant links in a network, and in the mean time, allows for link redundancy.
Like many other protocols, STP evolves as the network grows. The later versions of STP are the Rapid
Spanning Tree Protocol (RSTP) and the Multiple Spanning Tree Protocol (MSTP). This chapter
describes the characteristics of STP, RSTP, and MSTP and the relationship among them.
Introduction to STP
Why STP
STP was developed based on the 802.1d standard of IEEE to eliminate loops at the data link layer in a
local area network (LAN). Devices running this protocol detect loops in the network by exchanging
information with one another and eliminate loops by selectively blocking certain ports to prune the loop
structure into a loop-free tree structure. This avoids proliferation and infinite cycling of packets that
would occur in a loop network and prevents decreased performance of network devices caused by
duplicate packets received.
In the narrow sense, STP refers to IEEE 802.1d STP; in the broad sense, STP refers to the IEEE
802.1d STP and various enhanced spanning tree protocols derived from that protocol.
Protocol Packets of STP
STP uses bridge protocol data units (BPDUs), also known as configuration messages, as its protocol
packets.
STP-enabled network devices exchange BPDUs to establish a spanning tree. BPDUs contain
sufficient information for the network devices to complete spanning tree calculation.
In STP, BPDUs come in two types:
z Configuration BPDUs, used for calculating a spanning tree and maintaining the spanning tree
topology.
4-1

z Topology change notification (TCN) BPDUs, used for notifying the concerned devices of network
topology changes, if any.
Basic Concepts in STP
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.
Upon initialization of a network, each device generates and sends out BPDUs periodically with itself as
the root bridge; after network convergence, only the root bridge generates and sends out configuration
BPDUs at a certain interval, and the other devices just forward the BPDUs.
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.
Designated bridge and designated port
The following table describes designated bridges and designated ports.
Table 4-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
BPDUs to the local device to this device
The port through which the
The device responsible for forwarding
For a LAN designated bridge forwards BPDUs
BPDUs to this LAN segment
to this LAN segment
As shown in Figure 4-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.
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.
4-2

Figure 4-1 A schematic diagram of designated bridges and designated ports
All the ports on the root bridge are 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.
How STP works
The devices on a network exchange BPDUs to identify the network topology. Configuration BPDUs
contain sufficient information for the network devices to complete spanning tree calculation. Important
fields in a configuration BPDU include:
z Root bridge ID: consisting of the priority and MAC address of the root bridge.
z Root path cost: the cost of the path to the root bridge denoted by the root identifier from the
transmitting bridge.
z Designated bridge ID: consisting of the priority and MAC address of the designated bridge.
z Designated port ID: designated port priority plus port name.
z Message age: age of the configuration BPDU while it propagates in the network.
z Max age: maximum age of the configuration BPDU.
z Hello time: configuration BPDU transmission interval.
z Forward delay: the delay used by STP bridges to transit the state of the root and designated ports
to forwarding.
4-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 (related to the rate of the link connecting the port)
z Designated bridge ID (represented by device priority)
z Designated port ID (represented by port name)
Calculation process of the STP algorithm
z 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.
z Selection of the optimum configuration BPDU
Each device sends out its configuration BPDU and receives configuration BPDUs from other devices.
Table 4-2 describes the process of selecting the optimum configuration BPDU.
Table 4-2 Selection of the optimum configuration BPDU
Step Actions
Upon receiving a configuration BPDU on a port, the device performs the following:
z If the received configuration BPDU has a lower priority than that of the configuration
BPDU generated by the port, the device discards the received configuration BPDU
1 and does not process the configuration BPDU of this port.
z If the received configuration BPDU has a higher priority than that of the
configuration BPDU generated by the port, the device replaces the content of the
configuration BPDU generated by the port with the content of the received
configuration BPDU.
The device compares the configuration BPDUs of all the ports and chooses the
2
optimum configuration BPDU.
The following are the principles of configuration BPDU comparison:

z The configuration BPDU that has the lowest root bridge ID has the highest priority.
z If all the configuration BPDUs have the same root bridge ID, their root path costs are compared.
Assume that the root path cost in a configuration BPDU plus the path cost of a receiving port is S.
The configuration BPDU with the smallest S value has the highest priority.
z If all configuration BPDUs have the same ports value, their designated bridge IDs, designated port
IDs, and the IDs of the receiving ports are compared in sequence. The configuration BPDU
containing a smaller ID wins out.
z Selection of the root bridge
4-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.
z Selection of the root port and designated ports on a non-root device
Table 4-3 describes the process of selecting the root port and designated ports.
Table 4-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
3 the designated port, and replaces the configuration BPDU on the port with the
calculated configuration BPDU, which will be sent out periodically.
z If the configuration BPDU on the port is superior, the device blocks this port without
updating its configuration BPDU. The blocked port can receive BPDUs but not send
BPDUs or forward data.
When the network topology is stable, only the root port and designated ports forward traffic, while other
ports are all in the blocked state they receive BPDUs but do not forward BPDUs or user traffic.
A tree-shape topology forms upon successful election of the root bridge, the root port on each non-root
bridge and the designated ports.
The following is an example of how the STP algorithm works. As shown in Figure 4-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.
4-5

Figure 4-2 Network diagram for the STP algorithm
Device A
With priority 0
AP1 AP2
5
10
BP1
BP2
4 CP1
CP2
Device B
With priority 1
Device C
With priority 2
z Initial state of each device

Table 4-4 shows the initial state of each device.
Table 4-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

Table 4-5 shows the comparison process and result on each device.
Table 4-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, AP1: {0, 0, 0, AP1}
Device A
0, 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.
4-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,
BP2: {1, 0, 1, BP2}
2, CP2}. Device B finds that the configuration BPDU of the
local port {1, 0, 1, BP2} is superior to the received
configuration BPDU, and therefore discards the received
configuration BPDU.
z Device B compares the configuration BPDUs of all its 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. As the {0, 5, 1, BP2}
calculated BPDU is superior, BP2 will act as the designated
port, and the configuration BPDU on this port will be replaced
with the calculated configuration BPDU, which will be sent out
periodically.
z Port CP1 receives the configuration BPDU of Device A {0, 0,
0, AP2}. Device C finds that the received configuration BPDU
is superior to the configuration BPDU of the local port {2, 0, 2,
CP1}, and updates the configuration BPDU of CP1.
z Port CP2 receives the configuration BPDU of port BP2 of CP1: {0, 0, 0, AP2}
Device C
Device B {1, 0, 1, BP2} before the configuration BPDU is CP2: {1, 0, 1, BP2}
updated. Device C finds that the received configuration
BPDU is superior to the configuration BPDU of the local port
{2, 0, 2, CP2}, and therefore updates the configuration BPDU
of CP2.
After comparison:
z The configuration BPDU of CP1 is elected as the optimum 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 {0, 10, 2, CP2}
the configuration BPDU of this port will be replaced with the
calculated configuration BPDU.
z Then, port CP2 receives the updated configuration BPDU of
Device B {0, 5, 1, BP2}. Because the received configuration
BPDU is superior to its own configuration BPDU, Device C CP1: {0, 0, 0, AP2}
launches a BPDU update process.
CP2: {0, 5, 1, BP2}
z At the same time, port CP1 receives periodic configuration
BPDUs from Device A. Device C does not launch an update
process after comparison.
4-7

BPDU of port
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 4-3.
Figure 4-3 The final calculated spanning tree
Device A
With priority 0
AP1 AP2
BP1
BP2
4
CP2
Device B
With priority 1
Device C
With priority 2
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.
4-8

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.
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 RSTP
Developed based on the 802.1w standard of IEEE, RSTP is an optimized version of STP. It achieves
rapid network convergence by allowing a newly elected root port or designated port to enter the
forwarding state much quicker under certain conditions than in STP.
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.
4-9

Introduction to MSTP
Why MSTP
Weaknesses 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.
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.
Features of MSTP
Developed based on IEEE 802.1s, MSTP overcomes the shortcomings of STP and RSTP. In addition
to the support for rapid network convergence, it 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 spanning tree instances by means of a VLAN-to-instance
mapping table. MSTP can reduce communication overheads and resource usage by mapping
multiple VLANs to one instance.
z MSTP divides a switched network into multiple regions, each containing multiple spanning trees
that are independent of one another.
z MSTP prunes a loop network into a loop-free tree, thus avoiding proliferation and endless cycling
of packets in a loop network. In addition, it provides multiple redundant paths for data forwarding,
thus supporting load balancing of VLAN data.
z MSTP is compatible with STP and RSTP.
4-10

Basic Concepts in MSTP
Figure 4-4 Basic concepts in MSTP
Region A0
VLAN 1 mapped to instance 1
Other VLANs mapped to CIST
BPDU BPDU
B CST
C
D
Region D0
VLAN 1 mapped to instance 1, BPDU Region B0
B as regional root bridge VLAN 1 mapped to instance 1
VLAN 2 mapped to instance 2, VLAN 2 mapped to instance 2
C as regional root bridge Other VLANs mapped to CIST
Region C0
VLAN 2 and 3 mapped to
instance 2
Assume that all devices in Figure 4-4 are running MSTP. This section explains some basic concepts of
MSTP.
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-instance 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 4-4 have the same MST region configuration:
z The same region name,
z The same VLAN-to-instance 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).
Multiple MST regions can exist in a switched network. You can use an MSTP command to assign
multiple devices to the same MST region.
4-11

VLAN-to-instance mapping table
As an attribute of an MST region, the VLAN-to-instance mapping table describes the mapping
relationships between VLANs and MSTIs. In Figure 4-4, for example, the VLAN-to-instance mapping
table of region A0 is as follows: 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-instance mapping table.
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 the section of the CIST in an MST region,
as shown in Figure 4-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 4-4 represent the CST.
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 4-4, for example, the ISTs in all MST regions plus the inter-region CST constitute the CIST of
the entire network.
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 4-4, for example, multiple spanning trees can exist in each MST region, each spanning tree
corresponding to the specific VLAN(s). These spanning trees are called MSTIs.
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 4-4, the regional root of MSTI 1 is device B, while that of MSTI 2 is
device C.
Common root bridge
The common root bridge is the root bridge of the CIST.

In Figure 4-4, for example, the common root bridge is a device in region A0.
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 4-4, for
example, if a device in region A0 is interconnected with the first port of a device in region D0 and the
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.
4-12

During MSTP calculation, a boundary ports role on an MSTI is consistent with its role on the CIST. But
that is not true with master ports. A master port on MSTIs is a root port on the CIST.
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 a root port or master port. When the root port or master port is
blocked, the alternate port becomes the new root port or master port.
z Backup port: The backup port of a designated port. When the designated port is blocked, the
backup port becomes a new designated port and starts forwarding data without delay. A loop
occurs when two ports of the same MSTP device are interconnected. Therefore, the device will
block either of the two ports, and the backup port is that port to be blocked.
A port can play different roles in different MSTIs.
Figure 4-5 Port roles
Connecting to the
common root bridge
MST region Port 2

Port 1
Master port Alternate port

A
B C
Port 6
Port 5
Backup port
D
Designated port
Port 3 Port 4
Figure 4-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.
4-13

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 4-6 lists the port state(s) supported by
each port role ( indicates that the port supports this state, while indicates that the port does not
support this state).
Table 4-6 Port states supported by different port roles
Port role
(right) Root port/master
Designated port Alternate port Backup port
Port state port
(below)
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.
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.
MSTI calculation
Within an MST region, MSTP generates different MSTIs for different VLANs based on the
VLAN-to-instance 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:
4-14

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 BPDU dropping
Protocols and Standards
MSTP is documented in:

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

Before configuring MSTP, you need to know the role 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 the Configuring an MST Region Required
root bridge
Configuring the Root Bridge or a Secondary Root Bridge Optional
Configuring the Work Mode of an MSTP Device Optional
Configuring the Priority of a 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 Timeout Factor Optional

Configuring the Maximum Port Rate Optional
Configuring Ports as Edge Ports Optional
Configuring the Link Type of Ports Optional
Configuring the Mode a Port Uses to Recognize/Send

Optional
MSTP Packets
Enabling the Output of Port State Transition Information Optional
4-15

Task Remarks
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 the Configuring Path Costs of Ports Optional
leaf nodes
Configuring Port Priority Optional
Configuring the Link Type of Ports Optional
Configuring the Mode a Port Uses to Recognize/Send
Optional
MSTP Packets
Enabling the Output of Port State Transition Information Optional
Enabling the MSTP Feature Required

Performing mCheck Optional
Configuring Digest Snooping Optional
Configuring No Agreement Check Optional
Configuring Protection Functions Optional
z If GVRP and MSTP are both 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 you
configure the VLAN-to-instance 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 system view take effect globally; configurations made in Ethernet interface
view take effect on the current interface only; configurations made in port group view take effect
on all member ports in the port group; configurations made in Layer 2 aggregate interface view
take effect only on the aggregate interface; configurations made on an aggregation member port
can take effect only after the port is removed from the aggregation group.
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 is consistent with those
of the corresponding Layer 2 aggregate interface.
z Though the member ports of an aggregation group do not participate in MSTP calculation, the
ports still reserve its MSTP configurations for participating MSTP calculation after leaving the
aggregation group.
4-16

Configuring MSTP
Configuring an MST Region
Make the following configurations on the root bridge and on the leaf nodes separately.
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-instance mapping All VLANs in an MST region
table are mapped to MSTI 0 by
vlan-mapping modulo modulo
default.
Configure the MSTP Optional

revision level of the MST revision-level level
region 0 by default
Display the MST region

configurations that are not check region-configuration Optional
activated yet
Activate MST region
active region-configuration Required
configuration manually
Display the configurations
The display command can
of currently activated MST display stp region-configuration
be executed in any view.
regions
z Two or more MSTP-enabled devices belong to the same MST region only if they are configured to
have the same format selector (0 by default, not configurable), MST region name, the same
VLAN-to-instance mapping entries in the MST region and the same MST region revision level, and
they are interconnected via a physical link.
z The configuration of MST regionrelated parameters, especially the VLAN-to-instance 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 activate the MST regionrelated parameters using the active region-configuration
command, or enable MSTP using the stp enable command in the case that MSTP is not enabled.
4-17

Configuring 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 or a secondary root bridge using the commands
provided by the system.
Note that:
z A device has independent roles in different MSTIs. It can act as the root bridge or a secondary
root bridge of one MSTI while being 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 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 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 then, 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.
Configuring the current device as the root bridge of a specific spanning tree
Follow these steps to configure the current device as the root bridge of a specific spanning tree:

Required
Configure the current device as
stp [ instance instance-id ] By default, a device does not
the root bridge of a specific
root primary function as the root bridge of
spanning tree
any spanning tree.
Configuring the current device as a secondary root bridge of a specific spanning tree
Follow these steps to configure the current device as a secondary root bridge of a specific spanning
tree:

Required
Configure the current device as
stp [ instance instance-id ] By default, a device does not
a secondary root bridge of a
root secondary function as a secondary root
specific spanning tree
bridge.
4-18

z After specifying the current device as the root bridge or a secondary root bridge, you cannot
change the priority of the device.
z Alternatively, you can also configure 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 a Device.
Configuring the Work Mode of an MSTP Device
Being mutually compatible, MSTP and RSTP can recognize each others protocol packets. 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.
Make this configuration on the root bridge and on the leaf nodes separately.
Follow these steps to configure the MSTP work mode:

Configure the work mode of Required

stp mode { stp | rstp | mstp }
MSTP MSTP mode by default
Configuring the Priority of a Device
Device priorities participate in spanning tree calculation. 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.
Make this configuration on the root bridge only.
Follow these steps to configure the priority of a device in a specified MSTI:

Configure the priority of the Required
stp [ instance instance-id ]
current device in a specified
priority priority 32768 by default
MSTI
4-19

z After configuring a 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.
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.
Make this configuration on the root bridge only. 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 an MST region:

Configure the maximum hops Required

stp max-hops hops
of the MST region 20 by default
Configuring the Network Diameter of a Switched Network
Any two terminal devices 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. The network diameter is a parameter that indicates the network size. A bigger network
diameter indicates a larger network size.
Follow these steps to configure the network diameter of a switched network:

Configure the network Required
diameter of the switched stp bridge-diameter diameter
network 7 by default
4-20

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.
z The network diameter must be configured on the root bridge. Otherwise, it will not take effect.
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.
z To prevent temporary loops on a network, MSTP sets an intermediate port state called learning
between the discarding state and the forwarding state, that is, before a port in the discarding state
can transit to the forwarding state, it needs to go through the learning state. Forward delay is the
delay time for port state transition. This is to ensure that the state transition of the local port and
that of the peer occur in a synchronized manner.
z Hello time is the time interval at which a device sends configuration BPDUs to the surrounding
devices to ensure that the paths are fault-free. If a device fails to receive configuration BPDUs
within a certain period of time, it starts a new spanning tree calculation process.
z MSTP can detect link failures and automatically restore blocked redundant links to the forwarding
state. A device on the CIST determines whether a configuration BPDU received by a port has
expired according to the max age parameter. If yes, it starts a new spanning tree calculation
process. The max age set for an MSTI does not take effect.
These three timers set on the root bridge of the CIST apply on all the devices on the entire switched
network.

Follow these steps to configure the timers of MSTP:

Optional
Configure the forward delay
stp timer forward-delay time 1,500 centiseconds (15
timer
seconds) by default
Optional
Configure the hello timer stp timer hello time 200 centiseconds (2 seconds)
by default
4-21

Optional
Configure the max age timer stp timer max-age time 2,000 centiseconds (20
seconds) by default
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 bridge-diameter command and let
MSTP automatically calculate optimal settings of these three timers based on the network diameter.
Configuring the Timeout Factor
The timeout factor is a parameter used to decide the timeout time, as shown in the following formula:
Timeout time = timeout factor 3 hello time.
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 assumes
that the upstream device has failed and starts a new spanning tree calculation process.
Sometimes a device may fail to receive a BPDU from the upstream device because the upstream
device is busy. A spanning tree calculation that occurs in this case not only is unnecessary, but also
wastes the network resources. In a very stable network, you can avoid such unwanted spanning tree
calculations by setting the timeout factor to 5, 6, or 7.
Follow these steps to configure the timeout factor:
4-22

Required
Configure the timeout factor of the device stp timer-factor factor
3 by default
Configuring the Maximum Port Rate
The maximum rate of a port refers to the maximum number of BPDUs the port can send within each
hello time. The maximum rate of a port is related to the physical status of the port and the network
structure.
Follow these steps to configure the maximum rate of a port or a group of ports:

Enter Ethernet interface

Enter view, or Layer 2 interface interface-type
interface aggregate interface interface-number Required
view or port view
Use either command.
group view port-group manual
Enter port group view
port-group-name
Configure the maximum rate of the Required

stp transmit-limit limit
ports 10 by default
The higher the maximum port rate is, the more BPDUs will be sent within each hello time, and the
more system resources will be used. By setting an appropriate maximum port rate, you can limit the
rate at which the port sends BPDUs and prevent MSTP from using excessive network resources when
the network becomes instable. We recommend that you use the default setting.
Configuring Ports as Edge Ports
If a port directly connects to a user terminal rather than another device or a shared LAN segment, this
port is regarded as an edge port. When a network topology change occurs, an edge port will not cause
a temporary loop. Because a device does not know whether a port is directly connected to a terminal,
you need to manually configure the port to be an edge port. After that, this port can transition rapidly
from the blocked state to the forwarding state without delay.
Follow these steps to specify a port or a group of ports as edge port or ports:

4-23

Enter interface interface-type
view, or Layer 2
interface interface-number Required
aggregate interface view
view or port Use either command.
group view Enter port group view
port-group manual
port-group-name
Required
Configure the current ports as edge ports stp edged-port enable All 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. To restore the edge port, re-enable it.
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.
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 achieving VLAN-based load balancing.
The device can automatically calculate the default path cost; alternatively, you can also configure the
path cost for ports.
Make the following configurations on the leaf nodes only.
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 private standard.
Follow these steps to specify a standard for the device to use when calculating the default path cost:

Optional
Specify a standard for the
device to use when calculating stp pathcost-standard By default, the device
the default path costs of its { dot1d-1998 | dot1t | legacy } calculates the default path cost
ports for ports based on a private
standard.
4-24

Table 4-7 Link speed vs. path cost
Link speed Duplex state 802.1d-1998 802.1t Private standard

0 65535 200,000,000 200,000
Single Port 100 2,000,000 2,000
Aggregate Link 2 Ports 100 1,000,000 1,800
10 Mbps
Aggregate Link 3 Ports 100 666,666 1,600
Aggregate Link 4 Ports 100 500,000 1,400
Single Port 19 200,000 200
Aggregate Link 2 Ports 19 100,000 180
100 Mbps
Single Port 4 20,000 20
1000 Mbps
Single Port 2 2,000 2
10 Gbps
Aggregate Link 3 Ports 2 666 1
Aggregate Link 4 Ports 2 500 1
When calculating path cost for an aggregate 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 of 802.1t 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 aggregate interface interface-number Required
or port group view
Use either command.
view port-group manual
port-group-name
Required
stp [ instance By default, MSTP
Configure the path cost of the ports
instance-id ] cost cost automatically calculates
the path cost of each port.
4-25

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.
Configuration example
# Specify that the device use 802.1d-1998 when calculating the default path costs of its ports.
<Sysname> system-view
[Sysname] stp pathcost-standard dot1d-1998
# Set the path cost of GigabitEthernet 1/0/3 on MSTI 2 to 200.

[Sysname] interface gigabitethernet 1/0/3
[Sysname-GigabitEthernet1/0/3] stp instance 2 cost 200
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.
Make this configuration on the leaf nodes only.
Follow these steps to configure the priority of a port or a group of ports:


interface view aggregate interface interface-number Required
or port group view
Use either command.
port-group-name
stp [ instance Optional
Configure the port priority instance-id ] port priority
priority 128 for all ports by default.
4-26

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 priority value indicates a higher priority. If you configure the same priority value
for all the ports on a device, the specific priority of a port depends on the index number of the port.
Changing the priority of a port triggers a new spanning tree calculation process.
Configuring the Link Type of Ports
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 configure the link type of a port or a group of ports:

Enter Ethernet
interface view, or
Layer 2
aggregate
or port group interface view Use either command.
view
Enter port group port-group manual
view port-group-name
Optional
The default setting is
stp point-to-point { auto | auto; namely the port
Configure the link type of ports
force-false | force-true } automatically detects
whether its link is
point-to-point.
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.
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets
A port can receive/send MSTP packets of two formats:
4-27

z dot1s: 802.1s-compliant standard format, and
z legacy: 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 on 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 on a port or a group of ports:

Enter Ethernet
Enter interface view, or
interface Layer 2
interface-number Required
view or aggregate
port group interface view Use either command.
view Enter port group port-group manual
Configure the mode the port Required
stp compliance { auto | dot1s |
uses to recognize/send MSTP
legacy } auto by default
packets
z MSTP provides the MSTP packet format incompatibility guard function. In MSTP mode, if a port is
configured to recognize/send MSTP packets in a mode other than auto, and 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 MSTP provides the MSTP packet format frequent change guard function. 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 administrators.
Enabling the Output of Port State Transition Information
In a large-scale, MSTP-enabled network, there are a large number of MSTIs, so ports may frequently
transition from one state to another. In this situation, you can enable devices to output the port state
transition information of all MSTIs or the specified MSTI so as to monitor the port states in real time.
Follow these steps to enable output of port state transition information:

4-28

Required
Enable output of port state transition stp port-log { all |
information instance instance-id } This function is enabled by
default.
Enabling the MSTP Feature
You must enable MSTP for the device before any other MSTP-related configurations can take effect.
Follow these steps to enable the MSTP feature:

Required
Enable the MSTP feature globally stp enable MSTP is globally enabled by
default.
Enter Ethernet
Enter interface view, or interface interface-type
interface view Layer 2 aggregate interface-number Required
or port group interface view
Use either command.
Optional
Enable the MSTP feature for the
stp enable By default, MSTP is enabled
ports
on all ports.
z MSTP takes effect when it is enabled both globally and on the port.
z To control MSTP flexibly, you can use the undo stp enable 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 CPU resources of the device.
Performing mCheck
MSTP has three working modes: STP compatible mode, RSTP mode, and MSTP mode.
If a port on a device running MSTP (or RSTP) connects to a device running STP, this port will
automatically migrate to the STP-compatible mode. However, it will not be able to migrate
automatically back to the MSTP (or RSTP) mode, but will remain working in the STP-compatible mode
under the following circumstances:
z The device running STP is shut down or removed.
z The device running STP migrates to the MSTP (or RSTP) mode.
4-29

By then, 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 the following two approaches, which lead to the same
result.
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 interface view, or Layer interface interface-type

2 aggregate interface view interface-number
Perform mCheck stp mcheck Required
An mCheck operation takes effect on a device only when MSTP operates in RSTP or MSTP mode.
Configuring Digest Snooping
As defined in IEEE 802.1s, interconnected devices are in the same region only when the MST
region-related configurations (domain name, revision level, VLAN-to-instance mappings) on them are
identical. An MSTP-enabled device identifies devices in the same MST region by 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-instance mappings.
Since MSTP implementations vary with vendors, the configuration digests calculated using private
keys is different; hence different vendors devices in the same MST region can not communicate with
each other.
Enabling the Digest Snooping feature on the port connecting the local device to a third-party device in
the same MST region can make the two devices communicate with each other.
4-30

Before enabling digest snooping, ensure that associated devices of different vendors are
interconnected and run MSTP.
Configuring the Digest Snooping feature
You can enable Digest Snooping only on a device that is connected to a third-party device that uses its
private key to calculate the configuration digest.
Follow these steps to configure Digest Snooping:

Enter Ethernet
interface view, or interface interface-type
Enter Layer 2 aggregate interface-number
interface view interface view Required
or port group Use either command.
Enable digest snooping on the Required

stp config-digest-snooping
interface or port group Not enabled by default
Return to system view quit

Required
Enable global digest snooping stp config-digest-snooping
Not enabled by default
z With the Digest Snooping feature enabled, comparison of configuration digest is not needed for
in-the-same-region check, so the VLAN-to-instance mappings must be the same on associated
ports.
z With global Digest Snooping enabled, modification of VLAN-to-instance 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, thus making the
configuration take effect on all configured ports and reducing impact on the network, and disable
the feature globally to disable it on all associated ports.
z You are recommended not to enable Digest Snooping on MST region edge ports, thus avoiding
loops.
z You are recommended to enable Digest Snooping first and then MSTP. Do not configure Digest
Snooping when the network works well, thus avoiding traffic interruption.
4-31

Digest Snooping configuration example
1) Network requirements
z Device A and Device B connect to Device C, a third-party device, and all these devices are in the
same region.
z Enable Digest Snooping on Device A and Device B so that the three devices can communicate
with one another.
Figure 4-6 Digest Snooping configuration
2) Configuration procedure
# Enable Digest Snooping on GigabitEthernet 1/0/1 of Device A and enable global Digest Snooping on
Device A.
[DeviceA-GigabitEthernet1/0/1] stp config-digest-snooping
[DeviceA] stp config-digest-snooping
# Enable Digest Snooping on GigabitEthernet 1/0/1 of Device B and enable global Digest Snooping on
Device B.
<DeviceB> system-view
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] stp config-digest-snooping
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] stp config-digest-snooping
Configuring No Agreement Check
In RSTP and MSTP, two types of messages are used for rapid state transition on designated ports:
z Proposal: sent by designated ports to request rapid transition
z Agreement: used to acknowledge rapid transition requests
Both RSTP and MSTP devices can perform rapid transition on a designated port only when the port
receives an agreement packet from the downstream device. The differences between RSTP and
MSTP devices 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.
4-32

Figure 4-7 shows the rapid state transition mechanism on MSTP designated ports.
Figure 4-7 Rapid state transition of an MSTP designated port
Figure 4-8 shows rapid state transition of an RSTP designated port.

Figure 4-8 Rapid state transition of an RSTP designated port
Upstream device Downstream device
Proposal for rapid transition

Root port blocks other non-
edge ports, changes to
forwarding state and sends
Agreement to upstream device
n t
eme
Agre
Designated port
changes to
forwarding state Root port
Designated port
If the upstream device is a third-party device, the rapid state transition implementation may be limited.
For example, when the upstream device uses a rapid transition mechanism similar to that of RSTP,
and the downstream device adopts MSTP and does not work in 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 device
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.
Configuration Prerequisites
z A device is connected to a third-party upstream device supporting MSTP via a point-to-point link.
z Configure the same region name, revision level and VLAN-to-instance mappings on the two
devices, thus assigning them to the same region.
Configuring the No Agreement Check function
To make the No Agreement Check feature take effect, enable it on the root port.
Follow these steps to configure No Agreement Check:
4-33

Enter Ethernet
interface view, or interface interface-type
Enter
Layer 2 aggregate interface-number Required
interface or
interface view
port group Use either command.
port-group-name
Required
Enable No Agreement Check stp no-agreement-check
Disabled by default
No Agreement Check configuration example
z Device A connects to Device B, a third-party device that has different MSTP implementation. Both
devices are in the same region.
z Device B is the regional root bridge, and Device A is the downstream device.
Figure 4-9 No Agreement Check configuration
# Enable No Agreement Check on GigabitEthernet 1/0/1 of Device A.
[DeviceA-GigabitEthernet1/0/1] stp no-agreement-check
Configuring Protection Functions
An MSTP-enabled device supports the following protection functions:

z BPDU guard
z Root guard
z Loop guard
z TC-BPDU guard
z BPDU dropping
Among loop guard, root guard and edge port settings, only one function can take effect on a port at the
same time.
4-34

Configuration prerequisites
MSTP has been correctly configured on the device.
Enabling BPDU guard
For access layer devices, the access ports generally connect directly with user terminals (such as PCs)
or file servers. In this case, the access ports are configured as edge ports to allow rapid transition.
When these ports receive configuration BPDUs, the system will automatically set these ports as
non-edge ports and start a new spanning tree calculation process. This will cause a change of network
topology. Under normal conditions, these ports should not receive configuration BPDUs. However, if
someone forges configuration BPDUs maliciously to attack the devices, network instability will occur.
MSTP provides the BPDU guard function to protect the system against such attacks. With the BPDU
guard function enabled on the devices, when edge ports receive configuration BPDUs, MSTP will
close these ports and notify the NMS that these ports have been closed by MSTP. Those ports closed
thereby can be restored only by the network administers.
Make this configuration on a device with edge ports configured.
Follow these steps to enable BPDU guard:

Enable the BPDU guard Required

stp bpdu-protection
function for the device Disabled by default
BPDU guard does not take effect on loopback test-enabled ports. For information about loopback test,
refer to Ethernet Interface Configuration in the Access Volume.
Enabling Root guard
The root bridge and secondary root bridge of a spanning 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. If the root guard
function is enabled on a port of 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, it will revert to its original state.
Make this configuration on a designated port.
4-35

Follow these steps to enable root guard:

Enter Ethernet
interface view, or
Layer 2
aggregate
view
Enable the root guard function for Required

stp root-protection
the port(s) Disabled by default
Enabling Loop guard
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 takes
part in STP calculation, all the instances on the port, no matter what roles the port plays, will be set to,
and stay in, the Discarding state.
Make this configuration on the root port or an alternate port of a device.
Follow these steps to enable loop guard:

Enter Ethernet
interface view, or
Layer 2
aggregate
view
Enable the loop guard function for Required

stp loop-protection
the ports Disabled by default
Enabling TC-BPDU guard
When receiving topology change (TC) BPDUs (the BPDUs used to notify topology changes), a switch
flushes its forwarding address entries. If someone forges TC-BPDUs to attack the switch, the switch
will receive a large number of TC-BPDUs within a short time and be busy with forwarding address
entry flushing. This affects network stability.
4-36

With the TC-BPDU guard function, you can set the maximum number of immediate forwarding address
entry flushes that the switch can perform within a certain period of time after receiving the first
TC-BPDU. For TC-BPDUs received in excess of the limit, the switch performs forwarding address
entry flush only when the time period expires. This prevents frequent flushing of forwarding address
entries.
Follow these steps to enable TC-BPDU guard:

Enable the TC-BPDU guard Optional

stp tc-protection enable
function Enabled by default
Configure the maximum

number of forwarding address
entry flushes that the device stp tc-protection threshold Optional
can perform within a specific number 6 by default
time period after it receives the
first TC-BPDU
We recommend that you keep this feature enabled.
Enabling BPDU Dropping
In a STP-enabled network, some users may send BPDU packets to the switch continuously in order to
destroy the network. When a switch receives the BPDU packets, it will forward them to other switches.
As a result, STP calculation is performed repeatedly, which may occupy too much CPU of the switches
or cause errors in the protocol state of the BPDU packets.
In order to avoid this problem, you can enable BPDU dropping on Ethernet ports. Once the function is
enabled on a port, the port will not receive or forward any BPDU packets. In this way, the switch is
protected against the BPDU packet attacks so that the STP calculation is assured to be right.
Follow these steps to enable BPDU dropping:

Enter Ethernet Required

interface view Use either command.
Enter or Layer-2
interface-number Configurations made in
interface view aggregate
interface view interface view will take effect
or port group on the current port only;
view configurations made in port
Enter port port-group manual
group view will take effect on
all ports in the port group.
Enable BPDU dropping for the Required

bpdu-drop any
port(s) Disabled by default
4-37

Displaying and Maintaining MSTP
View information about abnormally
display stp abnormal-port Available in any view
blocked ports
View information about ports blocked
display stp down-port Available in any view
by STP protection functions
View the historical information of port display stp [ instance
role calculation for the specified instance-id ] history [ slot Available in any view
MSTI or all MSTIs slot-number ]
View the statistics of TC/TCN
display stp [ instance
BPDUs sent and received by all ports Available in any view
instance-id ] tc [ slot slot-number ]
in the specified MSTI or all MSTIs
display stp [ instance

View the status information and instance-id ] [ interface
statistics information of MSTP interface-list | slot slot-number ]
[ brief ]
View the MST region configuration
display stp region-configuration Available in any view
information that has taken effect
View the root bridge information of all
display stp root Available in any view
MSTIs
Clear the statistics information of
reset stp [ interface interface-list ] Available in user view
MSTP
MSTP Configuration Example

z All devices on the network are in the same MST region. Device A and Device B work on the
distribution layer, while Device C and Device D work on the access layer.
z Configure MSTP so that packets of different VLANs are forwarded along different spanning trees:
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 VLAN 10 and VLAN 30 are terminated on the distribution layer devices, and VLAN 40 is
terminated on the access layer devices, so the root bridges of MSTI 1 and MSTI 3 are Device A
and Device B respectively, while the root bridge of MSTI 4 is Device C.
4-38

Figure 4-10 Network diagram for MSTP configuration
GE
/1
1/0
1/0
GE
/1
/1
GE
1/0
1/0
GE
/1
1) VLAN and VLAN member port configuration

Create VLAN 10, VLAN 20, and VLAN 30 on Device A and Device B respectively, create VLAN 10,
VLAN 20, and VLAN 40 on Device C, and create VLAN 20, VLAN 30, and VLAN 40 on Device D;
configure the ports on these devices as trunk ports and assign them to related VLANs. The detailed
configuration procedure is omitted.
2) Configuration on Device A
# Enter MST region view, configure the MST region name as example, map VLAN 10, VLAN 30, and
VLAN 40 to MSTI 1, MSTI 3, and MSTI 4 respectively, and configure the revision level of the MST
region as 0.
[DeviceA] stp region-configuration
[DeviceA-mst-region] region-name example
[DeviceA-mst-region] instance 1 vlan 10
[DeviceA-mst-region] revision-level 0
# Activate MST region configuration.

[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit
# Specify the current device as the root bridge of MSTI 1.

[DeviceA] stp instance 1 root primary
# Enable MSTP globally.

[DeviceA] stp enable
3) Configuration on Device B
region as 0.
4-39

[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

[DeviceB] stp instance 3 root primary

[DeviceB] stp enable
4) Configuration on Device C.
region as 0.
<DeviceC> system-view
[DeviceC] stp region-configuration
[DeviceC-mst-region] region-name example
[DeviceC-mst-region] instance 1 vlan 10
[DeviceC-mst-region] revision-level 0

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

[DeviceC] stp instance 4 root primary

[DeviceC] stp enable
5) Configuration on Device D.
region as 0.
<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
4-40

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

[DeviceD] stp enable
6) Verifying the configurations

You can use the display stp brief command to display brief spanning tree information on each device
after the network is stable.
# Display brief spanning tree information on Device A.
[DeviceA] display stp brief
MSTID Port Role STP State Protection
0 GigabitEthernet1/0/1 ALTE DISCARDING NONE
0 GigabitEthernet1/0/2 DESI FORWARDING NONE
0 GigabitEthernet1/0/3 ROOT FORWARDING NONE
# Display brief spanning tree information on Device B.

[DeviceB] display stp brief
# Display brief spanning tree information on Device C.

[DeviceC] display stp brief
# Display brief spanning tree information on Device D.

[DeviceD] display stp brief
4-41

Based on the above information, you can draw the MSTI corresponding to each VLAN, as shown in
Figure 4-11.
Figure 4-11 MSTIs corresponding to different VLANs
4-42

5 LLDP Configuration
When configuring LLDP, go to these sections for information you are interested in:
z Overview
z LLDP Configuration Task List
z Performing Basic LLDP Configuration
z Configuring CDP Compatibility
z Configuring LLDP Trapping
z Displaying and Maintaining LLDP
z LLDP Configuration Examples
Overview
Background
In a heterogeneous network, it is important that different types of network devices from different
vendors can discover one other and exchange configuration for interoperability and management sake.
This calls for a standard configuration exchange platform.
To address the needs, the IETF drafted the Link Layer Discovery Protocol (LLDP) in IEEE 802.1AB.
The protocol operates on the data link layer to exchange device information between directly
connected devices. With LLDP, a device sends local device information (including its major functions,
management IP address, device ID, and port ID) as TLV (type, length, and value) triplets in LLDPDUs
to the directly connected devices, and at the same time, stores the device information received in
LLDPDUs sent from the LLDP neighbors in a standard management information base (MIB). It allows
a network management system to fast detect Layer-2 network topology change and identify what the
change is.
For more information about MIBs, refer to SNMP Configuration in the System Volume.
Basic Concepts
LLDP frames
LLDP sends device information in LLDP data units (LLDPDUs). LLDPDUs are encapsulated in
Ethernet II or SNAP frames.
1) Ethernet II-encapsulated LLDP frame format
5-1

Figure 5-1 Ethernet II-encapsulated LLDP frame format
The fields in the frame are described in Table 5-1:
Table 5-1 Description of the fields in an Ethernet II-encapsulated LLDP frame
Field Description
The MAC address to which the LLDPDU is advertised. It is fixed to
Destination MAC address
0x0180-C200-000E, a multicast MAC address.
The MAC address of the sending port. If the port does not have a MAC
Source MAC address
address, the MAC address of the sending bridge is used.
Type The Ethernet type for the upper layer protocol. It is 0x88CC for LLDP.
Data LLDP data unit (LLDPDU).

Frame check sequence, a 32-bit CRC value used to determine the
FCS
validity of the received Ethernet frame.
2) SNAP-encapsulated LLDP frame format

Figure 5-2 SNAP-encapsulated LLDP frame format
0 15 31
Source MAC address
Type
Data = LLDPU
(n bytes)
FCS
The fields in the frame are described in Table 5-2:
Table 5-2 Description of the fields in a SNAP-encapsulated LLDP frame
Field Description
The MAC address to which the LLDPDU is advertised. It is fixed to
0x0180-C200-000E, a multicast MAC address.
5-2

Field Description
The MAC address of the sending port. If the port does not have a MAC
Source MAC address
address, the MAC address of the sending bridge is used.
The SNAP type for the upper layer protocol. It is
Type
0xAAAA-0300-0000-88CC for LLDP.
Data LLDPDU.
Frame check sequence, a 32-bit CRC value used to determine the

FCS
validity of the received Ethernet frame.
LLDPDUs
LLDP uses LLDPDUs to exchange information. An LLDPDU comprises multiple type, length, and value
(TLV) sequences, each carrying a type of device information, as shown in Figure 5-3.
Figure 5-3 An LLDPDU
An LLDPDU can carry up to 28 types of TLVs, of which the chassis ID TLV, port ID TLV, TTL TLV, and
end of LLDPDU TLV (end TLV in the figure) are mandatory TLVs that must be carried and other TLVs
are optional.
TLVs
TLVs are type, length, and value sequences that carry information elements, where the type field
identifies the type of information, the length field indicates the length of the information field in octets,
and the value field contains the information itself.
LLDPDU TLVs fall into these categories: basic management TLVs, organizationally (IEEE 802.1 and
IEEE 802.3) specific TLVs, and LLDP-MED (media endpoint discovery) TLVs. Basic management
TLVs are essential to device management. Organizationally specific TLVs and LLDP-MED TLVs are
used for enhanced device management; they are defined by standardization or other organizations
and thus are optional to LLDPDUs.
1) Basic management TLVs
Table 5-1 lists the basic management TLV types currently in use. Some of them are mandatory to
LLDPDUs, that is, must be included in every LLDPDU.
Table 5-3 Basic LLDP TLVs
Type Description Remarks

Chassis ID Bridge MAC address of the sending device.
ID of the sending port.
If MED TLVs are included in the LLDPDU, the port ID TLV
Port ID carries the MAC address of the sending port or the bridge
MAC in case the port does not have a MAC address. If no Mandatory
MED TLVs are included, the port ID TLV carries the port
name.
Time To Live Life of the transmitted information on the receiving device.
End of LLDPDU Marks the end of the TLV sequence in the LLDPDU.
5-3

Type Description Remarks
Port Description Port description of the sending port.
System Name Assigned name of the sending device.
System Description Description of the sending device.
Identifies the primary functions of the sending device and Optional
System Capabilities
the primary functions that have been enabled.
Management address used to reach higher level entities to
Management assist discovery by network management, and the interface
Address number and OID (object identifier) associated with the
address.
2) IEEE 802.1 organizationally specific TLVs
Table 5-4 IEEE 802.1 organizationally specific TLVs
Type Description
Port VLAN ID PVID of the sending port
Port And Protocol VLAN ID Port and protocol VLAN IDs
VLAN Name A specific VLAN name on the port

Protocol Identity Protocols supported on the port
Currently, 3Com switches 4510G support receiving but not sending protocol identity TLVs.
3) IEEE 802.3 organizationally specific TLVs
Table 5-5 IEEE 802.3 organizationally specific TLVs
Type Description
Contains the rate and duplex capabilities of the sending port,
MAC/PHY Configuration/Status support for auto negotiation, enabling status of auto
negotiation, and the current rate and duplex mode.
Power Via MDI Contains Power supply capability of the port.
Indicates the support of the port for link aggregation, the
Link Aggregation aggregation capability of the port, and the aggregation status
(that is, whether the link is in an aggregation).
Indicates the supported maximum frame size. It is now the
Maximum Frame Size
MTU of the port.
LLDP-MED TLVs
LLDP-MED TLVs provide multiple advanced applications for voice over IP (VoIP), such as basic
configuration, network policy configuration, and address and directory management. LLDP-MED TLVs
satisfy the voice device vendors requirements for cost effectiveness, ease of deployment, and ease of
5-4

management. In addition, LLDP-MED TLVs make deploying voice devices in Ethernet easier.
LLDP-MED TLVs are shown in Table 5-6:
Table 5-6 LLDP-MED TLVs
Type Description
Allows a MED endpoint to advertise the supported LLDP-MED
LLDP-MED Capabilities
TLVs and its device type.
Allows a network device or MED endpoint to advertise LAN
Network Policy type and VLAN ID of the specific port, and the Layer 2 and
Layer 3 priorities for a specific set of applications.
Allows a network device or MED endpoint to advertise
Extended Power-via-MDI
power-related information (according to IEEE 802.3AF).
Allows a MED endpoint device to advertise its hardware
Hardware Revision
version.
Firmware Revision Allows a MED endpoint to advertise its firmware version.
Software Revision Allows a MED endpoint to advertise its software version.
Allows an LLDP-MED endpoint device to advertise its serial
Serial Number
number.
Manufacturer Name Allows a MED endpoint to advertise its vendor name.
Model Name Allows a MED endpoint to advertise its model name.
Allows a MED endpoint to advertise its asset ID. The typical

Asset ID case is that the user specifies the asset ID for the endpoint to
facilitate directory management and asset tracking.
Allows a network device to advertise the appropriate location
Location Identification identifier information for an endpoint to use in the context of
location-based applications.
Management address
The management address of a device is used by the network management system to identify and
manage the device for topology maintenance and network management. The management address is
encapsulated in the management address TLV.
Operating Modes of LLDP
LLDP can operate in one of the following modes:

z TxRx mode. A port in this mode sends and receives LLDP frames.
z Tx mode. A port in this mode only sends LLDP frames.
z Rx mode. A port in this mode only receives LLDP frames.
z Disable mode. A port in this mode does not send or receive LLDP frames.
Each time the LLDP operating mode of a port changes, its LLDP protocol state machine re-initializes.
To prevent LLDP from being initialized too frequently at times of frequent operating mode change, an
initialization delay, which is user configurable, is introduced. With this delay mechanism, a port must
wait for the specified interval before it can initialize LLDP after the LLDP operating mode changes.
5-5

How LLDP Works
Transmitting LLDP frames
An LLDP-enabled port operating in TxRx mode or Tx mode sends LLDP frames to its directly
connected devices both periodically and when the local configuration changes. To prevent the network
from being overwhelmed by LLDP frames at times of frequent local device information change, an
interval is introduced between two successive LLDP frames.
This interval is shortened to 1 second in either of the following two cases:
z A new neighbor is discovered, that is, a new LLDP frame is received carrying device information
new to the local device.
z The LLDP operating mode of the port changes from Disable/Rx to TxRx or Tx.
This is the fast sending mechanism of LLDP. With this mechanism, a specific number of LLDP frames
are sent successively at the 1-second interval to help LLDP neighbors discover the local device as
soon as possible. Then, the normal LLDP frame transmit interval resumes.
Receiving LLDP frames
An LLDP-enabled port operating in TxRx mode or Rx mode checks the TLVs carried in every LLDP
frame it receives for validity violation. If valid, the information is saved and an aging timer is set for it
based on the time to live (TTL) TLV carried in the LLDPDU. If the TTL TLV is zero, the information is
aged out immediately.
The protocols and standards related to LLDP include:

z IEEE 802.1AB-2005, Station and Media Access Control Connectivity Discovery
z ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices
LLDP Configuration Task List

Complete these tasks to configure LLDP:
Task Remarks
Enabling LLDP Required
Setting LLDP Operating Mode Optional

Setting the LLDP Re-Initialization Delay Optional
Performing Enabling LLDP Polling Optional

Basic LLDP Configuring the TLVs to Be Advertised Optional
Configuration
Configuring the Management Address and Its Encoding
Format Optional
Setting Other LLDP Parameters Optional

Setting an Encapsulation Format for LLDPDUs Optional
Configuring CDP Compatibility Optional
Configuring LLDP Trapping Optional
5-6

LLDP-related configurations made in Ethernet interface view takes effect only on the current port, and
those made in port group view takes effect on all ports in the current port group.
Performing Basic LLDP Configuration

Enabling LLDP
To make LLDP take effect on certain ports, you need to enable LLDP both globally and on these ports.
Follow these steps to enable LLDP:

Required
Enable LLDP globally lldp enable By default, LLDP is disabled
global.
Enter Enter Ethernet interface interface-type
Ethernet interface view interface-number Required
interface
view or port Enter port port-group manual Use either command.
group view group view port-group-name
Optional
Enable LLDP lldp enable By default, LLDP is enabled on
a port.
Setting LLDP Operating Mode
LLDP can operate in one of the following modes.

z TxRx mode. A port in this mode sends and receives LLDP frames.
z Tx mode. A port in this mode only sends LLDP frames.
z Rx mode. A port in this mode only receives LLDP frames.
z Disable mode. A port in this mode does not send or receive LLDP frames.
Follow these steps to set LLDP operating mode:


Ethernet interface view interface-number
Required
interface
view or port Enter port port-group manual Use either command.
lldp admin-status { disable | Optional

Set the LLDP operating mode
rx | tx | txrx } TxRx by default.
5-7

Setting the LLDP Re-Initialization Delay
When LLDP operating mode changes on a port, the port initializes the protocol state machines after a
certain delay. By adjusting the LLDP re-initialization delay, you can avoid frequent initializations caused
by frequent LLDP operating mode changes on a port.
Follow these steps to set the LLDP re-initialization delay for ports:

Set the LLDP re-initialization Optional

lldp timer reinit-delay delay
delay 2 seconds by default
Enabling LLDP Polling
With LLDP polling enabled, a device checks for local configuration changes periodically. Upon
detecting a configuration change, the device sends LLDP frames to inform the neighboring devices of
the change.
Follow these steps to enable LLDP polling:

Enter
Ethernet
interface view
or port group Use either command.
view Enter port
port-group manual port-group-name
group view
Enable LLDP polling and set Required

lldp check-change-interval interval
the polling interval Disabled by default
Configuring the TLVs to Be Advertised
Follow these steps to configure the LLDPDU TLVs to be advertised out the specified port or ports:

Enter Enter
Ethernet Ethernet interface interface-type interface-number
interface interface view Required
view or
port Use either command.
Enter port
group group view
view
5-8

lldp tlv-enable { basic-tlv { all |
port-description | system-capability |
system-description | system-name } |
dot1-tlv { all | port-vlan-id | Optional
protocol-vlan-id [ vlan-id ] | vlan-name
Configure the TLVs to be [ vlan-id ] } | dot3-tlv { all | link-aggregation | By default, all types
advertised mac-physic | max-frame-size | power } | of LLDP TLVs except
med-tlv { all | capability | inventory | location identification
location-id { civic-address device-type TLV are advertisable.
country-code { ca-type ca-value }&<110> |
elin-address tel-number } | network-policy |
power-over-ethernet } }
Configuring the Management Address and Its Encoding Format
LLDP encodes management addresses in numeric or character string format in management address
TLVs.
By default, management addresses are encoded in numeric format. If a neighbor encoded its
management address in character string format, you can configure the encoding format of the
management address as string on the connecting port to guarantee normal communication with the
neighbor.
Follow these steps to configure a management address to be advertised and its encoding format on
one or a group of ports:

Enter Enter
Ethernet Ethernet
interface interface view
Optional
By default, the management
Enable LLDP to advertise address is sent through
management address TLVs, LLDPDUs, and the
lldp management-address-tlv management address is the
and optionally, configure a
[ ip-address ] main IP address of the
management IP address if
needed lowest-ID VLAN carried on the
interface. If the VLAN is not
assigned a main IP address,
127.0.0.1 is used.
Optional
Configure the encoding lldp
format of the management management-address-format By default, the management
address to character string string address is encapsulated in the
numeric format.
5-9

Setting Other LLDP Parameters
The TTL TLV carried in an LLDPDU determines how long the device information carried in the
LLDPDU can be saved on a recipient device.
You can configure the TTL of locally sent LLDP frames to determine how long information about the
local device can be saved on a neighbor device by setting the TTL multiplier. The TTL is expressed as
follows:
TTL = Min (65535, (TTL multiplier LLDPDU transmit interval))
As the expression shows, the TTL can be up to 65535 seconds. TTLs greater than it will be rounded
down to 65535 seconds.
Follow these steps to change the TTL multiplier:

Optional
Set the TTL multiplier lldp hold-multiplier value
4 by default.
Set the LLDPDU transmit Optional

lldp timer tx-interval interval
interval 30 seconds by default
Optional
Set LLDPDU transmit delay lldp timer tx-delay delay
2 seconds by default
Set the number of LLDP

frames sent each time fast Optional
lldp fast-count count
LLDPDU transmission is 3 by default
triggered.
Both the LLDPDU transmit interval and delay must be less than the TTL to ensure that the LLDP
neighbors can receive LLDP frames to update information about the device you are configuring before
it is aged out.
Setting an Encapsulation Format for LLDPDUs
LLDPDUs can be encapsulated in Ethernet II or SNAP frames.

z With Ethernet II encapsulation configured, an LLDP port sends LLDPDUs in Ethernet II frames
and processes an incoming LLDP frame only when it is Ethernet II encapsulated.
z With SNAP encapsulation configured, an LLDP port sends LLDPDUs in SNAP frames and
processes an incoming LLDP frame only when it is SNAP encapsulated.
By default, LLDPDUs are encapsulated in Ethernet II frames. If the neighbor devices encapsulate
LLDPDUs in SNAP frames, configure the encapsulation format for LLDPDUs as SNAP to guarantee
normal communication with the neighbors.
Follow these steps to set the encapsulation format for LLDPDUs to SNAP:
5-10


Enter Ethernet interface view interface-number Required
interface view or
port group view Enter port Use either command.
group view
Required
Ethernet II
encapsulation format
Set the encapsulation format for applies by default.
lldp encapsulation snap
LLDPDUs to SNAP To restore the
default, use the undo
lldp encapsulation
command.
LLDP-CDP (CDP is short for the Cisco Discovery Protocol) packets use only SNAP encapsulation.
Configuring CDP Compatibility
For detailed information about voice VLAN, refer to VLAN Configuration in the Access Volume.
You need to enable CDP compatibility for your device to work with Cisco IP phones.
As your LLDP-enabled device cannot recognize CDP packets, it does not respond to the requests of
Cisco IP phones for the voice VLAN ID configured on the device. This can cause a requesting Cisco IP
phone to send voice traffic without any tag to your device, disabling your device to differentiate the
voice traffic from other types of traffic.
By configuring CDP compatibility, you can enable LLDP on your device to receive and recognize CDP
packets from Cisco IP phones and respond with CDP packets carrying the voice VLAN configuration
TLV for the IP phones to configure the voice VLAN automatically. Thus, the voice traffic is confined in
the configured voice VLAN to be differentiated from other types of traffic.
Before configuring CDP compatibility, make sure that:

z LLDP is enabled globally.
z LLDP is enabled on the port connected to an IP phone and is configured to operate in TxRx mode
on the port.
5-11

Configuring CDP Compatibility
CDP-compatible LLDP operates in one of the follows two modes:

z TxRx, where CDP packets can be transmitted and received.
z Disable, where CDP packets can neither be transmitted nor be received.
To make CDP-compatible LLDP take effect on certain ports, first enable CDP-compatible LLDP
globally and configure CDP-compatible LLDP to operate in TxRx mode.
Follow these steps to enable LLDP to be compatible with CDP:

Enable CDP compatibility Required

lldp compliance cdp
globally Disabled by default.

interface
view or port Enter port Use either command.
group view group view
Required
Configure CDP-compatible
lldp compliance admin-status cdp By default,
LLDP to operate in TxRx
txrx CDP-compatible LLDP
mode
operates in disable mode.
As the maximum TTL allowed by CDP is 255 seconds, ensure that the product of the TTL multiplier
and the LLDPDU transmit interval is less than 255 seconds for CDP-compatible LLDP to work properly
with Cisco IP phones.
Configuring LLDP Trapping

LLDP trapping is used to notify the network management system (NMS) of events such as new
neighboring devices detected and link malfunctions.
To prevent excessive LLDP traps from being sent when topology is unstable, you can set a minimum
trap sending interval for LLDP.
Follow these steps to configure LLDP trapping:

interface
view or port Enter port Use either command.
group view group view
5-12

lldp notification remote-change Required

Enable LLDP trap sending
Quit to system view quit
Set the interval to send LLDP lldp timer notification-interval Optional

traps interval 5 seconds by default
Displaying and Maintaining LLDP

Display the global LLDP
display lldp local-information
information or the information
[ global | interface interface-type Available in any view
contained in the LLDP TLVs to
interface-number ]
be sent through a port
display lldp neighbor-information
Display the information
[ brief | interface interface-type
contained in the LLDP TLVs Available in any view
interface-number [ brief ] | list
sent from neighboring devices
[ system-name system-name ] ]
display lldp statistics [ global |
Display LLDP statistics interface interface-type Available in any view
interface-number ]
display lldp status [ interface
Display LLDP status of a port Available in any view
interface-type interface-number ]
Display types of advertisable display lldp tlv-config [ interface
optional LLDP TLVs interface-type interface-number ]
LLDP Configuration Examples

Basic LLDP Configuration Example
As shown in Figure 5-4, the NMS and Switch A are located in the same Ethernet. An MED device and
Switch B are connected to GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 of Switch A.
Enable LLDP on the ports of Switch A and Switch B to monitor the link between Switch A and Switch B
and the link between Switch A and the MED device on the NMS.
Figure 5-4 Network diagram for basic LLDP configuration
MED
GE1/0/1
NMS
GE1/0/2 GE1/0/1
Switch A Switch B
5-13

1) Configure Switch A.
# Enable LLDP globally.
<SwitchA> system-view
[SwitchA] lldp enable
# Enable LLDP on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 (you can skip this step because
LLDP is enabled on ports by default), and set the LLDP operating mode to Rx.
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] lldp enable
[SwitchA-GigabitEthernet1/0/1] lldp admin-status rx
[SwitchA-GigabitEthernet1/0/1] quit
[SwitchA-GigabitEthernet1/0/2] lldp admin-status rx
2) Configure Switch B.
# Enable LLDP globally.
<SwitchB> system-view
[SwitchB] lldp enable
# Enable LLDP on GigabitEthernet1/0/1 (you can skip this step because LLDP is enabled on ports by
default), and set the LLDP operating mode to Tx.
[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] lldp enable
[SwitchB-GigabitEthernet1/0/1] lldp admin-status tx
[SwitchB-GigabitEthernet1/0/1] quit
3) Verify the configuration.

# Display the global LLDP status and port LLDP status on Switch A.
[SwitchA] display lldp status
Global status of LLDP : Enable
The current number of LLDP neighbors : 2
The current number of CDP neighbors : 0
LLDP neighbor information last changed time: 0 days,0 hours,4 minutes,40 seconds
Transmit interval : 30s
Hold multiplier : 4
Reinit delay : 2s
Transmit delay : 2s
Trap interval : 5s
Fast start times : 3
Port 1 [GigabitEthernet1/0/1]:
Port status of LLDP : Enable
Admin status : Rx_Only
Trap flag : No
5-14

Roll time : 0s
Number of neighbors : 1
Number of MED neighbors : 1
Number of CDP neighbors : 0
Number of sent optional TLV : 0
Number of received unknown TLV : 0
Trap flag : No
Roll time : 0s
As the sample output shows, GigabitEthernet 1/0/1 of Switch A connects a MED device, and
GigabitEthernet 1/0/2 of Switch A connects a non-MED device. Both ports operate in Rx mode, that is,
they only receive LLDP frames.
# Tear down the link between Switch A and Switch B and then display the global LLDP status and port
LLDP status on Switch A.
[SwitchA] display lldp status
Global status of LLDP : Enable
The current number of LLDP neighbors : 1
The current number of CDP neighbors : 0
LLDP neighbor information last changed time: 0 days,0 hours,5 minutes,20 seconds
Transmit interval : 30s
Hold multiplier : 4
Reinit delay : 2s
Transmit delay : 2s
Trap interval : 5s
Fast start times : 3
Trap flag : No
Roll time : 0s
5-15

Trap flag : No
Roll time : 0s
As the sample output shows, GigabitEthernet 1/0/2 of Switch A does not connect any neighboring
devices.
CDP-Compatible LLDP Configuration Example
As shown in Figure 5-5:

z GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 of Switch A are each connected to a Cisco IP
phone.
z Configure voice VLAN 2 on Switch A. Enable CDP compatibility of LLDP on Switch A to allow the
Cisco IP phones to automatically configure the voice VLAN, thus confining their voice traffic within
the voice VLAN to be isolated from other types of traffic.
Figure 5-5 Network diagram for CDP-compatible LLDP configuration
1) Configure a voice VLAN on Switch A

# Create VLAN 2.
[SwitchA] vlan 2
[SwitchA-vlan2] quit
# Set the link type of GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to trunk and enable voice VLAN
on them.
[SwitchA-GigabitEthernet1/0/1] port link-type trunk
[SwitchA-GigabitEthernet1/0/1] voice vlan 2 enable
[SwitchA-GigabitEthernet1/0/2] voice vlan 2 enable
5-16

2) Configure CDP-compatible LLDP on Switch A.
# Enable LLDP globally and enable LLDP to be compatible with CDP globally.
[SwitchA] lldp enable
[SwitchA] lldp compliance cdp
# Enable LLDP (you can skip this step because LLDP is enabled on ports by default), configure LLDP
to operate in TxRx mode, and configure CDP-compatible LLDP to operate in TxRx mode on
GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.
[SwitchA-GigabitEthernet1/0/1] lldp admin-status txrx
[SwitchA-GigabitEthernet1/0/1] lldp compliance admin-status cdp txrx
[SwitchA-GigabitEthernet1/0/2] lldp admin-status txrx
[SwitchA-GigabitEthernet1/0/2] lldp compliance admin-status cdp txrx
3) Verify the configuration

# Display the neighbor information on Switch A.
[SwitchA] display lldp neighbor-information
CDP neighbor-information of port 1[GigabitEthernet1/0/1]:
CDP neighbor index : 1
Chassis ID : SEP00141CBCDBFE
Port ID : Port 1
Sofrware version : P0030301MFG2
Platform : Cisco IP Phone 7960
Duplex : Full
CDP neighbor-information of port 2[GigabitEthernet1/0/2]:

CDP neighbor index : 2
Chassis ID : SEP00141CBCDBFF
Port ID : Port 1
Sofrware version : P0030301MFG2
Platform : Cisco IP Phone 7960
Duplex : Full
As the sample output shows, Switch A has discovered the IP phones connected to GigabitEthernet
1/0/1 and GigabitEthernet 1/0/2, and has obtained their LLDP device information.
5-17

6 VLAN Configuration
When configuring VLAN, go to these sections for information you are interested in:
z Introduction to VLAN
z Configuring Basic VLAN Settings
z Configuring Basic Settings of a VLAN Interface
z Port-Based VLAN Configuration
z MAC-Based VLAN Configuration
z Protocol-Based VLAN Configuration
z Displaying and Maintaining VLAN
z VLAN Configuration Example
Introduction to VLAN
VLAN Overview
Ethernet is a network technology based on the Carrier Sense Multiple Access/Collision Detect
(CSMA/CD) mechanism. As the medium is shared, collisions and excessive broadcasts cannot be
avoided on an Ethernet. To address the issue, virtual LAN (VLAN) was introduced.
The idea is to break a LAN down into separate VLANs, that is, Layer 2 broadcast domains whereby
frames are switched between ports assigned to the same VLAN. VLANs are isolated from each other
at Layer 2. A VLAN is a bridging domain, and all broadcast traffic is contained within it, as shown in
Figure 6-1.
Figure 6-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:
6-1

2) Confining broadcast traffic within individual VLANs. This reduces bandwidth waste and improves
network performance.
3) 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.
4) 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 6-2.
Figure 6-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 6-3.
Figure 6-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 handles the frame depending on whether the frame is VLAN
tagged and the value of the VLAN tag, if any. For more information, refer to section Introduction to
Port-Based VLAN.
6-2

z The Ethernet II encapsulation format is used here. Besides the Ethernet II encapsulation format,
other encapsulation formats, including 802.2 LLC, 802.2 SNAP, and 802.3 raw, are also
supported by Ethernet. The VLAN tag fields are also added to frames encapsulated in these
formats for VLAN identification.
z For a frame with multiple VLAN tags, the device handles it according to its outer VLAN tag, while
transmits its inner VLAN tags as payload.
Types of VLAN
You can implement VLAN based on:

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

Follow these steps to configure basic VLAN settings:

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.
Optional
Configure a name for
name text By default, the name of a VLAN is its VLAN
the current VLAN
ID, VLAN 0001 for example.
Configure the Optional

description of the description text VLAN ID is used by default, for example,
current VLAN VLAN 0001.
6-3

z As the default VLAN, VLAN 1 cannot be created or removed.
z You cannot manually create or remove VLANs reserved for special purposes.
z Dynamic VLANs cannot be removed with the undo vlan command.
z A VLAN with a QoS policy applied cannot be removed.
z For isolate-user-VLANs or secondary VLANs, if you have used the isolate-user-vlan command to
create mappings between them, you cannot remove them until you remove the mappings
between them 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.
Configuring Basic Settings of a VLAN Interface

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

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.
ip address ip-address Optional

Assign an IP address
{ mask | mask-length } No IP address is assigned to any VLAN
to the VLAN interface
[ sub ] interface by default.

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.
6-4

Before creating a VLAN interface for a VLAN, create the VLAN first.
Port-Based VLAN Configuration

Introduction to Port-Based VLAN
Port-based VLANs group VLAN members by port. A port forwards traffic for a VLAN only after it is
assigned to the VLAN.
Port link type
You can configure the link type of a port as access, trunk, or hybrid. The three link types use different
VLAN tag handling methods. When configuring the link type of a port, note that:
z An access port can belong to only one VLAN. Usually, ports directly connected to PCs are
configured as access ports.
z A trunk port can carry multiple VLANs to receive and send traffic for them. Except traffic of the
default VLAN, traffic passes through a trunk port will be VLAN tagged. Usually, ports connecting
network devices are configured as trunk ports to allow members of the same VLAN to
communicate with each other across multiple network devices.
z Like a trunk port, a hybrid port can carry multiple VLANs to receive and send traffic for them.
Unlike a trunk port, a hybrid port allows traffic of all VLANs to pass through VLAN untagged. You
can configure a port connected to a network device or user terminal as a hybrid port for access
link connectivity or trunk connectivity.
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.
6-5

z Do not set the voice VLAN as the default VLAN of a port in automatic voice VLAN assignment
mode. Otherwise, the system prompts error information. For information about voice VLAN, refer
to Voice VLAN Configuration.
z The local and remote ports must use the same default VLAN ID for the traffic of the default VLAN
to be transmitted properly.
A port configured with the default VLAN handles a frame as follows:
Actions (in the inbound direction) Actions (in the

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

VLAN ID is the same as
Tag the frame with
the default VLAN ID. Remove the default VLAN
Access the default VLAN
z Drop the frame if its VLAN tag and send the frame.
tag.
ID is different from the
default VLAN ID.
z Remove the tag and
send the frame if the
frame carries the
default VLAN tag and
the port belongs to the
default VLAN.
Trunk
Check whether the z Send the frame
default VLAN is without removing the
permitted on the tag if its VLAN is
port: z Receive the frame if its carried on the port but
VLAN is carried on the is different from the
z If yes, tag the port.
frame with the default one.
z Drop the frame if its VLAN
default VLAN is not carried on the port. Send the frame if its
tag. VLAN is carried on the
z If not, drop the port. The frame is sent
frame. with the VLAN tag
removed or intact
Hybrid
depending on your
configuration with the
port hybrid vlan
command. This is true of
the default VLAN.
Assigning an Access Port to a VLAN
You can assign an access port to a VLAN in VLAN view, 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:

6-6

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

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


interface view interface-number Use either command.
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.
z In Layer-2 aggregate
interface view, the
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
port or ports as access
access by default.
Optional
Assign the current access
port access vlan vlan-id By default, all access ports
port(s) to a VLAN
belong to VLAN 1.
6-7

z Before assigning an access port to a VLAN, create the VLAN first.
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 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 subsequent configurations
aggregate apply to the current port.
interface-number
Enter interface view z In port group view, the
interface view subsequent configurations
or port group apply to all ports in the port
view group.
interface view, the
aggregate interface and all its
member ports.
port link-type trunk Required
port or ports as trunk
Required
Assign the trunk port(s) to the port trunk permit vlan
specified VLAN(s) { vlan-id-list | all } By default, a trunk port carries
only VLAN 1.
Optional
Configure the default VLAN of
port trunk pvid vlan vlan-id VLAN 1 is the default VLAN by
the trunk port(s)
default.
6-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.
z The local and remote hybrid ports must use the same default VLAN ID for the traffic of the default
VLAN to be transmitted properly.
z After configuring the default VLAN for a trunk port, you must use the port trunk permit vlan
command to configure the trunk port to allow packets from the default VLAN to pass through, so
that the egress port can forward packets from the default VLAN.
next port.
Assigning a Hybrid Port to a VLAN
A hybrid port can carry multiple VLANs. You can assign it to a VLAN in interface view or port group
view.
Follow these steps to assign a hybrid port to one or multiple VLANs:


Enter Layer-2 z In Ethernet interface view,
aggregate the subsequent
interface-number
interface view configurations apply to the
current port.
Enter
interface
view or port
apply to all ports in the port
group view
group.
interface view, the
its member ports.
port link-type hybrid Required
port(s) as hybrid
Required
Assign the hybrid port(s) to port hybrid vlan vlan-id-list By default, a hybrid port allows
the specified VLAN(s) { tagged | untagged } only packets of VLAN 1 to
pass through untagged.
Optional
Configure the default VLAN of
port hybrid pvid vlan vlan-id VLAN 1 is the default by
the hybrid port
default.
6-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.
z The local and remote hybrid ports must use the same default VLAN ID for the traffic of the default
VLAN to be transmitted properly.
z After configuring the default VLAN for a hybrid port, you must use the port hybrid vlan command
to configure the hybrid port to allow packets from the default VLAN to pass through, so that the
egress port can forward packets from the default VLAN.
next port.
MAC-Based VLAN Configuration

Introduction to MAC-Based VLAN
MAC-based VLANs group VLAN members by MAC address. They are mostly used in conjunction with
security technologies such as 802.1X to provide secure, flexible network access for terminal devices.
MAC-based VLAN implementation
With MAC-based VLAN configured, the device processes received packets as follows:
z When receiving an untagged frame, the device looks up the list of MAC-to-VLAN mappings based
on the source MAC address of the frame for a match. Two matching modes are available: exact
matching and fuzzy matching. In exact matching mode, the device searches the MAC-to-VLAN
mappings whose masks are all-Fs. If the MAC address in a MAC-to-VLAN mapping matches the
source MAC address of the untagged frame exactly, the device ends the search and adds a VLAN
tag containing the corresponding VLAN ID to the packet. In fuzzy matching mode, the device
searches the MAC-to-VLAN mappings whose masks are not all-Fs and performs a logical AND
operation on the keyword and each mask. If the result of an AND operation matches the
corresponding MAC address exactly, the device ends the search the adds a VLAN tag containing
the corresponding VLAN ID to the packet. If no match is found, the system looks up other types of
VLANs to make the forwarding decision.
z When receiving a tagged frame, the receiving port forwards the frame if it is assigned to the
corresponding VLAN or drops the frame if it is not. In this case, port-based VLAN applied.
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)
6-10

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.
Configuring a MAC Address-Based VLAN
MAC-based VLANs are available only on hybrid ports.
Follow these steps to configure a MAC-based VLAN:

mac-vlan mac-address
Associate MAC addresses
mac-address vlan vlan-id [ priority Required
with a VLAN
priority ]
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.
6-11

Protocol-Based VLAN Configuration
Introduction to Protocol-Based VLAN
Protocol-based VLANs are only applicable on hybrid ports.
In this approach, inbound packets are assigned to different VLANs based on their protocol types and
encapsulation formats. The protocols that can be used for VLAN assignment include IP, IPX, and
AppleTalk (AT). The encapsulation formats include Ethernet II, 802.3 raw, 802.2 LLC, and 802.2 SNAP.
A protocol-based VLAN is defined by a protocol template comprised of encapsulation format and
protocol type. A port can be associated with multiple protocol templates. An untagged packet reaching
a port associated with protocol-based VLANs will be processed as follows.
z If the packet matches a protocol template, the packet will be tagged with the VLAN tag
corresponding to the protocol template.
z If the packet matches no protocol template, the packet will be tagged with the default VLAN ID of
the port.
The port processes a tagged packet as it processes tagged packets of a port-based VLAN.
z If the port permits the VLAN ID of the packet to pass through, the port forwards the packet.
z If the port does not permit the VLAN ID of the packet to pass through, the port drops the packet.
This feature is mainly used to assign packets of the specific service type to a specific VLAN.
Configuring a Protocol-Based VLAN
Follow these steps to configure a protocol-based VLAN:

Required
Enter VLAN view vlan vlan-id If the specified VLAN does
not exist, this command
creates the VLAN first.
protocol-vlan
[ protocol-index ] { at | ipv4 |
ipv6 | ipx { ethernetii | llc |
Create a protocol template for the raw | snap } | mode
Required
VLAN { ethernetii etype etype-id |
llc { dsap dsap-id [ ssap
ssap-id ] | ssap ssap-id } |
snap etype etype-id } }
Exit VLAN view quit Required
Enter interface Enter Ethernet interface interface-type

Required
view or port interface view interface-number
6-12

group view Enter Layer-2 interface Use either command.
aggregate bridge-aggregation z In Ethernet interface view,
interface view interface-number the subsequent
configurations apply to the
current port.
apply to all ports in the
Enter port port-group manual port group.
group view port-group-name z In Layer-2 aggregate
interface view, the
aggregate interface and
all its member ports.
Configure the port link type as
hybrid
Configure the port(s) to permit the
packets of the specified port hybrid vlan vlan-id-list
Required
protocol-based VLANs to pass { tagged | untagged }
through untagged
Associate the hybrid port(s) with port hybrid protocol-vlan
the specified protocol-based vlan vlan-id { protocol-index Required
VLAN [ to protocol-end ] | all }
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.
next port.
6-13

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

Enter VLAN view vlan vlan-id
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.
interface view, the
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
6-14

Associate the hybrid port(s) with
port hybrid ip-subnet-vlan
the specified IP subnet-based Required
vlan vlan-id
VLAN
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 |
Display VLAN information interface interface-type Available in any view
interface-number.subnumber |
reserved | static ]
display interface
Display VLAN interface
vlan-interface Available in any view
information
[ vlan-interface-id ]
Display hybrid ports or trunk
display port { hybrid | trunk } Available in any view
ports on the device
display mac-vlan { all |

Display MAC address-to-VLAN dynamic | mac-address
entries mac-address | 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
and protocol indexes of the Available in any view
{ vlan-id [ to vlan-id ] | all }
specified VLANs
display protocol-vlan
Display protocol-based VLAN interface { interface-type
information on specified interface-number [ to Available in any view
interfaces interface-type
interface-number ] | all }
Display IP subnet-based VLAN
display ip-subnet-vlan vlan
information and IP subnet Available in any view
{ vlan-id [ to vlan-id ] | all }
indexes of specified VLANs
Display the IP subnet-based
VLAN information and IP display ip-subnet-vlan
subnet indexes of specified interface { interface-list | all }
ports
6-15

Clear statistics on a port [ interface-type Available in user view
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.
VLAN Configuration Example

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

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

# Configure GigabitEthernet 1/0/1 as a trunk port and configure its default VLAN ID as 100.
[DeviceA-GigabitEthernet1/0/1] port link-type trunk
[DeviceA-GigabitEthernet1/0/1] port trunk pvid vlan 100
# Configure GigabitEthernet 1/0/1 to deny the packets of VLAN 1 (by default, the packets of VLAN 1
are permitted to pass through on all the ports).
[DeviceA-GigabitEthernet1/0/1] undo port trunk permit vlan 1
6-16

# Configure GigabitEthernet 1/0/1 to permit packets from VLAN 2, VLAN 6 through VLAN 50, and
VLAN 100 to pass through.
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 2 6 to 50 100
[DeviceA] quit
2) Configure Device B as you configure Device A.
Verification
Verifying the configuration on Device A is similar to that of Device B. So only Device A is taken for
example here.
# Display the information about GigabitEthernet 1/0/1 of Device A to verify the above configurations.
<DeviceA> display interface gigabitethernet 1/0/1
GigabitEthernet1/0/1 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 001e-c16f-ae68
Description: GigabitEthernet1/0/1 Interface
Loopback is not set
Media type is twisted pair
Port hardware type is 1000_BASE_T
Unknown-speed mode, unknown-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 9216
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
Peak value of input: 0 bytes/sec, at 2000-04-26 12:01:40
Peak value of output: 0 bytes/sec, at 2000-04-26 12:01:40
Last 300 seconds input: 0 packets/sec 0 bytes/sec -%
Last 300 seconds output: 0 packets/sec 0 bytes/sec -%
Input (total): 0 packets, 0 bytes
0 unicasts, 0 broadcasts, 0 multicasts
Input (normal): 0 packets, - bytes
0 unicasts, 0 broadcasts, 0 multicasts
Input: 0 input errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 frame, - overruns, 0 aborts
- ignored, - parity errors
Output (total): 0 packets, 0 bytes
6-17

0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses
Output (normal): 0 packets, - bytes
0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, - no carrier
The output above shows that:

z The port (GigabitEthernet 1/0/1) is a trunk port.
z The default VLAN of the port is VLAN 100.
z The port permits packets of VLAN 2, VLAN 6 through VLAN 50, and VLAN 100 to pass through.
Therefore, the configuration is successful.
6-18

7 Isolate-User-VLAN Configuration
When configuring an isolate-user VLAN, go to these sections for information you are interested in:
z Overview
z Configuring Isolate-User-VLAN
z Displaying and Maintaining Isolate-User-VLAN
z Isolate-User-VLAN Configuration Example
Overview
An isolate-user-VLAN adopts a two-tier VLAN structure. In this approach, two types of VLANs,
isolate-user-VLAN and secondary VLAN, are configured on the same device.
The following are the characteristics of the isolate-user-VLAN implementation:
z Isolate-user-VLANs are mainly used for upstream data exchange. An isolate-user-VLAN can be
associated with multiple secondary VLANs. As the upstream device is aware of only the
isolate-user-VLAN but not the secondary VLANs, network configuration is simplified and VLAN
resources are saved.
z You can isolate the Layer 2 traffic of different users by assigning the ports connected to them to
different secondary VLANs. To enable communication between secondary VLANs associated with
the same isolate-user-VLAN, you can enable local proxy ARP on the upstream device to realize
Layer 3 communication between the secondary VLANs.
As illustrated in the following figure, the isolate-user-VLAN function is enabled on Switch B. VLAN 10 is
the isolate-user-VLAN, and VLAN 2, VLAN 5, and VLAN 8 are secondary VLANs associated with
VLAN 10 and are invisible to Switch A.
Figure 7-1 An isolate-user-VLAN example
Configuring Isolate-User-VLAN
Configure the isolate-user-VLAN through the following steps:
1) Configure the isolate-user-VLAN;
2) Configure the secondary VLANs;
7-1

3) Assign non-trunk ports to the isolate-user-VLAN and ensure that at least one port takes the
isolate-user-VLAN as its default VLAN;
4) Assign non-trunk ports to each secondary VLAN and ensure that at least one port in a secondary
VLAN takes the secondary VLAN as its default VLAN;
5) Associate the isolate-user-VLAN with the specified secondary VLANs.
Follow these steps to configure an isolate-user-VLAN:

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 Refer to Assigning an Access Port to a
Access port
and ensure that at VLAN
least one port
Use either approach.
takes the
isolate-user-VLAN Refer to Assigning a Hybrid Port to a
as its default Hybrid port
VLAN
VLAN
Create secondary VLANs vlan { vlan-id1 [ to vlan-id2 ] | all } Required

Assign ports to
each secondary Refer to Assigning an Access Port to a
VLAN and Access port
VLAN
ensure that at
least one port in Required to choose
a secondary either
VLAN takes the
secondary VLAN Refer to Assigning a Hybrid Port to a
Hybrid port
VLAN
as its default
VLAN
Associate the isolate-user-VLAN isolate-user-vlan isolate-user-vlan-id

with the specified secondary secondary secondary-vlan-id [ to Required
VLANs secondary-vlan-id ]
After associating an isolate-user-VLAN with the specified secondary VLANs, you cannot add/remove a
access port to/from each involved VLAN or remove each involved VLAN. To do that, you must cancel
the association first.
7-2

Displaying and Maintaining Isolate-User-VLAN
Display the mapping between an
display isolate-user-vlan
isolate-user-VLAN and its secondary Available in any view
[ isolate-user-vlan-id ]
VLAN(s)
Isolate-User-VLAN Configuration Example

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

z Configure VLAN 5 on Device B as an isolate-user-VLAN, assign the uplink port GigabitEthernet
1/0/5 to VLAN 5, and associate VLAN 5 with secondary VLANs VLAN 2 and VLAN 3. Assign
GigabitEthernet 1/0/2 to VLAN 2 and GigabitEthernet 1/0/1 to VLAN 3.
z Configure VLAN 6 on Device C as an isolate-user-VLAN, assign the uplink port GigabitEthernet
1/0/5 to VLAN 6, and associate VLAN 6 with secondary VLANs VLAN 3 and VLAN 4. Assign
GigabitEthernet 1/0/3 to VLAN 3 and GigabitEthernet 1/0/4 to VLAN 4.
z For Device A, Device B only has VLAN 5 and Device C only has VLAN 6.
Figure 7-2 Network diagram for isolate-user-VLAN configuration
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 gigabitethernet 1/0/5
[DeviceB-vlan5] quit
# Configure the secondary VLANs.

[DeviceB] vlan 3
7-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 gigabitethernet 1/0/5
[DeviceC-vlan6] quit
# Configure the secondary VLANs.

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

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

[DeviceB] display isolate-user-vlan
Isolate-user-VLAN VLAN ID : 5
Secondary VLAN ID : 2-3
VLAN ID: 5
VLAN Type: static
Isolate-user-VLAN type : isolate-user-VLAN
Route Interface: not configured
Description: VLAN 0005
Name: VLAN 0005
Tagged Ports: none
Untagged Ports:
gigabitethernet 1/0/1 gigabitethernet 1/0/2 gigabitethernet 1/0/5
VLAN ID: 2
VLAN Type: static
Isolate-user-VLAN type : secondary
Name: VLAN 0002
Tagged Ports: none
Untagged Ports:
7-4

gigabitethernet 1/0/2 gigabitethernet 1/0/5
VLAN ID: 3
VLAN Type: static
Isolate-user-VLAN type : secondary
Name: VLAN 0003
Tagged Ports: none
Untagged Ports:
gigabitethernet 1/0/1 gigabitethernet 1/0/5
7-5

8 Voice VLAN Configuration
When configuring a voice VLAN, go to these sections for information you are interested in:
z Overview
z Configuring a Voice VLAN
z Displaying and Maintaining Voice VLAN
z Voice VLAN Configuration
Overview
A voice VLAN is configured specially for voice traffic. After assigning the ports connecting to voice
devices to a voice VLAN, you can configure quality of service (QoS) parameters for the voice traffic,
thus improving transmission priority and ensuring voice quality.
OUI Addresses
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.
You can configure the OUI addresses in advance or use the default OUI addresses. Table 8-1 lists the
default OUI address for each vendors devices.
Table 8-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
8-1

z In general, as the first 24 bits of a MAC address (in binary format), an OUI address is a globally
unique identifier assigned to a vendor by IEEE. OUI addresses mentioned in this document,
however, are different from those in common sense. OUI addresses in this document are used by
the system to determine whether a received packet is a voice packet. They are the results of the
AND operation of the two arguments mac-address and oui-mask in the voice vlan mac-address
command.
z You can remove the default OUI address of a device manually and then add new ones manually.
Voice VLAN Assignment Modes
A port can be assigned to a voice VLAN in one of the following two modes:
z In automatic mode, the system matches the source MAC addresses in the untagged 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 packet is received from the port after the aging time expires.
Assigning/removing ports to/from a voice VLAN are automatically performed by the system.
z In manual mode, you should assign an IP phone connecting port to a voice VLAN manually. Then,
the system matches the source MAC addresses in the packets against the OUI addresses. If a
match is found, the system issues ACL rules and configures the packet precedence. In this mode,
assigning/removing ports to/from a voice VLAN are performed manually.
z Both modes forward tagged packets according to their tags.
The following table lists the co-relation between the port voice VLAN mode, the voice traffic type of an
IP phone, and the port link type.
Table 8-2 Co-relation
Voice VLAN assignment Voice traffic

Port link type
mode type
Access: not supported
Trunk: supported if the default VLAN of the

connecting port exists and is not the voice VLAN and
Tagged voice the connecting port belongs to the default VLAN
traffic
Automatic mode Hybrid: supported if the default VLAN of the
the traffic of the default VLAN is permitted to pass
through the connecting port
Untagged
Access, Trunk, hybrid: not supported
voice traffic
8-2

Voice VLAN assignment Voice traffic
Port link type
mode type
Access: not supported

the connecting port belongs to the default VLAN
Tagged voice
traffic Hybrid: supported if the default VLAN of the
connecting port exists and is not the voice VLAN, the
traffice of the default VLAN is permitted to pass
through the port, and the traffic of the Voice VLAN is
permitted to pass through the connecting port tagged
Manual mode
Access: supported if the default VLAN of the
connecting port is the voice VLAN
connecting port is the voice VLAN and that the voice
Untagged
VLAN is permitted to pass through the connecting
voice traffic
port
Hybrid port: supported if the default VLAN of the
connecting port is the voice VLAN and is permitted to
pass through the connecting port untagged
If an IP phone sends tagged voice traffic and its connecting 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 connecting port, and the 802.1X Guest VLAN.
z The default VLANs for all ports are VLAN 1. You can configure the default VLAN of a port and
configure a port to permit a certain VLAN to pass through with commands. For more information,
refer to Port-Based VLAN Configuration.
z Use the display interface command to display the default VLAN of a port and the VLANs
permitted to pass through the port.
Security Mode and Normal Mode of Voice VLANs
Voice VLAN-enabled ports can operate in security mode or normal mode based on their inbound
packet filtering mechanisms.
In a safe network, you can configure the voice VLANs to operate in normal mode, thus reducing the
consumption of system resources due to source MAC addresses checking. It is recommended not to
transmit both voice packets and non-voice packets in a voice VLAN. If you have to, please ensure that
the voice VLAN security mode is disabled.
8-3

Table 8-3 How a voice VLAN-enable port processes packets in security/normal mode
Voice VLAN
Packet type Packet processing mode
working mode
Untagged packets If the source MAC address of a packet matches an OUI
Packets carrying the address configured for the device, it is forwarded in the
Security mode voice VLAN tag voice VLAN; otherwise, it is dropped.
Packets carrying Forwarded or dropped depending on whether the port

other tags allows packets of these VLANs to pass through
Untagged packets The port does not check the source MAC addresses of
inbound packets. All types of packets can be
Packets carrying the transmitted in the voice VLAN.
Normal mode voice VLAN tag
Packets carrying Forwarded or dropped depending on whether the port

other tags allows packets of these VLANs to pass through
Configuring a Voice VLAN

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

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

voice vlan security enable
security mode Enabled by default.
Optional
voice vlan mac-address oui By default, each voice VLAN
Add a recognizable OUI has default OUI addresses
mask oui-mask [ description
address configured. Refer to Table 8-1
text ]
for the default OUI addresses
of different vendors.
interface-number
8-4

Optional
Automatic voice VLAN
Configure the port to operate in assignment mode is enabled
automatic voice VLAN voice vlan mode auto by default.
assignment mode The voice VLAN assignment
modes on different ports are
independent of one another.
Required
Enable voice VLAN on the port voice vlan vlan-id enable
Not enabled by default
z An switch 4510G supports up to eight voice VLANs globally.

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 assignment mode as the
voice VLAN.
Setting a Port to Operate in Manual Voice VLAN Assignment Mode
Follow these steps to set a port to operate in manual voice VLAN assignment mode:

Enable the voice VLAN Optional

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

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

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 An switch 4510G supports up to eight voice VLANs globally.

z You can configure different voice VLANs on different ports at the same time. However, one port
can be configured with only one voice VLAN, and this voice VLAN must be a static VLAN that
already exists on the device.
z Voice VLAN is mutually exclusive with Link Aggregation Control Protocol (LACP) on a port.
z To make voice VLAN take effect on a port which is enabled with voice VLAN and operates in
manual voice VLAN assignment 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
Voice VLAN Configuration Examples

Automatic Voice VLAN Mode Configuration Example
As shown in Figure 8-1,

z The MAC address of IP phone A is 0011-1100-0001. The phone connects to a downstream device
named PC A whose MAC address is 0022-1100-0002 and to GigabitEthernet 1/0/1 on an
upstream device named Device A.
z The MAC address of IP phone B is 0011-2200-0001. The phone connects to a downstream device
named PC B whose MAC address is 0022-2200-0002 and to GigabitEthernet 1/0/2 on Device A.
z Device A uses voice VLAN 2 to transmit voice packets for IP phone A and voice VLAN 3 to
transmit voice packets for IP phone B.
Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to work in automatic voice VLAN
assignment mode. In addition, if one of them has not received any voice packet in 30 minutes, the port
is removed from the corresponding voice VLAN automatically.
8-6

Figure 8-1 Network diagram for automatic voice VLAN assignment mode configuration
Device A Device B
Internet
GE1/0/1
GE1/0/2 GE1/0/1
VLAN 2 VLAN 3
IP phone A IP phone B
010-1001 010-1002
MAC: 0011-1100-0001 MAC: 0011-2200-0001
Mask: ffff-ff00-0000 Mask: ffff-ff00-0000 0755-2002
PC A PC B
MAC: 0022-1100-0002 MAC: 0022-2200-0002
# Create VLAN 2 and VLAN 3.

[DeviceA] vlan 2 to 3
# Set the voice VLAN aging time to 30 minutes.

[DeviceA] voice vlan aging 30
# Since GigabitEthernet 1/0/1 may receive both voice traffic and data traffic at the same time, to ensure
the quality of voice packets and effective bandwidth use, configure voice VLANs to work in security
mode, that is, configure the voice VLANs to transmit only voice packets. (Optional. By default, voice
VLANs work in security mode.)
[DeviceA] voice vlan security enable
# Configure the allowed OUI addresses as MAC addresses prefixed by 0011-1100-0000 or

0011-2200-0000. In this way, Device A identifies packets whose MAC addresses match any of the
configured OUI addresses as voice packets.
[DeviceA] voice vlan mac-address 0011-1100-0001 mask ffff-ff00-0000 description IP phone A
[DeviceA] voice vlan mac-address 0011-2200-0001 mask ffff-ff00-0000 description IP phone B
# Configure GigabitEthernet 1/0/1 to operate in automatic voice VLAN assignment mode. (Optional. By
default, a port operates in automatic voice VLAN assignment mode.)
[DeviceA-GigabitEthernet1/0/1] voice vlan mode auto
# Configure GigabitEthernet 1/0/1 as a hybrid port.

[DeviceA-GigabitEthernet1/0/1] port link-type access
[DeviceA-GigabitEthernet1/0/1] port link-type hybrid
# Configure VLAN 2 as the voice VLAN for GigabitEthernet 1/0/1.

[DeviceA-GigabitEthernet1/0/1] voice vlan 2 enable
# Configure GigabitEthernet 1/0/2.

8-7

[DeviceA-GigabitEthernet1/0/2] voice vlan mode auto
[DeviceA-GigabitEthernet1/0/2] port link-type access
[DeviceA-GigabitEthernet1/0/2] port link-type hybrid
[DeviceA-GigabitEthernet1/0/2] voice vlan 3 enable
Verification
# Display the OUI addresses, OUI address masks, and description strings supported currently.
<DeviceA> display voice vlan oui
Oui Address Mask Description
0001-e300-0000 ffff-ff00-0000 Siemens phone
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
0011-1100-0000 ffff-ff00-0000 IP phone A
0011-2200-0000 ffff-ff00-0000 IP phone B
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 states of voice VLANs.

<DeviceA> display voice vlan state
Maximum of Voice VLANs: 16
Current Voice VLANs: 2
Voice VLAN security mode: Security
Voice VLAN aging time: 1440 minutes
Voice VLAN enabled port and its mode:
PORT VLAN MODE
-----------------------------------------------
GigabitEthernet1/0/1 2 AUTO
GigabitEthernet1/0/2 3 AUTO
Manual Voice VLAN Assignment Mode Configuration Example
z Create VLAN 2 and configure it as a voice VLAN permitting only voice traffic to pass through.
z The IP phones send untagged voice traffic. Configure GigabitEthernet 1/0/1 as a hybrid port.
z Configure GigabitEthernet 1/0/1 to operate in manual voice VLAN assignment mode. Configure
GigabitEthernet 1/0/1 to allow 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.
8-8

Figure 8-2 Network diagram for manual voice VLAN assignment 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 GigabitEthernet 1/0/1 to operate in manual voice VLAN assignment mode.

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

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

[DeviceA-GigabitEthernet1/0/1] voice vlan enable
Verification
# Display the OUI addresses, OUI address masks, and description strings supported currently.
<DeviceA> display voice vlan oui
Oui Address Mask Description
0001-e300-0000 ffff-ff00-0000 Siemens phone
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
8-9

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
Maximum of Voice VLANs: 16
Current Voice VLANs: 2
Voice VLAN security mode: Security
Voice VLAN aging time: 100 minutes
Voice VLAN enabled port and its mode:
PORT VLAN MODE
-----------------------------------------------
GigabitEthernet1/0/1 2 MANUAL
8-10

9 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 GVRP Configuration Task List
z Configuring GVRP Functions
z Configuring GARP Timers
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 application entity exchanges information with other GARP application entities by:
z Sending 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 Sending 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 Sending 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.
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:
9-1

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 a 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 is 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 On a GARP-enabled network, a device 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 application entity to propagate throughout
a LAN quickly. In GARP, a GARP application entity registers or deregisters its attributes with other
entities by making or withdrawing declarations of attributes and at the same time, based on received
declarations or withdrawals, handles attributes of other entities. When a port receives an attribute
declaration, it registers the attribute; when a port receives an attribute withdrawal, it deregisters the
attribute.
GARP application entities send protocol data units (PDUs) 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 will be delivered.
9-2

GARP message format
Figure 9-1 GARP message format
Figure 9-1 illustrates the GARP message format. Table 9-1 describes the GARP message fields.
Table 9-1 Description on the GARP message fields
Field Description Value

Protocol ID Protocol identifier for GARP 1
One or multiple messages, each
Message containing 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
z 0: LeaveAll event
z 1: JoinEmpty event
z 2: JoinIn event
Attribute Event Event described by the attribute
z 3: LeaveEmpty event
z 4: LeaveIn event
z 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
9-3

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
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.
GVRP Configuration Task List

Complete these tasks to configure GVRP:
Task Remarks
Configuring GVRP Functions Required
Configuring GARP Timers Optional
z GVRP configuration made in Ethernet interface view or Layer-2 aggregate interface view takes
effect on the current interface only; .GVRP configuration made in port group view takes effect on
all the member ports in the group.
z GVRP configuration made on a member port in an aggregation group takes effect only after the
port is removed from the aggregation group.
Configuring GVRP Functions

Before enabling GVRP on a port, you must enable GVRP globally.
Follow these steps to configure GVRP functions on a trunk port:
9-4

Required
Enable GVRP globally gvrp Globally disabled by
default.
Enter Ethernet Enter Ethernet
interface view, interface view or Layer interface interface-type
Layer 2 2 aggregate interface interface-number Required
aggregate view Perform either of the
interface view, commands.
or port-group Enter port-group view
port-group manual
Required
Enable GVRP on the port or port group gvrp
Disabled by default.
Configure the GVRP registration mode gvrp registration { fixed | Optional

on the port or port group forbidden | normal } The default is normal.
z GVRP can be configured only on trunk ports.

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

Among the four GARP timers, the LeaveAll timer is configured in system view and takes effect on all
ports, while the other three are configured on a port basis.
Follow these steps to configure GARP timers:

Optional
Configure the GARP LeaveAll garp timer leaveall
timer timer-value The default is 1000
centiseconds.
9-5

Enter Enter Ethernet or Required
Ethernet Layer 2 interface interface-type Perform either of the
interface aggregate interface-number commands.
view, Layer interface view
2 aggregate Depending on the view you
interface accessed, the subsequent
view, or Enter port-group port-group manual configuration takes effect on
port-group view port-group-name a port or all ports in a
view port-group.
Optional
Configure the Hold timer garp timer hold timer-value
10 centiseconds by default.
Optional
Configure the Join timer garp timer join timer-value
Optional
Configure the Leave timer garp timer leave timer-value
As shown in Table 9-2, the values of GARP timers are dependent on each other:
z If you want to set a value beyond the value range for a timer, you may change the value range by
tuning the value of another related timer.
z If you want to restore the default settings of the timers, restore the Hold timer first, and then the
Join, Leave, and LeaveAll timers.
Table 9-2 Dependencies of GARP timers
Timer Lower limit Upper limit

No greater than half of the Join timer
Hold 10 centiseconds
setting
No less than two times the Hold timer
Join Less than half of the leave timer setting
setting
Greater than two times the Join timer
Leave Less than the LeaveAll timer setting
setting
LeaveAll Greater than the Leave timer setting 32765 centiseconds
Displaying and Maintaining GVRP

display garp statistics [ interface
Display statistics about GARP Available in any view
interface-list ]
Display GARP timers for specified display garp timer [ interface
or all ports interface-list ]
Display the local VLAN display gvrp local-vlan interface
information maintained by GVRP interface-type interface-number
9-6

display gvrp state interface
Display the current GVRP state interface-type interface-number vlan Available in any view
vlan-id
display gvrp statistics [ interface
Display statistics about GVRP Available in any view
interface-list ]
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 [ interface
Clear the GARP statistics Available in user view
interface-list ]
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.
Figure 9-2 Network diagram for GVRP configuration
# Enable GVRP globally.
[DeviceA] gvrp
# Configure port GigabitEthernet 1/0/1 as a trunk port, allowing all VLANs to pass through.
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan all
# Enable GVRP on trunk port GigabitEthernet 1/0/1.

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

[DeviceA] vlan 2
9-7

[DeviceB] gvrp
[DeviceB-GigabitEthernet1/0/1] port link-type trunk
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan all
# Enable GVRP on trunk port GigabitEthernet 1/0/1.

[DeviceB-GigabitEthernet1/0/1] gvrp

[DeviceB] vlan 3
# 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
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.
[DeviceA] gvrp
# Enable GVRP on GigabitEthernet 1/0/1 and set the GVRP registration type to fixed on the port.
[DeviceA-GigabitEthernet1/0/1] gvrp registration fixed
9-8


[DeviceA] vlan 2
[DeviceB] gvrp
# Enable GVRP on GigabitEthernet 1/0/1.


[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.
[DeviceA] gvrp
9-9

# Enable GVRP on GigabitEthernet 1/0/1 and set the GVRP registration type to forbidden on the port.
[DeviceA-GigabitEthernet1/0/1] gvrp registration forbidden

[DeviceA] vlan 2
[DeviceB] gvrp
# Enable GVRP on GigabitEthernet 1/0/1.


[DeviceB] vlan 3

9-10

10 QinQ Configuration
When configuring QinQ, go to these sections for information you are interested in:
z Introduction to QinQ
z QinQ Configuration Task List
z Configuring Basic QinQ
z Configuring Selective QinQ
z Configuring the TPID Value in VLAN Tags
z QinQ Configuration Examples
Throughout this document, customer network VLANs (CVLANs), also called inner VLANs, refer to the
VLANs that a customer uses on the private network; and service provider network VLANs (SVLANs),
also called outer VLANs, refer to the VLANs that a service provider uses to carry VLAN tagged traffic
for customers.
Introduction to QinQ
Background
In the VLAN tag field defined in IEEE 802.1Q, only 12 bits are used for VLAN IDs, so a device can
support a maximum of 4094 VLANs. In actual applications, however, a large number of VLANs are
required to isolate users, especially in metropolitan area networks (MANs), and 4094 VLANs are far
from satisfying such requirements.
QinQ Mechanism and Benefits
The QinQ feature is a flexible, easy-to-implement Layer 2 VPN technique. It enables the edge device
on the service provider network to encapsulate an outer VLAN tag in Ethernet frames from customer
networks (private networks), so that the Ethernet frames will travel across the service provider network
(public network) with double VLAN tags. QinQ enables a service provider to use a single SVLAN to
serve customers who have multiple CVLANs.
The devices in the public network forward a frame only according to its outer VLAN tag and learn its
source MAC address into the MAC address table of the outer VLAN. The inner VLAN tag of the frame
is transmitted as the payload.
10-1

Figure 10-1 Schematic diagram of the QinQ feature
Customer network A
VLAN 1~10
Customer network A
VLAN 1~10
VLAN 3 VLAN 3
Network
VLAN 4 VLAN 4
Service provider network
VLAN 1~20 VLAN 1~20
Customer network B Customer network B
As shown in Figure 10-1, customer network A has CVLANs 1 through 10, while customer network B
has CVLANs 1 through 20. The SVLAN allocated by the service provider for customer network A is
SVLAN 3, and that for customer network B is SVLAN 4. When a tagged Ethernet frame of customer
network A enters the service provider network, it is tagged with outer VLAN 3; when a tagged Ethernet
frame of customer network B enters the service provider network, it is tagged with outer VLAN 4. In this
way, there is no overlap of VLAN IDs among customers, and traffic from different customers does not
become mixed.
By tagging tagged frames, QinQ expands the available VLAN space from 4094 to 4094 4094 and
thus satisfies the requirement for VLAN space in MAN. It mainly addresses the following issues:
z Releases the stress on the SVLAN resource.
z Enables customers to plan their CVLANs without conflicting with SVLANs.
z Provides an easy-to-implement Layer 2 VPN solution for small-sized MANs or intranets.
QinQ Frame Structure
A QinQ frame is transmitted double-tagged over the service provider network. The inner VLAN tag is
the CVLAN tag while the outer one is the SVLAN tag that the service provider has allocated to the
customer. Figure 10-2 shows the structure of single-tagged and double-tagged Ethernet frames.
10-2

Figure 10-2 Single-tagged frame structure vs. double-tagged Ethernet frame structure
The default maximum transmission unit (MTU) of an interface is 1500 bytes. The size of an outer
VLAN tag is 4 bytes. Therefore, you are recommended to increase the MTU of each interface on the
service provider network. The recommended minimum MTU is 1504 bytes.
Implementations of QinQ
There are two types of QinQ implementations: basic QinQ and selective QinQ.
1) Basic QinQ
Basic QinQ is a port-based feature. When a frame arrives at a basic QinQ-enabled port, the port tags it
with the ports default VLAN tag, regardless of whether the frame is tagged or untagged. If the received
frame is already tagged, it becomes a double-tagged frame; if it is untagged, it becomes a frame
tagged with the ports default VLAN tag.
2) Selective QinQ
Selective QinQ is a more flexible, VLAN-based implementation of QinQ. In addition to all the functions
of basic QinQ, selective QinQ can tag frames with different outer VLAN tags based on different inner
VLAN IDs.
Modifying the TPID in a VLAN Tag
A VLAN tag uses the tag protocol identifier (TPID) field to identify the protocol type of the tag. The
value of this field, as defined in IEEE 802.1Q, is 0x8100.
0 shows the 802.1Q-defined tag structure of an Ethernet frame.
10-3

Figure 10-3 VLAN tag structure of an Ethernet frame
The device determines whether a received frame carries a SVLAN tag or a CVLAN tag by checking the
corresponding TPID value. Upon receiving a frame, the device compares the configured TPID value
with the value of the TPID field in the frame. If the two match, the devices considers that the frame
carries the VLAN tag. For example, if a frame carries a VLAN tag with the TPID value 0x9100 while the
configured TPID value of the VLAN tag is 0x8100, the device considers that the frame carries no VLAN
tag.
In addition, the systems of different vendors may set the TPID of the outer VLAN tag of QinQ frames to
different values. For compatibility with these systems, you can modify the TPID value so that the QinQ
frames, when sent to the public network, carry the TPID value identical to the value of a particular
vendor to allow interoperability with the devices of that vendor.
The TPID in an Ethernet frame has the same position with the protocol type field in a frame without a
VLAN tag. To avoid problems in packet forwarding and handling in the network, you cannot set the
TPID value to any of the values in the table below.
Table 10-1 Reserved protocol type values
Protocol type Value

ARP 0x0806
PUP 0x0200
RARP 0x8035
IP 0x0800
IPv6 0x86DD
PPPoE 0x8863/0x8864
MPLS 0x8847/0x8848
IPX/SPX 0x8137
IS-IS 0x8000
LACP 0x8809
802.1x 0x888E
Cluster 0x88A7
Reserved 0xFFFD/0xFFFE/0xFFFF
10-4

QinQ Configuration Task List
Table 10-2 QinQ configuration task list
Configuration task Remarks

Configuring Basic QinQ Optional
Configuring Selective QinQ Based on Ports
Use either
Configuring Selective QinQ Configuring Selective QinQ through QoS approach
Policies
Configuring the TPID Value in VLAN Tags Optional
z QinQ requires configurations only on the service provider network, not on the customer network.
z QinQ configurations made in Ethernet interface view take effect on the current interface only;
those made in Layer-2 aggregate interface view take effect on the current aggregate interface and
all the member ports in the aggregation group; those made in port group view take effect on all
member ports in the current port group.
z Basic and selective QinQ should both be configured on the ports connecting customer networks.
z Do not configure QinQ on a reflector port. For information about reflector ports, refer to Port
Mirroring Configuration in the Access Volume.
Configuring Basic QinQ

Enabling Basic QinQ
Follow these steps to enable basic QinQ:

Enter Ethernet or
Layer-2 aggregate
interface interface-number Required
interface view
group view Enter port group view
port-group manual
port-group-name
Required
Enable QinQ on the port(s) qinq enable
Configuring Selective QinQ

You can configure selective QinQ in one of the following two approaches:
z Configuring selective QinQ based on ports
z Configuring selective QinQ through QoS policies
10-5

The two approaches can achieve the same result. If two approaches are both used to configure
different outer VLAN tagging policies on the same port, the outer VLAN tagging policy configured in the
QoS policy approach takes effect.
Configuring Selective QinQ Based on Ports
Switch 4510G series switches support the configuration of basic QinQ and selective QinQ at the same
time on a port and when the two features are both enabled on the port, frames that meet the selective
QinQ condition are handled with selective QinQ on this port first, and the left frames are handled with
basic QinQ.
Follow these steps to configure an outer VLAN tagging policy:

Enter
Ethernet or
Enter interface Layer-2
view or port aggregate
group view interface view Use either command
Required
Enter QinQ view and configure
the SVLAN tag for the port to qinq vid vlan-id By default, the SVLAN tag to
add be added is the default VLAN
tag of the receiving port.
Tag frames of the specified raw-vlan-id inbound { all |
Required
CVLANs with the current SVLAN vlan-list }
z An inner VLAN tag corresponds to only one outer VLAN tag.

z If you want to change an outer VLAN tag, you must delete the old outer VLAN tag configuration
and configure a new outer VLAN tag.
Configuring Selective QinQ through QoS Policies
The Switch 4510G series switches support configuring selective QinQ through QoS policies. To
implement adding outer VLAN tags according to inner VLAN tags, you can configure a class to match
packets with the specified inner VLAN tags, configure an outer VLAN tagging behavior, associate the
class with the behavior in a QoS policy, and then apply the QoS policy to the port connecting to users.
Follow these steps to configure an outer VLAN tagging policy though QoS policies:

10-6

Required
Create a class and enter traffic classifier classifier-name By default, the relationship
class view [ operator { and | or } ] between the match criteria in a
class is logical AND.
Specify the inner VLAN if-match customer-vlan-id
Required
ID(s) of matching frames vlan-id-list
Create a traffic behavior

and enter traffic behavior traffic behavior behavior-name Required
view
Specify an outer VLAN ID nest top-most vlan-id vlan-id Required
Create a QoS policy and

qos policy policy-name Required
enter QoS policy view
Associate the traffic class
classifier classifier-name behavior
with the traffic behavior Required
behavior-name
defined earlier
Enter
Ethernet
Enter the port view
Ethernet port or Layer 2
interface-number
view of the aggregate Enter the Ethernet port view of
customer interface the customer network-side port
network-side view
port Enter port
port-group { manual
group
port-group-name }
view
Enable basic QinQ qing enable Required
Apply the QoS policy in qos apply policy policy-name

Required
the inbound direction inbound
z For detailed information about QoS policies, refer to the part talking about QoS in the QoS
Volume.
z By configuring different match criteria, you can add outer VLAN tags to packets more flexibly. For
example, you can add an outer VLAN tag to packets with the specified source IP/source MAC,
add different outer VLAN tags to packets of different protocols (matched through ACL), or add
different outer VLAN tags to packets with different priorities.
Configuring the TPID Value in VLAN Tags

You can configure the TPID value in VLAN tags in system view, where the configuration takes effect on
all ports of the device.
10-7

Follow these steps to configure a TPID value globally:

Configure the TPID value in the qinq ethernet-type Optional

CVLAN tag or the SVLAN tag hex-value By default, the TPID value is 0x8100
QinQ Configuration Examples

Basic QinQ Configuration Example

z Provider A and Provider B are edge devices on the service provider network and are
interconnected through trunk ports. They belong to SVLAN 10 and 50.
z Customer A1, Customer A2, Customer B1 and Customer B2 are edge devices on the customer
network.
z Third-party devices with a TPID value of 0x8200 are deployed between Provider A and Provider
B.
Make configuration to achieve the following:
z Frames of VLAN 200 through VLAN 299 can be exchanged between Customer A1 and Customer
A2 through VLAN 10 of the service provider network.
z Frames of VLAN 250 through VLAN 350 can be exchanged between Customer B1 and Customer
B2 through VLAN 50 of the service provider network.
Figure 10-4 Network diagram for VLAN transparent transmission configuration
10-8

Make sure that the devices in the service provider network have been configured to allow QinQ
packets to pass through.
1) Configuration on Provider A
z Configure GigabitEthernet 1/0/1
# Configure VLAN 10 as the default VLAN of GigabitEthernet 1/0/1.
<ProviderA> system-view
[ProviderA] interface gigabitethernet 1/0/1
[ProviderA-GigabitEthernet1/0/1] port access vlan 10
# Enable basic QinQ on GigabitEthernet 1/0/1.

[ProviderA-GigabitEthernet1/0/1] qinq enable
[ProviderA-GigabitEthernet1/0/1] quit
# Configure GigabitEthernet 1/0/2 as a hybrid port and configure VLAN 50 as the default VLAN of the
port.
[ProviderA-GigabitEthernet1/0/2] port link-type hybrid
[ProviderA-GigabitEthernet1/0/2] port hybrid pvid vlan 50
[ProviderA-GigabitEthernet1/0/2] port hybrid vlan 50 untagged

# Configure GigabitEthernet 1/0/3 as a trunk port to permit frames of VLAN 10 and 50 to pass through.
[ProviderA-GigabitEthernet1/0/3] port link-type trunk
[ProviderA-GigabitEthernet1/0/3] port trunk permit vlan 10 50
# Set the TPID value in the outer tag to 0x8200.

[ProviderA] qinq ethernet-type 8200
2) Configuration on Provider B
# Configure VLAN 50 as the default VLAN of GigabitEthernet 1/0/1.
<ProviderB> system-view
[ProviderB] interface gigabitethernet 1/0/1
[ProviderB-GigabitEthernet1/0/1] port access vlan 50

[ProviderB-GigabitEthernet1/0/1] qinq enable
[ProviderB-GigabitEthernet1/0/1] quit
10-9

# Configure GigabitEthernet 1/0/2 as a hybrid port and configure VLAN 10 as the default VLAN of the
port.
[ProviderB-GigabitEthernet1/0/2] port link-type hybrid
[ProviderB-GigabitEthernet1/0/2] port hybrid pvid vlan 10
[ProviderB-GigabitEthernet1/0/2] port hybrid vlan 10 untagged

# Configure GigabitEthernet 1/0/3 as a trunk port to permit frames of VLAN 10 and 50 to pass through.
[ProviderA-GigabitEthernet1/0/B] port link-type trunk
[ProviderA-GigabitEthernet1/0/B] port trunk permit vlan 10 50

[ProviderB] qinq ethernet-type 8200
3) Configuration on third-party devices
Configure the third-party devices between Provider A and Provider B as follows: configure the port
connecting GigabitEthernet 1/0/3 of Provider A and that connecting GigabitEthernet 1/0/3 of Provider B
to allow tagged frames of VLAN 10 and 50 to pass through.
Selective QinQ Configuration Example (Port-Based Configuration)

z Provider A and Provider B are edge devices on the service provider network and are
interconnected through trunk ports. They belong to SVLAN 1000 and SVLAN 2000 separately.
z Customer A, Customer B and Customer C are edge devices on the customer network.
z Third-party devices with a TPID value of 0x8200 are deployed between Provider A and Provider
B.
Make configuration to achieve the following:
z VLAN 10 frames of Customer A and Customer B can be forwarded to each other across SVLAN
1000;
z VLAN 20 frames of Customer A and Customer C can be forwarded to each other across SVLAN
2000.
10-10

Figure 10-5 Network diagram for comprehensive selective QinQ configuration
# Configure GigabitEthernet 1/0/1 as a hybrid port to permit frames of VLAN 1000 and VLAN 2000 to
pass through, and configure GigabitEthernet 1/0/1 to send packets of these VLANs with tags removed.
[ProviderA-GigabitEthernet1/0/1] port hybrid vlan 1000 2000 untagged
# Tag CVLAN 10 frames with SVLAN 1000.

[ProviderA-GigabitEthernet1/0/1] qinq vid 1000
[ProviderA-GigabitEthernet1/0/1-vid-1000] raw-vlan-id inbound 10
[ProviderA-GigabitEthernet1/0/1-vid-1000] quit

# Configure GigabitEthernet 1/0/2 as a hybrid port to permit frames of VLAN 1000 to pass through, and
configure GigabitEthernet 1/0/2 to send packets of VLAN 1000 with tag removed.
10-11

[ProviderA-GigabitEthernet1/0/2] port hybrid vlan 1000 untagged

# Configure GigabitEthernet 1/0/3 as a trunk port to permit frames of VLAN 1000 and VLAN 2000 to
pass through.
[Sysname-GigabitEthernet1/0/3] port trunk permit vlan 1000 2000

# Configure GigabitEthernet 1/0/1 as a trunk port to permit frames of VLAN 1000 and VLAN 2000 to
pass through.
[ProviderB-GigabitEthernet1/0/1] port link-type trunk
[ProviderB-GigabitEthernet1/0/1] port trunk permit vlan 1000 2000
# Configure GigabitEthernet 1/0/2 as a hybrid port to permit frames of VLAN 2000 to pass through, and
configure GigabitEthernet 1/0/2 to send packets of VLAN 2000 with tag removed.
[ProviderB-GigabitEthernet1/0/2] port link-type hybrid
[ProviderB-GigabitEthernet1/0/2] port hybrid vlan 2000 untagged

[ProviderB-GigabitEthernet1/0/2] qinq vid 2000
[ProviderB-GigabitEthernet1/0/2-vid-2000] raw-vlan-id inbound 20

3) Configuration on third-party devices
Configure the third-party devices between Provider A and Provider B as follows: configure the port
connecting GigabitEthernet 1/0/3 of Provider A and that connecting GigabitEthernet 1/0/1 of Provider B
to allow tagged frames of VLAN 1000 and VLAN 2000 to pass through.
10-12

Selective QinQ Configuration Example (QoS Policy-Based Configuration)

z Provider A and Provider B are service provider network access devices.
z Customer A, Customer B, Customer C, and Customer D are customer network access devices.
z Provider A and Provider B are interconnected through a trunk port, which permits the frames of
VLAN 1000, VLAN 2000, and VLAN 3000 to pass through.
z Third-party devices are deployed between Provider A and Provider B, with a TPID value of
0x8200.
The expected result of the configuration is as follows:
z VLAN 10 of Customer A and Customer B can intercommunicate across VLAN 1000 on the public
network.
z VLAN 20 of Customer A and Customer C can intercommunicate across VLAN 2000 on the public
network.
z Frames of the VLANs other than VLAN 10 and VLAN 20 of Customer A can be forwarded to
Customer D across VLAN 3000 on the public network.
Figure 10-6 Network diagram for basic QinQ configuration
# Enter system view.
10-13

z Configuration on GigabitEthernet 1/0/1
# Configure the port as a hybrid port permitting frames of VLAN 1000, VLAN 2000, and VLAN 3000 to
pass through with the outer VLAN tag removed.
[ProviderA-GigabitEthernet1/0/1] port hybrid vlan 1000 2000 3000 untagged
# Configure VLAN 3000 as the default VLAN of GigabitEthernet 1/0/1, and enable basic QinQ on
GigabitEthernet 1/0/1. As a result, the frames received on the port are tagged with the outer VLAN tag
3000.
[ProviderA-GigabitEthernet1/0/1] port hybrid pvid vlan 3000
# Create a class A10 to match frames of VLAN 10 of Customer A.

[ProviderA] traffic classifier A10
[ProviderA-classifier-A10] if-match customer-vlan-id 10
[ProviderA-classifier-A10] quit
# Create a traffic behavior P1000 and configure the action of tagging frames with the outer VLAN tag
1000 for the traffic behavior.
[ProviderA] traffic behavior P1000
[ProviderA-behavior-P1000] nest top-most vlan-id 1000
[ProviderA-behavior-P1000] quit
# Create a class A20 to match frames of VLAN 20 of Customer A.

[ProviderA] traffic classifier A20
[ProviderA-classifier-A20] if-match customer-vlan-id 20
[ProviderA-classifier-A20] quit
# Create a traffic behavior P2000 and configure the action of tagging frames with the outer VLAN tag
2000 for the traffic behavior.
[ProviderA] traffic behavior P2000
[ProviderA-behavior-P2000] nest top-most vlan-id 2000
[ProviderA-behavior-P2000] quit
# Create a QoS policy qinq. Associate the class A10 with the traffic behavior P1000, and associate the
class A20 with the traffic behavior P2000 in the QoS policy qinq.
[ProviderA] qos policy qinq
[ProviderA-qospolicy-qinq] classifier A10 behavior P1000
[ProviderA-qospolicy-qinq] classifier A20 behavior P2000
[ProviderA-qospolicy-qinq] quit
# Apply the QoS policy qinq in the inbound direction of GigabitEthernet 1/0/1.
[ProviderA] interface GigabitEthernet 1/0/1
[ProviderA-GigabitEthernet1/0/1] qos apply policy qinq inbound
# Configure VLAN 1000 as the default VLAN.
10-14

[ProviderA-GigabitEthernet1/0/2] port access vlan 1000
# Enable basic QinQ. Tag frames from VLAN 10 with the outer VLAN tag 1000.
z Configuration on GigabitEthernet 1/0/3.
# Configure the port as a trunk port permitting frames of VLAN 1000, VLAN 2000 and VLAN 3000 to
pass through.
[ProviderA-GigabitEthernet1/0/3] port trunk permit vlan 1000 2000 3000
# To enable interoperability with the third-party devices in the public network, set the TPID of the
service provider network VLAN tags to 0x8200. Therefore, the port tags the frames with the outer
VLAN tag whose TPID is 0x8200.
# Configure the port as a trunk port permitting frames of VLAN 1000, VLAN 2000 and VLAN 3000 to
pass through.
[ProviderB-GigabitEthernet1/0/1] port link-type trunk
[ProviderB-GigabitEthernet1/0/1] port trunk permit vlan 1000 2000 3000
# To enable interoperability with the third-party devices in the public network, set the TPID of the
service provider network VLAN tags to 0x8200. Therefore, the port tags the received frames with the
outer VLAN tag whose TPID is 0x8200.
[ProviderB] qinq ethernet-type 8200
[ProviderB] interface GigabitEthernet 1/0/2
# Enable basic QinQ. Tag frames from VLAN 20 with the outer VLAN tag 2000.
[ProviderB] interface GigabitEthernet 1/0/3
# Enable basic QinQ to tag frames of all customer VLANs with the outer VLAN tag 3000.
3) Configuration on devices on the public network
10-15

As third-party devices are deployed between Provider A and Provider B, what we discuss here is only
the basic configuration that should be made on the devices. Configure that device connecting with
GigabitEthernet 1/0/3 of Provider A and the device connecting with GigabitEthernet 1/0/1 of Provider B
so that their corresponding ports send tagged frames of VLAN 1000, VLAN 2000 and VLAN 3000. The
configuration steps are omitted here.
10-16

11 BPDU Tunneling Configuration
When configuring BPDU tunneling, go to these sections for information you are interested in:
z Introduction to BPDU Tunneling
z Configuring BPDU Tunneling
z BPDU Tunneling Configuration Examples
Introduction to BPDU Tunneling

As a Layer 2 tunneling technology, BPDU tunneling enables Layer 2 protocol packets from
geographically dispersed customer networks to be transparently transmitted over specific channels
across a service provider network.
Background
Customers usually use dedicated lines in a service provider network to build their own Layer 2
networks. As a result, very often, a customer network is broken down into parts located at different
sides of the service provider network. As shown in Figure 11-1, User A has two devices: CE 1 and CE 2,
both of which belong to VLAN 100. User As network is divided into network 1 and network 2, which are
connected by the service provider network. When Layer 2 protocol packets cannot be transparently
transmitted in the service provider network, User As network cannot implement independent Layer 2
protocol calculation (for example, STP spanning tree calculation). In this case, the Layer 2 protocol
calculation in User As network is mixed with that in the service provider network.
Figure 11-1 BPDU tunneling application scenario
PE 1 PE 2
ISP network
CE 1 CE 2
User A network 1 User A network 2

VLAN 100 VLAN 100
With BPDU tunneling, Layer 2 protocol packets from customer networks can be transparently
transmitted in the service provider network:
2) After receiving a Layer 2 protocol packet from User A network 1, PE 1 in the service provider
network encapsulates the packet, replaces its destination MAC address with a specific multicast
MAC address, and then forwards the packet in the service provider network;
3) The encapsulated Layer 2 protocol packet (called bridge protocol data unit, BPDU) is forwarded to
PE 2 at the other end of the service provider network, which decapsulates the packet, restores the
original destination MAC address of the packet, and then sends the packet to User A network 2.
11-1

Depending on the device models, BPDU tunneling may support the transparent transmission of these
types of Layer 2 protocol packets:
z Cisco Discovery Protocol (CDP)
z Device Link Detection Protocol (DLDP)
z Ethernet Operation, Administration and Maintenance (EOAM)
z GARP VLAN Registration Protocol (GVRP)
z HW Group Management Protocol (HGMP)
z Link Aggregation Control Protocol (LACP)
z Link Layer Discovery Protocol (LLDP)
z Port Aggregation Protocol (PAGP)
z Per VLAN Spanning Tree (PVST)
z Spanning tree protocol (STP)
z Uni-directional Link Direction (UDLD)
z VLAN Trunking Protocol (VTP)
BPDU Tunneling Implementation
The BPDU tunneling implementations for different protocols are all similar. This section describes how
BPDU tunneling is implemented by taking the Spanning Tree Protocol (STP) as an example.
z The term STP in this document is in a broad sense. It includes STP, RSTP, and MSTP.
z STP calculates the topology of a network by transmitting BPDUs among devices in the network.
For details, refer to MSTP Configuration in the Access Volume.
To avoid loops in your network, you can enable STP on your devices. When the topology changes at
one side of the customer network, the devices at this side of the customer network send BPDUs to
devices on the other side of the customer network to ensure consistent spanning tree calculation in the
whole customer network. However, because BPDUs are Layer 2 packets, all STP-enabled devices,
both in the customer network and in the service provider network, can receive and process these
BPDUs. In this case, neither the service provider network nor the customer network can correctly
calculate its independent spanning tree.
To allow each network to calculate an independent spanning tree with STP, BPDU tunneling was
introduced.
BPDU tunneling delivers the following benefits:
z BPDUs can be transparently transmitted. BPDUs of the same customer network can be broadcast
in a specific VLAN across the service provider network, so that the geographically dispersed
11-2

networks of the same customer can implement consistent spanning tree calculation across the
service provider network.
z BPDUs of different customer networks can be confined within different VLANs for transmission on
the service provider network. Thus, each customer network can perform independent spanning
tree calculation.
Figure 11-2 Network diagram for BPDU tunneling implementation
PE 1 ISP network PE 2
BPDU tunnel
CE 1 CE 2
User A network 1 User A network 2
As shown in Figure 11-2, the upper part is the service provider network (ISP network), and the lower
part represents two different parts of a customer network: User A network 1 and User A network 2.
Enabling the BPDU tunneling function on the edge devices (PE 1 and PE 2) in the service provider
network allows BPDUs of the customer network to be transparently transmitted in the service provider
network, thus ensuring consistent spanning tree calculation of User A network, without affecting the
spanning tree calculation of the service provider network.
Assume a BPDU is sent from User A network 1 to User A network 2:
z At the ingress of the service provider network, PE 1 changes the destination MAC address of the
BPDU from 0x0180-C200-0000 to a special multicast MAC address, 0x010F-E200-0003 (the
default multicast MAC address) for example. In the service provider network, the modified BPDU
is forwarded as a data packet in the VLAN assigned to User A.
z At the egress of the service provider network, PE 2 recognizes the BPDU with the destination
MAC address 0x010F-E200-0003, restores its original destination MAC address
0x0180-C200-0000, and then sends the BPDU to User A network 2.
Make sure, through configuration, that the VLAN tags carried in BPDUs are neither changed nor
removed during the transparent transmission in the service provider network; otherwise, the devices in
the service provider network will fail to transparently transmit the customer network BPDUs correctly.
Configuring BPDU Tunneling

z Before configuring BPDU tunneling for a protocol, enable the protocol in the customer network
first.
11-3

z Assign the port on which you want to enable BPDU tunneling on the PE device and the connected
port on the CE device to the same VLAN.
z Configure all the ports in the service provider network as trunk ports allowing packets of any VLAN
to pass through.
Enabling BPDU Tunneling
You can enable BPDU tunneling for different protocols in different views.
z Settings made in Ethernet interface view or Layer 2 aggregate interface view take effect only on
the current port; settings made in port group view take effect on all ports in the port group.
z Before enabling BPDU tunneling for DLDP, EOAM, GVRP, HGMP, LLDP, or STP on a port,
disable the protocol on the port first. Because PVST is a special STP protocol, before enabling
BPDU tunneling for PVST on a port, you need to disable STP and then enable BPDU tunneling for
STP on the port first.
z Before enabling BPDU tunneling for LACP on a dynamic aggregation group member port, remove
the port from the dynamic aggregation group first.
Enabling BPDU tunneling for a protocol in Ethernet interface view or port group view
Follow these steps to enable BPDU tunneling for a protocol in Ethernet interface view or port group
view:

interface
view or port Enter port group port-group manual Use either command
group view view port-group-name
bpdu-tunnel dot1q { cdp | Required

Enable BPDU tunneling for a dldp | eoam | gvrp | hgmp |
protocol lacp | lldp | pagp | pvst | stp | By default, BPDU tunneling for a
udld | vtp } protocol is disabled.
Enabling BPDU tunneling for a protocol in Layer 2 aggregate interface view
Follow these steps to enable BPDU tunneling for a protocol in Layer 2 aggregate interface view:

interface
Enter Layer 2 aggregate interface
bridge-aggregation
view
interface-number
11-4

Enable BPDU tunneling for a bpdu-tunnel dot1q { cdp | Required

protocol on the Layer 2 aggregate gvrp | hgmp | pvst | stp | By default, BPDU tunneling for
interface vtp } a protocol is disabled.
Configuring Destination Multicast MAC Address for BPDUs
By default, the destination multicast MAC address for BPDUs is 0x010F-E200-0003. You can change it
to 0x0100-0CCD-CDD0, 0x0100-0CCD-CDD1 or 0x0100-0CCD-CDD2 through the following
configuration.
Follow these steps to configure destination multicast MAC address for BPDUs:

Configure the destination multicast bpdu-tunnel tunnel-dmac Optional

MAC address for BPDUs mac-address 0x010F-E200-0003 by default.
For BPDUs to be recognized, the destination multicast MAC addresses configured for BPDU tunneling
must be the same on the edge devices on the service provider network.
BPDU Tunneling Configuration Examples

BPDU Tunneling for STP Configuration Example

z CE 1 and CE 2 are edges devices on the geographically dispersed network of User A; PE 1 and
PE 2 are edge devices on the service provider network.
z All ports used to connect devices in the service provider network are trunk ports and allow packets
of any VLAN to pass through.
z MSTP is enabled on User As network.
It is required that, after the configuration, CE 1 and CE 2 implement consistent spanning tree
calculation across the service provider network, and that the destination multicast MAC address
carried in BPDUs be 0x0100-0CCD-CDD0.
11-5

Figure 11-3 Network diagram for configuring BPDU tunneling for STP
1) Configuration on PE 1
# Configure the destination multicast MAC address for BPDUs as 0x0100-0CCD-CDD0.
<PE1> system-view
[PE1] bpdu-tunnel tunnel-dmac 0100-0ccd-cdd0
# Create VLAN 2 and assign GigabitEthernet 1/0/1 to VLAN 2.

[PE1] vlan 2
[PE1-vlan2] quit
[PE1] interface gigabitethernet 1/0/1
[PE1-GigabitEthernet1/0/1] port access vlan 2
# Disable STP on GigabitEthernet 1/0/1, and then enable BPDU tunneling for STP on it.
[PE1-GigabitEthernet1/0/1] undo stp enable
[PE1-GigabitEthernet1/0/1] bpdu-tunnel dot1q stp
<PE2> system-view
# Create VLAN 2 and assign GigabitEthernet 1/0/2 to VLAN 2.

[PE2] vlan 2
[PE2-vlan2] quit
[PE2-GigabitEthernet1/0/2] port access vlan 2
# Disable STP on GigabitEthernet 1/0/2, and then enable BPDU tunneling for STP on it.
BPDU Tunneling for PVST Configuration Example

z CE 1 and CE 2 are edges devices on the geographically dispersed network of User A; PE 1 and
PE 2 are edge devices on the service provider network.
11-6

z All ports used to connect devices in the service provider network are trunk ports and allow packets
of any VLAN to pass through.
z PVST is enabled for VLANs 1 through 4094 on User As network. It is required that, after the
configuration, CE 1 and CE 2 implement consistent PVST calculation across the service provider
network, and that the destination multicast MAC address carried in BPDUs be
0x0100-0CCD-CDD0.
Figure 11-4 Network diagram for configuring BPDU tunneling for PVST
<PE1> system-view
# Configure GigabitEthernet 1/0/1 as a trunk port and assign it to all VLANs.

[PE1-GigabitEthernet1/0/1] port link-type trunk
[PE1-GigabitEthernet1/0/1] port trunk permit vlan all
# Disable STP on GigabitEthernet 1/0/1, and then enable BPDU tunneling for STP and PVST on it.
[PE1-GigabitEthernet1/0/1] bpdu-tunnel dot1q pvst
<PE2> system-view
# Configure GigabitEthernet 1/0/2 as a trunk port and assign it to all VLANs.

[PE2-GigabitEthernet1/0/2] port link-type trunk
[PE2-GigabitEthernet1/0/2] port trunk permit vlan all
# Disable STP on GigabitEthernet 1/0/2, and then enable BPDU tunneling for STP and PVST on it.
[PE2-GigabitEthernet1/0/2] bpdu-tunnel dot1q pvst
11-7

12 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
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/VLAN 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.
Implementing Port Mirroring
Port mirroring is implemented through port mirroring groups. There are three types of mirroring groups:
local, remote source, and remote destination.
The following subsections describe how local port mirroring and remote port mirroring are
implemented.
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.
12-1

As shown in Figure 12-1, packets on the mirroring port are mirrored to the monitor port for the data
monitoring device to analyze.
Figure 12-1 Local port mirroring implementation
How the device processes packets
Traffic
mirrored to
Mirroring port Monitor port
Monitor port
Mirroring port
Data monitoring device
PC
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 Figure 12-2.
Figure 12-2 Remote port mirroring implementation
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.
12-2

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.
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.
To make the port mirroring function work properly, before configuring bidirectional traffic mirroring on a
port in a mirroring group, you need to use the mac-address mac-learning disable command on the
source device, intermediate devices, and destination device to disable the MAC address learning
function for the remote port mirroring VLAN. For more information about the mac-address
mac-learning disable command, refer to MAC Address Table Management Commands in the
System Volume.
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 You can configure
{ both | inbound | outbound } mirroring ports in a
interface interface-type mirroring group.
interface-number In system view, you can
Configure configure a list of
[ mirroring-group groupid ] mirroring ports to the
mirroring
mirroring-port { both | inbound | mirroring group at a time.
ports
In interface view outbound }
In interface view, you can
assign only the current
port to the mirroring
quit group. To monitor
multiple ports, repeat the
step.
Configure mirroring-group groupid Required
In system view
the monitor-port monitor-port-id Use either approach.
monitor
port interface interface-type
In interface view
interface-number
12-3

[ mirroring-group groupid ]
monitor-port
z A local port mirroring group takes effect only after its mirroring and monitor ports are configured.
z To ensure operation of your device, do not enable STP, MSTP, or RSTP on the monitor port.
z A port mirroring group can have multiple mirroring ports, but only one monitor port.
z A mirroring or monitor port to be configured cannot belong to an existing port mirroring group.
z You are recommended to use a monitor port only for port mirroring. This is to ensure that the data
monitoring device receives and analyzes only the mirrored traffic rather than a mix of mirrored
traffic and normally forwarded traffic.
Configuring Remote Port Mirroring

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.
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 the Source Device)
A remote source mirroring group comprises the following:

z One or multiple mirroring ports.
z A remote probe VLAN.
z An egress 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.
Configuring a remote source mirroring group with an egress port
Follow these steps to configure a remote port mirroring group with an egress port:
12-4

Create a remote source mirroring-group groupid

Required
mirroring group remote-source
mirroring-group groupid Required
In system view mirroring-port mirroring-port-list You configure multiple
{ both | inbound | outbound } mirroring ports in a
interface interface-type mirroring group.
interface-number In system view, you can
Configure assign a list of mirroring
mirroring [ mirroring-group groupid ] ports to the mirroring
ports In interface mirroring-port { both | inbound | group at a time.
view outbound }
In interface view, you can
assign only the current
interface to the mirroring
quit group. To monitor multiple
ports, repeat the step.
mirroring-group groupid
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 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 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.
z A remote port mirroring group can have only one egress port.
12-5

z 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.
z You are recommended to use a remote probe VLAN exclusively for the mirroring purpose.
z A port can belong to only one mirroring group. A VLAN can belong to only one mirroring group.
Configuring a Remote Destination Mirroring Group (on the Destination Device)
A remote destination mirroring group comprises a remote probe VLAN and a monitor port. You must
ensure that the remote probe VLAN is the same as the one configured in the remote source mirroring
group.
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 approach.
[ mirroring-group groupid ] monitor-port
view
quit
Enter the interface view of the

interface interface-type interface-number
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.
12-6

When configuring the monitor port, use the following guidelines:
z The port can belong to only the current mirroring group.
z To ensure operation of your device, do not assign the monitor port to a mirroring VLAN.
z Disable these functions on the port: STP, MSTP, and RSTP.
z You are recommended to use a monitor port only for port mirroring. This is to ensure that the data
monitoring device receives and analyzes only the mirrored traffic rather than a mix of mirrored
traffic and normally forwarded traffic.
Displaying and Maintaining Port Mirroring

display mirroring-group { groupid | all |
Display the configuration of Available in any
local | remote-destination |
port mirroring groups view
remote-source }
Port Mirroring Configuration Examples

Local Port Mirroring Configuration Example
The departments of a company connect to each other through Ethernet switches:

z Research and Development (R&D) department is connected to Switch C through GigabitEthernet
1/0/1.
z Marketing department is connected to Switch C through GigabitEthernet 1/0/2.
z Data monitoring device is connected to Switch C through GigabitEthernet 1/0/3
As shown in Figure 12-3, the administrator wants to monitor the packets received on and sent from the
R&D department and the marketing department through the data monitoring device.
Use the local port mirroring function to meet the requirement. Perform the following configurations on
Switch C.
z Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as mirroring source ports.
z Configure GigabitEthernet 1/0/3 as the mirroring destination port.
12-7

Figure 12-3 Network diagram for local port mirroring configuration
Switch A
R&D
department GE1/0/1
GE1/0/3
GE1/0/2
Switch C
Data monitoring
device
Switch B
Marketing
department
Configure Switch C.
# Create a local port mirroring group.
<SwitchC> system-view
[SwitchC] mirroring-group 1 local
# Add port GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to the port mirroring group as source ports.
Add port GigabitEthernet 1/0/3 to the port mirroring group as the destination port.
[SwitchC] mirroring-group 1 mirroring-port GigabitEthernet 1/0/1 GigabitEthernet 1/0/2 both
[SwitchC] mirroring-group 1 monitor-port GigabitEthernet 1/0/3
# Display the configuration of all the port mirroring groups.

[SwitchC] display mirroring-group all
mirroring-group 1:
type: local
status: active
mirroring port:
GigabitEthernet1/0/1 both
GigabitEthernet1/0/2 both
monitor port: GigabitEthernet1/0/3
After finishing the configuration, you can monitor all the packets received and sent by R&D department
and Marketing department on the Data monitoring device.
Remote Port Mirroring Configuration Example
The departments of a company connect to each other through Ethernet switches:

z Department 1 is connected to GigabitEthernet 1/0/1 of Switch A.
z Department 2 is connected to GigabitEthernet 1/0/2 of Switch A.
z GigabitEthernet 1/0/3 of Switch A connects to GigabitEthernet 1/0/1 of Switch B.
z GigabitEthernet 1/0/2 of Switch B connects to GigabitEthernet 1/0/1 of Switch C.
z The data monitoring device is connected to GigabitEthernet 1/0/2 of Switch C.
12-8

As shown in Figure 12-4, the administrator wants to monitor the packets sent from Department 1 and 2
through the data monitoring device.
Use the remote port mirroring function to meet the requirement. Perform the following configurations:
z Use Switch A as the source device, Switch B as the intermediate device, and Switch C as the
destination device.
z On Switch A, create a remote source mirroring group; create VLAN 2 and configure it as the
remote port mirroring VLAN; add port GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to the port
mirroring group as two source ports. Configure port GigabitEthernet 1/0/3 as the outbound
mirroring port.
z Configure port GigabitEthernet 1/0/3 of Switch A, port GigabitEthernet 1/0/1 and GigabitEthernet
1/0/2 of Switch B, and port GigabitEthernet 1/0/1 of Switch C as trunk ports and configure them to
permit packets of VLAN 2.
z Create a remote destination mirroring group on Switch C. Configure VLAN 2 as the remote port
mirroring VLAN and port GigabitEthernet 1/0/2, to which the data monitoring device is connected,
as the destination port.
Figure 12-4 Network diagram for remote port mirroring configuration
1) Configure Switch A (the source device).

# Create a remote source port mirroring group.
[SwitchA] mirroring-group 1 remote-source
# Create VLAN 2.
[SwitchA] vlan 2
# Configure VLAN 2 as the remote port mirroring VLAN of the remote port mirroring group. Add port
GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to the remote port mirroring group as source ports.
Configure port GigabitEthernet 1/0/3 as the outbound mirroring port.
[SwitchA] mirroring-group 1 remote-probe vlan 2
[SwitchA] mirroring-group 1 mirroring-port GigabitEthernet 1/0/1 GigabitEthernet 1/0/2
inbound
[SwitchA] mirroring-group 1 monitor-egress GigabitEthernet 1/0/3
12-9

# Configure port GigabitEthernet 1/0/3 as a trunk port and configure the port to permit the packets of
VLAN 2.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] port trunk permit vlan 2
2) Configure Switch B (the intermediate device).
VLAN 2.
[SwitchB] interface GigabitEthernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] port link-type trunk
[SwitchB-GigabitEthernet1/0/1] port trunk permit vlan 2
VLAN 2.
[SwitchB] interface GigabitEthernet 1/0/2
3) Configure Switch C (the destination device).
VLAN 2.
[SwitchC] interface GigabitEthernet 1/0/1
[SwitchC-GigabitEthernet1/0/1] port link-type trunk
[SwitchC-GigabitEthernet1/0/1] port trunk permit vlan 2
[SwitchC-GigabitEthernet1/0/1] quit
# Create a remote destination port mirroring group.

[SwitchC] mirroring-group 1 remote-destination
# Create VLAN 2.
[SwitchC] vlan 2
[SwitchC-vlan2] quit
# Configure VLAN 2 as the remote port mirroring VLAN of the remote destination port mirroring group.
Add port GigabitEthernet 1/0/2 to the remote destination port mirroring group as the destination port.
[SwitchC] mirroring-group 1 remote-probe vlan 2
[SwitchC] mirroring-group 1 monitor-port GigabitEthernet 1/0/2
[SwitchC-GigabitEthernet1/0/2] port access vlan 2
After finishing the configuration, you can monitor all the packets sent by Department 1 and Department
2 on the Data monitoring device.
12-10

Table of Contents
1 IP Addressing Configuration1-1
IP Addressing Overview1-1
IP Address Classes 1-1
Special IP Addresses 1-2
Subnetting and Masking 1-2
Configuring IP Addresses 1-3
Assigning an IP Address to an Interface 1-3
IP Addressing Configuration Example1-4
Displaying and Maintaining IP Addressing 1-5
2 ARP Configuration2-1
ARP Overview2-1
ARP Function 2-1
ARP Message Format 2-1
ARP Address Resolution Process2-2
ARP Table 2-3
Configuring ARP 2-3
Configuring a Static ARP Entry 2-3
Configuring the Maximum Number of ARP Entries for a Interface 2-4
Setting the Aging Time for Dynamic ARP Entries 2-4
Enabling the ARP Entry Check 2-5
ARP Configuration Example2-5
Configuring Gratuitous ARP2-5
Introduction to Gratuitous ARP2-5
Configuring Gratuitous ARP 2-6
Displaying and Maintaining ARP2-6
3 Proxy ARP Configuration 3-1

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

Configuring ARP Source Suppression4-1
Introduction to ARP Source Suppression4-1
Configuring ARP Source Suppression 4-1
Displaying and Maintaining ARP Source Suppression 4-2
Configuring ARP Defense Against IP Packet Attacks 4-2
Introduction to ARP Defense Against IP Packet Attacks 4-2

Enabling ARP Defense Against IP Packet Attacks 4-2
Configuring ARP Active Acknowledgement4-2
Introduction4-2
Configuring the ARP Active Acknowledgement Function 4-3
Configuring Source MAC Address Based ARP Attack Detection4-3
Introduction4-3
Configuration Procedure4-3
Displaying and Maintaining Source MAC Address Based ARP Attack Detection4-4
Configuring ARP Packet Source MAC Address Consistency Check 4-4
Introduction4-4
Configuring ARP Packet Source MAC Address Consistency Check4-5
Configuring ARP Packet Rate Limit 4-5
Introduction4-5
Configuring the ARP Packet Rate Limit Function 4-5
Configuring ARP Detection 4-5
Introduction to ARP Detection 4-5
Enabling ARP Detection Based on DHCP Snooping Entries/802.1X Security Entries/Static
IP-to-MAC Bindings 4-6
Configuring ARP Detection Based on Specified Objects 4-8
Displaying and Maintaining ARP Detection4-9
ARP Detection Configuration Example I 4-9
ARP Detection Configuration Example II 4-10
5 DHCP Overview5-1
Introduction to DHCP 5-1
DHCP Address Allocation 5-2
Allocation Mechanisms5-2
Dynamic IP Address Allocation Process 5-2
IP Address Lease Extension 5-3
DHCP Message Format 5-3
DHCP Options5-4
DHCP Options Overview 5-4
Introduction to DHCP Options 5-4
Self-Defined Options 5-5
Protocols and Standards5-8
6 DHCP Relay Agent Configuration 6-1

Introduction to DHCP Relay Agent 6-1
Application Environment6-1
Fundamentals6-1
DHCP Relay Agent Support for Option 82 6-2
DHCP Relay Agent Configuration Task List 6-3
Configuring the DHCP Relay Agent6-3
Enabling DHCP 6-3
Enabling the DHCP Relay Agent on an Interface 6-4
Correlating a DHCP Server Group with a Relay Agent Interface6-4
Configuring the DHCP Relay Agent Security Functions 6-5
Configuring the DHCP Relay Agent to Send a DHCP-Release Request 6-7
Configuring the DHCP Relay Agent to Support Option 826-7
ii

Displaying and Maintaining DHCP Relay Agent Configuration 6-9
DHCP Relay Agent Configuration Examples6-9
DHCP Relay Agent Configuration Example 6-9
DHCP Relay Agent Option 82 Support Configuration Example6-10
Troubleshooting DHCP Relay Agent Configuration6-11
7 DHCP Client Configuration7-1

Introduction to DHCP Client7-1
Enabling the DHCP Client on an Interface 7-1
Displaying and Maintaining the DHCP Client 7-2
DHCP Client Configuration Example 7-2
8 DHCP Snooping Configuration 8-1

DHCP Snooping Overview8-1
Function of DHCP Snooping 8-1
Application Environment of Trusted Ports 8-2
DHCP Snooping Support for Option 828-3
Configuring DHCP Snooping Basic Functions8-4
Configuring DHCP Snooping to Support Option 828-5
Prerequisites8-5
Configuring DHCP Snooping to Support Option 82 8-5
Displaying and Maintaining DHCP Snooping 8-7
DHCP Snooping Configuration Examples 8-7
DHCP Snooping Configuration Example8-7
DHCP Snooping Option 82 Support Configuration Example 8-8
9 BOOTP Client Configuration 9-1

Introduction to BOOTP Client 9-1
BOOTP Application 9-1
Obtaining an IP Address Dynamically 9-2
Configuring an Interface to Dynamically Obtain an IP Address Through BOOTP 9-2
Displaying and Maintaining BOOTP Client Configuration9-3
BOOTP Client Configuration Example9-3
10 DNS Configuration10-1
DNS Overview10-1
Static Domain Name Resolution 10-1
Dynamic Domain Name Resolution 10-1
DNS Proxy10-3
Configuring the DNS Client10-4
Configuring Static Domain Name Resolution10-4
Configuring Dynamic Domain Name Resolution10-4
Configuring the DNS Proxy10-5
Displaying and Maintaining DNS 10-5
DNS Configuration Examples 10-5
Static Domain Name Resolution Configuration Example10-5
Dynamic Domain Name Resolution Configuration Example10-6
DNS Proxy Configuration Example 10-9
Troubleshooting DNS Configuration 10-10
iii

11 IP Performance Optimization Configuration11-1
IP Performance Overview 11-1
Enabling Reception and Forwarding of Directed Broadcasts to a Directly Connected Network 11-1
Enabling Reception of Directed Broadcasts to a Directly Connected Network11-1
Enabling Forwarding of Directed Broadcasts to a Directly Connected Network 11-2
Configuration Example 11-2
Configuring TCP Optional Parameters 11-3
Configuring ICMP to Send Error Packets 11-4
Displaying and Maintaining IP Performance Optimization11-6
12 UDP Helper Configuration 12-1

Introduction to UDP Helper 12-1
Configuring UDP Helper 12-1
Displaying and Maintaining UDP Helper12-2
UDP Helper Configuration Examples12-2
UDP Helper Configuration Example12-2
13 IPv6 Basics Configuration 13-1

IPv6 Overview 13-1
IPv6 Features 13-1
Introduction to IPv6 Address 13-3
Introduction to IPv6 Neighbor Discovery Protocol13-6
IPv6 PMTU Discovery 13-8
Introduction to IPv6 DNS13-9
IPv6 Basics Configuration Task List 13-10
Configuring Basic IPv6 Functions 13-10
Enabling IPv6 13-10
Configuring an IPv6 Unicast Address13-10
Configuring IPv6 NDP 13-12
Configuring a Static Neighbor Entry 13-12
Configuring the Maximum Number of Neighbors Dynamically Learned 13-12
Configuring Parameters Related to RA Messages 13-13
Configuring the Maximum Number of Attempts to Send an NS Message for DAD 13-15
Configuring PMTU Discovery13-15
Configuring a Static PMTU for a Specified IPv6 Address 13-15
Configuring the Aging Time for Dynamic PMTUs 13-15
Configuring IPv6 TCP Properties13-16
Configuring ICMPv6 Packet Sending13-16
Configuring the Maximum ICMPv6 Error Packets Sent in an Interval 13-16
Enable Sending of Multicast Echo Replies13-17
Enabling Sending of ICMPv6 Time Exceeded Packets 13-17
Configuring IPv6 DNS Client13-18
Configuring Static IPv6 Domain Name Resolution13-18
Configuring Dynamic IPv6 Domain Name Resolution13-18
Displaying and Maintaining IPv6 Basics Configuration13-19
IPv6 Configuration Example 13-20
Troubleshooting IPv6 Basics Configuration13-25
iv

14 Dual Stack Configuration14-1
Dual Stack Overview14-1
Configuring Dual Stack 14-1
15 sFlow Configuration 15-1

sFlow Overview15-1
Introduction to sFlow 15-1
Operation of sFlow 15-1
Configuring sFlow 15-2
Displaying and Maintaining sFlow15-2
sFlow Configuration Example 15-3
Troubleshooting sFlow Configuration 15-4
The Remote sFlow Collector Cannot Receive sFlow Packets 15-4

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 Displaying and Maintaining IP Addressing
IP Addressing Overview
This section covers these topics:
z IP Address Classes
z Special IP Addresses
IP Address Classes
On an IP network, a 32-bit address is used to identify a host. 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 for
the address just mentioned.
Each IP address breaks down into two parts:
z Net ID: The first several bits of the IP address defining a network, also known as class bits.
z Host-id: Identifies a host on a network.
IP addresses are divided into five classes, 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.
1-1

Table 1-1 IP address classes and ranges
Class Address range Remarks

The IP address 0.0.0.0 is used by a host at bootstrap for
temporary communication. This address is never a valid
0.0.0.0 to destination address.
A
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.
128.0.0.0 to
B
191.255.255.255
192.0.0.0 to
C
223.255.255.255
224.0.0.0 to
D Multicast addresses.
239.255.255.255
240.0.0.0 to Reserved for future use except for the broadcast address
E
255.255.255.255 255.255.255.255.
Special 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.
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.
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
1-2

In the absence of subnetting, some special addresses such as the addresses with the net ID of all
zeros and the addresses with the host ID of all ones, are not assignable to hosts. The same is true for
subnetting. 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 for the subnet, 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.
Configuring IP Addresses
An interface needs an IP address to communicate with other devices. You can assign an IP address to
a VLAN interface or a loopback interface on a switch. Besides directly assigning an IP address to the
VLAN interface, you may configure the VLAN interface to obtain one through BOOTP, or DHCP 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.
This chapter only covers how to assign an IP address manually. For the other two approaches, refer to
DHCP Configuration in the IP Services Volume.
This section includes:

z Assigning an IP Address to an Interface
z IP Addressing Configuration Example
Assigning an IP Address to an Interface
You may assign an interface on the Switch 4510G 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
Assign an IP address to ip address ip-address { mask Required

the interface | mask-length } [ sub ] No IP address is assigned by default.
1-3

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 or DHCP 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 must reside on different network segments.
IP Addressing Configuration Example
As shown in Figure 1-3, a port in VLAN 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 communicate with the external network through
the switch, and the hosts on the LAN can communicate with each other, do the following:
z Assign two IP addresses to VLAN-interface 1 on the switch.
z Set the switch as the gateway on all PCs in the two networks.
Figure 1-3 Network diagram for IP addressing configuration
# Assign a primary IP address and a secondary IP address to VLAN-interface 1.

<Switch> system-view
[Switch] interface vlan-interface 1
[Switch-Vlan-interface1] ip address 172.16.1.1 255.255.255.0
[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 subnet 172.16.1.0/24, and to
172.16.2.1 on the PCs attached to subnet 172.16.2.0/24.
# Ping a host on subnet 172.16.1.0/24 from the switch to check the connectivity.
1-4

<Switch> ping 172.16.1.2
PING 172.16.1.2: 56 data bytes, press CTRL_C to break
Reply from 172.16.1.2: bytes=56 Sequence=1 ttl=255 time=25 ms
--- 172.16.1.2 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 25/26/27 ms
The output information shows that the switch can communicate with the hosts on subnet
172.16.1.0/24.
# Ping a host on subnet 172.16.2.0/24 from the switch to check the connectivity.
<Switch> ping 172.16.2.2

0.00% packet loss
The output information shows that the switch can communicate with the hosts on subnet
172.16.2.0/24.
# Ping a host on subnet 172.16.1.0/24 from a host on subnet 172.16.2.0/24 to check the connectivity.
Host B can be successfully pinged from Host A.
Displaying and Maintaining IP Addressing

Display information about a display ip interface [ interface-type
specified or all Layer 3 interfaces interface-number ]
Display brief information about a display ip interface brief
specified or all Layer 3 interfaces [ interface-type [ interface-number ] ]
1-5

This document is organized as follows:
z ARP Configuration
z Proxy ARP Configuration
z ARP Attack Defense Configuration
2 ARP Configuration
When configuring ARP, go to these sections for information you are interested in:
z ARP Overview
z Configuring ARP
z Configuring Gratuitous ARP
z Displaying and Maintaining ARP
ARP Overview
ARP Function
The Address Resolution Protocol (ARP) is used to resolve an IP address into an Ethernet MAC
address (or physical address).
In a LAN, when a host or other network device is to send data to another host or device, the sending
host or device must know the network layer address (that is, the IP address) of the destination host or
device. Because IP datagrams must be encapsulated within Ethernet frames before they can be
transmitted over physical networks, the sending host or device also needs to know the physical
address of the destination host or device. Therefore, a mapping between the IP address and the
physical address is needed. ARP is the protocol to implement the mapping function.
ARP Message Format
Figure 2-1 ARP message format
The following explains the fields in Figure 2-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
2-1

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.
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 2-2. The resolution process is as follows:
1) Host A looks into 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 sender IP address and the sender MAC address are the IP address and the MAC
address of Host A respectively, and the target IP address and the target MAC address are the IP
address of Host B and an all-zero MAC address respectively. Because the ARP request is a
broadcast, all hosts on this subnet can receive the request, but only the requested host (namely,
Host B) will respond to 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 in 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 to its ARP table.
Meanwhile, Host A encapsulates the IP packet and sends it out.
Figure 2-2 ARP address resolution process
If Host A is not on the same subnet with Host B, Host A first sends an ARP request to the gateway. The
target 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
2-2

request, in which the target IP address is the IP address of Host B. After obtaining the MAC address of
Host B, the gateway sends the packet to Host B.
ARP Table
After obtaining the MAC address for the destination host, the device puts the IP-to-MAC mapping into
its own ARP table. This mapping is used for forwarding packets with the same destination in future.
An ARP table contains ARP entries, which fall into one of two categories: dynamic or static.
Dynamic ARP entry
A dynamic entry is automatically created and maintained by ARP. It can get aged, be updated by a new
ARP packet, or be overwritten by a static ARP entry. When the aging timer expires or the interface
goes down, the corresponding dynamic ARP entry will be removed.
Static ARP entry
A static ARP entry is manually configured and maintained. It cannot get aged or be overwritten by a
dynamic ARP entry.
Using static ARP entries enhances communication security. You can configure a static ARP entry to
restrict an IP address to communicate with the specified MAC address only. After that, attack packets
cannot modify the IP-to-MAC mapping specified in the static ARP entry. Thus, communications
between the protected device and the specified device are ensured.
Static ARP entries can be classified into permanent or non-permanent.
z A permanent static ARP entry can be directly used to forward packets. When configuring a
permanent static ARP entry, you must configure a VLAN and an outbound interface for the entry
besides the IP address and the MAC address.
z A non-permanent static ARP entry has only an IP address and a MAC address configured. If a
non-permanent static ARP entry matches an IP packet to be forwarded, the device sends an ARP
request first. If the sender IP and MAC addresses in the received ARP reply are the same as
those in the non-permanent static ARP entry, the device adds the interface receiving the ARP
reply to 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:
2-3

arp static ip-address mac-address Required

Configure a permanent
vlan-id interface-type No permanent static ARP entry
static ARP entry
interface-number is configured by default.
Configure a Required
non-permanent static ARP arp static ip-address mac-address No non-permanent static ARP
entry entry is configured by default.
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 for a Interface
Follow these steps to set the maximum number of dynamic ARP entries that a interface can learn:

Enter interface view interface interface-type interface-number

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

Set the aging time for dynamic Optional

arp timer aging aging-time
ARP entries 20 minutes by default.
2-4

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

Optional
Enable the ARP entry check arp check enable By default, the device is disabled from
learning multicast MAC addresses.
ARP Configuration Example
z Enable the ARP entry check.

z Set the aging time for dynamic ARP entries to 10 minutes.
z Set the maximum number of dynamic ARP entries that VLAN-interface 10 can learn to 1,000.
z Add a static ARP entry, with the IP address being 192.168.1.1/24, the MAC address being
000f-e201-0000, and the outbound interface being GigabitEthernet 1/0/1 of VLAN 10.
[Sysname] arp check enable
[Sysname] arp timer aging 10
[Sysname] vlan 10
[Sysname-vlan10] quit
[Sysname-GigabitEthernet1/0/1] port access vlan 10
[Sysname-GigabitEthernet1/0/1] quit
[Sysname] interface vlan-interface 10
[Sysname-vlan-interface10] arp max-learning-num 1000
[Sysname-vlan-interface10] quit
[Sysname] arp static 192.168.1.1 000f-e201-0000 10 gigabitethernet 1/0/1
Configuring Gratuitous ARP

Introduction to Gratuitous ARP
A gratuitous ARP packet is a special ARP packet, in which the sender IP address and the target IP
address are both the IP address of the sender, the sender MAC address is the MAC address of the
sender, and the target MAC address is the broadcast address ff:ff:ff:ff:ff:ff.
A device implements the following functions by sending gratuitous ARP packets:
2-5

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 adds the information carried in the packet to its own
dynamic ARP table if it finds no corresponding ARP entry for the ARP packet in the cache.
Configuring Gratuitous ARP
Follow these steps to configure gratuitous ARP:

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

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

display arp [ [ all | dynamic | static ] [ slot
slot-number ] | vlan vlan-id | interface
Display ARP entries in the
interface-type interface-number ] [ [ | Available in any view
ARP table
{ begin | exclude | include }
regular-expression ] | count ]
display arp ip-address [ slot slot-number ] Available in any view

Display the ARP entry for a
[ | { begin | exclude | include }
specified IP address
Display the aging time for

display arp timer aging Available in any view
dynamic ARP entries
Clear ARP entries from the reset arp { all | dynamic | static | slot
ARP table slot-number | interface interface-type Available in user view
For distributed devices interface-number }
2-6

3 Proxy ARP Configuration
When configuring proxy ARP, go to these sections for information you are interested in:
z Proxy ARP Overview
z Enabling Proxy ARP
z Displaying and Maintaining Proxy ARP
Proxy ARP Overview

If a host sends an ARP request for the MAC address of another host that actually resides on another
network (but the sending host considers the requested host is on the same network) or that is isolated
from the sending host at Layer 2, the device in between must be able to respond to the request with
the MAC address of the receiving interface to allow Layer 3 communication between the two hosts.
This is achieved by proxy ARP. Proxy ARP hides the physical details of the network.
Proxy ARP involves common proxy ARP and local proxy ARP, which are described in the following
sections.
The term proxy ARP in the following sections of this chapter refers to common proxy ARP unless
otherwise specified.
Proxy ARP
A proxy ARP enabled device allows hosts that reside on different subnets to communicate.
As shown in Figure 3-1, Switch connects to two subnets through VLAN-interface 1 and VLAN-interface
2. The IP addresses of the two interfaces are 192.168.10.99/24 and 192.168.20.99/24. Host A and
Host B have the same prefix 192.168.0.0 assigned and connect to VLAN-interface 1 and
VLAN-interface 2, respectively.
Figure 3-1 Application environment of proxy ARP
Because Host A considers that Host B is on the same network, it directly sends an ARP request for the
MAC address of Host B. Host B, however, cannot receive this request because it locates in a different
broadcast domain.
3-1

You can solve the problem by enabling proxy ARP on Switch. After that, Switch can reply to the ARP
request from Host A with the MAC address of VLAN-interface 1, and forward packets sent from Host A
to Host B. In this case, Switch seems to be a proxy of Host B.
A main advantage of proxy ARP is that it is added on a single router without disturbing routing tables of
other routers in the network. Proxy ARP acts as the gateway for IP hosts that are not configured with a
default gateway or do not have routing capability.
Local Proxy ARP
As shown in Figure 3-2, Host A and Host B belong to VLAN 2, but are isolated at Layer 2. Host A
connects to GigabitEthernet 1/0/3 while Host B connects to GigabitEthernet 1/0/1. Enable local proxy
ARP on Switch to allow Layer 3 communication between the two hosts.
Figure 3-2 Application environment of local proxy ARP
Switch
Vlan-int2
192.168.10.100/24
VLAN 2
port-isolate group
GE1/0/2
GE1/0/3
GE1/0/1
Host A Switch Host B

192.168.10.99/24 192.168.10.200/24
In one of the following cases, you need to enable local proxy ARP:
z Hosts connecting to different isolated Layer 2 ports in the same VLAN need to communicate at
Layer 3.
z If an isolate-user-vlan is configured, hosts 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:

Enter interface view interface interface-type interface-number Required

Required
Enable proxy ARP proxy-arp enable
Follow these steps to enable local proxy ARP in VLAN interface view:

Enter interface view interface interface-type interface-number Required
3-2

Required
Enable local proxy ARP local-proxy-arp enable
Displaying and Maintaining Proxy ARP

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

Proxy ARP Configuration Example
Host A and Host D have the same IP prefix and mask. Host A belongs to VLAN 1; Host D belongs to
VLAN 2. Configure proxy ARP on the switch to enable the communication between the two hosts.
Figure 3-3 Network diagram for proxy ARP
# Configure Proxy ARP on Switch to enable the communication between Host A and Host D.
[Switch] vlan 2
[Switch-vlan2] quit
[Switch-Vlan-interface1] proxy-arp enable
3-3

[Switch-Vlan-interface1] quit
[Switch-Vlan-interface2] proxy-arp enable
Local Proxy ARP Configuration Example in Case of Port Isolation
z Host A and Host B belong to the same VLAN, and connect to Switch B via GigabitEthernet 1/0/2
and GigabitEthernet 1/0/3, respectively.
z Switch B connects to Switch A via GigabitEthernet 1/0/1.
z On Switch B, Layer 2 and Layer 3 port isolation are configured on GigabitEthernet 1/0/2 and
GigabitEthernet 1/0/3. Enable proxy ARP on Switch A to allow communication between Host A
and Host B.
Figure 3-4 Network diagram for local proxy ARP between isolated ports
Switch A
GE1/0/2
VLAN 2
Vlan-int2
192.168.10.100/24
GE1/0/1
GE1/0/2 GE1/0/3
Host A Switch B Host B

192.168.10.99/24 192.168.10.200/24
1) Configure Switch B
# Add GigabitEthernet 1/0/3, GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to VLAN 2. Host A and
Host B are isolated and unable to exchange Layer 2 packets.
[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 1/0/1
[SwitchB-vlan2] quit
[SwitchB-GigabitEthernet1/0/2] port-isolate enable
[SwitchB-GigabitEthernet1/0/3] port-isolate enable
2) Configure Switch A
3-4

# Configure an IP address of VLAN-interface 2.
[SwitchA] vlan 2
[SwitchA-vlan2] port gigabitethernet 1/0/2
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.10.100 255.255.0.0
The ping operation from Host A to Host B is unsuccessful because they are isolated at Layer 2.
# Configure local proxy ARP to let Host A and Host B communicate at Layer 3.
[SwitchA-Vlan-interface2] local-proxy-arp enable
[SwitchA-Vlan-interface2] quit
The ping operation from Host A to Host B is successful after the configuration.
Local Proxy ARP Configuration Example in Isolate-user-vlan
z Switch A is attached to Switch B through GigabitEthernet 1/0/1.

z VLAN 5 on Switch B is an isolate-user-vlan, which includes uplink port GigabitEthernet 1/0/1 and
two secondary VLANs (VLAN 2 and VLAN 3). GigabitEthernet 1/0/2 belongs to VLAN 2, and
GigabitEthernet 1/0/3 belongs to VLAN 3.
z Configure local proxy ARP on Switch A to implement Layer 3 communication between VLAN 2
and VLAN 3.
Figure 3-5 Network diagram for local proxy ARP configuration in isolate-user-vlan
Switch A
GE1/0/1
VLAN 5
Vlan-int5
192.168.10.100/16 Isolate-uer-vlan 5
Secondary VLAN 2 3
GE1/0/1
VLAN 5
GE1/0/2 GE1/0/3
VLAN 2 VLAN 3
Host A Host B
Switch B
192.168.10.99/16 192.168.10.200/16
# Create VLAN 2, VLAN 3, and VLAN 5 on Switch B. Add GigabitEthernet 1/0/2 to VLAN 2,
GigabitEthernet 1/0/3 to VLAN 3, and GigabitEthernet 1/0/1 to VLAN 5. Configure VLAN 5 as the
isolate-user-vlan, and VLAN 2 and VLAN 3 as secondary VLANs. Configure the mappings between
isolate-user-vlan and the secondary VLANs.
[SwitchB] vlan 2
3-5

[SwitchB] vlan 3
[SwitchB] vlan 5
[SwitchB-vlan5] isolate-user-vlan enable
[SwitchB] isolate-user-vlan 5 secondary 2 3
# Create VLAN 5 and add GigabitEthernet 1/0/1 to it.
[SwitchA] vlan 5
[SwitchA-vlan5] interface vlan-interface 5
The ping operation from Host A to Host B is unsuccessful because they are isolated at Layer 2.
# Configure local proxy ARP to implement communication between VLAN 2 and VLAN 3.
[SwitchA-Vlan-interface5] local-proxy-arp enable
The ping operation from Host A to Host B is successful after the configuration.
3-6

4 ARP Attack Defense Configuration
When configuring ARP attack defense, go to these sections for information you are interested in:
z Configuring ARP Source Suppression
z Configuring ARP Defense Against IP Packet Attacks
z Configuring ARP Active Acknowledgement
z Configuring Source MAC Address Based ARP Attack Detection
z Configuring ARP Packet Source MAC Address Consistency Check
z Configuring ARP Packet Rate Limit
z Configuring ARP Detection
Although ARP is easy to implement, it provides no security mechanism and thus is prone to network
attacks. Currently, ARP attacks and viruses are threatening LAN security. The device can provide
multiple features to detect and prevent such attacks. This chapter mainly introduces these features.
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 increases 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 suppresses 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:

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

Displaying and Maintaining ARP Source Suppression

Display the ARP source suppression
display arp source-suppression Available in any view
configuration information
Configuring ARP Defense Against IP Packet Attacks

Introduction to ARP Defense Against IP Packet Attacks
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
attacks 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 Attacks
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 attacks:

Enable ARP defense against IP packet Optional

arp resolving-route enable
attacks Enabled by default.
Configuring ARP Active Acknowledgement

Introduction
Typically, the ARP active acknowledgement feature is configured on gateway devices to identify invalid
ARP packets.
With this feature enabled, the gateway, upon receiving an ARP packet with a different source MAC
address from that in the corresponding ARP entry, checks whether the ARP entry has been updated
within the last minute:
z If yes, the gateway does not update the ARP entry;
z If not, the gateway unicasts an ARP request to the source MAC address of the ARP entry.
Then,
z If an ARP reply is received within five seconds, the ARP packet is ignored;
z If not, the gateway unicasts an ARP request to the MAC address of the ARP packet.
4-2

Then,
z If an ARP reply is received within five seconds, the gateway updates the ARP entry;
z If not, the ARP entry is not updated.
Configuring the ARP Active Acknowledgement Function
Follow these steps to configure ARP active acknowledgement:

Enable the ARP active Required

arp anti-attack active-ack enable
acknowledgement function Disabled by default.
Configuring Source MAC Address Based ARP Attack Detection

Introduction
This feature allows the device to check the source MAC address of ARP packets. If the number of ARP
packets sent from a MAC address within five seconds exceeds the specified value, the device
considers this an attack.
Only the ARP packets delivered to the CPU are detected.
Configuration Procedure
Enabling source MAC address based ARP attack detection
After this feature is enabled for a device, if the number of ARP packets it receives from a MAC address
within five seconds exceeds the specified value, it generates an alarm and filters out ARP packets
sourced from that MAC address (in filter mode), or only generates an alarm (in monitor mode).
Follow these steps to configure source MAC address based ARP attack detection:

Enable source MAC address Required

arp anti-attack source-mac { filter |
based ARP attack detection
monitor } Disabled by default.
and specify the detection mode
Configuring protected MAC addresses
A protected MAC address is excluded from ARP attack detection even though it is an attacker. You can
specify certain MAC addresses, such as that of a gateway or important servers, as protected MAC
addresses.
4-3

Follow these steps to configure protected MAC addresses:

Configure protected MAC arp anti-attack source-mac Optional

addresses exclude-mac mac-address&<1-n> Not configured by default.
Configuring the aging timer for protected MAC addresses
Follow these steps to configure the aging timer for protected MAC addresses:

Configure aging timer for arp anti-attack source-mac Optional

protected MAC addresses aging-time time Five minutes by default.
Configuring the threshold
Follow these steps to configure the threshold:

arp anti-attack source-mac threshold Optional

Configure the threshold
threshold-value 50 by default.
Displaying and Maintaining Source MAC Address Based ARP Attack Detection

display arp anti-attack source-mac { slot
Display attacking
slot-number | interface interface-type Available in any view
entries detected
interface-number }
A protected MAC address is no longer excluded from detection after the specified aging time expires.
Configuring ARP Packet Source MAC Address Consistency Check

Introduction
This feature enables a gateway device to filter out ARP packets with the source MAC address in the
Ethernet header different from the sender MAC address in the ARP message, so that the gateway
device can learn correct ARP entries.
4-4

ARP detection also checks source MAC address consistency of ARP packets, but it is enabled on an
access device to detect only ARP packets sent to it.
Configuring ARP Packet Source MAC Address Consistency Check
Follow these steps to enable ARP packet source MAC address consistency check:

Enable ARP packet source MAC arp anti-attack valid-check Required

address consistency check enable Disabled by default.
Configuring ARP Packet Rate Limit

Introduction
This feature allows you to limit the rate of ARP packets to be delivered to the CPU.
Configuring the ARP Packet Rate Limit Function
Follow these steps to configure ARP packet rate limit:

interface-number
Required
arp rate-limit { disable | rate
Configure ARP packet rate limit By default, the ARP packet rate
pps drop }
limit is enabled and is 100 pps.
Configuring ARP Detection
z For information about DHCP snooping, refer to DHCP Configuration in the IP Services Volume.
z For information about 802.1X, refer to 802.1X Configuration in the Security Volume.
Introduction to ARP Detection
The ARP detection feature allows only the ARP packets of authorized clients to be forwarded.
4-5

Enabling ARP Detection Based on DHCP Snooping Entries/802.1X Security
Entries/Static IP-to-MAC Bindings
With this feature enabled, the device compares the source IP and MAC addresses of an ARP packet
received from the VLAN against the DHCP snooping entries, 802.1X security entries, or static
IP-to-MAC binding entries. You can specify a detection type or types as needed. If all the detection
types are specified, the system uses static IP-to-MAC binding entries first, then DHCP snooping
entries, and then 802.1X security entries.
1) After you enable ARP detection based on DHCP snooping entries for a VLAN,
z Upon receiving an ARP packet from an ARP untrusted port, the device compares the ARP packet
against the DHCP snooping entries. If a match is found, that is, the parameters (such as IP
address, MAC addresses, port index, and VLAN ID) are consistent, the ARP packet passes the
check; if not, the ARP packet cannot pass the check.
z Upon receiving an ARP packet from an ARP trusted port, the device does not check the ARP
packet.
z If ARP detection is not enabled for the VLAN, the ARP packet is not checked even if it is received
from an ARP untrusted port.
ARP detection based on DHCP snooping entries involves both dynamic DHCP snooping entries and
static IP Source Guard binding entries. Dynamic DHCP snooping entries are automatically generated
through the DHCP snooping function. For details, refer to DHCP Configuration in the IP Service
Volume. Static IP Source Guard binding entries are created by using the user-bind command. For
details, refer to IP Source Guard Configuration in the Security Volume.
2) After you enable ARP detection based on 802.1X security entries, the device, upon receiving an
ARP packet from an ARP untrusted port, compares the ARP packet against the 802.1X security
entries.
z If an entry with matching source IP and MAC addresses, port index, and VLAN ID is found, the
ARP packet is considered valid.
z If an entry with no matching IP address but with a matching OUI MAC address is found, the ARP
packet is considered valid.
Otherwise, the packet is considered invalid and discarded.
3) After you enable ARP detection based on static IP-to-MAC bindings, the device, upon receiving an
ARP packet from an ARP trusted/untrusted port, compares the source IP and MAC addresses of
the ARP packet against the static IP-to-MAC bindings.
z If an entry with a matching IP address but a different MAC address is found, the ARP packet is
considered invalid and discarded.
z If an entry with both matching IP and MAC addresses is found, the ARP packet is considered valid
and can pass the detection.
z If no match is found, the ARP packet is considered valid and can pass the detection.
Follow these steps to enable ARP detection for a VLAN and specify a trusted port:
4-6

Required
Disabled by default. That is, ARP
Enable ARP detection for detection based on DHCP snooping
arp detection enable
the VLAN entries/802.1X security entries/static
IP-to-MAC bindings is not enabled by
default.
interface-number
Configure the port as a Optional

arp detection trust
trusted port The port is an untrusted port by default.
Required
arp detection mode
Specify an ARP attack No ARP attack detection mode is
{ dhcp-snooping |
detection mode specified by default; that is, all packets
dot1x | static-bind }
are considered to be invalid by default.
Optional
arp detection Not configured by default.
Configure a static IP-to-MAC
static-bind ip-address If the ARP attack detection mode is
binding for ARP detection
mac-address static-bind, you need to configure static
IP-to-MAC bindings for ARP detection.
z If all the detection types are specified, the system uses IP-to-MAC bindings first, then DHCP
snooping entries, and then 802.1X security entries. If an ARP packet fails to pass ARP detection
based on static IP-to-MAC bindings, it is discarded. If the packet passes this detection, it will be
checked against DHCP snooping entries. If a match is found, the packet is considered to be valid
and will not be checked against 802.1X security entries; otherwise, the packet is checked against
802.1X security entries. If a match is found, the packet is considered to be valid; otherwise, the
packet is discarded.
z Before enabling ARP detection based on DHCP snooping entries, make sure that DHCP snooping
is enabled.
z Before enabling ARP detection based on 802.1X security entries, make sure that 802.1X is
enabled and the 802.1X clients are configured to upload IP addresses.
4-7

During the DHCP assignment process, when the client receives the DHCP-ACK message from the
DHCP server, it broadcasts a gratuitous ARP packet to detect address conflicts. If no response is
received in a pre-defined time period, the client uses the assigned IP address. If the client is enabled
with ARP detection based on 802.1X security entries, the IP address is not uploaded to the 802.1X
device before the client uses the IP address. As a result, the gratuitous ARP packet is considered to be
an attack packet and is discarded, and thus cannot detect conflicts. After the client uploads its IP
address to the 802.1X device, subsequent ARP packets sent by the client are considered to be valid
and are allowed to travel through.
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 are 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:

arp detection validate { dst-mac Required

Specify objects for ARP detection
| ip | src-mac } * Not specified by default.
4-8

z If both the ARP detection based on specified objects and the ARP detection based on snooping
entries/802.1X security entries/static IP-to-MAC bindings are enabled, the former one applies first,
and then the latter applies.
z Before enabling ARP detection based on DHCP snooping entries, make sure that DHCP snooping
is enabled.
z Before enabling ARP detection based on 802.1X security entries, make sure that 802.1X is
enabled and the 802.1X clients are configured to upload IP addresses.
Displaying and Maintaining ARP Detection

Display the VLANs enabled
display arp detection Available in any view
with ARP detection
Display the ARP detection display arp detection statistics
statistics [ interface interface-type interface-number ]
Clear the ARP detection reset arp detection statistics [ interface
Available in user view
statistics interface-type interface-number ]
ARP Detection Configuration Example I
z 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.
Figure 4-1 Network diagram for ARP detection configuration
4-9

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 a DHCP server (the configuration procedure is omitted).
3) Configure Host A and Host B as DHCP clients (the configuration procedure is omitted).
# Enable DHCP snooping.
[SwitchB] dhcp-snooping
[SwitchB-GigabitEthernet1/0/1] dhcp-snooping trust
# Enable ARP detection for VLAN 10. Configure the upstream port as a trusted port and the
downstream ports as untrusted ports (a port is an untrusted port by default).
[SwitchB] vlan 10
[SwitchB-vlan10] arp detection enable
[SwitchB-vlan10] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] arp detection trust
# Configure a static IP Source Guard binding entry on GigabitEthernet 1/0/2.

[SwitchB-GigabitEthernet1/0/2] user-bind ip-address 10.1.1.5 mac-address 0001-0203-0405
vlan 10
# Configure a static IP Source Guard binding entry on GigabitEthernet 1/0/3.

vlan 10
# Configure a static IP-to-MAC binding.

[SwitchB] arp detection static-bind 10.1.1.1 000f-e249-8050
# Enable ARP detection based on both DHCP snooping entries and static IP-to-MAC bindings.
[SwitchB] arp detection mode dhcp-snooping
[SwitchB] arp detection mode static-bind
# Enable the checking of the MAC addresses and IP addresses of ARP packets.
[SwitchB] arp detection validate dst-mac ip src-mac
ARP Detection Configuration Example II
z Enable 802.1X 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 local 802.1X access users.
4-10

Figure 4-2 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 a DHCP server (the configuration procedure is omitted).
3) Configure Host A and Host B as 802.1x clients (the configuration procedure is omitted) and
configure them to upload IP addresses for ARP detection.
# Enable the 802.1x function.
[SwitchB] dot1x
[SwitchB-GigabitEthernet1/0/1] dot1x
[SwitchB-GigabitEthernet1/0/2] dot1x
# Add local access user test.

[SwitchB] local-user test
[SwitchB-luser-test] service-type lan-access
[SwitchB-luser-test] password simple test
[SwitchB-luser-test] 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 gigabitethernet 1/0/3
[SwitchB-GigabitEthernet1/0/3] arp detection trust
# Enable ARP detection based on 802.1X security entries.

[SwitchB] arp detection mode dot1x
4-11

This document is organized as follows:
z DHCP Overview
z DHCP Relay Agent Configuration
z DHCP Client Configuration
z DHCP Snooping Configuration
z BOOTP Client Configuration
5 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.
A typical DHCP application, as shown in Figure 5-1, includes a DHCP server and multiple clients (PCs
and laptops).
Figure 5-1 A typical DHCP application
A DHCP client can get an IP address and other configuration parameters from a DHCP server on
another subnet via a DHCP relay agent. For information about the DHCP relay agent, refer to
Introduction to DHCP Relay Agent.
5-1

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 DHCP clients obtain their addresses in this way.
Dynamic IP Address Allocation Process
Figure 5-2 Dynamic IP address allocation process
As shown in Figure 5-2, a DHCP client obtains an IP address from a DHCP server via four steps:
2) The client broadcasts a DHCP-DISCOVER message to locate a DHCP server.
3) A DHCP server offers configuration parameters including an IP address to the client in a
DHCP-OFFER message. The sending mode of the DHCP-OFFER message is determined by the
flag field in the DHCP-DISCOVER message. Refer to DHCP Message Format for related
information.
4) 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.
5) All DHCP servers receive the DHCP-REQUEST message, but only the server from which the
client accepts the offered IP address responds. The server returns a DHCP-ACK message to the
client, confirming that the IP address has been allocated to the client, or a DHCP-NAK unicast
message, denying the IP address allocation.
5-2

z After receiving the DHCP-ACK message, the client probes whether the IP address assigned by
the server is in use by broadcasting a gratuitous ARP packet. If the client receives no response
within a specified time, the client can use this IP address. Otherwise, the client sends a
DHCP-DECLINE message to the server and requests an IP address again.
z The IP addresses offered by other DHCP servers 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
expires, the IP address is 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.
If the client receives no reply, it broadcasts another DHCP-REQUEST message for lease extension
after 7/8 lease duration elapses. The DHCP server handles the request as above mentioned.
DHCP Message Format

Figure 5-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 5-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: 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.
5-3

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: 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.
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 5-4 shows the DHCP option format.
Figure 5-4 DHCP option format
Introduction to DHCP Options
The common DHCP options are as follows:

z Option 3: Router option. It specifies the gateway address to be assigned to the client.
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.
5-4

z Option 121: Classless route option. It specifies a list of classless static routes (the destination
addresses in these static routes are classless) that the requesting client should add to its routing
table.
z Option 33: Static route option. It specifies a list of classful static routes (the destination addresses
in these static routes are classful) that a client should add to its routing table. If Option 121 exists,
Option 33 is ignored.
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 following information through Option 43:
z Auto-Configuration Server (ACS) parameters, including the ACS URL, username, and password.
z Service provider identifier acquired by the customer premises equipment (CPE) from the DHCP
server and sent to the ACS for selecting vender-specific configurations and parameters.
z Preboot Execution Environment (PXE) server address for further obtaining the bootfile or other
control information from the PXE server.
1) Format of Option 43
Figure 5-5 Format of Option 43
For the sake of scalability, network configuration parameters are carried in different sub-options of
Option 43 so that the DHCP client can obtain more information through Option 43 as shown in Figure
5-5. The sub-option fields are described as follows:
z Sub-option type: Type of a sub-option. The field value can be 0x01, 0x02, or 0x80. 0x01 indicates
an ACS parameter sub-option. 0x02 indicates a service provider identifier sub-option. 0x80
indicates a PXE server address sub-option.
z Sub-option length: Length of a sub-option excluding the sub-option type and sub-option length
fields.
z Sub-option value: Value of a sub-option.
2) Format of the sub-option value field of Option 43
z As shown in Figure 5-6, the value field of the ACS parameter sub-option is filled in with variable
ACS URL, username, and password separated with a space (0x20) in between.
5-5

Figure 5-6 Format of the value field of the ACS parameter sub-option
z The value field of the service provider identifier sub-option contains the service provider identifier.
z Figure 5-7 shows the format of the value field of the PXE server address sub-option. Currently, the
value of the PXE server type can only be 0. The server number field indicates the number of PXE
servers contained in the sub-option. The server IP addresses filed contains the IP addresses of
the PXE servers.
Figure 5-7 Format of the value field of the PXE server address sub-option
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 before forwarding the message 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 is defined. Currently 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 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, 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 as follows:
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.
5-6

Figure 5-8 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 5-9 Sub-option 2 in normal padding format
2) Verbose padding format

The padding contents for sub-options in the verbose padding format are as follows:
z Sub-option 1: Padded with the user-specified access node identifier (ID of the device that adds
Option 82 in DHCP messages), and the type, number, and VLAN ID of the interface that received
the clients request. Its format is shown in Figure 5-10.
Figure 5-10 Sub-option 1 in verbose padding format
In Figure 5-10, 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 5-9.
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:
5-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 effective.

z RFC 2131: Dynamic Host Configuration Protocol
z RFC 2132: DHCP Options and BOOTP Vendor Extensions
z RFC 1542: Clarifications and Extensions for the Bootstrap Protocol
z RFC 3046: DHCP Relay Agent Information Option
5-8

6 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 DHCP Relay Agent Configuration Task List
z Configuring the DHCP Relay Agent
z Displaying and Maintaining DHCP Relay Agent Configuration
z DHCP Relay Agent Configuration Examples
z Troubleshooting DHCP Relay Agent Configuration
The DHCP relay agent configuration is supported only on VLAN interfaces.
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.
Fundamentals
Figure 6-1 shows a typical application of the DHCP relay agent.
6-1

Figure 6-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 6-2 DHCP relay agent work process
As shown in Figure 6-2, the DHCP relay agent works as follows:

2) 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.
3) 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 toRelay 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.
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.
6-2

If a clients
Handling
requesting Padding format The DHCP relay agent will
strategy
message has
Drop Random Drop the message.
Forward the message without changing
Keep Random
Option 82.
Forward the message after replacing
normal the original Option 82 with the Option
82 padded in normal format.
Option 82
Replace verbose the original Option 82 with the Option
82 padded in verbose format.
user-defined the 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
DHCP Relay Agent Configuration Task List

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 Security Functions Optional
Configuring the DHCP Relay Agent to Send a DHCP-Release Request 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.
6-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 With DHCP enabled, interfaces
dhcp select relay
on the current interface work in the DHCP server
mode.
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
6-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 argument in the dhcp relay server-select command was specified by the dhcp
relay server-group command.
Configuring the DHCP Relay Agent Security Functions
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
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 ip-address Optional

Create a static binding mac-address [ interface interface-type No static binding is created
interface-number ] by default.
interface-number
Enable invalid IP dhcp relay address-check { disable | Required

address check enable } Disabled by default.
6-5

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.
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.
Follow these steps to configure dynamic binding update interval:

Optional
Configure binding dhcp relay security auto by default. (auto interval is calculated by
update interval tracker { interval | auto } the relay agent according to the number of
bindings.)
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.
6-6

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
information of recorded DHCP servers is cleared, the relay agent will re-record server information
following this mechanism.
Configuring the DHCP Relay Agent to Send a DHCP-Release Request
This task allows you to release a clients IP address manually on the DHCP relay agent. After you
configure this task, the DHCP relay agent actively sends 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; meanwhile, the clients IP-to-MAC binding entry is removed
from the DHCP relay agent.
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 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
6-7

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 dhcp relay information Required

support Option 82 enable Disabled by default.
Configure the handling
dhcp relay information Optional
strategy for requesting
strategy { drop | keep |
messages containing Option replace by default.
replace }
82
dhcp relay information
Configure the format { normal | verbose Optional
padding format [ node-identifier { mac |
for Option 82 sysname | user-defined normal by default.
node-identifier } ] }
Optional
By default, the code type depends
Configure Configure the on the padding format of Option
dhcp relay information
non-user- code type for the 82. Each field has its own code
circuit-id format-type
defined circuit ID type.
{ ascii | hex }
Option 82 sub-option The code type configuration
applies to non-user-defined Option
82 only.
Optional
Configure the
dhcp relay information By default, the code type is hex.
code type for the
remote-id format-type This code type configuration
remote ID
{ ascii | hex } applies to non-user-defined Option
sub-option
82 only.

padding content dhcp relay information By default, the padding content
for the circuit ID circuit-id string circuit-id depends on the padding format of
Configure
sub-option Option 82.
user-defin
ed Option Optional
Configure the
82 dhcp relay information
padding content By default, the padding content
remote-id string
for the remote ID depends on the padding format of
{ remote-id | sysname }
sub-option Option 82.
z To support Option 82, it is required to perform related configuration on both the DHCP server and
relay agent.
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,
6-8

the device name must contain no spaces. Otherwise, the DHCP relay agent will drop the
message.
Displaying and Maintaining DHCP Relay Agent Configuration

Display information about DHCP display dhcp relay { all |
server groups correlated to a specified interface interface-type
or all interfaces interface-number }
display dhcp relay information
Display Option 82 configuration
{ all | interface interface-type
information on the DHCP relay agent
interface-number }
Display information about bindings of display dhcp relay security
DHCP relay agents [ ip-address | dynamic | static ]
Display statistics information about display dhcp relay security
bindings of DHCP relay agents statistics
Display information about the
display dhcp relay security
refreshing interval for entries of
tracker
dynamic IP-to-MAC bindings
display dhcp relay
configuration of a specified or all
server-group { 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 user
agent [ server-group group-id ] view
DHCP Relay Agent Configuration Examples

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 6-3, Switch A
forwards messages between DHCP clients and the DHCP server.
6-9

Figure 6-3 Network diagram for DHCP relay agent
# Specify IP addresses for the interfaces (omitted).

# Enable DHCP.
[SwitchA] dhcp enable
# Add DHCP server 10.1.1.1 into DHCP server group 1.

[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
Because the DHCP relay agent and server are on different subnets, you need to configure a static
route or dynamic routing protocol to make them reachable to each other.
DHCP Relay Agent Option 82 Support Configuration Example
z As shown in Figure 6-3, Enable Option 82 on the DHCP relay agent (Switch 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 Switch A forwards DHCP requests to the DHCP server after replacing Option 82 in the requests,
so that the DHCP clients can obtain IP addresses.
6-10

# Specify IP addresses for the interfaces (omitted).

# Enable DHCP.
[SwitchA] dhcp enable
# Add DHCP server 10.1.1.1 into DHCP server group 1.

[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
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 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.
6-11

7 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
z The DHCP client configuration is supported only on VLAN 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.
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 ip address dhcp-alloc [ client-identifier mac Required

client on the interface interface-type interface-number ] Disabled by default.
7-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 display dhcp client [ verbose ] [ interface
configuration information interface-type interface-number ]
DHCP Client Configuration Example

As shown in Figure 7-1, on a LAN, Switch A contacts the DHCP server via VLAN-interface 2 to obtain
an IP address, DNS server address, and static route information. The IP address resides on network
10.1.1.0/24. The DNS server address is 20.1.1.1. The next hop of the static route to network
20.1.1.0/24 is 10.1.1.2.
The DHCP server uses Option 121 to assign static route information to DHCP The destination
descriptor field comprises two parts, subnet mask length and destination network address. In this
example, the value of the destination descriptor field takes 18 14 01 01, a hexadecimal number
indicating that the subnet mask length is 24 and destination network address is 20.1.1.0, and the value
of the next hop address field takes 0A 01 01 02, a hexadecimal number indicating that the next hop is
10.1.1.2.
Figure 7-1 Network diagram for DHCP client configuration example
7-2

# Enable the DHCP client on VLAN-interface 2.
[SwitchA-Vlan-interface2] ip address dhcp-alloc
2) Verification
# Use the display dhcp client command to view the IP address and other network parameters
assigned to Switch A.
[SwitchA-Vlan-interface2] display dhcp client verbose
Vlan-interface2 DHCP client information:
Current machine state: BOUND
Allocated IP: 10.1.1.3 255.255.255.0
Allocated lease: 864000 seconds, T1: 432000 seconds, T2: 756000 seconds
Lease from 2009.02.20 11:06:35 to 2009.03.02 11:06:35
DHCP server: 10.1.1.1
Transaction ID: 0x410090f0
Classless static route:
Destination: 20.1.1.0, Mask: 255.255.255.0, NextHop: 10.1.1.2
DNS server: 20.1.1.1
Client ID: 3030-3066-2e65-3230-
302e-3030-3032-2d45-
7468-6572-6e65-7430-
2f30
T1 will timeout in 4 days 23 hours 59 minutes 50 seconds.
# Use the display ip routing-table command to view the route information on Switch A. A static route
to network 20.1.1.0/24 is added to the routing table.
[SwitchA-Vlan-interface2] display ip routing-table
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 Direct 0 0 10.1.1.3 Vlan2

10.1.1.3/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 Static 70 0 10.1.1.2 Vlan2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
7-3

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

1) Ensuring DHCP clients to obtain IP addresses from authorized DHCP servers
2) Recording IP-to-MAC mappings of DHCP clients
Ensuring DHCP clients to obtain IP addresses from authorized DHCP servers
If there is an unauthorized DHCP server on a network, the DHCP clients may obtain invalid IP
addresses and network configuration parameters, and cannot normally communicate with other
network devices. 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.
z Trusted: A trusted port forwards DHCP messages normally.
z Untrusted: An untrusted port discards the DHCP-ACK or DHCP-OFFER messages from any
DHCP server.
You should configure ports that connecting to authorized DHCP servers and other DHCP snooping
devices as trusted, and other ports as untrusted. With such configurations, DHCP clients obtain IP
addresses from authorized DHCP servers only, while unauthorized DHCP servers cannot assign IP
addresses to DHCP clients.
8-1

Recording IP-to-MAC mappings of DHCP clients
DHCP snooping reads DHCP-REQUEST messages and DHCP-ACK messages from trusted ports to
record DHCP snooping entries, including MAC addresses of clients, IP addresses obtained by the
clients, ports that connect to DHCP clients, and VLANs to which the ports belong. With DHCP
snooping entries, DHCP snooping can implement the following:
z ARP detection: Whether ARP packets are sent from an authorized client is determined based on
DHCP snooping entries. This feature prevents ARP attacks from unauthorized clients. For details,
refer to ARP Configuration in the IP Services Volume.
z IP Source Guard: IP Source Guard uses dynamic binding entries generated by DHCP snooping to
filter packets on a per-port basis, and thus prevents unauthorized packets from traveling through.
For details, refer to IP Source Guard Configuration in the Security Volume.
Application Environment of Trusted Ports
Configuring a trusted port connected to a DHCP server
Figure 8-1 Configure trusted and untrusted ports
DHCP server
Trusted
DHCP snooping
Untrusted Untrusted
DHCP client Unauthorized

DHCP server
DHCP reply messages
As shown in Figure 8-1, a DHCP snooping devices port that is connected to an authorized DHCP
server should be configured as a trusted port to forward reply messages from the DHCP server, so that
the DHCP client is guaranteed to obtain IP addresses from the authorized DHCP server.
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.
8-2

Figure 8-2 Configure trusted ports in a cascaded network
Table 8-1 describes roles of the ports shown in Figure 8-2.
Table 8-1 Roles of ports
Trusted port disabled from Trusted port enabled to

Device Untrusted port
recording binding entries record binding entries
Switch A GE1/0/1 GE1/0/3 GE1/0/2
Switch B GE1/0/3 and GE1/0/4 GE1/0/1 GE1/0/2
Switch C GE1/0/1 GE1/0/3 and Ethernet 1/4 GE1/0/2
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.
8-3

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.
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.
normal
Option 82 padded in normal format.
no Option 82 verbose
Option 82 padded in verbose format.

user-defined
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.
8-4

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 You can specify Layer 2 Ethernet interfaces and Layer 2 aggregate interfaces as trusted ports.
For details about aggregate interfaces, refer to Link Aggregation Configuration in the Access
Volume.
z If a Layer 2 Ethernet interface is added to an aggregation group, DHCP snooping configured on
the interface will not take effect. After the interface quits from the aggregation group, DHCP
snooping will be effective.
z Do not add an untrusted Layer 2 Ethernet interface to an aggregation group.
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.
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 Option information strategy
82 { drop | keep | replace } replace by default.
8-5

dhcp-snooping
information format
{ normal | verbose
padding format for
[ node-identifier { mac | normal by default.
Option 82
sysname | user-defined
node-identifier } ] }
Optional
By default, the code type
depends on the padding
format of Option 82. Each
Configure Configure the code dhcp-snooping
field has its own code
non-user-defined type for the circuit ID information circuit-id
type.
Option 82 sub-option format-type { ascii | hex }
This code type
configuration applies to
non-user-defined Option
82 only.
Optional
hex by default.
Configure the code dhcp-snooping
type for the remote information remote-id The code type
ID sub-option format-type { ascii | hex } configuration applies to
non-user-defined Option
82 only.
Optional
Configure the
dhcp-snooping By default, the padding
padding content for
information [ vlan vlan-id ] content depends on the
the circuit ID
circuit-id string circuit-id padding format of Option
sub-option
Configure 82.
user-defined
Option 82 Optional
Configure the dhcp-snooping
padding content for information [ vlan vlan-id ] By default, the padding
the remote ID remote-id string content depends on the
sub-option { remote-id | sysname } padding format of Option
82.
z You can enable DHCP snooping to support Option 82 on Layer 2 Ethernet interfaces only.
z To support Option 82, it is required to perform related configuration on both the DHCP server and
the device enabled with DHCP snooping.
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.
8-6

Displaying and Maintaining DHCP Snooping
display dhcp-snooping [ ip
Display DHCP snooping entries
ip-address ]
display dhcp-snooping
Display Option 82 configuration
information { all | interface Available in any
information on the DHCP snooping device
interface-type interface-number } view
Display DHCP packet statistics on the display dhcp-snooping packet
DHCP snooping device statistics [ slot slot-number ]
Display information about trusted ports display dhcp-snooping trust
reset dhcp-snooping { all | ip
Clear DHCP snooping entries
ip-address } Available in
Clear DHCP packet statistics on the DHCP reset dhcp-snooping packet user view
snooping device statistics [ slot slot-number ]
DHCP Snooping Configuration Examples

DHCP Snooping Configuration Example
z As shown in Figure 8-3, Switch B is connected to a DHCP server through GigabitEthernet 1/0/1,
and to two DHCP clients through GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3.
z GigabitEthernet 1/0/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.
Figure 8-3 Network diagram for DHCP snooping configuration

# Specify GigabitEthernet 1/0/1 as trusted.

8-7

DHCP Snooping Option 82 Support Configuration Example
z As shown in Figure 8-3, enable DHCP snooping and Option 82 support on Switch B.
z Configure the handling strategy for DHCP requests containing Option 82 as replace.
z On GigabitEthernet 1/0/2, configure the padding content for the circuit ID sub-option as
company001 and for the remote ID sub-option as device001.
z On GigabitEthernet 1/0/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 after replacing Option 82 in the requests,
so that the DHCP clients can obtain IP addresses.

# Specify GigabitEthernet 1/0/1 as trusted.

# Configure GigabitEthernet 1/0/2 to support Option 82.

[SwitchB-GigabitEthernet1/0/2] dhcp-snooping information enable
[SwitchB-GigabitEthernet1/0/2] dhcp-snooping information strategy replace
[SwitchB-GigabitEthernet1/0/2] dhcp-snooping information circuit-id string company001
[SwitchB-GigabitEthernet1/0/2] dhcp-snooping information remote-id string device001
# Configure GigabitEthernet 1/0/3 to support Option 82.

[SwitchB-GigabitEthernet1/0/3] dhcp-snooping information enable
[SwitchB-GigabitEthernet1/0/3] dhcp-snooping information strategy replace
[SwitchB-GigabitEthernet1/0/3] dhcp-snooping information format verbose node-identifier
sysname
[SwitchB-GigabitEthernet1/0/3] dhcp-snooping information circuit-id format-type ascii
[SwitchB-GigabitEthernet1/0/3] dhcp-snooping information remote-id format-type ascii
8-8

9 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 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.
Introduction to BOOTP Client

z BOOTP Application
z Obtaining an IP Address Dynamically
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.
9-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
Required
Configure an interface to
dynamically obtain IP address ip address bootp-alloc By default, an interface does
through BOOTP not use BOOTP to obtain an IP
address.
9-2

Displaying and Maintaining BOOTP Client Configuration
Display related information on display bootp client [ interface
a BOOTP client interface-type interface-number ]
BOOTP Client Configuration Example

Network requirement
As shown in Figure 9-1, 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.
Figure 9-1 Network diagram for BOOTP
Client WINS server
10.1.1.4/25 Vlan-int1
10.1.1.126/25 10.1.1.1/25
Gateway A DHCP server

10.1.1.2/25
Vlan-int1
Switch B
DNS server
Client
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] interface vlan-interface 1
[SwitchB-Vlan-interface1] ip address bootp-alloc
9-3

10 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 configuration. For information about IPv6 DNS configuration,
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.
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.
10-1

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 10-1 Dynamic domain name resolution
Figure 10-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.
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.
10-2

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 10-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 10-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.
10-3

Configuring the DNS Client
Configuring Static Domain Name Resolution
Follow these steps to configure static domain name resolution:

Configure a mapping between a host Required

name and IP address in the static ip host hostname ip-address Not configured by
name resolution table 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.
Optional
Configure a domain name Not configured by default, that
dns domain domain-name
suffix is, only the provided domain
name is resolved.
You may configure up to six DNS servers and ten DNS suffixes.
10-4

Configuring the DNS Proxy
Follow these steps to configure the DNS proxy:

Required
Enable DNS proxy dns proxy enable
Displaying and Maintaining DNS

Display the static domain name
display ip host Available in
resolution table
any view
Display DNS server information display dns server [ dynamic ]
Display domain name suffixes display dns domain [ dynamic ]
Available in
Display the information of the dynamic any view
display dns dynamic-host
domain name cache
Clear the information of the dynamic Available in
reset dns dynamic-host
domain name cache user view
DNS Configuration Examples

Static Domain Name Resolution Configuration Example
Switch uses the static domain name resolution to access Host with IP address 10.1.1.2 through
domain name host.com.
Figure 10-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 Switch 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):
10-5

56 data bytes, press CTRL_C to break
--- 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. The mapping between
domain name Host and IP address 3.1.1.1/16 is stored in the com domain.
z Switch 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.
Figure 10-4 Network diagram for dynamic domain name resolution
z Before performing the following configuration, make sure that there is a route between the Switch
and the host, and the IP addresses of the interfaces are configured as shown Figure 10-4.
z This configuration may vary with different DNS servers. The following configuration is performed
on a Windows server 2000.
1) Configure the DNS server

# Enter DNS server configuration page.
Select Start > Programs > Administrative Tools > DNS.
# Create zone com.
10-6

In Figure 10-5, right click Forward Lookup Zones, select New zone, and then follow the instructions
to create a new zone named com.
Figure 10-5 Create a zone
# Create a mapping between the host name and IP address.

Figure 10-6 Add a host
In Figure 10-6, right click zone com, and then select New Host to bring up a dialog box as shown in
Figure 10-7. Enter host name host and IP address 3.1.1.1.
10-7

Figure 10-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 Switch to verify that the communication between the Switch
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
10-8

DNS Proxy Configuration Example
z Specify Switch A as the DNS server of Switch B (the DNS client).

z Switch A acts as a DNS proxy. The IP address of the real DNS server is 4.1.1.1.
z Switch B implements domain name resolution through Switch A.
Figure 10-8 Network diagram for DNS proxy
Before performing the following configuration, assume that Switch 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 10-8.
1) Configure the DNS server

This configuration may vary with different DNS servers. When a Windows server 2000 acts as the DNS
server, refer to Dynamic Domain Name Resolution Configuration Example for related configuration
information.
2) Configure the DNS proxy
[SwitchA] dns server 4.1.1.1
# Enable DNS proxy.

[SwitchA] dns proxy enable
3) Configure the DNS client

# Enable the domain name resolution function.
[SwitchB] dns resolve
10-9

[SwitchB] dns server 2.1.1.2
4) Configuration verification
# Execute the ping host.com command on Switch B to verify that the communication between the
Switch and the host is normal and that the corresponding destination IP address is 3.1.1.1.
[SwitchB] 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.
10-10

11 IP Performance Optimization Configuration
When optimizing 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 Optional Parameters
z Configuring ICMP to Send Error Packets
z Displaying and Maintaining IP Performance Optimization
IP Performance Overview
In some network environments, you can adjust the IP parameters to achieve best network
performance. IP performance optimization configuration includes:
z Enabling the device to receive and forward directed broadcasts
z Configuring TCP timers
z Configuring the TCP buffer size
z Enabling ICMP error packets sending
Enabling Reception and Forwarding of Directed Broadcasts to a

Directly Connected Network
Directed broadcast packets are broadcast on a specific network. In the destination IP address of a
directed broadcast, the network ID is a network ID identifies the target network, and the host ID is
all-one. If a device is allowed to forward directed broadcasts to a directly connected network, hackers
may mount attacks to the network. Therefore, the device is disabled from receiving and forwarding
directed broadcasts to a directly connected network by default. However, you should enable the
feature when 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.
11-1

Enabling Forwarding of Directed Broadcasts to a Directly Connected Network
Follow these steps to enable the device to forward directed broadcasts:

interface-number
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 If an ACL is referenced in the ip forward-broadcast [ acl-number ] command, only packets

permitted by the ACL can be forwarded.
z If you repeatedly execute the ip forward-broadcast acl [ acl-number ] command on an interface,
the last executed command takes effect only. If the command executed last time does not include
the acl acl-number, the ACL configured previously will be removed.
Configuration Example
As shown in Figure 11-1, 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.
Figure 11-1 Network diagram for receiving and forwarding directed broadcasts
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.

11-2

[SwitchA-Vlan-interface3] ip address 1.1.1.2 24
# Enable VLAN-interface 2 to forward directed broadcasts.

[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 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 packet is
received within the synwait timer interval, the TCP connection cannot be created.
z finwait timer: When a TCP connection is changed into FIN_WAIT_2 state, the finwait timer is
started. If no FIN packets is received within the timer interval, the TCP connection will be
terminated. If a FIN packet is received, the TCP connection state changes to TIME_WAIT. If a
non-FIN packet is received, the system restarts the timer upon 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 the TCP synwait tcp timer syn-timeout Optional

timer time-value 75 seconds by default.
tcp timer fin-timeout Optional

Configure the TCP finwait timer
time-value 675 seconds by default.
Configure the size of TCP Optional

tcp window window-size
receive/send buffer 8 KB by default.
11-3

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. 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:
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.
11-4

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 a device receives a lot of malicious packets that cause it to send ICMP error packets, its
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 Required

ip redirects enable
redirect packets Disabled by default.
Disable sending of ICMP Required

undo ip ttl-expires
timeout packets Enabled by default.
Enable sending of ICMP Required
destination unreachable ip unreachables enable
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.
11-5

Displaying and Maintaining IP Performance Optimization
Display current TCP connection state display tcp status
Display TCP connection statistics display tcp statistics
Display UDP statistics display udp statistics
display ip statistics [ slot
Display statistics of IP packets
slot-number ]
display icmp statistics [ slot
Display statistics of ICMP flows
slot-number ]
display ip socket [ socktype
Display socket information sock-type ] [ task-id socket-id ]
[ slot slot-number ]
display fib [ | { begin | include |
exclude } regular-expression |
Display FIB information
acl acl-number | ip-prefix
ip-prefix-name ]
Display FIB information matching the display fib ip-address [ mask |
specified destination IP address mask-length ]
reset ip statistics [ slot Available in user
Clear statistics of IP packets
slot-number ] view
Available in user
Clear statistics of TCP connections reset tcp statistics
view
Available in user
Clear statistics of UDP traffic reset udp statistics
view
11-6

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

Required
Enable UDP Helper udp-helper enable
Enable the forwarding of udp-helper port { port-number Required
packets with the specified | dns | netbios-ds |
UDP destination port netbios-ns | tacacs | tftp | No UDP port number is specified
number(s) time } by default.
12-1

interface-number
Specify the destination Required

server to which UDP packets udp-helper server ip-address No destination server is specified
are to be forwarded by default.
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
[ interface interface-type Available in any view
forwarded UDP packets
interface-number ]
Clear statistics about packets
reset udp-helper packet Available in user view
forwarded
UDP Helper Configuration Examples

UDP Helper Configuration Example
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.
12-2

Figure 12-1 Network diagram for UDP Helper configuration
The following configuration assumes that a route from Switch A to the network segment 10.2.0.0/16 is
available.
# Enable UDP Helper.

[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
12-3

13 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 ICMPv6 Packet Sending
z Configuring IPv6 DNS Client
z Displaying and Maintaining IPv6 Basics Configuration
z IPv6 Configuration Example
z Troubleshooting IPv6 Basics Configuration
The term router or the router icon in this document refers to a router in a generic sense or a Layer 3
Ethernet switch running a routing protocol.
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
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
13-1

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 13-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.
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.
13-2

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.
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.
13-3

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 13-1 lists
the mappings between address types and format prefixes.
Table 13-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
Anycast address and 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.
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.
13-4

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 13-2 are reserved for special purpose.
Table 13-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.
Figure 13-2 Convert a MAC address into an EUI-64 interface identifier
13-5

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 13-3 lists the types and functions of ICMPv6 messages used by the NDP.
Table 13-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
136
(NA) message an NA message to notify neighbor nodes of the node
information change.
After started, a node sends an RS message to request
Router solicitation (RS) the router for an address prefix and other
133
message configuration information for the purpose of
autoconfiguration.
Used to respond to an RS message
Router advertisement With the RA message suppression disabled, the

134 router regularly sends an RA message containing
(RA) message
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:
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 13-3 shows how node A acquires the link-layer
address of node B.
13-6

Figure 13-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 13-4 shows the DAD procedure.
Figure 13-4 Duplicate address detection
The DAD procedure is as follows:

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

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
procedure is as follows:
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
fragmented at the source end so as to reduce the processing pressure of forwarding devices and
utilize network resources properly.
13-8

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 13-5 shows the working procedure of PMTU discovery.
Figure 13-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)
z RFC 2462: IPv6 Stateless Address Autoconfiguration
13-9

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 ICMPv6 Packet Sending Optional
Configuring IPv6 DNS Client 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.
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.
13-10

z Manual assignment: IPv6 link-local addresses can be assigned manually.
Follow these steps to configure an IPv6 unicast address:

interface-number
Configure ipv6 address

an IPv6 { ipv6-address One of the two commands is
Manually assign an
aggregatabl prefix-length | required.
IPv6 address
e global ipv6-address/prefix-length
By default, no site-local
unicast }
address or aggregatable
address or Adopt the EUI-64 ipv6 address global unicast address is
site-local format to form an ipv6-address/prefix-length configured for an interface.
address IPv6 address eui-64
Automatically Optional
generate a link-local ipv6 address auto By default, after an IPv6
Configure address for the link-local site-local address or
an IPv6 interface aggregatable global unicast
link-local address is configured for an
address Manually assign a interface, a link-local address
ipv6 address
link-local address for will be generated
ipv6-address link-local
the interface automatically.
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 only remove the link-local addresses
generated through the ipv6 address auto link-local command. 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.
13-11

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.
Follow these steps to configure a static neighbor entry:

ipv6 neighbor ipv6-address mac-address { vlan-id
Configure a static
port-type port-number | interface interface-type Required
neighbor entry
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
Configure the maximum number of Optional
ipv6 neighbors
neighbors dynamically learned by
max-learning-num number The default value is 128.
an interface
13-12

Configuring Parameters Related to RA Messages
You can enable an interface to send RA messages, and configure the interval for sending RA
messages and parameters in RA messages. After receiving an RA message, a host can use these
parameters to perform corresponding operations. Table 13-4 lists the configurable parameters in an RA
message and their descriptions.
Table 13-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
Cur hop limit Limit field in IPv6 headers. The value is also filled into the Cur Hop Limit
field in response messages of a device.
Prefix information After receiving the prefix information advertised by the device, the hosts on
options the same link can perform stateless autoconfiguration.
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
M flag IPv6 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
Router lifetime
the 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
Retrans timer
after 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
Reachable time time. If 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:

13-13

Configure the hop Optional

ipv6 nd hop-limit value
limit 64 by default.
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
sending RA messages is 600 seconds, and
Configure the the minimum interval is 200 seconds.
maximum and ipv6 nd ra interval
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.
13-14

The maximum interval for sending RA messages should be less than or equal to the router lifetime in
RA messages.
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
Optional
Configure the number of
attempts to send an NS ipv6 nd dad attempts value 1 by default. When the value
message for DAD argument is set to 0, DAD is
disabled.
Configuring PMTU Discovery

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.
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
13-15

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.
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
13-16

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.
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
Configure the and the update interval is 100 milliseconds. That
Ipv6 icmp-error { bucket
capacity and is, at most 10 IPv6 ICMP error packets can be
bucket-size | ratelimit
update interval of sent within 100 milliseconds.
interval } *
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 Optional

ipv6 hoplimit-expires enable
time exceeded packets Enabled by default.
13-17

Configuring IPv6 DNS Client
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 Required
domain name resolution dns resolve
function Disabled by default.
Required
dns server ipv6 If the IPv6 address of the DNS server is a
Configure an IPv6 DNS
ipv6-address [ interface-type link-local address, you need to specify
server
interface-number ] the interface-type and interface-number
argument.
Required
By default, no domain name suffix is
Configure a DNS suffix dns domain 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.
13-18

Displaying and Maintaining IPv6 Basics Configuration
Display DNS suffix information display dns domain [ dynamic ]
Display IPv6 dynamic domain name
display dns ipv6 dynamic-host
cache information
Display IPv6 DNS server
display dns ipv6 server [ dynamic ]
information
display ipv6 fib [ slot-number ]
Display the IPv6 FIB entries
[ ipv6-address ]
Display the host name to IPv6
address mappings in the static DNS display ipv6 host
database
display ipv6 interface [ interface-type
Display the IPv6 interface settings
[ interface-number ] ] [ verbose ]
display ipv6 neighbors { { ipv6-address |

all | dynamic | static } [slot slot-number ] |
Display neighbor information interface interface-type interface-number |
vlan vlan-id } [ | { begin | exclude |
include } regular-expression ] Available in
display ipv6 neighbors { { all | dynamic | any view
Display the total number of neighbor
static } [ slot slot-number ] | interface
entries satisfying the specified
interface-type interface-number | vlan
conditions
vlan-id } count
Display the PMTU information of an display ipv6 pathmtu { ipv6-address | all |
IPv6 address dynamic | static }
display ipv6 socket [ socktype
Display socket information socket-type ] [ task-id socket-id ] [ slot
slot-number ]
Display the statistics of IPv6
display ipv6 statistics [ slot slot-number ]
packets and ICMPv6 packets
Display the IPv6 TCP connection
display tcp ipv6 statistics
statistics
Display the IPv6 TCP connection
display tcp ipv6 status
status information
Display the IPv6 UDP connection
display udp ipv6 statistics
statistics
Clear IPv6 dynamic domain name Available in
reset dns ipv6 dynamic-host
cache information user view
reset ipv6 neighbors { all | dynamic |
Clear IPv6 neighbor information interface interface-type interface-number |
slot slot-number | static }
reset ipv6 pathmtu { all | static |
Clear the specified PMTU values
dynamic}
Clear the statistics of IPv6 and
reset ipv6 statistics [ slot slot-number ]
ICMPv6 packets
Clear all IPv6 TCP connection
reset tcp ipv6 statistics
statistics
13-19

Clear the statistics of all IPv6 UDP
reset udp ipv6 statistics
packets
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

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.
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, and a route to
Switch B is available.
Figure 13-6 Network diagram for IPv6 address configuration
The VLAN interfaces have been created on the switch.
z Configure Switch A
# Enable IPv6.
[SwitchA] ipv6
# Specify an aggregatable global unicast address for VLAN-interface 2.

[SwitchA-Vlan-interface2] ipv6 address 3001::1/64
13-20

# 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-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 route-static 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 gigabitethernet 1/0/2
Type: S-Static D-Dynamic
IPv6 Address Link-layer VID Interface State T Age
FE80::215:E9FF:FEA6:7D14 0015-e9a6-7d14 1 GE1/0/2 STALE D 1238
2001::15B:E0EA:3524:E791 0015-e9a6-7d14 1 GE1/0/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 settings on Switch A.

[SwitchA-Vlan-interface1] display ipv6 interface vlan-interface 2 verbose
Vlan-interface2 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
13-21

InTooShorts: 0
InTruncatedPkts: 0
InHopLimitExceeds: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 47
OutRequests: 89
OutForwDatagrams: 48
InNoRoutes: 0
InTooBigErrors: 0
OutFragOKs: 0
OutFragCreates: 0
InMcastPkts: 6
InMcastNotMembers: 25747
OutMcastPkts: 48
InAddrErrors: 0
InDiscards: 0
OutDiscards: 0
[SwitchA-Vlan-interface1] display ipv6 interface vlan-interface 1 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
13-22

InTooShorts: 0
InTruncatedPkts: 0
InBadHeaders: 0
InBadOptions: 0
ReasmReqds: 0
ReasmOKs: 0
InFragDrops: 0
InFragTimeouts: 0
OutFragFails: 0
InUnknownProtos: 0
InDelivers: 159
OutRequests: 1012
OutForwDatagrams: 35
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
IPv6 is enabled, link-local address is FE80::20F:E2FF:FE00:1234
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
13-23

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

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
[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 ---
13-24

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.
13-25

14 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 14-1 illustrates the IPv4/IPv6 dual stack in relation to the IPv4 stack.
Figure 14-1 IPv4/IPv6 dual stack in relation to IPv4 stack (on Ethernet)
IPv4 application IPv4/IPv6 application
TCP UDP TCP UDP
IPv4 IPv4 IPv6
Protocol ID: Protocol ID: Protocol ID:

0x0800 0x0800 0x86DD
Ethernet Ethernet
IPv4 stack Dual 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:

Required
Enable the IPv6 packet forwarding function ipv6 Disabled by
default.
14-1

interface-number
Required
ip address ip-address
Configure an IPv4 address for the interface { mask | mask-length } By default, no IP
[ sub ] address is
configured.
ipv6 address
{ ipv6-address prefix-length Use either
Configure an Manually specify command.
|
IPv6 global an IPv6 address
ipv6-address/prefix-length By default, no
unicast } site-local address
address or or global unicast
site-local Configure an address is
ipv6 address
address IPv6 address in configured on an
ipv6-address/prefix-length
Configure an the EUI-64 interface.
eui-64
IPv6 format
address on
the interface Automatically Optional
create an IPv6 ipv6 address auto By default, after
link-local link-local you configured an
Configure an address
IPv6 IPv6 site-local
link-local address or global
address Manually specify unicast address, a
ipv6 address ipv6-address link local address
an IPv6 link-local
link-local is automatically
address
created.
z For information about IPv4 addressing, refer to IP Addressing Configuration in the IP Services
Volume.
z For more information about IPv6 address, refer to IPv6 Basics Configuration in the IP Services
Volume.
z For how to enable IPv6 and configure an IPv6 address on an interface, refer to IPv6 Basics
Commands in the IP Services Volume.
14-2

15 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.
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.
15-1

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
random by default.
Specify the sFlow sampling sflow sampling-mode
mode { determine | random } Currently, the determine mode
is not supported on Switch
4510G Family.
Specify the number of packets Optional
out of which the interface will sflow sampling-rate rate
sample a packet 200000 by default.
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 configuration Available in any

display sflow [ slot slot-id ]
information view
15-2

sFlow Configuration Example
z Host A and Server are connected to Switch through GigabitEthernet 1/0/1 and GigabitEthernet
1/0/2 respectively.
z Host B works as an sFlow collector with IP address 3.3.3.2 and port number 6343, and is
connected to Switch through GigabitEthernet 1/0/3.
z GigabitEthernet 1/0/3 belongs to VLAN 1, having an IP address of 3.3.3.1.
Run sFlow agent on Switch, and enable sFlow on GigabitEthernet 1/0/1 to monitor traffic on this
interface. Switch sends sFlow packets through GigabitEthernet 1/0/3 to Host B, which then analyzes
the sFlow packets and displays the results.
Network diagram
Figure 15-1 Network diagram for sFlow configuration
# Configure an IP address for the sFlow agent.

[Switch] sflow agent ip 3.3.3.1
# Specify the IP address and port number of the sFlow collector.

[Switch] sflow collector ip 3.3.3.2
# Set the sFlow interval to 30 seconds.

[Switch] sflow interval 30
# Enable sFlow in both the inbound and outbound directions on GigabitEthernet 1/0/1.
[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] sflow enable inbound
[Switch-GigabitEthernet1/0/1] sflow enable outbound
# Specify the traffic sampling rate.

[Switch-GigabitEthernet1/0/1] sflow sampling-rate 100000
# Display the sFlow configuration information.

[Switch-GigabitEthernet1/0/1] display sflow
sFlow Version: 5
sFlow Global Information:
Agent IP:3.3.3.1
15-3

Collector IP:3.3.3.2 Port:6343
Interval(s): 30
sFlow Port Information:
Interface Direction Rate Mode Status
GE1/0/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.
15-4

Table of Contents
1 IP Routing Overview1-1
IP Routing and Routing Table1-1
Routing 1-1
Routing Table 1-1
Routing Protocol Overview 1-3
Static Routing and Dynamic Routing1-3
Routing Protocols and Routing Priority 1-3
Displaying and Maintaining a Routing Table 1-3
2 Static Routing Configuration2-1

Introduction 2-1
Static Route 2-1
Default Route2-1
Application Environment of Static Routing 2-2
Configuring a Static Route 2-2
Detecting Reachability of the Static Routes Nexthop 2-3
Detecting Nexthop Reachability Through Track2-3
Displaying and Maintaining Static Routes2-4
Static Route Configuration Example 2-4
Basic Static Route Configuration Example2-4
3 RIP Configuration 3-1

RIP Overview 3-1
Operation of RIP3-1
Operation of RIP3-2
RIP Version 3-2
RIP Message Format3-3
Supported RIP Features3-5
Configuring RIP Basic Functions 3-5
Configuring RIP Route Control 3-7
Configuring an Additional Routing Metric 3-7
Configuring RIPv2 Route Summarization3-8
Disabling Host Route Reception 3-9
Advertising a Default Route3-9
Configuring Inbound/Outbound Route Filtering3-10
Configuring a Priority for RIP3-10
Configuring RIP Route Redistribution 3-11
Configuring RIP Network Optimization 3-11
Configuring RIP Timers 3-11
Configuring Split Horizon and Poison Reverse 3-12
i

Enabling Zero Field Check on Incoming RIPv1 Messages 3-13
Enabling Source IP Address Check on Incoming RIP Updates3-13
Configuring RIPv2 Message Authentication3-13
Specifying a RIP Neighbor 3-14
Configuring RIP-to-MIB Binding 3-14
Configuring the RIP Packet Sending Rate 3-15
Displaying and Maintaining RIP 3-15
RIP Configuration Examples3-15
Configuring RIP Version 3-15
Configuring RIP Route Redistribution 3-17
Configuring an Additional Metric for a RIP Interface 3-20
Troubleshooting RIP 3-21
No RIP Updates Received 3-21
Route Oscillation Occurred 3-22
4 IPv6 Static Routing Configuration 4-1

Introduction to IPv6 Static Routing4-1
Features of IPv6 Static Routes4-1
Default IPv6 Route 4-1
Configuring an IPv6 Static Route4-1
Configuration prerequisites 4-1
Configuring an IPv6 Static Route 4-2
Displaying and Maintaining IPv6 Static Routes 4-2
IPv6 Static Routing Configuration Example 4-2
5 RIPng Configuration5-1
Introduction to RIPng 5-1
RIPng Working Mechanism 5-1
RIPng Packet Format 5-2
RIPng Packet Processing Procedure 5-3
Configuring RIPng Basic Functions 5-3
Configuring RIPng Route Control 5-4
Configuring an Additional Routing Metric 5-4
Configuring RIPng Route Summarization 5-5
Advertising a Default Route5-5
Configuring a RIPng Route Filtering Policy 5-6
Configuring a Priority for RIPng5-6
Configuring RIPng Route Redistribution 5-6
Tuning and Optimizing the RIPng Network5-7
Configuring RIPng Timers 5-7
Configuring Split Horizon and Poison Reverse 5-7
Configuring Zero Field Check on RIPng Packets5-8
Displaying and Maintaining RIPng 5-9
RIPng Configuration Example5-9
Configure RIPng Basic Functions 5-9
ii

6 Route Policy Configuration 6-1
Introduction to Route Policy 6-1
Route Policy 6-1
Filters 6-1
Route Policy Application6-2
Route Policy Configuration Task List 6-2
Defining Filters 6-2
Prerequisites6-2
Defining an IP-prefix List 6-3
Configuring a Route Policy 6-4
Prerequisites6-4
Creating a Route Policy6-4
Defining if-match Clauses6-5
Defining apply Clauses6-6
Displaying and Maintaining the Route Policy6-7
Route Policy Configuration Example 6-7
Applying a Route Policy to IPv4 Route Redistribution 6-7
Applying a Route Policy to IPv6 Route Redistribution 6-8
Troubleshooting Route Policy Configuration 6-10
IPv4 Routing Information Filtering Failure 6-10
IPv6 Routing Information Filtering Failure 6-10
iii

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 Displaying and Maintaining a Routing Table
The term router in this document refers to a router in a generic sense or a Layer 3 switch.
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.
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.
1-1

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.
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
1-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.
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
STATIC 60
RIP 100
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.
Displaying and Maintaining a Routing Table

Display brief information about
display ip routing-table [ verbose | | { begin Available in any
the active routes in the routing
| exclude | include } regular-expression ] view
table
Display information about display ip routing-table ip-address
Available in any
routes to the specified [ mask-length | mask ] [ longer-match ]
view
destination [ verbose ]
1-3

Display information about
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
Display statistics about the Available in any
display ip routing-table statistics
network routing table view
Clear statistics for the routing reset ip routing-table statistics protocol Available in user
table { all | protocol } view
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
[ inactive | verbose ] view
protocol
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 ]
Clear specified IPv6 routing reset ipv6 routing-table statistics protocol Available in user
table statistics { all | protocol } view
1-4

2 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 Static Route Configuration Example
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 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:
2-1

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 RIP.
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. For a NULL0 or loopback interface, if the output interface has
already been configured, there is no need to configure the next hop address
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. The next hop address can not be a local interface IP address; otherwise, the route
configuration will not take effect.
3) Other attributes
You can configure different preferences for different static routes so that route management policies
can be applied more flexibly.
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
2-2

Follow these steps to configure a static route:

Required
By default,
ip route-static dest-address { mask | mask-length } preference for
Configure a static { next-hop-address | interface-type interface-number static routes is 60,
route next-hop-address } [ preference preference-value ] tag is 0, and no
[ tag tag-value ] [ description description-text ] description
information is
configured.
Configure the default Optional
ip route-static default-preference
preference for static
default-preference-value 60 by default
routes
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.
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 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.
Following method can be used to detect reachability of the static routes next hop.
Detecting Nexthop Reachability Through Track
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.
2-3

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.
Follow these steps to detect the reachability of a static route's nexthop through Track:

ip route-static dest-address { mask | mask-length } Required

Associate the static next-hop-address track track-entry-number [ preference Not
route with a track entry preference-value ] [ tag tag-value ] [ description configured by
description-text ] default
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 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
display current-configuration
Display the brief information of
display ip routing-table
the IP routing table
Available in
Display the detailed any view
information of the IP routing display ip routing-table verbose
table
View information of static display ip routing-table protocol static
routes [ inactive | verbose ]
Available In
Delete all the static routes delete static-routes all
system view
Static Route Configuration Example

Basic Static Route Configuration Example
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.
2-4

Figure 2-1 Network diagram for static route configuration
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
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.
[SwitchA] display ip routing-table
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
2-5

# 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:
Reply from 1.1.2.2: bytes=32 time=1ms TTL=255

Ping statistics for 1.1.2.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
# 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.
2-6

3 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
z Troubleshooting RIP
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.
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.
3-1

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.
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.
3-2

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
A RIPv1 message consists of a header and up to 25 route entries. (A RIPv2 authentication message
uses the first route entry as the authentication entry, so it has up to 24 route entries.)
RIPv1 message format
Figure 3-1 shows the format of RIPv1 message.

Figure 3-1 RIPv1 Message Format
z Command: Type of message. 1 indicates request, which is used to request all or part of the
routing information from the neighbor, and 2 indicates response, which contains all or part of the
routing information. A response message consists of up to 25 route entries.
z Version: Version of RIP, 0x01 for RIPv1.
z Must be zero: This field must be zero.
z AFI: Address Family Identifier, 2 for IP, and 0 for request messages.
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, 16 for request messages.
3-3

RIPv2 message format
The format of RIPv2 message is similar to RIPv1. Figure 3-2 shows it.
Figure 3-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 3-3.
Figure 3-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.
3-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.
Supported RIP Features
The current implementation supports the following RIP features.

z RIPv1 and RIPv2
z RIP multi-instance.
z RFC 1058: Routing Information Protocol

z RFC 1723: RIP Version 2 - Carrying Additional Information
z RFC 1721: RIP Version 2 Protocol Analysis
z RFC 1722: RIP Version 2 Protocol Applicability Statement
z RFC 1724: RIP Version 2 MIB Extension
z RFC 2082: RIPv2 MD5 Authentication
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:

Enable a RIP process and Required

rip [ process-id ]
enter RIP view Not enabled by default
Enable RIP on the Required

interface attached to the network network-address
specified network Disabled by default
3-5

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:

Enter RIP view rip [ process-id ]
Disable an or all interfaces Optional
from sending routing silent-interface { interface-type
updates (the interfaces can interface-number | all } All interfaces can send
still receive updates) routing updates by default.

interface-number
Enable the interface to Optional

rip input
receive 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.
3-6

Follow these steps to configure a RIP version:


Optional
By default, if an interface has a
RIP version specified, the
version takes precedence over
the global one. If no RIP
Specify a global RIP version version { 1 | 2 } version is 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 for rip version { 1 | 2 [ broadcast |
Optional
the interface multicast ] }
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:
3-7

interface-number
Define an inbound rip metricin [ route-policy Optional

additional routing metric route-policy-name ] value 0 by default
Define an outbound rip metricout [ route-policy Optional

additional routing metric route-policy-name ] 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:

Enable RIPv2 automatic route Optional

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

Disable RIPv2 automatic route Required

undo summary
summarization Enabled by default
interface-number
rip summary-address ip-address
Advertise a summary route Required
{ mask | mask-length }
3-8

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:

Disable RIP from receiving Required

undo host-route
host routes Enabled by default
RIPv2 can be disabled from receiving host routes, but RIPv1 cannot.
Advertising a Default Route
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:

Enable RIP to advertise a default-route { only | originate } Optional

default route [ cost cost ] Not enabled by default
interface-number
3-9

Optional
rip default-route { { only | By default, a RIP interface can
Configure the RIP interface
originate } [ cost cost ] | advertise a default route if the
to advertise a default route
no-originate } 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:

filter-policy { acl-number | gateway

Configure the filtering ip-prefix-name | ip-prefix ip-prefix-name Required
of incoming routes [ gateway ip-prefix-name ] } import Not configured by default
[ interface-type interface-number ]
filter-policy { acl-number | ip-prefix
Configure the filtering ip-prefix-name } export [ protocol Required
of outgoing routes [ process-id ] | interface-type Not configured by default
interface-number ]
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:
3-10

preference [ route-policy Optional

Configure a priority for RIP
route-policy-name ] value 100 by default
Configuring RIP Route Redistribution
If a router runs RIP and other routing protocols, you can configure RIP to redistribute static or direct
routes.
Follow these steps to configure RIP route redistribution:

Optional
Configure a default metric for The default metric of a
default cost value
redistributed routes redistributed route is 0 by
default.
import-route protocol Required
Redistribute routes from [ process-id | all-processes ]
another protocol [ cost cost | route-policy No redistribution is
route-policy-name | tag tag ] * configured by default.
Only active routes can be redistributed. You can use the display ip routing-table protocol command
to display route state information.
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:

3-11

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:

interface-number
Optional
Enable split horizon rip split-horizon
Enabled by default
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
3-12

Required
Enable poison reverse rip poison-reverse
Disabled by default
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.
This task does not apply to RIPv2 packets that have no zero fields.
Follow these steps to enable zero field check on incoming RIPv1 messages:

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, 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.
Follow these steps to enable source IP address check on incoming RIP updates:

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.
3-13

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:

rip authentication-mode { md5 { rfc2082

Configure RIPv2
key-string key-id | rfc2453 key-string } | simple Required
authentication
password }
This task does not apply to RIPv1 because RIPv1 does not support authentication. Although you can
specify authentication modes for RIPv1 in interface view, the configuration does not take effect.
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:

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
z 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
z If a specified neighbor is not directly connected, you need to disable source address check on
incoming updates.
Configuring RIP-to-MIB Binding
This task allows you to enable a specific RIP process to receive SNMP requests.
3-14

Follow these steps to bind RIP to MIB:

Optional
Bind RIP to MIB rip mib-binding process-id
By default, MIB is bound to RIP process 1.
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:

Enable a RIP process and
rip [ process-id ]
enter RIP view
Configure the maximum Optional

number of RIP packets that By default, an interface sends
output-delay time count count
can be sent at the specified up to three RIP packets every
interval 20 milliseconds.
Displaying and Maintaining RIP

Display RIP current status
display rip [ process-id ]
and configuration information
Display all active routes in
display rip process-id database
RIP database
Display RIP interface display rip process-id interface Available in any view
information [ interface-type interface-number ]
display rip process-id route
Display routing information
[ ip-address { mask | mask-length } |
about a specified RIP process
peer ip-address | statistics ]
Clear the statistics of a RIP
reset rip process-id statistics Available in user view
process
RIP Configuration Examples

Configuring RIP Version
As shown in Figure 3-4, enable RIPv2 on all interfaces on Switch A and Switch B.
3-15

Figure 3-4 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)
# Configure Switch A.
# Configure Switch B.
[SwitchB-Vlan-interface100] quit
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
Route Flags: R - RIP, T - TRIP
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
--------------------------------------------------------------------------
Peer 192.168.1.2 on Vlan-interface100
3-16

Destination/Mask Nexthop Cost Tag Flags Sec
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) On Switch A and Switch B, specify the RIP version as RIPv2, and disable RIPv2 route automatic
summarization to advertise all subnet routes.
# 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
--------------------------------------------------------------------------
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 the routing information advertised by RIPv1 has a long aging time, it will still exist until it ages out
after RIPv2 is configured.
Configuring RIP Route Redistribution
As shown in the following figure:

z Two RIP processes are running on Switch B, which communicates with Switch A through RIP 100
and with Switch C through RIP 200.
z Configure route redistribution on Switch B to make RIP 200 redistribute direct routes and routes
from RIP 100. Thus, Switch C can learn routes destined for 10.2.1.0/24 and 11.1.1.0/24, while
Switch A cannot learn routes destined for 12.3.1.0/24 and 16.4.1.0/24.
z Configure a filtering policy on Switch B to filter out the route 10.2.1.1/24 from RIP 100, making the
route not advertised to Switch C.
3-17

Figure 3-5 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 12.0.0.0
[SwitchC-rip-200] version 2
[SwitchC-rip-200] undo summary
# Display the routing table of Switch C.

[SwitchC] display ip routing-table
12.3.1.0/24 Direct 0 0 12.3.1.2 Vlan200
3-18

12.3.1.2/32 Direct 0 0 127.0.0.1 InLoop0
16.4.1.0/24 Direct 0 0 16.4.1.1 Vlan400
16.4.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
# On Switch B, configure RIP 200 to redistribute direct routes and routes from RIP 100.
[SwitchB] rip 200
[SwitchB-rip-200] import-route rip 100
[SwitchB-rip-200] import-route direct

10.2.1.0/24 RIP 100 1 12.3.1.1 Vlan200
11.1.1.0/24 RIP 100 1 12.3.1.1 Vlan200
12.3.1.0/24 Direct 0 0 12.3.1.2 Vlan200
12.3.1.2/32 Direct 0 0 127.0.0.1 InLoop0
16.4.1.0/24 Direct 0 0 16.4.1.1 Vlan400
16.4.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
4) Configure an filtering policy to filter redistributed routes
# Configure ACL 2000 to filter routes redistributed from RIP 100 on Switch B, making the route
10.2.1.0/24 not advertised to Switch C.
[SwitchB] acl number 2000
[SwitchB-acl-basic-2000] rule deny source 10.2.1.1 0.0.0.255
[SwitchB-acl-basic-2000] rule permit
[SwitchB-acl-basic-2000] quit
[SwitchB] rip 200
[SwitchB-rip-200] filter-policy 2000 export rip 100

11.1.1.0/24 RIP 100 1 12.3.1.1 Vlan200
12.3.1.0/24 Direct 0 0 12.3.1.2 Vlan200
12.3.1.2/32 Direct 0 0 127.0.0.1 InLoop0
16.4.1.0/24 Direct 0 0 16.4.1.1 Vlan400
16.4.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-19

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.
Figure 3-6 Network diagram for RIP interface additional metric configuration
1) Configure IP addresses for the interfaces (omitted).

2) Configure RIP basic functions.
[SwitchA] rip 1
[SwitchB] rip 1
# Configure Switch C.
[SwitchB] rip 1
[SwitchC-rip-1] version 2
[SwitchC-rip-1] undo summary
# Configure Switch D.
<SwitchD> system-view
3-20

[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> system-view
[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.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 next hops 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 next hop 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.0.0.0/8, cost 0, ClassfulSumm
1.1.3.0/24, cost 1, nexthop 1.1.1.2
1.1.4.0/24, cost 2, nexthop 1.1.1.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 next hop as Switch B
(1.1.1.2) and a cost of 2.
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.
3-21

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.
3-22

4 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
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.
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
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
4-1

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 Required

prefix-length [ interface-type The default
Configure an IPv6 static route
interface-number ] nexthop-address preference of IPv6
[ preference preference-value ] static routes is 60.
Displaying and Maintaining IPv6 Static Routes

Display IPv6 static route display ipv6 routing-table protocol
information static [ inactive | verbose ]
Available in system
Remove all IPv6 static routes delete ipv6 static-routes all
view
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

With IPv6 static routes configured, all hosts and switches can interact with each other.
4-2

Figure 4-1 Network diagram for static routes
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 : :: /128 Protocol : Static

NextHop : FE80::510A:0:8D7:1 Preference : 60
Interface : Vlan-interface200 Cost : 0
Destination : ::1/128 Protocol : Direct

NextHop : ::1 Preference : 0
Interface : InLoop0 Cost : 0
Destination : 1:: /64 Protocol : Direct
4-3

NextHop : 1::1 Preference : 0
Interface : Vlan-interface100 Cost : 0
Destination : 1::1/128 Protocol : Direct

NextHop : ::1 Preference : 0
Interface : InLoop0 Cost : 0
Destination : FE80::/10 Protocol : Direct

NextHop : :: Preference : 0
Interface : NULL0 Cost : 0
# Verify the connectivity with the ping command.

[SwitchA] ping ipv6 3::1
PING 3::1 : 56 data bytes, press CTRL_C to break
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
--- 3::1 ping statistics ---

0.00% packet loss
4-4

5 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
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 has the following basic differences from 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-router 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 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.
5-1

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 5-1 shows the packet format of RIPng.
Figure 5-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 5-2 shows the format of the next hop RTE:
Figure 5-2 Next hop RTE format
IPv6 next hop address is the IPv6 address of the next hop.
Figure 5-3 shows the format of the IPv6 prefix RTE.
5-2

Figure 5-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 RFC 2080: RIPng for IPv6

z RFC 2081: RIPng Protocol Applicability Statement
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.
Before the configuration, accomplish the following tasks first:

z Enable IPv6 packet forwarding.
5-3

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
Before the configuration, accomplish the following tasks first:
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.
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.
5-4

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:

Advertise a summary IPv6 ripng summary-address ipv6-address
Required
prefix prefix-length
Advertising a Default Route
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
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.
5-5

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 ]
Required
filter-policy { acl6-number |
Configure a filter policy to filter By default, RIPng does not
ipv6-prefix ipv6-prefix-name }
incoming routes filter incoming routing
import
information.
Required
filter-policy { acl6-number |
Configure a filter policy to filter By default, RIPng does not
ipv6-prefix ipv6-prefix-name }
outgoing routes filter outgoing routing
export [ protocol [ process-id ] ]
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:

preference [ route-policy Optional

Configure a RIPng priority
route-policy-name ] preference By default, the RIPng priority is 100.
Configuring RIPng Route Redistribution
Follow these steps to configure RIPng route redistribution:


Optional
Configure a default routing
default cost cost The default metric of
metric for redistributed routes
redistributed routes is 0.
import-route protocol Required
Redistribute routes from [ process-id ] [ allow-ibgp ]
another routing protocol [ cost cost | route-policy No route redistribution is
route-policy-name ] * configured by default.
5-6

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
Configuring RIPng Timers
You can adjust RIPng timers to optimize the performance of the RIPng network.
Follow these steps to configure RIPng timers:


Optional.
timers { garbage-collect The RIPng timers have the following defaults:
garbage-collect-value |
Configure RIPng z 30 seconds for the update timer
suppress suppress-value |
timers 180 seconds for the timeout timer
timeout timeout-value | z
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.
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
5-7

same interface to prevent routing loops between neighbors.
Follow these steps to configure split horizon:

Enable the split horizon Optional

ripng split-horizon
function Enabled by default
Generally, you are recommended to enable split horizon to prevent routing loops.
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:

Enable the poison reverse Required

ripng poison-reverse
function Disabled by default
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
5-8

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

Configure RIPng Basic Functions
As shown in Figure 5-4, 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.
Figure 5-4 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
[SwitchA-Vlan-interface100] ripng 1 enable
[SwitchB] ripng 1
[SwitchB-ripng-1] quit
5-9

[SwitchB-Vlan-interface200] ripng 1 enable
# Configure Switch C.
[SwitchC] ripng 1
[SwitchC-ripng-1] quit
[SwitchC] interface vlan-interface 200
[SwitchC-Vlan-interface200] ripng 1 enable
[SwitchC-Vlan-interface200] quit
# Display the routing table of Switch B.

[SwitchB] display ripng 1 route
Route Flags: A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Vlan-interface100

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 Vlan-interface200

Dest 3::/64,
via FE80::20F:E2FF:FE00:100, cost 1, tag 0, A, 11 Sec
Dest 4::/64,
Dest 5::/64,
# Display the routing table of Switch A.

[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,
5-10

Dest 5::/64,
Dest 3::/64,
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,
5-11

6 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
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
A route policy is used on a router for route filtering and attributes modification when routes are received,
advertised, or redistributed.
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.
Filters
There are six types of filters: ACL, IP prefix list, and route policy.
ACL
ACL involves IPv4 ACL and IPv6 ACL. An ACL is configured to match the destinations or next hops of
For ACL configuration, refer to ACL configuration in the Security Volume.
IP prefix list
IP prefix list involves IPv4 and IPv6 prefix list.
6-1

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 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.
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.
Route Policy Configuration Task List

Complete the following tasks to configure a route policy:
Task
Defining Filters Defining an IP-prefix 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
6-2

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

Define an IPv4 prefix index-number ] { permit | deny } ip-address Required
list mask-length [ greater-equal min-mask-length ] Not defined by default.
[ less-equal max-mask-length ]
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.
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 ip-prefix abc index 10 deny 10.1.0.0 16
[Sysname] ip ip-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

Define an IPv6 prefix index-number ] { deny | permit } ipv6-address Required
list prefix-length [ greater-equal min-prefix-length ] Not defined by default.
[ less-equal max-prefix-length ]
6-3

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 ipv6-prefix abc index 10 deny 2000:1:: 48
[Sysname] ip ipv6-prefix abc index 40 permit :: 0 less-equal 128
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 information that has satisfied the match
criteria, such as route attribute modification.
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
route-policy route-policy-name { permit |
node for it and enter route Required
deny } node node-number
policy node view
6-4

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
Enter route policy node view route-policy-name { permit | Required
deny } node node-number
Match IPv4 routing
information specified in if-match acl acl-number
the ACL Optional
Define Match IPv4 routing Not configured by default.
if-match ip-prefix
match information specified in
ip-prefix-name
criteria the IP prefix list
for IPv4
routes Match IPv4 routing
if-match ip { next-hop |
information whose next Optional
route-source } { acl
hop or source is
acl-number | ip-prefix Not configured by default.
specified in the ACL or
ip-prefix-name }
IP prefix list
if-match ipv6 { address |
Match IPv6 routing information Optional
next-hop | route-source }
whose next hop or source is
{ acl acl-number | prefix-list Not configured by default.
specified in the ACL or IP prefix list
ipv6-prefix-name }
Match routes having the specified Optional

if-match cost value
cost Not configured by default.
if-match interface Optional

Match routing information having
{ interface-type
specified outbound interface(s) Not configured by default.
interface-number }&<1-16>
Match RIP routing information Optional

if-match tag value
having the specified tag value Not configured by default.
6-5

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 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 Required
Enter route policy node view route-policy-name { permit
| deny } node node-number Not created by default.
Optional
apply ip-address Not set by default.
for IPv4 routes
next-hop ip-address The setting does not apply to
Set the next redistributed routing information.
hop Optional
apply ipv6 next-hop Not set by default.
for IPv6 routes
ipv6-address The setting does not apply to
redistributed routing information.
Set the preference for the apply preference Optional

routing protocol preference Not set by default.
Set a tag value for RIP routing Optional

apply tag value
information Not set by default.
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.
6-6

Displaying and Maintaining the Route Policy
Display IPv4 prefix list statistics display ip ip-prefix [ ip-prefix-name ]
Available in any
Display IPv6 prefix list statistics display ip ipv6-prefix [ ipv6-prefix-name ]
view
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

Applying a Route Policy to IPv4 Route Redistribution
Network Requirements
As shown in the following figure, Switch A and Switch B communicate with each other at the network
layer through RIPv2. Switch A has static routes to networks 20.0.0.0/8, 30.0.0.0/8, and 40.0.0.0/8.
Switch B needs to access these networks through Switch A, while Switch A allows Switch B to access
networks 20.0.0.0/8 and 40.0.0.0/8, but not 30.0.0.0/8.
Figure 6-1 Network diagram for route policy application to route redistribution
# Configure IP addresses of the interfaces (omitted).
# Configure RIP basic functions.
[SwitchA] rip
# Configure three static routes.

# Configure an ACL.
[SwitchA] acl number 2000
6-7

[SwitchA-acl-basic-2000] rule deny source 30.0.0.0 0.255.255.255
[SwitchA-acl-basic-2000] rule permit source any
[SwitchA-acl-basic-2000] quit
# Redistribute static routes.

[SwitchA] rip
[SwitchA-rip-1] import-route static
# Apply ACL 2000 to filter the routing information to be advertised to Switch B.

[SwitchA-rip-1] filter-policy 2000 export vlan-interface 100
# Configure IP addresses of the interfaces (omitted).
# Configure RIP basic functions.
[SwitchB] rip
3) Display the RIP routing table of Switch B and verify the configuration.
[SwitchB] display rip 1 route
----------------------------------------------------------------------
20.0.0.0/8 192.168.1.3 1 0 RA 14
40.0.0.0/8 192.168.1.3 1 0 RA 14
The display shows that Switch B has only the routing information permitted by ACL 2000. Therefore,
the configurations above can meet the configuration requirements.
Applying a Route Policy to IPv6 Route Redistribution

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.
6-8

Figure 6-2 Network diagram for route policy application to route redistribution
# Configure IPv6 addresses for VLAN-interface 100 and VLAN-interface 200.
[SwitchA] ipv6
[SwitchA-Vlan-interface100] ipv6 address 10::1 32
[SwitchA-Vlan-interface200] ipv6 address 11::1 32
# Enable RIPng on VLAN-interface 100.

# Configure three static routes.

[SwitchA] ipv6 route-static 20:: 32 11::2
# Configure a route policy.

[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
[SwitchA-route-policy] quit
[SwitchA] route-policy static2ripng permit node 10
[SwitchA-route-policy] quit
# Enable RIPng and apply the route policy to static route redistribution.
[SwitchA] ripng
[SwitchA-ripng-1] import-route static route-policy static2ripng
# Configure the IPv6 address for VLAN-interface 100.
[SwitchB] ipv6
[SwitchB-Vlan-interface100] ipv6 address 10::2 32
# Enable RIPng on VLAN-interface 100.
6-9

# 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,
via FE80::7D58:0:CA03:1, cost 1, tag 0, A, 18 Sec
Dest 20::/32,
Dest 40::/32,
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.
6-10

Table of Contents
1 Multicast Overview 2-1

Introduction to Multicast 2-1
Comparison of Information Transmission Techniques2-1
Features of Multicast 2-4
Common Notations in Multicast2-5
Advantages and Applications of Multicast2-5
Multicast Models 2-5
Multicast Architecture2-6
Multicast Addresses 2-7
Multicast Protocols 2-10
Multicast Packet Forwarding Mechanism 2-12
2 IGMP Snooping Configuration 2-1

IGMP Snooping Overview2-1
Principle of IGMP Snooping 2-1
Basic Concepts in IGMP Snooping 2-2
How IGMP Snooping Works2-3
IGMP Snooping Configuration Task List2-5
Configuring Basic Functions of IGMP Snooping2-6
Enabling IGMP Snooping 2-6
Configuring the Version of IGMP Snooping 2-7
Configuring IGMP Snooping Port Functions2-7
Configuring Aging Timers for Dynamic Ports 2-8
Configuring Static Ports2-8
Configuring Simulated Joining2-9
Configuring Fast Leave Processing 2-10
Configuring IGMP Snooping Querier 2-11
Enabling IGMP Snooping Querier 2-11
Configuring IGMP Queries and Responses 2-12
Configuring Source IP Address of IGMP Queries 2-13
Configuring an IGMP Snooping Policy2-13
Configuring a Multicast Group Filter2-14
Configuring Multicast Source Port Filtering 2-14
Configuring the Function of Dropping Unknown Multicast Data 2-15
Configuring IGMP Report Suppression 2-16
Configuring Maximum Multicast Groups that Can Be Joined on a Port2-16
Configuring Multicast Group Replacement 2-17
Displaying and Maintaining IGMP Snooping 2-18
IGMP Snooping Configuration Examples 2-19

Configuring Group Policy and Simulated Joining2-19
Static Port Configuration2-21
IGMP Snooping Querier Configuration2-25
Troubleshooting IGMP Snooping Configuration 2-27
Switch Fails in Layer 2 Multicast Forwarding 2-27
Configured Multicast Group Policy Fails to Take Effect 2-27
3 Multicast VLAN Configuration3-1

Introduction to Multicast VLAN3-1
Multicast VLAN Configuration Task List3-3
Configuring Sub-VLAN-Based Multicast VLAN 3-3
Configuring Sub-VLAN-Based Multicast VLAN3-3
Configuring Port-Based Multicast VLAN 3-4
Configuring User Port Attributes3-4
Configuring Multicast VLAN Ports 3-5
Displaying and Maintaining Multicast VLAN 3-6
Multicast VLAN Configuration Examples 3-6
Sub-VLAN-Based Multicast VLAN Configuration3-6
Port-Based Multicast VLAN Configuration 3-10
4 MLD Snooping Configuration4-1

MLD Snooping Overview 4-1
Introduction to MLD Snooping4-1
Basic Concepts in MLD Snooping4-2
How MLD Snooping Works 4-3
MLD Snooping Configuration Task List 4-5
Configuring Basic Functions of MLD Snooping 4-6
Enabling MLD Snooping4-6
Configuring the Version of MLD Snooping 4-7
Configuring MLD Snooping Port Functions 4-7
Configuring Aging Timers for Dynamic Ports 4-8
Configuring Static Ports4-8
Configuring Simulated Joining4-9
Configuring Fast Leave Processing 4-10
Configuring MLD Snooping Querier4-11
Enabling MLD Snooping Querier4-11
Configuring MLD Queries and Responses4-12
Configuring Source IPv6 Addresses of MLD Queries 4-13
Configuring an MLD Snooping Policy 4-14
Configuring an IPv6 Multicast Group Filter4-14
Configuring IPv6 Multicast Source Port Filtering4-15
Configuring MLD Report Suppression4-16
ii

Configuring Maximum Multicast Groups that Can Be Joined on a Port4-16
Configuring IPv6 Multicast Group Replacement 4-17
Displaying and Maintaining MLD Snooping 4-18
MLD Snooping Configuration Examples 4-19
Configuring IPv6 Group Policy and Simulated Joining4-19
Static Port Configuration4-21
MLD Snooping Querier Configuration 4-25
Troubleshooting MLD Snooping 4-26
Switch Fails in Layer 2 Multicast Forwarding 4-26
Configured IPv6 Multicast Group Policy Fails to Take Effect4-27
5 IPv6 Multicast VLAN Configuration 5-1

Introduction to IPv6 Multicast VLAN 5-1
IPv6 Multicast VLAN Configuration Task List 5-3
Configuring IPv6 Sub-VLAN-Based IPv6 Multicast VLAN 5-3
Configuring Sub-VLAN-Based IPv6 Multicast VLAN5-3
Configuring Port-Based IPv6 Multicast VLAN5-4
Configuring User Port Attributes5-4
Configuring IPv6 Multicast VLAN Ports5-5
Displaying and Maintaining IPv6 Multicast VLAN 5-6
IPv6 Multicast VLAN Configuration Examples5-6
Sub-VLAN-Based Multicast VLAN Configuration Example5-6
Port-Based Multicast VLAN Configuration Example 5-9
iii

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.
2-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 Host B, Host D and Host 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.
2-2

Figure 1-2 Broadcast transmission
Assume that only Host B, Host D, and Host E need the information. If the information is broadcast to
the subnet, Host A and Host 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.
2-3

Figure 1-3 Multicast transmission
The multicast source (Source in the figure) sends only one copy of the information to a multicast group.
Host B, Host D and Host 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 Host B, Host D, and Host 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 (Receiver 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.
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.
2-4

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
TV transmission Multicast transmission

A TV station transmits a TV program through A multicast source sends multicast data to a
a channel. multicast group.
A user tunes the TV set to the channel. A receiver joins the multicast group.
The user starts to watch the TV program The receiver starts to receive the multicast data that
transmitted by the TV station via the channel. the source is sending to the multicast group.
The user turns off the TV set or tunes to The receiver leaves the multicast group or joins
another channel. 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.
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-multipoint applications at the price of minimum network
resources.
Applications of multicast
Applications of the multicast technique include:

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-multipoint 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).
2-5

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.
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.
2-6

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 for topology searching, protocol maintenance, and
224.0.0.0 to 224.0.0.255 so on. Common 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 designated group addresses:
224.0.1.0 to 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 considered to be locally rather than globally unique, and can
239.0.0.0 to 239.255.255.255
be reused in 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.
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
2-7

Address Description
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

Figure 1-4 IPv6 multicast format
Referring to Figure 1-4, the meanings of the fields of an IPv6 multicast address are as follows:
z 0xFF: The most significant 8 bits are 11111111, indicating that this address is an IPv6 multicast
address.
Figure 1-5 Format of the Flags field
z Flags: Referring to Figure 1-5, the following table describes the four bits of the Flags field.
Table 1-4 Description on the bits of the Flags field
Bit Description
0 Reserved, set to 0
z When set to 0, it indicates that this address is an IPv6 multicast address without
an embedded RP address
R
z When set to 1, it indicates that this address is an IPv6 multicast address with an
embedded RP address (The P and T bits must also be set to 1)
z When set to 0, it indicates that this address is an IPv6 multicast address not
based on a unicast prefix
P
z When set to 1, it indicates that this address is an IPv6 multicast address based
on a unicast prefix (the T bit must also be set to 1)
2-8

Bit Description
z When set to 0, it indicates that this address is an IPv6 multicast address
permanently-assigned by IANA
T
z When set to 1, it indicates that this address is a transient, or dynamically
assigned IPv6 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-5.
Table 1-5 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
z Group ID: 112 bits, IPv6 multicast group identifier that uniquely identifies an IPv6 multicast group
in the scope defined by the Scope field.
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-6.
Figure 1-6 IPv4-to-MAC address mapping
5 bits lost
XXXX X
32-bit IPv4 address 1110 XXXX XXXX XXXX XXXX XXXX XXXX XXXX
23 bits
mapped
48-bit MAC address
0000 0001 0000 0000 0101 1110 0XXX XXXX XXXX XXXX XXXX XXXX
25-bit MAC address prefix
2-9

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-7 shows an example of mapping an IPv6
multicast address, FF1E::F30E:101, to a MAC address.
Figure 1-7 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.
z This section provides only general descriptions about applications and functions of the Layer 2
and Layer 3 multicast protocols in a network.
Layer 3 multicast protocols
Layer 3 multicast protocols include multicast group management protocols and multicast routing
protocols. Figure 1-8 describes where these multicast protocols are in a network.
2-10

Figure 1-8 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, an extension of the Multi-protocol Border Gateway
Protocol (MP-BGP), is used 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-9 shows where these protocols are in the network.
2-11

Figure 1-9 Position of Layer 2 multicast protocols
Source
Multicast VLAN
/IPv6 Multicast VLAN
IGMP Snooping
/MLD Snooping
Receiver Receiver
IPv4/IPv6 multicast packets
2) 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.
3) 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, the 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.
2-12

2 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 2-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.
Figure 2-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
IGMP Snooping forwards multicast data to only the receivers requiring it at Layer 2. It brings the
following advantages:
2-1

z Reducing Layer 2 broadcast packets, thus saving network bandwidth.
z Enhancing the security of multicast traffic.
z Facilitating the implementation of per-host accounting.
Basic Concepts in IGMP Snooping
IGMP Snooping related ports
As shown in Figure 2-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 2-2 IGMP Snooping related ports
Receiver
Router A Switch A
GE1/0/1 GE1/0/2
GE1/0/3 Host A
Host B
GE1/0/1 Receiver
Source GE1/0/2
Switch B Host C
Router port
Member port
Multicast packets
Host D
Ports involved in IGMP Snooping, as shown in Figure 2-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, GigabitEthernet 1/0/1 of Switch A and
GigabitEthernet 1/0/1 of Switch B are router ports. The switch registers all its local router ports in
its router port list.
z Member port: A member port is a port on an Ethernet switch that leads the switch towards
multicast group members. In the figure, GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 of Switch
A and GigabitEthernet 1/0/2 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.
2-2

Aging timers for dynamic ports in IGMP Snooping and related messages and actions
Table 2-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
IGMP general query of
router port, the switch The switch removes
Dynamic router port which the source
sets a timer initialized this port from its router
aging timer address is not 0.0.0.0
to the dynamic router port list.
or PIM hello
port aging time.
When a port
dynamically joins a
multicast group, the The switch removes
Dynamic member port switch sets a timer for IGMP membership this port from the
aging timer the port, which is report IGMP Snooping
initialized to the forwarding table.
dynamic 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:
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.
2-3

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.
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.
2-4

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.
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
2-5

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 port view are effective only for the current port; configurations made in Layer 2 aggregate
port view are effect only for the current port; 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 port view, Layer 2
aggregate port view or port group view.
z For IGMP Snooping, configurations made on a Layer 2 aggregate port do not interfere with
configurations made on its member ports, nor do they take part in aggregation calculations;
configurations made on a member port of the aggregate group will not take effect until it leaves the
aggregate group.
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
2-6

z IGMP Snooping must be enabled globally before it can be enabled in a VLAN.
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
z Configure the corresponding port groups.
Before configuring IGMP Snooping port functions, prepare the following data:
z Aging time of dynamic router ports,
z Aging time of dynamic member ports, and
z Multicast group and multicast source addresses
2-7

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.
2-8

Follow these steps to configure static ports:

Enter Ethernet port/Layer 2 interface-number Required
aggregate port 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) joining 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 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.
2-9

Follow these steps to configure simulated joining:

Enter Ethernet port/Layer 2 interface interface-type

group view Use either approach
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. However, 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. Therefore, if the
function of dropping unknown multicast traffic is already enabled on the switch or in the VLANs, the
fast leave processing function should not be enabled.
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
2-10

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:

Enter Ethernet port/Layer 2 interface interface-type interface-number Required

group view port-group manual port-group-name Use either approach
Required
Enable fast leave processing igmp-snooping fast-leave [ vlan vlan-list ]
Disabled by default
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.
Follow these steps to enable IGMP Snooping querier:

Required
Enable IGMP Snooping querier igmp-snooping querier
Disabled by default
2-11

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


response time to IGMP general max-response-time interval
queries 10 seconds by default
Configure the IGMP Optional

last-member-query-interval interval
last-member query interval 1 second by default
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
2-12

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 does not enlist
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
{ current-interface | ip-address } 0.0.0.0 by default
group-specific queries
The source address of IGMP query messages may affect IGMP querier selection within the segment.
Configuring an IGMP Snooping Policy

Before configuring an IGMP Snooping policy, complete the following task:

z Enable IGMP Snooping in the VLAN
2-13

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 By default, no group filter is
filter [ vlan vlan-list ] globally configured, that is,
hosts in VLANs can join any
valid 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 By default, no group filter is
filter acl-number [ vlan vlan-list ] configured on the current port,
that is, hosts on this port can
join any valid multicast group.
Configuring Multicast Source Port Filtering
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.
2-14

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 port view interface-number Required
or port group view Use either approach
Enable multicast source Required

igmp-snooping source-deny
port filtering Disabled by default
For the Switch 4510G Family, 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 receiving such multicast traffic, the switch floods it in the VLAN, incurring
network bandwidth waste and low forwarding efficiency.
With the function of dropping unknown multicast data enabled, the switch forwards unknown multicast
data to its router ports instead of flooding it in the VLAN. If no router ports exist, the switch drops the
unknown multicast data..
Follow these steps to configure the function of dropping unknown multicast data in a VLAN:

2-15

Enable the function of dropping igmp-snooping Required

unknown multicast data drop-unknown Disabled by default
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.
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:

port-group-name
Optional
igmp-snooping group-limit By default, the maximum
number of multicast groups
limit [ vlan vlan-list ] number of multicast groups
allowed on the port(s)
allowed on the port(s) is 1000.
2-16

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
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
2-17

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
Enable multicast group igmp-snooping overflow-replace Required

replacement [ vlan vlan-list ] Disabled by default
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.
Displaying and Maintaining IGMP Snooping

View IGMP Snooping multicast display igmp-snooping group [ vlan Available in
group information 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.
2-18

IGMP Snooping Configuration Examples
Configuring Group Policy and Simulated Joining
z As shown in Figure 2-3, Router A connects to the multicast source through GigabitEthernet 1/0/2
and to Switch A through GigabitEthernet 1/0/1.
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 GigabitEthernet
1/0/3 and GigabitEthernet 1/0/4 of Switch A even if Host A and Host B accidentally, temporarily
stop receiving multicast data.
Network diagram
Figure 2-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 2-3. The detailed
configuration steps are omitted.
2) Configure Router A
# Enable IP multicast routing, enable PIM-DM on each interface, and enable IGMP on GigabitEthernet
1/0/1.
<RouterA> system-view
[RouterA] multicast routing-enable
[RouterA] interface gigabitethernet 1/0/1
[RouterA-GigabitEthernet1/0/1] igmp enable
[RouterA-GigabitEthernet1/0/1] pim dm
[RouterA-GigabitEthernet1/0/1] quit
2-19

# Enable IGMP Snooping globally.
[SwitchA] igmp-snooping
[SwitchA-igmp-snooping] quit
# Create VLAN 100, assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/4 to this VLAN, and
enable IGMP Snooping and the function of dropping unknown multicast traffic in the VLAN.
[SwitchA] vlan 100
[SwitchA-vlan100] port gigabitethernet 1/0/1 to gigabitethernet 1/0/4
[SwitchA-vlan100] igmp-snooping enable
[SwitchA-vlan100] igmp-snooping drop-unknown
# Configure a multicast group filter so that the hosts in VLAN 100 can join only the multicast group
224.1.1.1.
[SwitchA] acl number 2001
[SwitchA-acl-basic-2001] rule permit source 224.1.1.1 0
[SwitchA-acl-basic-2001] quit
[SwitchA-igmp-snooping] group-policy 2001 vlan 100
# Configure GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 as simulated hosts for multicast group
224.1.1.1.
[SwitchA-GigabitEthernet1/0/3] igmp-snooping host-join 224.1.1.1 vlan 100
[SwitchA-GigabitEthernet1/0/4] 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.
GE1/0/1 (D) ( 00:01:30 )
2-20

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.
GE1/0/3 (D) ( 00:03:23 )
GE1/0/4 (D) ( 00:04:10 )
MAC group(s):
MAC group address:0100-5e01-0101
GE1/0/3
GE1/0/4
As shown above, GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 of Switch A has joined multicast
group 224.1.1.1.
Static Port Configuration
z As shown in Figure 2-4, Router A connects to a multicast source (Source) through GigabitEthernet
1/0/2, and to Switch A through GigabitEthernet 1/0/1.
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 Host A and host C are permanent receivers of multicast group 224.1.1.1. GigabitEthernet 1/0/3
and GigabitEthernet 1/0/5 on Switch C are required to be configured as static member ports for
multicast group 224.1.1.1 to enhance the reliability of multicast traffic transmission.
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 attached
to Switch C only along the path of Switch ASwitch BSwitch C.
z It is required to configure GigabitEthernet 1/0/3 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.
2-21

Network diagram
Figure 2-4 Network diagram for static port configuration
Source
Switch A
GE1/0/2 GE1/0/1
1.1.1.2/24 10.1.1.1/24 GE1/0/1
/3
GE
1/0
1.1.1.1/24 Router A
1/0
GE
/2
IGMP querier
/1
GE
1/0
1/0
Switch C
GE
/1
GE1/0/5 GE1/0/2 GE1/0/2
/4
GE
Host C
1/0
Switch B
1/0
GE
Receiver
/3
Host B Host A
Receiver
# Enable IP multicast routing, enable PIM-DM on each interface, and enable IGMP on GigabitEthernet
1/0/1.
enable IGMP Snooping in the VLAN.
[SwitchA] vlan 100
2-22

# Configure GigabitEthernet 1/0/3 to be a static router port.

[SwitchA-GigabitEthernet1/0/3] igmp-snooping static-router-port vlan 100
[SwitchB] igmp-snooping
[SwitchB-igmp-snooping] quit
# Create VLAN 100, assign GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to this VLAN, and enable
IGMP Snooping in the VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port gigabitethernet 1/0/1 gigabitethernet 1/0/2
[SwitchB-vlan100] igmp-snooping enable
5) Configure Switch C
[SwitchC] igmp-snooping
[SwitchC-igmp-snooping] quit
enable IGMP Snooping in the VLAN.
[SwitchC] vlan 100
[SwitchC-vlan100] port gigabitethernet 1/0/1 to gigabitethernet 1/0/5
[SwitchC-vlan100] igmp-snooping enable
# Configure GigabitEthernet 1/0/3 and GigabitEthernet 1/0/5 as static member ports for multicast
group 224.1.1.1.
[SwitchC-GigabitEthernet1/0/3] igmp-snooping static-group 224.1.1.1 vlan 100
[SwitchC-GigabitEthernet1/0/5] igmp-snooping static-group 224.1.1.1 vlan 100
# View the detailed IGMP Snooping multicast group information in VLAN 100 on Switch A.
[SwitchA] display igmp-snooping group vlan 100 verbose

2-23

Vlan(id):100.
GE1/0/1 (D) ( 00:01:30 )
GE1/0/3 (S)
(0.0.0.0, 224.1.1.1):
GE1/0/2 (D) ( 00:03:23 )
MAC group(s):
GE1/0/2
As shown above, GigabitEthernet 1/0/3 of Switch A has become a static router port.
# View the detailed IGMP Snooping multicast group information in VLAN 100 on Switch C.
[SwitchC] display igmp-snooping group vlan 100 verbose

Vlan(id):100.
GE1/0/2 (D) ( 00:01:23 )
(0.0.0.0, 224.1.1.1):
GE1/0/3 (S)
GE1/0/5 (S)
MAC group(s):
GE1/0/3
GE1/0/5
As shown above, GigabitEthernet 1/0/3 and GigabitEthernet 1/0/5 on Switch C have become static
member ports for multicast group 224.1.1.1.
2-24

IGMP Snooping Querier Configuration
z As shown in Figure 2-5, in a Layer 2only network environment, two multicast sources Source 1
and Source 2 send multicast data to multicast groups 224.1.1.1 and 225.1.1.1 respectively, Host A
and Host C are receivers of multicast group 224.1.1.1, while Host B and Host D are receivers of
multicast group 225.1.1.1.
z All the receivers are running IGMPv2, and all the switches need to run IGMP Snooping version 2.
Switch A, which is close to the multicast sources, is chosen as the IGMP-Snooping querier.
z To prevent flooding of unknown multicast traffic within the VLAN, it is required to configure all the
switches to drop unknown multicast data packets.
z Because a switch does not enlist a port that has heard an IGMP query with a source IP address of
0.0.0.0 (default) as a dynamic router port, configure a non-all-zero IP address as the source IP
address of IGMP queries to ensure normal creation of Layer 2 multicast forwarding entries.
Network diagram
Figure 2-5 Network diagram for IGMP Snooping querier configuration
1) Configure switch A
# Create VLAN 100 and assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/3 to the VLAN.
[SwitchA] vlan 100
# Enable IGMP Snooping and the function of dropping unknown multicast traffic in VLAN 100.
[SwitchA-vlan100] igmp-snooping drop-unknown
2-25

# Enable the IGMP-Snooping querier function in VLAN 100
[SwitchA-vlan100] igmp-snooping querier
# Set the source IP address of IGMP general queries and group-specific queries to 192.168.1.1 in
VLAN 100.
[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, and assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/4 to the VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port gigabitethernet 1/0/1 to gigabitethernet 1/0/4
# Enable IGMP Snooping and the function of dropping unknown multicast traffic in VLAN 100.
[SwitchB-vlan100] igmp-snooping enable
[SwitchB-vlan100] igmp-snooping drop-unknown
Configurations on Switch C and Switch D are similar to the configuration on Switch B.

After the IGMP Snooping querier starts to work, all the switches but the querier can receive IGMP
general queries. By using the display igmp-snooping statistics command, you can view the
statistics information about the IGMP messages received. For example:
# View the IGMP message statistics on Switch B.
[SwitchB] 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.
2-26

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.
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.
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 port 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 igmp-snooping drop-unknown command to
enable the function of dropping unknown multicast data.
2-27

3 Multicast VLAN Configuration
When configuring multicast VLAN, go to these sections for information you are interested in:
z Introduction to Multicast VLAN
z Multicast VLAN Configuration Task List
z Configuring Sub-VLAN-Based Multicast VLAN
z Configuring Port-Based Multicast VLAN
z Displaying and Maintaining Multicast VLAN
z Multicast VLAN Configuration Examples
Introduction to Multicast VLAN

As shown in Figure 3-1, in the traditional multicast programs-on-demand mode, when hosts, Host A,
Host B and Host C, belonging to different VLANs require multicast programs on demand service, the
Layer 3 device, Router A, needs to forward a separate copy of the multicast traffic in each user VLAN
to the Layer 2 device, Switch A. This results in not only waste of network bandwidth but also extra
burden on the Layer 3 device.
Figure 3-1 Multicast transmission without multicast VLAN
The multicast VLAN feature configured on the Layer 2 device is the solution to this issue. With the
multicast VLAN feature, the Layer 3 device needs to replicate the multicast traffic only in the multicast
VLAN instead of making a separate copy of the multicast traffic in each user VLAN. This saves the
network bandwidth and lessens the burden of the Layer 3 device.
The multicast VLAN feature can be implemented in two approaches, as described below:
Sub-VLAN-based multicast VLAN
As shown in Figure 3-2, Host A, Host B and Host C are in three different user VLANs. On Switch A,
configure VLAN 10 as a multicast VLAN, configure all the user VLANs as sub-VLANs of this multicast
VLAN, and enable IGMP Snooping in the multicast VLAN.
3-1

Figure 3-2 Sub-VLAN-based multicast VLAN
Multicast packets
VLAN 10 (Multicast VLAN) VLAN 2
VLAN 2
Receiver
VLAN 3
Host A
VLAN 4
VLAN 3
Receiver
Host B
Source Router A Switch A
IGMP querier
VLAN 4
Receiver
Host C
After the configuration, IGMP Snooping manages router ports in the multicast VLAN and member ports
in the sub-VLANs. When forwarding multicast data to Switch A, Router A needs to send only one copy
of multicast traffic to Switch A in the multicast VLAN, and Switch A distributes the traffic to the multicast
VLANs sub-VLANs that contain receivers.
Port-based multicast VLAN
As shown in Figure 3-3, Host A, Host B and Host C are in three different user VLANs. All the user ports
(ports with attached hosts) on Switch A are hybrid ports. On Switch A, configure VLAN 10 as a
multicast VLAN, assign all the user ports to this multicast VLAN, and enable IGMP Snooping in the
multicast VLAN and all the user VLANs.
Figure 3-3 Port-based multicast VLAN
After the configuration, upon receiving an IGMP message on a user port, Switch A tags the message
with the multicast VLAN ID and relays it to the IGMP querier, so that IGMP Snooping can uniformly
manage the router ports and member ports in the multicast VLAN. When forwarding multicast data to
Switch A, Router A needs to send only one copy of multicast traffic to Switch A in the multicast VLAN,
and Switch A distributes the traffic to all the member ports in the multicast VLAN.
3-2

z For information about IGMP Snooping, router ports, and member ports, refer to IGMP Snooping
Configuration in the IP Multicast Volume.
z For information about VLAN tags, refer to VLAN Configuration in the Access Volume.
Multicast VLAN Configuration Task List

Complete the following tasks to configure multicast VLAN:
Task Remarks
Configuring Sub-VLAN-Based Multicast VLAN
Required
Configuring Port-Based Configuring User Port Attributes
Multicast VLAN Configuring Multicast VLAN Ports
If you have configured both sub-VLAN-based multicast VLAN and port-based multicast VLAN on a
device, the port-based multicast VLAN configuration is given preference.

Before configuring sub-VLAN-based multicast VLAN, complete the following tasks:

z Create VLANs as required
z Enable IGMP Snooping in the VLAN to be configured as a multicast VLAN
In this approach, you need to configure a VLAN as a multicast VLAN, and then configure user VLANs
as sub-VLANs of the multicast VLAN.
Follow these steps to configure sub-VLAN-based multicast VLAN:

Configure the specified VLAN Required

as a multicast VLAN and enter multicast-vlan vlan-id Not a multicast VLAN by
multicast VLAN view default
Configure the specified Required

VLAN(s) as sub-VLAN(s) of the subvlan vlan-list By default, a multicast VLAN
multicast VLAN has no sub-VLANs.
3-3

z The VLAN to be configured as a multicast VLAN must exist.
z The VLANs to be configured as sub-VLANs of the multicast VLAN must exist and must not be
sub-VLANs of another multicast VLAN.
z The total number of sub-VLANs of a multicast VLAN must not exceed 63.
Configuring Port-Based Multicast VLAN

When configuring port-based multicast VLAN, you need to configure the attributes of each user port
and then assign the ports to the multicast VLAN.
z A user port can be configured as a multicast VLAN port only if it is of the Ethernet or Layer 2
aggregate port type.
z Configurations made in Ethernet port view are effective only for the current port; configurations
made in Layer 2 aggregate port view are effective only for the current port; configurations made in
port group view are effective for all the ports in the current port group.
Before configuring port-based multicast VLAN, complete the following tasks:

z Enable IGMP Snooping in the VLAN to be configured as a multicast VLAN
z Enable IGMP Snooping in all the user VLANs
Configuring User Port Attributes
Configure the user ports as hybrid ports that permit packets of the specified user VLAN to pass, and
configure the user VLAN to which the user ports belong as the default VLAN.
Configure the user ports to permit packets of the multicast VLAN to pass and untag the packets. Thus,
upon receiving multicast packets tagged with the multicast VLAN ID from the upstream device, the
Layer 2 device untags the multicast packets and forwards them to its downstream device.
3-4

Follow these steps to configure user port attributes:

interface-number
Enter port view or port group Required
view port-group { manual Use either command
port-group-name |
aggregation agg-id }
Configure the user port link Required

port link-type hybrid
type as hybrid Access by default
Specify the user VLAN that Required

comprises the current user port hybrid pvid vlan vlan-id
port(s) as the default VLAN VLAN 1 by default
Configure the current user Required

port(s) to permit packets of the port hybrid vlan vlan-id-list By default, a hybrid port
specified multicast VLAN(s) to untagged permits only packets of VLAN 1
pass and untag the packets to pass.
For details about the port link-type, port hybrid pvid vlan, and port hybrid vlan commands, refer to
VLAN Commands in the Access Volume.
Configuring Multicast VLAN Ports
In this approach, you need to configure a VLAN as a multicast VLAN and then assign user ports to this
multicast VLAN by either adding the user ports in the multicast VLAN or specifying the multicast VLAN
on the user ports. These two configuration methods give the same result.
Configuring multicast VLAN ports in multicast VLAN view
Follow these steps to configure multicast VLAN ports in multicast VLAN view:

Configure the specified VLAN as Required

a multicast VLAN and enter multicast-vlan vlan-id Not a multicast VLAN by
multicast VLAN view default
Required
Assign ports to the multicast
port interface-list By default, a multicast VLAN
VLAN
has no ports.
3-5

Configuring multicast VLAN ports in port view or port group view
Follow these steps to configure multicast VLAN ports in port view or port group view:
To do Use this command Remarks


as a multicast VLAN and enter multicast-vlan vlan-id Not a multicast VLAN by
multicast VLAN view default.
Enter port view or port group interface-number Required
view port-group manual Use either command.
port-group-name
Required
Configure the current port(s) as
port multicast-vlan vlan-id By default, a user port does not
port(s) of the multicast VLAN
belong to any multicast VLAN.
z The VLAN to be configured as a multicast VLAN must exist.

z A port can belong to only one multicast VLAN.
Displaying and Maintaining Multicast VLAN

Display information about a display multicast-vlan
multicast VLAN [ vlan-id ]
Multicast VLAN Configuration Examples

Sub-VLAN-Based Multicast VLAN Configuration
z Router A connects to a multicast source through GigabitEthernet1/0/1 and to Switch A, through

GigabitEthernet 1/0/2.
z IGMPv2 is required on Router A, and IGMPv2 Snooping is required on Switch A. Router A is the
IGMP querier.
z Switch As GigabitEthernet 1/0/1 belongs to VLAN 10, GigabitEthernet 1/0/2 through
GigabitEthernet1/0/4 belong to VLAN 2 through VLAN 4 respectively, and Host A through Host C
are attached to GigabitEthernet 1/0/2 through GigabitEthernet 1/0/4 of Switch A respectively.
z The multicast source sends multicast data to multicast group 224.1.1.1. Host A, Host B, and Host
C are receivers of the multicast group.
3-6

z Configure the sub-VLAN-based multicast VLAN feature so that Router A just sends multicast data
to Switch A through the multicast VLAN and Switch A forwards the traffic to the receivers that
belong to different user VLANs.
Network diagram
Figure 3-4 Network diagram for sub-VLAN-based multicast VLAN configuration
Source IGMP querier

GE1/0/1 Router A
1.1.1.2/24
1.1.1.1/24 GE1/0/2
10.110.1.1/24
GE1/0/1
Switch A
GE1/0/2 GE1/0/4
GE1/0/3
Receiver Receiver Receiver

Host A Host B Host C
VLAN 2 VLAN 3 VLAN 4
# Enable IP multicast routing, enable PIM-DM on each interface and enable IGMP on the host-side
interface GigabitEthernet 1/0/2.
# Create VLAN 2 and assign GigabitEthernet 1/0/2 to this VLAN.

[SwitchA] vlan 2
3-7

The configuration for VLAN 3 and VLAN 4 is similar to the configuration for VLAN 2.
# Create VLAN 10, assign GigabitEthernet 1/0/1 to this VLAN and enable IGMP Snooping in the
VLAN.
[SwitchA] vlan 10
# Configure VLAN 10 as a multicast VLAN and configure VLAN 2 through VLAN 4 as its sub-VLANs.
[SwitchA] multicast-vlan 10
[SwitchA-mvlan-10] subvlan 2 to 4
[SwitchA-mvlan-10] quit
# Display information about the multicast VLAN.
[SwitchA] display multicast-vlan
Total 1 multicast-vlan(s)
Multicast vlan 10
subvlan list:
vlan 2-4
port list:
no port
# View the IGMP Snooping multicast group information on Switch A.

[SwitchA] display igmp-snooping group

Vlan(id):2.
(0.0.0.0, 224.1.1.1):
GE1/0/2 (D)
MAC group(s):
GE1/0/2
3-8

Vlan(id):3.
(0.0.0.0, 224.1.1.1):
GE1/0/3 (D)
MAC group(s):
GE1/0/3
Vlan(id):4.
(0.0.0.0, 224.1.1.1):
GE1/0/4 (D)
MAC group(s):
GE1/0/4
Vlan(id):10.
GE1/0/1 (D)
(0.0.0.0, 224.1.1.1):
MAC group(s):
As shown above, IGMP Snooping is maintaining the router port in the multicast VLAN (VLAN 10) and
the member ports in the sub-VLANs (VLAN 2 through VLAN 4).
3-9

Port-Based Multicast VLAN Configuration
z As shown in Figure 3-5, Router A connects to a multicast source (Source) through GigabitEthernet
1/0/1, and to Switch A through GigabitEthernet 1/0/2.
z IGMPv2 is required on Router A. IGMPv2 Snooping is required on Switch A. Router A acts as the
IGMP querier.
GigabitEthernet 1/0/4 belong to VLAN 2 through VLAN 4 respectively, and Host A through Host C
are attached to GigabitEthernet 1/0/2 through GigabitEthernet1/0/4 of Switch A respectively.
z The multicast source sends multicast data to multicast group 224.1.1.1. Host A, Host B, and Host
C are receivers of the multicast group.
z Configure the port-based multicast VLAN feature so that Router A just sends multicast data to
Switch A through the multicast VLAN and Switch A forwards the multicast data to the receivers
that belong to different user VLANs.
Network diagram
Figure 3-5 Network diagram for port-based multicast VLAN configuration
Source IGMP querier

GE1/0/1 Router A
1.1.1.2/24
1.1.1.1/24 GE1/0/2
10.110.1.1/24
GE1/0/1
Switch A
GE1/0/2 GE1/0/4
GE1/0/3

Configure the IP address and subnet mask for each interface as per Figure 3-5. The detailed
# Enable IP multicast routing, enable PIM-DM on each interface, and enable IGMP on the host-side
interface GigabitEthernet 1/0/2.
3-10

# Create VLAN 10, assign GigabitEthernet 1/0/1 to VLAN 10, and enable IGMP Snooping in this
VLAN.
[SwitchA] vlan 10
# Create VLAN 2 and enable IGMP Snooping in the VLAN.

[SwitchA] vlan 2
The configuration for VLAN 3 and VLAN 4 is similar. The detailed configuration steps are omitted.
# Configure GigabitEthernet 1/0/2 as a hybrid port. Configure VLAN 2 as the default VLAN. Configure
GigabitEthernet 1/0/2 to permit packets of VLAN 2 and VLAN 10 to pass and untag the packets when
forwarding them.
[SwitchA-GigabitEthernet1/0/2] port link-type hybrid
[SwitchA-GigabitEthernet1/0/2] port hybrid pvid vlan 2
[SwitchA-GigabitEthernet1/0/2] port hybrid vlan 2 untagged
The configuration for GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 is similar. The detailed
# Configure VLAN 10 as a multicast VLAN.
[SwitchA] multicast-vlan 10
# Assign GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 to VLAN 10.

[SwitchA-mvlan-10] port gigabitethernet 1/0/2 to gigabitethernet 1/0/3
[SwitchA-mvlan-10] quit
# Assign GigabitEthernet 1/0/4 to VLAN 10.

[SwitchA-GigabitEthernet1/0/4] port multicast-vlan 10
# View the multicast VLAN information on Switch A.
[SwitchA] display multicast-vlan
3-11

Total 1 multicast-vlan(s)
Multicast vlan 10
subvlan list:
no subvlan
port list:
GE1/0/2 GE1/0/3 GE1/0/4
# View the IGMP Snooping multicast group information on Switch A.

[SwitchA] display igmp-snooping group

Vlan(id):10.
GE1/0/1 (D)
(0.0.0.0, 224.1.1.1):
GE1/0/2 (D)
GE1/0/3 (D)
GE1/0/4 (D)
MAC group(s):
GE1/0/2
GE1/0/3
GE1/0/4
As shown above, IGMP Snooping is maintaining the router ports and member ports in VLAN 10.
3-12

4 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 4-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.
Figure 4-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
MLD Snooping forwards multicast data to only the receivers requiring it at Layer 2. It brings the
following advantages:
4-1

z Reducing Layer 2 broadcast packets, thus saving network bandwidth.
z Enhancing the security of multicast traffic.
z Facilitating the implementation of per-host accounting.
Basic Concepts in MLD Snooping
MLD Snooping related ports
As shown in Figure 4-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 4-2 MLD Snooping related ports
Receiver
Router A Switch A
GE1/0/1 GE1/0/2
GE1/0/3 Host A
Host B
GE1/0/1 Receiver
Source GE1/0/2
Switch B Host C
Router port
Member port
IPv6 multicast packets
Host D
Ports involved in MLD Snooping, as shown in Figure 4-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, GigabitEthernet 1/0/1 of Switch A and
GigabitEthernet 1/0/1 of Switch B are router ports. The switch registers all its local router ports in
its router port list.
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, GigabitEthernet 1/0/2
and GigabitEthernet 1/0/3 of Switch A and GigabitEthernet 1/0/2 of Switch B are member ports.
The switch registers all the member ports on the local device in its MLD Snooping forwarding
table.
4-2

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.
Aging timers for dynamic ports in MLD Snooping
Table 4-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 MLD general query of
The switch removes
Dynamic router port, 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 The switch removes
Dynamic
group, the switch sets a this port from the MLD
member port MLD report message.
timer for the port, which is Snooping forwarding
aging timer
initialized to the dynamic table.
member port aging 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:
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.
4-3

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 applied on hosts, 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.
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.
4-4

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.
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 Functions Enabling MLD Snooping Required

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
4-5

Task Remarks
Configuring an IPv6 Multicast Group Filter Optional
Configuring IPv6 Multicast Source Port Filtering Optional

Configuring an MLD Configuring MLD Report Suppression Optional
Snooping Policy
Configuring Maximum Multicast Groups that Can Be
Optional
Joined on a Port
Configuring IPv6 Multicast Group Replacement Optional
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 port view are effective only for the current port; configurations made in Layer 2 aggregate
port view are effect only for the current port; 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 port view, Layer 2
aggregate port view or port group view.
z For MLD Snooping, configurations made on a Layer 2 aggregate port do not interfere with
configurations made on its member ports, nor do they take part in aggregation calculations;
configurations made on a member port of the aggregate group will not take effect until it leaves the
aggregate group.
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
4-6

Enable MLD Snooping in the Required

mld-snooping enable
VLAN Disabled by default
z MLD Snooping must be enabled globally before it can be enabled in a VLAN.

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 joining, and will:
z Keep forwarding entries from version 2 static (*, G) joining;
z Clear forwarding entries from version 2 static (S, G) joining, which will be restored when MLD
Snooping is switched back to version 2.
For details about static joining, 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
4-7

z Configure the corresponding port groups
Before configuring MLD Snooping port functions, prepare the following data:
z Aging time of dynamic router ports,
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.
4-8

Follow these steps to configure static ports:

port-group-name
mld-snooping static-group
ipv6-group-address Required
Configure the port(s) as static
[ source-ip No static member ports by
member port(s)
ipv6-source-address ] vlan default
vlan-id
Configure the port(s) as static mld-snooping Required

router port(s) static-router-port 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 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.
z When the simulated joining function is disabled on a port, the switch sends an MLD done
message through that port.
4-9

Follow these steps to configure simulated joining:


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
4-10

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:


mld-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 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:
4-11

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.
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
Response time field.
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:


response time for MLD general max-response-time interval
queries 10 seconds by default
Configure the MLD last-listener-query-interval Optional

last-member query interval interval 1 second by default
4-12

Configuring MLD queries and responses in a VLAN
Follow these steps to configure MLD queries and responses in a VLAN

mld-snooping query-interval Optional

Configure MLD query interval
mld-snooping
response time for MLD general
max-response-time interval 10 seconds by default
queries
mld-snooping Optional
Configure the MLD
last-listener-query-interval
last-member query interval 1 second by default
interval
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.
4-13

Configuring an MLD Snooping Policy
Before configuring an MLD Snooping policy, complete the following tasks:

z Enable MLD Snooping in the VLAN
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 By default, no group filter is globally
group filter [ vlan vlan-list ] configured, that is, hosts in VLANs
can join any valid 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
4-14

Required
By default, no group filter is
Configure an IPv6 multicast mld-snooping group-policy configured on the current
group filter acl6-number [ vlan vlan-list ] port, that is, hosts on this
port can join any valid IPv6
multicast group.
Configuring IPv6 Multicast Source Port Filtering
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
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:

Enter Ethernet port view or port interface-number Required
port-group-name
Enable IPv6 multicast source Required

mld-snooping source-deny
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.
4-15

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

port-group-name
number of IPv6 multicast mld-snooping group-limit Optional
groups that can be joined on a limit [ vlan vlan-list ] 1000 by default.
port
4-16

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 joining 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 joining again, until the number of IPv6 multicast groups joined by the port
comes back within the configured threshold.
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
4-17

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
Enable IPv6 multicast group mld-snooping overflow-replace Required

replacement [ vlan vlan-list ] Disabled by default
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.
Displaying and Maintaining MLD Snooping

To do Use the command... Remarks
display mld-snooping group [ vlan
View MLD Snooping multicast group Available in any
vlan-id ] [ slot slot-number ]
information 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 on an MLD Snoopingenabled VLAN.

z The reset mld-snooping group command cannot clear the MLD Snooping multicast group
information for static joining.
4-18

MLD Snooping Configuration Examples
Configuring IPv6 Group Policy and Simulated Joining
z As shown in Figure 4-3, Router A connects to the IPv6 multicast source through GigabitEthernet
1/0/2 and to Switch A through GigabitEthernet 1/0/1. 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
GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 of Switch A even if Host A and Host B
accidentally, temporarily stop receiving IPv6 multicast data.
Network diagram
Figure 4-3 Network diagram for IPv6 group policy simulated joining configuration
Receiver
Host A
Source
GE1/0/4
Receiver
GE1/0/2 GE1/0/1
1::2/64 2001::1/64 GE1/0/1 GE1/0/3
1::1/64 Router A Switch A GE1/0/2 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 4-3. The detailed configuration steps are omitted.
# Enable IPv6 multicast routing, enable IPv6 PIM-DM on each interface, and enable MLDv1 on
[RouterA] multicast ipv6 routing-enable
[RouterA-GigabitEthernet1/0/1] mld enable
[RouterA-GigabitEthernet1/0/1] pim ipv6 dm
4-19

# Enable MLD Snooping globally.
[SwitchA] mld-snooping
[SwitchA-mld-snooping] quit
enable MLD Snooping in the VLAN.
[SwitchA] vlan 100
[SwitchA-vlan100] mld-snooping enable
# 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 GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 as simulated hosts for IPv6 multicast
group FF1E::101.
[SwitchA-GigabitEthernet1/0/3] mld-snooping host-join ff1e::101 vlan 100
[SwitchA-GigabitEthernet1/0/4] 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.
GE1/0/1 (D) ( 00:01:30 )
4-20

IP group address:FF1E::101
(::, FF1E::101):
GE1/0/3 (D) ( 00:03:23 )
GE1/0/4 (D) ( 00:04:10 )
MAC group(s):
MAC group address:3333-0000-1001
GE1/0/3
GE1/0/4
As shown above, GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 of Switch A have joined IPv6
multicast group FF1E::101.
Static Port Configuration
z As shown in Figure 4-4, Router A connects to an IPv6 multicast source (Source) through
GigabitEthernet 1/0/2, and to Switch A through GigabitEthernet 1/0/1.
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 Host A and host C are permanent receivers of IPv6 multicast group FF1E::101. GigabitEthernet
1/0/3 and GigabitEthernet 1/0/5 on Switch C are required to be configured as static member ports
for multicast group 224.1.1.1 to enhance the reliability of multicast traffic transmission.
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
attached to Switch C only along the path of Switch ASwitch BSwitch C.
z It is required to configure GigabitEthernet 1/0/3 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.
4-21

Network diagram
Figure 4-4 Network diagram for static port configuration
Source
Switch A
GE1/0/2 GE1/0/1
1::2/64 2001::1/64 GE1/0/1
/3
GE
1/0
1::1/64 Router A
1/0
GE
/2
MLD querier
/1
GE
1/0
1/0
Switch C
GE
/1
GE1/0/5 GE1/0/2 GE1/0/2
/4
GE
Host C
1/0 Switch B
1/0
GE
Receiver
/3
Host B Host A
Receiver

Enable IPv6 forwarding and configure an IPv6 address and prefix length for each interface as per
Figure 4-4.
# Enable IPv6 multicast routing, enable IPv6 PIM-DM on each interface, and enable MLD on
[SwitchA] vlan 100
4-22

# Configure GigabitEthernet 1/0/3 to be a static router port.

[SwitchA-GigabitEthernet1/0/3] mld-snooping static-router-port vlan 100
[SwitchB] mld-snooping
[SwitchB-mld-snooping] quit
# Create VLAN 100, assign GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to this VLAN, and enable
MLD Snooping in the VLAN.
[SwitchB] vlan 100
[SwitchB-vlan100] port gigabitethernet 1/0/1 gigabitethernet 1/0/2
[SwitchB-vlan100] mld-snooping enable
5) Configure Switch C
[SwitchC] mld-snooping
[SwitchC-mld-snooping] quit
[SwitchC] vlan 100
[SwitchC-vlan100] port gigabitethernet 1/0/1 to gigabitethernet 1/0/5
[SwitchC-vlan100] mld-snooping enable
# Configure GigabitEthernet 1/0/3 and GigabitEthernet 1/0/5 as static member ports for IPv6 multicast
group FF1E::101.
[SwitchC-GigabitEthernet1/0/3] mld-snooping static-group ff1e::101 vlan 100
[SwitchC-GigabitEthernet1/0/5] mld-snooping static-group 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

4-23

Vlan(id):100.
GE1/0/1 (D) ( 00:01:30 )
GE1/0/3 (S)
(::, FF1E::101):
GE1/0/2 (D) ( 00:03:23 )
MAC group(s):
GE1/0/2
As shown above, GigabitEthernet 1/0/3 of Switch A has become a static router port.
# View the detailed MLD Snooping multicast group information in VLAN 100 on Switch C.
[SwitchC] display mld-snooping group vlan 100 verbose

Vlan(id):100.
GE1/0/2 (D) ( 00:01:23 )
(::, FF1E::101):
GE1/0/3 (S)
GE1/0/5 (S)
MAC group(s):
GE1/0/3
GE1/0/5
As shown above, GigabitEthernet 1/0/3 and GigabitEthernet 1/0/5 on Switch C have become static
member ports for IPv6 multicast group FF1E::101.
4-24

MLD Snooping Querier Configuration
z As shown in Figure 4-5, in a Layer-2-only network environment, two multicast sources Source 1
and Source 2 send IPv6 multicast data to multicast groups FF1E::101 and FF1E::102 respectively,
Host A and Host C are receivers of multicast group FF1E::101, while Host B and Host D are
receivers of multicast group FF1E::102.
z MLDv1 is enabled on all the receivers and MLDv1 Snooping is enabled on all the switches. Switch
A, which is close to the multicast sources, is chosen as the MLD Snooping querier.
Network diagram
Figure 4-5 Network diagram for MLD Snooping querier configuration
# Enable IPv6 forwarding and enable MLD Snooping globally.
[SwitchA] ipv6
# Create VLAN 100 and assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/3 to VLAN 100.
[SwitchA] vlan 100
# Enable MLD Snooping and configure MLD Snooping querier feature in VLAN 100.
[SwitchA-vlan100] mld-snooping querier
# Enable IPv6 forwarding and enable MLD Snooping globally.
4-25

[SwitchB] ipv6
[SwitchB] mld-snooping
[SwitchB-mld-snooping] quit
# Create VLAN 100, add GigabitEthernet 1/0/1 through GigabitEthernet 1/0/4 into VLAN 100.
[SwitchB] vlan 100
[SwitchB-vlan100] port gigabitethernet 1/0/1 to gigabitethernet 1/0/4
# Enable the MLD Snooping feature in VLAN 100.

[SwitchB-vlan100] mld-snooping enable
Configurations of Switch C and Switch D are similar to the configuration of Switch B.

When the MLD Snooping querier starts to work, all the switches but the querier receive MLD general
queries. Use the display mld-snooping statistics command to view the statistics information of these
MLD messages received.
# View the MLD message statistics on Switch B.
[SwitchB-vlan100] display mld-snooping statistics
Received MLD general queries:3.
Received MLDv1 specific queries:0.
Received MLDv1 reports:12.
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.
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.
4-26

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.
Analysis
z The IPv6 ACL rule is incorrectly configured.

z The IPv6 multicast group policy is not correctly applied.
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 port 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.
4-27

5 IPv6 Multicast VLAN Configuration
When configuring IPv6 multicast VLAN, go to these sections for information you are interested in:
z Introduction to IPv6 Multicast VLAN
z Multicast VLAN Configuration Task List
z Configuring IPv6 Sub-VLAN-Based IPv6 Multicast VLAN
z Configuring Port-Based IPv6 Multicast VLAN
z Displaying and Maintaining IPv6 Multicast VLAN
z IPv6 Multicast VLAN Configuration Examples
Introduction to IPv6 Multicast VLAN

As shown in Figure 3-1, in the traditional IPv6 multicast programs-on-demand mode, when hosts, Host
A, Host B and Host C, belonging to different VLANs require IPv6 multicast programs on demand
service, the Layer 3 device, Router A, needs to forward a separate copy of the multicast traffic in each
user VLAN to the Layer 2 device, Switch A. This results in not only waste of network bandwidth but
also extra burden on the Layer 3 device.
Figure 5-1 Multicast transmission without IPv6 multicast VLAN
The IPv6 multicast VLAN feature configured on the Layer 2 device is the solution to this issue. With the
IPv6 multicast VLAN feature, the Layer 3 device needs to replicate the multicast traffic only in the IPv6
multicast VLAN instead of making a separate copy of the multicast traffic in each user VLAN. This
saves the network bandwidth and lessens the burden of the Layer 3 device.
The IPv6 multicast VLAN feature can be implemented in two approaches, as described below:
Sub-VLAN-based IPv6 multicast VLAN
As shown in Figure 5-2, Host A, Host B and Host C are in three different user VLANs. On Switch A,
configure VLAN 10 as an IPv6 multicast VLAN, configure all the user VLANs as sub-VLANs of this
IPv6 multicast VLAN, and enable MLD snooping in the IPv6 multicast VLAN.
5-1

Figure 5-2 Sub-VLAN-based IPv6 multicast VLAN
IPv6 Multicast packets
VLAN 10 (IPv6 Multicast VLAN) VLAN 2
VLAN 2
Receiver
VLAN 3
Host A
VLAN 4
VLAN 3
Receiver
Host B
Source Router A Switch A
MLD querier
VLAN 4
Receiver
Host C
After the configuration, MLD snooping manages router ports in the IPv6 multicast VLAN and member
ports in the sub-VLANs. When forwarding multicast data to Switch A, Router A needs to send only one
copy of multicast traffic to Switch A in the IPv6 multicast VLAN, and Switch A distributes the traffic to
the IPv6 multicast VLANs sub-VLANs that contain receivers.
Port-based IPv6 multicast VLAN
As shown in Figure 5-3, Host A, Host B and Host C are in three different user VLANs. All the user ports
are hybrid ports. On Switch A, configure VLAN 10 as an IPv6 multicast VLAN, assign all the user ports
to this IPv6 multicast VLAN, and enable MLD Snooping in the IPv6 multicast VLAN and all the user
VLANs.
Figure 5-3 Port-based IPv6 multicast VLAN
After the configuration, upon receiving an MLD message on a user port, Switch A tags the message
with the IPv6 multicast VLAN ID and relays it to the MLD querier, so that MLD Snooping can uniformly
manage the router ports and member ports in the IPv6 multicast VLAN. When forwarding multicast
data to Switch A, Router A needs to send only one copy of multicast traffic to Switch A in the IPv6
multicast VLAN, and Switch A distributes the traffic to all the member ports in the IPv6 multicast VLAN.
5-2

z For information about MLD Snooping, router ports, and member ports, refer to MLD Snooping
Configuration in the IP Multicast Volume.
z For information about VLAN tags, refer to VLAN Configuration in the Access Volume.
IPv6 Multicast VLAN Configuration Task List

Complete the following tasks to configure IPv6 multicast VLAN:

Configuring IPv6 Sub-VLAN-Based IPv6 Multicast VLAN
Required
Configuring Port-Based IPv6 Configuring User Port Attributes
Multicast VLAN Configuring Multicast VLAN Ports
If you have configured both sub-VLAN-based IPv6 multicast VLAN and port-based IPv6 multicast
VLAN on a device, the port-based IPv6 multicast VLAN configuration is given preference.
Configuring IPv6 Sub-VLAN-Based IPv6 Multicast VLAN

Before configuring sub-VLAN-based IPv6 multicast VLAN, complete the following tasks:
z Enable MLD Snooping in the VLAN to be configured as an IPv6 multicast VLAN
Configuring Sub-VLAN-Based IPv6 Multicast VLAN
In this approach, you configure a VLAN as an IPv6 multicast VLAN, and configure user VLANs as
sub-VLANs of the IPv6 multicast VLAN.
Follow these steps to configure sub-VLAN-based IPv6 multicast VLAN:


as an IPv6 multicast VLAN and multicast-vlan ipv6 vlan-id No IPv6 multicast VLAN
enter IPv6 multicast VLAN view configured by default
5-3


VLAN(s) as sub-VLAN(s) of the subvlan vlan-list By default, an IPv6 multicast
IPv6 multicast VLAN VLAN has no sub-VLANs.
z The VLAN to be configured as an IPv6 multicast VLAN must exist.

z The VLANs to be configured as the sub-VLANs of the IPv6 multicast VLAN must exist and must
not be sub-VLANs of another IPv6 multicast VLAN.
z The total number of sub-VLANs of an IPv6 multicast VLAN must not exceed 63.
Configuring Port-Based IPv6 Multicast VLAN

When configuring port-based IPv6 multicast VLAN, you need to configure the attributes of each user
port and then assign the ports to the IPv6 multicast VLAN.
z A user port can be configured as a multicast VLAN port only if it is of the Ethernet or Layer 2
aggregate port type.
z Configurations made in Ethernet port view are effective only for the current port; configurations
made in Layer 2 aggregate port view are effective only for the current port; configurations made in
port group view are effective for all the ports in the current port group.
Before configuring port-based IPv6 multicast VLAN, complete the following tasks:
z Enable MLD Snooping in the VLAN to be configured as an IPv6 multicast VLAN
z Enable MLD Snooping in all the user VLANs
Configuring User Port Attributes
Configure the user ports as hybrid ports to permit packets of the specified user VLAN to pass and
configure the user VLAN to which the user ports belong as the default VLAN.
Configure the user ports to permit packets of the IPv6 multicast VLAN to pass and untag the packets.
Thus, upon receiving multicast packets tagged with the IPv6 multicast VLAN ID from the upstream
device, the Layer 2 device untags the multicast packets and forwards them to its downstream device.
Follow these steps to configure user port attributes:
5-4

Enter port view or port group interface-number Required
view port-group manual Use either approach.
port-group-name
Configue the user port link type Required

port link-type hybrid
as hybrid Access by default
Specify the user VLAN that Required

comprises the current user port hybrid pvid vlan vlan-id
port(s) as the default VLAN VLAN 1 by default
Configure the current user Required

ports to permit packets of the port hybrid vlan vlan-id-list By default, a hybrid port
specified IPv6 multicast VLAN { tagged | untagged } permits only packets of VLAN 1
to pass and untag the packets to pass.
For details about the port link-type, port hybrid pvid vlan, and port hybrid vlan commands, refer to
VLAN Commands in the Access Volume.
Configuring IPv6 Multicast VLAN Ports
In this approach, you need to configure a VLAN as an IPv6 multicast VLAN and then assign user ports
to this IPv6 multicast VLAN by either adding the user ports in the IPv6 multicast VLAN or specifying the
IPv6 multicast VLAN on the user ports. These two methods give the same result.
Configure IPv6 multicast VLAN ports in IPv6 multicast VLAN view
Follow these steps to configure IPv6 multicast VLAN ports in IPv6 multicast VLAN view:

as an IPv6 multicast VLAN and
multicast-vlan ipv6 vlan-id No IPv6 multicast VLAN
enter IPv6 multicast VLAN
view configured by default
Required
Assign port(s) to the IPv6
port interface-list By default, an IPv6 multicast
multicast VLAN
VLAN has no ports.
5-5

Configure IPv6 multicast VLAN ports in terface view or port group view
Follow these steps to configure IPv6 multicast VLAN ports in port view or port group view:
To do Use this command Remarks


VLAN as an IPv6 multicast
multicast-vlan ipv6 vlan-id Not an IPv6 multicast
VLAN and enter IPv6
multicast VLAN view VLAN by default.
Enter port view or port interface-number Required
group view Use either command.
Required
Configure the port(s) as
port(s) of the IPv6 muticast port multicast-vlan ipv6 vlan-id By default, a user port
VLAN does not belong to any
IPv6 multicast VLAN.
z The VLAN to be configured as an IPv6 multicast VLAN must exist.

z A port can belong to only one IPv6 multicast VLAN.
Displaying and Maintaining IPv6 Multicast VLAN

Display information about an display multicast-vlan ipv6
IPv6 multicast VLAN [ vlan-id ]
IPv6 Multicast VLAN Configuration Examples

Sub-VLAN-Based Multicast VLAN Configuration Example
z As shown in Figure 3-4, Router A connects to an IPv6 multicast source through GigabitEthernet
1/0/1 and to Switch A, through GigabitEthernet 1/0/2.
z MLDv1 is required on Router A, and MLD Snooping is required on Switch A. Router A is the MLD
querier.
are attached to GigabitEthernet 1/0/2 through GigabitEthernet 1/0/4 of Switch A.
z The IPv6 multicast source sends IPv6 multicast data to the IPv6 multicast group FF1E::101. Host
A, Host B, and Host C are receivers of the IPv6 multicast group.
5-6

z Configure the sub-VLAN-based IPv6 multicast VLAN feature so that Router A just sends IPv6
multicast data to Switch A through the IPv6 multicast VLAN and Switch A forwards the traffic to
the receivers that belong to different user VLANs.
Figure 5-4 Network diagram for sub-VLAN-based IPv6 multicast VLAN configuration
Source MLD querier

GE1/0/1 Router A
1:2/64
1::1/64 GE1/0/2
2001::1/64
GE1/0/1
Switch A
GE1/0/2 GE1/0/4
GE1/0/3


Enable IPv6 forwarding on each device and configure an IPv6 address and address prefix for each
interface as per Figure 3-4. The detailed configuration steps are omitted here.
# Enable IPv6 multicast routing, enable IPv6 PIM-DM on each interface and enable MLD on the
host-side interface GigabitEthernet 1/0/2.
# Create VLAN 2 and assign GigabitEthernet 1/0/2 to this VLAN.

[SwitchA] vlan 2
5-7

The configuration for VLAN 3 and VLAN 4 is similar to the configuration for VLAN 2.
# Create VLAN 10, assign GigabitEthernet 1/0/1 to this VLAN and enable MLD Snooping in the VLAN.
[SwitchA] vlan 10
# Configure VLAN 10 as an IPv6 multicast VLAN and configure VLAN 2 through VLAN 4 as its
sub-VLANs.
[SwitchA] multicast-vlan ipv6 10
[SwitchA-ipv6-mvlan-10] subvlan 2 to 4
[SwitchA-ipv6-mvlan-10] quit
# Display information about the IPv6 multicast VLAN.
[SwitchA] display multicast-vlan ipv6
Total 1 IPv6 multicast-vlan(s)
IPv6 Multicast vlan 10
subvlan list:
vlan 2-4
port list:
no port
# View the MLD Snooping IPv6 multicast group information on Switch A.

[SwitchA] display mld-snooping group
Vlan(id):2.
(::, FF1E::101):
GE1/0/2 (D)
MAC group(s):
GE1/0/2
Vlan(id):3.
5-8

(::, FF1E::101):
GE1/0/3 (D)
MAC group(s):
GE1/0/3
Vlan(id):4.
(::, FF1E::101):
GE1/0/4 (D)
MAC group(s):
GE1/0/4
Vlan(id):10.
GE1/0/1 (D)
(::, FF1E::101):
MAC group(s):
As shown above, MLD Snooping is maintaining the router port in the IPv6 multicast VLAN (VLAN 10)
and the member ports in the sub-VLANs (VLAN 2 through VLAN 4).
Port-Based Multicast VLAN Configuration Example
z As shown in Figure 5-5, Router A connects to an IPv6 multicast source (Source) through
GigabitEthernet 1/0/1, and to Switch A through GigabitEthernet 1/0/2.
z MLDv1 is required on Router A. MLDv1 Snooping is required on Switch A. Router A acts as the
MLD querier.
5-9

are attached to GigabitEthernet 1/0/2 through GigabitEthernet 1/0/4 of Switch A.
z The IPv6 multicast source sends IPv6 multicast data to IPv6 multicast group FF1E::101. Host A,
Host B, and Host C are receivers of the IPv6 multicast group.
z Configure the port-based IPv6 multicast VLAN feature so that Router A just sends IPv6 multicast
data to Switch A through the IPv6 multicast VLAN and Switch A forward the IPv6 multicast data to
the receivers that belong to different user VLANs.
Figure 5-5 Network diagram for port-based IPv6 multicast VLAN configuration
Source MLD querier

GE1/0/1 Router A
1:2/64
1::1/64 GE1/0/2
2001::1/64
GE1/0/1
Switch A
GE1/0/2 GE1/0/4
GE1/0/3


Enable IPv6 forwarding on each device and configure the IPv6 address and address prefix for each
interface as per Figure 5-5. The detailed configuration steps are omitted here.
# Enable IPv6 multicast routing, enable IPv6 PIM-DM on each interface, and enable MLD on the
host-side interface GigabitEthernet 1/0/2.
[RouterA-GigabitEthernet1/0/1] ipv6 pim dm
[RouterA-GigabitEthernet1/0/2] ipv6 pim dm
5-10

# Create VLAN 10, assign GigabitEthernet 1/0/1 to VLAN 10, and enable MLD Snooping in this VLAN.
[SwitchA] vlan 10
# Create VLAN 2 and enable MLD Snooping in the VLAN.

[SwitchA] vlan 2
The configuration for VLAN 3 and VLAN 4 is similar. The detailed configuration steps are omitted.
# Configure GigabitEthernet 1/0/2 as a hybrid port. Configure VLAN 2 as the default VLAN. Configue
GigabitEthernet 1/0/2 to permit packets of VLAN 2 to pass and untag the packets when forwarding
them.
[SwitchA-GigabitEthernet1/0/2] port link-type hybrid
[SwitchA-GigabitEthernet1/0/2] port hybrid pvid vlan 2
The configuration for GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 is similar. The detailed
# Configure VLAN 10 as an IPv6 multicast VLAN.
[SwitchA] multicast-vlan ipv6 10
# Assign GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 to IPv6 multicast VLAN 10.
[SwitchA-ipv6-mvlan-10] port gigabitethernet 1/0/2 to gigabitethernet 1/0/3
[SwitchA-ipv6-mvlan-10] quit
# Assign GigabitEthernet 1/0/4 to IPv6 multicast VLAN 10.

[SwitchA-GigabitEthernet1/0/4] port multicast-vlan ipv6 10
# View the IPv6 multicast VLAN information on Switch A.
[SwitchA] display multicast-vlan ipv6
Total 1 IPv6 multicast-vlan(s)
IPv6 Multicast vlan 10
subvlan list:
no subvlan
port list:
GE1/0/2 GE1/0/3 GE1/0/4
# View the MLD Snooping multicast group information on Switch A.

[SwitchA] display mld-snooping group
5-11


Vlan(id):10.
GE1/0/1 (D)
(::, FF1E::101):
GE1/0/2 (D)
GE1/0/3 (D)
GE1/0/4 (D)
MAC group(s):
GE1/0/2
GE1/0/3
GE1/0/4
As shown above, MLD Snooping is maintaining router ports and member ports in VLAN 10.
5-12

Table of Contents
1 QoS Overview 1-1

Introduction to QoS 1-1
Introduction to QoS Service Models 1-1
Best-Effort Service Model1-1
IntServ Service Model 1-1
DiffServ Service Model 1-2
QoS Techniques Overview 1-2
Positions of the QoS Techniques in a Network1-2
2 QoS Configuration Approaches2-1

QoS Configuration Approach Overview 2-1
Non Policy-Based Configuration 2-1
Policy-Based Configuration 2-1
Configuring a QoS Policy2-2
Defining a Class 2-2
Defining a Traffic Behavior 2-4
Defining a Policy2-5
Applying the QoS Policy2-5
Displaying and Maintaining QoS Policies2-8
3 Priority Mapping Configuration3-1

Priority Mapping Overview 3-1
Introduction to Priority Mapping3-1
Priority Mapping Tables3-1
Priority Trust Mode on a Port 3-2
Priority Mapping Procedure3-2
Priority Mapping Configuration Tasks 3-3
Configuring Priority Mapping3-4
Configuring a Priority Mapping Table 3-4
Configuring the Priority Trust Mode on a Port3-4
Configuring the Port Priority of a Port3-5
Displaying and Maintaining Priority Mapping3-5
Priority Mapping Configuration Examples3-5
Priority Mapping Table and Priority Marking Configuration Example3-5
4 Traffic Policing, Traffic Shaping, and Line Rate Configuration4-1

Traffic Policing, Traffic Shaping, and Line Rate Overview4-1
Traffic Evaluation and Token Buckets4-1
Traffic Policing 4-2
Traffic Shaping 4-3
Line Rate 4-4
Configuring Traffic Policing 4-5
Configuring GTS 4-6

Configuring the Line Rate 4-7
Displaying and Maintaining Traffic Policing, GTS, and Line Rate 4-7
5 Congestion Management Configuration 5-1

Congestion Management Overview5-1
Causes, Impacts, and Countermeasures of Congestion5-1
Congestion Management Policies5-1
Congestion Management Configuration Approaches 5-4
Configuring Congestion Management 5-5
Configuring SP Queuing5-5
Configure WRR Queuing5-5
Configuring WFQ Queuing 5-6
Configuring SP+WRR Queues 5-7
Displaying and Maintaining Congestion Management5-9
6 Traffic Filtering Configuration6-1

Traffic Filtering Overview 6-1
Configuring Traffic Filtering6-1
Traffic Filtering Configuration Example6-2
Traffic Filtering Configuration Example 6-2
7 Priority Marking Configuration7-1

Priority Marking Overview 7-1
Configuring Priority Marking7-1
Priority Marking Configuration Example7-2
Priority Marking Configuration Example 7-2
8 Traffic Redirecting Configuration 8-1

Traffic Redirecting Overview8-1
Traffic Redirecting 8-1
Configuring Traffic Redirecting 8-1
9 Traffic Mirroring Configuration 9-1

Traffic Mirroring Overview 9-1
Configuring Traffic Mirroring 9-1
Mirroring Traffic to an Interface 9-1
Mirroring Traffic to the CPU9-2
Displaying and Maintaining Traffic Mirroring9-3
Traffic Mirroring Configuration Examples9-3
Example for Mirroring Traffic to an Interface9-3
10 Class-Based Accounting Configuration10-1

Class-Based Accounting Overview10-1
Configuring Class-Based Accounting 10-1
Displaying and Maintaining Traffic Accounting 10-2
Class-Based Accounting Configuration Example 10-2
ii

Class-Based Accounting Configuration Example10-2
11 User Profile Configuration11-1

User Profile Overview 11-1
User Profile Configuration11-1
User Profile Configuration Task List11-1
Creating a User Profile 11-2
Applying a QoS Policy to User Profile 11-2
Enabling a User Profile11-3
Displaying and Maintaining User Profile 11-3
12 Appendix 12-1
Appendix A Acronym12-1
Appendix B Default Priority Mapping Tables 12-2
Uncolored Priority Mapping Tables 12-2
Appendix C Introduction to Packet Precedences 12-3
IP Precedence and DSCP Values12-3
802.1p Priority 12-5
iii

1 QoS Overview
This chapter covers the following topics:

z Introduction to QoS
z Introduction to QoS Service Models
z QoS Techniques Overview
Introduction to QoS
For network traffic, the Quality of Service (QoS) involves bandwidth, delay, and packet loss rate during
traffic forwarding process. In a network, you can improve the QoS by guaranteeing the bandwidth, and
reducing the delay, jitter, and packet loss rate.
The network resources are always scarce. QoS requirements exist on any occasion where traffic flows
contend for network resources. QoS is a relative concept for traffic flows, that is, guaranteeing QoS for
a certain traffic flow may damage QoS of other traffic flows. For example, in the case of fixed
bandwidth, if a traffic flow gets more bandwidth, the other traffic flows will get less bandwidth and may
be affected. Therefore, the network administrator should reasonably plan and allocate network
resources based on the characteristics of various traffic flows, thus utilizing the network resources
effectively.
The following part introduces the QoS service models, and some mature QoS techniques used most
widely. Using these techniques reasonably in the specific environments, you can improve the QoS
effectively.
Introduction to QoS Service Models

This section covers three typical QoS service models:
z Best-effort service
z Integrated service (IntServ)
z Differentiated service (DiffServ)
Best-Effort Service Model
Best effort is a single service model and also the simplest service model. In the best effort service
model, the network delivers the packets at its best effort but does not guarantee delay or reliability.
The best-effort service model is the default model in the Internet and is applicable to most network
applications. It is implemented through FIFO queuing.
IntServ Service Model
IntServ is a multiple services model that can accommodate multiple QoS requirements. In this model,
an application must request a specific kind of service from the network before it can send data. The
request is made by RSVP signaling. RSVP runs on each device from the source end to the destination
end, and monitors each data flow to prevent each data flow from consuming more resources than the
1-1

requested, reserved, and pre-purchased resources. The Inter-Serv model can definitely identify and
guarantee QoS for each data flow, and provides the most granularly differentiated QoS.
However, the Inter-Serv model imposes extremely high requirements on devices. In a network with
heavy data traffic, the Inter-Serv model imposes very great pressure on the storage and processing
capabilities of devices. On the other hand, the Inter-Serv model is poor in scalability, and therefore, it is
hard to be deployed in the core Internet network.
DiffServ Service Model
DiffServ is a multiple services model that can satisfy diverse QoS requirements. Unlike IntServ,
DiffServ does not require an application to signal the network to reserve resources before sending data.
DiffServ is easy to implement and extend.
All QoS techniques mentioned in this document are based on the Diff-Serv model.
QoS Techniques Overview

The QoS techniques include traffic classification, traffic policing, traffic shaping, line rate, congestion
management, and congestion avoidance. The following part briefly introduces these QoS techniques.
Positions of the QoS Techniques in a Network
Figure 1-1 Positions of the QoS techniques in a network
As shown in Figure 1-1, traffic classification, traffic shaping, traffic policing, congestion management,
and congestion avoidance mainly implement the following functions:
z Traffic classification uses certain match criteria to organize packets with different characteristics
into different classes. Traffic classification is the basis for providing differentiated services.
z Traffic policing polices particular flows entering or leaving a device according to configured
specifications and can be applied in both inbound and outbound directions of a port. When a flow
exceeds the specification, some restriction or punishment measures can be taken to prevent
overconsumption of network resources.
z Traffic shaping proactively adjusts the output rate of traffic to adapt traffic to the network resources
of the downstream device and avoid unnecessary packet drop and congestion. Traffic shaping is
usually applied to the outgoing traffic of a port.
1-2

z Congestion management provides a resource scheduling policy to arrange the forwarding
sequence of packets when congestion occurs. Congestion management is usually applied to the
outgoing traffic of a port.
z Congestion avoidance monitors the usage status of network resources and is usually applied to
the outgoing traffic of a port. As congestion becomes worse, it actively reduces the amount of
traffic by dropping packets.
1-3

2 QoS Configuration Approaches
This chapter covers the following topics:

z QoS Configuration Approach Overview
z Configuring a QoS Policy
QoS Configuration Approach Overview

Two approaches are available for you to configure QoS: policy-based and non policy-based.
Some QoS features can be configured in either approach while some can be configured only in one
approach.
Non Policy-Based Configuration
In the non policy-based approach, you configure QoS service parameters without using a QoS policy.
For example, to rate limit an interface, you can use the line rate feature to directly configure a rate limit
on the interface rather than using a QoS policy.
Policy-Based Configuration
In the policy-based approach, QoS service parameters are configured through configuring QoS
policies. A QoS policy defines what QoS actions to take on what class of traffic for purposes such as
traffic shaping or traffic policing.
Before configuring a QoS policy, be familiar with these concepts: class, traffic behavior, and policy.
Class
Classes are used to identify traffic.

A class is identified by a class name and contains some match criteria for traffic identification. The
relationship between the criteria is AND or OR.
z AND: A packet is considered as belonging to a class only when the packet matches all the criteria
in the class.
z OR: A packet is considered as belonging to a class if it matches any of the criteria in the class.
Traffic behavior
A traffic behavior defines a set of QoS actions to take on packets, such as priority marking and traffic
redirecting.
Policy
A policy associates a class with a traffic behavior to define what actions to take on which class of
traffic.
You can configure multiple class-behavior associations in a policy.

Configuring a QoS Policy
Figure 2-1 shows how to configure a QoS policy.
Figure 2-1 QoS policy configuration procedure
Define a class
Define a behavior
Define a policy
Apply the policy
Apply the Apply the Apply the Apply the

policy to an policy to policy to a policy
interface online VLAN globally
users
Defining a Class
To define a class, you need to specify a name for it and then configure match criteria in class view.
Follow these steps to define a class:

Required
Create a class and enter class traffic classifier tcl-name
view [ operator { and | or } ] By default, the relationship
between match criteria is AND.
Configure match criteria if-match match-criteria Required
match-criteria: Match criterion. Table 2-1 shows the available criteria.
Table 2-1 The keyword and argument combinations for the match-criteria argument
Form Description
Specifies to match an IPv4 ACL specified by its
number or name. The access-list-number
acl { access-list-number | name acl-name } argument specifies an ACL by its number, which
ranges from 2000 to 4999; the name acl-name
keyword-argument combination specifies an
ACL by its name.

Form Description
Specifies to match an IPv6 ACL specified by its
number or name. The access-list-number
acl ipv6 { access-list-number | name acl-name } argument specifies an ACL by its number, which
ranges from 2000 to 3999; the name acl-name
keyword-argument combination specifies an
ACL by its name.
any Specifies to match all packets.
Specifies to match packets by 802.1p priority of
the customer network. The 8021p-list argument
is a list of CoS values, in the range of 0 to 7.
customer-dot1p 8021p-list
Even though you can provide up to eight
space-separated CoS values for this argument,
the Switch 4510G series switches support only
one CoS value in a rule. If you configure multiple
CoS values in a rule, the rule cannot be issued.
Specifies to match the packets of specified
VLANs of user networks. The vlan-id-list
argument specifies a list of VLAN IDs, in the
form of vlan-id to vlan-id or multiple
discontinuous VLAN IDs (separated by space).
You can specify up to eight VLAN IDs for this
customer-vlan-id vlan-id-list argument at a time. VLAN ID is in the range 1 to
4094.
In a class configured with the operator and, the
logical relationship between the customer VLAN
IDs specified for the customer-vlan-id keyword
is or.
Specifies to match the packets with a specified
destination-mac mac-address
destination MAC address.
Specifies to match packets by DSCP
precedence. The dscp-list argument is a list of
DSCP values in the range of 0 to 63.
dscp dscp-list Even though you can provide up to eight

space-separated DSCP values for this
argument, the Switch 4510G series switches
support only one DSCP value in a rule. If you
configure multiple DSCP values in a rule, the
rule cannot be issued.
Specifies to match packets by IP precedence.
The ip-precedence-list argument is a list of IP
precedence values in the range of 0 to 7.
ip-precedence ip-precedence-list Even though you can provide up to eight

space-separated IP precedence values for this
argument, the Switch 4510G series switches
support only one IP precedence value in a rule.
If you configure multiple IP precedence values in
a rule, the rule cannot be issued.
Specifies to match the packets of a specified
protocol protocol-name protocol. The protocol-name argument can be
IP or IPv6.

Form Description
Specifies to match packets by 802.1p priority of
the service provider network. The 8021p-list
argument is a list of CoS values in the range of 0
to 7.
service-dot1p 8021p-list
Even though you can provide up to eight
space-separated CoS values for this argument,
the Switch 4510G series switches support only
one CoS value in a rule. If you configure multiple
CoS values in a rule, the rule cannot be issued.
Specifies to match the packets of the VLANs of
the operators network. The vlan-id-list argument
is a list of VLAN IDs, in the form of vlan-id to
vlan-id or multiple discontinuous VLAN IDs
(separated by space). You can specify up to
service-vlan-id vlan-id-list eight VLAN IDs for this argument at a time.
VLAN ID is in the range of 1 to 4094.
In a class configured with the operator and, the
logical relationship between the service VLAN
IDs specified for the service-vlan-id keyword is
or.
Specifies to match the packets with a specified
source-mac mac-address
source MAC address.
Suppose the logical relationship between classification rules is and. Note the following when using the
if-match command to define matching rules.
z If multiple matching rules with the acl or acl ipv6 keyword specified are defined in a class, the
actual logical relationship between these rules is or when the policy is applied.
z If multiple matching rules with the customer-vlan-id or service-vlan-id keyword specified are
defined in a class, the actual logical relationship between these rules is or.
Defining a Traffic Behavior
To define a traffic behavior, you must first create it and then configure QoS actions such as priority
marking and redirect in traffic behavior view.
Follow these steps to define a traffic behavior:

Create a traffic behavior and traffic behavior

Required
enter traffic behavior view behavior-name
Refer to the subsequent sections depending on the purpose of
Configure other actions in the
the traffic behavior: traffic policing, traffic filtering, traffic
traffic behavior
redirecting, priority marking, traffic accounting and so on.

Defining a Policy
In a policy, you can define multiple class-behavior associations. A behavior is performed for the
associated class of packets. In this way, various QoS features can be implemented.
Follow these steps to associate a class with a behavior in a policy:

Create a policy and enter

qos policy policy-name Required
policy view
Required
Specify the
Associate a class with a classifier tcl-name behavior dot1q-tag-manipulation
behavior in the policy behavior-name keyword if the class-behavior
association is defined for VLAN
mapping.
z If an ACL is referenced by a QoS policy for defining traffic match criteria, packets matching the
ACL are organized as a class and the behavior defined in the QoS policy applies to the class
regardless of whether the match mode of the if-match clause is deny or permit.
z In a QoS policy with multiple class-to-traffic-behavior associations, if the action of creating an
outer VLAN tag, the action of setting customer network VLAN ID, or the action of setting service
provider network VLAN ID is configured in a traffic behavior, we recommend you not to configure
any other action in this traffic behavior. Otherwise, the QoS policy may not function as expected
after it is applied.
Applying the QoS Policy
You can apply a QoS policy to different occasions:

z Applied to an interface, the policy takes effect on the traffic sent or received on the interface.
z Applied to a user profile, the policy takes effect on the traffic sent or received by the online users
of the user profile.
z Applied to a VLAN, the policy takes effect on the traffic sent or received on all ports in the VLAN.
z Applied globally, the policy takes effect on the traffic sent or received on all ports.

z You cannot modify the classification rules, traffic behaviors, and classifier-behavior associations in
a QoS policy already applied. To check whether a QoS policy has been applied successfully, use
the display qos policy global command and the display qos policy interface command.
z The switch may save the applications of some QoS policies that have failed to be applied due to
insufficient hardware resources in the configuration file. After the switch reboots, these policies
may preempt other user configurations for resources, resulting in loss of configurations. Suppose
that the user-bind command is configured on GigabitEthernet 1/0/2, and the application of a QoS
policy to GigabitEthernet 1/0/1 is saved in the configuration file even though the application has
failed due to insufficient resources. After the switch reboots, it may assign resources to have the
QoS policy take effect preferentially, while the user-bind configuration may be lost due to
insufficient resources.
Applying the QoS policy to an interface
A policy can be applied to multiple ports. Only one policy can be applied in inbound direction of a
port/port group.
Follow these steps to apply the QoS policy to an interface:

Enter Use either command
Enter interface Settings in interface view take
interface-number
interface view effect on the current interface;
view or port settings in port group view take
group view Enter port port-group manual effect on all ports in the port
group view port-group-name group.
Apply the policy to the qos apply policy policy-name
Required
interface/port group inbound
Applying the QoS policy to online users
You can apply a QoS policy to multiple online users, but in one direction of each online user only one
policy can be applied. To modify a QoS policy already applied in a certain direction, remove the QoS
policy application first.
Follow these steps to apply the QoS policy to online users:


Required
The configuration made in
user profile view takes effect
when the user-profile is
activated and there are online
Enter user profile view user-profile profile-name dot1x
users.
Refer to User Profile
Configuration in the QoS
Volume for more information
about user profiles.
Required
Use the inbound keyword to
apply the QoS policy to the
qos apply policy policy-name traffic received by the online
Apply the QoS policy
{ inbound | outbound } users. Use the outbound
keyword to apply the QoS
policy to the traffic sent by the
online users.
Required
Activate the user profile user-profile profile-name enable
Inactive by default
z If a user profile is active, the QoS policy, except ACLs referenced in the QoS policy, applied to it
cannot be configured or removed. If the user profile is being used by online users, the referenced
ACLs cannot be modified either.
z The QoS policies applied in user profile view support only the remark, car, and filter actions.
z Do not apply an empty policy in user profile view because a user profile with an empty policy
applied cannot be activated.
z Refer to User Profile Configuration in the QoS Volume for more information about user profiles.
Applying the QoS policy to a VLAN
You can apply a QoS policy to a VLAN to regulate traffic of the VLAN.
Follow these steps to apply the QoS policy to a VLAN:

qos vlan-policy policy-name
Apply the QoS policy to VLANs Required
vlan vlan-id-list inbound

z QoS policies cannot be applied to dynamic VLANs, for example, VLANs created by GVRP.
z Do not apply a QoS policy to a VLAN and the ports in the VLAN at the same time.
z A QoS policy containing any of the nest, remark customer-vlan-id, and remark service-vlan-id
actions cannot be applied to a VLAN.
Applying the QoS policy globally
You can apply a QoS policy globally to the inbound or outbound direction of all ports.
Follow these steps to apply the QoS policy globally:

qos apply policy policy-name
Apply the QoS policy globally Required
global inbound
A QoS policy containing any of the nest, remark customer-vlan-id, and remark service-vlan-id
Actions cannot be applied globally.
Displaying and Maintaining QoS Policies

Display information about a display qos policy
class and the corresponding user-defined [ policy-name Available in any view
actions associated by a policy [ classifier classifier-name ] ]
display qos policy interface
[ interface-type Available in any view
policies applied on a port
interface-number ] [ inbound ]
display traffic behavior
Display information about a
user-defined Available in any view
traffic behavior
[ behavior-name ]
display traffic classifier
class
[ classifier-name ]
Display information about a display qos policy global
global QoS policy [ slot slot-number ] [ inbound ]
display qos vlan-policy
Display information about QoS { name policy-name | vlan
policies applied to VLANs [ vlan-id ] } [ slot slot-number ]
[ inbound ]

Clear the statistics of a global reset qos policy global
QoS policy [ inbound ]
Clear the statistics of QoS reset qos vlan-policy [ vlan
policies applied to VLANs vlan-id ] [ inbound ]

3 Priority Mapping Configuration
When configuring priority mapping, go to these sections for information you are interested in:
z Priority Mapping Overview
z Priority Mapping Configuration Tasks
z Configuring Priority Mapping
z Displaying and Maintaining Priority Mapping
z Priority Mapping Configuration Examples
Priority Mapping Overview

Introduction to Priority Mapping
The priorities of a packet determine its transmission priority. There are two types of priority: priorities
carried in packets and priorities locally assigned for scheduling only.
The packet-carried priorities include 802.1p priority, DSCP precedence, IP precedence, EXP, and so
on. These priorities have global significance and affect the forwarding priority of packets across the
network.
The locally assigned priorities have only local significance. They are assigned by the device for
scheduling only. These priorities include the local precedence and drop precedence, as follows.
z Local precedence is used for queuing. A local precedence value corresponds to an output queue.
A packet with higher local precedence is assigned to a higher priority output queue to be
preferentially scheduled.
z Drop precedence is used for making packet drop decisions. Packets with the highest drop
precedence are dropped preferentially.
When a packet enters the device from a port, the device assigns a set of QoS priority parameters to
the packet based on a certain priority and sometimes may modify its priority, according to certain rules
depending on device status. This process is called priority mapping. The priority based on which
priority mapping is performed depends on the priority trust mode configured on the port (see section
Priority Trust Mode on a Port. The set of QoS priority parameters decides the scheduling priority and
forwarding priority of the packet.
Priority Mapping Tables
Priority mapping is implemented with priority mapping tables. The device provides various types of
priority mapping tables, or rather, priority mappings. By looking up a priority mapping table, the device
decides which priority value is to assign to a packet for subsequent packet processing.
z dot1p-dp: 802.1p-to-drop priority mapping table.
z dot1p-lp: 802.1p-to-local priority mapping table.
z dscp-dot1p: DSCP-to-802.1p priority mapping table, which is applicable to only IP packets.
z dscp-dp: DSCP-to-drop priority mapping table, which is applicable to only IP packets.
z dscp-dscp: DSCP-to-DSCP priority mapping table, which is applicable to only IP packets.
3-1

The default priority mapping tables (as shown in Appendix B Default Priority Mapping Tables) are
available for priority mapping. Generally, they are sufficient for priority mapping. If a default priority
mapping table cannot meet your requirements, you can modify the priority mapping table as required.
Priority Trust Mode on a Port
The priority trust mode on a port decides which priority is used for priority mapping table lookup. For
the priority mapping purpose, port priority was introduced so that you can use it for priority mapping in
addition to priority fields carried in packets. There are three priority trust modes on Switch 4510G
series :
z dot1p: Uses the 802.1p priority carried in packets for priority mapping.
z dscp: Uses the DSCP carried in packets for priority mapping.
z undo qos trust: Uses the port priority as the 802.1p priority for priority mapping. The port priority
is user configurable.
The priority mapping procedure varies with the priority modes, as described in the next section Priority
Mapping Procedure.
Priority Mapping Procedure

Upon receiving an Ethernet packet on a port, the switch marks the scheduling priorities (local
precedence and drop precedence) for the Ethernet packet according to the priority trust mode of the
receiving port and the 802.1q tagging status of the packet, as shown in Figure 3-1.
3-2

Figure 3-1 Priority mapping procedure for an Ethernet packet
Receive a packet
on a port
Which priority is
802.1p
trusted on the Port priority
in packets
port?
Use the port

priority as the
Use the port priority N DSCP 802.1p priority for
Is the packet
as the 802.1p priority in packets priority mapping
802.1q tagged?
for priority mapping
Y
Look up the dot1p-dp Look up the dscp-dp, Look up the dot1p-
Look up the dot1p-dp dscp-dot1p, and dscp-
and dot1p-lp and dot1p-lp mapping dp, and dot1p-lp
dscp mapping tables mapping tables
mapping tables tables
Mark the packet with

Mark the packet with Mark the packet with Mark the packet
802.1p priority, drop
local precedence and local precedence and with local
precedence, and new
drop precedence drop precedence precedence and
DSCP precedence
drop precedence
Look up the dot1p-lp

Mapping table
Mark the packet with

local precedence
Schedule the packet

according to its local and
drop precedence
The priority mapping procedure presented above applies in the absence of priority marking. If priority
marking is configured, the device performs priority marking before priority mapping, and then uses the
re-marked packet-carried priority for priority mapping or directly uses the re-marked scheduling priority
for traffic scheduling depending on your configuration. In this case, neither priority trust mode
configuration on the port nor port priority configuration takes effect.
Priority Mapping Configuration Tasks

You can modify priority mappings by modifying priority mapping tables, priority trust mode on a port,
and port priority.
You are recommended to plan QoS throughout the network before making QoS configuration.
Complete the following task to configure priority mapping:
3-3

Task Remarks
Configuring a Priority Mapping Table Optional
Configuring the Priority Trust Mode on a Port Optional
Configuring the Port Priority of a Port Optional
Configuring Priority Mapping

Configuring a Priority Mapping Table
Follow these steps to configure an uncolored priority mapping table:

qos map-table { dot1p-dp |

Enter priority mapping table
dot1p-lp | dscp-dot1p | Required
view
dscp-dp | dscp-dscp }
Required
Configure the priority mapping import import-value-list export
table export-value Newly configured mappings
overwrite the old ones.
display qos map-table
Display the configuration of the [ dot1p-dp | dot1p-lp | Optional
priority mapping table dscp-dot1p | dscp-dp | Available in any view
dscp-dscp ]
You cannot configure mapping any DSCP value to drop precedence 1.
Configuring the Priority Trust Mode on a Port
Follow these steps to configure the trusted packet priority type on an interface/port group:


interface-number
Trust the
Configure 802.1p or Use either command
the priority DSCP qos trust { dot1p | dscp } By default, the device trusts the
trust mode priority in port priority.
packets
3-4

Trust the undo qos trust

port priority
Display the priority trust Optional
display qos trust interface
mode configuration on
[ interface-type interface-number ] Available in any view
the port
Configuring the Port Priority of a Port
You can change the port priority of a port used for priority mapping. For the priority mapping procedure,
see Figure 3-1.
Follow these steps to configure the port priority of a port for priority mapping:


interface
interface interface-number Settings in interface view take effect
view
view or port on the current interface; settings in
group view Enter port port-group manual port group view take effect on all
group view port-group-name ports in the port group.
Required
Configure the port priority qos priority priority-value
The default port priority is 0.
Displaying and Maintaining Priority Mapping

display qos map-table
Display priority mapping table [ dot1p-dp | dot1p-lp |
configuration dscp-dot1p | dscp-dp |
dscp-dscp ]
display qos trust interface
Display the trusted packet
priority type on a port
interface-number ]
Priority Mapping Configuration Examples

Priority Mapping Table and Priority Marking Configuration Example
For information about priority marking, refer to Priority Marking Configuration.
3-5

As shown in Figure 3-2, the enterprise network of a company interconnects all departments through
Device. The network is described as follows:
z The marketing department connects to GigabitEthernet 1/0/1 of Device, which sets the 802.1p
priority of traffic from the marketing department to 3.
z The R&D department connects to GigabitEthernet 1/0/2 of Device, which sets the 802.1p priority
of traffic from the R&D department to 4.
z The management department connects to GigabitEthernet 1/0/3 of Device, which sets the 802.1p
priority of traffic from the management department to 5.
Configure port priority, 802.1p-to-local priority mapping table, and priority marking to implement the
plan as described in Table 3-1.
Table 3-1 Configuration plan
Queuing plan
Traffic
Traffic Priority order Output Queue
destination Traffic source
queue priority
R&D department 6 High
R&D department > Management
4 Medium
Public servers management department > department
marketing department
Marketing
2 Low
department
R&D department 2 Low
management department > Management
Internet 6 High
marketing department > R&D department
through HTTP
department
Marketing
4 Medium
department
3-6

Figure 3-2 Network diagram for priority mapping table and priority marking configuration
Internet
Host Host
Server Server
GE1/0/5
Management department GE1/0/3 GE1/0/2

R&D department
GE1/0/4 GE1/0/1
Device Host
Server
Public servers Marketing department
1) Configure trusting port priority

# Set the port priority of GigabitEthernet 1/0/1 to 3.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] qos priority 3

[Device-GigabitEthernet1/0/2] qos priority 4

[Device-GigabitEthernet1/3] qos priority 5
[Device-GigabitEthernet1/3] quit
2) Configure the priority mapping table
# Configure the 802.1p-to-local priority mapping table to map 802.1p priority values 3, 4, and 5 to local
precedence values 2, 6, and 4.
[Device] qos map-table dot1p-lp
[Device-maptbl-dot1p-lp] import 3 export 2
[Device-maptbl-dot1p-lp] quit
3-7

3) Configure priority marking
# Mark the HTTP traffic of the management department, marketing department, and R&D department
to the Internet with 802.1p priorities 4, 5, and 3 respectively. Use the priority mapping table configured
above to map the 802.1p priorities to local precedence values 6, 4, and 2 respectively for differentiated
traffic treatment.
# Create ACL 3000 to match HTTP traffic.
[Device] acl number 3000
[Device-acl-adv-3000] rule permit tcp destination-port eq 80
[Device-acl-adv-3000] quit
# Create class http and reference ACL 3000 in the class.

[Device] traffic classifier http
[Device-classifier-http] if-match acl 3000
[Device-classifier-http] quit
# Configure a priority marking policy for the management department and apply the policy to the
incoming traffic of GigabitEthernet 1/0/3.
[Device] traffic behavior admin
[Device-behavior-admin] remark dot1p 4
[Device-behavior-admin] quit
[Device] qos policy admin
[Device-qospolicy-admin] classifier http behavior admin
[Device-qospolicy-admin] quit
[Device-GigabitEthernet1/0/3] qos apply policy admin inbound
# Configure a priority marking policy for the marketing department and apply the policy to the incoming
traffic of GigabitEthernet 1/0/1.
[Device] traffic behavior market
[Device-behavior-market] remark dot1p 5
[Device-behavior-market] quit
[Device] qos policy market
[Device-qospolicy-market] classifier http behavior market
[Device-qospolicy-market] quit
[Device-GigabitEthernet1/0/1] qos apply policy market inbound
# Configure a priority marking policy for the R&D department and apply the policy to the incoming
traffic of GigabitEthernet 1/0/2.
[Device] traffic behavior rd
[Device-behavior-rd] remark dot1p 3
[Device-behavior-rd] quit
[Device] qos policy rd
[Device-qospolicy-rd] classifier http behavior rd
[Device-qospolicy-rd] quit
[Device-GigabitEthernet1/0/2] qos apply policy rd inbound
3-8

4 Traffic Policing, Traffic Shaping, and Line Rate
Configuration
When configuring traffic policing, traffic shaping and line rate, go to these sections for information you
are interested in:
z Traffic Policing, Traffic Shaping, and Line Rate Overview
z Configuring Traffic Policing
z Configuring GTS
z Configuring the Line Rate
z Displaying and Maintaining Traffic Policing, GTS, and Line Rate
Traffic Policing, Traffic Shaping, and Line Rate Overview

Without limits on user traffic, a network can be overwhelmed very easily. To help assign network
resources such as bandwidth efficiently to improve network performance and hence user satisfaction,
QoS technologies such as traffic policing, traffic shaping, and rate limit were introduced. For example,
you can configure a flow to use only the resources committed to it in a certain time range, thus
avoiding network congestion caused by burst traffic.
Traffic policing and generic traffic shaping (GTS) limit traffic rate and resource usage according to
traffic specifications. Once a particular traffic exceeds its specifications such as bandwidth assigned to
it, it is shaped or policed to ensure that it is under the specifications. Generally, token buckets are used
to evaluate traffic specifications.
Traffic Evaluation and Token Buckets
Token bucket features
A token bucket is analogous to a container holding a certain number of tokens. The system puts tokens
into the bucket at a set rate. When the token bucket is full, the extra tokens overflows.
Evaluating traffic with the token bucket
The evaluation of traffic specifications is based on whether the number of tokens in the bucket can
meet the need of packet forwarding. Generally, one token is associated with a 1-bit forwarding
authority. If the number of tokens in the bucket is enough for forwarding the packets, the traffic
conforms to the specification and is called conforming traffic; otherwise, the traffic does not conform to
the specification and is called excess traffic.
A token bucket has the following configurable parameters:
z Mean rate: At which tokens are put into the bucket, namely, the permitted average rate of traffic. It
is usually set to the committed information rate (CIR).
z Burst size: the capacity of the token bucket, namely, the maximum traffic size that is permitted in
each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater
than the maximum packet size.
4-1

One evaluation is performed on each arriving packet. In each evaluation, if the number of tokens in the
bucket is enough, the traffic conforms to the specification and the corresponding tokens for forwarding
the packet are taken away; if the number of tokens in the bucket is not enough, it means that too many
tokens have been used and the traffic is excessive.
Complicated evaluation
You can set two token buckets (referred to as the C bucket and E bucket respectively) in order to
evaluate more complicated conditions and implement more flexible regulation policies. For example,
traffic policing uses four parameters:
z CIR: Rate at which tokens are put into the C bucket, that is, the average packet transmission or
forwarding rate allowed by the C bucket.
z CBS: Size of the C bucket, that is, transient burst of traffic that the C bucket can forward.
z Peak information rate (PIR): Rate at which tokens are put into the E bucket, that is, the average
packet transmission or forwarding rate allowed by the E bucket.
z Excess burst size (EBS): Size of the E bucket, that is, transient burst of traffic that the E bucket
can forward.
CBS and EBS are carried by two different token buckets. In each evaluation, packets are measured
against the buckets:
z If the C bucket has enough tokens, packets are colored green.
z If the C bucket does not have enough tokens but the E bucket has enough tokens, packets are
colored yellow.
z If neither the C bucket nor the E bucket has sufficient tokens, packets are colored red.
Traffic Policing
The typical application of traffic policing is to supervise the specification of certain traffic entering a
network and limit it within a reasonable range, or to "discipline" the extra traffic. In this way, the network
resources and the interests of the carrier are protected. For example, you can limit bandwidth
consumption of HTTP packets to less than 50% of the total. If the traffic of a certain session exceeds
the limit, traffic policing can drop the packets or reset the IP precedence of the packets.
Figure 4-1 Schematic diagram for traffic policing
Tokens are put into the

bucket at the set rate
Packets to be sent
through this interface
Packets sent
Packet
classification
Token
bucket
Queue
Packets dropped
4-2

Traffic policing is widely used in policing traffic entering the networks of internet service providers
(ISPs). It can classify the policed traffic and perform pre-defined policing actions based on different
evaluation results. These actions include:
z Forwarding the traffic if the evaluation result is conforming.
z Dropping the traffic if the evaluation result is excess.
z Marking a conforming packet or a non-conforming packet with a new DSCP precedence value and
forwarding the packet.
Traffic Shaping
Traffic shaping supports shaping traffic to the outgoing traffic.
Traffic shaping provides measures to adjust the rate of outbound traffic actively. A typical traffic
shaping application is to limit the local traffic output rate according to the downstream traffic policing
parameters.
The difference between traffic policing and GTS is that packets to be dropped in traffic policing are
cached in a buffer or queue in GTS, as shown in Figure 4-2. When there are enough tokens in the
token bucket, these cached packets are sent at an even rate. Traffic shaping may result in an
additional delay while traffic policing does not.
Figure 4-2 Schematic diagram for GTS
For example, in Figure 4-3, Switch A sends packets to Switch B. Switch B performs traffic policing on
packets from Switch A and drops packets exceeding the limit.
4-3

Figure 4-3 GTS application
You can perform traffic shaping for the packets on the outgoing interface of Switch A to avoid
unnecessary packet loss. Packets exceeding the limit are cached in Switch A. Once resources are
released, traffic shaping takes out the cached packets and sends them out. In this way, all the traffic
sent to Switch B conforms to the traffic specification defined in Switch B.
Line Rate
Line rate supports rate-limiting traffic in the outbound direction.
The line rate of a physical interface specifies the maximum rate for forwarding packets (including
critical packets).
Line rate also uses token buckets for traffic control. With line rate configured on an interface, all
packets to be sent through the interface are firstly handled by the token bucket at line rate. If there are
enough tokens in the token bucket, packets can be forwarded; otherwise, packets are put into QoS
queues for congestion management. In this way, the traffic passing the physical interface is controlled.
Figure 4-4 Line rate implementation
In the token bucket approach to traffic control, bursty traffic can be transmitted so long as enough
tokens are available in the token bucket; if tokens are inadequate, packets cannot be transmitted until
4-4

the required number of tokens are generated in the token bucket. Thus, traffic rate is restricted to the
rate for generating tokens, thus limiting traffic rate and allowing bursty traffic.
Line rate can only limit the total traffic rate on a physical port, while traffic policing can limit the rate of a
flow on a port. To limit the rate of all the packets on a port, using line rate is easier.
Configuring Traffic Policing

Follow these steps to configure traffic policing:

Create a class and enter traffic classifier tcl-name [ operator

class view { and | or } ]
Configure the match
if-match match-criteria
criteria
Exit class view quit
Create a behavior and

traffic behavior behavior-name
enter behavior view
car cir committed-information-rate

[ cbs committed-burst-size [ ebs
Configure a traffic policing
excess-burst-size ] ] [ pir Required
action
peak-information-rate ] [ green action ]
[ red action ] [ yellow action ]
Exit behavior view quit

qos policy policy-name
policy view
Associate the class with
classifier tcl-name behavior
the traffic behavior in the
behavior-name
QoS policy
Exit policy view quit
To an interface Applying the QoS policy to an interface
Apply the To online Applying the QoS policy to online

QoS users users
policy To a VLAN Applying the QoS policy to a VLAN
Globally Applying the QoS policy globally
Configure traffic policing on GigabitEthernet 1/0/1 to limit the rate of received HTTP traffic to 512 kbps
and drop the exceeding traffic.
# Configure advanced ACL 3000 to match HTTP traffic.

[Sysname] acl number 3000
4-5

[Sysname-acl-adv-3000] rule permit tcp destination-port eq 80
[Sysname-acl-adv-3000] quit
# Create a class named http, and reference ACL 3000 in the class to match HTTP traffic.
[Sysname] traffic classifier http
[Sysname-classifier-http] if-match acl 3000
[Sysname-classifier-http] quit
# Configure a traffic policing QoS policy, and apply the QoS policy to the incoming packets of
[Sysname] traffic behavior http
[Sysname-behavior-http] car cir 512
[Sysname-behavior-http] quit
[Sysname] qos policy http
[Sysname-qospolicy-http] classifier http behavior http
[Sysname-qospolicy-http] quit
[Sysname-GigabitEthernet1/0/1] qos apply policy http inbound
Configuring GTS
On the Switch 4510G series, traffic shaping is implemented as queue-based GTS, that is, configuring
GTS parameters for packets of a certain queue.
Follow these steps to configure queue-based GTS:

Enter Enter Use either command

interface interface
interface-number Settings in interface view take
view or view
effect on the current interface;
port Enter port settings in port group view take
group group port-group manual port-group-name effect on all ports in the port
view view group.
qos gts queue queue-number cir

Configure GTS for a
committed-information-rate [ cbs Required
queue
committed-burst-size ]
Configure GTS on GigabitEthernet1/0/1, shaping the packets of queue 1 when the sending rate
exceeds 512 kbps.
# Enter interface view.

# Configure GTS parameters.
4-6

[Sysname-GigabitEthernet1/0/1] qos gts queue 1 cir 512
Configuring the Line Rate

Follow these steps to configure the line rate:

interface
interface interface-number Settings in interface view take
view
view or effect on the current interface;
port group Enter port settings in port group view take
port-group manual effect on all ports in the port
view group
port-group-name group.
view
Configure the outbound qos lr outbound cir
line rate for the committed-information-rate [ cbs Required
interface/port group committed-burst-size ]
Limit the outbound line rate of GigabitEthernet 1/0/1 to 512 kbps.

# Enter interface view.

# Limit the outbound line rate of GigabitEthernet 1/0/1 to 512 kbps.

[Sysname-GigabitEthernet1/0/1] qos lr outbound cir 512
Displaying and Maintaining Traffic Policing, GTS, and Line Rate
On the Switch 4510G series, you can configure traffic policing in policy-based approach. For related
displaying and maintaining commands, refer to Displaying and Maintaining QoS Policies.

display qos gts interface
Display interface GTS
interface-number ]
display qos lr interface
Display interface line rate
interface-number ]
4-7

4-8

5 Congestion Management Configuration
When configuring hardware congestion management, go to these sections for information you are
interested in:
z Congestion Management Overview
z Congestion Management Configuration Approaches
z Configuring Congestion Management
z Displaying and Maintaining Congestion Management
Congestion Management Overview

Causes, Impacts, and Countermeasures of Congestion
Network congestion is a major factor contributed to service quality degrading on a traditional network.
Congestion is a situation where the forwarding rate decreases due to insufficient resources, resulting
in extra delay.
Congestion easily occurs in complex packet switching circumstances in the Internet. The following
figure shows two common cases:
Figure 5-1 Traffic congestion causes
100M
100M 10M 10M 100M
100M>10M
50M
100M+10M+50M>100M
1 2
Congestion may bring these negative results:

z Increased delay and jitter during packet transmission
z Decreased network throughput and resource use efficiency
z Network resource (memory in particular) exhaustion and even system breakdown
Congestion is unavoidable in switched networks and multi-user application environments. To improve
the service performance of your network, you must take some proper measures to address the
congestion issues.
The key to congestion management is how to define a dispatching policy for resources to decide the
order of forwarding packets when congestion occurs.
Congestion Management Policies
In general, congestion management uses queuing technology. The system uses a certain queuing
algorithm for traffic classification, and then uses a certain precedence algorithm to send the traffic.
5-1

Each queuing algorithm addresses a particular network traffic problem and which algorithm is used
affects bandwidth resource assignment, delay, and jitter significantly.
The Switch 4510G series support the following four queue scheduling methods:
z Scheduling all queues with the strict priority (SP) algorithm.
z Scheduling all queues with the weighted round robin (WRR) algorithm.
z Scheduling all queues with the weighted fair queuing (WFQ) algorithm
z Scheduling some queues with the SP algorithm and some with the WRR algorithm.
This section describes how SP, WRR, WFQ, and SP+WRR work in details.
SP queuing
SP queuing is specially designed for mission-critical applications, which require preferential service to
reduce the response delay when congestion occurs.
Figure 5-2 Schematic diagram for SP queuing
As shown in Figure 5-2, SP queuing classifies eight queues on a port into eight classes, numbered 7 to
0 in descending priority order.
SP queuing schedules the eight queues strictly according to the descending order of priority. It sends
packets in the queue with the highest priority first. When the queue with the highest priority is empty, it
sends packets in the queue with the second highest priority, and so on. Thus, you can assign
mission-critical packets to the high priority queue to ensure that they are always served first and
common service packets to the low priority queues and transmitted when the high priority queues are
empty.
The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if
there are packets in the higher priority queues. This may cause lower priority traffic to starve to death.
WRR queuing
WRR queuing schedules all the queues in turn to ensure that every queue can be served for a certain
time, as shown in Figure 5-3.
5-2

Figure 5-3 Schematic diagram for WRR queuing
Assume there are eight output queues on a port. WRR assigns each queue a weight value
(represented by w7, w6, w5, w4, w3, w2, w1, or w0) to decide the proportion of resources assigned to
the queue. On a 100 Mbps port, you can configure the weight values of WRR queuing to 5, 3, 1, 1, 5, 3,
1, and 10 (corresponding to w7, w6, w5, w4, w3, w2, w1, and w0 respectively). In this way, the queue
with the lowest priority is assured of 5 Mbps of bandwidth at least, thus avoiding the disadvantage of
SP queuing that packets in low-priority queues may fail to be served for a long time.
Another advantage of WRR queuing is that while the queues are scheduled in turn, the service time for
each queue is not fixed, that is, if a queue is empty, the next queue will be scheduled immediately. This
improves bandwidth resource use efficiency.
WFQ queuing
Figure 5-4 Schematic diagram for WFQ queuing
Queue 1 Band width 1
Packets to be sent through

this port Queue 2 Band width 2 Sent packets
Interface

Queue N-1 Band width N-1
Sending queue
Packet Queue
classification scheduling
Queue N Band width N
WFQ is derived from fair queuing (FQ), which is designed for fairly sharing network resources,
reducing the delay and jitter of all traffic. FQ fully consider the interests of all queues to ensure that:
z Different queues have fair dispatching opportunities, preventing a single queue from being
delayed for too long.
5-3

z Short packets and long packets are fairly scheduled: if there are both long packets and short
packets in queues, statistically the short packets should be scheduled preferentially to reduce the
jitter between packets as a whole.
Compared with FQ, WFQ takes weights into account when determining the queue scheduling order.
Statistically, WFQ gives high priority traffic more scheduling opportunities than low priority traffic. WFQ
can automatically classify traffic according to the session information of traffic (protocol type, TCP or
UDP source/destination port numbers, source/destination IP addresses, IP precedence bits in the ToS
field, and so on), and try to provide as many queues as possible so that each traffic flow can be put into
these queues to balance the delay of every traffic flow as a whole. When dequeuing packets, WFQ
assigns the outgoing interface bandwidth to each traffic flow by precedence. The higher precedence
value a traffic flow has, the more bandwidth it gets.
Additionally, WFQ can work with the minimum guaranteed bandwidth mechanism. You can configure a
minimum guaranteed bandwidth for each WFQ queue to guarantee that each WFQ queue is
guaranteed of the bandwidth when congestion occurs. The assignable bandwidth (assignable
bandwidth = total bandwidth the sum of the minimum guaranteed bandwidth for each queue) is
allocated to queues based on queue priority.
For example, assume that the total bandwidth of a port is 10 Mbps, and there are five flows on the port
currently, with the precedence being 0, 1, 2, 3, and 4 and the minimum guaranteed bandwidth being
128 kbps, 128 kbps, 128 kbps, 64 kbps, and 64 kbps respectively.
z The assignable bandwidth = 10 Mbps (128 kbps + 128 kbps + 128 kbps + 64 kbps + and 64
kbps) = 9.5 Mbps
z The total assignable bandwidth quota is the sum of all the (precedence value + 1)s, that is, 1 + 2 +
3 + 4 + 5 = 15.
z The bandwidth percentage assigned to each flow is (precedence value of the flow + 1)/total
assignable bandwidth quota. The bandwidth percentages for the flows are 1/15, 2/15, 3/15, 4/15,
and 5/15 respectively.
z The bandwidth finally assigned to a queue = the minimum guaranteed bandwidth + the bandwidth
allocated to the queue from the assignable bandwidth
Because WFQ can balance delay and jitter among flows when congestion occurs, it is effectively
applied in some special occasions. For example, WFQ is used for the assured forwarding (AF)
services of the Resource Reservation Protocol (RSVP). In Generic Traffic Shaping (GTS), WFQ is
used to schedule buffered packets.
SP+WRR queuing
By assigning some queues on the port to the SP scheduling group and the others to the WRR
scheduling group (that is, group 1), you implement SP + WRR queue scheduling on the port. Packets
in the SP scheduling group are scheduled preferentially. When the SP scheduling group is empty,
packets in the WRR scheduling group are scheduled. Queues in the SP scheduling group are
scheduled with the SP queue scheduling algorithm. Queues in the WRR scheduling group are
scheduled with WRR.
Congestion Management Configuration Approaches

Complete the following tasks to achieve congestion management:
Task Remarks
Configuring SP Queuing Optional
5-4

Task Remarks
Configure WRR Queuing Optional
Configuring WFQ Queuing Optional
Configuring SP+WRR Queues Optional
Configuring Congestion Management

Configuring SP Queuing
Follow these steps to configure SP queuing:


interface
interface interface-number Settings in interface view take effect
view
view or port on the current interface; settings in
group view Enter port port-group manual port group view take effect on all
group view port-group-name ports in the port group.
Required
By default, all the ports adopt the
Configure SP queuing qos sp WRR queue scheduling algorithm,
with the weight values assigned to
queue 0 through queue 7 being 1, 2,
3, 4, 5, 9, 13, and 15.
Configure GigabitEthernet 1/0/1 to use SP queuing.
# Enter system view
# Configure GigabitEthernet1/0/1 to use SP queuing.

[Sysname]interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] qos sp
Configure WRR Queuing
Follow these steps to configure group-based WRR queuing:

5-5

interface-number
Optional
Enable WRR queuing qos wrr The default queuing algorithm

on an interface is WRR
queuing.
Required
By default, all the ports adopt
qos wrr queue-id group group-id the WRR queue scheduling
Configure a WRR queue algorithm, with the weight
weight schedule-value
values assigned to queue 0
through queue 7 being 1, 2, 3,
4, 5, 9, 13, and 15.
z Enable WRR queuing on the interface GigabitEthernet 1/0/1.
z Assign queues 0 through 7 to the WRR group, with their weights being 1, 2, 4, 6, 8, 10, 12, and 14.
# Configure the WRR queues on port GigabitEthernet1/0/1.

[Sysname] interface GigabitEthernet 1/0/1
[Sysname-GigabitEthernet1/0/1] qos wrr
[Sysname-GigabitEthernet1/0/1] qos wrr 0 group 1 weight 1
Configuring WFQ Queuing
Follow these steps to configure a WFQ queue:

Enter Enter Use either command

interface interface Settings in interface view take
interface-number
view or port view effect on the current interface;
5-6

group view settings in port group view take
Enter port port-group manual effect on all ports in the port
Required
By default, all the ports adopt
the WRR queue scheduling
Enable WFQ queuing qos wfq algorithm, with the weight
values assigned to queue 0
through queue 7 being 1, 2, 3,
4, 5, 9, 13, and 15.
Configure the minimum Optional
qos bandwidth queue queue-id
guaranteed bandwidth for
min bandwidth-value 64 kbps by default
an WFQ queue
Specify the queue Optional
qos wfq queue-id weight
scheduling weight for an
schedule-value 1 by default
WFQ queue
z Enable WFQ on GigabitEthernet 1/0/1, and set the weights of queues 0 through 7 to 1, 2, 4, 6, 8,
10, 12, and 14 respectively.
z Set the minimum guaranteed bandwidth of queue 0 to 128 kbps.
# Configure WFQ queues on GigabitEthernet 1/0/1.

[Sysname-GigabitEthernet1/0/1] qos wfq
[Sysname-GigabitEthernet1/0/1] qos wfq 0 weight 1
# Set the minimum guaranteed bandwidth of queue 0 to 128 kbps.

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 0 min 128
Configuring SP+WRR Queues
Follow these steps to configure SP + WRR queues:

5-7

Enter Enter interface interface-type Use either command

interface interface view interface-number Settings in interface view take effect
view or on the current interface; settings in
port group Enter port port-group manual port group view take effect on all ports
view group view port-group-name in the port group.
Required
Enable the WRR queue
qos wrr The default queuing algorithm on an
scheduling on the port
interface is WRR queuing.
Required
By default, all the ports adopt the
Configure SP queue WRR queue scheduling algorithm,
qos wrr queue-id group sp
scheduling with the weight values assigned to
3, 4, 5, 9, 13, and 15.
Required
qos wrr queue-id group By default, all the ports adopt the
Configure WRR queue WRR queue scheduling algorithm,
group-id weight
scheduling with the weight values assigned to
schedule-value
3, 4, 5, 9, 13, and 15.
z Configure to adopt SP+WRR queue scheduling algorithm on GigabitEthernet1/0/1.

z Configure queue 0, queue 1, queue 2 and queue 3 on GigabitEthernet1/0/1 to be in SP queue
scheduling group.
z Configure queue 4, queue 5, queue 6 and queue 7 on GigabitEthernet1/0/1 to be in WRR queue
scheduling group, with the weight being 2, 4, 6 and 8 respectively.

# Enable the SP+WRR queue scheduling algorithm on GigabitEthernet1/0/1.

[Sysname-GigabitEthernet1/0/1] qos wrr
[Sysname-GigabitEthernet1/0/1] qos wrr 0 group sp
5-8

Displaying and Maintaining Congestion Management
Display WRR queue display qos wrr interface [ interface-type
configuration information interface-number ]
Display SP queue display qos sp interface [ interface-type Available in any
configuration information interface-number ] view
Display WFQ queue display qos wfq interface [ interface-type

configuration information interface-number ]
5-9

6 Traffic Filtering Configuration
When configuring traffic filtering, go to these sections for information you are interested in:
z Traffic Filtering Overview
z Configuring Traffic Filtering
z Traffic Filtering Configuration Example
Traffic Filtering Overview

You can filter in or filter out a class of traffic by associating the class with a traffic filtering action. For
example, you can filter packets sourced from a specific IP address according to network status. By
using ACL rules configured with a time range for traffic classification, you can implement time-based
traffic filtering.
Configuring Traffic Filtering

Follow these steps to configure traffic filtering:


Configure the match criteria if-match match-criteria
Create a behavior and enter

behavior view
Required
Configure the traffic filtering z deny: Drops packets.
filter { deny | permit }
action z permit: Permits packets
to pass through.

policy view
Associate the class with the
traffic behavior in the QoS
behavior-name
policy
Apply the Applying the QoS policy to an

To an interface
QoS interface
policy
Applying the QoS policy to online
To online users
users
To a VLAN Applying the QoS policy to a VLAN
6-1

Display the traffic filtering display traffic behavior Optional

configuration user-defined [ behavior-name ] Available in any view
With filter deny configured for a traffic behavior, the other actions (except class-based accounting) in
the traffic behavior do not take effect.
Traffic Filtering Configuration Example

Traffic Filtering Configuration Example
As shown in Figure 6-1, Host is connected to GigabitEthernet 1/0/1 of Device.

Configure traffic filtering to filter the packets whose source port is 21 received on GigabitEthernet 1/0/1.
Figure 6-1 Network diagram for traffic filtering configuration
# Create advanced ACL 3000, and configure a rule to match packets whose source port number is 21.
[DeviceA] acl number 3000
[DeviceA-acl-basic-3000] rule 0 permit tcp source-port eq 21
[DeviceA-acl-basic-3000] quit
# Create a class named classifier_1, and reference ACL 3000 in the class.
[DeviceA] traffic classifier classifier_1
[DeviceA-classifier-classifier_1] if-match acl 3000
[DeviceA-classifier-classifier_1] quit
# Create a behavior named behavior_1, and configure the traffic filtering action for the behavior.
[DeviceA] traffic behavior behavior_1
[DeviceA-behavior-behavior_1] filter deny
[DeviceA-behavior-behavior_1] quit
# Create a policy named policy, and associate class classifier_1 with behavior behavior_1 in the
policy.
[DeviceA] qos policy policy
[DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1
6-2

[DeviceA-qospolicy-policy] quit
# Apply the policy named policy to the incoming traffic of GigabitEthernet 1/0/1.
[DeviceA-GigabitEthernet1/0/1] qos apply policy policy inbound
6-3

7 Priority Marking Configuration
When configuring priority marking, go to these sections for information you are interested in:
z Priority Marking Overview
z Configuring Priority Marking
z Priority Marking Configuration Example
Priority Marking Overview
Priority marking can be used together with priority mapping. For details, refer to Priority Mapping Table
and Priority Marking Configuration Example.
Priority marking sets the priority fields or flag bits of packets to modify the priority of traffic. For example,
you can use priority marking to set IP precedence or DSCP for a class of IP traffic to change its
transmission priority in the network.
To configure priority marking, you can associate a class with a behavior configured with the priority
marking action to set the priority fields or flag bits of the class of packets.
Configuring Priority Marking

Follow these steps to configure priority marking:


Configure the match
if-match match-criteria
criteria
Create a behavior and

enter behavior view
Set the DSCP value for

remark dscp dscp-value Optional
packets
Set the 802.1p priority for
remark dot1p Optional
packets
Set the drop precedence remark drop-precedence
Optional
for packets drop-precedence-value
7-1

Set the IP precedence for remark ip-precedence
Optional
packets ip-precedence-value
Set the local precedence remark local-precedence
Optional
for packets local-precedence

policy view
Associate the class with
the traffic behavior in the
behavior-name
QoS policy
To an interface Applying the QoS policy to an interface
Apply the To online Applying the QoS policy to online

QoS users users
policy To a VLAN Applying the QoS policy to a VLAN
Display the priority marking display traffic behavior user-defined Optional

configuration [ behavior-name ] Available in any view
Priority Marking Configuration Example

Priority Marking Configuration Example
As shown in Figure 7-1, the enterprise network of a company interconnects hosts with servers through
Device. The network is described as follows:
z Host A and Host B are connected to GigabitEthernet 1/0/1 of Device.
z The data server, mail server, and file server are connected to GigabitEthernet 1/0/2 of Device.
Configure priority marking on Device to satisfy the following requirements:
Traffic source Destination Processing priority

Host A, B Data server High
Host A, B Mail server Medium
Host A, B File server Low
7-2

Figure 7-1 Network diagram for priority marking configuration
Internet
Host A Data server

192.168.0.1/24
GE1/0/1 GE1/0/2 Mail server

192.168.0.2/24
Host B
Device
File server
192.168.0.3/24
# Create advanced ACL 3000, and configure a rule to match packets with destination IP address
192.168.0.1.
[Device-acl-adv-3000] rule permit ip destination 192.168.0.1 0
192.168.0.2.
192.168.0.3.
# Create a class named classifier_dbserver, and reference ACL 3000 in the class.
[Device] traffic classifier classifier_dbserver
[Device-classifier-classifier_dbserver] if-match acl 3000
[Device-classifier-classifier_dbserver] quit
# Create a class named classifier_mserver, and reference ACL 3001 in the class.
[Device] traffic classifier classifier_mserver
[Device-classifier-classifier_mserver] if-match acl 3001
[Device-classifier-classifier_mserver] quit
# Create a class named classifier_fserver, and reference ACL 3002 in the class.
[Device] traffic classifier classifier_fserver
[Device-classifier-classifier_fserver] if-match acl 3002
[Device-classifier-classifier_fserver] quit
# Create a behavior named behavior_dbserver, and configure the action of setting the local
precedence value to 4 for the behavior.
7-3

[Device] traffic behavior behavior_dbserver
[Device-behavior-behavior_dbserver] remark local-precedence 4
[Device-behavior-behavior_dbserver] quit
# Create a behavior named behavior_mserver, and configure the action of setting the local
[Device] traffic behavior behavior_mserver
[Device-behavior-behavior_mserver] remark local-precedence 3
[Device-behavior-behavior_mserver] quit
# Create a behavior named behavior_fserver, and configure the action of setting the local
[Device] traffic behavior behavior_fserver
[Device-behavior-behavior_fserver] remark local-precedence 2
[Device-behavior-behavior_fserver] quit
# Create a policy named policy_server, and associate classes with behaviors in the policy.
[Device] qos policy policy_server
[Device-qospolicy-policy_server] classifier classifier_dbserver behavior behavior_dbserver
[Device-qospolicy-policy_server] classifier classifier_mserver behavior behavior_mserver
[Device-qospolicy-policy_server] classifier classifier_fserver behavior behavior_fserver
[Device-qospolicy-policy_server] quit
# Apply the policy named policy_server to the incoming traffic of GigabitEthernet 1/0/1.
[Device-GigabitEthernet1/0/1] qos apply policy policy_server inbound
7-4

8 Traffic Redirecting Configuration
When configuring traffic redirecting, go to these sections for information you are interested in:
z Traffic Redirecting Overview
z Configuring Traffic Redirecting
Traffic Redirecting Overview

Traffic Redirecting
Traffic redirecting is the action of redirecting the packets matching the specific match criteria to a
certain location for processing.
Currently, the following two traffic redirecting actions are supported:
z Redirecting traffic to the CPU: redirects packets which require processing by CPU to the CPU.
z Redirecting traffic to an interface: redirects packets which require processing by an interface to the
interface. Note that this action is applicable to only Layer 2 packets, and the target interface
should be a Layer 2 interface.
Configuring Traffic Redirecting

Follow these steps to configure traffic redirecting:



traffic behavior behavior-name Required
behavior view
Configure a traffic redirect { cpu | interface
Optional
redirecting action interface-type interface-number }

policy view
behavior-name
policy
Apply the Applying the QoS policy to an

To an interface
QoS interface
policy
8-1

z Generally, the action of redirecting traffic to the CPU and the action of redirecting traffic to an
interface are mutually exclusive with each other in the same traffic behavior.
z You can use the display traffic behavior command to view the traffic redirecting configuration.
z A QoS policy that contains a traffic redirecting action can be applied only to the incoming traffic.
8-2

9 Traffic Mirroring Configuration
When configuring traffic mirroring, go to these sections for information you are interested in:
z Traffic Mirroring Overview
z Configuring Traffic Mirroring
z Displaying and Maintaining Traffic Mirroring
z Traffic Mirroring Configuration Examples
Traffic Mirroring Overview

Traffic mirroring is the action of copying the specified packets to the specified destination for packet
analyzing and monitoring.
You can configure mirroring traffic to an interface or to the CPU.
z Mirroring traffic to an interface: copies the matching packets on an interface to a destination
interface.
z Mirroring traffic to the CPU: copies the matching packets on an interface to a CPU (the CPU of the
device where the traffic mirroring-enabled interface resides).
Configuring Traffic Mirroring

To configure traffic mirroring, you must enter the view of an existing traffic behavior.
In a traffic behavior, the action of mirroring traffic to an interface and the action of mirroring traffic to a
CPU is mutually exclusive.
Mirroring Traffic to an Interface
Follow these steps to mirror traffic to an interface:



behavior view
9-1

Specify the destination mirror-to interface interface-type
Required
interface for traffic mirroring interface-number

policy view
behavior-name
policy
Applying the QoS policy to an

To an interface
Apply the interface
QoS
policy
Mirroring Traffic to the CPU
Follow these steps to mirror traffic to the CPU:



behavior view
Mirror traffic to the CPU mirror-to cpu Required

policy view
behavior-name
policy

To an interface
Apply the interface
QoS
policy
9-2

Displaying and Maintaining Traffic Mirroring

display traffic behavior
Display traffic behavior
[ behavior-name ]
display qos policy
Display QoS policy
user-defined [ policy-name Available in any view
[ classifier tcl-name ] ]
Traffic Mirroring Configuration Examples

Example for Mirroring Traffic to an Interface
On the network as shown in Figure 9-1, Host A (with the IP address 192.168.0.1) and Host B are
connected to GigabitEthernet1/0/1 of the switch; a data monitoring device is connected to
GigabitEthernet1/0/2 of the switch.
Monitor and analyze packets sent by Host A on the data monitoring device.
Figure 9-1 Network diagram for configuring traffic mirroring to a port
Configure Switch:
# Configure basic IPv4 ACL 2000 to match packets with the source IP address 192.168.0.1.
[Sysname-acl-basic-2000] rule permit source 192.168.0.1 0
[Sysname-acl-basic-2000] quit
# Create class 1 and configure the class to use ACL 2000 for traffic classification.
[Sysname] traffic classifier 1
[Sysname-classifier-1] if-match acl 2000
[Sysname-classifier-1] quit
# Create behavior 1 and configure the action of mirroring traffic to GigabitEthernet1/0/2 in the traffic
behavior.
9-3

[Sysname] traffic behavior 1
[Sysname-behavior-1] mirror-to interface GigabitEthernet 1/0/2
[Sysname-behavior-1] quit
# Create QoS policy 1 and associate traffic behavior 1 with class 1 in the QoS policy.
[Sysname] qos policy 1
[Sysname-policy-1] classifier 1 behavior 1
[Sysname-policy-1] quit
# Apply the QoS policy to the incoming traffic of GigabitEthernet 1/0/1.

[Sysname-GigabitEthernet1/0/1] qos apply policy 1 inbound
After the configurations, you can monitor all packets sent from Host A on the data monitoring device.
9-4

10 Class-Based Accounting Configuration
When configuring class-based accounting, go to these sections for information you are interested in:
z Class-Based Accounting Overview
z Configuring Class-Based Accounting
z Displaying and Maintaining Traffic Accounting
z Class-Based Accounting Configuration Example
Class-Based Accounting Overview

Class-based accounting collects statistics on a per-traffic class basis. For example, you can define the
action to collect statistics for traffic sourced from a certain IP address. By analyzing the statistics, you
can determine whether there are anomalies and what action to take.
Configuring Class-Based Accounting

Follow these steps to configure class-based accounting:



behavior view
Optional
Configure the accounting The class-based accounting
accounting function on Switch 4510G
action
series counts traffic in the
number of packets.
policy view
behavior-name
policy

To an interface
Apply the interface
QoS
policy
10-1

Displaying and Maintaining Traffic Accounting
After completing the configuration above, you can verify the configuration with the display qos policy
global, display qos policy interface, or display qos vlan-policy command depending on the
occasion where the QoS policy is applied.
Class-Based Accounting Configuration Example

Class-Based Accounting Configuration Example
As shown in Figure 10-1, Host is connected to GigabitEthernet 1/0/1 of Device.

Configure class-based accounting to collect statistics for traffic sourced from 1.1.1.1/24 and received
on GigabitEthernet 1/0/1.
Figure 10-1 Network diagram for traffic accounting configuration
# Create basic ACL 2000, and configure a rule to match packets with source IP address 1.1.1.1.
[DeviceA-acl-basic-2000] rule permit source 1.1.1.1 0
# Create a class named classifier_1, and reference ACL 2000 in the class.
[DeviceA] traffic classifier classifier_1
[DeviceA-classifier-classifier_1] if-match acl 2000
[DeviceA-classifier-classifier_1] quit
# Create behavior behavior_1, and configure an accounting action in the behavior.

[DeviceA] traffic behavior behavior_1
[DeviceA-behavior-behavior_1] accounting
[DeviceA-behavior-behavior_1] quit
# Create a policy named policy, and associate class classifier_1 with behavior behavior_1 in the
policy.
[DeviceA] qos policy policy
[DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1
[DeviceA-qospolicy-policy] quit
# Apply the policy named policy to the incoming traffic of GigabitEthernet 1/0/1.
[DeviceA-GigabitEthernet1/0/1] qos apply policy policy inbound
10-2

# Display traffic statistics to verify the configuration.

[DeviceA] display qos policy interface gigabitethernet 1/0/1
Interface: GigabitEthernet1/0/1
Direction: Inbound
Policy: policy
Classifier: classifier_1
Operator: AND
Rule(s) : If-match acl 2000
Behavior: behavior_1
Accounting Enable:
28529 (Packets)
10-3

11 User Profile Configuration
When configuring user profile, go to these sections for information you are interested in:
z User Profile Overview
z User Profile Configuration
z Displaying and Maintaining User Profile
User Profile Overview

User profile provides a configuration template to save predefined configurations. Based on different
application scenarios, you can configure different items for a user profile, such as Committed Access
Rate (CAR), Quality of Service (QoS), and so on.
When accessing the device, users need to be authenticated. During the authentication process, the
authentication server sends the user profile name to the device, which then enables the configurations
in the user profile. After the users pass the authentication and access the device, the device will restrict
the users access based on these configurations. When the users log out, the device automatically
disables the configurations in the user profile, and thus the restrictions on the users are removed.
Therefore, user profile is applicable to restricting online users access; if no users are online (no user
access, no users pass the authentication, or users have logged out), user profile does not take effect
as it is a predefined configuration.
With user profile, you can:
z Make use of system resources more granularly. For example, without user profile, you can apply a
QoS policy based on interface, VLAN, globally and so on. This QoS policy is applicable to a group
of users. With user profile, however, you can apply a QoS policy on a per-user basis.
z Restrict users access to the system resources more flexibly. For example, without user profile,
you can perform traffic policing based on CAR, ACL, or for all the traffic of the current interface;
when the physical position of users changes (for example, the users access the network using
another interface), you need to configure traffic policing on another interface. With user profile,
however, you can perform traffic policing on a per-user basis. As long as users are online, the
authentication server applies the corresponding user profile (with CAR configured) to the users;
when the users are offline, the system automatically removes the corresponding configuration.
User Profile Configuration

User Profile Configuration Task List
Task Remarks
Creating a User Profile Required
Applying a QoS Policy to User Profile Required
Enabling a User Profile Required
11-1

Creating a User Profile
Before creating a user profile, you need to configure authentication parameters. User profile supports
802.1X authentications. You need to perform the related configurations (for example, username,
password, authentication scheme, domain and binding between a user profile and user) on the client,
the device and authentication server.
Creating a User Profile
Follow these steps to create a user profile:

Required
If the specified user profile
already exists, you will directly
enter the corresponding user
Create a user profile, and enter the user-profile profile view.
corresponding user profile view profile-name dot1x The configuration made in user
profile view takes effect when
the user profile is enabled and
the corresponding users are
online.
Refer to 802.1x Configuration in the Security Volume for detailed information about 802.1x
authentication.
Applying a QoS Policy to User Profile
After a user profile is created, you need to configure detailed items in user profile view to implement
restrictions on the online users. Currently supported configurations are as follows:
Follow these steps to apply a QoS policy to traffic of online users:

Required
The configuration made in
user-profile profile-name user profile view takes effect
Enter user profile view
[ dot1x ] when the user-profile is active
and the corresponding users
are online.
qos apply policy policy-name
Apply the QoS policy Required
{ inbound | outbound }
11-2

z When a user profile is active, you cannot configure or remove the QoS policy applied to it.
z The QoS policies applied in user profile view support only the remark, car, and filter actions.
z Do not apply an empty QoS policy in user profile view, because even if you can do that, the user
profile cannot be activated.
Enabling a User Profile
A created user profile takes effect only after being enabled.

Follow these steps to enable a user profile:

user-profile profile-name Required

Enable a user profile
enable A user profile is disabled by default.
z Only an enabled user profile can be used by a user. You cannot modify or remove the
configuration items in a user profile until the user profile is disabled.
z Disabling a user profile logs out the users using the user profile.
Displaying and Maintaining User Profile

To do Use the command
Display information about all the created user profiles display user-profile
11-3

12 Appendix
This chapter covers the following appendixes:

z Appendix A Acronym
z Appendix B Default Priority Mapping Tables
z Appendix C Introduction to Packet Precedences
Appendix A Acronym
Table 12-1 Appendix A Acronym
Acronym Full spelling

AF Assured Forwarding
BE Best Effort
CAR Committed Access Rate
CBS Committed Burst Size

CBWFQ Class Based Weighted Fair Queuing
CE Customer Edge
CIR Committed Information Rate
CQ Custom Queuing
DAR Deeper Application Recognition
DiffServ Differentiated Service

DSCP Differentiated Services Codepoint
EACL Enhanced ACL
EBS Excess Burst Size
EF Expedited Forwarding
FEC Forwarding Equivalence Class
FIFO First in First out
GTS Generic Traffic Shaping
IntServ Integrated Service
ISP Internet Service Provider

LFI Link Fragmentation & Interleaving
LLQ Low Latency Queuing
LR Line Rate
LSP Label Switched Path
MPLS Multiprotocol Label Switching
12-1

Acronym Full spelling
PE Provider Edge
PHB Per-hop Behavior
PIR Peak Information Rate
PQ Priority Queuing
QoS Quality of Service
RED Random Early Detection
RSVP Resource Reservation Protocol
RTP Real Time Protocol
SLA Service Level Agreement
TE Traffic Engineering
ToS Type of Service
TP Traffic Policing
TS Traffic Shaping
VoIP Voice over IP
VPN Virtual Private Network
WFQ Weighted Fair Queuing
WRED Weighted Random Early Detection
Appendix B Default Priority Mapping Tables

Uncolored Priority Mapping Tables
For the default dscp-dscp priority mapping table, an input value yields a target value that is equal to it.
Table 12-2 The default dot1p-lp, dot1p-dp, dot1p-dscp, and dot1p-rpr priority mapping tables
Input priority value dot1p-lp mapping dot1p-dp mapping

Local precedence
802.1p priority (dot1p) Drop precedence (dp)
(lp)
0 2 0
1 0 0
12-2

Input priority value dot1p-lp mapping dot1p-dp mapping
2 1 0
3 3 0
4 4 0
5 5 0
6 6 0
7 7 0
Table 12-3 The default dscp-lp, dscp-dp, dscp-dot1p, and dscp-exp priority mapping tables
Input priority value dscp-dp mapping dscp-dot1p mapping

DSCP Drop precedence (dp) 802.1p priority (dot1p)
0 to 7 0 0
8 to 15 0 1
16 to 23 0 2
24 to 31 0 3
32 to 39 0 4
40 to 47 0 5
48 to 55 0 6
56 to 63 0 7
Appendix C Introduction to Packet Precedences

IP Precedence and DSCP Values
Figure 12-1 ToS and DS fields
As shown in Figure 12-1, the ToS field of the IP header contains eight bits, and the first three bits (0 to
2) represent IP precedence from 0 to 7. According to RFC 2474, the ToS field of the IP header is
redefined as the differentiated services (DS) field, where a DSCP value is represented by the first six
bits (0 to 5) and is in the range 0 to 63. The remaining two bits (6 and 7) are reserved.
12-3

Table 12-4 Description on IP precedence
IP precedence (decimal) IP precedence (binary) Description

0 000 Routine
1 001 priority
2 010 immediate
3 011 flash
4 100 flash-override
5 101 critical
6 110 internet
7 111 network
Table 12-5 Description on DSCP values
DSCP value (decimal) DSCP value (binary) Description

46 101110 ef
10 001010 af11
12 001100 af12
14 001110 af13
18 010010 af21
20 010100 af22
22 010110 af23
26 011010 af31
28 011100 af32
30 011110 af33
34 100010 af41
36 100100 af42
38 100110 af43
8 001000 cs1
16 010000 cs2
24 011000 cs3
32 100000 cs4
40 101000 cs5
48 110000 cs6
56 111000 cs7
0 000000 be (default)
12-4

802.1p Priority
802.1p priority lies in Layer 2 packet headers and is applicable to occasions where Layer 3 header
analysis is not needed and QoS must be assured at Layer 2.
Figure 12-2 An Ethernet frame with an 802.1Q tag header
As shown in Figure 12-2, the 4-byte 802.1Q tag header consists of the tag protocol identifier (TPID,
two bytes in length), whose value is 0x8100, and the tag control information (TCI, two bytes in length).
Figure 12-3 presents the format of the 802.1Q tag header. The Priority field in the 802.1Q tag header is
called the 802.1p priority, because its use is defined in IEEE 802.1p. Table 12-6 presents the values for
802.1p priority.
Figure 12-3 802.1Q tag header
Byte 1 Byte 2 Byte 3 Byte 4
TPID (Tag protocol identifier) TCI (Tag control information)
CFI
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 Priority VLAN ID
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Table 12-6 Description on 802.1p priority
802.1p priority (decimal) 802.1p priority (binary) Description

0 000 best-effort
1 001 background
2 010 spare
3 011 excellent-effort
4 100 controlled-load
5 101 video
6 110 voice
7 111 network-management
12-5

Table of Contents
1 AAA Configuration 1-1

Introduction to AAA 1-1
Introduction to RADIUS1-2
Client/Server Model 1-2
Security and Authentication Mechanisms 1-3
Basic Message Exchange Process of RADIUS 1-3
RADIUS Packet Format1-4
Extended RADIUS Attributes 1-7
Introduction to HWTACACS1-7
Differences Between HWTACACS and RADIUS1-8
Basic Message Exchange Process of HWTACACS 1-8
Protocols and Standards1-10
AAA Configuration Task List 1-10
AAA Configuration Task List 1-11
RADIUS Configuration Task List 1-11
HWTACACS Configuration Task List 1-12
Configuring AAA1-12
Creating an ISP Domain1-12
Configuring ISP Domain Attributes1-13
Configuring AAA Authentication Methods for an ISP Domain 1-14
Configuring AAA Authorization Methods for an ISP Domain 1-15
Configuring AAA Accounting Methods for an ISP Domain1-17
Configuring Local User Attributes1-19
Configuring User Group Attributes 1-20
Tearing down User Connections Forcibly 1-21
Displaying and Maintaining AAA 1-21
Configuring RADIUS 1-22
Creating a RADIUS Scheme 1-22
Specifying the RADIUS Authentication/Authorization Servers1-23
Specifying the RADIUS Accounting Servers and Relevant Parameters1-23
Setting the Shared Key for RADIUS Packets1-24
Setting the Upper Limit of RADIUS Request Retransmission Attempts 1-25
Setting the Supported RADIUS Server Type 1-25
Setting the Status of RADIUS Servers 1-26
Configuring Attributes Related to Data to Be Sent to the RADIUS Server 1-27
Setting Timers Regarding RADIUS Servers 1-28
Specifying a Security Policy Server1-29
Enabling the Listening Port of the RADIUS Client 1-30
Displaying and Maintaining RADIUS1-30
Configuring HWTACACS 1-30
Creating a HWTACACS scheme1-31
Specifying the HWTACACS Authentication Servers1-31

Specifying the HWTACACS Authorization Servers1-32
Specifying the HWTACACS Accounting Servers1-32
Setting the Shared Key for HWTACACS Packets1-33
Configuring Attributes Related to the Data Sent to HWTACACS Server1-33
Setting Timers Regarding HWTACACS Servers 1-34
Displaying and Maintaining HWTACACS1-35
AAA Configuration Examples1-35
AAA for Telnet Users by a HWTACACS Server 1-35
AAA for Telnet Users by Separate Servers1-37
AAA for SSH Users by a RADIUS Server 1-38
Troubleshooting AAA 1-42
Troubleshooting RADIUS 1-42
Troubleshooting HWTACACS 1-43
2 802.1X Configuration2-1
802.1X Overview2-1
Architecture of 802.1X 2-1
Authentication Modes of 802.1X 2-2
Basic Concepts of 802.1X 2-2
EAP over LANs2-3
EAP over RADIUS2-5
802.1X Authentication Triggering 2-5
Authentication Process of 802.1X 2-6
802.1X Timers 2-9
Extensions to 802.1X2-10
Features Working Together with 802.1X2-10
Configuring 802.1X 2-12
Configuring 802.1X Globally2-12
Configuring 802.1X for a Port2-14
Configuring an 802.1X Port-based Guest VLAN 2-15
Displaying and Maintaining 802.1X2-16
802.1X Configuration Example 2-16
Guest VLAN and VLAN Assignment Configuration Example 2-18
ACL Assignment Configuration Example2-21
3 EAD Fast Deployment Configuration 3-1

EAD Fast Deployment Overview 3-1
Overview3-1
EAD Fast Deployment Implementation 3-1
Configuring EAD Fast Deployment 3-2
Displaying and Maintaining EAD Fast Deployment 3-3
EAD Fast Deployment Configuration Example3-4
Troubleshooting EAD Fast Deployment3-5
Users Cannot be Redirected Correctly3-5
4 HABP Configuration 4-1

Introduction to HABP4-1
ii

Configuring HABP 4-2
Configuring the HABP Server4-2
Configuring an HABP Client 4-3
Displaying and Maintaining HABP 4-3
HABP Configuration Example4-3
5 MAC Authentication Configuration5-1

MAC Authentication Overview 5-1
RADIUS-Based MAC Authentication5-1
Local MAC Authentication 5-1
Related Concepts5-2
MAC Authentication Timers5-2
Quiet MAC Address5-2
VLAN Assigning5-2
ACL Assigning 5-2
Configuring MAC Authentication5-2
Displaying and Maintaining MAC Authentication 5-4
MAC Authentication Configuration Examples5-4
Local MAC Authentication Configuration Example 5-4
RADIUS-Based MAC Authentication Configuration Example 5-6
ACL Assignment Configuration Example 5-7
6 Port Security Configuration6-1

Introduction to Port Security6-1
Port Security Overview 6-1
Port Security Features6-2
Port Security Modes 6-2
Port Security Configuration Task List6-4
Enabling Port Security6-5
Setting the Maximum Number of Secure MAC Addresses6-5
Setting the Port Security Mode 6-6
Configuring Procedure6-7
Configuring Port Security Features6-7
Configuring NTK 6-7
Configuring Intrusion Protection 6-8
Configuring Trapping 6-9
Configuring Secure MAC Addresses 6-9
Ignoring Authorization Information from the Server 6-10
Displaying and Maintaining Port Security 6-10
Port Security Configuration Examples 6-11
Configuring the autoLearn Mode6-11
Configuring the userLoginWithOUI Mode6-13
iii

Configuring the macAddressElseUserLoginSecure Mode 6-17
Troubleshooting Port Security6-19
Cannot Set the Port Security Mode6-19
Cannot Configure Secure MAC Addresses6-20
Cannot Change Port Security Mode When a User Is Online 6-20
7 IP Source Guard Configuration7-1

IP Source Guard Overview 7-1
Configuring a Static Binding Entry 7-1
Configuring Dynamic Binding Function7-2
Displaying and Maintaining IP Source Guard 7-3
IP Source Guard Configuration Examples 7-3
Static Binding Entry Configuration Example7-3
Dynamic Binding Function Configuration Example 7-4
Troubleshooting IP Source Guard 7-6
Failed to Configure Static Binding Entries and Dynamic Binding Function7-6
8 SSH2.0 Configuration8-1
SSH2.0 Overview8-1
Introduction to SSH2.0 8-1
Operation of SSH 8-1
Configuring the Device as an SSH Server8-4
SSH Server Configuration Task List8-4
Generating a DSA or RSA Key Pair 8-4
Enabling SSH Server8-5
Configuring the User Interfaces for SSH Clients8-5
Configuring a Client Public Key8-6
Configuring an SSH User 8-7
Setting the SSH Management Parameters 8-8
Configuring the Device as an SSH Client 8-9
SSH Client Configuration Task List 8-9
Specifying a Source IP address/Interface for the SSH client 8-9
Configuring Whether First-time Authentication is Supported 8-10
Establishing a Connection Between the SSH Client and the Server 8-11
Displaying and Maintaining SSH8-11
SSH Server Configuration Examples8-12
When Switch Acts as Server for Password Authentication 8-12
When Switch Acts as Server for Publickey Authentication 8-14
SSH Client Configuration Examples 8-19
When Switch Acts as Client for Password Authentication 8-19
When Switch Acts as Client for Publickey Authentication8-22
9 SFTP Configuration 9-1

SFTP Overview 9-1
Configuring an SFTP Server9-1
Enabling the SFTP Server9-1
Configuring the SFTP Connection Idle Timeout Period 9-2
Configuring an SFTP Client 9-2
Specifying a Source IP Address or Interface for the SFTP Client9-2
iv

Establishing a Connection to the SFTP Server9-2
Working with the SFTP Directories 9-3
Working with SFTP Files 9-4
Displaying Help Information 9-4
Terminating the Connection to the Remote SFTP Server9-5
SFTP Client Configuration Example 9-5
SFTP Server Configuration Example9-9
10 PKI Configuration 10-1

Introduction to PKI10-1
PKI Overview10-1
PKI Terms10-1
Architecture of PKI10-2
Applications of PKI 10-3
Operation of PKI 10-3
PKI Configuration Task List 10-4
Configuring an Entity DN 10-4
Configuring a PKI Domain 10-6
Submitting a PKI Certificate Request10-7
Submitting a Certificate Request in Auto Mode 10-8
Submitting a Certificate Request in Manual Mode 10-8
Retrieving a Certificate Manually 10-9
Configuring PKI Certificate Verification10-10
Destroying a Local RSA Key Pair 10-11
Deleting a Certificate10-11
Configuring an Access Control Policy10-12
Displaying and Maintaining PKI 10-12
PKI Configuration Examples 10-13
Requesting a Certificate from a CA Running RSA Keon 10-13
Requesting a Certificate from a CA Running Windows 2003 Server10-16
Configuring a Certificate Attribute-Based Access Control Policy10-20
Troubleshooting PKI10-21
Failed to Retrieve a CA Certificate 10-21
Failed to Request a Local Certificate 10-22
Failed to Retrieve CRLs 10-22
11 SSL Configuration 11-1

SSL Overview 11-1
SSL Security Mechanism 11-1
SSL Protocol Stack11-2
SSL Configuration Task List 11-2
Configuring an SSL Server Policy11-3
SSL Server Policy Configuration Example 11-4
Configuring an SSL Client Policy 11-5
Displaying and Maintaining SSL 11-6

Troubleshooting SSL11-6
SSL Handshake Failure11-6
12 Public Key Configuration12-1

Asymmetric Key Algorithm Overview12-1
Basic Concepts12-1
Key Algorithm Types 12-1
Asymmetric Key Algorithm Applications12-2
Configuring the Local Asymmetric Key Pair12-2
Creating an Asymmetric Key Pair 12-2
Displaying or Exporting the Local RSA or DSA Host Public Key 12-3
Destroying an Asymmetric Key Pair12-3
Configuring the Public Key of a Peer 12-3
Displaying and Maintaining Public Keys 12-4
Public Key Configuration Examples12-5
Configuring the Public Key of a Peer Manually12-5
Importing the Public Key of a Peer from a Public Key File12-6
13 ACL Overview 13-1

Introduction to ACL 13-1
Introduction13-1
Application of ACLs on the Switch 13-1
Introduction to IPv4 ACL 13-2
IPv4 ACL Classification 13-2
IPv4 ACL Naming 13-2
IPv4 ACL Match Order 13-3
IPv4 ACL Step 13-4
Effective Period of an IPv4 ACL 13-4
IP Fragments Filtering with IPv4 ACL 13-4
Introduction to IPv6 ACL 13-5
IPv6 ACL Classification 13-5
IPv6 ACL Naming 13-5
IPv6 ACL Match Order 13-5
IPv6 ACL Step 13-6
Effective Period of an IPv6 ACL 13-6
ACL Application13-6
14 IPv4 ACL Configuration 14-1

Creating a Time Range 14-1
Configuring a Basic IPv4 ACL14-2
Configuring an Advanced IPv4 ACL 14-4
Configuring an Ethernet Frame Header ACL14-6
vi

Copying an IPv4 ACL14-7
Displaying and Maintaining IPv4 ACLs 14-8
IPv4 ACL Configuration Example 14-8
Network Requirements 14-8
15 IPv6 ACL Configuration 15-1

Creating a Time Range 15-1
Configuring a Basic IPv6 ACL15-1
Configuring an Advanced IPv6 ACL 15-2
Copying an IPv6 ACL15-4
Displaying and Maintaining IPv6 ACLs 15-5
IPv6 ACL Configuration Example 15-5
Network Requirements 15-5
16 ACL Application for Packet Filtering 16-1

Filtering Ethernet Frames 16-1
Filtering IPv4 Packets 16-1
Filtering IPv6 Packets 16-2
Configuring Packet Filtering Statistics Function 16-2
ACL Application Examples16-3
ACL Application to an Ethernet Interface 16-3
ACL Application to a VLAN Interface 16-4
vii

1 AAA Configuration
When configuring AAA, go to these sections for information you are interested in:
z Introduction to AAA
z Introduction to RADIUS
z Introduction to HWTACACS
z AAA Configuration Task List
z Configuring AAA
z Configuring RADIUS
z Configuring HWTACACS
z AAA Configuration Examples
z Troubleshooting AAA
Introduction to AAA
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for configuring
these three security functions to implement network security management.
AAA usually uses a client/server model, where the client runs on the network access server (NAS) and
the server maintains user information centrally. In an AAA network, a NAS is a server for users but a
client for the AAA servers, as shown in Figure 1-1.
Figure 1-1 AAA networking diagram
When a user tries to establish a connection to the NAS and to obtain the rights to access other
networks or some network resources, the NAS authenticates the user or the corresponding connection.
The NAS can transparently pass the users AAA information to the server (RADIUS server or
HWTACACS server). The RADIUS/HWTACACS protocol defines how a NAS and a server exchange
user information between them.
In the AAA network shown in Figure 1-1, there is a RADIUS server and a HWTACACS server. You can
determine the authentication, authorization and accounting methods according to the actual
1-1

requirements. For example, you can use the HWTACACS server for authentication and authorization,
and the RADIUS server for accounting.
The three security functions are described as follows:
z Authentication: Identifies remote users and judges whether a user is legal.
z Authorization: Grants different users different rights. For example, a user logging into the server
can be granted the permission to access and print the files in the server.
z Accounting: Records all network service usage information of users, including the service type,
start and end time, and traffic. In this way, accounting can be used for not only charging, but also
network security surveillance.
You can use AAA to provide only one or two security functions, if desired. For example, if your
company only wants employees to be authenticated before they access specific resources, you only
need to configure an authentication server. If network usage information is expected to be recorded,
you also need to configure an accounting server.
As described above, AAA provides a uniform framework to implement network security management.
It is a security mechanism that enables authenticated and authorized entities to access specific
resources and records operations of the entities. The AAA framework thus allows for excellent
scalability and centralized user information management.
AAA can be implemented through multiple protocols. Currently, the device supports using RADIUS,
HWTACACS for AAA, and RADIUS is often used in practice.
Introduction to RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol
in a client/server model. RADIUS can protect networks against unauthorized access and is often used
in network environments where both high security and remote user access are required. Based on
UDP, RADIUS uses UDP port 1812 for authentication and 1813 for accounting. RADIUS defines the
RADIUS packet format and message transfer mechanism.
RADIUS was originally designed for dial-in user access. With the diversification of access methods,
RADIUS has been extended to support more access methods, for example, Ethernet access and
ADSL access. It uses authentication and authorization in providing access services and uses
accounting to collect and record usage information of network resources.
Client/Server Model
z Client: The RADIUS client runs on the NASs located throughout the network. It passes user
information to designated RADIUS servers and acts on the responses (for example, rejects or
accepts user access requests).
z Server: The RADIUS server runs on the computer or workstation at the network center and
maintains information related to user authentication and network service access. It listens to
connection requests, authenticates users, and returns the processing results (for example,
rejecting or accepting the user access request) to the clients.
In general, the RADIUS server maintains three databases, namely, Users, Clients, and Dictionary, as
shown in Figure 1-2:
1-2

Figure 1-2 RADIUS server components
z Users: Stores user information such as the usernames, passwords, applied protocols, and IP
addresses.
z Clients: Stores information about RADIUS clients, such as the shared keys and IP addresses.
z Dictionary: Stores information about the meanings of RADIUS protocol attributes and their values.
Security and Authentication Mechanisms
Information exchanged between a RADIUS client and the RADIUS server is authenticated with a
shared key, which is never transmitted over the network. This enhances the information exchange
security. In addition, to prevent user passwords from being intercepted in non-secure networks,
RADIUS encrypts passwords before transmitting them.
A RADIUS server supports multiple user authentication methods, for example, the Password
Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Moreover, a
RADIUS server can act as the client of another AAA server to provide authentication proxy services.
Basic Message Exchange Process of RADIUS
Figure 1-3 illustrates the interaction of the host, the RADIUS client, and the RADIUS server.
Figure 1-3 Basic message exchange process of RADIUS
Host RADIUS client RADIUS server
1) Username and password

2) Access-Request
3) Access-Accept/Reject
4) Accounting-Request (start)
5) Accounting-Response
6) The host accesses the resources
7) Accounting-Request (stop)
8) Accounting-Response
9) Notification of access termination
The following is how RADIUS operates:
1-3

2) The host initiates a connection request carrying the username and password to the RADIUS
client.
3) Having received the username and password, the RADIUS client sends an authentication request
(Access-Request) to the RADIUS server, with the user password encrypted by using the
Message-Digest 5 (MD5) algorithm and the shared key.
4) The RADIUS server authenticates the username and password. If the authentication succeeds, it
sends back an Access-Accept message containing the users authorization information. If the
authentication fails, it returns an Access-Reject message.
5) The RADIUS client permits or denies the user according to the returned authentication result. If it
permits the user, it sends a start-accounting request (Accounting-Request) to the RADIUS server.
6) The RADIUS server returns a start-accounting response (Accounting-Response) and starts
accounting.
7) The user accesses the network resources.
8) The host requests the RADIUS client to tear down the connection and the RADIUS client sends a
stop-accounting request (Accounting-Request) to the RADIUS server.
9) The RADIUS server returns a stop-accounting response (Accounting-Response) and stops
accounting for the user.
10) The user stops access to network resources.
RADIUS Packet Format
RADIUS uses UDP to transmit messages. It ensures the smooth message exchange between the
RADIUS server and the client through a series of mechanisms, including the timer management
mechanism, retransmission mechanism, and slave server mechanism. Figure 1-4 shows the RADIUS
packet format.
Figure 1-4 RADIUS packet format
Descriptions of the fields are as follows:

2) The Code field (1-byte long) is for indicating the type of the RADIUS packet. Table 1-1 gives the
possible values and their meanings.
Table 1-1 Main values of the Code field
Code Packet type Description

From the client to the server. A packet of this type carries user
information for the server to authenticate the user. It must
1 Access-Request
contain the User-Name attribute and can optionally contain the
attributes of NAS-IP-Address, User-Password, and NAS-Port.
1-4

Code Packet type Description
From the server to the client. If all the attribute values carried in
2 Access-Accept the Access-Request are acceptable, that is, the authentication
succeeds, the server sends an Access-Accept response.
From the server to the client. If any attribute value carried in the
3 Access-Reject Access-Request is unacceptable, the server rejects the user
and sends an Access-Reject response.
From the client to the server. A packet of this type carries user
information for the server to start/stop accounting for the user. It
4 Accounting-Request contains the Acct-Status-Type attribute, which indicates
whether the server is requested to start the accounting or to
end the accounting.
From the server to the client. The server sends to the client a
packet of this type to notify that it has received the
5 Accounting-Response
Accounting-Request and has correctly started recording the
accounting information.
3) The Identifier field (1-byte long) is for matching request packets and response packets and
detecting retransmitted request packets. The request and response packets of the same type
have the same identifier.
4) The Length field (2-byte long) indicates the length of the entire packet, including the Code,
Identifier, Length, Authenticator, and Attribute fields. The value of the field is in the range 20 to
4096. Bytes beyond the length are considered the padding and are neglected upon reception. If
the length of a received packet is less than that indicated by the Length field, the packet is
dropped.
5) The Authenticator field (16-byte long) is used to authenticate replies from the RADIUS server, and
is also used in the password hiding algorithm. There are two kinds of authenticators: request
authenticator and response authenticator.
6) The Attribute field, with a variable length, carries the specific authentication, authorization, and
accounting information for defining configuration details of the request or response. This field is
represented in triplets of Type, Length, and Value.
z Type: One byte, in the range 1 to 255. It indicates the type of the attribute. Commonly used
attributes for RADIUS authentication, authorization and accounting are listed in Table 1-2.
z Length: One byte for indicating the length of the attribute in bytes, including the Type, Length, and
Value fields.
z Value: Value of the attribute, up to 253 bytes. Its format and content depend on the Type and
Length fields.
Table 1-2 RADIUS attributes
No. Attribute No. Attribute

1 User-Name 45 Acct-Authentic
2 User-Password 46 Acct-Session-Time
3 CHAP-Password 47 Acct-Input-Packets
4 NAS-IP-Address 48 Acct-Output-Packets
5 NAS-Port 49 Acct-Terminate-Cause
6 Service-Type 50 Acct-Multi-Session-Id
7 Framed-Protocol 51 Acct-Link-Count
1-5

8 Framed-IP-Address 52 Acct-Input-Gigawords
9 Framed-IP-Netmask 53 Acct-Output-Gigawords
10 Framed-Routing 54 (unassigned)
11 Filter-ID 55 Event-Timestamp
12 Framed-MTU 56-59 (unassigned)
13 Framed-Compression 60 CHAP-Challenge
14 Login-IP-Host 61 NAS-Port-Type
15 Login-Service 62 Port-Limit
16 Login-TCP-Port 63 Login-LAT-Port
17 (unassigned) 64 Tunnel-Type
18 Reply_Message 65 Tunnel-Medium-Type
19 Callback-Number 66 Tunnel-Client-Endpoint
20 Callback-ID 67 Tunnel-Server-Endpoint
21 (unassigned) 68 Acct-Tunnel-Connection
22 Framed-Route 69 Tunnel-Password
23 Framed-IPX-Network 70 ARAP-Password
24 State 71 ARAP-Features
25 Class 72 ARAP-Zone-Access
26 Vendor-Specific 73 ARAP-Security
27 Session-Timeout 74 ARAP-Security-Data
28 Idle-Timeout 75 Password-Retry
29 Termination-Action 76 Prompt
30 Called-Station-Id 77 Connect-Info
31 Calling-Station-Id 78 Configuration-Token
32 NAS-Identifier 79 EAP-Message
33 Proxy-State 80 Message-Authenticator
34 Login-LAT-Service 81 Tunnel-Private-Group-id
35 Login-LAT-Node 82 Tunnel-Assignment-id
36 Login-LAT-Group 83 Tunnel-Preference
37 Framed-AppleTalk-Link 84 ARAP-Challenge-Response
38 Framed-AppleTalk-Network 85 Acct-Interim-Interval
39 Framed-AppleTalk-Zone 86 Acct-Tunnel-Packets-Lost
40 Acct-Status-Type 87 NAS-Port-Id
41 Acct-Delay-Time 88 Framed-Pool
42 Acct-Input-Octets 89 (unassigned)
43 Acct-Output-Octets 90 Tunnel-Client-Auth-id
1-6

44 Acct-Session-Id 91 Tunnel-Server-Auth-id
The attribute types listed in Table 1-2 are defined by RFC 2865, RFC 2866, RFC 2867, and RFC 2568.
Extended RADIUS Attributes
The RADIUS protocol features excellent extensibility. Attribute 26 (Vender-Specific) defined by RFC
2865 allows a vender to define extended attributes to implement functions that the standard RADIUS
protocol does not provide.
A vendor can encapsulate multiple type-length-value (TLV) sub-attributes in RADIUS packets for
extension in applications. As shown in Figure 1-5, a sub-attribute that can be encapsulated in Attribute
26 consists of the following four parts:
z Vendor-ID (four bytes): Indicates the ID of the vendor. Its most significant byte is 0 and the other
three bytes contain a code complying with RFC 1700.
z Vendor-Type: Indicates the type of the sub-attribute.
z Vendor-Length: Indicates the length of the sub-attribute.
z Vendor-Data: Indicates the contents of the sub-attribute.
Figure 1-5 Segment of a RADIUS packet containing an extended attribute
Introduction to HWTACACS
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security
protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for
information exchange between NAS and HWTACACS server.
HWTACACS is mainly used to provide AAA services for terminal users. In a typical HWTACACS
application, a terminal user needs to log into the device for operations, and HWTACACS authenticates,
authorizes and keeps accounting for the user. Working as the HWTACACS client, the device sends the
username and password to the HWTACACS sever for authentication. After passing authentication and
being authorized, the user can log into the device to perform operations.
1-7

Differences Between HWTACACS and RADIUS
HWTACACS and RADIUS have many common features, like implementing AAA, using a client/server
model, using shared keys for user information security and having good flexibility and extensibility.
Meanwhile, they also have differences, as listed in Table 1-3.
Table 1-3 Primary differences between HWTACACS and RADIUS
HWTACACS RADIUS
Uses TCP, providing more reliable network
Uses UDP, providing higher transport efficiency.
transmission.
Encrypts the entire packet except for the Encrypts only the user password field in an
HWTACACS header. authentication packet.
Protocol packets are complicated and
authorization is independent of authentication. Protocol packets are simple and authorization is
Authentication and authorization can be combined with authentication.
deployed on different HWTACACS servers.
Supports authorized use of configuration
Does not support authorized use of
commands. For example, an authenticated login
configuration commands.
user can be authorized to configure the device.
Basic Message Exchange Process of HWTACACS
The following takes a Telnet user as an example to describe how HWTACACS performs user
authentication, authorization, and accounting. Figure 1-6 illustrates the basic message exchange
process of HWTACACS.
1-8

Figure 1-6 Basic message exchange process of HWTACACS for a Telnet user
Host HWTACACS client HWTACACS server
1) The user logs in
2) Start-authentication packet
3) Authentication response requesting the username
4) Request for username
5) The user inputs the username

6) Authentication continuance packet with the
username
7) Authentication response requesting the login

password
8) Request for password
9) The user inputs the password

10) Authentication continuance packet with the
login password
11) Authentication response indicating successful
authentication
12) User authorization request packet

13) Authorization response indicating successful
authorization
14) The user logs in successfully
15) Start-accounting request

16) Accounting response indicating the start of
accounting
17) The user logs off
18) Stop-accounting request
19) Stop-accounting response
2) A Telnet user sends an access request to the NAS.

3) Upon receiving the request, the HWTACACS client sends a start-authentication packet to the
HWTACACS server.
4) The HWTACACS server sends back an authentication response requesting the username.
5) Upon receiving the response, the HWTACACS client asks the user for the username.
6) The user inputs the username.
7) After receiving the username from the user, the HWTACACS client sends to the server a
continue-authentication packet carrying the username.
8) The HWTACACS server sends back an authentication response, requesting the login password.
9) Upon receipt of the response, the HWTACACS client asks the user for the login password.
10) The user inputs the password.
11) After receiving the login password, the HWTACACS client sends to the HWTACACS server a
continue-authentication packet carrying the login password.
12) The HWTACACS server sends back an authentication response indicating that the user has
passed authentication.
1-9

13) The HWTACACS client sends the user authorization request packet to the HWTACACS server.
14) The HWTACACS server sends back the authorization response, indicating that the user is
authorized now.
15) Knowing that the user is now authorized, the HWTACACS client pushes the configuration
interface of the NAS to the user.
16) The HWTACACS client sends a start-accounting request to the HWTACACS server.
17) The HWTACACS server sends back an accounting response, indicating that it has received the
start-accounting request.
18) The user logs off.
19) The HWTACACS client sends a stop-accounting request to the HWTACACS server.
20) The HWTACACS server sends back a stop-accounting response, indicating that the
stop-accounting request has been received.

The protocols and standards related to AAA, RADIUS, HWTACACS include:
z RFC 2865: Remote Authentication Dial In User Service (RADIUS)
z RFC 2866: RADIUS Accounting
z RFC 2867: RADIUS Accounting Modifications for Tunnel Protocol Support
z RFC 2868: RADIUS Attributes for Tunnel Protocol Support
z RFC 2869: RADIUS Extensions
z RFC 1492: An Access Control Protocol, Sometimes Called TACACS
AAA Configuration Task List

The basic procedure to configure AAA is as follows:
1) Configure the required AAA schemes.
z Local authentication: Configure local users and related attributes, including usernames and
passwords of the users to be authenticated.
z Remote authentication: Configure the required RADIUS and/or HWTACACS schemes, and
configure user attributes on the servers accordingly.
2) Configure the AAA methods: Reference the configured AAA schemes in the users ISP domains.
z Authentication method: No authentication (none), local authentication (local), or remote
authentication (scheme)
z Authorization method: No authorization (none) , local authorization (local), or remote
authorization (scheme)
z Accounting method: No accounting (none), local accounting (local), or remote accounting
(scheme)
For login users, it is necessary to configure the authentication mode for logging into the user interface
as scheme. For detailed information, refer to Login Configuration of the System Volume.
1-10

AAA Configuration Task List
Task Remarks
Creating an ISP Domain Required
Configuring ISP Domain Attributes Optional

Required
For local authentication, refer to Configuring
Local User Attributes.
Configuring AAA Authentication Methods for an
ISP Domain For RADIUS authentication, refer to Configuring
RADIUS.
For HWTACACS authentication, refer to
Configuring HWTACACS.
Configuring AAA Authorization Methods for an
Optional
ISP Domain
Configuring AAA Accounting Methods for an ISP
Optional
Domain
Configuring Local User Attributes Optional
Configuring User Group Attributes Optional
Tearing down User Connections Forcibly Optional
Displaying and Maintaining AAA Optional
RADIUS Configuration Task List
Task Remarks
Creating a RADIUS Scheme Required
Specifying the RADIUS Authentication/Authorization Servers Required
Specifying the RADIUS Accounting Servers and Relevant Parameters Optional
Setting the Shared Key for RADIUS Packets Required

Setting the Upper Limit of RADIUS Request Retransmission Attempts Optional
Setting the Supported RADIUS Server Type Optional
Setting the Status of RADIUS Servers Optional

Configuring Attributes Related to Data to Be Sent to the RADIUS Server Optional
Setting Timers Regarding RADIUS Servers Optional
Specifying a Security Policy Server Optional

Enabling the Listening Port of the RADIUS Client Optional
Displaying and Maintaining RADIUS Optional
1-11

HWTACACS Configuration Task List
Task Remarks
Creating a HWTACACS scheme Required
Specifying the HWTACACS Authentication Servers Required

Specifying the HWTACACS Authorization Servers Optional
Specifying the HWTACACS Accounting Servers Optional
Setting the Shared Key for HWTACACS Packets Required
Configuring Attributes Related to the Data Sent to HWTACACS Server Optional
Setting Timers Regarding HWTACACS Servers Optional
Displaying and Maintaining HWTACACS Optional
Configuring AAA
By configuring AAA, you can provide network access service for legal users, protect the networking
devices, and avoid unauthorized access and repudiation. In addition, you can configure ISP domains
to perform AAA on accessing users.
The AAA feature allows you to manage users based on their access types:
z LAN users: Users on a LAN who access through, for example, 802.1X authentication or MAC
address authentication.
z Login users: Users who log in using, for example, SSH, Telnet, FTP, or HyperTerminal.
You can configure separate authentication/authorization/accounting policies for all the other types of
users.
For a user who has logged in to the device, AAA can provide the command authorization service to
enhance device security: Allows the authorization server to check each command executed by the
login user and only authorized commands can be successfully executed.
For remote authentication, authorization, or accounting, you must create the RADIUS or HWTACACS
scheme first. For RADIUS scheme configuration, refer to Configuring RADIUS. For HWTACACS
scheme configuration, refer to Configuring HWTACACS.
Creating an ISP Domain
An Internet service provider (ISP) domain represents a group of users belonging to it. For a username
in the userid@isp-name format, the access device considers the userid part the username for
authentication and the isp-name part the domain name.
In a networking scenario with multiple ISPs, an access device may connect users of different ISPs. As
users of different ISPs may have different user attributes (such as username and password structure,
service type, and rights), you need to configure ISP domains to distinguish the users. In addition, you
need to configure different attribute sets including AAA methods for the ISP domains.
1-12

For the NAS, each user belongs to an ISP domain. Up to 16 ISP domains can be configured on a NAS.
If a user does not provide the ISP domain name, the system considers that the user belongs to the
default ISP domain.
Follow these steps to create an ISP domain:

Create an ISP domain and

domain isp-name Required
enter ISP domain view
Optional
domain default enable
Specify the default ISP domain By default, the system has a default
isp-name
ISP domain named system.
z You cannot delete the default ISP domain unless you change it to a non-default ISP domain (with
the domain default disable command) first.
z If a user enters a username without an ISP domain name, the device uses the authentication
method configured for the default ISP domain to authenticate the user.
Configuring ISP Domain Attributes
Follow these steps to configure ISP domain attributes:

Optional
Place the ISP domain to the When created, an ISP domain
state { active | block } is in the active state by default,
state of active or blocked
and users in the domain can
request network services.
Specify the maximum number Optional
access-limit enable
of active users in the ISP
max-user-number No limit by default
domain
Optional
Disabled by default
Configure the idle cut function idle-cut enable minute
Currently, this command is
effective only for LAN users.
Configure the self-service self-service-url enable Optional

server localization function url-string Disabled by default
1-13

A self-service RADIUS server, for example, iMC, is required for the self-service server localization
function to work. With the self-service function, a user can manage and control his or her accounting
information or card number. A server with self-service software is a self-service server.
Configuring AAA Authentication Methods for an ISP Domain
In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to
the interactive authentication process of username/password/user information during access or
service request. The authentication process neither sends authorization information to a supplicant nor
triggers any accounting.
AAA supports the following authentication methods:
z No authentication: All users are trusted and no authentication is performed. Generally, this
method is not recommended.
z Local authentication: Authentication is performed by the NAS, which is configured with the user
information, including the usernames, passwords, and attributes. Local authentication features
high speed and low cost, but the amount of information that can be stored is limited by the
hardware.
z Remote authentication: The access device cooperates with a RADIUS or HWTACACS server to
authenticate users. As for RADIUS, the device can use the standard RADIUS protocol or
extended RADIUS protocol in collaboration with systems like iMC to implement user
authentication. Remote authentication features centralized information management, high
capacity, high reliability, and support for centralized authentication for multiple devices. You can
configure local authentication as the backup method in case the remote server is not available.
You can configure AAA authentication to work alone without authorization and accounting. By default,
an ISP domain uses the local authentication method.
Before configuring authentication methods, complete these three tasks:
z For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be
referenced first. The local and none authentication methods do not require any scheme.
z Determine the access mode or service type to be configured. With AAA, you can configure an
authentication method specifically for each access mode and service type, limiting the
authentication protocols that can be used for access.
z Determine whether to configure an authentication method for all access modes or service types.
Follow these steps to configure AAA authentication methods for an ISP domain:

1-14

authentication default
{ hwtacacs-scheme
Specify the default Optional
hwtacacs-scheme-name
authentication method for all
[ local ] | local | none | local by default
types of users
radius-scheme
radius-scheme-name [ local ] }
authentication lan-access Optional

Specify the authentication
{ local | none | radius-scheme The default authentication
method for LAN users
radius-scheme-name [ local ] } method is used by default.
authentication login
{ hwtacacs-scheme Optional
Specify the authentication hwtacacs-scheme-name
method for login users [ local ] | local | none | The default authentication
radius-scheme method is used by default.
z The authentication method specified with the authentication default command is for all types of
users and has a priority lower than that for a specific access mode.
z With an authentication method that references a RADIUS scheme, AAA accepts only the
authentication result from the RADIUS server. The Access-Accept message from the RADIUS
server does include the authorization information, but the authentication process ignores the
information.
z With the radius-scheme radius-scheme-name local or hwtacacs-scheme
hwtacacs-scheme-name local keyword and argument combination configured, local
authentication is the backup method and is used only when the remote server is not available.
z If the primary authentication method is local or none, the system performs local authentication or
does not perform any authentication, and will not use any RADIUS or HWTACACS authentication
scheme.
Configuring AAA Authorization Methods for an ISP Domain
In AAA, authorization is a separate process at the same level as authentication and accounting. Its
responsibility is to send authorization requests to the specified authorization server and to send
authorization information to users. Authorization method configuration is optional in AAA configuration.
AAA supports the following authorization methods:
z No authorization: Every user is trusted and has the corresponding default rights of the system.
z Local authorization: Users are authorized by the access device according to the attributes
configured for them.
z Remote authorization: The access device cooperates with a RADIUS or HWTACACS server to
authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS
authorization can work only after RADIUS authentication is successful, and the authorization
information is carried in the Access-Accept message. HWTACACS authorization is separate from
HWTACACS authentication, and the authorization information is carried in the authorization
1-15

response after successful authentication. You can configure local authorization or no authorization
as the backup method in case the remote server is not available.
By default, an ISP domain uses the local authorization method. If the no authorization method (none)
is configured, the users are not required to be authorized, in which case an authenticated user has the
default right. The default right is visiting (the lowest one) for EXEC users (that is, console users who
use the console, AUX port, or Telnet to connect to the device, such as Telnet or SSH users. Each
connection of these types is called an EXEC user). The default right for FTP users is to use the root
directory of the device.
Before configuring authorization methods, complete these three tasks:
1) For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For
RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS
authentication scheme; otherwise, it does not take effect.
2) Determine the access mode or service type to be configured. With AAA, you can configure an
authorization scheme specifically for each access mode and service type, limiting the
authorization protocols that can be used for access.
3) Determine whether to configure an authorization method for all access modes or service types.
Follow these steps to configure AAA authorization methods for an ISP domain:

authorization default
{ hwtacacs-scheme
Specify the default Optional
hwtacacs-scheme-name
authorization method for all
[ local ] | local | none | local by default
types of users
radius-scheme
authorization command Optional
Specify the command { hwtacacs-scheme
authorization method hwtacacs-scheme-name The default authorization
[ local | none ] | local | none } method is used by default.
authorization lan-access Optional

Specify the authorization
{ local | none | radius-scheme The default authorization
method for LAN users
radius-scheme-name [ local ] } method is used by default.
authorization login
Specify the authorization hwtacacs-scheme-name
method for login users [ local ] | local | none | The default authorization
radius-scheme method is used by default.
1-16

z The authorization method specified with the authorization default command is for all types of
users and has a priority lower than that for a specific access mode.
z RADIUS authorization is special in that it takes effect only when the RADIUS authorization
scheme is the same as the RADIUS authentication scheme. In addition, if a RADIUS authorization
fails, the error message returned to the NAS says that the server is not responding.
hwtacacs-scheme-name [ local | none ] keyword and argument combination configured, local
authorization or no authorization is the backup method and is used only when the remote server is
not available.
z If the primary authorization method is local or none, the system performs local authorization or
does not perform any authorization; it will never use the RADIUS or HWTACACS authorization
scheme.
z The authorization information of the RADIUS server is sent to the RADIUS client along with the
authentication response message; therefore, you cannot specify a separate RADIUS
authorization server. If you use RADIUS for authorization and authentication, you must use the
same scheme setting for authorization and authentication; otherwise, the system will prompt you
with an error message.
Configuring AAA Accounting Methods for an ISP Domain
In AAA, accounting is a separate process at the same level as authentication and authorization. Its
responsibility is to send accounting start/update/end requests to the specified accounting server.
Accounting is not required, and therefore accounting method configuration is optional.
AAA supports the following accounting methods:
z No accounting: The system does not perform accounting for the users.
z Local accounting: Local accounting is implemented on the access device. It is for collecting
statistics on the number of users and controlling the number of local user connections; it does not
provide statistics for user charge.
z Remote accounting: The access device cooperates with a RADIUS server or HWTACACS server
for accounting of users. You can configure local accounting as the backup method in case the
remote server is not available.
By default, an ISP domain uses the local accounting method.
Before configuring accounting methods, complete these three tasks:
1) For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be
referenced first. The local and none authentication methods do not require any scheme.
2) Determine the access mode or service type to be configured. With AAA, you can configure an
accounting method specifically for each access mode and service type, limiting the accounting
protocols that can be used for access.
3) Determine whether to configure an accounting method for all access modes or service types.
Follow these steps to configure AAA accounting methods for an ISP domain:
1-17


Enable the accounting optional Optional

accounting optional
feature Disabled by default
accounting default
{ hwtacacs-scheme
Specify the default accounting hwtacacs-scheme-name Optional
method for all types of users [ local ] | local | none | local by default
radius-scheme
accounting command Optional

Specify the accounting
hwtacacs-scheme The default accounting
method for command
hwtacacs-scheme-nam method is used by
line users
e default.
accounting lan-access { local Optional

Specify the accounting method
| none | radius-scheme The default accounting method
for LAN users
radius-scheme-name [ local ] } is used by default.
accounting login
Specify the accounting method hwtacacs-scheme-name
for login users [ local ] | local | none | The default accounting method
radius-scheme is used by default.
z With the accounting optional command configured, a user to be disconnected can still use the
network resources even when there is no available accounting server or communication with the
current accounting server fails.
z The local accounting is not used for accounting implementation, but together with the attribute
access-limit command for limiting the number of local user connections. However, with the
accounting optional command configured, the limit on the number of local user connections is
not effective.
z The accounting method specified with the accounting default command is for all types of users
and has a priority lower than that for a specific access mode.
hwtacacs-scheme-name local keyword and argument combination configured, local accounting is
the backup method and is used only when the remote server is not available.
z If the primary accounting method is local or none, the system performs local accounting or does
not perform any accounting, and will not use the RADIUS or HWTACACS accounting scheme.
z In login access mode, accounting is not supported for FTP services.
1-18

Configuring Local User Attributes
For local authentication, you need to create local users and configure user attributes on the device as
needed.
A local user represents a set of user attributes configured on a device, and such a user set is uniquely
identified by the username. For a user requesting network service to pass local authentication, you
must add an entry as required in the local user database of the device.
Each local user belongs to a local user group and bears all attributes of the group, such as the
password control attributes and authorization attributes. For details about local user group, refer to
Configuring User Group Attributes.
When configuring local users and local user groups, pay attention to the effective ranges and priority
relationship of user group attributes and user attributes:
z Authorization attributes
You can configure an authorization attribute in user group view or local user view, making the attribute
effective on all local users of the group or only the local user. An authorization attribute configured in
local user view takes precedence over the same attribute configured in user group view.
Follow these steps to configure the attributes for a local user:

Optional
local-user auto by default, indicating
Set the password display mode to display the password of
password-display-mode
for all local users a local user in the way
{ auto | cipher-force }
indicated by the password
command.
Required
Add a local user and enter local
local-user user-name No local user exists by
user view
default.
Configure a password for the local password { cipher | simple }
Optional
user password
Optional
Place the local user to the state of When created, a local user
state { active | block } is in the state of active by
active or blocked
default, and the user can
request network services.
Optional
Set the maximum number of user By default, there is no limit
connections using the local user access-limit max-user-number on the maximum number of
account user connections using the
same local user account.
Optional
Specify the service types for the service-type { ftp | lan-access |
local user { ssh | telnet | terminal } * } By default, no service is
authorized to a user.
1-19

bind-attribute { call-number
call-number [ : subcall-number ] Optional
Configure the binding attributes | ip ip-address | location port By default, no binding
for the local user slot-number subslot-number attribute is configured for a
port-number | mac mac-address local user.
| vlan vlan-id } *
authorization-attribute { acl
acl-number | callback-number Optional
callback-number | idle-cut
Configure the authorization By default, no authorization
minute | level level |
attributes for the local user attribute is configured for a
user-profile profile-name | vlan
vlan-id | work-directory local user.
directory-name } *
Optional
Set the expiration time of the user expiration-date time
Not set by default
Optional
Specify the user group for the By default, a local user
group group-name
local user belongs to default user
group system.
Note that:
z With the local-user password-display-mode cipher-force command configured, a local user
password is always displayed in cipher text, regardless of the configuration of the password
command. In this case, if you use the save command to save the configuration, all existing local
user passwords will still be displayed in cipher text after the device restarts, even if you restore the
display mode to auto.
z The access-limit command configured for a local user takes effect only when local accounting is
used.
z Local authentication checks the service types of a local user. If the service types are not available,
the user cannot pass authentication.
z In the authentication method that requires the username and password, including local
authentication, RADIUS authentication and HWTACACS authentication, the commands that a
login user can use after logging in depend on the level of the user. In other authentication methods,
which commands are available depends on the level of the user interface. For an SSH user using
public key authentication, the commands that can be used depend on the level configured on the
user interface. For details regarding authentication method and commands accessible to user
interface, refer to Login Configuration in the System Volume.
z Binding attributes are checked upon authentication of a local user. If the checking fails, the user
fails the authentication. Therefore, be cautious when deciding which binding attributes should be
configured for a local user.
z Every configurable authorization attribute has its definite application environments and purposes.
Therefore, when configuring authorization attributes for a local user, consider what attributes are
needed.
Configuring User Group Attributes
For simplification of local user configuration and manageability of local users, the concept of user
group is introduced. A user group consists of a group of local users and has a set of local user
attributes. You can configure local user attributes for a user group to implement centralized
1-20

management of user attributes for the local users in the group. Currently, you can configure password
control attributes and authorization attributes for a user group.
By default, every newly added local user belongs to the user group of system and bears all attributes
of the group. User group system is automatically created by the device.
Follow these steps to configure the attributes for a user group:

Create a user group and enter user

user-group group-name Required
group view
authorization-attribute { acl Optional
acl-number | callback-number By default, no
Configure the authorization callback-number | idle-cut minute | authorization
attributes for the user group level level | user-profile profile-name | attribute is
vlan vlan-id | work-directory configured for a
directory-name } * user group.
Tearing down User Connections Forcibly
Follow these steps to tear down user connections forcibly:

cut connection { access-type
{ dot1x | mac-authentication }
| all | domain isp-name |
interface interface-type Required
Tear down AAA user
interface-number | ip Applies to only LAN access
connections forcibly
ip-address | mac mac-address user connections at present
| ucibindex ucib-index |
user-name user-name | vlan
vlan-id } [ slot slot-number ]
Displaying and Maintaining AAA

Display the configuration
information of a specified ISP display domain [ isp-name ] Available in any view
domain or all ISP domains
display connection [access-type
{ dot1x | mac-authentication } |
domain isp-name | interface
Display information about interface-type interface-number | ip
specified or all user connections ip-address | mac mac-address |
ucibindex ucib-index | user-name
user-name | vlan vlan-id ] [ slot
slot-number ]
1-21

display local-user [ idle-cut
{ disable | enable } | service-type
Display information about { ftp | lan-access | ssh | telnet |
specified or all local users terminal } | state { active | block } |
user-name user-name | vlan
vlan-id ] [ slot slot-number ]
Display configuration
information about a specified display user-group [ group-name ] Available in any view
user group or all user groups
Configuring RADIUS
The RADIUS protocol is configured on a per scheme basis. After creating a RADIUS scheme, you
need to configure the IP addresses and UDP ports of the RADIUS servers for the scheme. The servers
include authentication/authorization servers and accounting servers, or primary servers and secondary
servers. In other words, the attributes of a RADIUS scheme mainly include IP addresses of primary
and secondary servers, shared key, and RADIUS server type.
Actually, the RADIUS protocol configurations only set the parameters necessary for the information
interaction between a NAS and a RADIUS server. For these settings to take effect, you must reference
the RADIUS scheme containing those settings in ISP domain view. For information about the
commands for referencing a scheme, refer to Configuring AAA.
When there are users online, you cannot modify RADIUS parameters other than the retransmission
ones and the timers.
Creating a RADIUS Scheme
Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and
enter RADIUS scheme view:

Create a RADIUS scheme and radius scheme Required

enter RADIUS scheme view radius-scheme-name Not defined by default
A RADIUS scheme can be referenced by more than one ISP domain at the same time.
1-22

Specifying the RADIUS Authentication/Authorization Servers
Follow these steps to specify the RADIUS authentication/authorization servers:


Specify the primary RADIUS
primary authentication Required
authentication/authorization
ip-address [ port-number ] Configure at least one of
server
the commands
Specify the secondary RADIUS
secondary authentication No authentication server by
authentication/authorization
ip-address [ port-number ] default
server
z It is recommended to specify only the primary RADIUS authentication/authorization server if

backup is not required.
z If both the primary and secondary authentication/authorization servers are specified, the
secondary one is used when the primary one is unreachable.
z In practice, you may specify two RADIUS servers as the primary and secondary
authentication/authorization servers respectively. At one time, a server can be the primary
authentication/authorization server for a scheme and the secondary authentication/authorization
servers for another scheme.
z The IP addresses of the primary and secondary authentication/authorization servers for a scheme
cannot be the same. Otherwise, the configuration fails.
Specifying the RADIUS Accounting Servers and Relevant Parameters
Follow these steps to specify the RADIUS accounting servers and perform related configurations:


Specify the primary RADIUS primary accounting Required
accounting server ip-address [ port-number ] Configure at least one of the
commands
Specify the secondary RADIUS secondary accounting
No accounting server by
accounting server ip-address [ port-number ]
default
Enable the device to buffer Optional
stop-accounting-buffer
stop-accounting requests
enable Enabled by default
getting no responses
1-23

retry stop-accounting
stop-accounting request
retry-times 500 by default
transmission attempts
retry realtime-accounting
accounting request
z It is recommended to specify only the primary RADIUS accounting server if backup is not
required.
z If both the primary and secondary accounting servers are specified, the secondary one is used
when the primary one is not reachable.
z In practice, you can specify two RADIUS servers as the primary and secondary accounting
servers respectively, or specify one server to function as the primary accounting server in a
scheme and the secondary accounting server in another scheme. Besides, because RADIUS
uses different UDP ports to receive authentication/authorization and accounting packets, the port
for authentication/authorization must be different from that for accounting.
z You can set the maximum number of stop-accounting request transmission buffer, allowing the
device to buffer and resend a stop-accounting request until it receives a response or the number
of transmission retries reaches the configured limit. In the latter case, the device discards the
packet.
z You can set the maximum number of accounting request transmission attempts on the device,
allowing the device to disconnect a user when the number of accounting request transmission
attempts for the user reaches the limit but it still receives no response to the accounting request.
z The IP addresses of the primary and secondary accounting servers cannot be the same.
Otherwise, the configuration fails.
z Currently, RADIUS does not support keeping accounts on FTP users.
Setting the Shared Key for RADIUS Packets
The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between
them and a shared key to verify the packets. Only when the same key is used can they properly
receive the packets and make responses.
Follow these steps to set the shared key for RADIUS packets:


Set the shared key for RADIUS Required
key { accounting |
authentication/authorization or
authentication } string No key by default
accounting packets
1-24

The shared key configured on the device must be the same as that configured on the RADIUS server.
Setting the Upper Limit of RADIUS Request Retransmission Attempts
Because RADIUS uses UDP packets to carry data, the communication process is not reliable. If a NAS
receives no response from the RADIUS server before the response timeout timer expires, it is required
to retransmit the RADIUS request. If the number of transmission attempts exceeds the specified limit
but it still receives no response, it considers that the authentication has failed.
Follow these steps to set the upper limit of RADIUS request retransmission attempts:


Set the number of Optional
retransmission attempts of retry retry-times
RADIUS packets 3 by default
z The maximum number of retransmission attempts of RADIUS packets multiplied by the RADIUS
server response timeout period cannot be greater than 75.
z Refer to the timer response-timeout command in the command manual for configuring RADIUS
server response timeout period.
Setting the Supported RADIUS Server Type
Follow these steps to set the supported RADIUS server type:


Optional
Specify the RADIUS server server-type { extended | By default, the supported
type supported by the device standard } RADIUS server type is
standard.
1-25

z If you change the type of RADIUS server, the data stream destined to the original RADIUS server
will be restored to the default unit.
z When a third-party RADIUS is used, you can configure the RADIUS server to standard or
extended. When iMC server is used, you must configure the RADIUS server to extended.
Setting the Status of RADIUS Servers
When a primary server fails, the device automatically tries to communicate with the secondary server.
When both the primary and secondary servers are available, the device sends request packets to the
primary server.
Once the primary server fails, the primary server turns into the state of block, and the device turns to
the secondary server. In this case:
z If the secondary server is available, the device triggers the primary server quiet timer. After the
quiet timer times out, the status of the primary server is active again and the status of the
secondary server remains the same.
z If the secondary server fails, the device restores the status of the primary server to active
immediately.
If the primary server has resumed, the device turns to use the primary server and stops communicating
with the secondary server. After accounting starts, the communication between the client and the
secondary server remains unchanged.
Follow these steps to set the status of RADIUS servers:


Set the status of the primary
state primary authentication
RADIUS
{ active | block }
authentication/authorization server
Set the status of the primary state primary accounting { active Optional
RADIUS accounting server | block } active for every
server configured with
Set the status of the secondary IP address in the
state secondary authentication
RADIUS RADIUS scheme
{ active | block }
authentication/authorization server
Set the status of the secondary state secondary accounting
RADIUS accounting server { active | block }
1-26

z If both the primary server and the secondary server are in the blocked state, it is necessary to
manually turn the secondary server to the active state so that the secondary server can perform
authentication. If the secondary server is still in the blocked state, the primary/secondary
switchover cannot take place.
z If one server is in the active state while the other is blocked, the primary/secondary switchover will
not take place even if the active server is not reachable.
z The server status set by the state command cannot be saved in the configuration file and will be
restored to active every time the server restarts.
Configuring Attributes Related to Data to Be Sent to the RADIUS Server
Follow these steps to configure the attributes related to data to be sent to the RADIUS server:

radius trap Optional
Enable the RADIUS trap
{ accounting-server-down |
function Disabled by default
authentication-server-down }

Optional
Specify the format of the user-name-format
username to be sent to a { keep-original | with-domain By default, the ISP domain
RADIUS server | without-domain } name is included in the
username.
data-flow-format { data { byte Optional
Specify the unit for data flows | giga-byte | kilo-byte |
The defaults are as follows:
or packets to be sent to a mega-byte } | packet
RADIUS server { giga-packet | kilo-packet | byte for data flows, and
mega-packet | one-packet } }* one-packet for data packets.
Set the In RADIUS Use either command

nas-ip ip-address
source IP scheme view
address of the By default, the outbound port
device to quit serves as the source IP
In system address to send RADIUS
send RADIUS view
packets radius nas-ip ip-address packets
1-27

z Some earlier RADIUS servers cannot recognize usernames that contain an ISP domain name. In
this case, the device must remove the domain name before sending a username including a
domain name. You can configure the user-name-format without-domain command on the
device for this purpose.
z If a RADIUS scheme defines that the username is sent without the ISP domain name, do not
apply the RADIUS scheme to more than one ISP domain, thus avoiding the confused situation
where the RADIUS server regards two users in different ISP domains but with the same userid as
one.
z The unit of data flows sent to the RADIUS server must be consistent with the traffic statistics unit
of the RADIUS server. Otherwise, accounting cannot be performed correctly.
z The nas-ip command in RADIUS scheme view is only for the current RADIUS scheme, while the
radius nas-ip command in system view is for all RADIUS schemes. However, the nas-ip
command in RADIUS scheme view takes precedence over the radius nas-ip command.
Setting Timers Regarding RADIUS Servers
When communicating with the RADIUS server, a device can enable the following three timers:
z RADIUS server response timeout (response-timeout): If a NAS receives no response from the
RADIUS server in a period of time after sending a RADIUS request (authentication/authorization
or accounting request), it has to resend the request so that the user has more opportunity to
obtain the RADIUS service. The NAS uses the RADIUS server response timeout timer to control
the transmission interval.
z Primary server quiet timer (timer quiet): If the primary server is not reachable, its state changes to
blocked, and the device will turn to the specified secondary server. If the secondary server is
reachable, the device starts this timer and communicates with the secondary server. After this
timer expires, the device turns the state of the primary server to active and tries to communicate
with the primary server while keeping the state of the secondary server unchanged. If the primary
server has come back into operation, the device interacts with the primary server and terminates
its communication with the secondary server.
z Real-time accounting interval (realtime-accounting): This timer defines the interval for
performing real-time accounting of users. After this timer is set, the switch will send accounting
information of online users to the RADIUS server at the specified interval.
Follow these steps to set timers regarding RADIUS servers:


Set the RADIUS server timer response-timeout Optional

response timeout timer seconds 3 seconds by default
Set the quiet timer for the Optional

timer quiet minutes
primary server 5 minutes by default
1-28

Set the real-time accounting timer realtime-accounting Optional

interval minutes 12 minutes by default
z The maximum number of retransmission attempts of RADIUS packets multiplied by the RADIUS
server response timeout period cannot be greater than 75. This product is also the upper limit of
the timeout time of different access modules.
z For an access module, the maximum number of retransmission attempts multiplied by the
RADIUS server response timeout period must be smaller than the timeout time. Otherwise,
stop-accounting messages cannot be buffered, and the primary/secondary server switchover
cannot take place. For example, as the timeout time of voice access is 10 seconds, the product of
the two parameters cannot exceed 10 seconds; as the timeout time of Telnet access is 30
seconds, the product of the two parameters cannot exceed 30 seconds. For detailed information
about timeout time of a specific access module, refer to the corresponding part in the Access
Volume.
z To configure the maximum number of retransmission attempts of RADIUS packets, refer to the
command retry in the command manual.
Specifying a Security Policy Server
The core of the EAD solution is integration and cooperation, and the security policy server system is
the management and control center. As a collection of software, the security policy server system can
run on Windows and Linux to provide functions such as user management, security policy
management, security status assessment, security cooperation control, and security event audit.
This task allows you to configure the IP address of a security policy server. If the security policy server
and the RADIUS server reside on the same host, you can omit this task. When the device receives a
control packet from the security policy server, it checks whether the source IP address of the packet is
the IP address of the security policy server or RADIUS server. If not, the device considers the packet
invalid.
Follow these steps to specify a security policy server:

Create a RADIUS Required

radius scheme
scheme and enter its By default, no RADIUS scheme is
radius-scheme-name
view present.
Specify a security policy security-policy-server Optional

server ip-address Not specified by default
1-29

You can specify up to eight security policy servers for a RADIUS scheme.
Enabling the Listening Port of the RADIUS Client
Follow these steps to enable the listening port of the RADIUS client:

Enable the listening port of the RADIUS Optional

radius client enable
client Enabled by default
Displaying and Maintaining RADIUS

Display the configuration
display radius scheme
information of a specified Available in any
[ radius-scheme-name ] [ slot
RADIUS scheme or all RADIUS view
slot-number ]
schemes
Display statistics about RADIUS display radius statistics [ slot Available in any
packets slot-number ] view
display stop-accounting-buffer
Display information about { radius-scheme radius-server-name |
Available in any
buffered stop-accounting session-id session-id | time-range
view
requests that get no responses start-time stop-time | user-name
user-name } [ slot slot-number ]
reset radius statistics [ slot Available in user
Clear RADIUS statistics
slot-number ] view
reset stop-accounting-buffer
{ radius-scheme radius-server-name |
Clear buffered stop-accounting Available in user
session-id session-id | time-range
requests that get no responses view
start-time stop-time | user-name
user-name } [ slot slot-number ]
Configuring HWTACACS
Different from RADIUS, except for deleting HWTACACS schemes and changing the IP addresses of
the HWTACACS servers, you can make any changes to HWTACACS parameters, whether there are
users online or not.
1-30

Creating a HWTACACS scheme
The HWTACACS protocol is configured on a per scheme basis. Before performing other HWTACACS
configurations, follow these steps to create a HWTACACS scheme and enter HWTACACS scheme
view:

Create a HWTACACS scheme and hwtacacs scheme Required

enter HWTACACS scheme view hwtacacs-scheme-name Not defined by default
z Up to 16 HWTACACS schemes can be configured.

z A scheme can be deleted only when it is not referenced.
Specifying the HWTACACS Authentication Servers
Follow these steps to specify the HWTACACS authentication servers:

Create a HWTACACS scheme Required

hwtacacs scheme
and enter HWTACACS
hwtacacs-scheme-name Not defined by default
scheme view
Specify the primary
primary authentication Required
HWTACACS authentication
ip-address [ port-number ] Configure at least one of the
server
commands
Specify the secondary
secondary authentication No authentication server by
HWTACACS authentication
server
z It is recommended to specify only the primary HWTACACS authentication server if backup is not
required.
z If both the primary and secondary authentication servers are specified, the secondary one is used
z The IP addresses of the primary and secondary authentication servers cannot be the same.
z You can remove an authentication server only when no active TCP connection for sending
authentication packets is using it.
1-31

Specifying the HWTACACS Authorization Servers
Follow these steps to specify the HWTACACS authorization servers:


hwtacacs scheme
and enter HWTACACS
scheme view
Specify the primary
primary authorization Required
HWTACACS authorization
ip-address [ port-number ] Configure at least one of the
server
commands
Specify the secondary
secondary authorization No authorization server by
HWTACACS authorization
server
z It is recommended to specify only the primary HWTACACS authorization server if backup is not
required.
z If both the primary and secondary authorization servers are specified, the secondary one is used
z The IP addresses of the primary and secondary authorization servers cannot be the same.
z You can remove an authorization server only when no active TCP connection for sending
authorization packets is using it.
Specifying the HWTACACS Accounting Servers
Follow these steps to specify the HWTACACS accounting servers and perform related configurations:


hwtacacs scheme
and enter HWTACACS
scheme view
Specify the primary primary accounting Required
HWTACACS accounting server ip-address [ port-number ] Configure at least one of the
commands
Specify the secondary secondary accounting
No accounting server by
HWTACACS accounting server ip-address [ port-number ]
default
Enable the device to buffer Optional
stop-accounting-buffer
stop-accounting requests
enable Enabled by default
getting no responses
retry stop-accounting
stop-accounting request
1-32

z It is recommended to specify only the primary HWTACACS accounting server if backup is not
required.
z If both the primary and secondary accounting servers are specified, the secondary one is used
z The IP addresses of the primary and secondary accounting servers cannot be the same.
z You can remove an accounting server only when no active TCP connection for sending
accounting packets is using it.
z Currently, HWTACACS does not support keeping accounts on FTP users.
Setting the Shared Key for HWTACACS Packets
When using a HWTACACS server as an AAA server, you can set a key to secure the communications
between the device and the HWTACACS server.
The HWTACACS client and HWTACACS server use the MD5 algorithm to encrypt packets exchanged
between them and a shared key to verify the packets. Only when the same key is used can they
properly receive the packets and make responses.
Follow these steps to set the shared key for HWTACACS packets:


hwtacacs scheme
and enter HWTACACS
scheme view
Set the shared keys for Required
key { accounting |
HWTACACS authentication,
authentication | No shared key exists by
authorization, and accounting
authorization } string default.
packets
Configuring Attributes Related to the Data Sent to HWTACACS Server
Follow these steps to configure the attributes related to the data sent to the HWTACACS server:


hwtacacs scheme
and enter HWTACACS scheme
view
user-name-format Optional
Specify the format of the
{ keep-original | By default, the ISP domain
username to be sent to a
with-domain | name is included in the
HWTACACS server
without-domain } username.
1-33

data-flow-format { data
Optional
{ byte | giga-byte | kilo-byte
Specify the unit for data flows or The defaults are as follows:
| mega-byte } | packet
packets to be sent to a
{ giga-packet | kilo-packet | byte for data flows, and
HWTACACS server
mega-packet |
one-packet for data packets.
one-packet } }*
Set the source In HWTACACS Use either command
nas-ip ip-address
IP address of scheme view
the device to By default, the outbound port
send quit serves as the source IP
HWTACACS In system view address to send HWTACACS
packets hwtacacs nas-ip ip-address packets.
z If a HWTACACS server does not support a username with the domain name, you can configure
the device to remove the domain name before sending the username to the server.
z The nas-ip command in HWTACACS scheme view is only for the current HWTACACS scheme,
while the hwtacacs nas-ip command in system view is for all HWTACACS schemes. However,
the nas-ip command in HWTACACS scheme view overwrites the configuration of the hwtacacs
nas-ip command.
Setting Timers Regarding HWTACACS Servers
Follow these steps to set timers regarding HWTACACS servers:

hwtacacs scheme
and enter HWTACACS
scheme view
Set the HWTACACS server timer response-timeout Optional

response timeout timer seconds 5 seconds by default
Set the quiet timer for the Optional

timer quiet minutes
primary server 5 minutes by default
Set the real-time accounting timer realtime-accounting Optional

interval minutes 12 minutes by default
1-34

z For real-time accounting, a NAS must transmit the accounting information of online users to the
HWTACACS accounting server periodically. Note that if the device does not receive any response
to the information, it does not disconnect the online users forcibly
z The real-time accounting interval must be a multiple of 3.
z The setting of the real-time accounting interval somewhat depends on the performance of the
NAS and the HWTACACS server: a shorter interval requires higher performance.
Displaying and Maintaining HWTACACS

Display configuration information display hwtacacs
or statistics of the specified or all [ hwtacacs-server-name Available in any view
HWTACACS schemes [ statistics ] ] [ slot slot-number ]
display stop-accounting-buffer
hwtacacs-scheme
buffered stop-accounting Available in any view
hwtacacs-scheme-name [ slot
requests that get no responses
slot-number ]
reset hwtacacs statistics
{ accounting | all | authentication
Clear HWTACACS statistics Available in user view
| authorization } [ slot
slot-number ]
reset stop-accounting-buffer
Clear buffered stop-accounting hwtacacs-scheme
requests that get no responses hwtacacs-scheme-name [ slot
slot-number ]
AAA Configuration Examples

AAA for Telnet Users by a HWTACACS Server
As shown in Figure 1-7, configure the switch to use the HWTACACS server to provide authentication,
authorization, and accounting services to login users.
z The HWTACACS server is used for authentication, authentication, and accounting. Its IP address
is 10.1.1.1.
z On the switch, set the shared keys for authentication, authorization, and accounting packets to
expert. Configure the switch to remove the domain name from a user name before sending the
user name to the HWTACACS server.
z On the HWTACACS server, set the shared keys for packets exchanged with the switch to expert.
1-35

Figure 1-7 Configure AAA for Telnet users by a HWTACACS server
Authentication/Accounting server
10.1.1.1/24
Internet
Telnet user Switch
# Configure the IP addresses of the interfaces (omitted).

# Enable the Telnet server on the switch.
[Switch] telnet server enable
# Configure the switch to use AAA for Telnet users.

[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme
[Switch-ui-vty0-4] quit
# Configure the HWTACACS scheme.

[Switch] hwtacacs scheme hwtac
[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.1 49
[Switch-hwtacacs-hwtac] primary accounting 10.1.1.1 49
[Switch-hwtacacs-hwtac] key authentication expert
[Switch-hwtacacs-hwtac] key authorization expert
[Switch-hwtacacs-hwtac] key accounting expert
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Configure the AAA methods for the domain.

[Switch] domain bbb
[Switch-isp-bbb] authentication login hwtacacs-scheme hwtac
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login hwtacacs-scheme hwtac
[Switch-isp-bbb] quit
# You can achieve the same result by setting default AAA methods for all types of users.
[Switch] domain bbb
[Switch-isp-bbb] authentication default hwtacacs-scheme hwtac
[Switch-isp-bbb] authorization default hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting default hwtacacs-scheme hwtac
When telneting into the switch, a user enters username userid@bbb for authentication using domain
bbb.
1-36

AAA for Telnet Users by Separate Servers
As shown in Figure 1-8, configure the switch to provide local authentication, HWTACACS authorization,
and RADIUS accounting services to Telnet users. The user name and the password for Telnet users
are both hello.
z The HWTACACS server is used for authorization. Its IP address is 10.1.1.2. On the switch, set the
shared keys for packets exchanged with the HWTACACS server to expert. Configure the switch
to remove the domain name from a user name before sending the user name to the HWTACACS
server.
z The RADIUS server is used for accounting. Its IP address is 10.1.1.1. On the switch, set the
shared keys for packets exchanged with the RADIUS server to expert.
Configuration of separate AAA for other types of users is similar to that given in this example. The only
difference lies in the access type.
Figure 1-8 Configure AAA by separate servers for Telnet users
# Configure the IP addresses of various interfaces (omitted).

# Enable the Telnet server on the switch.
[Switch] telnet server enable
# Configure the switch to use AAA for Telnet users.

# Configure the HWTACACS scheme.

[Switch] hwtacacs scheme hwtac
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.2 49
[Switch-hwtacacs-hwtac] key authorization expert
1-37

[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Configure the RADIUS scheme.

[Switch] radius scheme rd
[Switch-radius-rd] primary accounting 10.1.1.1 1813
[Switch-radius-rd] key accounting expert
[Switch-radius-rd] server-type extended
[Switch-radius-rd] user-name-format without-domain
[Switch-radius-rd] quit
# Create a local user named hello.

[Switch] local-user hello
[Switch-luser-hello] service-type telnet
[Switch-luser-hello] password simple hello
[Switch-luser-hello] quit
# Configure the AAA methods for the ISP domain.

[Switch] domain bbb
[Switch-isp-bbb] authentication login local
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login radius-scheme rd
# Configure the default AAA methods for all types of users.

[Switch] domain bbb
[Switch-isp-bbb] authentication default local
[Switch-isp-bbb] authorization default hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting default radius-scheme imc
When telneting into the switch, a user enters username telnet@bbb for authentication using domain
bbb.
AAA for SSH Users by a RADIUS Server
As shown in Figure 1-9, configure the switch to use the RADIUS server to provide authentication,
authorization, and accounting services to SSH users.
z Configure an iMC server to act as the RADIUS server to provide authentication, authorization, and
accounting services for SSH users. The IP address of the RADIUS server is 10.1.1.1/24.
z Set both the shared keys for authentication and accounting packets exchanged with the RADIUS
server to expert; and specify that a username sent to the RADIUS server carries the domain
name. The RADIUS server provides different user services according to the domain names.
1-38

Figure 1-9 Configure AAA for SSH users by a RADIUS server
RADIUS server
10.1.1.1/24
Vlan-int2
192.168.1.70/24
Internet
SSH user Switch
1) Configure the RADIUS server. (iMC)
This example assumes that the RADIUS server runs iMC PLAT 3.20-R2602 or iMC UAM 3.60-E6102.
# Add an access device.

Log into the iMC management platform, select the Service tab, and select Access Service > Access
Device from the navigation tree to enter the Access Device page. Then, click Add to enter the Add
Access Device window and perform the following configurations:
z Set both the shared keys for authentication and accounting packets to expert
z Specify the ports for authentication and accounting as 1812 and 1813 respectively
z Select Device Management Service as the service type
z Select 3Com as the access device type
z Select the access device from the device list or manually add the device with the IP address of
10.1.1.2
z Click OK to finish the operation
1-39

Figure 1-10 Add an access device
# Add a user for device management

Log into the iMC management platform, select the User tab, and select Access User View > Device
Mgmt User from the navigation tree to enter the Device Management User page. Then, click Add to
enter the Add Device Management User window and perform the following configurations:
z Add a user named hello@bbb and specify the password
z Select SSH as the service type
z Specify the IP address range of the hosts to be managed as 192.168.1.0 to 192.168.1.255, and
click Add to finish the operation
1-40

Figure 1-11 Add an account for device management
2) Configure the switch

# Configure the IP address of VLAN interface 2, through which the SSH user accesses the switch.
# Configure the IP address of VLAN-interface 3, through which the switch access the server.
# Generate RSA and DSA key pairs and enable the SSH server.
[Switch] public-key local create rsa
[Switch] public-key local create dsa
[Switch] ssh server enable
# Configure the switch to use AAA for SSH users.

# Configure the user interfaces to support SSH.

[Switch-ui-vty0-4] protocol inbound ssh
1-41


[Switch] radius scheme rad
[Switch-radius-rad] primary authentication 10.1.1.1 1812
[Switch-radius-rad] primary accounting 10.1.1.1 1813
[Switch-radius-rad] key authentication expert
[Switch-radius-rad] key accounting expert
[Switch-radius-rad] user-name-format with-domain
[Switch-radius-rad] quit
# Configure the AAA methods for the domain.

[Switch] domain bbb
[Switch-isp-bbb] authentication login radius-scheme rad
[Switch-isp-bbb] authorization login radius-scheme rad
[Switch-isp-bbb] accounting login radius-scheme rad
When using SSH to log in, a user enters a username in the form userid@bbb for authentication using
domain bbb.
After the above configuration, the SSH user should be able to use the configured account to access
the user interface of the switch. The commands that the user can access depend on the settings for
EXEC users on the iMC server.
Troubleshooting AAA
Troubleshooting RADIUS
Symptom 1: User authentication/authorization always fails.

Analysis:
1) A communication failure exists between the NAS and the RADIUS server.
2) The username is not in the format of userid@isp-name or no default ISP domain is specified for
the NAS.
3) The user is not configured on the RADIUS server.
4) The password of the user is incorrect.
5) The RADIUS server and the NAS are configured with different shared key.
Solution:
Check that:
6) The NAS and the RADIUS server can ping each other.
7) The username is in the userid@isp-name format and a default ISP domain is specified on the
NAS.
8) The user is configured on the RADIUS server.
9) The correct password is entered.
10) The same shared key is configured on both the RADIUS server and the NAS.
Symptom 2: RADIUS packets cannot reach the RADIUS server.
Analysis:
1-42

11) The communication link between the NAS and the RADIUS server is down (at the physical layer
and data link layer).
12) The NAS is not configured with the IP address of the RADIUS server.
13) The UDP ports for authentication/authorization and accounting are not correct.
14) The port numbers of the RADIUS server for authentication, authorization and accounting are
being used by other applications.
Solution:
Check that:
15) The communication links between the NAS and the RADIUS server work well at both physical and
link layers.
16) The IP address of the RADIUS server is correctly configured on the NAS.
17) UDP ports for authentication/authorization/accounting configured on the NAS are the same as
those configured on the RADIUS server.
18) The port numbers of the RADIUS server for authentication, authorization and accounting are
available.
Symptom 3: A user is authenticated and authorized, but accounting for the user is not normal.
Analysis:
19) The accounting port number is not correct.
20) Configuration of the authentication/authorization server and the accounting server are not correct
on the NAS. For example, one server is configured on the NAS to provide all the services of
authentication/authorization and accounting, but in fact the services are provided by different
servers.
Solution:
Check that:
21) The accounting port number is correctly set.
22) The authentication/authorization server and the accounting server are correctly configured on the
NAS.
Troubleshooting HWTACACS
Refer to Troubleshooting RADIUS if you encounter a HWTACACS fault.
1-43

2 802.1X Configuration
When configuring 802.1X, go to these sections for information you are interested in:
z 802.1X Overview
z Configuring 802.1X
z Configuring an 802.1X Port-based Guest VLAN
z 802.1X Configuration Example
z Guest VLAN and VLAN Assignment Configuration Example
z ACL Assignment Configuration Example
802.1X Overview
The 802.1X protocol was proposed by IEEE802 LAN/WAN committee for security of wireless LANs
(WLAN). It has been widely used on Ethernet as a common port access control mechanism.
As a port-based access control protocol, 802.1X authenticates and controls accessing devices at the
port level. A device connected to an 802.1X-enabled port of an access control device can access the
resources on the LAN only after passing authentication.
The port security feature provides rich security modes that combine or extend 802.1X and MAC
address authentication. In a networking environment that requires flexible use of 802.1X and MAC
address authentication, you are recommended to configure the port security feature. In a network
environment that requires only 802.1X authentication, you are recommended to configure the 802.1X
directly rather than configure the port security feature for simplicity sake. For how to use the port
security feature, refer to Port Security Configuration in the Security Volume.
To get more information about 802.1X, go to these topics:

z Architecture of 802.1X
z Basic Concepts of 802.1X
z EAP over LANs
z EAP over RADIUS
z 802.1X Authentication Triggering
z Authentication Process of 802.1X
z 802.1X Timers
z Features Working Together with 802.1X
Architecture of 802.1X
802.1X operates in the typical client/server model and defines three entities: client, device, and server,
as shown in Figure 2-1.
2-1

Figure 2-1 Architecture of 802.1X
z Client: An entity to be authenticated by the device residing on the same LAN. A client is usually a
user-end device and initiates 802.1X authentication through 802.1X client software supporting the
EAP over LANs (EAPOL) protocol.
z Device: The entity that authenticates connected clients residing on the same LAN. A device is
usually an 802.1X-enabled network device and provides ports (physical or logical) for clients to
access the LAN.
z Server: The entity providing authentication, authorization, and accounting services for the device.
The server usually runs the Remote Authentication Dial-in User Service (RADIUS).
Authentication Modes of 802.1X
The 802.1X authentication system employs the Extensible Authentication Protocol (EAP) to exchange
authentication information between the client, device, and authentication server.
z Between the client and the device, EAP protocol packets are encapsulated using EAPOL to be
transferred on the LAN.
z Between the device and the RADIUS server, EAP protocol packets can be handled in two modes:
EAP relay and EAP termination. In EAP relay mode, EAP protocol packets are encapsulated by
using the EAP over RADIUS (EAPOR) and then relayed to the RADIUS server. In EAP
termination mode, EAP protocol packets are terminated at the device, repackaged in the
Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP)
attributes of RADIUS packets, and then transferred to the RADIUS server.
Basic Concepts of 802.1X
These basic concepts are involved in 802.1X: controlled port/uncontrolled port, authorized
state/unauthorized state, and control direction.
Controlled port and uncontrolled port
A device provides ports for clients to access the LAN. Each port can be regarded as a unity of two
logical ports: a controlled port and an uncontrolled port.
z The uncontrolled port is always open in both the inbound and outbound directions to allow EAPOL
protocol frames to pass, guaranteeing that the client can always send and receive authentication
frames.
z The controlled port is open to allow data traffic to pass only when it is in the authorized state.
z The controlled port and uncontrolled port are two parts of the same port. Any frames arriving at the
port are visible to both of them.
Authorized state and unauthorized state
The device uses the authentication server to authenticate a client trying to access the LAN and
controls the status of the controlled port depending on the authentication result, putting the controlled
port in the authorized state or unauthorized state, as shown in Figure 2-2.
2-2

Figure 2-2 Authorized/unauthorized status of a controlled port
You can set the access control mode of a specified port to control the authorization status. The access
control modes include:
z authorized-force: Places the port in the authorized state, allowing users of the ports to access
the network without authentication.
z unauthorized-force: Places the port in the unauthorized state, denying any access requests from
users of the ports.
z auto: Places the port in the unauthorized state initially to allow only EAPOL frames to pass, and
turns the ports into the authorized state to allow access to the network after the users pass
authentication. This is the most common choice.
Control direction
In the unauthorized state, the controlled port can be set to deny traffic to and from the client or just the
traffic from the client.
Currently, your device can only be set to deny traffic from the client.
EAP over LANs
EAPOL frame format
EAPOL, defined in 802.1X, is intended to carry EAP protocol packets between clients and devices over
LANs. Figure 2-3 shows the EAPOL frame format.
2-3

Figure 2-3 EAPOL frame format
z PAE Ethernet type: Protocol type. It takes the value 0x888E.

z Protocol version: Version of the EAPOL protocol supported by the EAPOL frame sender.
z Type: Type of the EAPOL frame. Table 2-1 lists the types that the device currently supports.
Table 2-1 Types of EAPOL frames
Type Description
Frame for carrying authentication information, present between
a device and the authentication server.
EAP-Packet (a value of 0x00) A frame of this type is repackaged and transferred by RADIUS
to get through complex networks to reach the authentication
server.
Frame for initiating authentication, present between a client
EAPOL-Start (a value of 0x01)
and a device.
Frame for logoff request, present between a client and a
EAPOL-Logoff (a value of 0x02)
device.
z Length: Length of the data, that is, length of the Packet body field, in bytes. If the value of this field
is 0, no subsequent data field is present.
z Packet body: Content of the packet. The format of this field varies with the value of the Type field.
EAP Packet Format
An EAPOL frame of the type of EAP-Packet carries an EAP packet in its Packet body field. The format
of the EAP packet is shown in Figure 2-4.
Figure 2-4 EAP packet format
z Code: Type of the EAP packet, which can be Request, Response, Success, or Failure.
An EAP packet of the type of Success or Failure has no Data field, and has a length of 4.
An EAP packet of the type of Request or Response has a Data field in the format shown in Figure 2-5.
The Type field indicates the EAP authentication type. A value of 1 represents Identity, indicating that
2-4

the packet is for querying the identity of the client. A value of 4 represents MD5-Challenge, which
corresponds closely to the PPP CHAP protocol.
Figure 2-5 Format of the Data field in an EAP request/response packet
z Identifier: Allows matching of responses with requests.

z Length: Length of the EAP packet, including the Code, Identifier, Length, and Data fields, in bytes.
z Data: Content of the EAP packet. This field is zero or more bytes and its format is determined by
the Code field.
EAP over RADIUS
Two attributes of RADIUS are intended for supporting EAP authentication: EAP-Message and
Message-Authenticator. For information about RADIUS packet format, refer to AAA Configuration in
the Security Volume.
EAP-Message
The EAP-Message attribute is used to encapsulate EAP packets. Figure 2-6 shows its encapsulation
format. The value of the Type field is 79. The String field can be up to 253 bytes. If the EAP packet is
longer than 253 bytes, it can be fragmented and encapsulated into multiple EAP-Message attributes.
Figure 2-6 Encapsulation format of the EAP-Message attribute
Message-Authenticator
Figure 2-7 shows the encapsulation format of the Message-Authenticator attribute. The
Message-Authenticator attribute is used to prevent access requests from being snooped during EAP
authentication. It must be included in any packet with the EAP-Message attribute; otherwise, the
packet will be considered invalid and get discarded.
Figure 2-7 Encapsulation format of the Message-Authenticator attribute
802.1X Authentication Triggering
802.1X authentication can be initiated by either a client or the device.
2-5

Unsolicited triggering of a client
A client initiates authentication by sending an EAPOL-Start frame to the device. The destination
address of the frame is 01-80-C2-00-00-03, the multicast address specified by the IEEE 802.1X
protocol.
Some devices in the network may not support multicast packets with the above destination address,
causing the authentication device unable to receive the authentication request of the client. To solve
the problem, the device also supports EAPOL-Start frames whose destination address is a broadcast
MAC address. In this case, the iNode 802.1X client is required.
Unsolicited triggering of the device
The device can trigger authentication by sending EAP-Request/Identity packets to unauthenticated

clients periodically (every 30 seconds by default). This method can be used to authenticate clients
which cannot send EAPOL-Start frames and therefore cannot trigger authentication, for example, the
802.1X client provided by Windows XP.
Authentication Process of 802.1X
An 802.1X device communicates with a remotely located RADIUS server in two modes: EAP relay and
EAP termination. The following description takes the EAP relay as an example to show the 802.1X
authentication process.
EAP relay
EAP relay is an IEEE 802.1X standard mode. In this mode, EAP packets are carried in an upper layer
protocol, such as RADIUS, so that they can go through complex networks and reach the authentication
server. Generally, EAP relay requires that the RADIUS server support the EAP attributes of
EAP-Message and Message-Authenticator, which are used to encapsulate EAP packets and protect
RADIUS packets carrying the EAP-Message attribute respectively.
Figure 2-8 shows the message exchange procedure with EAP-MD5.
2-6

Figure 2-8 Message exchange in EAP relay mode
Client Device Server
EAPOL EAPOR
EAPOL-Start
EAP-Request / Identity
EAP-Response / Identity RADIUS Access-Request

(EAP-Response / Identity)
RADIUS Access-Challenge
(EAP-Request / MD5 challenge)
EAP-Request / MD5 challenge
EAP-Response / MD5 challenge RADIUS Access-Request

(EAP-Response / MD5 challenge)
RADIUS Access-Accept
(EAP-Success)
EAP-Success
Port authorized
Handshake timer
Handshake request
[ EAP-Request / Identity ]
Handshake response
[ EAP-Response / Identity ]
......
EAPOL-Logoff
Port unauthorized
2) When a user launches the 802.1X client software and enters the registered username and
password, the 802.1X client software generates an EAPOL-Start frame and sends it to the device
to initiate an authentication process.
3) Upon receiving the EAPOL-Start frame, the device responds with an EAP-Request/Identity packet
for the username of the client.
4) When the client receives the EAP-Request/Identity packet, it encapsulates the username in an
EAP-Response/Identity packet and sends the packet to the device.
5) Upon receiving the EAP-Response/Identity packet, the device relays the packet in a RADIUS
Access-Request packet to the authentication server.
6) When receiving the RADIUS Access-Request packet, the RADIUS server compares the identify
information against its user information table to obtain the corresponding password information.
Then, it encrypts the password information using a randomly generated challenge, and sends the
challenge information through a RADIUS Access-Challenge packet to the device.
7) After receiving the RADIUS Access-Challenge packet, the device relays the contained
EAP-Request/MD5 Challenge packet to the client.
8) When receiving the EAP-Request/MD5 Challenge packet, the client uses the offered challenge to
encrypt the password part (this process is not reversible), creates an EAP-Response/MD5
Challenge packet, and then sends the packet to the device.
9) After receiving the EAP-Response/MD5 Challenge packet, the device relays the packet in a
RADIUS Access-Request packet to the authentication server.
2-7

10) When receiving the RADIUS Access-Request packet, the RADIUS server compares the password
information encapsulated in the packet with that generated by itself. If the two are identical, the
authentication server considers the user valid and sends to the device a RADIUS Access-Accept
packet.
11) Upon receiving the RADIUS Access-Accept packet, the device opens the port to grant the access
request of the client. After the client gets online, the device periodically sends handshake requests
to the client to check whether the client is still online. By default, if two consecutive handshake
attempts end up with failure, the device concludes that the client has gone offline and performs the
necessary operations, guaranteeing that the device always knows when a client goes offline.
12) The client can also send an EAPOL-Logoff frame to the device to go offline unsolicitedly. In this
case, the device changes the status of the port from authorized to unauthorized and sends an
EAP-Failure frame to the client.
In EAP relay mode, a client must use the same authentication method as that of the RADIUS server.
On the device, however, you only need to execute the dot1x authentication-method eap command
to enable EAP relay.
EAP termination
In EAP termination mode, EAP packets are terminated at the device and then repackaged into the PAP
or CHAP attributes of RADIUS and transferred to the RADIUS server for authentication, authorization,
and accounting. Figure 2-9 shows the message exchange procedure with CHAP authentication.
2-8

Figure 2-9 Message exchange in EAP termination mode
Client Device Server
EAPOL EAPOR
EAPOL-Start
EAP-Request / Identity
EAP-Response / Identity
EAP-Request / MD5 challenge
EAP-Response / MD5 challenge

RADIUS Access-Request
(CHAP-Response / MD5 challenge)
RADIUS Access-Accept
(CHAP-Success)
EAP-Success
Port authorized
Handshake timer
Handshake request
[ EAP-Request / Identity ]
Handshake response
[ EAP-Response / Identity ]
......
EAPOL-Logoff
Port unauthorized
Different from the authentication process in EAP relay mode, it is the device that generates the random
challenge for encrypting the user password information in EAP termination authentication process.
Consequently, the device sends the challenge together with the username and encrypted password
information from the client to the RADIUS server for authentication.
802.1X Timers
This section describes the timers used on an 802.1X device to guarantee that the client, the device,
and the RADIUS server can interact with each other in a reasonable manner.
z Username request timeout timer (tx-period): The device starts this timer when it sends an
EAP-Request/Identity frame to a client. If it receives no response before this timer expires, the
device retransmits the request. When cooperating with a client that sends EAPOL-Start requests
only when requested, the device multicasts EAP-Request/Identity frames to the client at an
interval set by this timer.
z Client timeout timer (supp-timeout): Once a device sends an EAP-Request/MD5 Challenge frame
to a client, it starts this timer. If this timer expires but it receives no response from the client, it
retransmits the request.
z Server timeout timer (server-timeout): Once a device sends a RADIUS Access-Request packet to
the authentication server, it starts this timer. If this timer expires but it receives no response from
the server, it retransmits the request.
2-9

z Handshake timer (handshake-period): After a client passes authentication, the device sends to the
client handshake requests at this interval to check whether the client is online. If the device
receives no response after sending the allowed maximum number of handshake requests, it
considers that the client is offline.
z Quiet timer (quiet-period): When a client fails the authentication, the device refuses further
authentication requests from the client in this period of time.
z Periodic re-authentication timer (reauth-period): If periodic re-authentication is enabled on a port,
the device re-authenticates online users on the port at the interval specified by this timer.
Extensions to 802.1X
The devices extend and optimize the mechanism that the 802.1X protocol specifies by:
z Allowing multiple users to access network services through the same physical port.
z Supporting two authentication methods: portbased and macbased. With the portbased method,
after the first user of a port passes authentication, all other users of the port can access the
network without authentication, and when the first user goes offline, all other users get offline at
the same time. With the macbased method, each user of a port must be authenticated separately,
and when an authenticated user goes offline, no other users are affected.
After an 802.1X client passes authentication, the authentication server sends authorization information
to the device. If the authorization information contains VLAN authorization information, the device adds
the port connecting the client to the assigned VLAN. This neither changes nor affects the
configurations of the port. The only result is that the assigned VLAN takes precedence over the
manually configured one, that is, the assigned VLAN takes effect. After the client goes offline, the
configured one takes effect.
Features Working Together with 802.1X
VLAN assignment
After an 802.1X user passes the authentication, the server will send an authorization message to the
device. If the server is enabled with the VLAN assignment function, the assigned VLAN information will
be included in the message. The device, depending on the link type of the port used to log in, adds the
port to the assigned VLAN according to the following rules:
z If the port link type is Access, the port leaves its initial VLAN, that is, the VLAN configured for it
and joins the assigned VLAN.
z If the port link type is Trunk, the assigned VLAN is allowed to pass the current trunk port. The
default VLAN ID of the port is that of the assigned VLAN.
z If the port link type is Hybrid, the assigned VLAN is allowed to pass the current port without
carrying the tag. The default VLAN ID of the port is that of the assigned VLAN. Note that if the
Hybrid port is assigned a MAC-based VLAN, the device will dynamically create a MAC-based
VLAN according to the VLAN assigned by the authentication server, and remain the default VLAN
ID of the port unchanged.
2-10

The assigned VLAN neither changes nor affects the configuration of a port. However, as the assigned
VLAN has higher priority than the initial VLAN of the port, it is the assigned VLAN that takes effect after
a user passes authentication. After the user goes offline, the port returns to the initial VLAN of the port.
For details about VLAN configuration, refer to VLAN Configuration in the Access Volume.
z With a Hybrid port, the VLAN assignment will fail if you have configured the assigned VLAN to
carry tags.
z With a Hybrid port, you cannot configure an assigned VLAN to carry tags after the VLAN has been
assigned.
Guest VLAN
Guest VLAN allows unauthenticated users and users failing the authentication to access a specified
VLAN, where the users can, for example, download or upgrade the client software, or execute some
user upgrade programs. This VLAN is called the guest VLAN.
Currently, on the S4510G series Ethernet switches, a guest VLAN can be only a port-based guest
VLAN (PGV), which is supported on a port that uses the access control method of portbased.
With PGV configured on a port, if no users are successfully authenticated on the port in a certain
period of time (90 seconds by default), the port will be added to the guest VLAN and all users
accessing the port will be authorized to access the resources in the guest VLAN.
The device adds a PGV-configured port into the guest VLAN according to the ports link type in the
similar way as described in VLAN assignment. When a user of a port in the guest VLAN initiates an
authentication, if the authentication is not successful, the port stays in the guest VLAN; if the
authentication is successful, the port leaves the guest VLAN, and:
z If the authentication server assigns a VLAN, the port joins the assigned VLAN. After the user goes
offline, the port returns to its initial VLAN, that is, the VLAN specified for it during port configuration,
or, in other words, the VLAN it was in before it joined the guest VLAN.
z If the authentication server does not assign any VLAN, the port returns to its initial VLAN. After the
client goes offline, the port just stays in its initial VLAN.
ACL assignment
ACLs provide a way of controlling access to network resources and defining access rights. When a
user logs in through a port, and the RADIUS server is configured with authorization ACLs, the device
will permit or deny data flows traversing through the port according to the authorization ACLs. Before
specifying authorization ACLs on the server, you need to configure the ACL rules on the device. You
can change the access rights of users by modifying authorization ACL settings on the RADIUS server
or changing the corresponding ACL rules on the device.
Online User Handshake Function
The online user handshake function allows the device to send handshake messages to online users to
check whether the users are still online at the interval specified by the dot1x timer handshake-period
command. If the device does not receive any response from an online user after the device has sent
2-11

the handshake packet for the maximum number of times, which is set by the dot1x retry command,
the device will set the user state to offline.
The online user handshake security function helps prevent online users from using illegal client
software to exchange handshake messages with the device. Using illegal client software for
handshake message exchange may result in escape from some security inspection functions, such as
proxy detection and dual network interface card (NIC) detection. With the online handshake security
function enabled, the device checks the authentication information carried in the handshake messages
of a client. If the client fails the authentication, the device forces the user offline.
Mandatory authentication domain for a specified port
The mandatory authentication domain function provides a security control mechanism for 802.1X
access. With a mandatory authentication domain specified for a port, the system uses the mandatory
authentication domain for authentication, authorization, and accounting of all 802.1X users on the port.
In this way, users accessing the port cannot use any account in other domains.
Meanwhile, for EAP relay mode 802.1X authentication that uses certificates, the certificate of a user
determines the authentication domain of the user. However, you can specify different mandatory
authentication domains for different ports even if the user certificates are from the same certificate
authority (that is, the user domain names are the same). This allows you to deploy 802.1X access
policies flexibly.
Configuring 802.1X
802.1X provides a user identity authentication scheme. However, 802.1X cannot implement the
authentication scheme solely by itself. RADIUS or local authentication must be configured to work with
802.1X.
z Configure the ISP domain to which the 802.1X user belongs and the AAA scheme to be used (that
is, local authentication or RADIUS).
z For remote RADIUS authentication, the username and password information must be configured
on the RADIUS server.
z For local authentication, the username and password information must be configured on the
device and the service type must be set to lan-access.
For detailed configuration of the RADIUS client, refer to AAA Configuration in the Security Volume.
Configuring 802.1X Globally
Follow these steps to configure 802.1X globally:

Required
Enable 802.1X globally dot1x
Disabled by default
dot1x authentication-method Optional

Set the authentication method
{ chap | eap | pap } CHAP by default
2-12

Set the port
dot1x port-control
access control Optional
{ authorized-force | auto |
mode for
unauthorized-force } auto by default
specified or all
[ interface interface-list ]
ports
Set the port
access control dot1x port-method Optional
Set the port
method for { macbased | portbased }
access control macbased by default
specified or all [ interface interface-list ]
parameters
ports
Set the
maximum
number of dot1x max-user user-number Optional
users for [ interface interface-list ] 256 by default
specified or all
ports
Set the maximum number of
attempts to send an Optional
dot1x retry max-retry-value
authentication request to a 2 by default
client
Optional
dot1x timer The defaults are as follows:
{ handshake-period 15 seconds for the handshake
handshake-period-value | timer,
quiet-period
60 seconds for the quiet timer,
quiet-period-value |
3600 seconds for the periodic
reauth-period
Set timers re-authentication timer,
reauth-period-value |
server-timeout 100 seconds for the server
server-timeout-value | timeout timer,
supp-timeout 30 seconds for the client
supp-timeout-value | tx-period timeout timer, and
tx-period-value }
30 seconds for the username
request timeout timer.
Optional
Enable the quiet timer dot1x quiet-period
Disabled by default
Note that:
z For 802.1X to take effect on a port, you must enable it both globally in system view and for the port
in system view or Ethernet interface view.
z You can also enable 802.1X and set port access control parameters (that is, the port access
control mode, port access method, and the maximum number of users) for a port in Ethernet
interface view. For detailed configuration, refer to Configuring 802.1X for a Port. The only
difference between configuring 802.1X globally and configuring 802.1X for a port lies in the
applicable scope. If both a global setting and a local setting exist for an argument of a port, the last
configured one is in effect.
z 802.1X timers only need to be changed in special or extreme network environments. For example,
you can give the client timeout timer a higher value in a low-performance network, give the quiet
timer a higher value in a vulnerable network or a lower value for quicker authentication response,
or adjust the server timeout timer to suit the performance of the authentication server.
2-13

Configuring 802.1X for a Port
Enabling 802.1X for a port
Follow these steps to enable 802.1X for a port:

In system view dot1x interface interface-list
Enable Required
802.1X for interface interface-type
In Ethernet Use either approach.
one or more interface-number
ports interface view Disabled by default
dot1x
Configuring 802.1X parameters for a port
Follow these steps to configure 802.1X parameters for a port:

interface-number
dot1x port-control Optional
Set the port access control
{ authorized-force | auto |
mode for the port auto by default
unauthorized-force }
Set the port access control dot1x port-method Optional

method for the port { macbased | portbased } macbased by default

dot1x max-user user-number
users for the port 256 by default
Optional
Enable online user handshake dot1x handshake
Enabled by default
Enable the online handshake Optional

dot1x handshake secure
security function Disabled by default
Optional
Enable multicast trigger dot1x multicast-trigger
Enabled by default
Enable periodic Required

dot1x re-authenticate
re-authentication Disabled by default
Specify the mandatory Optional

dot1x mandatory-domain
authentication domain for the No mandatory authentication
domain-name
port domain is specified by default.
Note that:
z Enabling 802.1X on a port is mutually exclusive with adding the port to an aggregation group.
z In EAP relay authentication mode, the device encapsulates the 802.1X user information in the
EAP attributes of RADIUS packets and sends the packets to the RADIUS server for authentication.
In this case, you can configure the user-name-format command but it does not take effect. For
2-14

information about the user-name-format command, refer to AAA Commands in the Security
Volume.
z If the username of a client contains the version number or one or more blank spaces, you can
neither retrieve information nor disconnect the client by using the username. However, you can
use items such as IP address and connection index number to do so.
z The online user handshake security function is implemented based on the online user handshake
function. To bring the security function into effect, keep the online user handshake function
enabled.
z The iNode client software and iMC server are recommended to ensure the normal operation of the
online user handshake security function.
z Once enabled with the 802.1X multicast trigger function, a port sends multicast trigger messages
to the client periodically to initiate authentication.
z For a user-side device sending untagged traffic, the voice VLAN function and 802.1X are mutually
exclusive and cannot be configured together on the same port. For details about voice VLAN,
refer to VLAN Configuration in the Access Volume.
Configuring an 802.1X Port-based Guest VLAN

z Enable 802.1X.
z Create the VLAN to be specified as the guest VLAN.
z Set the port access control method to portbased.
z Ensure that the 802.1X multicast trigger function is enabled.
Follow these steps to configure a port-based guest VLAN:

dot1x guest-vlan
In system
guest-vlan-id [ interface Required
Configure the view
interface-list ]
guest VLAN Use either approach.
for specified interface interface-type By default, a port is configured
or all ports In Ethernet interface-number with no guest VLAN.
interface view
dot1x guest-vlan vlan-id
z Different ports can be configured with different guest VLANs, but a port can be configured with
only one guest VLAN.
z You cannot configure both the guest VLAN function and the free IP function in EAD fast
deployment.
2-15

z If the data flows from a user-side device carry VLAN tags, and 802.1X and guest VLAN are
enabled on the access port, you are recommended to configure different VLAN IDs for the voice
VLAN, the default port VLAN, and the guest VLAN of 802.1X.
Displaying and Maintaining 802.1X

Display 802.1X session
display dot1x [ sessions |
information, statistics, or
statistics ] [ interface Available in any view
configuration information of
interface-list ]
specified or all ports
reset dot1x statistics
Clear 802.1X statistics Available in user view
[ interface interface-list ]
802.1X Configuration Example

z The access control method of macbased is required on the port GigabitEthernet 1/0/1 to control
clients.
z All clients belong to default domain aabbcc.net, which can accommodate up to 30 users. RADIUS
authentication is performed at first, and then local authentication when no response from the
RADIUS server is received. If the RADIUS accounting fails, the device gets users offline.
z A server group with two RADIUS servers is connected to the device. The IP addresses of the
servers are 10.1.1.1 and 10.1.1.2 respectively. Use the former as the primary
authentication/secondary accounting server, and the latter as the secondary
authentication/primary accounting server.
z Set the shared key for the device to exchange packets with the authentication server as name,
and that for the device to exchange packets with the accounting server as money.
z Specify the device to try up to five times at an interval of 5 seconds in transmitting a packet to the
RADIUS server until it receives a response from the server, and to send real time accounting
packets to the accounting server every 15 minutes.
z Specify the device to remove the domain name from the username before passing the username
to the RADIUS server.
z Set the username of the 802.1X user as localuser and the password as localpass and specify to
use clear text mode. Enable the idle cut function to get the user offline whenever the user remains
idle for over 20 minutes.
2-16

Figure 2-10 Network diagram for 802.1X configuration
The following configuration procedure covers most AAA/RADIUS configuration commands for the
device, while configuration on the 802.1X client and RADIUS server are omitted. For information about
AAA/RADIUS configuration commands, refer to AAA Configuration in the Security Volume.
# Configure the IP addresses for each interface. (Omitted)

# Add local access user localuser, enable the idle cut function, and set the idle cut interval.
[Device] local-user localuser
[Device-luser-localuser] service-type lan-access
[Device-luser-localuser] password simple localpass
[Device-luser-localuser] attribute idle-cut 20
[Device-luser-localuser] quit
# Create RADIUS scheme radius1 and enter its view.

[Device] radius scheme radius1
# Configure the IP addresses of the primary authentication and accounting RADIUS servers.
[Device-radius-radius1] primary authentication 10.1.1.1
[Device-radius-radius1] primary accounting 10.1.1.2
# Configure the IP addresses of the secondary authentication and accounting RADIUS servers.
[Device-radius-radius1] secondary authentication 10.1.1.2
[Device-radius-radius1] secondary accounting 10.1.1.1
# Specify the shared key for the device to exchange packets with the authentication server.
[Device-radius-radius1] key authentication name
# Specify the shared key for the device to exchange packets with the accounting server.
[Device-radius-radius1] key accounting money
2-17

# Set the interval for the device to retransmit packets to the RADIUS server and the maximum number
of transmission attempts.
[Device-radius-radius1] timer response-timeout 5
[Device-radius-radius1] retry 5
# Set the interval for the device to send real time accounting packets to the RADIUS server.
[Device-radius-radius1] timer realtime-accounting 15
# Specify the device to remove the domain name of any username before passing the username to the
RADIUS server.
[Device-radius-radius1] user-name-format without-domain
[Device-radius-radius1] quit
# Create domain aabbcc.net and enter its view.

[Device] domain aabbcc.net
# Set radius1 as the RADIUS scheme for users of the domain and specify to use local authentication
as the secondary scheme.
[Device-isp-aabbcc.net] authentication default radius-scheme radius1 local
[Device-isp-aabbcc.net] authorization default radius-scheme radius1 local
[Device-isp-aabbcc.net] accounting default radius-scheme radius1 local
# Set the maximum number of users for the domain as 30.

[Device-isp-aabbcc.net] access-limit enable 30
# Enable the idle cut function and set the idle cut interval.
[Device-isp-aabbcc.net] idle-cut enable 20
[Device-isp-aabbcc.net] quit
# Configure aabbcc.net as the default domain.

[Device] domain default enable aabbcc.net
# Enable 802.1X globally.

[Device] dot1x
# Enable 802.1X for port GigabitEthernet 1/0/1.

[Device-GigabitEthernet1/0/1] dot1x
# Set the port access control method. (Optional. The default settings meet the requirement.)
[Device] dot1x port-method macbased interface GigabitEthernet 1/0/1
Guest VLAN and VLAN Assignment Configuration Example


z A host is connected to port GigabitEthernet 1/0/2 of the device and must pass 802.1X
authentication to access the Internet. GigabitEthernet 1/0/2 is in VLAN 1.
z The authentication server runs RADIUS and is in VLAN 2.
z The update server, which is in VLAN 10, is for client software download and upgrade.
z Port GigabitEthernet 1/0/3 of the device, which is in VLAN 5, is for accessing the Internet.
2-18

z On port GigabitEthernet 1/0/2, enable 802.1X and set VLAN 10 as the guest VLAN of the port. If
the device sends an EAP-Request/Identity packet from the port for the maximum number of times
but still receives no response, the device adds the port to its guest VLAN. In this case, the host
and the update server are both in VLAN 10, so that the host can access the update server and
download the 802.1X client.
z After the host passes the authentication and logs in, the host is added to VLAN 5. In this case, the
host and GigabitEthernet 1/0/3 are both in VLAN 5, so that the host can access the Internet.
Figure 2-11 Network diagram for guest VLAN configuration
Update server Authenticator server
VLAN 10 VLAN 2
GE1/0/1 GE1/0/4
VLAN 1 VLAN 5
GE1/0/2 GE1/0/3
Switch
Internet
Supplicant
Figure 2-12 Network diagram with the port in the guest VLAN
2-19

Figure 2-13 Network diagram when the client passes authentication
z The following configuration procedure uses many AAA/RADIUS commands. For detailed
configuration of these commands, refer to AAA Configuration in the Security Volume.
z Configurations on the 802.1X client and RADIUS server are omitted.
# Configure RADIUS scheme 2000.

[Device] radius scheme 2000
[Device-radius-2000] primary authentication 10.11.1.1 1812
[Device-radius-2000] primary accounting 10.11.1.1 1813
[Device-radius-2000] key authentication abc
[Device-radius-2000] key accounting abc
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
# Configure authentication domain system and specify to use RADIUS scheme 2000 for users of the
domain.
[Device] domain system
[Device-isp-system] authentication default radius-scheme 2000
[Device-isp-system] authorization default radius-scheme 2000
[Device-isp-system] accounting default radius-scheme 2000
[Device-isp-system] quit

[Device] dot1x
2-20

# Set the port access control method to portbased.

[Device-GigabitEthernet1/0/2] dot1x port-method portbased
# Set the port access control mode to auto.

[Device-GigabitEthernet1/0/2] dot1x port-control auto
# Create VLAN 10.

[Device] vlan 10
[Device-vlan10] quit
# Specify port GigabitEthernet 1/0/2 to use VLAN 10 as its guest VLAN.

[Device] dot1x guest-vlan 10 interface GigabitEthernet 1/0/2
You can use the display current-configuration or display interface GigabitEthernet 1/0/2
command to view your configuration. You can also use the display vlan 10 command in the following
cases to verify whether the configured guest VLAN functions:
z When no users log in.
z When a user goes offline.
After a user passes the authentication successfully, you can use the display interface
GigabitEthernet 1/0/2 command to verity that port GigabitEthernet 1/0/2 has been added to the
assigned VLAN 5.
ACL Assignment Configuration Example

As shown in Figure 2-14, a host is connected to port GigabitEthernet 1/0/1 of the device and must pass
802.1X authentication to access the Internet.
z Configure the RADIUS server to assign ACL 3000.
z Enable 802.1X authentication on port GigabitEthernet 1/0/1 of the device, and configure ACL
3000.
After the host passes 802.1X authentication, the RADIUS server assigns ACL 3000 to port
GigabitEthernet 1/0/1. As a result, the host can access the Internet but cannot access the FTP server,
whose IP address is 10.0.0.1.
Figure 2-14 Network diagram for ACL assignment
2-21

# Configure the IP addresses of the interfaces. (Omitted)

# Create an ISP domain and specify the AAA schemes.

[Device] domain 2000
[Device-isp-2000] authentication default radius-scheme 2000
[Device-isp-2000] authorization default radius-scheme 2000
[Device-isp-2000] accounting default radius-scheme 2000
[Device-isp-2000] quit
# Configure ACL 3000 to deny packets destined for 10.0.0.1.

[Device-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0

[Device] dot1x

After logging in successfully, a user can use the ping command to verify whether the ACL 3000
assigned by the RADIUS server functions.
C:\>ping 10.0.0.1
Request timed out.

Request timed out.
Request timed out.
Request timed out.

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
C:\>
2-22

3 EAD Fast Deployment Configuration
When configuring EAD fast deployment, go to these sections for information you are interested in:
z EAD Fast Deployment Overview
z Configuring EAD Fast Deployment
z Displaying and Maintaining EAD Fast Deployment
z EAD Fast Deployment Configuration Example
z Troubleshooting EAD Fast Deployment
EAD Fast Deployment Overview

Overview
Endpoint Admission Defense (EAD) is an integrated endpoint access control solution. By allowing the
security clients, access devices, security policy servers, and third-party servers in the network to
collaborate with each other, it can improve the overall defense capability of a network and implement
centralized management of users.
Normally, to use EAD on your network, you need to manually deploy the EAD client on each device,
which tends to be time consuming and inefficient. To address the issue, quick EAD deployment was
developed. In conjunction with 802.1X, it can have an access switch to force all attached devices to
download and install the EAD client before permitting them to access the network.
EAD Fast Deployment Implementation
To support the fast deployment of EAD schemes, 802.1X provides the following two mechanisms:
1) Limit on accessible network resources
Before successful 802.1X authentication, a user can access only a specific IP segment, which may
have one or more servers. Users can download EAD client software or obtain dynamic IP address from
the servers.
2) URL redirection
Before successful 802.1X authentication, a user using a Web browser to access the network is
automatically redirected to a specified URL, for example, the EAD client software download page. The
server that provides the URL redirection must be in the specific network segment that users can
access before passing 802.1X authentication.
3-1

Configuring EAD Fast Deployment
Currently, MAC authentication and port security cannot work together with EAD fast deployment. Once
MAC authentication or port security is enabled globally, the EAD fast deployment is disabled
automatically.
z Enable 802.1X globally.

z Enable 802.1X on the specified port, and set the access control mode to auto.
Configuring a freely accessible network segment
A freely accessible network segment, also called a free IP, is a network segment that users can access
before passing 802.1X authentication.
Once a free IP is configured, the fast deployment of EAD is enabled.
Follow these steps to configure a freely accessible network segment:

Configure a freely Required

dot1x free-ip ip-address
accessible network No freely accessible network segment
{ mask-address | mask-length }
segment is configured by default.
z You cannot configure both the free IP and the 802.1X guest VLAN function.
z If no freely accessible network segment is configured, a user cannot obtain a dynamic IP address
before passing 802.1X authentication. To solve this problem, you can configure a freely
accessible network segment that is on the same network segment with the DHCP server.
3-2

Configuring the IE redirect URL
Follow these steps to configure the IE redirect URL:

Required
Configure the IE redirect URL dot1x url url-string
No redirect URL is configured by default.
The redirect URL and the freely accessible network segment must belong to the same network
segment. Otherwise, the specified URL is unaccessible.
Setting the EAD rule timeout time
With the EAD fast deployment function, a user is authorized by an EAD rule (generally an ACL rule) to
access the freely accessible network segment before passing authentication. After successful
authentication, the occupied ACL will be released. If a large amount of users access the freely
accessible network segment but fail the authentication, ACLs will soon be used up and new users will
be rejected.
An EAD rule timeout timer is designed to solve this problem. When a user accesses the network, this
timer is started. If the user neither downloads client software nor performs authentication before the
timer expires, the occupied ACL will be released so that other users can use it. When there are a large
number of users, you can shorten the timeout time to improve the ACL usage efficiency.
Follow these steps to set the EAD rule timeout time:

dot1x timer ead-timeout Optional

Set EAD rule timeout time
ead-timeout-value 30 minutes by default
Displaying and Maintaining EAD Fast Deployment

Display 802.1X session display dot1x [ sessions |
information, statistics, or statistics ] [ interface Available in any view
configuration information interface-list ]
3-3

EAD Fast Deployment Configuration Example
As shown in Figure 3-1, the host is connected to the device, and the device is connected to the freely
accessible network segment and outside network.
It is required that:
z Before successful 802.1 authentication, the host using IE to access outside network will be
redirected to the WEB server, and it can download and install 802.1X client software.
z After successful 802.1X authentication, the host can access outside network.
Figure 3-1 Network diagram for EAD fast deployment
Internet
Free IP:
WEB server
192.168.2.3/24
GE1/0/1
192.168.2.0/24
192.168.1.1/24
Host Device
192.168.1.10/24
1) Configure the WEB server

Before using the EAD fast deployment function, you need to configure the WEB server to provide the
download service of 802.1X client software.
2) Configure the device to support EAD fast deployment
# Configure the IP addresses of the interfaces (omitted).
# Configure the free IP.
[Device] dot1x free-ip 192.168.2.0 24
# Configure the redirect URL for client software download.

[Device] dot1x url http://192.168.2.3

[Device] dot1x
# Enable 802.1X on the port.

[Device -GigabitEthernet1/0/1] dot1x
3) Verify your configuration

# Use the ping command to ping an IP address within the network segment specified by free IP to
check that the user can access that segment before passing 802.1X authentication.
3-4

C:\>ping 192.168.2.3
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128


Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Besides, if the user uses IE to access any external website, the user will be taken to the WEB server,
which provides the client software download service.
Troubleshooting EAD Fast Deployment

Users Cannot be Redirected Correctly
Symptom
When a user enters an external website address in the IE browser, the user is not redirected to the
specified URL.
Analysis
z The address is in the string format. In this case, the operating system of the host regards the string
a website name and tries to have it resolved. If the resolution fails, the operating system sends an
ARP request with the address in the format other than X.X.X.X. The redirection function does
redirect this kind of ARP request.
z The address is within the freely accessible network segment. In this case, the device regards that
the user is trying to access a host in the freely accessible network segment, and redirection will
not take place, even if no host is present with the address.
z The redirect URL is not in the freely accessible network segment, no server is present with that
URL, or the server with the URL does not provide WEB services.
Solution
z Enter an IP address that is not within the freely accessible network segment in dotted decimal
notation (X.X.X.X).
z Ensure that the device and the server are configured correctly.
3-5

4 HABP Configuration
When configuring HABP, go to these sections for the information you are interested in:
z Introduction to HABP
z Configuring HABP
z Displaying and Maintaining HABP
z HABP Configuration Example
Introduction to HABP
The HW Authentication Bypass Protocol (HABP) is used to enable the downstream network devices of
an 802.1X or MAC authentication enabled access device to bypass 802.1X authentication and MAC
authentication.
HABP is usually adopted at the access layer of a campus or enterprise network. This feature is useful
when 802.1X authentication or MAC address authentication is adopted on the management switch of a
cluster, in which case you must configure HABP to allow the packets between the member devices of
the cluster to bypass 802.1X authentication because network devices usually do not support 802.1
client. Otherwise, the management device will fail to perform centralized management of the cluster
member devices. For more information about the cluster function, refer to Cluster Configuration in the
System Volume.
As shown in Figure 4-1, 802.1X authenticator Switch A has two switches attached to it: Switch B and
Switch C. On Switch A, 802.1X authentication is enabled globally and on the ports connecting the
downstream network devices. The end-user devices (the supplicants) run the 802.1X client software
for 802.1X authentication. For Switch B and Switch D, where 802.1X client is not supported (which is
typical of network devices), the communication between them will fail because they cannot pass
802.1X authentication and their packets will be blocked on Switch A. To allow the two switches to
communicate, you can use HABP.
4-1

Figure 4-1 Network diagram for HABP application
Internet
Switch A
Authentication
server
Authenticator
Switch B Switch C
Switch D Switch E
Supplicant
Supplicant Supplicant
HABP is a link layer protocol that works above the MAC layer. It is built on the client-server model.
Generally, the HABP server is assumed by the management device (such as Switch A in the above
example), and the attached switches function as the HABP clients, such as Switch B through Switch E
in the example. No device can function as both an HABP server and a client at the same time. Typically,
the HABP server sends HABP requests to all its clients periodically to collect their MAC addresses,
and the clients respond to the requests. After the server learns the MAC addresses of all the clients, it
registers the MAC addresses as HABP entries. Then, link layer frames exchanged between the clients
can bypass the 802.1X authentication on ports of the server without affecting the normal operation of
the whole network. All HABP packets must travel in a VLAN, which is called the management VLAN.
Communication between the HABP server and the HABP clients is implemented through the
management VLAN.
Configuring HABP
Complete the following tasks to configure HABP:
z Configuring the HABP Server
z Configuring an HABP Client
Configuring the HABP Server
With the HABP server function enabled, the administrative device starts to send HABP requests to the
attached switches. The HABP responses include the MAC addresses of the attached switches. This
makes it possible for the administrative device to manage the attached switches.
You can configure the interval of sending HABP requests on the administrative device.
Follow these steps to configure an HABP server:

Optional
Enable HABP habp enable
Enabled by default
4-2

Configure HABP to work Required

habp server vlan vlan-id
in server mode HABP works in client mode by default.
Set the interval to send Optional

habp timer interval
HABP requests 20 seconds by default
Configuring an HABP Client
Configure the HABP client function on each device that is attached to the administrative device and
needs to be managed. As the HABP client function is enabled by default, this configuration task is
optional.
Follow these steps to configure an HABP client:

Optional
Enable HABP habp enable
Enabled by default
Configure HABP to work in Optional

undo habp server
client mode HABP works in client mode by default.
Displaying and Maintaining HABP

Display HABP configuration
display habp Available in any view
information
Display HABP MAC address
display habp table Available in any view
table entries
Display HABP packet statistics display habp traffic Available in any view
HABP Configuration Example

Switch A is the administrative device and connects two access devices: Switch B and Switch C.
Configure HABP so that Switch A can manage Switch B and Switch C.
z Configure Switch A as the HABP server, allowing HABP packets to be transmitted in VLAN 2.
z Enable HABP client on Switch B and Switch C.
z On switch A, set the interval to send HABP request packets to 50 seconds.
4-3

Figure 4-2 Network diagram for HABP configuration
# Enable HABP.
[SwitchA] habp enable
# Configure HABP to work in server mode, allowing HABP packets to be transmitted in VLAN 2.
[SwitchA] habp server vlan 2
# Set the interval to send HABP request packets to 50 seconds.

[SwitchA] habp timer 50
2) Configure Switch B and Switch C
Configure Switch B and Switch C to work in HABP client mode. This configuration is usually
unnecessary because HABP is enabled and works in client mode by default.
# Display HABP configuration information.
<SwitchA> display habp
Global HABP information:
HABP Mode: Server
Sending HABP request packets every 50 seconds
Bypass VLAN: 2
# Display HABP MAC address table entries.

<SwitchA> display habp table
MAC Holdtime Receive Port
001f-3c00-0030 53 GigabitEthernet 1/0/2
001f-3c00-0031 53 GigabitEthernet 1/0/1
4-4

5 MAC Authentication Configuration
When configuring MAC authentication, go to these sections for information you are interested in:
z MAC Authentication Overview
z Related Concepts
z Configuring MAC Authentication
z Displaying and Maintaining MAC Authentication
z MAC Authentication Configuration Examples
MAC Authentication Overview

MAC authentication provides a way for authenticating users based on ports and MAC addresses.
Once detecting a new MAC address, the device initiates the authentication process. MAC
authentication requires neither client software to be installed on the hosts, nor any username or
password to be entered by users during authentication.
Currently, the device supports two MAC authentication modes: Remote Authentication Dial-In User
Service (RADIUS) based MAC authentication and local MAC authentication. For detailed information
about RADIUS authentication and local authentication, refer to AAA Configuration of the Security
Volume.
MAC authentication supports two types of usernames:
z MAC address, where the MAC address of a user serves as both the username and password.
z Fixed username, where all users use the same preconfigured username and password for
authentication, regardless of the MAC addresses.
RADIUS-Based MAC Authentication
In RADIUS-based MAC authentication, the device serves as a RADIUS client and requires a RADIUS
server to cooperate with it.
z If the type of username is MAC address, the device forwards a detected MAC address as the
username and password to the RADIUS server for authentication of the user.
z If the type of username is fixed username, the device sends the same username and password
configured locally to the RADIUS server for authentication of each user.
If the authentication succeeds, the user will be granted permission to access the network resources.
Local MAC Authentication
In local MAC authentication, the device performs authentication of users locally and different items
need to be manually configured for users on the device according to the specified type of username:
z If the type of username is MAC address, a local user must be configured for each user on the
device, using the MAC address of the accessing user as both the username and password.
z If the type of username is fixed username, a single username and optionally a single password are
required for the device to authenticate all users.
5-1

Related Concepts
MAC Authentication Timers
The following timers function in the process of MAC authentication:

z Offline detect timer: At this interval, the device checks to see whether there is traffic from a user.
Once detecting that there is no traffic from a user within this interval, the device logs the user out
and sends to the RADIUS server a stop accounting request.
z Quiet timer: Whenever a user fails MAC authentication, the device does not perform MAC
authentication of the user during such a period.
z Server timeout timer: During authentication of a user, if the device receives no response from the
RADIUS server in this period, it assumes that its connection to the RADIUS server has timed out
and forbids the user to access the network.
Quiet MAC Address
When a user fails MAC authentication, the MAC address becomes a quiet MAC address, which means
that any packets from the MAC address will be discarded silently by the device until the quiet timer
expires. This prevents the device from authenticating an illegal user repeatedly in a short time.
If a quiet MAC address is the same as a static MAC address configured or an MAC address that has
passed another type of authentication, the quiet function does not take effect.
VLAN Assigning
For separation of users from restricted network resources, users and restricted resources are usually
put into different VLANs. After a user passes identity authentication, the authorization server assigns to
the user the VLAN where the restricted resources reside as an authorized VLAN, and the port through
which the user accesses the device will be assigned to the authorized VLAN. As a result, the user can
access those restricted network resources.
ACL Assigning
ACLs assigned by an authorization server are referred to as authorization ACLs, which are designed to
control access to network resources. If the RADIUS server is configured with authorization ACLs, the
device will permit or deny data flows traversing through the port through which a user accesses the
device according to the authorization ACLs. You can change access rights of users by modifying
authorization ACL settings on the RADIUS server.
Configuring MAC Authentication

z Create and configure an ISP domain.

z For local authentication, create the local users and configure the passwords.
5-2

z For RADIUS authentication, ensure that a route is available between the device and the RADIUS
server, and add the usernames and passwords on the server.
When adding usernames and passwords on the device or server, ensure that:
z The type of username and password must be consistent with that used for MAC authentication.
z All the letters in the MAC address to be used as the username and password must be in lower
case.
z The service type of the local users must be configured as lan-access.
Follow these steps to configure MAC authentication:

Enable MAC Required

mac-authentication
authentication globally Disabled by default
mac-authentication interface
interface-list
Enable MAC Required
authentication for specified Use either approach.
interface-number
ports Disabled by default
mac-authentication
quit
Optional
Specify the ISP domain for mac-authentication domain
MAC authentication isp-name The default ISP domain is used
by default.
mac-authentication timer Optional

Set the offline detect timer
offline-detect offline-detect-value 300 seconds by default
mac-authentication timer quiet Optional

Set the quiet timer
quiet-value 60 seconds by default
mac-authentication timer Optional
Set the server timeout
server-timeout
timer 100 seconds by default
server-timeout-value
mac-authentication Optional
user-name-format { fixed
Configure the username By default, the users source
[ account name ] [ password
and password for MAC MAC address serves as the
{ cipher | simple } password ] |
authentication username and password, with
mac-address [ with-hyphen |
without-hyphen ] } - in the MAC address.
5-3

z You can configure MAC authentication for ports first. However, the configuration takes effect only
after you enable MAC authentication globally.
z Enabling MAC authentication on a port is mutually exclusive with adding the port to an
aggregation group.
z For details about the default ISP domain, refer to AAA Configuration in the Security Volume.
Displaying and Maintaining MAC Authentication

Display the global MAC
authentication information or the display mac-authentication
MAC authentication information [ interface interface-list ]
about specified ports
reset mac-authentication
Clear the MAC authentication
statistics [ interface Available in user view
statistics
interface-list ]
MAC Authentication Configuration Examples

Local MAC Authentication Configuration Example
As illustrated in Figure 5-1, a supplicant is connected to the device through port GigabitEthernet 1/0/1.
z Local MAC authentication is required on every port to control user access to the Internet.
z All users belong to domain aabbcc.net.
z Local users use their MAC addresses as the usernames and passwords for authentication.
z Set the offline detect timer to 180 seconds and the quiet timer to 3 minutes.
Figure 5-1 Network diagram for local MAC authentication
1) Configure MAC authentication on the device

# Add a local user, setting the username and password as 00-e0-fc-12-34-56, the MAC address of the
user.
[Device] local-user 00-e0-fc-12-34-56
[Device-luser-00-e0-fc-12-34-56] password simple 00-e0-fc-12-34-56
5-4

[Device-luser-00-e0-fc-12-34-56] service-type lan-access
[Device-luser-00-e0-fc-12-34-56] quit
# Configure ISP domain aabbcc.net, and specify that the users in the domain use local authentication.
[Device] domain aabbcc.net
[Device-isp-aabbcc.net] authentication lan-access local
[Device-isp-aabbcc.net] quit
# Enable MAC authentication globally.

[Device] mac-authentication
# Enable MAC authentication for port GigabitEthernet 1/0/1.

[Device] mac-authentication interface GigabitEthernet 1/0/1
# Specify the ISP domain for MAC authentication.

[Device] mac-authentication domain aabbcc.net
# Set the MAC authentication timers.

[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Specify the MAC authentication username format as MAC address, that is, using the MAC address
(with hyphens) of a user as the username and password for MAC authentication of the user.
[Device] mac-authentication user-name-format mac-address with-hyphen
# Display global MAC authentication information.
<Device> display mac-authentication
MAC address authentication is enabled.
User name format is MAC address, like xx-xx-xx-xx-xx-xx
Fixed username:mac
Fixed password:not configured
Offline detect period is 180s
Quiet period is 180s.
Server response timeout value is 100s
The max allowed user number is 1024 per slot
Current user number amounts to 1
Current domain is aabbcc.net
Silent Mac User info:

MAC Addr From Port Port Index
GigabitEthernet1/0/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Current online user number is 1
MAC Addr Authenticate state Auth Index
00e0-fc12-3456 MAC_AUTHENTICATOR_SUCCESS 29
5-5

RADIUS-Based MAC Authentication Configuration Example
As illustrated in Figure 5-2, a host is connected to the device through port GigabitEthernet 1/0/1. The
device authenticates, authorizes and keeps accounting on the host through the RADIUS server.
z MAC authentication is required on every port to control user access to the Internet.
z Set the offline detect timer to 180 seconds and the quiet timer to 3 minutes.
z All users belong to ISP domain 2000.
z The username type of fixed username is used for authentication, with the username being aaa
and password being 123456.
Figure 5-2 Network diagram for MAC authentication using RADIUS
It is required that the RADIUS server and the device are reachable to each other and the username
and password are configured on the server.
1) Configure MAC authentication on the device

# Configure a RADIUS scheme.
# Specify the AAA schemes for the ISP domain.

[Device] domain 2000
[Device-isp-2000] authentication default radius-scheme 2000
[Device-isp-2000] authorization default radius-scheme 2000
5-6

[Device-isp-2000] accounting default radius-scheme 2000
[Device-isp-2000] quit

[Device] mac-authentication

[Device] mac-authentication interface GigabitEthernet 1/0/1
# Specify the ISP domain for MAC authentication.

[Device] mac-authentication domain 2000
# Set the MAC authentication timers.

[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Specify to use the username aaa and password 123456 for MAC authentication of all users.
[Device] mac-authentication user-name-format fixed account aaa password simple 123456
# Display global MAC authentication information.
<Device> display mac-authentication
MAC address authentication is enabled.
User name format is fixed account
Fixed username:aaa
Fixed password:123456
Offline detect period is 180s
Quiet period is 180s.
Server response timeout value is 100s
The max allowed user number is 1024 per slot
Current user number amounts to 1
Current domain is 2000
Silent Mac User info:

MAC Addr From Port Port Index
00e0-fc12-3456 MAC_AUTHENTICATOR_SUCCESS 29
ACL Assignment Configuration Example
As shown in Figure 5-3, a host is connected to port GigabitEthernet 1/0/1 of the switch and must pass
MAC authentication to access the Internet.
z Specify to use the MAC address of a user as the username and password for MAC authentication
of the user.
z Configure the RADIUS server to assign ACL 3000.
5-7

z On port GigabitEthernet 1/0/1 of the switch, enable MAC authentication and configure ACL 3000.
After the host passes MAC authentication, the RADIUS server assigns ACL 3000 to port
GigabitEthernet 1/0/1 of the switch. As a result, the host can access the Internet but cannot access the
FTP server, whose IP address is 10.0.0.1.
Figure 5-3 Network diagram for ACL assignment
z Make sure that there is a route available between the RADIUS server and the switch.
z In this example, the switch uses the default username type (user MAC address) for MAC
authentication. Therefore, you need to add the username and password of each user on the
RADIUS server correctly.
z You need to configure the RADIUS server to assign ACL 3000 as the authorization ACL.

[Sysname] radius scheme 2000
[Sysname-radius-2000] primary authentication 10.1.1.1 1812
[Sysname-radius-2000] primary accounting 10.1.1.2 1813
[Sysname-radius-2000] key authentication abc
[Sysname-radius-2000] key accounting abc
[Sysname-radius-2000] user-name-format without-domain
[Sysname-radius-2000] quit
# Create an ISP domain and specify the AAA schemes.

[Sysname] domain 2000
[Sysname-isp-2000] authentication default radius-scheme 2000
[Sysname-isp-2000] authorization default radius-scheme 2000
[Sysname-isp-2000] accounting default radius-scheme 2000
[Sysname-isp-2000] quit
# Configure ACL 3000 to deny packets destined for 10.0.0.1.

5-8

[Sysname-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0
[Sysname-acl-adv-3000] quit

[Sysname] mac-authentication
# Specify the ISP domain for MAC authentication users.

[Sysname] mac-authentication domain 2000
# Specify the MAC authentication username type as MAC address, that is, using the MAC address of a
user as the username and password for MAC authentication of the user.
[Sysname] mac-authentication user-name-format mac-address

[Sysname-GigabitEthernet1/0/1] mac-authentication
After completing the above configurations, you can use the ping command to verify whether the ACL
3000 assigned by the RADIUS server functions.
C:\>ping 10.0.0.1
Request timed out.

Request timed out.
Request timed out.
Request timed out.

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
C:\>
5-9

6 Port Security Configuration
When configuring port security, go to these sections for information you are interested in:
z Introduction to Port Security
z Port Security Configuration Task List
z Displaying and Maintaining Port Security
z Port Security Configuration Examples
z Troubleshooting Port Security
Introduction to Port Security

Port Security Overview
Port security is a MAC address-based security mechanism for network access controlling. It is an
extension to the existing 802.1X authentication and MAC authentication. It controls the access of
unauthorized devices to the network by checking the source MAC address of an inbound frame and
the access to unauthorized devices by checking the destination MAC address of an outbound frame.
With port security, you can define various port security modes to make a device learn only legal source
MAC addresses, so that you can implement different network security management as needed. When
a port security-enabled device detects an illegal frame, it triggers the corresponding port security
feature and takes a pre-defined action automatically. This reduces your maintenance workload and
greatly enhances system security.
The following types of frames are classified as illegal:
z Received frames with unknown source MAC addresses when MAC address learning is disabled.
z Received frames with unknown source MAC addresses when the number of MAC addresses
learned by the port has already reached the upper limit.
z Frames from unauthenticated users.
The security modes of the port security feature provide extended and combined use of 802.1X
authentication and MAC authentication and therefore apply to scenarios that require both 802.1X
authentication and MAC authentication. For scenarios that require only 802.1X authentication or MAC
authentication for access control, however, you are recommended to configure the 802.1X
authentication or MAC authentication for simplicity. For information about 802.1X and MAC
authentication, refer to 802.1X Configuration and MAC Authentication Configuration in the Security
Volume.
6-1

Port Security Features
NTK
The need to know (NTK) feature checks the destination MAC addresses in outbound frames and
allows frames to be sent to only devices passing authentication, thus preventing illegal devices from
intercepting network traffic.
Intrusion protection
The intrusion protection feature checks the source MAC addresses in inbound frames and takes a
pre-defined action accordingly upon detecting illegal frames. The action may be disabling the port
temporarily, disabling the port permanently, or blocking frames from the MAC address for three
minutes (unmodifiable).
Trap
The trap feature enables the device to send trap messages upon detecting specified frames that result
from, for example, intrusion or user login/logout operations, helping you monitor special activities.
Port Security Modes
Table 6-1 details the port security modes.
Table 6-1 Port security modes
Security mode Description Features

In this mode, neither
Port security is disabled on the port and access to the NTK nor the
noRestrictions
the port is not restricted. intrusion protection
feature is triggered.
In this mode, a port can learn a specified number
of MAC addresses and save those addresses as
secure MAC addresses. It permits only frames
whose source MAC addresses are secure MAC
autoLearn addresses or static MAC addresses configured by
using the mac-address static command. In either mode, the
When the number of secure MAC addresses device will trigger NTK
reaches the upper limit, the port changes to work and intrusion protection
in secure mode. upon detecting an
illegal frame.
In this mode, a port is disabled from learning
MAC addresses and permits only frames whose
secure source MAC addresses are secure MAC
addresses or static MAC addresses configured by
using the mac-address static command.
In this mode, a port performs 802.1X In this mode, neither
authentication of users in portbased mode. NTK nor intrusion
userLogin
A port in this mode can service multiple 802.1X protection will be
users, but allows only one at a moment. triggered.
6-2

Security mode Description Features
In this mode, a port performs 802.1X
authentication of users in portbased mode and
userLoginSecure
services only one user passing 802.1X
authentication.
Similar to the userLoginSecure mode, a port in
this mode performs 802.1X authentication of
users and services only one user passing 802.1X
userLoginWithOUI authentication.
The port also permits frames from a user whose
MAC address contains a specified OUI
(organizationally unique identifier).
macAddressWithRa In this mode, a port performs MAC authentication
dius of users.
This mode is the combination of the

userLoginSecure and macAddressWithRadius
modes, with 802.1X authentication having a
macAddressOrUser higher priority
LoginSecure The port performs MAC authentication upon
receiving non-8021.x frames and performs In any of these modes,
802.1X authentication upon receiving 802.1X the device will trigger
frames. NTK and intrusion
protection upon
This mode is the combination of the detecting an illegal
macAddressWithRadius and userLoginSecure frame.
modes, with MAC authentication having a higher
priority.
macAddressElseUs z Upon receiving a non-802.1X frame, a port in
erLoginSecure this mode performs only MAC authentication.
z Upon receiving an 802.1X frame, the port
performs MAC authentication and then, if
MAC authentication fails, 802.1X
authentication.
In this mode, a port performs 802.1X
userLoginSecureExt authentication of users in macbased mode and
supports multiple 802.1X users.
This mode is similar to the

macAddressOrUser macAddressOrUserLoginSecure mode, except
LoginSecureExt that it supports multiple 802.1X and MAC
authentication users on the port.
This mode is similar to the
macAddressElseUs macAddressElseUserLoginSecure mode, except
erLoginSecureExt that it supports multiple 802.1X and MAC
authentication users on the port.
6-3

z Currently, port security supports two authentication methods: 802.1X and MAC authentication.
Different port security modes employ different authentication methods or different combinations of
authentication methods.
z The maximum number of users a port supports is the lesser of the maximum number of secure
MAC addresses or the maximum number of authenticated users the security mode supports. For
example, in userLoginSecureExt mode, the maximum number of users a port supports is the
lesser of the maximum number of secure MAC addresses configured or the maximum number of
users that 802.1X supports.
These security mode naming rules may help you remember the modes:
z userLogin specifies port-based 802.1X authentication.
z macAddress specifies MAC address authentication.
z Else specifies that the authentication method before Else is applied first. If the authentication fails,
the protocol type of the authentication request determines whether to turn to the authentication
method following the Else.
z In a security mode with Or, the protocol type of the authentication request determines which
authentication method is to be used. However, 802.1X authentication is preferred by wireless
users.
z userLogin with Secure specifies MAC-based 802.1X authentication.
z Ext indicates allowing multiple 802.1X users to be authenticated and get online. A security mode
without Ext allows only one 802.1X user to be authenticated and get online.
Port Security Configuration Task List

Complete the following tasks to configure port security:
Task Remarks
Enabling Port Security Required
Setting the Maximum Number of Secure MAC Addresses Optional
Setting the Port Security Mode Required
Configuring NTK Optional

Configuring Port Security Features Configuring Intrusion Protection Choose one or
more features as
Configuring Trapping required.
Configuring Secure MAC Addresses Optional
Ignoring Authorization Information from the Server Optional
6-4

Enabling Port Security
Before enabling port security, you need to disable 802.1X and MAC authentication globally.
Follow these steps to enable port security:

Required
Enable port security port-security enable
Disabled by default
Note that:
1) Enabling port security resets the following configurations on a port to the bracketed defaults. Then,
values of these configurations cannot be changed manually; the system will adjust them based on
the port security mode automatically:
z 802.1X (disabled), port access control method (macbased), and port access control mode (auto)
z MAC authentication (disabled)
2) Disabling port security resets the following configurations on a port to the bracketed defaults:
z Port security mode (noRestrictions)
z 802.1X (disabled), port access control method (macbased), and port access control mode (auto)
z MAC authentication (disabled)
3) Port security cannot be disabled if there is any user present on a port.
z For detailed 802.1X configuration, refer to 802.1X Configuration in the Security Volume.
z For detailed MAC-based authentication configuration, refer to MAC Authentication Configuration
in the Security Volume.
Setting the Maximum Number of Secure MAC Addresses

With port security enabled, more than one authenticated user is allowed on a port. The number of
authenticated users allowed, however, cannot exceed the specified upper limit.
By setting the maximum number of secure MAC addresses allowed on a port, you can:
z Control the maximum number of users who are allowed to access the network through the port.
z Control the number of secure MAC addresses that can be added with port security.
6-5

Follow these steps to set the maximum number of secure MAC addresses allowed on a port:

interface-number
Set the maximum number of Required
port-security max-mac-count
secure MAC addresses
count-value Not limited by default
allowed on a port
This configuration is different from that of the maximum number of MAC addresses that can be leaned
by the port in MAC address management.
Setting the Port Security Mode

Before setting the port security mode, ensure that:

z 802.1X is disabled, the port access control method is macbased, and the port access control
mode is auto.
z MAC authentication is disabled.
z The port does not belong to any aggregation group.
The above requirements must be all met. Otherwise, you will see an error message and your
configuration will fail. On the other hand, after setting the port security mode on a port, you cannot
change any configurations of the first three requirements.
z With port security disabled, you can configure the port security mode, but your configuration does
not take effect.
z You cannot change the port security mode of a port when any user is present on the port.
z Before configuring the port to operate in autoLearn mode, set the maximum number of secure
MAC addresses allowed on a port.
6-6

Configuring Procedure
Follow these steps to enable any other port security mode:

Optional
Set an OUI value for port-security oui oui-value index Not configured by default.
user authentication index-value The command is required for
the userlogin-withoui mode.
interface-number
port-security port-mode { autolearn |
mac-authentication |
mac-else-userlogin-secure |
mac-else-userlogin-secure-ext | Required
Set the port security
secure | userlogin | userlogin-secure By default, a port operates in
mode
| userlogin-secure-ext | noRestrictions mode.
userlogin-secure-or-mac |
userlogin-secure-or-mac-ext |
userlogin-withoui }
z You cannot change the maximum number of secure MAC addresses allowed on a port that
operates in autoLearn mode.
z OUI, defined by IEEE, is the first 24 bits of the MAC address and uniquely identifies a device
vendor.
z You can configure multiple OUI values. However, a port in userLoginWithOUI mode allows only
one 802.1X user and one user whose MAC address contains a specified OUI.
z After enabling port security, you can change the port security mode of a port only when the port is
operating in noRestrictions mode, the default mode. To change the port security mode of a port
operating in any other mode, use the undo port-security port-mode command to restore the
default port security mode at first.
z You cannot change the port security mode of a port with users online.
Configuring Port Security Features

Configuring NTK
The need to know (NTK) feature checks the destination MAC addresses in outbound frames to allow
frames to be forwarded to only devices passing authentication. The NTK feature supports three
modes:
z ntkonly: Forwards only frames destined for authenticated MAC addresses.
z ntk-withbroadcasts: Forwards only frames destined for authenticated MAC addresses or the
broadcast address.
6-7

z ntk-withmulticasts: Forwards only frames destined for authenticated MAC addresses, multicast
addresses, or the broadcast address.
By default, NTK is disabled on a port and the port forwards all frames. With NTK configured, a port will
discard any unicast packet with an unknown MAC address no matter in which mode it operates.
Follow these steps to configure the NTK feature:

interface-number
Required
port-security ntk-mode
Configure the NTK feature { ntk-withbroadcasts | By default, NTK is disabled on
ntk-withmulticasts | ntkonly } a port and all frames are
allowed to be sent.
Support for the NTK feature depends on the port security mode.
Configuring Intrusion Protection
The intrusion protection enables a device to perform either of the following security policies when it
detects illegal frames:
z blockmac: Adds the source MAC addresses of illegal frames to the blocked MAC addresses list
and discards frames with blocked source MAC addresses. A blocked MAC address is restored to
normal after being blocked for three minutes, which is fixed and cannot be changed.
z disableport: Disables the port permanently.
z disableport-temporarily: Disables the port for a specified period of time. Use the port-security
timer disableport command to set the period.
Follow these steps to configure the intrusion protection feature:

interface-number
port-security intrusion-mode Required

Configure the intrusion
{ blockmac | disableport | By default, intrusion protection
protection feature
disableport-temporarily } is disabled.
Set the silence timeout during port-security timer Optional

which a port remains disabled disableport time-value 20 seconds by default
6-8

On a port operating in either the macAddressElseUserLoginSecure mode or the
macAddressElseUserLoginSecureExt mode, intrusion protection is triggered only after both MAC
authentication and 802.1X authentication for the same frame fail.
Configuring Trapping
The trapping feature enables a device to send trap information in response to four types of events:
z addresslearned: A port learns a new address.
z dot1xlogfailure/dot1xlogon/dot1xlogoff: A port learns 802.1x authentication failure/successful
802.1x authentication/802.1x user logoff.
z ralmlogfailure/ralmlogoff: A port learns MAC authentication failure/MAC authentication user
logoff.
z intrusion: A port learns illegal frames.
Follow these steps to configure port security trapping:

port-security trap { addresslearned | Required

Enable port security dot1xlogfailure | dot1xlogoff |
traps dot1xlogon | intrusion | ralmlogfailure By default, no port security trap
| ralmlogoff | ralmlogon } is enabled.
Configuring Secure MAC Addresses

Secure MAC addresses are special MAC addresses. They never age out or get lost if saved before the
device restarts. One secure MAC address can be added to only one port in the same VLAN. Thus, you
can bind a MAC address to one port in the same VLAN.
Secure MAC addresses can be:
z Learned by a port working in autoLearn mode.
z Manually configured through the command line interface (CLI) or management information base
(MIB).
When the maximum number of secure MAC addresses is reached, no more can be added. The port
allows only the packets with the source MAC address being the secure MAC address.
z Enable port security

z Set the maximum number of secure MAC addresses allowed on the port
z Set the port security mode to autoLearn
Follow these steps to configure a secure MAC address:
6-9

port-security mac-address security

In system Required
mac-address interface interface-type
view
Configure a interface-number vlan vlan-id Use either approach
secure MAC No secure MAC
interface interface-type interface-number
address In interface address is configured
view port-security mac-address security by default.
mac-address vlan vlan-id
The configured secure MAC addresses are saved in the configuration file and will not get lost when the
port goes up or goes down. After you save the configuration file, the secure MAC address saved in the
configuration file are maintained even after the device restarts.
Ignoring Authorization Information from the Server

After an 802.1X user or MAC authenticated user passes RADIUS authentication, the RADIUS server
delivers the authorization information to the device. You can configure a port to ignore the
authorization information from the RADIUS server.
Follow these steps to configure a port to ignore the authorization information from the RADIUS server:

interface-number
Required
Ignore the authorization
port-security authorization By default, a port uses the
information from the RADIUS
ignore authorization information from
server
the RADIUS server.
Displaying and Maintaining Port Security

Display port security
configuration information,
display port-security [ interface Available in any
operation information, and
interface-list ] view
statistics about one or more
ports or all ports
display port-security mac-address
Display information about Available in any
security [ interface interface-type
secure MAC addresses view
interface-number ] [ vlan vlan-id ] [ count ]
6-10

display port-security mac-address block
Display information about Available in any
[ interface interface-type interface-number ]
blocked MAC addresses view
[ vlan vlan-id ] [ count ]
Port Security Configuration Examples

Configuring the autoLearn Mode
Restrict port GigabitEthernet 1/0/1 of the switch as follows:

z Allow up to 64 users to access the port without authentication and permit the port to learn and add
the MAC addresses of the users as secure MAC addresses.
z After the number of secure MAC addresses reaches 64, the port stops learning MAC addresses. If
any frame with an unknown MAC address arrives, intrusion protection is triggered and the port is
disabled and stays silence for 30 seconds.
Figure 6-1 Network diagram for configuring the autoLearn mode
1) Configure port security

# Enable port security.
[Switch] port-security enable
# Enable intrusion protection trap.

[Switch] port-security trap intrusion
[Switch] interface gigabitethernet 1/0/1
# Set the maximum number of secure MAC addresses allowed on the port to 64.
[Switch-GigabitEthernet1/0/1] port-security max-mac-count 64
# Set the port security mode to autoLearn.

[Switch-GigabitEthernet1/0/1] port-security port-mode autolearn
# Configure the port to be silent for 30 seconds after the intrusion protection feature is triggered.
[Switch-GigabitEthernet1/0/1] port-security intrusion-mode disableport-temporarily
[Switch-GigabitEthernet1/0/1] quit
[Switch] port-security timer disableport 30
After completing the above configurations, you can use the following command to view the port
security configuration information:
<Switch> display port-security interface gigabitethernet 1/0/1
6-11

Equipment port-security is enabled
Intrusion trap is enabled
Disableport Timeout: 30s
OUI value:
Port mode is autoLearn
NeedToKnow mode is disabled
Intrusion Protection mode is DisablePortTemporarily
Max MAC address number is 64
Stored MAC address number is 0
Authorization is permitted
As shown in the output, the maximum number of secure MAC addresses allowed on the port is 64, the
port security mode is autoLearn, the intrusion protection trap is enabled, and the intrusion protection
action is to disable the port (DisablePortTemporarily) for 30 seconds.
You can also use the above command repeatedly to track the number of MAC addresses learned by
the port, or use the display this command in interface view to display the secure MAC addresses
learned, as shown below:
[Switch-GigabitEthernet1/0/1] display this
#
interface GigabitEthernet1/0/1
port-security max-mac-count 64
port-security port-mode autolearn
port-security intrusion-mode disableport-temporarily
port-security mac-address security 0002-0000-0015 vlan 1
#
Issuing the display port-security interface command after the number of MAC addresses learned by
the port reaches 64, you will see that the port security mode has changed to secure. When any frame
with a new MAC address arrives, intrusion protection is triggered and you will see trap messages as
follows:
#May 2 03:15:55:871 2000 Switch PORTSEC/1/VIOLATION:Traph3cSecureViolation
A intrusion occurs!
IfIndex: 9437207
Port: 9437207
MAC Addr: 0.2.0.0.0.21
VLAN ID: 1
IfAdminStatus: 1
In addition, you will see that the port security feature has disabled the port if you issue the following
command:
[Switch-GigabitEthernet1/0/1] display interface gigabitethernet 1/0/1
6-12

GigabitEthernet1/0/1 current state: Port Security Disabled
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 000f-cb00-5558
......
The port should be re-enabled 30 seconds later.

[Switch-GigabitEthernet1/0/1] display interface gigabitethernet 1/0/1
GigabitEthernet1/0/1 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 000f-cb00-5558
......
Now, if you manually delete several secure MAC addresses, the port security mode of the port will be
restored to autoLearn, and the port will be able to learn MAC addresses again.
Configuring the userLoginWithOUI Mode
The client is connected to the switch through port GigabitEthernet 1/0/1. The switch authenticates the
client by the RADIUS server. If the authentication succeeds, the client is authorized to access the
Internet.
z RADIUS server 192.168.1.2 functions as the primary authentication server and the secondary
accounting server, and RADIUS server 192.168.1.3 functions as the secondary authentication
server and the primary accounting server. The shared key for authentication is name, and that for
accounting is money.
z All users belong to default domain sun, which can accommodate up to 30 users.
z The RADIUS server response timeout time is five seconds and the maximum number of RADIUS
packet retransmission attempts is five. The switch sends real-time accounting packets to the
RADIUS server at an interval of 15 minutes, and sends user names without domain names to the
RADIUS server.
z Allow only one 802.1X user to be authenticated.
z Allow up to 16 OUI values to be configured and allow one additional user whose MAC address
has an OUI among the configured ones to access the port.
Figure 6-2 Network diagram for configuring the userLoginWithOUI mode
6-13

z The following configuration steps cover some AAA/RADIUS configuration commands. For details
about the commands, refer to AAA Configuration in the Security Volume.
z Configurations on the host and RADIUS servers are omitted.
1) Configure the RADIUS protocol

# Configure a RADIUS scheme named radsun.
[Switch] radius scheme radsun
[Switch-radius-radsun] primary authentication 192.168.1.2
[Switch-radius-radsun] primary accounting 192.168.1.3
[Switch-radius-radsun] secondary authentication 192.168.1.3
[Switch-radius-radsun] secondary accounting 192.168.1.2
[Switch-radius-radsun] key authentication name
[Switch-radius-radsun] key accounting money
[Switch-radius-radsun] timer response-timeout 5
[Switch-radius-radsun] retry 5
[Switch-radius-radsun] timer realtime-accounting 15
[Switch-radius-radsun] user-name-format without-domain
[Switch-radius-radsun] quit
# Configure an ISP domain named sun.

[Switch] domain sun
[Switch-isp-sun] authentication default radius-scheme radsun
[Switch-isp-sun] authorization default radius-scheme radsun
[Switch-isp-sun] accounting default radius-scheme radsun
[Switch-isp-sun] access-limit enable 30
[Switch-isp-sun] quit
2) Configure 802.1X
# Set the 802.1X authentication method to CHAP. (This configuration is optional. By default, the
authentication mehtod is CHAP for 802.1X.)
[Switch] dot1x authentication-method chap
# Add five OUI values.

[Switch] port-security oui 1234-0100-1111 index 1
6-14

# Set the port security mode to userLoginWithOUI.

[Switch-GigabitEthernet1/0/1] port-security port-mode userlogin-withoui
After completing the above configurations, you can use the following command to view the
configuration information of the RADIUS scheme named radsun:
<Switch> display radius scheme radsun
SchemeName : radsun
Index : 1 Type : standard
Primary Auth IP : 192.168.1.2 Port : 1812 State : active
Primary Acct IP : 192.168.1.3 Port : 1813 State : active
Second Auth IP : 192.168.1.3 Port : 1812 State : active
Second Acct IP : 192.168.1.2 Port :1813 State : active
Auth Server Encryption Key : name
Acct Server Encryption Key : money
Interval for timeout(second) : 5
Retransmission times for timeout : 5
Interval for realtime accounting(minute) : 15
Retransmission times of realtime-accounting packet : 5
Retransmission times of stop-accounting packet : 500
Quiet-interval(min) : 5
Username format : without-domain
Data flow unit : Byte
Packet unit : one
Use the following command to view the configuration information of the ISP domain named sun:
<Switch> display domain sun
Domain = sun
State = Active
Access-limit = 30
Accounting method = Required
Default authentication scheme : radius=radsun
Default authorization scheme : radius=radsun
Default accounting scheme : radius=radsun
Domain User Template:
Idle-cut = Disabled
Self-service = Disabled
Use the following command to view the port security configuration information:
Trap is disabled
OUI value:
Index is 1, OUI value is 123401
6-15

Port mode is userLoginWithOUI
NeedToKnow mode is disabled
Intrusion Protection mode is NoAction
Max MAC address number is not configured
After an 802.1X user gets online, you can see that the number of secure MAC addresses stored is 1.
You can also use the following command to view information about 802.1X users:
<Switch> display dot1x interface gigabitethernet 1/0/1
Equipment 802.1X protocol is enabled
CHAP authentication is enabled
EAD quick deploy is disabled
Configuration: Transmit Period 30 s, Handshake Period 15 s

Quiet Period 60 s, Quiet Period Timer is disabled
Supp Timeout 30 s, Server Timeout 100 s
The maximal retransmitting times 2
EAD quick deploy configuration:
EAD timeout: 30m
The maximum 802.1X user resource number is 1024 per slot

Total current used 802.1X resource number is 1
802.1X protocol is enabled
Handshake is enabled
The port is an authenticator
Authentication Mode is Auto
Port Control Type is Mac-based
802.1X Multicast-trigger is enabled
Mandatory authentication domain: NOT configured
Guest VLAN: NOT configured
Max number of on-line users is 256
EAPOL Packet: Tx 16331, Rx 102

Sent EAP Request/Identity Packets : 16316
EAP Request/Challenge Packets: 6
EAP Success Packets: 4, Fail Packets: 5
Received EAPOL Start Packets : 6
EAPOL LogOff Packets: 2
EAP Response/Identity Packets : 80
EAP Response/Challenge Packets: 6
Error Packets: 0
1. Authenticated user : MAC address: 0002-0000-0011
6-16

Controlled User(s) amount to 1
In addition, the port allows an additional user whose MAC address has an OUI among the specified
OUIs to access the port. You can use the following command to view the related information:
<Switch> display mac-address interface gigabitethernet 1/0/1
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
1234-0300-0011 1 Learned GigabitEthernet1/0/1 AGING
--- 1 mac address(es) found ---
Configuring the macAddressElseUserLoginSecure Mode
The client is connected to the switch through GigabitEthernet 1/0/1. The switch authenticates the client
by the RADIUS server. If the authentication succeeds, the client is authorized to access the Internet.
z Allow more than one MAC authenticated user to log on.
z For 802.1X users, perform MAC authentication first and then, if MAC authentication fails, 802.1X
authentication. Allow only one 802.1X user to log on.
z Set fixed username and password for MAC-based authentication. Set the total number of MAC
authenticated users and 802.1X-authenticated users to 64.
z Enable NTK to prevent frames from being sent to unknown MAC addresses.
See Figure 6-2.
z Configurations on the host and RADIUS servers are omitted.
1) Configure the RADIUS protocol

The required RADIUS authentication/accounting configurations are the same as those in Configuring
the userLoginWithOUI Mode.
# Configure a MAC authentication user, setting the user name and password to aaa and 123456
respectively.
[Switch] mac-authentication user-name-format fixed account aaa password simple 123456
# Set the 802.1X authentication method to CHAP. (This configuration is optional. By default, the
authentication method is CHAP for 802.1X.)
6-17

[Switch] dot1x authentication-method chap
# Set the maximum number of secure MAC addresses allowed on the port to 64.
# Set the port security mode to macAddressElseUserLoginSecure.

[Switch-GigabitEthernet1/0/1] port-security port-mode mac-else-userlogin-secure
# Set the NTK mode of the port to ntkonly.

[Switch-GigabitEthernet1/0/1] port-security ntk-mode ntkonly
After completing the above configurations, you can use the following command to view the port
security configuration information:
Trap is disabled
OUI value:
Port mode is macAddressElseUserLoginSecure
NeedToKnow mode is NeedToKnowOnly
Intrusion Protection mode is NoAction
Max MAC address number is 64
Use the following command to view MAC authentication information:

<Switch> display mac-authentication interface gigabitethernet 1/0/1
1234-0300-0011 MAC_AUTHENTICATOR_SUCCESS 13
Use the following command to view 802.1X authentication information:

<Switch> display dot1x interface gigabitethernet 1/0/1
Equipment 802.1X protocol is enabled
CHAP authentication is enabled
EAD quick deploy is disabled
Configuration: Transmit Period 30 s, Handshake Period 15 s

Quiet Period 60 s, Quiet Period Timer is disabled
Supp Timeout 30 s, Server Timeout 100 s
6-18

The maximal retransmitting times 2
EAD quick deploy configuration:
EAD timeout: 30m
Total maximum 802.1X user resource number is 1024 per slot

Total current used 802.1X resource number is 1
802.1X protocol is enabled
Handshake is enabled
The port is an authenticator
Authentication Mode is Auto
Port Control Type is Mac-based
802.1X Multicast-trigger is enabled
Mandatory authentication domain: NOT configured
Guest VLAN: NOT configured
Max number of on-line users is 256
EAPOL Packet: Tx 16331, Rx 102

Sent EAP Request/Identity Packets : 16316
EAP Request/Challenge Packets: 6
EAP Success Packets: 4, Fail Packets: 5
Received EAPOL Start Packets : 6
EAPOL LogOff Packets: 2
EAP Response/Identity Packets : 80
EAP Response/Challenge Packets: 6
Error Packets: 0
1. Authenticated user : MAC address: 0002-0000-0011
Controlled User(s) amount to 1
In addition, as NTK is enabled, frames with unknown destination MAC addresses, multicast addresses,
and broadcast addresses should be discarded.
Troubleshooting Port Security

Cannot Set the Port Security Mode
Symptom
Cannot set the port security mode.

Error:When we change port-mode, we should first change it to noRestrictions, then change
it to the other.
Analysis
For a port working in a port security mode other than noRestrictions, you cannot change the port
security mode by using the port-security port-mode command directly.
6-19

Solution
Set the port security mode to noRestrictions first.

[Switch-GigabitEthernet1/0/1] undo port-security port-mode
Cannot Configure Secure MAC Addresses
Symptom
Cannot configure secure MAC addresses.

[Switch-GigabitEthernet1/0/1] port-security mac-address security 1-1-2 vlan 1
Error:Can not operate security MAC address for current port mode is not autoLearn!
Analysis
No secure MAC address can be configured on a port operating in a port security mode other than
autoLearn.
Solution
Set the port security mode to autoLearn.

[Switch-GigabitEthernet1/0/1] port-security mac-address security 1-1-2 vlan 1
Cannot Change Port Security Mode When a User Is Online
Symptom
Port security mode cannot be changed when an 802.1X-authenticated or MAC authenticated user is
online.
Error:Cannot configure port-security for there is 802.1X user(s) on line on port
GigabitEthernet1/0/1.
Analysis
Changing port security mode is not allowed when an 802.1X-authenticated or MAC authenticated user
is online.
Solution
Use the cut command to forcibly disconnect the user from the port before changing the port security
mode.
[Switch] cut connection interface gigabitethernet 1/0/1
6-20

7 IP Source Guard Configuration
When configuring IP Source Guard, go to these sections for information you are interested in:
z IP Source Guard Overview
z Configuring a Static Binding Entry
z Configuring Dynamic Binding Function
z Displaying and Maintaining IP Source Guard
z IP Source Guard Configuration Examples
z Troubleshooting IP Source Guard
IP Source Guard Overview

By filtering packets on a per-port basis, IP source guard prevents illegal packets from traveling through,
thus improving the network security. After receiving a packet, the port looks up the key attributes
(including IP address, MAC address and VLAN tag) of the packet in the binding entries of the IP source
guard. If there is a match, the port forwards the packet. Otherwise, the port discards the packet.
IP source guard filters packets based on the following types of binding entries:
z IP-port binding entry
z MAC-port binding entry
z IP-MAC-port binding entry
z IP-VLAN-port binding entry
z MAC-VLAN-port binding entry
z IP-MAC-VLAN-port binding entry
You can manually set static binding entries, or use DHCP snooping or DHCP relay to provide dynamic
binding entries. Binding is on a per-port basis. After a binding entry is configured on a port, it is
effective only to the port.
Enabling IP source guard on a port is mutually exclusive with adding the port to an aggregation group.
Configuring a Static Binding Entry

Follow these steps to configure a static binding entry:

interface-number
7-1

user-bind { ip-address ip-address |
Required
Configure a static binding entry ip-address ip-address mac-address
No static binding entry
mac-address | mac-address
exists by default.
mac-address } [ vlan vlan-id ]
z The system does not support repeatedly binding a binding entry to one port.
z For products supporting multi-port binding, a binding entry can be configured to multiple ports; for
products that do not support multi-port binding, a binding entry can be configured to only one port.
z Supported binding entry types vary by device.
z In a valid binding entry, the MAC address cannot be all 0s, all Fs (a broadcast address), or a
multicast address, and the IP address can only be a Class A, Class B, or Class C address and can
be neither 127.x.x.x nor 0.0.0.0.
z A static binding entry can be configured on only Layer-2 Ethernet ports.
Configuring Dynamic Binding Function

After the dynamic binding function is enabled on a port, IP source guard will receive and process
corresponding DHCP snooping or DHCP relay entries, which contain such information as MAC
address, IP address, VLAN tag, port information or entry type. It adds the obtained information to the
dynamic binding entries to enable the port to filter packets according to the binding entries.
Follow these steps to configure port filtering:

interface-number
ip check source { ip-address Required
Configure dynamic binding
| ip-address mac-address |
function Not configured by default
mac-address }
z The dynamic binding function can be configured on Layer-2 Ethernet ports and VLAN interfaces.
z A port takes only the latest dynamic binding entries configured on it.
7-2

Displaying and Maintaining IP Source Guard
display user-bind [ interface
Display information about static interface-type interface-number | Available in any
binding entries ip-address ip-address | mac-address view
mac-address ]
display ip check source [ interface
Display information about interface-type interface-number | Available in any
dynamic binding entries ip-address ip-address | mac-address view
mac-address ]
IP Source Guard Configuration Examples

Static Binding Entry Configuration Example
As shown in Figure 7-1, Host A and Host B are connected to ports GigabitEthernet 1/0/2 and
GigabitEthernet 1/0/1 of Switch B respectively, Host C is connected to port GigabitEthernet 1/0/2 of
Switch A, and Switch B is connected to port GigabitEthernet 1/0/1 of Switch A.
Configure static binding entries on Switch A and Switch B to meet the following requirements:
z On port GigabitEthernet 1/0/2 of Switch A, only IP packets from Host C can pass.
z On port GigabitEthernet 1/0/1 of Switch A, only IP packets from Host A can pass.
z On port GigabitEthernet 1/0/2 of Switch B, only IP packets from Host A can pass.
z On port GigabitEthernet 1/0/1 of Switch B, only IP packets from Host B can pass.
Network diagram
Figure 7-1 Network diagram for configuring static binding entries
GE1/0/1 GE1/0/2
Switch A
GE1/0/2 GE1/0/1
Switch B
Host C
IP: 192.168.0.3/24
MAC : 00-01-02-03-04-05
Host A Host B
IP: 192.168.0.1/24 IP: 192.168.0.2/24
MAC: 00-01-02-03-04-06 MAC: 00-01-02-03-04-07
# Configure port GigabitEthernet 1/0/2 of Switch A to allow only IP packets with the source MAC
address of 00-01-02-03-04-05 and the source IP address of 192.168.0.3 to pass.
7-3

[SwitchA-GigabitEthernet1/0/2] user-bind ip-address 192.168.0.3 mac-address 0001-0203-0405
# Configure port GigabitEthernet 1/0/1 of Switch A to allow only IP packets with the source MAC
[SwitchA-GigabitEthernet1/0/1] user-bind ip-address 192.168.0.1 mac-address 0001-0203-0406
# Configure port GigabitEthernet 1/0/2 of Switch B to allow only IP packets with the source MAC
# Configure port GigabitEthernet 1/0/1 of Switch B to allow only IP packets with the source MAC
# On Switch A, static binding entries are configured successfully.
<SwitchA> display user-bind
Total entries found: 2
MAC IP Vlan Port Status
0001-0203-0405 192.168.0.3 N/A GigabitEthernet1/0/2 Static
# On Switch B, static binding entries are configured successfully.

<SwitchB> display user-bind
Dynamic Binding Function Configuration Example
Switch A connects to Client A and the DHCP server through ports GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2 respectively. DHCP snooping is enabled on Switch A.
Detailed requirements are as follows:
z Client A (with the MAC address of 00-01-02-03-04-06) obtains an IP address through the DHCP
server.
z On Switch A, create a DHCP snooping entry for Client A.
z On port GigabitEthernet 1/0/1 of Switch A, enable dynamic binding function to prevent attackers
from using forged IP addresses to attack the server.
7-4

For detailed configuration of a DHCP server, refer to DHCP Configuration in the IP Service Volume.
Network diagram
Figure 7-2 Network diagram for configuring dynamic binding function
# Configure dynamic binding function on port GigabitEthernet 1/0/1.
[SwitchA] interface gigabitethernet1/0/1
[SwitchA-GigabitEthernet1/0/1] ip check source ip-address mac-address

[SwitchA] dhcp-snooping
# Configure the port connecting to the DHCP server as a trusted port.

[SwitchA-GigabitEthernet1/0/2] dhcp-snooping trust
# Display dynamic binding function is configured successfully on port GigabitEthernet 1/0/1.
[SwitchA-GigabitEthernet1/0/1] display this
#
interface GigabitEthernet1/0/1
ip check source ip-address mac-address
#
return
# Display the dynamic binding entries that port GigabitEthernet 1/0/1 has obtained from DHCP
snooping.
[SwitchA-GigabitEthernet1/0/1] display ip check source
0001-0203-0406 192.168.0.1 1 GigabitEthernet 1/0/1 DHCP-SNP
# Display the dynamic entries of DHCP snooping and check it is identical with the dynamic entries that
port GigabitEthernet 1/0/1 has obtained.
7-5

[SwitchA-GigabitEthernet1/0/1] display dhcp-snooping
DHCP Snooping is enabled.
The client binding table for all untrusted ports.
Type : D--Dynamic , S--Static
Type IP Address MAC Address Lease VLAN Interface
==== =============== ============== ============ ==== =================
D 192.168.0.1 0001-0203-0406 86335 1 GigabitEthernet1/0/1
As you see, port GigabitEthernet 1/0/1 has obtained the dynamic entries generated by DHCP snooping
after it is configured with dynamic binding function.
Troubleshooting IP Source Guard

Failed to Configure Static Binding Entries and Dynamic Binding Function
Symptom
Configuring static binding entries and dynamic binding function fails on a port.
Analysis
IP Source Guard is not supported on the port which has joined an aggregation group. Neither static
binding entries nor dynamic binding function can be configured on the port which has joined an
aggregation group.
Solution
Remove the port from the aggregation group.
7-6

8 SSH2.0 Configuration
When configuring SSH2.0, go to these sections for information you are interested in:
z SSH2.0 Overview
z Configuring the Device as an SSH Server
z Configuring the Device as an SSH Client
z Displaying and Maintaining SSH
z SSH Server Configuration Examples
z SSH Client Configuration Examples
SSH2.0 Overview
Introduction to SSH2.0
Secure Shell (SSH) offers an approach to securely logging into a remote device. By encryption and
strong authentication, it protects devices against attacks such as IP spoofing and plain text password
interception.
The device can not only work as an SSH server to support connections with SSH clients, but also work
as an SSH client to allow users to establish SSH connections with a remote device acting as the SSH
server.
Currently, when acting as an SSH server, the device supports two SSH versions: SSH2.0 and SSH1.
When acting as an SSH client, the device supports SSH2.0 only.
Operation of SSH
The session establishment and interaction between an SSH client and the SSH server involves the
following five stages:
Table 8-1 Stages in session establishment and interaction between an SSH client and the server
Stages Description
SSH1 and SSH2.0 are supported. The two parties negotiate a
Version negotiation
version to use.
SSH supports multiple algorithms. The two parties negotiate an
Key and algorithm negotiation
algorithm for communication.
The SSH server authenticates the client in response to the
Authentication
clients authentication request.
8-1

Stages Description
After passing authentication, the client sends a session request
Session request
to the server.
After the server grants the request, the client and server start to
Interaction
communicate with each other.
Version negotiation
1) The server opens port 22 to listen to connection requests from clients.

2) The client sends a TCP connection request to the server. After the TCP connection is established,
the server sends the first packet to the client, which includes a version identification string in the
format of SSH-<primary protocol version number>.<secondary protocol version
number>-<software version number>. The primary and secondary protocol version numbers
constitute the protocol version number, while the software version number is used for debugging.
3) The client receives and resolves the packet. If the protocol version of the server is lower but
supportable, the client uses the protocol version of the server; otherwise, the client uses its own
protocol version.
4) The client sends to the server a packet that contains the number of the protocol version it decides
to use. The server compares the version carried in the packet with that of its own. If the server
supports the version, the server and client will use the version. Otherwise, the negotiation fails.
5) If the negotiation is successful, the server and the client proceed with key and algorithm
negotiation; otherwise, the server breaks the TCP connection.
All the packets involved in the above steps are transferred in plain text.
Key and algorithm negotiation
z The server and the client send key algorithm negotiation packets to each other, which include the
supported public key algorithm list, encryption algorithm list, Message Authentication Code (MAC)
algorithm list, and compression algorithm list.
z Based on the received algorithm negotiation packets, the server and the client figure out the
algorithms to be used. If the negotiation of any type of algorithm fails, the algorithm negotiation
fails and the server tears down the connection with the client.
z The server and the client use the DH key exchange algorithm and parameters such as the host
key pair to generate the session key and session ID and the client authenticates the identity of the
server.
Through the above steps, the server and client get the same session key and session ID. The session
key will be used to encrypt and decrypt data exchanged between the server and client later, and the
session ID will be used to identify the session established between the server and client and will be
used in the authentication stage.
8-2

Before the negotiation, the server must have already generated a DSA or RSA key pair, which is not
only used for generating the session key, but also used by the client to authenticate the identity of the
server. For details about DSA and RSA key pairs, refer to Public Key Configuration in the Security
Volume.
Authentication
SSH provides two authentication methods: password authentication and publickey authentication.
z Password authentication: The server uses AAA for authentication of the client. During password
authentication, the client encrypts its username and password, encapsulates them into a
password authentication request, and sends the request to the server. Upon receiving the request,
the server decrypts the username and password, checks the validity of the username and
password locally or by a remote AAA server, and then informs the client of the authentication
result.
z Publickey authentication: The server authenticates the client by the digital signature. During
publickey authentication, the client sends to the server a publickey authentication request that
contains its username, public key, and publickey algorithm information. The server checks
whether the public key is valid. If the public key is invalid, the authentication fails; otherwise, the
server authenticates the client by the digital signature. Finally, the server sends a message to the
client to inform the success or failure of the authentication. Currently, the device supports two
publickey algorithms for digital signature: RSA and DSA.
The following gives the steps of the authentication stage:
1) The client sends to the server an authentication request, which includes the username,
authentication method (password authentication or publickey authentication), and information
related to the authentication method (for example, the password in the case of password
authentication).
2) The server authenticates the client. If the authentication fails, the server informs the client by
sending a message, which includes a list of available methods for re-authentication.
3) The client selects a method from the list to initiate another authentication.
4) The above process repeats until the authentication succeeds or the failed authentication times
exceed the maximum of authentication attempts and the session is torn down.
Besides password authentication and publickey authentication, SSH2.0 provides another two
authentication methods:
z password-publickey: Performs both password authentication and publickey authentication if the
client is using SSH2.0 and performs either if the client is running SSH1.
z any: Performs either password authentication or publickey authentication.
8-3

Session request
After passing authentication, the client sends a session request to the server, while the server listens to
and processes the request from the client. After successfully processing the request, the server sends
back to the client an SSH_SMSG_SUCCESS packet and goes on to the interactive session stage with
the client. Otherwise, the server sends back to the client an SSH_SMSG_FAILURE packet, indicating
that the processing fails or it cannot resolve the request.
Interaction
In this stage, the server and the client exchanges data in the following way:
z The client encrypts and sends the command to be executed to the server.
z The server decrypts and executes the command, and then encrypts and sends the result to the
client.
z The client decrypts and displays the result on the terminal.
z In the interaction stage, you can execute commands from the client by pasting the commands in
text format (the text must be within 2000 bytes). It is recommended that the commands are in the
same view; otherwise, the server may not be able to perform the commands correctly.
z If the command text exceeds 2000 bytes, you can execute the commands by saving the text as a
configuration file, uploading the configuration file to the server through SFTP, and then using the
configuration file to restart the server.
Configuring the Device as an SSH Server

SSH Server Configuration Task List
Complete the following tasks to configure an SSH server:
Task Remarks
Generating a DSA or RSA Key Pair Required
Enabling SSH Server Required

Configuring the User Interfaces for SSH Clients Required
Required for publickey authentication users and
Configuring a Client Public Key
optional for password authentication users
Configuring an SSH User Optional
Setting the SSH Management Parameters Optional
Generating a DSA or RSA Key Pair
The DSA or RSA key pair will be used to generate the session ID in the key and algorithm negotiation
stage and used by the client to authenticate the server.
Follow these steps to generate a DSA or RSA key pair on the SSH server:
8-4

Required
Generate the local DSA or public-key local create { dsa |
RSA key pair rsa } By default, there is neither DSA
key pair nor RSA key pair.
z For details about the public-key local create command, refer to Public Key Commands in the
Security Volume.
z To ensure that all SSH clients can log into the SSH server successfully, you are recommended to
generate both DSA and RSA key pairs on the SSH server. This is because different SSH clients
may use different publickey algorithms, though a single client usually uses only one type of
publickey algorithm.
z The public-key local create rsa command generates two RSA key pairs: a server key pair and a
host key pair. Each of the key pairs consists of a public key and a private key. The public key in
the server key pair of the SSH server is used in SSH1 to encrypt the session key for secure
transmission of the key. As SSH2 uses the DH algorithm to generate the session key on the SSH
server and client respectively, no session key transmission is required in SSH2 and the server key
pair is not used.
z The length of the modulus of RSA server keys and host keys must be in the range 512 to 2048 bits.
Some SSH2 clients require that the length of the key modulus be at least 768 bits on the SSH
server side.
z The public-key local create dsa command generates only the host key pair. SSH1 does not
support the DSA algorithm.
z The length of the modulus of DSA host keys must be in the range 512 to 2048 bits. Some SSH2
clients require that the length of the key modulus be at least 768 bits on the SSH server side.
Enabling SSH Server
Follow these steps to enable SSH server:

Required
Enable the SSH server function ssh server enable
Disabled by default
Configuring the User Interfaces for SSH Clients
An SSH client accesses the device through a VTY user interface. Therefore, you need to configure the
user interfaces for SSH clients to allow SSH login. Note that the configuration takes effect only for
clients logging in after the configuration.
Follow these steps to configure the protocols for the current user interface to support:
8-5

Enter user interface view of user-interface vty number

one or more user interfaces [ ending-number ]
Required
Set the login authentication authentication-mode scheme
mode to scheme [ command-authorization ] By default, the authentication
mode is password.
Optional
Configure the user interface(s)
protocol inbound { all | ssh } All protocols are supported by
to support SSH login
default.
z For detailed information about the authentication-mode and protocol inbound commands, refer
to User Interface Commands of the System Volume.
z If you configure a user interface to support SSH, be sure to configure the corresponding
authentication method with the authentication-mode scheme command.
z For a user interface configured to support SSH, you cannot change the authentication mode. To
change the authentication mode, undo the SSH support configuration first.
Configuring a Client Public Key
This configuration task is only necessary for SSH users using publickey authentication.
For each SSH user that uses publickey authentication to login, you must configure the clients DSA or
RSA host public key on the server, and configure the client to use the corresponding private key.
To configure the public key of an SSH client, you can:
z Configure it manually: You can input or copy the public key to the local host. The copied public key
must have not been converted and be in the distinguished encoding rules (DER) encoding format.
z Import it from the public key file: During the import process, the system will automatically convert
the public key to a string coded using the Public Key Cryptography Standards (PKCS). Before
importing the public key, you must upload the public key file (in binary) to the local host through
FTP or TFTP.
8-6

z You are recommended to configure a client public key by importing it from a public key file.
z You can configure at most 20 client pubic keys on an SSH server.
Configuring a client public key manually
Follow these steps to configure the client public key manually:

Enter public key view public-key peer keyname

Enter public key code view public-key-code begin
Required
Enter the content of the public Spaces and carriage returns
Configure a client public key
key are allowed between
characters.

Return from public key code When you exit public key code
public-key-code end
view to public key view view, the system automatically
saves the public key.
Return from public key view to
peer-public-key end
system view
Importing a client public key from a public key file
Follow these steps to import a public key from a public key file:

Import the public key from a public-key peer keyname

Required
public key file import sshkey filename
For information about client side public key configuration and the relevant commands, refer to Public
Key Configuration in the Security Volume.
Configuring an SSH User
This configuration allows you to create an SSH user and specify the service type and authentication
mode.
Follow these steps to configure an SSH user and specify the service type and authentication mode:
8-7

ssh user username service-type stelnet

Create an For Stelnet authentication-type { password | { any |
SSH user, users password-publickey | publickey } assign
and specify publickey keyname } Required
the service ssh user username service-type { all | sftp } Use either
type and authentication-type { password | { any | command.
authentication For all users
password-publickey | publickey } assign
mode or SFTP users
publickey keyname work-directory
directory-name }
z A user without an SSH account can still pass password authentication and log into the server
through Stelnet or SFTP, as long as the user can pass AAA authentication and the service type is
SSH.
z An SSH server supports up to 1024 SSH users.
z The service type of an SSH user can be Stelnet (Secure Telnet) or SFTP (Secure FTP). For
information about Stelnet, refer to SSH2.0 Overview. For information about SFTP, refer to SFTP
Overview.
z For successful login through SFTP, you must set the user service type to sftp or all.
z As SSH1 does not support service type sftp, if the client uses SSH1 to log into the server, you
must set the service type to stelnet or all on the server. Otherwise, the client will fail to log in.
z The working folder of an SFTP user is subject to the user authentication method. For a user using
only password authentication, the working folder is the AAA authorized one. For a user using only
publickey authentication or using both the publickey and password authentication methods, the
working folder is the one set by using the ssh user command.
z The configured authentication method takes effect only for users logging in after the configuration.
For users using publickey authentication:

z You must configure on the device the corresponding username and public keys.
z After login, the commands available for a user are determined by the user privilege level, which is
configured with the user privilege level command on the user interface.
For users using password authentication:
z You can configure the accounting information either on the device or on the remote authentication
server (such as RADIUS authentication server).
z After login, the commands available to a user are determined by AAA authorization.
Setting the SSH Management Parameters
SSH management includes:
8-8

z Enabling the SSH server to be compatible with SSH1 client
z Setting the server key pair update interval, applicable to users using SSH1 client
z Setting the SSH user authentication timeout period
z Setting the maximum number of SSH authentication attempts
Setting the above parameters can help avoid malicious guess at and cracking of the keys and
usernames, securing your SSH connections.
Follow these steps to set the SSH management parameters:

Optional
Enable the SSH server to work ssh server compatible-ssh1x
with SSH1 clients enable By default, the SSH server can
work with SSH1 clients.
Optional
Set the RSA server key pair ssh server rekey-interval
update interval hours 0 by default, that is, the RSA
server key pair is not updated.
ssh server Optional
Set the SSH user
authentication-timeout
authentication timeout period 60 seconds by default
time-out-value
Set the maximum number of ssh server Optional

SSH authentication attempts authentication-retries times 3 by default
Authentication will fail if the number of authentication attempts (including both publickey and password
authentication) exceeds that specified in the ssh server authentication-retries command.
Configuring the Device as an SSH Client

SSH Client Configuration Task List
Complete the following tasks to configure an SSH client:
Task Remarks
Specifying a Source IP address/Interface for the SSH client Optional
Configuring Whether First-time Authentication is Supported Optional
Establishing a Connection Between the SSH Client and the Server Required
Specifying a Source IP address/Interface for the SSH client
This configuration task allows you to specify a source IP address or interface for the client to access
the SSH server, improving service manageability.
8-9

Specify a source
ssh client source { ip ip-address | Required
Specify a IPv4 address or
source IP interface for the By default, the
interface-number }
address or SSH client address of the
interface for interface decided
Specify a source by the routing is
the SSH ssh client ipv6 source { ipv6
IPv6 address or used to access
client ipv6-address | interface interface-type
interface for the the SSH server
interface-number }
SSH client
Configuring Whether First-time Authentication is Supported
When the device connects to the SSH server as an SSH client, you can configure whether the device
supports first-time authentication.
z With first-time authentication, when an SSH client not configured with the server host public key
accesses the server for the first time, the user can continue accessing the server, and save the
host public key on the client. When accessing the server again, the client will use the saved server
host public key to authenticate the server.
z Without first-time authentication, a client not configured with the server host public key will deny to
access the server. To access the server, a user must configure in advance the server host public
key locally and specify the public key name for authentication.
Enable the device to support first-time authentication
Follow these steps to enable the device to support first-time authentication:

Optional
Enable the device to support ssh client first-time
first-time authentication enable By default, first-time authentication
is supported on a client.
Disable first-time authentication
For successful authentication of an SSH client not supporting first-time authentication, the server host
public key must be configured on the client and the public key name must be specified.
Follow these steps to disable first-time authentication:

Optional
Disable first-time By default, first-time
undo ssh client first-time
authentication support authentication is supported on
a client.
8-10

Required
Refer to Configuring a Client The method of configuring
Configure the server public key server public key on the client
Public Key
is similar to that of configuring
client public key on the server.
ssh client authentication
Specify the host public key
server server assign Required
name of the server
publickey keyname
Establishing a Connection Between the SSH Client and the Server
Follow these steps to establish the connection between the SSH client and the server:

ssh2 server [ port-number ] [ identity-key { dsa
| rsa } | prefer-ctos-cipher { aes128 | des } |
Establish a prefer-ctos-hmac { md5 | md5-96 | sha1 |
connection For an
sha1-96 } | prefer-kex { dh-group-exchange |
between the SSH IPv4
dh-group1 | dh-group14 } |
client and server, server
prefer-stoc-cipher { aes128 | des } |
and specify the prefer-stoc-hmac { md5 | md5-96 | sha1 | Required
public key sha1-96 } ] *
algorithm, preferred Use either
encryption ssh2 ipv6 server [ port-number ] [ identity-key command in
algorithms, { dsa | rsa } | prefer-ctos-cipher { aes128 | user view.
preferred HMAC des } | prefer-ctos-hmac { md5 | md5-96 |
For an
algorithms and sha1 | sha1-96 } | prefer-kex
IPv4 IPv6
preferred key { dh-group-exchange | dh-group1 |
server
exchange algorithm dh-group14 } | prefer-stoc-cipher { aes128 |
des } | prefer-stoc-hmac { md5 | md5-96 |
sha1 | sha1-96 } ] *
Displaying and Maintaining SSH

Display the source IP address
or interface currently set for the display sftp client source Available in any view
SFTP client
Display the source IP address
or interface currently set for the display ssh client source Available in any view
SSH client
Display SSH server status
display ssh server { status |
information or session Available in any view
session }
information on an SSH server
Display the mappings between
SSH servers and their host
display ssh server-info Available in any view
public keys saved on an SSH
client
display ssh user-information
specified or all SSH users on Available in any view
[ username ]
the SSH server
8-11

Display the public keys of the display public-key local { dsa
local key pairs | rsa } public
Display the public keys of the display public-key peer
SSH peers [ brief | name publickey-name ]
For information about the display public-key local and display public-key peer commands, refer to
Public Key Commands in the Security Volume.
SSH Server Configuration Examples

When Switch Acts as Server for Password Authentication
z As shown in Figure 8-1, a local SSH connection is established between the host (the SSH client)
and the switch (the SSH server) for secure data exchange.
z Password authentication is required. The username and password are saved on the switch.
Figure 8-1 Switch acts as server for password authentication
1) Configure the SSH server

# Configure an IP address for VLAN interface 1. This address will serve as the destination of the SSH
connection.
# Set the authentication mode for the user interfaces to AAA.

# Enable the user interfaces to support SSH.
8-12

# Create local user client001, and set the user command privilege level to 3
[Switch] local-user client001
[Switch-luser-client001] password simple aabbcc
[Switch-luser-client001] service-type ssh
[Switch-luser-client001] authorization-attribute level 3
[Switch-luser-client001] quit
# Specify the service type for user client001 as Stelnet, and the authentication mode as password.
This step is optional.
[Switch] ssh user client001 service-type stelnet authentication-type password
2) Configure the SSH client
There are many kinds of SSH client software, such as PuTTY, and OpenSSH. The following is an
example of configuring SSH client using Putty Version 0.58.
# Establish a connection with the SSH server

Launch PuTTY.exe to enter the following interface. In the Host Name (or IP address) text box, enter
the IP address of the server (192.168.1.40).
8-13

Figure 8-2 SSH client configuration interface
In the window shown in Figure 8-2, click Open. If the connection is normal, you will be prompted to
enter the username and password. After entering the correct username (client001) and password
(aabbcc), you can enter the configuration interface.
When Switch Acts as Server for Publickey Authentication
z As shown in Figure 8-3, a local SSH connection is established between the host (the SSH client)
and the switch (the SSH server) for secure data exchange.
z Publickey authentication is used, the algorithm is RSA.
Figure 8-3 Switch acts as server for publickey authentication
SSH client SSH server

Vlan-int1
192.168.1.56/24 192.168.1.40/24
Host Switch

# Generate RSA and DSA key pairs and enable SSH server.
8-14

# Configure an IP address for VLAN interface 1. This address will serve as the destination of the SSH
connection.


# Set the user command privilege level to 3.

[Switch-ui-vty0-4] user privilege level 3
Before performing the following tasks, you must use the client software to generate an RSA key pair on
the client, save the public key in a file named key.pub, and then upload the file to the SSH server
through FTP or TFTP. For details, refer to Configure the SSH client below.
# Import the clients public key from file key.pub and name it Switch001.
[Switch] public-key peer Switch001 import sshkey key.pub
# Specify the authentication type for user client002 as publickey, and assign the public key Switch001
to the user.
[Switch] ssh user client002 service-type stelnet authentication-type publickey assign
publickey Switch001
# Generate an RSA key pair.
Run PuTTYGen.exe, select SSH-2 RSA and click Generate.
8-15

Figure 8-4 Generate a client key pair 1)
While generating the key pair, you must move the mouse continuously and keep the mouse off the
green process bar shown in Figure 8-5. Otherwise, the process bar stops moving and the key pair
generating process will be stopped.
8-16

After the key pair is generated, click Save public key and specify the file name as key.pub to save the
public key.
8-17

Likewise, to save the private key, click Save private key. A warning window pops up to prompt you
whether to save the private key without any protection. Click Yes and enter the name of the file for
saving the key (private in this case).
After generating a key pair on a client, you need to transmit the saved public key file to the server
through FTP or TFTP and have the configuration on the server done before continuing configuration of
the client.
# Specify the private key file and establish a connection with the SSH server
Launch PuTTY.exe to enter the following interface. In the Host Name (or IP address) text box, enter
the IP address of the server (192.168.1.40).
Figure 8-8 SSH client configuration interface 1)
8-18

Select Connection/SSH/Auth from the navigation tree. The following window appears. Click
Browse to bring up the file selection window, navigate to the private key file and click OK.
Figure 8-9 SSH client configuration interface 2)
In the window shown in Figure 8-9, click Open. If the connection is normal, you will be prompted to
enter the username. After entering the correct username (client002), you can enter the configuration
interface.
SSH Client Configuration Examples

When Switch Acts as Client for Password Authentication
z As shown in Figure 8-10, Switch A (the SSH client) needs to log into Switch B (the SSH server)
through the SSH protocol.
z The username of the SSH client is client001 and the password is aabbcc. Password
authentication is required.
Figure 8-10 Switch acts as client for password authentication
8-19

# Create RSA and DSA key pairs and enable the SSH server.
[SwitchB] public-key local create rsa
[SwitchB] public-key local create dsa
[SwitchB] ssh server enable
# Create an IP address for VLAN interface 1, which the SSH client will use as the destination for SSH
connection.
[SwitchB-Vlan-interface1] ip address 10.165.87.136 255.255.255.0

[SwitchB] user-interface vty 0 4
[SwitchB-ui-vty0-4] authentication-mode scheme

[SwitchB-ui-vty0-4] protocol inbound ssh
[SwitchB-ui-vty0-4] quit
# Create local user client001.

[SwitchB] local-user client001
[SwitchB-luser-client001] password simple aabbcc
[SwitchB-luser-client001] service-type ssh
[SwitchB-luser-client001] authorization-attribute level 3
[SwitchB-luser-client001] quit
# Specify the service type for user client001 as Stelnet, and the authentication type as password.
This step is optional.
[SwitchB] ssh user client001 service-type stelnet authentication-type password
# Configure an IP address for VLAN interface 1.
[SwitchA] quit
z If the client support first-time authentication, you can directly establish a connection from the client
to the server.
# Establish an SSH connection to server 10.165.87.136.
<SwitchA> ssh2 10.165.87.136
Username: client001
Trying 10.165.87.136 ...
Press CTRL+K to abort
Connected to 10.165.87.136 ...
The Server is not authenticated. Continue? [Y/N]:y

Do you want to save the server public key? [Y/N]:n
Enter password:
8-20

After you enter the correct username, you can log into Switch B successfully.
z If the client does not support first-time authentication, you need to perform the following
configurations.
# Disable first-time authentication.
[SwitchA] undo ssh client first-time
# Configure the host public key of the SSH server. You can get the server host public key by using the
display public-key local dsa public command on the server.
[SwitchA] public-key peer key1
[SwitchA-pkey-public-key] public-key-code begin
[SwitchA-pkey-key-code]308201B73082012C06072A8648CE3804013082011F0281810
0D757262C4584C44C211F18BD96E5F0
[SwitchA-pkey-key-code]61C4F0A423F7FE6B6B85B34CEF72CE14A0D3A5222FE08CECE
65BE6C265854889DC1EDBD13EC8B274
[SwitchA-pkey-key-code]DA9F75BA26CCB987723602787E922BA84421F22C3C89CB9B0
6FD60FE01941DDD77FE6B12893DA76E
[SwitchA-pkey-key-code]EBC1D128D97F0678D7722B5341C8506F358214B16A2FAC4B3
68950387811C7DA33021500C773218C
[SwitchA-pkey-key-code]737EC8EE993B4F2DED30F48EDACE915F0281810082269009E
14EC474BAF2932E69D3B1F18517AD95
[SwitchA-pkey-key-code]94184CCDFCEAE96EC4D5EF93133E84B47093C52B20CD35D02
492B3959EC6499625BC4FA5082E22C5
[SwitchA-pkey-key-code]B374E16DD00132CE71B020217091AC717B612391C76C1FB2E
88317C1BD8171D41ECB83E210C03CC9
[SwitchA-pkey-key-code]B32E810561C21621C73D6DAAC028F4B1585DA7F42519718CC
9B09EEF0381840002818000AF995917
[SwitchA-pkey-key-code]E1E570A3F6B1C2411948B3B4FFA256699B3BF871221CC9C5D
F257523777D033BEE77FC378145F2AD
[SwitchA-pkey-key-code]D716D7DB9FCABB4ADBF6FB4FDB0CA25C761B308EF53009F71
01F7C62621216D5A572C379A32AC290
[SwitchA-pkey-key-code]E55B394A217DA38B65B77F0185C8DB8095522D1EF044B465E
8716261214A5A3B493E866991113B2D
[SwitchA-pkey-key-code]485348
[SwitchA-pkey-key-code] public-key-code end
[SwitchA-pkey-public-key] peer-public-key end
# Specify the host public key for the SSH server (10.165.87.136) as key1.
[SwitchA] ssh client authentication server 10.165.87.136 assign publickey key1
[SwitchA] quit
# Establish an SSH connection to server 10.165.87.136.

<SwitchA> ssh2 10.165.87.136
Username: client001
Trying 10.165.87.136
Connected to 10.165.87.136...
Enter password:
After you enter the correct username and password, you can log into Switch B successfully.
8-21

When Switch Acts as Client for Publickey Authentication
z As shown in Figure 8-11, Switch A (the SSH client) needs to log into Switch B (the SSH server)
through the SSH protocol.
z Publickey authentication is used, and the public key algorithm is DSA.
Figure 8-11 Switch acts as client for publickey authentication

# Generate RSA and DSA key pairs and enable SSH server.
# Configure an IP address for VLAN interface 1, which the SSH client will use as the destination for
SSH connection.


# Set the user command privilege level to 3.

[SwitchB-ui-vty0-4] user privilege level 3
Before performing the following tasks, you must use the client software to generate an RSA key pair on
the client, save the public key in a file named key.pub, and then upload the file to the SSH server
through FTP or TFTP. For details, refer to Configure the SSH client below.
# Import the peer public key from the file key.pub.

[SwitchB] public-key peer Switch001 import sshkey key.pub
8-22

# Specify the authentication type for user client002 as publickey, and assign the public key Switch001
to the user.
[SwitchB] ssh user client002 service-type stelnet authentication-type publickey assign
publickey Switch001
# Configure an IP address for Vlan interface 1.
# Generate a DSA key pair.

[SwitchA] public-key local create dsa
# Export the DSA public key to the file key.pub.

[SwitchA] public-key local export dsa ssh2 key.pub
[SwitchA] quit
After generating a key pair on a client, you need to transmit the saved public key file to the server
the client.
# Establish an SSH connection to the server (10.165.87.136).

<SwitchA> ssh2 10.165.87.136
Username: client002
Trying 10.165.87.136 ...
Connected to 10.165.87.136 ...

Later, you will find that you have logged into Switch B successfully.
8-23

9 SFTP Configuration
When configuring SFTP, go to these sections for information you are interested in:
z SFTP Overview
z Configuring an SFTP Server
z Configuring an SFTP Client
z SFTP Client Configuration Example
z SFTP Server Configuration Example
SFTP Overview
The secure file transfer protocol (SFTP) is a new feature in SSH2.0.
SFTP uses the SSH connection to provide secure data transfer. The device can serve as the SFTP
server, allowing a remote user to log into the SFTP server for secure file management and transfer.
The device can also server as an SFTP client, enabling a user to login from the device to a remote
device for secure file transfer.
Configuring an SFTP Server

z You have configured the SSH server. For the detailed configuration procedure, refer to
Configuring the Device as an SSH Server.
z You have used the ssh user service-type command to set the service type of SSH users to sftp or
all. For configuration procedure, refer to Configuring an SSH User.
Enabling the SFTP Server
This configuration task is to enable the SFTP service so that a client can log into the SFTP server
through SFTP.
Follow these steps to enable the SFTP server:

Required
Enable the SFTP server sftp server enable
Disabled by default
9-1

When the device functions as the SFTP server, only one client can access the SFTP server at a time.
If the SFTP client uses WinSCP, a file on the server cannot be modified directly; it can only be
downloaded to a local place, modified, and then uploaded to the server.
Configuring the SFTP Connection Idle Timeout Period
Once the idle period of an SFTP connection exceeds the specified threshold, the system automatically
tears the connection down, so that a user cannot occupy a connection for nothing.
Follow these steps to configure the SFTP connection idle timeout period:

Configure the SFTP sftp server idle-timeout Optional

connection idle timeout period time-out-value 10 minutes by default
Configuring an SFTP Client

Specifying a Source IP Address or Interface for the SFTP Client
You can configure a client to use only a specified source IP address or interface to access the SFTP
server, thus enhancing the service manageability.
Follow these steps to specify a source IP address or interface for the SFTP client:

Specify a
sftp client source { ip
source IPv4
ip-address | interface
Specify a address or Required
interface-type
source IP interface for the Use either command.
interface-number }
address or SFTP client
By default, an SFTP client uses
interface for Specify a the interface address specified
the SFTP source IPv6 sftp client ipv6 source by the route of the device to
client address or { ipv6 ipv6-address | access the SFTP server.
interface for the interface interface-type
SFTP client interface-number }
Establishing a Connection to the SFTP Server
This configuration task is to enable the SFTP client to establish a connection with the remote SFTP
server and enter SFTP client view.
Follow these steps to enable the SFTP client:
9-2

sftp server [ port-number ] [ identity-key
Establish a
{ dsa | rsa } | prefer-ctos-cipher { aes128 |
connection to
des } | prefer-ctos-hmac { md5 | md5-96 |
the remote
sha1 | sha1-96 } | prefer-kex
IPv4 SFTP
{ dh-group-exchange | dh-group1 |
server and
Establish a dh-group14 } | prefer-stoc-cipher
enter SFTP
connection to { aes128 | des } | prefer-stoc-hmac { md5 |
client view Required
the remote md5-96 | sha1 | sha1-96 } ] *
SFTP server Use either
sftp ipv6 server [ port-number ] command in user
and enter Establish a [ identity-key { dsa | rsa } |
SFTP client view.
connection to prefer-ctos-cipher { aes128 | des } |
view the remote prefer-ctos-hmac { md5 | md5-96 | sha1 |
IPv6 SFTP sha1-96 } | prefer-kex
server and { dh-group-exchange | dh-group1 |
enter SFTP dh-group14 } | prefer-stoc-cipher
client view { aes128 | des } | prefer-stoc-hmac { md5 |
md5-96 | sha1 | sha1-96 } ] *
Working with the SFTP Directories
SFTP directory operations include:

z Changing or displaying the current working directory
z Displaying files under a specified directory or the directory information
z Changing the name of a specified directory on the server
z Creating or deleting a directory
Follow these steps to work with the SFTP directories:

sftp [ ipv6 ] server [ port-number ]
[ identity-key { dsa | rsa } |
prefer-ctos-cipher { aes128 | des }
| prefer-ctos-hmac { md5 | Required
md5-96 | sha1 | sha1-96 } |
Enter SFTP client view Execute the command in
prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | user view.
prefer-stoc-cipher { aes128 | des }
| prefer-stoc-hmac { md5 |
md5-96 | sha1 | sha1-96 } ] *
Change the working directory
cd [ remote-path ] Optional
of the remote SFTP server
Return to the upper-level
cdup Optional
directory
Display the current working
directory of the remote SFTP pwd Optional
server
dir [ -a | -l ] [ remote-path ] Optional
Display files under a specified The dir command
directory ls [ -a | -l ] [ remote-path ] functions as the ls
command.
Change the name of a
specified directory on the SFTP rename oldname newname Optional
server
9-3

Create a new directory on the
mkdir remote-path Optional
remote SFTP server
Delete a directory from the
rmdir remote-path&<1-10> Optional
SFTP server
Working with SFTP Files
SFTP file operations include:

z Changing the name of a file
z Downloading a file
z Uploading a file
z Displaying a list of the files
z Deleting a file
Follow these steps to work with SFTP files:

prefer-ctos-cipher { aes128 | des }
| prefer-ctos-hmac { md5 | Required
md5-96 | sha1 | sha1-96 } |
Enter SFTP client view Execute the command in
prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | user view.
prefer-stoc-cipher { aes128 | des }
| prefer-stoc-hmac { md5 |
md5-96 | sha1 | sha1-96 } ] *
Change the name of a
specified file or directory on the rename old-name new-name Optional
SFTP server
Download a file from the
remote server and save it get remote-file [ local-file ] Optional
locally
Upload a local file to the
put local-file [ remote-file ] Optional
remote SFTP server
dir [ -a | -l ] [ remote-path ] Optional

Display the files under a The dir command
specified directory functions as the ls
ls [ -a | -l ] [ remote-path ]
command.
delete remote-file&<1-10> Optional

Delete a file from the SFTP The delete command
server functions as the remove
remove remote-file&<1-10>
command.
Displaying Help Information
This configuration task is to display a list of all commands or the help information of an SFTP client
command, such as the command format and parameters.
9-4

Follow these steps to display a list of all commands or the help information of an SFTP client
command:

prefer-ctos-cipher { aes128 | des } | Required
prefer-ctos-hmac { md5 | md5-96 | sha1 |
Enter SFTP client view sha1-96 } | prefer-kex Execute the
{ dh-group-exchange | dh-group1 | command in user
dh-group14 } | prefer-stoc-cipher { aes128 view.
| des } | prefer-stoc-hmac { md5 | md5-96 |
sha1 | sha1-96 } ] *
Display a list of all commands
or the help information of an help [ all | command-name ] Required
SFTP client command
Terminating the Connection to the Remote SFTP Server
Follow these steps to terminate the connection to the remote SFTP server:

prefer-ctos-cipher { aes128 | des } |
prefer-ctos-hmac { md5 | md5-96 | sha1 Required
Enter SFTP client
| sha1-96 } | prefer-kex Execute the command in user
view
{ dh-group-exchange | dh-group1 | view.
dh-group14 } | prefer-stoc-cipher
{ aes128 | des } | prefer-stoc-hmac
{ md5 | md5-96 | sha1 | sha1-96 } ] *
Terminate the bye Required.
connection to the Use any of the commands.
remote SFTP server exit
and return to user These three commands
view quit function in the same way.
SFTP Client Configuration Example

As shown in Figure 9-1, an SSH connection is established between Switch A and Switch B. Switch A,
an SFTP client, logs in to Switch B for file management and file transfer. An SSH user uses publickey
authentication with the public key algorithm being RSA.
Figure 9-1 Network diagram for SFTP client configuration
9-5

1) Configure the SFTP server (Switch B)

# Enable the SFTP server.

[SwitchB] sftp server enable
# Configure an IP address for VLAN interface 1, which the SSH client uses as the destination for SSH
connection.
# Set the authentication mode on the user interfaces to AAA.

# Set the protocol that a remote user uses to log in as SSH.

Before performing the following tasks, you must generate use the client software to generate RSA key
pairs on the client, save the host public key in a file named pubkey, and then upload the file to the
SSH server through FTP or TFTP. For details, refer to Configure the SFTP client (Switch A) below.
# Import the peer public key from the file pubkey.

[SwitchB] public-key peer Switch001 import sshkey pubkey
# For user client001, set the service type as SFTP, authentication type as publickey, public key as
Switch001, and working folder as flash:/
[SwitchB] ssh user client001 service-type sftp authentication-type publickey assign publickey
Switch001 work-directory flash:/
2) Configure the SFTP client (Switch A)
# Configure an IP address for VLAN interface 1.
# Generate RSA key pairs.

[SwitchA] public-key local create rsa
9-6

# Export the host public key to file pubkey.
[SwitchA] public-key local export rsa ssh2 pubkey
[SwitchA] quit
After generating key pairs on a client, you need to transmit the saved public key file to the server
the client.
# Establish a connection to the remote SFTP server and enter SFTP client view.
<SwitchA> sftp 192.168.0.1 identity-key rsa
Input Username: client001
Trying 192.168.0.1 ...
Connected to 192.168.0.1 ...

sftp-client>
# Display files under the current directory of the server, delete the file named z, and check if the file has
been deleted successfully.
sftp-client> dir
-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub
-rwxrwxrwx 1 noone nogroup 0 Sep 01 08:00 z
sftp-client> delete z
The following File will be deleted:
/z
Are you sure to delete it? [Y/N]:y
This operation may take a long time.Please wait...
File successfully Removed

sftp-client> dir
# Add a directory named new1 and check if it has been created successfully.
9-7

sftp-client> mkdir new1
New directory created
sftp-client> dir
drwxrwxrwx 1 noone nogroup 0 Sep 02 06:30 new1
# Rename directory new1 to new2 and check if the directory has been renamed successfully.
sftp-client> rename new1 new2
File successfully renamed
sftp-client> dir
# Download the file pubkey2 from the server and change the name to public.
sftp-client> get pubkey2 public
Remote file:/pubkey2 ---> Local file: public
Downloading file successfully ended
# Upload the local file pu to the server, save it as puk, and check if the file has been uploaded
successfully.
sftp-client> put pu puk
Local file:pu ---> Remote file: /puk
Uploading file successfully ended
sftp-client> dir
-rwxrwxrwx 1 noone nogroup 283 Sep 02 06:36 puk
sftp-client>
# Terminate the connection to the remote SFTP server.

sftp-client> quit
Bye
<SwitchA>
9-8

SFTP Server Configuration Example
As shown in Figure 9-2, an SSH connection is established between the host and the switch. The host,
an SFTP client, logs into the switch for file management and file transfer. An SSH user uses password
authentication with the username being client002 and the password being aabbcc. The username
and password are saved on the switch.
Figure 9-2 Network diagram for SFTP server configuration
1) Configure the SFTP server

# Enable the SFTP server.

[Switch] sftp server enable
# Configure an IP address for VLAN-interface 1, which the client will use as the destination for SSH
connection.
# Set the authentication mode of the user interfaces to AAA.


# Configure a local user named client002 with the password being aabbcc and the service type being
SSH.
[Switch] local-user client002
[Switch-luser-client002] password simple aabbcc
[Switch-luser-client002] service-type ssh
[Switch-luser-client002] quit
# Configure the user authentication type as password and service type as SFTP.
[Switch] ssh user client002 service-type sftp authentication-type password
2) Configure the SFTP client
9-9

z There are many kinds of SSH client software. The following takes the PSFTP of Putty Version
0.58 as an example.
z The PSFTP supports only password authentication.
# Establish a connection with the remote SFTP server.

Run the psftp.exe to launch the client interface as shown in Figure 9-3, and enter the following
command:
open 192.168.1.45
Enter username client002 and password aabbcc as prompted to log into the SFTP server.
Figure 9-3 SFTP client interface
9-10

10 PKI Configuration
When configuring PKI, go to these sections for information you are interested in:
z Introduction to PKI
z PKI Configuration Task List
z Displaying and Maintaining PKI
z PKI Configuration Examples
z Troubleshooting PKI
Introduction to PKI
z PKI Overview
z PKI Terms
z Architecture of PKI
z Applications of PKI
z Operation of PKI
PKI Overview
The Public Key Infrastructure (PKI) is a general security infrastructure for providing information
security through public key technologies.
PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The
key pair consists of a private key and a public key. The private key must be kept secret while the public
key needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other.
A key problem of PKI is how to manage the public keys. Currently, PKI employs the digital certificate
mechanism to solve this problem. The digital certificate mechanism binds public keys to their owners,
helping distribute public keys in large networks securely.
With digital certificates, the PKI system provides network communication and e-commerce with
security services such as user authentication, data non-repudiation, data confidentiality, and data
integrity.
PKI Terms
Digital certificate
A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the
identity information of the entity, the public key of the entity, the name and signature of the CA, and the
validity period of the certificate, where the signature of the CA ensures the validity and authority of the
certificate. A digital certificate must comply with the international standard of ITU-T X.509. Currently,
the most common standard is X.509 v3.
This manual involves two types of certificates: local certificate and CA certificate. A local certificate is a
digital certificate signed by a CA for an entity, while a CA certificate is the certificate of a CA. If multiple
CAs are trusted by different users in a PKI system, the CAs will form a CA tree with the root CA at the
10-1

top level. The root CA has a CA certificate signed by itself while each lower level CA has a CA
certificate signed by the CA at the next higher level.
CRL
An existing certificate may need to be revoked when, for example, the user name changes, the private
key leaks, or the user stops the business. Revoking a certificate is to remove the binding of the public
key with the user identity information. In PKI, the revocation is made through certificate revocation lists
(CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates
that have been revoked. The CRLs contain the serial numbers of all revoked certificates and provide
an effective way for checking the validity of certificates.
A CA may publish multiple CRLs when the number of revoked certificates is so large that publishing
them in a single CRL may degrade network performance, and it uses CRL distribution points to
indicate the URLs of these CRLs.
CA policy
A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking
certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice
statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and
e-mail. As different CAs may use different methods to check the binding of a public key with an entity,
make sure that you understand the CA policy before selecting a trusted CA for certificate request.
Architecture of PKI
A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown in
Figure 10-1.
Figure 10-1 PKI architecture
Entity
An entity is an end user of PKI products or services, such as a person, an organization, a device like a
router or a switch, or a process running on a computer.
10-2

CA
A CA is a trusted authority responsible for issuing and managing digital certificates. A CA issues
certificates, specifies the validity periods of certificates, and revokes certificates as needed by
publishing CRLs.
RA
A registration authority (RA) is an extended part of a CA or an independent authority. An RA can

implement functions including identity authentication, CRL management, key pair generation and key
pair backup. The PKI standard recommends that an independent RA be used for registration
management to achieve higher security of application systems.
PKI repository
A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common database.
It stores and manages information like certificate requests, certificates, keys, CRLs and logs while
providing a simple query function.
LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user
information and digital certificates from the RA server and provides directory navigation service. From
an LDAP server, an entity can retrieve local and CA certificates of its own as well as certificates of
other entities.
Applications of PKI
The PKI technology can satisfy the security requirements of online transactions. As an infrastructure,
PKI has a wide range of applications. Here are some application examples.
VPN
A virtual private network (VPN) is a private data communication network built on the public
communication infrastructure. A VPN can leverage network layer security protocols (for instance,
IPSec) in conjunction with PKI-based encryption and digital signature technologies for confidentiality.
Secure E-mail
E-mails require confidentiality, integrity, authentication, and non-repudiation. PKI can address these
needs. The secure E-mail protocol that is currently developing rapidly is Secure/Multipurpose Internet
Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with
signature.
Web security
For Web security, two peers can establish a Secure Sockets Layer (SSL) connection first for
transparent and secure communications at the application layer. With PKI, SSL enables encrypted
communications between a browser and a server. Both the communication parties can verify the
identity of each other through digital certificates.
Operation of PKI
In a PKI-enabled network, an entity can request a local certificate from the CA and the device can
check the validity of certificates. Here is how it works:
1) An entity submits a certificate request to the RA.
10-3

2) The RA reviews the identity of the entity and then sends the identity information and the public key
with a digital signature to the CA.
3) The CA verifies the digital signature, approves the application, and issues a certificate.
4) The RA receives the certificate from the CA, sends it to the LDAP server to provide directory
navigation service, and notifies the entity that the certificate is successfully issued.
5) The entity retrieves the certificate. With the certificate, the entity can communicate with other
entities safely through encryption and digital signature.
6) The entity makes a request to the CA when it needs to revoke its certificate, while the CA
approves the request, updates the CRLs and publishes the CRLs on the LDAP server.
PKI Configuration Task List

Complete the following tasks to configure PKI:
Task Remarks
Configuring an Entity DN Required
Configuring a PKI Domain Required
Submitting a Certificate
Submitting a PKI Certificate Request in Auto Mode Required
Request Submitting a Certificate Use either approach
Request in Manual Mode
Retrieving a Certificate Manually Optional
Configuring PKI Certificate Optional
Destroying a Local RSA Key Pair Optional
Deleting a Certificate Optional
Configuring an Access Control Policy Optional
Configuring an Entity DN
A certificate is the binding of a public key and the identity information of an entity, where the identity
information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant
uniquely by entity DN.
An entity DN is defined by these parameters:
z Common name of the entity.
z Country code of the entity, a standard 2-character code. For example, CN represents China and
US represents the United States of America.
z Fully qualified domain name (FQDN) of the entity, a unique identifier of an entity on the network. It
consists of a host name and a domain name and can be resolved to an IP address. For example,
www.whatever.com is an FQDN, where www is a host name and whatever.com a domain name.
z IP address of the entity.
z Locality where the entity resides.
z Organization to which the entity belongs.
z Unit of the entity in the organization.
z State where the entity resides.
10-4

The configuration of an entity DN must comply with the CA certificate issue policy. You need to
determine, for example, which entity DN parameters are mandatory and which are optional. Otherwise,
certificate request may be rejected.
Follow these steps to configure an entity DN:

Create an entity and enter its Required

pki entity entity-name
view No entity exists by default.
Optional
Configure the common name
common-name name No common name is specified
for the entity
by default.
Optional
Configure the country code for
country country-code-str No country code is specified by
the entity
default.
Optional
Configure the FQDN for the
fqdn name-str No FQDN is specified by
entity
default.
Optional
Configure the IP address for
ip ip-address No IP address is specified by
the entity
default.
Optional
Configure the locality of the
locality locality-name No locality is specified by
entity
default.
Optional
Configure the organization
organization org-name No organization is specified by
name for the entity
default.
Configure the unit name for the organization-unit Optional

entity org-unit-name No unit is specified by default.
Optional
Configure the state or province
state state-name No state or province is
for the entity
specified by default.
z Currently, up to two entities can be created on a device.

z The Windows 2000 CA server has some restrictions on the data length of a certificate request. If
the entity DN in a certificate request goes beyond a certain limit, the server will not respond to the
certificate request.
10-5

Configuring a PKI Domain
Before requesting a PKI certificate, an entity needs to be configured with some enrollment information,
which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by
other applications like IKE and SSL, and has only local significance.
A PKI domain is defined by these parameters:
z Trusted CA
An entity requests a certificate from a trusted CA.
z Entity
A certificate applicant uses an entity to provide its identity information to a CA.
z RA
Generally, an independent RA is in charge of certificate request management. It receives the
registration request from an entity, checks its qualification, and determines whether to ask the CA to
sign a digital certificate. The RA only checks the application qualification of an entity; it does not issue
any certificate. Sometimes, the registration management function is provided by the CA, in which case
no independent RA is required. You are recommended to deploy an independent RA.
z URL of the registration server
An entity sends a certificate request to the registration server through Simple Certification Enrollment
Protocol (SCEP), a dedicated protocol for an entity to communicate with a CA.
z Polling interval and count
After an applicant makes a certificate request, the CA may need a long period of time if it verifies the
certificate request manually. During this period, the applicant needs to query the status of the request
periodically to get the certificate as soon as possible after the certificate is signed. You can configure
the polling interval and count to query the request status.
z IP address of the LDAP server
An LDAP server is usually deployed to store certificates and CRLs. If this is the case, you need to
configure the IP address of the LDAP server.
z Fingerprint for root certificate verification
Upon receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root
certificate, namely, the hash value of the root certificate content. This hash value is unique to every
certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain,
the entity will reject the root certificate.
Follow these steps to configure a PKI domain:

Required
Create a PKI domain and enter
pki domain domain-name No PKI domain exists by
its view
default.
Required
Specify the trusted CA ca identifier name No trusted CA is specified by
default.
10-6

Required
Specify the entity for certificate certificate request entity No entity is specified by
request entity-name default.
The specified entity must exist.
Required
Specify the authority for certificate request from { ca |
certificate request ra } No authority is specified by
default.
Required
Configure the URL of the certificate request url
server for certificate request url-string No URL is configured by
default.
Optional
Configure the polling interval certificate request polling
and attempt limit for querying { count count | interval The polling is executed for up
the certificate request status minutes } to 50 times at the interval of 20
minutes by default.
ldap-server ip ip-address Optional

Specify the LDAP server [ port port-number ] [ version No LDP server is specified by
version-number ] default.
Required when the certificate
request mode is auto and
optional when the certificate
request mode is manual. In the
Configure the fingerprint for root-certificate fingerprint latter case, if you do not
root certificate verification { md5 | sha1 } string configure this command, the
fingerprint of the root certificate
must be verified manually.
No fingerprint is configured by
default.
z Currently, up to two PKI domains can be created on a device.

z The CA name is required only when you retrieve a CA certificate. It is not used when in local
certificate request.
z Currently, the URL of the server for certificate request does not support domain name resolving.
Submitting a PKI Certificate Request

When requesting a certificate, an entity introduces itself to the CA by providing its identity information
and public key, which will be the major components of the certificate. A certificate request can be
submitted to a CA in two ways: online and offline. In offline mode, a certificate request is submitted to a
CA by an out-of-band means such as phone, disk, or e-mail.
Online certificate request falls into two categories: manual mode and auto mode.
10-7

Submitting a Certificate Request in Auto Mode
In auto mode, an entity automatically requests a certificate through the SCEP protocol when it has no
local certificate or the present certificate is about to expire.
Follow these steps to configure an entity to submit a certificate request in auto mode:

Enter PKI domain view pki domain domain-name
certificate request mode auto Required
Set the certificate request
[ key-length key-length | password
mode to auto Manual by default
{ cipher | simple } password ] *
Submitting a Certificate Request in Manual Mode
In manual mode, you need to retrieve a CA certificate, generate a local RSA key pair, and submit a
local certificate request for an entity.
The goal of retrieving a CA certificate is to verify the authenticity and validity of a local certificate.
Generating an RSA key pair is an important step in certificate request. The key pair includes a public
key and a private key. The private key is kept by the user, while the public key is transferred to the CA
along with some other information. For detailed information about RSA key pair configuration, refer to
Public Key Configuration in the Security Volume.
Follow these steps to submit a certificate request in manual mode:

Set the certificate request certificate request mode Optional

mode to manual manual Manual by default
Retrieve a CA certificate Refer to Retrieving a Certificate

Required
manually Manually
Required
Generate a local RSA key pair public-key local create rsa No local RSA key pair exists by
default.
pki request-certificate
Submit a local certificate domain domain-name
Required
request manually [ password ] [ pkcs10
[ filename filename ] ]
10-8

z If a PKI domain already has a local certificate, creating an RSA key pair will result in inconsistency
between the key pair and the certificate. To generate a new RSA key pair, delete the local
certificate and then issue the public-key local create command. For information about the
public-key local create command, refer to Public Key Commands in the Security Volume.
z A newly created key pair will overwrite the existing one. If you perform the public-key local
create command in the presence of a local RSA key pair, the system will ask you whether you
want to overwrite the existing one.
z If a PKI domain has already a local certificate, you cannot request another certificate for it. This is
to avoid inconsistency between the certificate and the registration information resulting from
configuration changes. To request a new certificate, use the pki delete-certificate command to
delete the existing local certificate and the CA certificate stored locally.
z When it is impossible to request a certificate from the CA through SCEP, you can save the request
information by using the pki request-certificate domain command with the pkcs10 and
filename keywords, and then send the file to the CA by an out-of-band means.
z Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of
the certificate will be abnormal.
z The pki request-certificate domain configuration will not be saved in the configuration file.
Retrieving a Certificate Manually

You can download an existing CA certificate, local certificate, or peer entity certificate from the CA
server and save it locally. To do so, you can use two ways: online and offline. In offline mode, you need
to retrieve a certificate by an out-of-band means like FTP, disk, e-mail and then import it into the local
PKI system.
Certificate retrieval serves two purposes:
z Locally store the certificates associated with the local security domain for improved query
efficiency and reduced query count,
z Prepare for certificate verification.
Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration.
Follow these steps to retrieve a certificate manually:

pki retrieval-certificate { ca | local }
Online
Retrieve a domain domain-name Required
certificate pki import-certificate { ca | local } Use either
manually Offline domain domain-name { der | p12 | pem } command.
[ filename filename ]
10-9

z If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This
is in order to avoid inconsistency between the certificate and registration information due to
related configuration changes. To retrieve a new CA certificate, use the pki delete-certificate
command to delete the existing CA certificate and local certificate first.
z The pki retrieval-certificate configuration will not be saved in the configuration file.
Configuring PKI Certificate Verification

A certificate needs to be verified before being used. Verifying a certificate is to check that the certificate
is signed by the CA and that the certificate has neither expired nor been revoked.
Before verifying a certificate, you need to retrieve the CA certificate.
You can specify whether CRL checking is required in certificate verification. If you enable CRL
checking, CRLs will be used in verification of a certificate.
Configuring CRL-checking-enabled PKI certificate verification
Follow these steps to configure CRL-checking-enabled PKI certificate verification:

Optional
Specify the URL of the CRL
crl url url-string No CRL distribution point URL
distribution point
is specified by default.
Optional
Set the CRL update period crl update-period hours By default, the CRL update
period depends on the next
update field in the CRL file.
Optional
Enable CRL checking crl check enable
Enabled by default
Refer to Retrieving a Certificate
Retrieve the CA certificate Required
Manually
pki retrieval-crl domain
Retrieve CRLs Required
domain-name
Verify the validity of a pki validate-certificate { ca |
Required
certificate local } domain domain-name
Configuring CRL-checking-disabled PKI certificate verification
Follow these steps to configure CRL-checking-disabled PKI certificate verification:
10-10

Required
Disable CRL checking crl check disable
Enabled by default

Refer to Retrieving a Certificate
Retrieve the CA certificate Required
Manually
Verify the validity of the pki validate-certificate { ca | local }
Required
certificate domain domain-name
z The CRL update period refers to the interval at which the entity downloads CRLs from the CRL
server. The CRL update period configured manually is prior to that specified in the CRLs.
z The pki retrieval-crl domain configuration will not be saved in the configuration file.
z Currently, the URL of the CRL distribution point does not support domain name resolving.
Destroying a Local RSA Key Pair

A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate
is about to expire, you can destroy the old RSA key pair and then create a pair to request a new
certificate.
Follow these steps to destroy a local RSA key pair:

Destroy a local RSA key pair public-key local destroy rsa Required
For details about the public-key local destroy command, refer to Public Key Commands in the
Security Volume.
Deleting a Certificate
When a certificate requested manually is about to expire or you want to request a new certificate, you
can delete the current local certificate or CA certificate.
Follow these steps to delete a certificate:
10-11

pki delete-certificate { ca | local } domain

Delete certificates Required
domain-name
Configuring an Access Control Policy

By configuring a certificate attribute-based access control policy, you can further control access to the
server, providing additional security for the server.
Follow these steps to configure a certificate attribute-based access control policy:

Required
Create a certificate attribute pki certificate attribute-group
group and enter its view group-name No certificate attribute group
exists by default.
attribute id { alt-subject-name Optional

Configure an attribute rule for
{ fqdn | ip } | { issuer-name | There is no restriction on the
the certificate issuer name,
subject-name } { dn | fqdn | issuer name, certificate subject
certificate subject name, or
ip } } { ctn | equ | nctn | nequ } name and alternative subject
alternative subject name
attribute-value name by default.
Create a certificate pki certificate Required

attribute-based access control access-control-policy No access control policy exists
policy and enter its view policy-name by default.
Configure a certificate Required

rule [ id ] { deny | permit }
attribute-based access control No access control rule exists
group-name
rule by default.
A certificate attribute group must exist to be associated with a rule.
Displaying and Maintaining PKI

display pki certificate { { ca |
Display the contents or request
local } domain domain-name | Available in any view
status of a certificate
request-status }
display pki crl domain
Display CRLs Available in any view
domain-name
display pki certificate
Display information about one
attribute-group { group-name Available in any view
or all certificate attribute groups
| all }
10-12

Display information about one display pki certificate
or all certificate attribute-based access-control-policy Available in any view
access control policies { policy-name | all }
PKI Configuration Examples
z The SCEP plug-in is required when you use the Windows Server as the CA. In this case, when
configuring the PKI domain, you need to use the certificate request from ra command to specify
that the entity requests a certificate from an RA.
z The SCEP plug-in is not required when RSA Keon is used. In this case, when configuring a PKI
domain, you need to use the certificate request from ca command to specify that the entity
requests a certificate from a CA.
Requesting a Certificate from a CA Running RSA Keon
The CA server runs RSA Keon in this configuration example.
z The device submits a local certificate request to the CA server.

z The device acquires the CRLs for certificate verification.
Figure 10-2 Request a certificate from a CA running RSA Keon
1) Configure the CA server

# Create a CA server named myca.
In this example, you need to configure these basic attributes on the CA server at first:
z Nickname: Name of the trusted CA.
10-13

z Subject DN: DN information of the CA, including the Common Name (CN), Organization Unit (OU),
Organization (O), and Country (C).
The other attributes may be left using the default values.
# Configure extended attributes.
After configuring the basic attributes, you need to perform configuration on the jurisdiction
configuration page of the CA server. This includes selecting the proper extension profiles, enabling the
SCEP autovetting function, and adding the IP address list for SCEP autovetting.
# Configure the CRL distribution behavior.
After completing the above configuration, you need to perform CRL related configurations. In this
example, select the local CRL distribution mode of HTTP and set the HTTP URL to
http://4.4.4.133:447/myca.crl.
After the above configuration, make sure that the system clock of the device is synchronous to that of
the CA, so that the device can request certificates and retrieve CRLs properly.
z Configure the entity DN
# Configure the entity name as aaa and the common name as switch.
[Switch] pki entity aaa
[Switch-pki-entity-aaa] common-name switch
[Switch-pki-entity-aaa] quit
z Configure the PKI domain
# Create PKI domain torsa and enter its view.
[Switch] pki domain torsa
# Configure the name of the trusted CA as myca.

[Switch-pki-domain-torsa] ca identifier myca
# Configure the URL of the registration server in the format of http://host:port/Issuing Jurisdiction ID,
where Issuing Jurisdiction ID is a hexadecimal string generated on the CA server.
[Switch-pki-domain-torsa] certificate request url
http://4.4.4.133:446/c95e970f632d27be5e8cbf80e971d9c4a9a93337
# Set the registration authority to CA.

[Switch-pki-domain-torsa] certificate request from ca
# Specify the entity for certificate request as aaa.

[Switch-pki-domain-torsa] certificate request entity aaa
# Configure the URL for the CRL distribution point.

[Switch-pki-domain-torsa] crl url http://4.4.4.133:447/myca.crl
[Switch-pki-domain-torsa] quit
z Generate a local key pair using RSA
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits in the modulus [default = 1024]:
10-14

Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++
z Apply for certificates

# Retrieve the CA certificate and save it locally.
[Switch] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5 fingerprint:EDE9 0394 A273 B61A F1B3 0072 A0B1 F9AB
SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8
Is the finger print correct?(Y/N):y
Saving CA/RA certificates chain, please wait a moment......

CA certificates retrieval success.
# Retrieve CRLs and save them locally.

[Switch] pki retrieval-crl domain torsa
Connecting to server for retrieving CRL. Please wait a while.....
CRL retrieval success!
# Request a local certificate manually.

[Switch] pki request-certificate domain torsa challenge-word
Certificate is being requested, please wait......
[Switch]
Enrolling the local certificate,please wait a while......
Certificate request Successfully!
Saving the local certificate to device......
Done!
# Use the following command to view information about the local certificate acquired.
<Switch> display pki certificate local domain torsa
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9A96A48F 9A509FD7 05FFF4DF 104AD094
Signature Algorithm: sha1WithRSAEncryption
Issuer:
C=cn
O=org
OU=test
CN=myca
Validity
Not Before: Jan 8 09:26:53 2007 GMT
10-15

Not After : Jan 8 09:26:53 2008 GMT
Subject:
CN=switch
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00D67D50 41046F6A 43610335 CA6C4B11
F8F89138 E4E905BD 43953BA2 623A54C0
EA3CB6E0 B04649CE C9CDDD38 34015970
981E96D9 FF4F7B73 A5155649 E583AC61
D3A5C849 CBDE350D 2A1926B7 0AE5EF5E
D1D8B08A DBF16205 7C2A4011 05F11094
73EB0549 A65D9E74 0F2953F2 D4F0042F
19103439 3D4F9359 88FB59F3 8D4B2F6C
2B
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 CRL Distribution Points:
URI:http://4.4.4.133:447/myca.crl

836213A4 F2F74C1A 50F4100D B764D6CE
B30C0133 C4363F2F 73454D51 E9F95962
EDE9E590 E7458FA6 765A0D3F C4047BC2
9C391FF0 7383C4DF 9A0CCFA9 231428AF
987B029C C857AD96 E4C92441 9382E798
8FCC1E4A 3E598D81 96476875 E2F86C33
75B51661 B6556C5E 8F546E97 5197734B
C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C
You can also use some other display commands to view detailed information about the CA certificate
and CRLs. Refer to the parts related to display pki certificate ca domain and display pki crl
domain commands in PKI Commands of the Security Volume.
Requesting a Certificate from a CA Running Windows 2003 Server
The CA server runs the Windows 2003 server in this configuration example.
Configure PKI entity Switch to request a local certificate from the CA server.
10-16

Figure 10-3 Request a certificate from a CA running Windows 2003 server
1) Configure the CA server

z Install the certificate server suites
From the start menu, select Control Panel > Add or Remove Programs, and then select
Add/Remove Windows Components > Certificate Services and click Next to begin the installation.
z Install the SCEP plug-in
As a CA server running the Windows 2003 server does not support SCEP by default, you need to
install the SCEP plug-in so that the switch can register and obtain its certificate automatically. After the
SCEP plug-in installation completes, a URL is displayed, which you need to configure on the switch as
the URL of the server for certificate registration.
z Modify the certificate service attributes
From the start menu, select Control Panel > Administrative Tools > Certificate Authority. If the CA
server and SCEP plug-in have been installed successfully, there should be two certificates issued by
the CA to the RA. Right-click on the CA server in the navigation tree and select Properties > Policy
Module. Click Properties and then select Follow the settings in the certificate template, if
applicable. Otherwise, automatically issue the certificate.
z Modify the Internet Information Services (IIS) attributes
From the start menu, select Control Panel > Administrative Tools > Internet Information Services
(IIS) Manager and then select Web Sites from the navigation tree. Right-click on Default Web Site
and select Properties > Home Directory. Specify the path for certificate service in the Local path text
box. In addition, you are recommended to specify an available port number as the TCP port number of
the default Web site to avoid conflict with existing services.
After completing the above configuration, check that the system clock of the switch is synchronous to
that of the CA server, ensuring that the switch can request a certificate normally.
z Configure the entity DN
# Configure the entity name as aaa and the common name as switch.
[Switch] pki entity aaa
[Switch-pki-entity-aaa] common-name switch
[Switch-pki-entity-aaa] quit
z Configure the PKI domain
# Create PKI domain torsa and enter its view.
[Switch] pki domain torsa
# Configure the name of the trusted CA as myca.

[Switch-pki-domain-torsa] ca identifier myca
10-17

# Configure the URL of the registration server in the format of http://host:port/ certsrv/mscep/mscep.dll,
where host:port indicates the IP address and port number of the CA server.
[Switch-pki-domain-torsa] certificate request url
http://4.4.4.1:8080/certsrv/mscep/mscep.dll
# Set the registration authority to RA.

[Switch-pki-domain-torsa] certificate request from ra
# Specify the entity for certificate request as aaa.

[Switch-pki-domain-torsa] certificate request entity aaa
z Generate a local key pair using RSA
Input the bits in the modulus [default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++
.
z Apply for certificates
# Retrieve the CA certificate and save it locally.
[Switch] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5 fingerprint:766C D2C8 9E46 845B 4DCE 439C 1C1F 83AB
SHA1 fingerprint:97E5 DDED AB39 3141 75FB DB5C E7F8 D7D7 7C9B 97B4
Is the finger print correct?(Y/N):y
Saving CA/RA certificates chain, please wait a moment......

CA certificates retrieval success.
# Request a local certificate manually.

[Switch] pki request-certificate domain torsa challenge-word
Certificate is being requested, please wait......
[Switch]
Enrolling the local certificate,please wait a while......
Certificate request Successfully!
Saving the local certificate to device......
Done!
# Use the following command to view information about the local certificate acquired.
<Switch> display pki certificate local domain torsa
Certificate:
10-18

Data:
Version: 3 (0x2)
Serial Number:
48FA0FD9 00000000 000C
Issuer:
CN=CA server
Validity
Not Before: Nov 21 12:32:16 2007 GMT
Not After : Nov 21 12:42:16 2008 GMT
Subject:
CN=switch
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00A6637A 8CDEA1AC B2E04A59 F7F6A9FE
5AEE52AE 14A392E4 E0E5D458 0D341113
0BF91E57 FA8C67AC 6CE8FEBB 5570178B
10242FDD D3947F5E 2DA70BD9 1FAF07E5
1D167CE1 FC20394F 476F5C08 C5067DF9
CB4D05E6 55DC11B6 9F4C014D EA600306
81D403CF 2D93BC5A 8AF3224D 1125E439
78ECEFE1 7FA9AE7B 877B50B8 3280509F
6B
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B68E4107 91D7C44C 7ABCE3BA 9BF385F8 A448F4E1
X509v3 Authority Key Identifier:
keyid:9D823258 EADFEFA2 4A663E75 F416B6F6 D41EE4FE
X509v3 CRL Distribution Points:

URI:http://l00192b/CertEnroll/CA%20server.crl
URI:file://\\l00192b\CertEnroll\CA server.crl
Authority Information Access:

CA Issuers - URI:http://l00192b/CertEnroll/l00192b_CA%20server.crt
CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt
1.3.6.1.4.1.311.20.2:
.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e
81029589 7BFA1CBD 20023136 B068840B
(Omitted)
You can also use some other display commands to view detailed information about the CA certificate.
Refer to the display pki certificate ca domain command in PKI Commands of the Security Volume.
10-19

Configuring a Certificate Attribute-Based Access Control Policy
z The client accesses the remote HTTP Security (HTTPS) server through the HTTPS protocol.
z SSL is configured to ensure that only legal clients log into the HTTPS server.
z Create a certificate attribute-based access control policy to control access to the HTTPS server.
Figure 10-4 Configure a certificate attribute-based access control policy
z For detailed information about SSL configuration, refer to SSL Configuration in the Security
Volume.
z For detailed information about HTTPS configuration, refer to HTTP Configuration in the System
Volume.
z The PKI domain to be referenced by the SSL policy must be created in advance. For detailed
configuration of the PKI domain, refer to Configure the PKI domain.
1) Configure the HTTPS server

# Configure the SSL policy for the HTTPS server to use.
[Switch] ssl server-policy myssl
[Switch-ssl-server-policy-myssl] pki-domain 1
[Switch-ssl-server-policy-myssl] client-verify enable
[Switch-ssl-server-policy-myssl] quit
2) Configure the certificate attribute group
# Create certificate attribute group mygroup1 and add two attribute rules. The first rule defines that
the DN of the subject name includes the string aabbcc, and the second rule defines that the IP
address of the certificate issuer is 10.0.0.1.
[Switch] pki certificate attribute-group mygroup1
[Switch-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc
[Switch-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ 10.0.0.1
[Switch-pki-cert-attribute-group-mygroup1] quit
10-20

# Create certificate attribute group mygroup2 and add two attribute rules. The first rule defines that
the FQDN of the alternative subject name does not include the string of apple, and the second rule
defines that the DN of the certificate issuer name includes the string aabbcc.
[Switch] pki certificate attribute-group mygroup2
[Switch-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple
[Switch-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc
[Switch-pki-cert-attribute-group-mygroup2] quit
3) Configure the certificate attribute-based access control policy
# Create the certificate attribute-based access control policy of myacp and add two access control
rules.
[Switch] pki certificate access-control-policy myacp
[Switch-pki-cert-acp-myacp] rule 1 deny mygroup1
[Switch-pki-cert-acp-myacp] rule 2 permit mygroup2
[Switch-pki-cert-acp-myacp] quit
4) Apply the SSL server policy and certificate attribute-based access control policy to HTTPS service
and enable HTTPS service.
# Apply SSL server policy myssl to HTTPS service.
[Switch] ip https ssl-server-policy myssl
# Apply the certificate attribute-based access control policy of myacp to HTTPS service.
[Switch] ip https certificate access-control-policy myacp
# Enable HTTPS service.

[Switch] ip https enable
Troubleshooting PKI
Failed to Retrieve a CA Certificate
Symptom
Failed to retrieve a CA certificate.
Analysis
Possible reasons include these:

z The network connection is not proper. For example, the network cable may be damaged or loose.
z No trusted CA is specified.
z The URL of the registration server for certificate request is not correct or not configured.
z No authority is specified for certificate request.
z The system clock of the device is not synchronized with that of the CA.
Solution
z Make sure that the network connection is physically proper.

z Check that the required commands are configured properly.
z Use the ping command to check that the RA server is reachable.
z Specify the authority for certificate request.
z Synchronize the system clock of the device with that of the CA.
10-21

Failed to Request a Local Certificate
Symptom
Failed to request a local certificate.
Analysis

z No CA certificate has been retrieved.
z The current key pair has been bound to a certificate.
z No trusted CA is specified.
z The URL of the registration server for certificate request is not correct or not configured.
z No authority is specified for certificate request.
z Some required parameters of the entity DN are not configured.
Solution

z Retrieve a CA certificate.
z Regenerate a key pair.
z Specify a trusted CA.
z Use the ping command to check that the RA server is reachable.
z Specify the authority for certificate request.
z Configure the required entity DN parameters.
Failed to Retrieve CRLs
Symptom
Failed to retrieve CRLs.
Analysis

z No CA certificate has been retrieved before you try to retrieve CRLs.
z The IP address of LDAP server is not configured.
z The CRL distribution URL is not configured.
z The LDAP server version is wrong.
Solution

z Retrieve a CA certificate.
z Specify the IP address of the LDAP server.
z Specify the CRL distribution URL.
z Re-configure the LDAP version.
10-22

11 SSL Configuration
When configuring SSL, go to these sections for information you are interested in:
z SSL Overview
z SSL Configuration Task List
z Displaying and Maintaining SSL
z Troubleshooting SSL
SSL Overview
Secure Sockets Layer (SSL) is a security protocol providing secure connection service for TCP-based
application layer protocols, for example, HTTP protocol. It is widely used in E-business and online
bank fields to provide secure data transmission over the Internet.
SSL Security Mechanism
SSL provides these security services:

z Confidentiality: SSL uses a symmetric encryption algorithm to encrypt data and uses the
asymmetric key algorithm of Rivest, Shamir, and Adelman (RSA) to encrypt the key to be used by
the symmetric encryption algorithm.
z Authentication: SSL supports certificate-based identity authentication of the server and client by
using the digital signatures, with the authentication of the client being optional. The SSL server
and client obtain certificates from a certificate authority (CA) through the Public Key Infrastructure
(PKI).
z Reliability: SSL uses the key-based message authentication code (MAC) to verify message
integrity. A MAC algorithm transforms a message of any length to a fixed-length message. Figure
11-1 illustrates how SSL uses a MAC algorithm to verify message integrity. With the key, the
sender uses the MAC algorithm to compute the MAC value of a message. Then, the sender
suffixes the MAC value to the message and sends the result to the receiver. The receiver uses the
same key and MAC algorithm to compute the MAC value of the received message, and compares
the locally computed MAC value with that received. If the two matches, the receiver considers the
message intact; otherwise, the receiver considers that the message has been tampered with in
transit and discards the message.
Figure 11-1 Message integrity verification by a MAC algorithm
11-1

z For details about symmetric key algorithms, asymmetric key algorithm RSA and digital signature,
refer to Public Key Configuration in the Security Volume.
z For details about PKI, certificate, and CA, refer to PKI Configuration in the Security Volume.
SSL Protocol Stack
As shown in Figure 11-2, the SSL protocol consists of two layers of protocols: the SSL record protocol
at the lower layer and the SSL handshake protocol, change cipher spec protocol, and alert protocol at
the upper layer.
Figure 11-2 SSL protocol stack
z SSL handshake protocol: As a very important part of the SSL protocol stack, it is responsible for
negotiating the cipher suite to be used during communication (including the symmetric encryption
algorithm, key exchange algorithm, and MAC algorithm), exchanging the key between the server
and client, and implementing identity authentication of the server and client. Through the SSL
handshake protocol, a session is established between a client and the server. A session consists
of a set of parameters, including the session ID, peer certificate, cipher suite, and master secret.
z SSL change cipher spec protocol: Used for notification between a client and the server that the
subsequent packets are to be protected and transmitted based on the newly negotiated cipher
suite and key.
z SSL alert protocol: Allowing a client and the server to send alert messages to each other. An alert
message contains the alert severity level and a description.
z SSL record protocol: Fragmenting and compressing data to be transmitted, calculating and adding
MAC to the data, and encrypting the data before transmitting it to the peer end.
SSL Configuration Task List

Different parameters are required on the SSL server and the SSL client.
Complete the following tasks to configure SSL:
Task Remarks
Configuring an SSL Server Policy Required
Configuring an SSL Client Policy Optional
11-2

Configuring an SSL Server Policy
An SSL server policy is a set of SSL parameters for a server to use when booting up. An SSL server
policy takes effect only after it is associated with an application layer protocol, HTTP protocol, for
example.
When configuring an SSL server policy, you need to specify the PKI domain to be used for obtaining
the server side certificate. Therefore, before configuring an SSL server policy, you must configure a
PKI domain. For details about PKI domain configuration, refer to PKI Configuration in the Security
Volume.
Follow these steps to configure an SSL server policy:

Create an SSL server policy
ssl server-policy policy-name Required
and enter its view
Required
Specify a PKI domain for the By default, no PKI domain is
pki-domain domain-name
SSL server policy specified for an SSL server
policy.
ciphersuite Optional
Specify the cipher suite(s) for [ rsa_aes_128_cbc_sha |
the SSL server policy to rsa_des_cbc_sha | By default, an SSL server
support rsa_rc4_128_md5 | policy supports all cipher
rsa_rc4_128_sha ] * suites.
Set the handshake timeout Optional

handshake timeout time
time for the SSL server 3,600 seconds by default
Configure the SSL connection Optional

close-mode wait
close mode Not wait by default
Optional
The defaults are as follows:
Set the maximum number of
session { cachesize size | 500 for the maximum number
cached sessions and the
timeout time } * of cached sessions,
caching timeout time
3600 seconds for the caching
timeout time.
Enable certificate-based SSL Optional

client-verify enable
client authentication Not enabled by default
11-3

z If you enable client authentication here, you must request a local certificate for the client.
z Currently, SSL mainly comes in these versions: SSL 2.0, SSL 3.0, and TLS 1.0, where TLS 1.0
corresponds to SSL 3.1. When the device acts as an SSL server, it can communicate with clients
running SSL 3.0 or TLS 1.0, and can identify Hello packets from clients running SSL 2.0. If a client
running SSL 2.0 also supports SSL 3.0 or TLS 1.0 (information about supported versions is
carried in the packet that the client sends to the server), the server will notify the client to use SSL
3.0 or TLS 1.0 to communicate with the server.
SSL Server Policy Configuration Example
z Device works as the HTTPS server.

z A host works as the client and accesses the HTTPS server through HTTP secured with SSL.
z A certificate authority (CA) issues a certificate to Device.
In this instance, Windows Server works as the CA and the Simple Certificate Enrollment Protocol
(SCEP) plug-in is installed on the CA.
Figure 11-3 Network diagram for SSL server policy configuration
1) Request a certificate for Device

# Create a PKI entity named en and configure it.
[Device] pki entity en
[Device-pki-entity-en] common-name http-server1
[Device-pki-entity-en] fqdn ssl.security.com
[Device-pki-entity-en] quit
# Create a PKI domain and configure it.

11-4

[Device] pki domain 1
[Device-pki-domain-1] ca identifier ca1
[Device-pki-domain-1] certificate request url http://10.1.2.2/certsrv/mscep/mscep.dll
[Device-pki-domain-1] certificate request from ra
[Device-pki-domain-1] certificate request entity en
[Device-pki-domain-1] quit
# Create the local RSA key pairs.

[Device] public-key local create rsa
# Retrieve the CA certificate.

[Device] pki retrieval-certificate ca domain 1
# Request a local certificate.

[Device] pki request-certificate domain 1
2) Configure an SSL server policy
# Create an SSL server policy named myssl.
[Device] ssl server-policy myssl
# Specify the PKI domain for the SSL server policy as 1.

[Device-ssl-server-policy-myssl] pki-domain 1
# Enable client authentication.

[Device-ssl-server-policy-myssl] client-verify enable
[Device-ssl-server-policy-myssl] quit
3) Associate HTTPS service with the SSL server policy and enable HTTPS service
# Configure HTTPS service to use SSL server policy myssl.
[Device] ip https ssl-server-policy myssl
# Enable HTTPS service.

[Device] ip https enable
Launch IE on the host and enter https://10.1.1.1 in the address bar. You should be able to log in to
Device and manage it.
z For details about PKI configuration commands, refer to PKI Commands in the Security Volume.
z For details about the public-key local create rsa command, refer to Public Key Commands in the
Security Volume.
z For details about HTTPS, refer to HTTP Configuration in the System Volume.
Configuring an SSL Client Policy

An SSL client policy is a set of SSL parameters for a client to use when connecting to the server. An
SSL client policy takes effect only after it is associated with an application layer protocol.
11-5

If the SSL server is configured to authenticate the SSL client, when configuring the SSL client policy,
you need to specify the PKI domain to be used for obtaining the certificate of the client. Therefore,
before configuring an SSL client policy, you must configure a PKI domain. For details about PKI
domain configuration, refer to PKI Configuration in the Security Volume.
Follow these steps to configure an SSL client policy:

Create an SSL client policy and
ssl client-policy policy-name Required
enter its view
Required
Specify a PKI domain for the
pki-domain domain-name No PKI domain is configured by
SSL client policy
default.
prefer-cipher
{ rsa_aes_128_cbc_sha | Optional
Specify the preferred cipher
rsa_des_cbc_sha |
suite for the SSL client policy rsa_rc4_128_md5 by default
rsa_rc4_128_md5 |
rsa_rc4_128_sha }
Specify the SSL protocol Optional

version { ssl3.0 | tls1.0 }
version for the SSL client policy TLS 1.0 by default
If you enable client authentication on the server, you must request a local certificate for the client.
Displaying and Maintaining SSL

Display SSL server policy display ssl server-policy
information { policy-name | all }
Display SSL client policy display ssl client-policy
information { policy-name | all }
Troubleshooting SSL
SSL Handshake Failure
Symptom
As the SSL server, the device fails to handshake with the SSL client.
11-6

Analysis
SSL handshake failure may result from the following causes:

z No SSL server certificate exists, or the certificate is not trusted.
z The server is expected to authenticate the client, but the SSL client has no certificate or the
certificate is not trusted.
z The cipher suites used by the server and the client do not match.
Solution
1) You can issue the debugging ssl command and view the debugging information to locate the
problem:
z If the SSL server has no certificate, request one for it.
z If the server certificate cannot be trusted, install on the SSL client the root certificate of the CA that
issues the local certificate to the SSL server, or let the server requests a certificate from the CA
that the SSL client trusts.
z If the SSL server is configured to authenticate the client, but the certificate of the SSL client does
not exist or cannot be trusted, request and install a certificate for the client.
2) You can use the display ssl server-policy command to view the cipher suite used by the SSL
server policy. If the cipher suite used by the SSL server does not match that used by the client,
use the ciphersuite command to modify the cipher suite of the SSL server.
11-7

12 Public Key Configuration
When configuring public keys, go to these sections for information you are interested in:
z Asymmetric Key Algorithm Overview
z Configuring the Local Asymmetric Key Pair
z Configuring the Public Key of a Peer
z Displaying and Maintaining Public Keys
z Public Key Configuration Examples
Asymmetric Key Algorithm Overview

Basic Concepts
z Algorithm: A set of transformation rules for encryption and decryption.

z Plain text: Information without being encrypted.
z Cipher text: Encrypted information.
z Key: A string of characters that controls the transformation between plain text and cipher text. It
participates in both the encryption and decryption.
Key Algorithm Types
As shown in Figure 12-1, the information is encrypted before being sent for confidentiality. The cipher
text is transmitted in the network, and then is decrypted by the receiver to obtain the original pain text.
Figure 12-1 Encryption and decryption
There are two types of key algorithms, based on whether the keys for encryption and decryption are
the same:
z Symmetric key algorithm: The same key is used for both encryption and decryption. Commonly
used symmetric key algorithms include Advanced Encryption Standard (AES) and Data
Encryption Standard (DES).
z Asymmetric key algorithm: Both ends have their own key pair, consisting of a private key and a
public key. The private key is kept secret while the public key may be distributed widely. The
information encrypted with the public key/private key can be decrypted only with the
corresponding private key/public key; however, the private key cannot be practically derived from
the public key.
12-1

Asymmetric Key Algorithm Applications
Asymmetric key algorithms can be used for encryption/decryption and digital signature:
z Encryption/decryption: The information encrypted with a receiver's public key can be decrypted by
the receiver possessing the corresponding private key. This is used to ensure confidentiality.
z Digital signature: The information encrypted with a sender's private key can be decrypted by
anyone who has access to the sender's public key, thereby proving that the information is from the
sender and has not been tampered with. For example, user 1 adds a signature to the data using
the private key, and then sends the data to user 2. User 2 verifies the signature using the public
key of user 1. If the signature is correct, the data is considered from user 1.
Revest-Shamir-Adleman Algorithm (RSA), and Digital Signature Algorithm (DSA) are all asymmetric
key algorithms. RSA can be used for data encryption/decryption and signature, whereas DSA are used
for signature only.
Asymmetric key algorithms are usually used in digital signature applications for peer identity
authentication because they involve complex calculations and are time-consuming; symmetric key
algorithms are often used to encrypt/decrypt data for security.
Configuring the Local Asymmetric Key Pair

You can create and destroy a local asymmetric key pair, and export the host public key of a local
asymmetric key pair.
Creating an Asymmetric Key Pair
Follow these steps to create an asymmetric key pair:

Create a local DSA , or public-key local create Required

RSA key pairs { dsa | rsa } By default, there is no such key pair.
12-2

z Configuration of the public-key local create command can survive a reboot.
z The public-key local create rsa command generates two key pairs: one server key pair and one
host key pair. Each key pair consists of a public key and a private key.
z The length of an RSA key modulus is in the range 512 to 2048 bits. After entering the public-key
local create rsa command, you will be required to specify the modulus length. For security, a
modulus of at least 768 bits is recommended.
z The public-key local create dsa command generates only one key pair, that is, the host key pair.
z The length of a DSA key modulus is in the range 512 to 2048 bits. After entering the public-key
local create dsa command, you will be required to specify the modulus length. For security, a
modulus of at least 768 bits is recommended.
Displaying or Exporting the Local RSA or DSA Host Public Key
You can display the local RSA or DSA host public key on the screen or export it to a specified file, so as
to configure the local RSA or DSA host public key on the remote end.
Follow these steps to display or export the local RSA or DSA host public key:

Display the local RSA host public key public-key local export rsa
on the screen in a specified format, or { openssh | ssh1 | ssh2 } Select a command
export it to a specified file [ filename ] according to the
Display the local DSA host public key type of the key to
public-key local export dsa be exported.
on the screen in a specified format, or
{ openssh | ssh2 } [ filename ]
export it to a specified file
Destroying an Asymmetric Key Pair
An asymmetric key pair may expire or leak. In this case, you need to destroy it and generate a new
pair.
Follow these steps to destroy an asymmetric key pair:

Destroy an asymmetric key pair public-key local destroy { dsa | rsa } Required
Configuring the Public Key of a Peer

To authenticate the remote host, you need to configure the RSA or DSA public key of that peer on the
local host.
To configure the public key of the peer, you can:
z Configure it manually: You can input on or copy the public key of the peer to the local host.
12-3

z Import it from the public key file: The system automatically converts the public key to a string
coded using the PKCS (Public Key Cryptography Standards). Before importing the public key, you
must upload the peer's public key file (in binary) to the local host through FTP or TFTP.
z If you choose to input the public key, the public key must be in a correct format. The key data
displayed by the display public-key local public command can be used to meet the format
requirements. The public key displayed in other methods may not meet the format requirements,
and the format-incompliant key cannot be saved. Thus, you are recommended to configure the
public key of the peer by importing it from a public key file.
z The device supports up to 20 host pubic keys of peers.
Follow these steps to configure the public key of a peer manually:

Enter public key view public-key peer keyname
Enter public key code view public-key-code begin
Required
Configure a public key of the Spaces and carriage returns
Type or copy the key
peer are allowed between
characters.

Return to public key view public-key-code end When you exit public key code
view, the system automatically
saves the public key.
Return to system view peer-public-key end
Follow these steps to import the host public key of a peer from the public key file:

Import the host public key of a public-key peer keyname

Required
peer from the public key file import sshkey filename
Displaying and Maintaining Public Keys

Display the public keys of the display public-key local { dsa
local key pairs | rsa } public
Display the public keys of the display public-key peer
peers [ brief | name publickey-name ]
12-4

Public Key Configuration Examples
Configuring the Public Key of a Peer Manually
Device A is authenticated by Device B when accessing Device B, so the public key of Device A should
be configured on Device B in advance.
In this example:
z RSA is used.
z The host public key of Device A is configured manually on Device B.
Figure 12-2 Network diagram for manually configuring the public key of a peer
# Create RSA key pairs on Device A.
[DeviceA] public-key local create rsa
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the created RSA key pairs.

[DeviceA] display public-key local rsa public
=====================================================
Time of Key pair created: 09:50:06 2007/08/07
Key name: HOST_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F814F985
4C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C669A78
4AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC078B2BAA3BC3BCA
80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
12-5

=====================================================
Key name: SERVER_KEY
=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87BB6158E
35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3CFA9E8
4B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F0203010001
# Configure the host public key of Device A on Device B. In public key code view, input the host public
key of Device A. The host public key is the content of HOST_KEY displayed on Device A using the
display public-key local dsa public command.
[DeviceB] public-key peer devicea
Public key view: return to System View with "peer-public-key end".
[DeviceB-pkey-public-key] public-key-code begin
Public key code view: return to last view with "public-key-code end".
[DeviceB-pkey-key-code]30819F300D06092A864886F70D010101050003818D0030818902818100D90003F
A95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A
9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326
470034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
[DeviceB-pkey-key-code] public-key-code end
[DeviceB-pkey-public-key] peer-public-key end
# Display the host public key of Device A saved on Device B.

[DeviceB] display public-key peer name devicea
=====================================
Key Name : devicea
Key Type : RSA
Key Module: 1024
=====================================
Key Code:
Importing the Public Key of a Peer from a Public Key File
Device A is authenticated when accessing Device B, so the public host public key of Device A should
be configured on Device B in advance.
In this example:
z RSA is used.
12-6

z The host public key of Device A is imported from the public key file to Device B.
Figure 12-3 Network diagram for importing the public key of a peer from a public key file
Configurtion procedure
1) Create key pairs on Device A and export the host public key
# Create RSA key pairs on Device A.
[DeviceA] public-key local create rsa
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the created RSA key pairs.

[DeviceA] display public-key local rsa public
=====================================================
Key name: HOST_KEY
=====================================================
Key code:
=====================================================
Key name: SERVER_KEY
=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87BB6158E
35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3CFA9E8
4B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F0203010001
# Export the RSA host public key to a file named devicea.pub.
12-7

[DeviceA] public-key local export rsa ssh2 devicea.pub
[DeviceA] quit
2) Enable the FTP server function on Device B
# Enable the FTP server function, create an FTP user with the username ftp and password 123.
[DeviceB] ftp server enable
[DeviceB] local-user ftp
[DeviceB-luser-ftp] password simple 123
[DeviceB-luser-ftp] service-type ftp
[DeviceB-luser-ftp] authorization-attribute level 3
[DeviceB-luser-ftp] quit
3) Upload the public key file of Device A to Device B
# FTP the public key file devicea.pub to Device B with the file transfer mode of binary.
<DeviceA> ftp 10.1.1.2
Trying 10.1.1.2 ...
Connected to 10.1.1.2.
220 FTP service ready.
User(10.1.1.2:(none)):ftp
331 Password required for ftp.
Password:
230 User logged in.
[ftp] binary
200 Type set to I.
[ftp] put devicea.pub
227 Entering Passive Mode (10,1,1,2,5,148).
125 BINARY mode data connection already open, transfer starting for /devicea.pub.
226 Transfer complete.
FTP: 299 byte(s) sent in 0.189 second(s), 1.00Kbyte(s)/sec.
4) Import the host public key of Device A to Device B
# Import the host public key of Device A from the key file devicea.pub to Device B.
[DeviceB] public-key peer devicea import sshkey devicea.pub
# Display the host public key of Device A saved on Device B.

[DeviceB] display public-key peer name devicea
=====================================
Key Name : devicea
Key Type : RSA
Key Module: 1024
=====================================
Key Code:
12-8

13 ACL Overview
In order to filter traffic, network devices use sets of rules, called access control lists (ACLs), to identify
and handle packets.
When configuring ACLs, go to these chapters for information you are interested in:
z ACL Overview
z IPv4 ACL Configuration
z IPv6 ACL Configuration
z ACL Application for Packet Filtering
Unless otherwise stated, ACLs refer to both IPv4 ACLs and IPv6 ACLs throughout this document.
Introduction to ACL
Introduction
As network scale and network traffic are increasingly growing, network security and bandwidth
allocation become more and more critical to network management. Packet filtering can be used to
efficiently prevent illegal users from accessing networks and to control network traffic and save
network resources. Access control lists (ACL) are often used to filter packets with configured matching
rules.
ACLs are sets of rules (or sets of permit or deny statements) that decide what packets can pass and
what should be rejected based on matching criteria such as source MAC address, destination MAC
address, source IP address, destination IP address, and port number.
Application of ACLs on the Switch
The switch supports two ACL application modes:

z Hardware-based application: An ACL is assigned to a piece of hardware. For example, an ACL
can be referenced by QoS for traffic classification. Note that when an ACL is referenced to
implement QoS, the actions defined in the ACL rules, deny or permit, do not take effect; actions to
be taken on packets matching the ACL depend on the traffic behavior definition in QoS. For details
about traffic behavior, refer to the QoS part in this manual.
13-1

z Software-based application: An ACL is referenced by a piece of upper layer software. For
example, an ACL can be referenced to configure login user control behavior, thus controlling
Telnet, SNMP and Web users. Note that when an ACL is reference by the upper layer software,
actions to be taken on packets matching the ACL depend on those defined by the ACL rules. For
details about login user control, refer to the part about login configuration in this manual.
z When an ACL is assigned to a piece of hardware and referenced by a QoS policy for traffic
classification, the switch does not take action according to the traffic behavior definition on a
packet that does not match the ACL.
z When an ACL is referenced by a piece of software to control Telnet, SNMP, and Web login users,
the switch denies all packets that do not match the ACL.
Introduction to IPv4 ACL

z IPv4 ACL Classification
z IPv4 ACL Naming
z IPv4 ACL Match Order
z IPv4 ACL Step
z Effective Period of an IPv4 ACL
z IP Fragments Filtering with IPv4 ACL
IPv4 ACL Classification
IPv4 ACLs, identified by ACL numbers, fall into three categories, as shown in Table 13-1.
Table 13-1 IPv4 ACL categories
Category ACL number Matching criteria

Basic IPv4 ACL 2000 to 2999 Source IP address
Source IP address, destination IP address,
Advanced IPv4 ACL 3000 to 3999 protocol carried over IP, and other Layer 3 or
Layer 4 protocol header information
Layer 2 protocol header fields such as source
Ethernet frame header
4000 to 4999 MAC address, destination MAC address, 802.1p
ACL
priority, and link layer protocol type
IPv4 ACL Naming
When creating an IPv4 ACL, you can specify a unique name for it. Afterwards, you can identify the ACL
by its name.
An IPv4 ACL can have only one name. Whether to specify a name for an ACL is up to you. After
creating an ACL, you cannot specify a name for it, nor can you change or remove its name.
13-2

The name of an IPv4 ACL must be unique among IPv4 ACLs. However, an IPv4 ACL and an IPv6 ACL
can share the same name.
IPv4 ACL Match Order
An ACL may consist of multiple rules, which specify different matching criteria. These criteria may have
overlapping or conflicting parts. The match order is for determining how packets should be matched
against the rules.
Two match orders are available for IPv4 ACLs:
z config: Packets are compared against ACL rules in the order the rules are configured.
z auto: Packets are compared against ACL rules in the depth-first match order.
The term depth-first match has different meanings for different types of ACLs:
Depth-first match for a basic IPv4 ACL
The following shows how your device performs depth-first match in a basic IPv4 ACL:
1) Sort rules by VPN instance first and compare packets against the rule configured with a VPN
instance.
2) In case of a tie, sort rules by source IP address wildcard and compare packets against the rule
configured with more zeros in the source IP address wildcard.
3) If two rules are present with the same number of zeros in their source IP address wildcards,
compare packets against the rule configured first.
Depth-first match for an advanced IPv4 ACL
The following shows how your device performs depth-first match in an advanced IPv4 ACL:
1) Sort rules by VPN instance first and compare packets against the rule configured with a VPN
instance.
2) In case of a tie, look at the protocol carried over IP. A rule with no limit to the protocol type (that is,
configured with the ip keyword) has the lowest precedence. Rules each of which has a single
specified protocol type are of the same precedence level.
3) If the protocol types have the same precedence, look at the source IP address wildcards. Then,
compare packets against the rule configured with more zeros in the source IP address wildcard.
4) If the numbers of zeros in the source IP address wildcards are the same, look at the destination IP
address wildcards. Then, compare packets against the rule configured with more zeros in the
destination IP address wildcard.
5) If the numbers of zeros in the destination IP address wildcards are the same, look at the Layer 4
port number ranges, namely the TCP/UDP port number ranges. Then compare packets against
the rule configured with the smaller port number range.
6) If the port number ranges are the same, compare packets against the rule configured first.
Depth-first match for an Ethernet frame header ACL
The following shows how your device performs depth-first match in an Ethernet frame header ACL:
13-3

1) Sort rules by source MAC address mask first and compare packets against the rule configured
with more ones in the source MAC address mask.
2) If two rules are present with the same number of ones in their source MAC address masks, look at
the destination MAC address masks. Then, compare packets against the rule configured with
more ones in the destination MAC address mask.
3) If the numbers of ones in the destination MAC address masks are the same, compare packets
against the one configured first.
The comparison of a packet against ACL rules stops immediately after a match is found. The packet is
then processed as per the rule.
IPv4 ACL Step
Meaning of the step
The step defines the difference between two neighboring numbers that are automatically assigned to
ACL rules by the device. For example, with a step of 5, rules are automatically numbered 0, 5, 10, 15,
and so on. By default, the step is 5.
Whenever the step changes, the rules are renumbered, starting from 0. For example, if four rules are
numbered 5, 10, 15, and 20 respectively, changing the step from 5 to 2 will cause the rules to be
renumbered 0, 2, 4, and 6.
Benefits of using the step
With the step and rule numbering/renumbering mechanism, you do not need to assign numbers to
rules when defining them. The system will assign a newly defined rule a number that is the smallest
multiple of the step bigger than the current biggest number. For example, with a step of five, if the
biggest number is currently 28, the newly defined rule will get a number of 30. If the ACL has no rule
defined already, the first defined rule will get a number of 0.
Another benefit of using the step is that it allows you to insert new rules between existing ones as
needed. For example, after creating four rules numbered 0, 5, 10, and 15 in an ACL with a step of five,
you can insert a rule numbered 1.
Effective Period of an IPv4 ACL
You can control when a rule can take effect by referencing a time range in the rule.
A referenced time range can be one that has not been created yet. The rule, however, can take effect
only after the time range is defined and becomes active.
IP Fragments Filtering with IPv4 ACL
Traditional packet filtering performs match operation on, rather than all IP fragments, the first ones only.
All subsequent non-first fragments are handled in the way the first fragments are handled. This causes
security risk as attackers may fabricate non-first fragments to attack your network.
As for the configuration of a rule of an IPv4 ACL, the fragment keyword specifies that the rule applies
to non-first fragment packets only, and does not apply to non-fragment packets or the first fragment
packets. ACL rules that do not contain this keyword is applicable to both non-fragment packets and
fragment packets.
13-4

Introduction to IPv6 ACL
z IPv6 ACL Classification
z IPv6 ACL Naming
z IPv6 ACL Match Order
z IPv6 ACL Step
z Effective Period of an IPv6 ACL
IPv6 ACL Classification
IPv6 ACLs, identified by ACL numbers, fall into three categories, as shown in Table 13-2.
Table 13-2 IPv6 ACL categories
Category ACL number Matching criteria

Basic IPv6 ACL 2000 to 2999 Source IPv6 address
Source IPv6 address, destination IPv6 address,
Advanced IPv6 ACL 3000 to 3999 protocol carried over IPv6, and other Layer 3 or
Layer 4 protocol header information
IPv6 ACL Naming
When creating an IPv6 ACL, you can specify a unique name for it. Afterwards, you can identify the
IPv6 ACL by its name.
An IPv6 ACL can have only one name. Whether to specify a name for an ACL is up to you. After
creating an ACL, you cannot specify a name for it, nor can you change or remove its name.
The name of an IPv6 ACL must be unique among IPv6 ACLs. However, an IPv6 ACL and an IPv4 ACL
can share the same name.
IPv6 ACL Match Order
Similar to IPv4 ACLs, an IPv6 ACL consists of multiple rules, each of which specifies different matching
criteria. These criteria may have overlapping or conflicting parts. The match order is for determining
how a packet should be matched against the rules.
Two match orders are available for IPv6 ACLs:
z config: Packets are compared against ACL rules in the order the rules are configured.
z auto: Packets are compared against ACL rules in the depth-first match order.
The term depth-first match has different meanings for different types of IPv6 ACLs:
Depth-first match for a basic IPv6 ACL
The following shows how your device performs depth-first match in a basic IPv6 ACL:
13-5

1) Sort rules by source IPv6 address prefix first and compare packets against the rule configured
with a longer prefix for the source IPv6 address.
2) In case of a tie, compare packets against the rule configured first.
Depth-first match for an advanced IPv6 ACL
The following shows how your device performs depth-first match in an advanced IPv6 ACL:
1) Look at the protocol type field in the rules first. A rule with no limit to the protocol type (that is,
configured with the ipv6 keyword) has the lowest precedence. Rules each of which has a single
specified protocol type are of the same precedence level. Compare packets against the rule with
the highest precedence.
2) In case of a tie, look at the source IPv6 address prefixes. Then, compare packets against the rule
configured with a longer prefix for the source IPv6 address.
3) If the prefix lengths for the source IPv6 addresses are the same, look at the destination IPv6
address prefixes. Then, compare packets against the rule configured with a longer prefix for the
destination IPv6 address.
4) If the prefix lengths for the destination IPv6 addresses are the same, look at the Layer 4 port
number ranges, namely the TCP/UDP port number ranges. Then compare packets against the
rule configured with the smaller port number range.
5) If the port number ranges are the same, compare packets against the rule configured first.
The comparison of a packet against an ACL stops immediately after a match is found. The packet is
then processed as per the rule.
IPv6 ACL Step
Refer to IPv4 ACL Step.
Effective Period of an IPv6 ACL
Refer to Effective Period of an IPv4 ACL.
ACL Application
ACLs are widely used in technologies. One typical application is to apply different types of ACLs for
traffic filtering. For details, refer to ACL Application for Packet Filtering.
In addition, ACLs can be used in such fields as routing, security, and QoS. For configuration details,
refer to the related parts of this configuration manual.
13-6

14 IPv4 ACL Configuration
When configuring an IPv4 ACL, go to these sections for information you are interested in:
z Configuring a Basic IPv4 ACL
z Configuring an Ethernet Frame Header ACL
z Displaying and Maintaining IPv4 ACLs
z IPv4 ACL Configuration Example
Creating a Time Range

Two types of time ranges are available:
z Periodic time range, which recurs periodically on the day or days of the week.
z Absolute time range, which takes effect only in a period of time and does not recur.
Follow these steps to create a time range:

time-range time-range-name
{ start-time to end-time days [ from
Create a time range time1 date1 ] [ to time2 date2 ] | from Required
time1 date1 [ to time2 date2 ] | to
time2 date2 }
Display the configuration Optional
display time-range
and status of one or all time
{ time-range-name | all } Available in any view
ranges
You may create a maximum of 256 time ranges.

A time range can be one of the following:
z Periodic time range created using the time-range time-range-name start-time to end-time days
command. A time range thus created recurs periodically on the day or days of the week. A
periodic time range is active only when the system time falls within it.
z Absolute time range created using the time-range time-range-name { from time1 date1 [ to time2
date2 ] | to time2 date2 } command. Unlike a periodic time range, a time range thus created does
not recur. For example, to create an absolute time range that is active between January 1, 2004
00:00 and December 31, 2004 23:59, you may use the time-range test from 00:00 01/01/2004 to
23:59 12/31/2004 command.
z Compound time range created using the time-range time-range-name start-time to end-time days
{ from time1 date1 [ to time2 date2 ] | to time2 date2 } command. A time range thus created
14-1

recurs on the day or days of the week only within the specified period. For example, to create a
time range that is active from 12:00 to 14:00 on Wednesdays between January 1, 2004 00:00 and
December 31, 2004 23:59, you may use the time-range test 12:00 to 14:00 wednesday from
00:00 01/01/2004 to 23:59 12/31/2004 command.
z You may create individual time ranges identified with the same name. They are regarded as one
time range whose active period is the result of ORing periodic ones, ORing absolute ones, and
ANDing periodic and absolute ones.
z If you do not specify the start time and date, the time range starts from the earliest time that the
system supports, namely 00:00 01/01/1970. If you do not specify the end time and date, the time
range ends at the latest time that the system supports, namely 24:00 12/31/2100.
# Create a time range that is active from 8:00 to 18:00 every working day.
[Sysname] time-range test 8:00 to 18:00 working-day
# Verify the configuration.

[Sysname] display time-range test
Current time is 22:17:42 1/5/2006 Thursday
Time-range : test ( Inactive )

08:00 to 18:00 working-day
# Create an absolute time range from 15:00, Jan 28, 2006 to 15:00, Jan 28, 2008.
[Sysname] time-range test from 15:00 1/28/2006 to 15:00 1/28/2008
[Sysname] display time-range test
Current time is 22:20:18 1/5/2006 Thursday
Time-range : test ( Inactive )

from 15:00 1/28/2006 to 15:00 1/28/2008
Configuring a Basic IPv4 ACL

Basic IPv4 ACLs match packets based on only source IP address. They are numbered from 2000 to
2999.
If you want to reference a time range in a rule, define it with the time-range command first.
14-2

Follow these steps to configure a basic IPv4 ACL:

Required
acl number acl-number The default match order is config.
Create a basic IPv4 ACL [ name acl-name ] If you specify a name for an IPv4 ACL
and enter its view [ match-order { auto | when creating the ACL, you can use
config } ] the acl name acl-name command to
enter the view of the ACL later.
rule [ rule-id ] { deny | Required

permit } [ fragment | logging To create or modify multiple rules,
| source { sour-addr repeat this step.
Create or modify a rule sour-wildcard | any } | Note that the logging keyword is not
time-range time-range-name supported if the ACL is to be
| vpn-instance referenced by a QoS policy for traffic
vpn-instance-name ] * classification.
Set the rule numbering Optional

step step-value
step 5 by default
Optional
Configure a description
description text By default, a basic IPv4 ACL has no
for the basic IPv4 ACL
ACL description.
Optional
Configure a rule
rule rule-id comment text By default, an IPv4 ACL rule has no
description
rule description.
Note that:
z You can only modify the existing rules of an ACL that uses the match order of config. When
modifying a rule of such an ACL, you may choose to change just some of the settings, in which
case the other settings remain the same.
z You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an
existing rule in the ACL.
z When the ACL match order is auto, a newly created rule will be inserted among the existing rules
in the depth-first match order. Note that the IDs of the rules still remain the same.
z You can modify the match order of an ACL with the acl number acl-number [ name acl-name ]
match-order { auto | config } command, but only when the ACL does not contain any rules.
z The rule specified in the rule comment command must already exist.
# Configure IPv4 ACL 2000 to deny packets with source address 1.1.1.1.
14-3

[Sysname-acl-basic-2000] rule deny source 1.1.1.1 0

[Sysname-acl-basic-2000] display acl 2000
Basic ACL 2000, named -none-, 1 rule,
ACL's step is 5
rule 0 deny source 1.1.1.1 0 (5 times matched)
Configuring an Advanced IPv4 ACL

Advanced IPv4 ACLs match packets based on source IP address, destination IP address, protocol
carried over IP, and other protocol header fields, such as the TCP/UDP source port number, TCP/UDP
destination port number, TCP flag, ICMP message type, and ICMP message code.
In addition, advanced IPv4 ACLs allow you to filter packets based on three priority criteria: type of
service (ToS), IP precedence, and differentiated services codepoint (DSCP) priority.
Advanced IPv4 ACLs are numbered in the range 3000 to 3999. Compared with basic IPv4 ACLs, they
allow of more flexible and accurate filtering.
Follow these steps to configure an advanced IPv4 ACL:

Required
The default match order is config.
Create an advanced acl number acl-number [ name If you specify a name for an IPv4
IPv4 ACL and enter its acl-name ] [ match-order { auto | ACL when creating the ACL, you
view config } ] can use the acl name acl-name
command to enter the view of the
ACL later.
14-4

rule [ rule-id ] { deny | permit }
protocol [ { established | { ack
ack-value | fin fin-value | psh
Required
psh-value | rst rst-value | syn
syn-value | urg urg-value } * } | To create or modify multiple rules,
destination { dest-addr repeat this step.
dest-wildcard | any } | Note that if the ACL is to be
destination-port operator port1 referenced by a QoS policy for traffic
[ port2 ] | dscp dscp | fragment | classification, the logging and
Create or modify a rule icmp-type { icmp-type icmp-code reflective keywords are not
| icmp-message } | logging | supported and the operator
precedence precedence | argument cannot be:
reflective | source { sour-addr
sour-wildcard | any } | z neq, if the policy is for the
source-port operator port1 inbound traffic,
[ port2 ] | time-range z gt, lt, neq or range, if the policy
time-range-name | tos tos | is for the outbound traffic.
vpn-instance
vpn-instance-name ] *

step step-value
step 5 by default
Configure a description Optional

for the advanced IPv4 description text By default, an advanced IPv4 ACL
ACL has no ACL description.
Optional
Configure a rule
description
rule description.
Note that:
# Configure IPv4 ACL 3000 to permit TCP packets with the destination port number of 80 from
129.9.0.0 to 202.38.160.0.
14-5

[Sysname-acl-adv-3000] rule permit tcp source 129.9.0.0 0.0.255.255 destination 202.38.160.0
0.0.0.255 destination-port eq 80

[Sysname-acl-adv-3000] display acl 3000
Advanced ACL 3000, named -none-, 1 rule,
ACL's step is 5
rule 0 permit tcp source 129.9.0.0 0.0.255.255 destination 202.38.160.0 0.0.0.255
destination-port eq www (5 times matched)
Configuring an Ethernet Frame Header ACL

Ethernet frame header ACLs match packets based on Layer 2 protocol header fields such as source
MAC address, destination MAC address, 802.1p priority (VLAN priority), and link layer protocol type.
They are numbered in the range 4000 to 4999.
Follow these steps to configure an Ethernet frame header ACL:

Required
Create an Ethernet acl number acl-number [ name If you specify a name for an IPv4
frame header ACL acl-name ] [ match-order { auto | ACL when creating the ACL, you can
and enter its view config } ] use the acl name acl-name
command to enter the view of the
ACL later.
rule [ rule-id ] { deny | permit } [ cos Required

vlan-pri | dest-mac dest-addr To create or modify multiple rules,
dest-mask | lsap lsap-code repeat this step.
Create or modify a
lsap-wildcard | source-mac Note that the lsap keyword is not
rule
sour-addr source-mask | time-range supported if the ACL is to be
time-range-name | type type-code referenced by a QoS policy for traffic
type-wildcard ] * classification.
Set the rule Optional

step step-value
numbering step 5 by default
Configure a Optional
description for the
description text By default, an Ethernet frame header
Ethernet frame
header ACL ACL has no ACL description.
Optional
Configure a rule
rule rule-id comment text By default, an Ethernet frame header
description
ACL rule has no rule description.
14-6

Note that:
# Configure ACL 4000 to deny frames with the 802.1p priority of 3.

[Sysname-acl-ethernetframe-4000] rule deny cos 3

[Sysname-acl-ethernetframe-4000] display acl 4000
Ethernet frame ACL 4000, named -none-, 1 rule,
ACL's step is 5
rule 0 deny cos excellent-effort(5 times matched)
Copying an IPv4 ACL

This feature allows you to copy an existing IPv4 ACL to generate a new one, which is of the same type
and has the same match order, rules, rule numbering step and descriptions as the source IPv4 ACL.
Make sure that the source IPv4 ACL exists while the destination IPv4 ACL does not.
Follow these steps to copy an IPv4 ACL:

14-7

Copy an existing IPv4 ACL to acl copy { source-acl-number | name
generate a new one of the source-acl-name } to { dest-acl-number Required
same type | name dest-acl-name }
z The source IPv4 ACL and the destination IPv4 ACL must be of the same type.
z The destination ACL does not take the name of the source IPv4 ACL.
Displaying and Maintaining IPv4 ACLs

Display information about one or all IPv4 display acl { acl-number | all | Available in any
ACLs name acl-name } view
Display information about ACL uses of a Available in any
display acl resource
switch view
Display the configuration and state of a display time-range Available in any
specified or all time ranges { time-range-name | all } view
Clear statistics about a specified or all
reset acl counter { acl-number | Available in user
IPv4 ACLs that are referenced by upper
all | name acl-name } view
layer software
IPv4 ACL Configuration Example

As shown in Figure 14-1, a company interconnects its departments through the switch.
Configure an ACL to deny access of all departments but the Presidents office to the salary query
server during office hours (from 8:00 to 18:00) in working days.
14-8

Figure 14-1 Network diagram for IPv4 ACL configuration
President`s office
192.168.1.0/24 Salary query server
192.168.4.1
GE1/0/1 GE1/0/4
GE1/0/2 GE1/0/3
Switch
R&D department Marketing department

192.168.2.0/24 192.168.3.0/24
1) Create a time range for office hours

# Create a periodic time range spanning 8:00 to 18:00 in working days.
[Switch] time-range trname 8:00 to 18:00 working-day
2) Define an ACL to control access to the salary query server
# Configure a rule to control access of the R&D Department to the salary query server.
[Switch] acl number 3000
[Switch-acl-adv-3000] rule deny ip source 192.168.2.0 0.0.0.255 destination 192.168.4.1
0.0.0.0 time-range trname
[Switch-acl-adv-3000] quit
# Configure a rule to control access of the Marketing Department to the salary query server.
[Switch] acl number 3001
[Switch-acl-adv-3001] rule deny ip source 192.168.3.0 0.0.0.255 destination 192.168.4.1
0.0.0.0 time-range trname
[Switch-acl-adv-3001] quit
3) Apply the IPv4 ACL
# Configure class c_rd for packets matching IPv4 ACL 3000.
[Switch] traffic classifier c_rd
[Switch-classifier-c_rd] if-match acl 3000
[Switch-classifier-c_rd] quit
# Configure traffic behavior b_rd to deny matching packets.

[Switch] traffic behavior b_rd
[Switch-behavior-b_rd] filter deny
[Switch-behavior-b_rd] quit
# Configure class c_market for packets matching IPv4 ACL 3001.

[Switch] traffic classifier c_market
14-9

[Switch-classifier-c_market] if-match acl 3001
[Switch-classifier-c_market] quit
# Configure traffic behavior b_ market to deny matching packets.

[Switch] traffic behavior b_market
[Switch-behavior-b_market] filter deny
[Switch-behavior-b_market] quit
# Configure QoS policy p_rd to use traffic behavior b_rd for class c_rd.
[Switch] qos policy p_rd
[Switch-qospolicy-p_rd] classifier c_rd behavior b_rd
[Switch-qospolicy-p_rd] quit
# Configure QoS policy p_market to use traffic behavior b_market for class c_market.
[Switch] qos policy p_market
[Switch-qospolicy-p_market] classifier c_market behavior b_market
[Switch-qospolicy-p_market] quit
# Apply QoS policy p_rd to interface GigabitEthernet 1/0/2.

[Switch-GigabitEthernet1/0/2] qos apply policy p_rd inbound
# Apply QoS policy p_market to interface GigabitEthernet 1/0/3.

[Switch-GigabitEthernet1/0/3] qos apply policy p_market inbound
14-10

15 IPv6 ACL Configuration
When configuring IPv6 ACLs, go to these sections for information you are interested in:
z Configuring a Basic IPv6 ACL
z Displaying and Maintaining IPv6 ACLs
z IPv6 ACL Configuration Example
Creating a Time Range

Refer to Creating a Time Range.
Configuring a Basic IPv6 ACL

Basic IPv6 ACLs match packets based on only source IPv6 address. They are numbered in the range
2000 to 2999.
Follow these steps to configure an IPv6 ACL:

Required
acl ipv6 number The default match order is config.
Create a basic IPv6
acl6-number [ name If you specify a name for an IPv6 ACL
ACL view and enter its
acl6-name ] [ match-order when creating the ACL, you can use the
view
{ auto | config } ] acl ipv6 name acl6-name command to
enter the view of the ACL later.
rule [ rule-id ] { deny | Required

permit } [ fragment | To create or modify multiple rules, repeat
logging | source this step.
Create or modify a rule { ipv6-address prefix-length Note that the logging and fragment
| ipv6-address/prefix-length | keywords are not supported if the ACL is
any } | time-range to be referenced by a QoS policy for traffic
time-range-name ] * classification.

step step-value
step 5 by default
15-1

Optional
Configure a description
description text By default, a basic IPv6 ACL has no ACL
for the basic IPv6 ACL
description.
Optional
Configure a rule
rule rule-id comment text By default, an IPv6 ACL rule has no rule
description
description.
Note that:
z You can modify the match order of an IPv6 ACL with the acl ipv6 number acl6-number [ name
acl6-name ] match-order { auto | config } command, but only when the ACL does not contain any
rules.
# Configure IPv6 ACL 2000 to permit IPv6 packets with the source address of 2030:5060::9050/64 and
deny IPv6 packets with the source address of fe80:5060::8050/96.
[Sysname] acl ipv6 number 2000
[Sysname-acl6-basic-2000] rule permit source 2030:5060::9050/64
[Sysname-acl6-basic-2000] rule deny source fe80:5060::8050/96

[Sysname-acl6-basic-2000] display acl ipv6 2000
Basic IPv6 ACL 2000, named -none-, 2 rules,
ACL's step is 5
rule 0 permit source 2030:5060::9050/64 (4 times matched)
rule 5 deny source FE80:5060::8050/96 (5 times matched)
Configuring an Advanced IPv6 ACL

Advanced IPv6 ACLs match packets based on the source IPv6 address, destination IPv6 address,
protocol carried over IPv6, and other protocol header fields such as the TCP/UDP source port number,
TCP/UDP destination port number, ICMP message type, and ICMP message code.
15-2

Advanced IPv6 ACLs are numbered in the range 3000 to 3999. Compared with basic IPv6 ACLs, they
allow of more flexible and accurate filtering.
Follow these steps to configure an advanced IPv6 ACL:

Required
Create an advanced acl ipv6 number acl6-number If you specify a name for an IPv6 ACL
IPv6 ACL and enter [ name acl6-name ] [ match-order when creating the ACL, you can use
its view { auto | config } ] the acl ipv6 name acl6-name
command to enter the view of the ACL
later.
rule [ rule-id ] { deny | permit }
protocol [ { established | { ack
ack-value | fin fin-value | psh Required
psh-value | rst rst-value | syn To create or modify multiple rules,
syn-value | urg urg-value } * } | repeat this step.
destination { dest dest-prefix |
dest/dest-prefix | any } | Note that if the ACL is to be
destination-port operator port1 referenced by a QoS policy for traffic
Create or modify a classification, the logging and
[ port2 ] | dscp dscp | fragment |
rule fragment keywords are not supported
icmpv6-type { icmpv6-type
icmpv6-code | icmpv6-message } | and the operator argument cannot be:
logging | source { source z neq, if the policy is for the inbound
source-prefix | traffic,
source/source-prefix | any } | z gt, lt, neq or range, if the policy is
source-port operator port1 for the outbound traffic.
[ port2 ] | time-range
time-range-name ] *
Set the rule Optional

step step-value
numbering step 5 by default
Configure a Optional
description for the description text By default, an advanced IPv6 ACL
advanced IPv6 ACL has no ACL description.
Optional
Configure a rule
description
rule description.
Note that:
15-3

z You can modify the match order of an IPv6 ACL with the acl ipv6 number acl6-number [ name
acl6-name ] match-order { auto | config } command, but only when the ACL does not contain any
rules.
# Configure IPv6 ACL 3000 to permit TCP packets with the source address of 2030:5060::9050/64.
[Sysname] acl ipv6 number 3000
[Sysname-acl6-adv-3000] rule permit tcp source 2030:5060::9050/64

[Sysname-acl6-adv-3000] display acl ipv6 3000
Advanced IPv6 ACL 3000, named -none-, 1 rule,
ACL's step is 5
rule 0 permit tcp source 2030:5060::9050/64 (5 times matched)
Copying an IPv6 ACL

This feature allows you to copy an existing IPv6 ACL to generate a new one, which is of the same type
and has the same match order, rules, rule numbering step, and descriptions as the source IPv6 ACL.
Make sure that the source IPv6 ACL exists while the destination IPv6 ACL does not.
Follow these steps to copy an IPv6 ACL:

Copy an existing IPv6 ACL acl ipv6 copy { source-acl6-number | name

to generate a new one of source-acl6-name } to { dest-acl6-number | Required
the same type name dest-acl6-name }
15-4

z The source IPv6 ACL and the destination IPv6 ACL must be of the same type.
z The destination ACL does not take the name of the source IPv6 ACL.
Displaying and Maintaining IPv6 ACLs

Display information about one or all display acl ipv6 { acl6-number | all | Available in any
IPv6 ACLs name acl6-name } view
Display information about ACL uses of Available in any
display acl resource
a switch view
Display the configuration and status on display time-range Available in any
time range { time-range-name | all } view
Clear statistics about a specified or all reset acl ipv6 counter
Available in user
IPv6 ACLs that are referenced by upper { acl6-number | all | name
view
layer software acl6-name }
IPv6 ACL Configuration Example

As shown in Figure 15-1, a company interconnects its departments through the switch.
Configure an ACL to deny access of the R&D department to external networks.
Figure 15-1 Network diagram for IPv6 ACL configuration
# Create an IPv6 ACL 2000.

[Switch] acl ipv6 number 2000
[Switch-acl6-basic-2000] rule deny source 4050::9000/120
[Switch-acl6-basic-2000] quit
# Configure class c_rd for packets matching IPv6 ACL 2000.
15-5

[Switch] traffic classifier c_rd
[Switch-classifier-c_rd] if-match acl ipv6 2000
[Switch-classifier-c_rd] quit
# Configure traffic behavior b_rd to deny matching packets.

[Switch] traffic behavior b_rd
[Switch-behavior-b_rd] filter deny
[Switch-behavior-b_rd] quit
# Configure QoS policy p_rd to use traffic behavior b_rd for class c_rd.
[Switch] qos policy p_rd
[Switch-qospolicy-p_rd] classifier c_rd behavior b_rd
[Switch-qospolicy-p_rd] quit
# Apply QoS policy p_rd to interface GigabitEthernet 1/0/1.

[Switch-GigabitEthernet1/0/1] qos apply policy p_rd inbound
15-6

16 ACL Application for Packet Filtering
When applying an ACL for packet filtering, go to these sections for information you are interested in:
z Filtering Ethernet Frames
z Configuring Packet Filtering Statistics Function
z ACL Application Examples
You can apply an ACL to the inbound or outbound direction of an ethernet interface or VLAN interface
to filter received or sent packets such as Ethernet frames, IPv4 packets, and IPv6 packets.
Filtering Ethernet Frames

Follow these steps to apply an Ethernet frame header ACL to an interface to filter Ethernet frames:


Enter interface view interface-number
interface Use either command
view Enter VLAN interface vlan-interface
interface view vlan-id
Apply an Ethernet frame packet-filter { acl-number | Required

header ACL to the interface to name acl-name } { inbound | By default, an interface does
filter Ethernet frames outbound } not filter Ethernet frames.
Filtering IPv4 Packets

Follow these steps to apply an IPv4 ACL to an interface to filter IPv4 packets:


view Enter VLAN interface vlan-interface
interface view vlan-id
Apply a basic or advanced packet-filter { acl-number | Required

IPv4 ACL to the interface to name acl-name } { inbound | By default, an interface does
filter IPv4 packets outbound } not filter IPv4 packets.
16-1

Filtering IPv6 Packets
Follow these steps to apply an IPv6 ACL to an interface to filter IPv6 packets:


view Enter VLAN interface
interface vlan-interface vlan-id
view
Required
packet-filter ipv6 { acl6-number
Apply a basic or advanced IPv6 ACL By default, no IPv6 ACL
| name acl6-name } { inbound |
to the interface to filter IPv6 packets is applied to the
outbound }
interface.
Configuring Packet Filtering Statistics Function

The Switch 4510G series switches provide the packet filtering statistics function so that the device can
output packet filtering statistics information at a specified interval. With the output, you are able to
know how many packets are filtered by which ACL rules.
The packet filtering statistics function takes effect for only rules with the logging keyword specified.
z The packet filtering statistics are managed and output as device log information by the information
center.
z The packet filtering statistics are of the severity level of 6, that is, informational. Informational
messages are not output to the console by default; therefore, you need to modify the log
information output rule for the informational message output to be sent to the console or other
destinations.
z For introduction and configuration of the information center, refer to Information Center
Configuration in the System Volume.
Follow the steps to set the intervals for packet filtering statistics so that the device outputs packet
filtering statistics at the end of every interval:

Set the interval for IPv4 packet acl logging frequence Configure a command as
filtering statistics frequence required.
0 by default, which means no
Set the interval for IPv6 packet acl ipv6 logging frequence packet filtering statistics is
filtering statistics frequence collected.
16-2

If you execute the display acl command to display the information about the ACLs, the device outputs
packet filtering statistics except those that have been displayed by the command during that interval.
ACL Application Examples

ACL Application to an Ethernet Interface
As shown in Figure 16-1, apply an ACL to the inbound direction of interface GigabitEthernet 1/0/1 on
Device A so that the interface denies IPv4 packets sourced from Host A from 8:00 to 18:00 everyday.
Configure the device to output log information about how many packets are filtered by this ACL to the
console at an interval of 10 minutes.
Figure 16-1 Network diagram for applying an ACL to an interface for filtering
Host A GE1/0/1
192.168.1.2/24 IP network
Device A
Host B
192.168.1.3/24
# Create a time range named study, setting it to become active from 08:00 to 18:00 everyday.
[DeviceA] time-range study 8:00 to 18:00 daily
# Create basic IPv4 ACL 2009.

# Create a basic IPv4 ACL rule to deny packets sourced from 192.168.1.2/32 during time range study.
[DeviceA-acl-basic-2009] rule deny source 192.168.1.2 0 time-range study
# Apply ACL 2009 to the inbound direction of interface GigabitEthernet 1/0/1.

[DeviceA-GigabitEthernet1/0/1] packet-filter 2009 inbound
# Set the interval for packet filtering statistics to 10 minutes.

[DeviceA] acl logging frequence 10
# Configure a system information output rule to output log information with severity being
informational to the console.
16-3

[DeviceA] info-center source default channel 0 log level informational
ACL Application to a VLAN Interface

As shown in Figure 16-2, apply an ACL to the inbound direction of interface VLAN-interface 100 on
Device A so that the interface denies IPv4 packets sourced from Host A from 14:00 to 18:00 of the
working days, and allows packets traveling between Host A and Host B.
Figure 16-2 Network diagram for applying an ACL to a VLAN interface for filtering
Host A
192.168.1.2
Vlan-int100
192.168.1.1
Server
192.168.5.100
Host B
192.168.1.3
# Create a time range named study, setting it to become active from 08:00 to 18:00 of the working
days.
[DeviceA] time-range study 14:00 to 18:00 working-day
# Create basic IPv4 ACL 2010.

# Create a basic IPv4 ACL rule to deny packets sourced from 192.168.1.2/32 during time range study.
[DeviceA-acl-basic-2009] rule deny source 192.168.1.2 0 time-range study
# Apply ACL 2010 to the inbound direction of interface VLAN-interface 100,

[DeviceA] interface vlan-interface 100
[DeviceA-Vlan-interface100] packet-filter 2010 inbound
16-4

Table of Contents
1 Smart Link Configuration 1-1

Smart Link Overview 1-1
Terminology1-2
How Smart Link Works 1-3
Smart Link Configuration Task List 1-4
Configuring a Smart Link Device 1-4
Configuring Protected VLANs for a Smart Link Group1-5
Configuring Member Ports for a Smart Link Group1-5
Configuring Role Preemption for a Smart Link Group1-6
Enabling the Sending of Flush Messages 1-6
Smart Link Device Configuration Example1-7
Configuring an Associated Device 1-7
Enabling the Receiving of Flush Messages 1-7
Associated Device Configuration Example 1-8
Displaying and Maintaining Smart Link1-8
Smart Link Configuration Examples1-9
Single Smart Link Group Configuration Example1-9
Multiple Smart Link Groups Load Sharing Configuration Example1-13
2 Monitor Link Configuration 2-1

Overview 2-1
Terminology2-1
How Monitor Link Works2-1
Configuring Monitor Link 2-2
Monitor Link Configuration Example 2-2
Displaying and Maintaining Monitor Link 2-3
Monitor Link Configuration Example 2-3
3 RRPP Configuration 3-1

RRPP Overview 3-1
Background 3-1
Basic Concepts in RRPP3-2
RRPPDUs3-4
RRPP Timers3-5
How RRPP Works 3-5
Typical RRPP Networking 3-6
RRPP Configuration Task List 3-9
Creating an RRPP Domain 3-10
Configuring Control VLANs3-11
Configuring Protected VLANs 3-11
Configuring RRPP Rings 3-12
i

Configuring RRPP Ports3-12
Configuring RRPP Nodes3-13
Activating an RRPP Domain 3-15
Configuring RRPP Timers3-15
Configuring an RRPP Ring Group 3-16
Displaying and Maintaining RRPP 3-17
RRPP Configuration Examples3-17
Single Ring Configuration Example3-17
Intersecting Ring Configuration Example 3-19
Intersecting-Ring Load Balancing Configuration Example3-24
Troubleshooting 3-34
4 DLDP Configuration 4-1

Overview 4-1
Background 4-1
How DLDP Works4-2
DLDP Configuration Task List4-8
Enabling DLDP4-8
Setting DLDP Mode 4-9
Setting the Interval for Sending Advertisement Packets4-9
Setting the DelayDown Timer 4-10
Setting the Port Shutdown Mode 4-10
Configuring DLDP Authentication 4-11
Resetting DLDP State 4-11
Resetting DLDP State in System View4-12
Resetting DLDP State in Port view/Port Group View 4-12
Displaying and Maintaining DLDP 4-12
DLDP Configuration Example 4-13
Troubleshooting 4-15
5 Ethernet OAM Configuration 5-1

Ethernet OAM Overview 5-1
Background 5-1
Major Functions of Ethernet OAM 5-1
Ethernet OAMPDUs 5-1
How Ethernet OAM Works 5-3
Standards and Protocols 5-5
Ethernet OAM Configuration Task List 5-5
Configuring Basic Ethernet OAM Functions 5-6
Configuring Link Monitoring 5-6
Configuring Errored Symbol Event Detection 5-7
Configuring Errored Frame Event Detection 5-7
Configuring Errored Frame Period Event Detection5-7
Configuring Errored Frame Seconds Event Detection 5-7
Enabling OAM Remote Loopback5-8
Displaying and Maintaining Ethernet OAM Configuration5-9
Ethernet OAM Configuration Example5-9
6 Connectivity Fault Detection Configuration 6-1

Overview 6-1
ii

Basic Concepts in CFD 6-1
Basic Functions of CFD6-4
CFD Configuration Task List6-5
Basic Configuration Tasks 6-5
Configuring Service Instance 6-6
Configuring MEP 6-6
Configuring MIP Generation Rules6-7
Configuring CC on MEPs6-8
Configuring Procedure6-8
Configuring LB on MEPs6-8
Configuring LT on MEPs 6-9
Finding the Path Between a Source MEP and a Target MEP6-9
Enabling Automatic LT Messages Sending6-9
Displaying and Maintaining CFD6-10
CFD Configuration Examples 6-10
Configuring Service Instance 6-10
Configuring MEP and Enabling CC on it 6-11
Configuring the Rules for Generating MIPs 6-13
Configuring LB on MEPs 6-14
Configuring LT on MEPs 6-14
7 Track Configuration7-1
Track Overview 7-1
Collaboration Between the Track Module and the Detection Modules 7-1
Collaboration Between the Track Module and the Application Modules7-2
Track Configuration Task List 7-2
Configuring Collaboration Between the Track Module and the Detection Modules 7-2
Configuring Track-NQA Collaboration7-2
Configuring Collaboration Between the Track Module and the Application Modules7-3
Configuring Track-Static Routing Collaboration 7-3
Displaying and Maintaining Track Object(s) 7-4
Track Configuration Examples7-4
Static Routing-Track-NQA Collaboration Configuration Example7-4
iii

1 Smart Link Configuration
When configuring Smart Link, go to these sections for information that you are interested in:
z Smart Link Overview
z Configuring a Smart Link Device
z Configuring an Associated Device
z Displaying and Maintaining Smart Link
z Smart Link Configuration Examples
Smart Link Overview

To avoid single-point failures and guarantee network reliability, downstream devices are usually dual
uplinked to upstream devices. That is, a downstream device connects to two different upstream
devices, as shown in Figure 1-1.
Figure 1-1 Diagram for a dual uplink network
/1 GE
1/0 1/0
GE /2
/1 GE
1/0 1/0
/1
GE
GE /2
1/0 1/0
/2 GE
A dual uplink network demonstrates high reliability, but it may contain network loops. In most cases,
Spanning Tree Protocol (STP) or Rapid Ring Protection Protocol (RRPP) is used to remove network
loops. The problem with STP, however, is that STP convergence time is long, which makes it not
suitable for users who have high demand on convergence speed. RRPP can meet users demand on
1-1

convergence speed, but it involves complicated networking and configurations and therefore is mainly
used in ring-shaped networks.
For more information about STP and RRPP, refer to MSTP Configuration in the Access Volume and
RRPP Configuration in the High Availability Volume.
Smart Link is a feature developed to address the slow convergence issue with STP. It provides link
redundancy as well as fast convergence in a dual uplink network, allowing the backup link to take over
quickly when the primary link fails. To sum up, Smart Link features the following:
z Dedicated to dual uplink networks
z Subsecond convergence
z Easy to configure
Terminology
Smart link group
A smart link group consists of only two member ports: the master and the slave. At a time, only one
port is active for forwarding, and the other port is blocked, that is, in the standby state. When link failure
occurs on the active port due to port shutdown or presence of unidirectional link for example, the
standby port becomes active to take over while the original active port transits to the blocked state.
As shown in Figure 1-1, GE1/0/1 and GE1/0/2 of Device C and GE1/0/1 and GE1/0/2 of Device D each
form a smart link group, with GE1/0/1 being active and GE1/0/2 being standby.
Master/slave port
Master port and slave port are two port roles in a smart link group. When both ports in a smart link
group are up, the master port preferentially transits to the forwarding state, while the slave port stays in
the standby state. Once the master port fails, the slave port takes over to forward traffic.
As shown in Figure 1-1, you can configure GE1/0/1 of Device C and that of Device D as master ports,
and GE1/0/2 of Device C and that of Device D slave ports.
Master/slave link
The link that connects the master port in a smart link group is the master link; the link that connects the
slave port is the slave link.
Protected VLAN
A smart link group controls the forwarding state of some data VLANs, which are referred to as
protected VLANs. Different smart link groups on a port control different protected VLANs. The state of
the port in a protected VLAN is determined by the state of the port in the smart link group.
Transmit control VLAN
The transmit control VLAN is used for transmitting flush messages. When link switchover occurs, the
devices (such as Device C and Device D in Figure 1-1) broadcast flush messages within the transmit
control VLAN.
1-2

Receive control VLAN
The receive control VLAN is used for receiving and processing flush messages. When link switchover
occurs, the devices (such as Device A, Device B, and Device E in Figure 1-1) receive and process
flush messages in the receive control VLAN and refresh their MAC address forwarding entries and
ARP/ND entries.
Flush message
Flush messages are used by a smart link group to notify other devices to refresh their MAC address
forwarding entries and ARP/ND entries when link switchover occurs in the smart link group. Flush
messages are common multicast data packets, and will be dropped by a blocked receiving port.
How Smart Link Works
Link backup mechanism
As shown in Figure 1-1, the link on GE1/0/1 of Device C is the master link, and the link on GE1/0/2 of
Device C is the slave link. Normally, GE1/0/1 is in the forwarding state, while GE1/0/2 is in the standby
state. When the master link fails, GE1/0/2 takes over to forward traffic while GE1/0/1 is blocked and
placed in the standby state.
z When a port switches to the forwarding state, the system outputs log information to notify the user
of the port state change.
z To keep traffic forwarding stable, the master port that has been blocked due to link failure does not
take over immediately upon its recovery. Instead, link switchover will occur at next link switchover.
Topology change mechanism
As link switchover can outdate the MAC address forwarding entries and ARP/ND entries on all devices,
you need a forwarding entry update mechanism to ensure proper transmission. By far, the following
two update mechanisms are provided:
z Uplink traffic-triggered MAC address learning, where update is triggered by uplink traffic. This
mechanism is applicable to environments with devices not supporting smart link, including devices
of other vendors.
z Flush update where a Smart Link-enabled device updates its information by transmitting flush
messages over the backup link to its upstream devices. This mechanism requires the upstream
devices to be capable of recognizing smart link flush messages to update its MAC address
forwarding entries and ARP/ND entries.
Role preemption mechanism
As shown in Figure 1-1, the link on GE1/0/1 of Device C is the master link, and the link on GE1/0/2 of
Device C is the slave link. Once the master link fails, GE1/0/1 is automatically blocked and placed in
the standby state, while GE1/0/2 takes over to forward traffic. During this period, if the smart link group
is configured with role preemption, GE1/0/1 takes over to forward traffic as soon as the former master
link recovers, while GE1/0/2 is automatically blocked and placed in the standby state.
1-3

Load sharing mechanism
A ring network may carry traffic of multiple VLANs. Smart link can forward traffic of different VLANs in
different smart link groups, thus implementing load sharing.
To implement load sharing, you can assign a port to multiple smart link groups (each configured with
different protected VLANs), making sure that the state of the port is different in these smart link groups.
In this way, traffic of different VLANs can be forwarded along different paths.
You can configure protected VLANs for a smart link group by referencing MSTIs.
Smart Link Configuration Task List

Complete the following tasks to configure Smart Link:
Task Remarks
Configuring Protected VLANs for a Smart Link Group Required
Configuring a Smart Configuring Member Ports for a Smart Link Group Required
Link Device Configuring Role Preemption for a Smart Link Group Optional
Enabling the Sending of Flush Messages Optional
Configuring an
Enabling the Receiving of Flush Messages Required
Associated Device
z A smart link device is a device that supports Smart Link and is configured with a smart link group
and a transmit control VLAN for flush message transmission. Device C and Device D in Figure 1-1
are two examples of smart link devices.
z An associated device is a device that supports Smart Link, and receives flush messages sent from
the specified control VLAN. Device A, Device B, and Device E in Figure 1-1 are examples of
associated devices.
Configuring a Smart Link Device

z Before configuring a port as a smart link group member, shut down the port to prevent loops. You
can bring up the port only after completing the smart link group configuration.
z Disable STP and RRPP on the ports you want to add to the smart link group, and make sure that
the ports are not member ports of any aggregation group.
A loop may occur on the network during the time when STP is disabled but Smart Link has not yet
taken effect on a port.
1-4

Configuring Protected VLANs for a Smart Link Group
Follow these steps to configure the protected VLANs for a smart link group:

Create a smart link group and enter smart-link group group-id

smart link group view
Required
Configure protected VLANs for the protected-vlan reference-instance By default, no
smart link group instance-id-list protected VLAN is
configured for a smart
link group.
The protected-vlan command configures protected VLANs for a smart link group by referencing
MSTIs. To view VLAN-to-MSTI mappings, use the display stp region-configuration command. For
VLAN-to-MSTI mapping configuration, refer to MSTP Configuration in the Access Volume.
Configuring Member Ports for a Smart Link Group
You can configure member ports for a smart link group either in smart link group view or in interface
view. The configurations made in these two views have the same effect.
In smart link group view
Follow these steps to configure member ports for a smart link group in smart link group view:


port interface-type
Configure member ports for a smart
interface-number { master | Required
link group
slave }
In interface view
Follow these steps to configure member ports for a smart link group in interface view:

Enter Ethernet interface view or layer 2 interface interface-type

aggregate interface view interface-number
1-5

Configure member ports for a smart port smart-link group group-id
Required
link group { master | slave }
Configuring Role Preemption for a Smart Link Group
Follow these steps to configure role preemption for a smart link group:


Required
Enable role preemption preemption mode role
Optional
Configure the preemption delay preemption delay delay-time
1 second by default
The preemption delay configuration takes effect only after role preemption is enabled.
Enabling the Sending of Flush Messages
Follow these steps to enable the sending of flush messages:

Create a smart link group and enter smart-link group group-id Required
Optional
Enable flush update in the specified flush enable [ control-vlan By default, flush
control VLAN vlan-id ] update is enabled,
and VLAN 1 is the
control VLAN.
1-6

z The control VLAN configured for a smart link group must be different from that configured for any
other smart link group.
z Make sure that the configured control VLAN already exists, and assign the smart link group
member ports to the control VLAN.
z Do not remove the control VLAN. Otherwise, flush messages cannot be sent properly.
Smart Link Device Configuration Example
z Create smart link group 1.

z The protected VLANs of smart link group 1 are mapped to MSTI 0 through 8.
z Configure GigabitEthernet 1/0/1 as the master port of the smart link group, and GigabitEthernet
1/0/2 as the slave port.
z Configure VLAN 20 for flush update.
[Sysname] vlan 20
[Sysname-GigabitEthernet1/0/1] undo stp enable
[Sysname-GigabitEthernet1/0/1] port link-type trunk
[Sysname-GigabitEthernet1/0/1] port trunk permit vlan 20
[Sysname-GigabitEthernet1/0/2] undo stp enable
[Sysname] smart-link group 1
[Sysname-smlk-group1] protected-vlan reference-instance 0 to 8
[Sysname-smlk-group1] port gigabitethernet 1/0/1 master
[Sysname-smlk-group1] port gigabitethernet 1/0/2 slave
[Sysname-smlk-group1] flush enable control-vlan 20
[Sysname-smlk-group1] quit
Configuring an Associated Device

Enabling the Receiving of Flush Messages
You do not need to enable all ports on the associated devices to receive flush messages sent from the
transmit control VLAN, only those on the master and slave links between the smart link device and the
destination device.
Follow these steps to enable the receiving of flush messages:
1-7

Enter Ethernet interface view or interface interface-type

Layer 2 aggregate interface view interface-number
Required
Configure the control VLANs for smart-link flush enable By default, no control
receiving flush messages [ control-vlan vlan-id-list ] VLAN exists for receiving
flush messages.
z Configure all the control VLANs to receive flush messages.

z If no control VLAN is specified for processing flush messages, the device forwards the received
flush messages without processing them.
z Make sure that the receive control VLAN is the same as the transmit control VLAN configured on
the smart link device. If they are not the same, the associated device will forward the received
flush messages directly without any processing.
z Do not remove the control VLANs. Otherwise, flush messages cannot be sent properly.
z Make sure that the control VLANs are existing VLANs, and assign the ports capable of receiving
flush messages to the control VLANs.
Associated Device Configuration Example
Configure GigabitEthernet 1/0/1 to receive and process flush messages in VLAN 20.
[Sysname] vlan 20
[Sysname-GigabitEthernet1/0/1] smart-link flush enable control-vlan 20
Displaying and Maintaining Smart Link

Display smart link group display smart-link group

information { group-id | all }
display smart-link flush Available in any view
received flush messages
1-8

Clear the statistics about flush
reset smart-link statistics Available in user view
messages
Smart Link Configuration Examples

Single Smart Link Group Configuration Example

z Map VLANs 1 through 10, VLANs 11 through 20, and VLANs 21 through 30 to MSTI 0, MSTI 1,
and MSTI 2 respectively.
z Traffic of VLANs 1 through 30 on Device C and Device D are dually uplinked to Device A.
z Configure Smart Link on the devices for dual uplink backup, using VLAN 1 (the default) for flush
update.
Figure 1-2 Single smart link group configuration
Device A
/1 GE
1/0 1/0
GE /2
/1 GE
1/0 1/0
/1
GE
Device B Device E
GE /2
1/0 1/0
GE1/0/3 /2 GE GE1/0/3
Master link
Slave link
Smart link group
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
Device C Device D
1) Configuration on Device C
# Create VLANs 1 through 30, map VLANs 1 through 10, VLANs 11 through 20, and VLANs 21
through 30 to MSTI 0, MSTI 1, and MSTI 2 respectively, and activate the MST region configuration.
[DeviceC] vlan 1 to 30
[DeviceC-mst-region] instance 0 vlan 1 to 10
# Disable STP on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, and configure them as
trunk ports that permit VLANs 1 through 30.
1-9

[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] undo stp enable
[DeviceC-GigabitEthernet1/0/1] port link-type trunk
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceC-GigabitEthernet1/0/1] quit
# Create smart link group 1 and configure all VLANs mapped to MSTIs 0 through 2 as the protected
VLANs.
[DeviceC] smart-link group 1
[DeviceC-smlk-group1] protected-vlan reference-instance 0 to 2
# Configure GigabitEthernet 1/0/1 as the master port and GigabitEthernet 1/0/2 as the slave port for
smart link group 1.
[DeviceC-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceC-smlk-group1] port gigabitethernet 1/0/2 slave
# Enable flush message sending in smart link group 1.

[DeviceC-smlk-group1] flush enable
[DeviceC-smlk-group1] quit
2) Configuration on Device D
# Create VLANs 1 through 30, map VLANs 1 through 10, VLANs 11 through 20, and VLANs 21
through 30 to MSTI 0, MSTI 1, and MSTI 2 respectively, and activate the MST region configuration.
[DeviceD] vlan 1 to 30
[DeviceD-mst-region] instance 0 vlan 1 to 10
# Disable STP on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, and configure them as
trunk ports that permit VLANs 1 through 30.
[DeviceD] interface gigabitethernet 1/0/1
[DeviceD-GigabitEthernet1/0/1] undo stp enable
[DeviceD-GigabitEthernet1/0/1] port link-type trunk
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceD-GigabitEthernet1/0/1] quit
1-10

# Create smart link group 1 and configure all VLANs mapped to MSTIs 0 through 2 as the protected
VLANs.
[DeviceD] smart-link group 1
[DeviceD-smlk-group1] protected-vlan reference-instance 0 to 2
smart link group 1.
[DeviceD-smlk-group1] port gigabitethernet 1/0/1 master
[DeviceD-smlk-group1] port gigabitethernet 1/0/2 slave
# Enable flush message sending in smart link group 1.

[DeviceD-smlk-group1] flush enable
[DeviceD-smlk-group1] quit
# Create VLANs 1 through 30.
[DeviceB] vlan 1 to 30
# Configure GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3 as trunk ports that
permit VLANs 1 through 30 and enable flush message receiving on them.
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceB-GigabitEthernet1/0/1] smart-link flush enable
4) Configuration on Device E
<DeviceE> system-view
[DeviceE] vlan 1 to 30
[DeviceE] interface gigabitethernet 1/0/1
[DeviceE-GigabitEthernet1/0/1] port link-type trunk
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceE-GigabitEthernet1/0/1] smart-link flush enable
[DeviceE-GigabitEthernet1/0/1] quit
1-11

[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[DeviceA-GigabitEthernet1/0/1] smart-link flush enable
You can use the display smart-link group command to display the smart link group configuration on
each device. For example:
# Display the smart link group configuration on Device C.
[DeviceC] display smart-link group 1
Smart link group 1 information:
Device ID: 000f-e23d-5af0
Preemption mode: NONE
Control VLAN: 1
Protected VLAN: Reference Instance 0 to 2
Member Role State Flush-count Last-flush-time
-------------------------------------------------------------------------------
GigabitEthernet1/0/1 MASTER ACTVIE 5 16:37:20 2009/02/21
GigabitEthernet1/0/2 SLAVE STANDBY 1 17:45:20 2009/02/21
You can use the display smart-link flush command to display the flush messages received on each
device. For example:
# Display the flush messages received on Device B.
[DeviceB] display smart-link flush
Received flush packets : 5
Receiving interface of the last flush packet : GigabitEthernet1/0/3
Receiving time of the last flush packet : 16:25:21 2009/02/21
1-12

Device ID of the last flush packet : 000f-e23d-5af0
Control VLAN of the last flush packet : 1
Multiple Smart Link Groups Load Sharing Configuration Example

z Traffic of VLANs 1 through 200 on Device C are dually uplinked to Device A by Device B and
Device D. Implement load sharing to uplink the traffic of VLANs 1 through 100 and the traffic of
VLANs 101 through 200 over different links to Device A.
z Implement dual uplink backup on Device C: traffic of VLANs 1 through 100 (mapped to MSTI 0) is
uplinked to Device A by Device B; traffic of VLANs 101 through 200 (mapped to MSTI 2) is
uplinked to Device A by Device D. Smart link group 1 references MSTI 0, and smart link group 2
references MSTI 2.
z The control VLAN of smart link group 1 is VLAN 10 and that of smart link group 2 is VLAN 101.
Figure 1-3 Multiple smart link groups load sharing configuration
Device A
/1 GE
1/0 1/0
GE /2
/1 GE
1/0 1/0
GE /1
Device B Device D
GE /2
1/0 1/0
/2 GE /2 GE
1/0 1/0
/1 GE
Device C
# Create VLAN 1 through VLAN 200, map VLAN 1 through VLAN 100 to MSTI 0 and VLAN 101
through VLAN 200 to MSTI 2, and activate MST region configuration.
[DeviceC] vlan 1 to 200
# Disable STP on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately, configure the ports as
trunk ports, and assign them to VLAN 1 through VLAN 200.
1-13

# Create smart link group 1, and configure all VLANs mapped to MSTI 0 as the protected VLANs for
smart link group 1.
[DeviceC-smlk-group1] protected-vlan reference-instance 0
smart link group 1.
# Enable role preemption in smart link group 1, enable flush message sending, and configure VLAN 10
as the transmit control VLAN.
[DeviceC-smlk-group1] preemption mode role
[DeviceC-smlk-group-1] flush enable control-vlan 10
[DeviceC-smlk-group-1] quit
# Create smart link group 2, and configure all VLANs mapped to MSTI 2 as the protected VLANs for
smart link group 2.
[DeviceC-smlk-group2] protected-vlan reference-instance 2
# Configure GigabitEthernet 1/0/1 as the slave port and GigabitEthernet 1/0/2 as the master port for
smart link group 2.
# Enable role preemption in smart link group 2, enable flush message sending, and configure VLAN
101 as the transmit control VLAN.
[DeviceC-smlk-group2] preemption mode role
[DeviceC-smlk-group2] flush enable control-vlan 101
[DeviceC-smlk-group2] quit
# Create VLAN 1 through VLAN 200.
[DeviceB] vlan 1 to 200
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 as trunk ports and assign them to VLANs
1 through 200; enable flush message receiving on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2
and configure VLAN 10 and VLAN 101 as the receive control VLANs.
[DeviceB-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 101
1-14

[DeviceB-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 101
[DeviceD] vlan 1 to 200
[DeviceD-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 101
[DeviceD-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 101
[DeviceA-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10 101
[DeviceA-GigabitEthernet1/0/2] smart-link flush enable control-vlan 10 101
You can use the display smart-link group command to display the smart link group configuration on
each device. For example:
# Display the smart link group configuration on Device C.
[DeviceC] display smart-link group all
1-15

Preemption mode: ROLE
Control VLAN: 10
Protected VLAN: Reference Instance 0
-------------------------------------------------------------------------------

Preemption mode: ROLE
Control VLAN: 101
Protected VLAN: Reference Instance 2
-------------------------------------------------------------------------------
You can use the display smart-link flush command to display the flush messages received on each
device. For example:
# Display the flush messages received on Device B.
[DeviceB] display smart-link flush
Received flush packets : 5
Receiving interface of the last flush packet : GigabitEthernet1/0/2
Receiving time of the last flush packet : 16:25:21 2009/02/21
Device ID of the last flush packet : 000f-e23d-5af0
Control VLAN of the last flush packet : 10
1-16

2 Monitor Link Configuration
When configuring monitor link, go to these sections for information you are interested in:
z Overview
z Configuring Monitor Link
z Displaying and Maintaining Monitor Link
z Monitor Link Configuration Example
Overview
Monitor link is a port collaboration function. Monitor link is usually used in conjunction with Layer 2
topology protocols. The idea is to adapt the up/down state of downlink ports to the up/down state of
uplink ports, triggering link switchover on the downlink device in time.
Terminology
Monitor link group
A monitor link group is a set of uplink ports and downlink ports. For the purpose of monitor link, uplink
ports refer to the monitored ports while downlink ports refer to the ports adapted to the up/down state
of the monitored ports. A port can be assigned to only one monitor link group. Both Layer 2 Ethernet
ports and Layer 2 aggregate interfaces can be assigned to a monitor link group.
Uplink
The uplink is the link monitored by the monitor link group. The monitor link group is down when the
group has no uplink ports or all uplink ports are down. The monitor link group is up when any uplink
port is up.
Downlink
The downlink is the state-adaptive link in the monitor link group. The state of the downlink ports is
always consistent with the up/down state of the monitor link group.
How Monitor Link Works
A monitor link group works independently of other monitor link groups. When a monitor link group
contains no uplink ports or all its uplink ports go down, the monitor link group goes down and forces all
downlink ports down at the same time. When any uplink port goes up, the monitor link group goes up
and brings up all the downlink ports.
Do not manually shut down or bring up the downlink ports in a monitor link group.
2-1

Configuring Monitor Link
Before assigning a port to a monitor link group, make sure the port is not the member port of any
aggregation group.
Follow these steps to configure monitor link:

Create a monitor link group and enter
monitor-link group group-id Required
monitor link group view
In monitor link port interface-type

group view interface-number uplink
Configure the Use either approach
uplink for the In Ethernet port Repeat this step to
monitor link group view or Layer 2 port monitor-link group add more uplink ports
aggregate group-id uplink
interface view
In monitor link port interface-type
group view interface-number downlink Use either approach
Configure the
downlink for the In Ethernet port Repeat this step to
monitor link group view or Layer 2 port monitor-link group add more downlink
aggregate group-id downlink ports
interface view
z A port can be assigned to only one monitor link group.

z You are recommended to configure uplink ports prior to downlink ports, thus avoiding undesired
down/up state changes on the downlink ports.
Monitor Link Configuration Example
GigabitEthernet1/0/1 and GigabitEthernet1/0/2 of a device are up. Configure GigabitEthernet1/0/2 to

change its up/down state as GigabitEthernet1/0/1.
[Sysname] monitor-link group 1
[Sysname-mtlk-group1] port gigabitethernet 1/0/1 uplink
[Sysname-mtlk-group1] port gigabitethernet 1/0/2 downlink
2-2

Displaying and Maintaining Monitor Link
Display monitor link group display monitor-link group
information { group-id | all }
Monitor Link Configuration Example


z Device C is dually uplinked to Device A through a smart link group.
z It is required that when GigabitEthernet1/0/1 or GigabitEthernet1/0/2 of Device A fails, Device C
can sense the link failure and perform link switchover in the smart link group.
For detailed information about smart link, refer to Smart Link Configuration in the High Availability
Volume.
Figure 2-1 Network diagram for smart link in combination with monitor link configuration
Device A
GE1/0/1 GE1/0/2
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
Device B Device D
GE1/0/1 GE1/0/2
Device C
# Disable STP on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately.
2-3

# Create smart link group 1 and configure the smart link group to protect all the VLANs mapped to
MSTIs 0 through 15 for smart link group 1.
[DeviceC-smlk-group1] protected-vlan reference-instance 0 to 15
smart link group 1.
# Enable the smart link group to transmit flush messages in VLAN 1.

[DeviceC-smlk-group1] flush enable
# Enable flush message receiving on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 separately.
# Create monitor link group 1.
[DeviceB] monitor-link group 1
# Configure GigabitEthernet 1/0/1 as an uplink port and GigabitEthernet 1/0/2 as a downlink port for
monitor link group 1.
[DeviceB-mtlk-group1] port gigabitethernet 1/0/1 uplink
[DeviceB-mtlk-group1] port gigabitethernet 1/0/2 downlink
[DeviceB-mtlk-group-1] quit
# Create monitor link group 1.
[DeviceD] monitor-link group 1
# Configure GigabitEthernet 1/0/1 as the uplink port and GigabitEthernet 1/0/2 as the downlink port for
monitor link group 1.
[DeviceD-mtlk-group1] port gigabitethernet 1/0/1 uplink
[DeviceD-mtlk-group1] port gigabitethernet 1/0/2 downlink
[DeviceD-mtlk-group1] quit
2-4

[DeviceD-GigabitEthernet1/0/1] smart-link flush enable
[DeviceD-GigabitEthernet1/0/2] smart-link flush enable
2-5

3 RRPP Configuration
When configuring RRPP, go to these sections for information you are interested in:
z RRPP Overview
z RRPP Configuration Task List
z Creating an RRPP Domain
z Configuring Control VLANs
z Configuring Protected VLANs
z Configuring RRPP Rings
z Activating an RRPP Domain
z Configuring RRPP Timers
z Configuring an RRPP Ring Group
z Displaying and Maintaining RRPP
z RRPP Configuration Examples
z Troubleshooting
RRPP Overview
The Rapid Ring Protection Protocol (RRPP) is a link layer protocol designed for Ethernet rings. RRPP
can prevent broadcast storms caused by data loops when an Ethernet ring is healthy, and rapidly
restore the communication paths between the nodes in the event that a link is disconnected on the
ring.
Compared with the IEEE spanning tree protocols, RRPP features the following:
z Fast topology convergence
z Convergence time independent of Ethernet ring size
Background
Metropolitan area networks (MANs) and enterprise networks usually use the ring structure to improve
reliability. However, services will be interrupted if any node in the ring network fails. A ring network
usually uses Resilient Packet Ring (RPR) or Ethernet rings. RPR is high in cost as it needs dedicated
hardware. Contrarily, the Ethernet ring technology is more mature and economical, so it is more and
more widely used in MANs and enterprise networks.
Currently, both Spanning Tree Protocol (STP) and RRPP can be used to eliminate Layer-2 loops. STP
is mature; however, it takes several seconds to converge. RRPP is an Ethernet ring-specific data link
layer protocol, and converges faster than STP. Additionally, the convergence time of RRPP is
independent of the number of nodes in the Ethernet ring, and therefore, RRPP can be applied to
large-diameter networks.
3-1

Basic Concepts in RRPP
Figure 3-1 RRPP networking diagram
RRPP domain
The interconnected devices with the same domain ID and control VLANs constitute an RRPP domain.
An RRPP domain contains the following elements: primary ring, subring, control VLAN, master node,
transit node, primary port, secondary port, common port, and edge port.
As shown in Figure 3-1, Domain 1 is an RRPP domain, including two RRPP rings: Ring 1 and Ring 2.
All the nodes on the two RRPP rings belong to the RRPP domain.
RRPP ring
A ring-shaped Ethernet topology is called an RRPP ring. RRPP rings fall into two types: primary ring
and subring. You can configure a ring as either the primary ring or a subring by specifying its ring level.
The primary ring is of level 0, while a subring is of level 1. An RRPP domain contains one or multiple
RRPP rings, one serving as the primary ring and the others serving as subrings. A ring can be in one of
the following two states:
z Health state: All the physical links on the Ethernet ring are connected.
z Disconnect state: Some physical links on the Ethernet ring are broken.
As shown in Figure 3-1, Domain 1 contains two RRPP rings: Ring 1 and Ring 2. The level of Ring 1 is
set to 0, that is, Ring 1 is configured as the primary ring; the level of Ring 2 is set to 1, that is, Ring 2 is
configured as a subring.
Control VLAN and data VLAN
1) Control VLAN
In an RRPP domain, a control VLAN is a VLAN dedicated to transferring RRPPDUs. On a device, the
ports accessing an RRPP ring belong to the control VLANs of the ring, and only such ports can join the
control VLANs.
An RRPP domain is configured with two control VLANs: one primary control VLAN, which is the control
VLAN for the primary ring; one secondary control VLAN, which is the control VLAN for subrings. All
subrings in the same RRPP domain share the same secondary control VLAN. After you specify a
VLAN as the primary control VLAN, the system automatically configures the VLAN whose ID is the
primary control VLAN ID plus one as the secondary control VLAN.
3-2

IP address configuration is prohibited on the control VLAN interfaces.
2) Data VLAN
A data VLAN is a VLAN dedicated to transferring data packets. Both RRPP ports and non-RRPP ports
can be assigned to a data VLAN.
Node
Each device on an RRPP ring is referred to as a node. The role of a node is configurable. There are
the following node roles:
z Master node: Each ring has one and only one master node. The master node initiates the polling
mechanism and determines the operations to be performed after a change in topology.
z Transit node: Transit nodes include all the nodes except the master node on the primary ring and
all the nodes on subrings except the master nodes and the nodes where the primary ring
intersects with the subrings. A transit node monitors the state of its directly-connected RRPP links
and notifies the master node of the link state changes, if any. Based on the link state changes, the
master node decides the operations to be performed.
z Edge node: A node residing on both the primary ring and a subring at the same time. An edge
node is a special transit node that serves as a transit node on the primary ring and an edge node
on the subring.
z Assistant-edge node: A node residing on both the primary ring and a subring at the same time. An
assistant-edge node is a special transit node that serves as a transit node on the primary ring and
an assistant-edge node on the subring. This node works in conjunction with the edge node to
detect the integrity of the primary ring and perform loop guard.
As shown in Figure 3-1, Ring 1 is the primary ring and Ring 2 is a subring. Device A is the master node
of Ring 1, Device B, Device C and Device D are the transit nodes of Ring 1. Device E is the master
node of Ring 2, Device B is the edge node of Ring 2, and Device C is the assistant-edge node of Ring
2.
Primary port and secondary port
Each master node or transit node has two ports connected to an RRPP ring, one serving as the
primary port and the other serving as the secondary port. You can determine the role of a port.
1) In terms of functionality, the difference between the primary port and the secondary port of a
master node is:
z The primary port and the secondary port are designed to play the role of sending and receiving
loop-detect packets respectively.
z When an RRPP ring is in Health state, the secondary port of the master node will logically deny
data VLANs and permit only the packets of the control VLANs.
z When an RRPP ring is in Disconnect state, the secondary port of the master node will permit data
VLANs, that is, forward packets of data VLANs.
2) In terms of functionality, there is no difference between the primary port and the secondary port of
a transit node. Both are designed for transferring protocol packets and data packets over an
RRPP ring.
As shown in Figure 3-1, Device A is the master node of Ring 1. Port 1 and Port 2 are the primary port
and the secondary port of the master node on Ring 1 respectively. Device B, Device C, and Device D
are the transit nodes of Ring 1. Their Port 1 and Port 2 are the primary port and the secondary port on
Ring 1 respectively.
3-3

Common port and edge port
The ports connecting the edge node and assistant-edge node to the primary ring are common ports.
The ports connecting the edge node and assistant-edge node only to the subrings are edge ports.
As shown in Figure 3-1, Device B and Device C lie on Ring 1 and Ring 2. Device Bs Port 1 and Port 2
and Device Cs Port 1 and Port 2 access the primary ring, so they are common ports. Device Bs Port 3
and Device Cs Port 3 access only the subring, so they are edge ports.
RRPP ring group
To reduce Edge-Hello traffic, you can configure a group of subrings on the edge node or
assistant-edge node. For information about Edge-Hello packets, refer to RRPPDUs. You must
configure a device as the edge node of these subrings, and another device as the assistant-edge node
of these subrings. Additionally, the subrings of the edge node and assistant-edge node must connect
to the same subring packet tunnels in major ring (SRPTs), so that Edge-Hello packets of the edge node
of these subrings travel to the assistant-edge node of these subrings over the same link.
An RRPP ring group configured on the edge node is called an edge node RRPP ring group, and an
RRPP ring group configured on an assistant-edge node is called an assistant-edge node RRPP ring
group. Up to one subring in an edge node RRPP ring group is allowed to send Edge-Hello packets.
RRPPDUs
Table 3-1 shows the types of RRPPDUs and their functions.
Table 3-1 RRPPDU types and their functions
Type Description
The master node initiates Hello packets to detect the integrity of a ring in a
Hello
network.
The transit node, the edge node or the assistant-edge node initiates
Link-Down Link-Down packets to notify the master node of the disappearance of a ring
in case of a link failure.
The master node initiates Common-Flush-FDB (FDB stands for Forwarding
Database) packets to instruct the transit nodes to update their own MAC
Common-Flush-FDB
entries and ARP/ND entries when an RRPP ring transits to Disconnect
state.
The master node initiates Complete-Flush-FDB packets to instruct the
transit nodes to update their own MAC entries and ARP/ND entries, and
Complete-Flush-FDB
release blocked ports from being blocked temporarily when an RRPP ring
transits to Health state.
The edge node initiates Edge-Hello packets to examine the SRPTs
Edge-Hello
between the edge node and the assistant-edge node.
The assistant-edge node initiates Major-Fault packets to notify the edge
Major-Fault node of SRPT failure when an SRPT between edge node and
assistant-edge node is torn down.
RRPPDUs of subrings are transmitted as data packets in the primary ring, while RRPPDUs of the
primary ring can only be transmitted within the primary ring.
3-4

RRPP Timers
When RRPP checks the link state of an Ethernet ring, the master node sends Hello packets out the
primary port according to the Hello timer and determines whether its secondary port receives the Hello
packets based on the Fail timer.
z The Hello timer specifies the interval at which the master node sends Hello packets out the
primary port.
z The Fail timer specifies the maximum delay between the master node sending Hello packets out
the primary port and the secondary port receiving the Hello packets from the primary port. If the
secondary port receives the Hello packets sent by the local master node before the Fail timer
expires, the overall ring is in Health state. Otherwise, the ring transits into Disconnect state.
In an RRPP domain, a transit node learns the Hello timer value and the Fail timer value on the master
node through the received Hello packets, ensuring that all nodes in the ring network are consistent in
the two timer settings.
How RRPP Works
Polling mechanism
The polling mechanism is used by the master node of an RRPP ring to check the Health state of the
ring network.
The master node sends Hello packets out its primary port periodically, and these Hello packets travel
through each transit node on the ring in turn.
z If the ring is complete, the secondary port of the master node will receive Hello packets before the
Fail timer expires and the master node will keep the secondary port blocked.
z If the ring is torn down, the secondary port of the master node will fail to receive Hello packets
before the Fail timer expires. The master node will release the secondary port from blocking data
VLANs while sending Common-Flush-FDB packets to instruct all transit nodes to update their own
MAC entries and ARP/ND entries.
Link down alarm mechanism
The transit node, the edge node or the assistant-edge node sends Link-Down packets to the master
node immediately when they find any of its own ports belonging to an RRPP domain is down. Upon the
receipt of a Link-Down packet, the master node releases the secondary port from blocking data VLANs
while sending Common-Flush-FDB packet to instruct all the transit nodes, the edge nodes and the
assistant-edge nodes to update their own MAC entries and ARP/ND entries. After each node updates
its own entries, traffic is switched to the normal link.
3-5

Ring recovery
The master node may find the ring is restored after a period of time after the ports belonging to the
RRPP domain on the transit nodes, the edge nodes, or the assistant-edge nodes are brought up again.
A temporary loop may arise in the data VLAN during this period. As a result, broadcast storm occurs.
To prevent temporary loops, non-master nodes block them immediately (and permit only the packets of
the control VLAN to pass through) when they find their ports accessing the ring are brought up again.
The blocked ports are activated only when the nodes are sure that no loop will be brought forth by
these ports.
Broadcast storm suppression mechanism in a multi-homed subring in case of SRPT failure
As shown in Figure 3-5, Ring 1 is the primary ring, and Ring 2 and Ring 3 are subrings. When the two
SRPTs between the edge node and the assistant-edge node are down, the master nodes of Ring 2
and Ring 3 will open their respective secondary ports, and thus a loop among Device B, Device C,
Device E, and Device F is generated. As a result, broadcast storm occurs.
In this case, to prevent generating this loop, the edge node will block the edge port temporarily. The
blocked edge port is activated only when the edge node is sure that no loop will be brought forth when
the edge port is activated.
Load balancing
In a ring network, maybe traffic of multiple VLANs is transmitted at the same time. RRPP can
implement load balancing for the traffic by transmitting traffic of different VLANs along different paths.
By configuring an individual RRPP domain for transmitting the traffic of the specified VLANs (referred
to as protected VLANs) in a ring network, traffic of different VLANs can be transmitted according to
different topologies in the ring network. In this way, load balancing is achieved.
As shown in Figure 3-6, Ring 1 is configured as the primary ring of Domain 1 and Domain 2, which are
configured with different protected VLANs. Device A is the master node of Ring 1 in Domain 1; Device
B is the master node of Ring 1 in Domain 2. With such configurations, traffic of different VLANs can be
transmitted on different links, and thus, load balancing is achieved in a single-ring network.
RRPP ring group
In an edge node RRPP ring group, only an activated subring with the lowest domain ID and ring ID can
send Edge-Hello packets. In an assistant-edge node RRPP ring group, any activated subring that has
received Edge-Hello packets will forward these packets to the other activated subrings. With an edge
node RRPP ring group and an assistant-edge node RRPP ring group configured, only one subring
sends and receives Edge-Hello packets, thus reducing CPU workload.
As shown in Figure 3-5, Device B is the edge node of Ring 2 and Ring 3, and Device C is the
assistant-edge node of Ring 2 and Ring 3. Device B and Device C need to send or receive Edge-Hello
packets frequently. If more subrings are configured or load balancing is configured for more multiple
domains, Device B and Device C will send or receive a mass of Edge-Hello packets.
To reduce Edge-Hello traffic, you can assign Ring 2 and Ring 3 to an RRPP ring group configured on
the edge node Device B, and assign Ring 2 and Ring 3 to an RRPP ring group configured on Device C.
After such configurations, if all rings are activated, only Ring 2 on Device B sends Edge-Hello packets.
Typical RRPP Networking
Here are several typical networking applications.
3-6

Single ring
As shown in Figure 3-2, there is only a single ring in the network topology. In this case, you only need
to define an RRPP domain.
Figure 3-2 Schematic diagram for a single-ring network
Tangent rings
As shown in Figure 3-3, there are two or more rings in the network topology and only one common
node between rings. In this case, you need to define an RRPP domain for each ring.
Figure 3-3 Schematic diagram for a tangent-ring network
Intersecting rings
As shown in Figure 3-4, there are two or more rings in the network topology and two common nodes
between rings. In this case, you only need to define an RRPP domain, and configure one ring as the
primary ring and the other rings as subrings.
3-7

Figure 3-4 Schematic diagram for an intersecting-ring network
Dual homed rings
As shown in Figure 3-5, there are two or more rings in the network topology and two similar common
nodes between rings. In this case, you only need to define an RRPP domain, and configure one ring as
the primary ring and the other rings as subrings.
Figure 3-5 Schematic diagram for a dual-homed-ring network
Single-ring load balancing
In a single-ring network, you can achieve load balancing by configuring multiple domains.
As shown in Figure 3-6, Ring 1 is configured as the primary ring of both Domain 1 and Domain 2.
Domain 1 and Domain 2 are configured with different protected VLANs. In Domain 1, Device A is
configured as the master node of Ring 1; in Domain 2, Device B is configured as the master node of
Ring 1. Such configurations enable the ring to block different links based on VLANs. Thus, single-ring
load balancing is achieved.
3-8

Figure 3-6 Schematic diagram for a single-ring load balancing network
Device A Device B
Domain 1 Ring 1 Domain 2
Device D Device C
Intersecting-ring load balancing
In an intersecting-ring network, you can also achieve load balancing by configuring multiple domains.
As shown in Figure 3-7, Ring 1 is the primary ring and Ring 2 is the subring in both Domain 1 and
Domain 2. Domain 1 and Domain 2 are configured with different protected VLANs. Device A is
configured as the master node of Ring 1 in Domain 1; Device D is configured as the master node of
Ring 1 in Domain 2. Device E is configured as the master node of Ring 2 in both Domain 1 and Domain
2. However, different ports on Device E are blocked in Domain 1 and Domain 2. With the
configurations, you can enable traffic of different VLANs to travel over different paths in the subring and
primary ring, thus achieving intersecting-ring load balancing.
Figure 3-7 Schematic diagram for an intersecting-ring load balancing network
RFC 3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 is related to
RRPP.
RRPP Configuration Task List

You can create RRPP domains based on service planning, specify control VLANs and data VLANs for
each RRPP domain, and then determine the ring roles and node roles based on the traffic paths in
each RRPP domain.
3-9

Complete the following tasks to configure RRPP:
Task Remarks
Required
Creating an RRPP Domain
Perform this task on all nodes in the RRPP domain.
Required
Configuring Control VLANs
Required
Configuring Protected VLANs
Required
Configuring RRPP Ports
Configuring Perform this task on all nodes in the RRPP domain.
RRPP Rings Required
Configuring RRPP Nodes
Perform this task on all nodes in the RRPP domain
Required
Activating an RRPP Domain
Optional
Configuring RRPP Timers Perform this task on the master node in the RRPP
domain.
Optional
Configuring an RRPP Ring Group Perform this task on the edge node and
assistant-edge node in the RRPP domain.
z RRPP does not have an auto election mechanism, so you must configure each node in the ring
network properly for RRPP to monitor and protect the ring network.
z Before configuring RRPP, you need to construct a ring-shaped Ethernet topology physically.
Creating an RRPP Domain

When creating an RRPP domain, specify a domain ID, which uniquely identifies an RRPP domain. All
devices in the same RRPP domain must be configured with the same domain ID.
Make this configuration on devices you want to configure as nodes in the RRPP domain.
Follow these steps to create an RRPP domain:

Create an RRPP domain and

rrpp domain domain-id Required
enter RRPP domain view
3-10

Configuring Control VLANs
Before configuring RRPP rings in an RRPP domain, configure the same control VLANs for all nodes in
the RRPP domain first.
Perform this configuration on all nodes in the RRPP domain to be configured.
Follow these steps to configure control VLANs:

Enter RRPP domain view rrpp domain domain-id
Specify the primary control

control-vlan vlan-id Required
VLAN for the RRPP domain
z To ensure proper forwarding of RRPPDUs, do not enable QinQ or VLAN mapping on the control
VLANs.
z To ensure that RRPPDUs can be sent and received correctly, do not configure the default VLAN
of a port accessing an RRPP ring as the primary control VLAN or the secondary control VLAN.
z To transparently transmit RRPPDUs on a device not configured with RRPP, you must ensure only
the two ports connecting the device to the RRPP ring permit the packets of the control VLANs.
Otherwise, the packets from other VLANs may go into the control VLANs in transparent
transmission mode and strike the RRPP ring.
Configuring Protected VLANs

Before configuring RRPP rings in an RRPP domain, configure the same protected VLANs for all nodes
in the RRPP domain first. All VLANs that the RRPP ports are assigned to should be protected by the
RRPP domains. Perform this configuration on all nodes in the RRPP domain to be configured.
Follow these steps to configure protected VLANs:

protected-vlan Required
Configure protected VLANs for
reference-instance By default, no protected VLAN is
the RRPP domain
instance-id-list configured for an RRPP domain.
When configuring load balancing, ensure that the protected VLANs configured for different RRPP
domains are different.
3-11

Configuring RRPP Rings
When configuring an RRPP ring, you must make some configurations on the ports connecting each
node to the RRPP ring before configuring the nodes.
z RRPP ports, that is, ports connecting devices to an RRPP ring, must be Layer-2 GE ports, Layer-2
XGE ports, or Layer-2 aggregate interfaces and cannot be member ports of any aggregation
group, or smart link group.
z After configuring a Layer-2 aggregate interface as an RRPP port, you can still assign ports to or
remove ports from the aggregation group corresponding to the interface.
Configuring RRPP Ports
Perform this configuration on each nodes ports intended for accessing RRPP rings.
Follow these steps to configure RRPP ports:

interface-number
Required
port link-type trunk By default, the link type of an
interface as trunk
interface is access.
Optional
Configure the trunk port carries port trunk permit vlan By default, a trunk port carries
the protected VLAN(s) { vlan-id-list | all } only the default VLAN, which is
VLAN 1 on the switch by
default.
Required
Disable STP undo stp enable
Enabled by default
Configure the port to trust the Required

802.1p precedence of the qos trust dot1p By default, the port priority is
received packets trusted.
3-12

z For detailed information about the port link-type trunk command and port trunk permit vlan
{ vlan-id-list | all } command, refer to VLAN Commands in the Access Volume.
z For detailed information about the undo stp enable command, refer to MSTP Commands in the
Access Volume.
z The 802.1p priority of trusted packets on the RRPP ports must be configured, so that RRPP
packets take higher precedence than data packets when passing through the RRPP ports.
z Do not enable OAM remote loopback function on an RRPP port. Otherwise, this may cause
temporary broadcast storm.
z You are recommended not to configure physical-link-state change suppression time on a port
accessing an RRPP ring to accelerate topology convergence. For details, refer to Ethernet
Interface Configuration in the Access Volume.
Configuring RRPP Nodes
z The maximum number of rings that can be configured on a device in all RRPP domains is 16.
z If a device carries multiple RRPP rings in an RRPP domain, only one ring can be configured as
the primary ring on the device and the role of the device on a subring can only be an edge node or
an assistant-edge node.
Specifying a master node
Perform this configuration on a device to be configured as a master node.

Follow these steps to specify a master node:

ring ring-id node-mode master

Specify the current device as
[ primary-port interface-type
the master node of the ring,
interface-number ] [ secondary-port Required
and specify the primary port
interface-type interface-number ] level
and the secondary port
level-value
Specifying a transit node
Perform this configuration on a device to be configured as a transit node.

Follow these steps to specify a transit node:
3-13

ring ring-id node-mode transit

Specify the current device as a
transit node of the ring, and
specify the primary port and
the secondary port
level-value
Specifying an edge node
When configuring an edge node, you must first configure the primary ring before configuring the
subrings.
Perform this configuration on a device to be configured as an edge node.
Follow these steps to specify an edge node:


transit node of the primary ring,
level-value
Specify the current device as ring ring-id node-mode edge
the edge node of a subring, [ edge-port interface-type Required
and specify the edge port interface-number ]
Specifying an assistant-edge node
When configuring an assistant-edge node, you must first configure the primary ring before configuring
the subrings.
Perform this configuration on a device to be configured as an assistant-edge node.
Follow these steps to specify an assistant-edge node:


transit node of the primary ring,
level-value
Specify the current device as
ring ring-id node-mode assistant-edge
the assistant-edge node of the
[ edge-port interface-type Required
subring, and specify an edge
interface-number ]
port
3-14

Activating an RRPP Domain
To activate an RRPP domain on the current device, enable the RRPP protocol and RRPP rings for the
RRPP domain on the current device.
Perform this operation on all nodes in the RRPP domain.
Follow these steps to activate an RRPP domain:

Required
Enable RRPP rrpp enable
Disabled by default
Enable the specified RRPP Required

ring ring-id enable
ring Disabled by default
On an edge node or assistant-edge node, enable/disable the primary ring and subrings separately as
follows:
z Enable the primary ring of an RRPP domain before enabling subrings of the RRPP domain.
z Disable the primary ring of an RRPP domain after disabling all subrings of the RRPP domain.
Configuring RRPP Timers

Perform this configuration on the master node of an RRPP domain.
Follow these steps to configure RRPP timers:

Required
Configure the Hello timer and timer hello-timer hello-value By default, the Hello timer
Fail timer for the RRPP domain fail-timer fail-value value is 1 second and the Fail
timer value is 3 seconds.
3-15

z The Fail timer value must be equal to or greater than three times the Hello timer value.
z To avoid temporary loops when the primary ring fails in a dual-homed-ring network, ensure that
the difference between the Fail timer value on the master node of the subring and that on the
master node of the primary ring is greater than twice the Hello timer value of the master node of
the subring.
Configuring an RRPP Ring Group

To reduce Edge-Hello traffic, you can adopt the RRPP ring group mechanism, that is, assign subrings
with the same edge node/assistant-edge node to an RRPP ring group. An RRPP ring group must be
configured on both the edge node and the assistant-edge node, and can only be configured on these
two types of nodes.
Perform this configuration on both the edge node and the assistant-edge node in an RRPP domain.
Follow these steps to configure an RRPP ring group:

Create an RRPP ring group
and enter RRPP ring group rrpp ring-group ring-group-id Required
view
Assign the specified subrings domain domain-id ring
Required
to the RRPP ring group ring-id-list
z You can assign a subring to only one RRPP ring group. Make sure that the RRPP ring group
configured on the edge node and that configured on the assistant-edge node must contain the
same subrings. Otherwise, the RRPP ring group cannot operate normally.
z Ensure that the subrings in an RRPP ring group share the same edge node and assistant-edge
node, and the edge node and the assistant edge node have the same SRPTs.
z Ensure that a device plays the same role on the subrings in an RRPP ring group. The role can be
the edge node or the assistant-edge node.
z Ensure that the RRPP ring group on the edge node and that on the assistant-edge node have the
same configurations and activation status.
z Ensure that all subrings in an RRPP ring group have the same SRPTs. If the SRPTs of these
subrings are configured or modified differently, the RRPP ring group cannot operate normally.
3-16

Displaying and Maintaining RRPP
Display brief RRPP information display rrpp brief
Display RRPP group display rrpp ring-group
configuration information [ ring-group-id ]
Display detailed RRPP display rrpp verbose domain Available in any view
information domain-id [ ring ring-id ]
display rrpp statistics domain
Display RRPP statistics
domain-id [ ring ring-id ]
reset rrpp statistics domain
Clear RRPP statistics Available in user view
domain-id [ ring ring-id ]
RRPP Configuration Examples

Single Ring Configuration Example
Networking requirements
z Device A, Device B, Device C, and Device D constitute RRPP domain 1, specify the primary
control VLAN of RRPP domain 1 as VLAN 4092, and RRPP domain 1 protects all VLANs;
z Device A, Device B, Device C and Device D constitute primary ring 1;
z Specify Device A as the master node of primary ring 1, GigabitEthernet 1/0/1 as the primary port
and GigabitEthernet 1/0/2 as the secondary port;
z Specify Device B, Device C and Device D as the transit nodes of primary ring 1, their
GigabitEthernet 1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port;
Figure 3-8 Network diagram for single ring configuration
# Configure the suppression time of physical-link-state changes on GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2 as zero, disable STP, configure the two ports as trunk ports, and assign them to
all VLANs, and configure them to trust the 802.1p precedence of the received packets.
3-17

[DeviceA-GigabitEthernet1/0/1] link-delay 0
[DeviceA-GigabitEthernet1/0/1] undo stp enable
[DeviceA-GigabitEthernet1/0/1] qos trust dot1p
# Create RRPP domain 1, configure VLAN 4092 as the primary control VLAN of RRPP domain 1, and
configure the VLANs mapped to MSTIs 0 through 16 as the protected VLANs of RRPP domain 1.
[DeviceA] rrpp domain 1
[DeviceA-rrpp-domain1] control-vlan 4092
[DeviceA-rrpp-domain1] protected-vlan reference-instance 0 to 16
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/1 as the primary
port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
[DeviceA-rrpp-domain1] ring 1 node-mode master primary-port gigabitethernet 1/0/1
secondary-port gigabitethernet 1/0/2 level 0
[DeviceA-rrpp-domain1] ring 1 enable
[DeviceA-rrpp-domain1] quit
# Enable RRPP.
[DeviceA] rrpp enable
[DeviceB-GigabitEthernet1/0/1] link-delay 0
[DeviceB-GigabitEthernet1/0/1] undo stp enable
[DeviceB-GigabitEthernet1/0/1] qos trust dot1p
3-18

[DeviceB] rrpp domain 1
[DeviceB-rrpp-domain1] control-vlan 4092
[DeviceB-rrpp-domain1] protected-vlan reference-instance 0 to 16
# Configure Device B as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary
[DeviceB-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1
[DeviceB-rrpp-domain1] ring 1 enable
[DeviceB-rrpp-domain1] quit
# Enable RRPP.
[DeviceB] rrpp enable
The configuration on Device C is similar to that on Device B and thus omitted here.
The configuration on Device C is similar to that on Device B and thus omitted here.
5) Verification
After the above configuration, you can use the display command to view RRPP configuration and
operational information on each device.
Intersecting Ring Configuration Example

z Device A, Device B, Device C and Device D constitute RRPP domain 1, VLAN 4092 is the primary
control VLAN of RRPP domain 1, and RRPP domain 1 protects all the VLANs;
z Device A, Device B, Device C and Device D constitute primary ring 1, and Device B, Device C and
Device E constitute subring 2;
z Device A is the master node of primary ring 1, GigabitEthernet 1/0/1 is the primary port and
GigabitEthernet 1/0/2 is the secondary port;
z Device E is the master node of subring 2, GigabitEthernet 1/0/1 is the primary port and
GigabitEthernet 1/0/2 is the secondary port;
z Device B is the transit node of primary ring 1 and the edge node of subring 2, and GigabitEthernet
1/0/3 is the edge port;
z Device C is the transit node of primary ring 1 and the assistant-edge node of subring 1, and
GigabitEthernet 1/0/3 is the edge port;
z Device D is the transit node of primary ring 1, GigabitEthernet 1/0/1 is the primary port and
GigabitEthernet 1/0/2 is the secondary port.
3-19

Figure 3-9 Network diagram for intersecting rings configuration
[DeviceA-rrpp-domain1] protected-vlan reference-instance 0 to 16
3-20

# Enable RRPP.
# Configure the suppression time of physical-link-state changes on GigabitEthernet 1/0/1,
GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3 as zero, disable STP, configure the ports as trunk
ports, and assign them to all VLANs, and configure them to trust the 802.1p precedence of the
received packets.
[DeviceB-rrpp-domain1] protected-vlan reference-instance 0 to 16
# Configure Device B as a transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port
and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
# Configure Device B as the edge node of subring 2, with GigabitEthernet 1/0/3 as the edge port, and
enable ring 2.
[DeviceB-rrpp-domain1] ring 2 node-mode edge edge-port gigabitethernet 1/0/3
3-21

# Enable RRPP.
# Configure the suppression time of physical-link-state changes on GigabitEthernet 1/0/1,
GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3 as zero, disable STP, configure the ports as trunk
ports, and assign them to all VLANs, and configure them to trust the 802.1p precedence of the
received packets.
[DeviceC-GigabitEthernet1/0/1] link-delay 0
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan all
[DeviceC-GigabitEthernet1/0/1] qos trust dot1p
configure VLANs mapped to MSTIs 0 through 16 as the protected VLANs of RRPP domain 1.
[DeviceC] rrpp domain 1
[DeviceC-rrpp-domain1] control-vlan 4092
[DeviceC-rrpp-domain1] protected-vlan reference-instance 0 to 16
# Configure Device C as a transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary port
[DeviceC-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1
[DeviceC-rrpp-domain1] ring 1 enable
# Configure Device C as the assistant-edge node of subring 2, with GigabitEthernet 1/0/3 as the edge
port, and enable ring 2.
[DeviceC-rrpp-domain1] ring 2 node-mode assistant-edge edge-port gigabitethernet 1/0/3
[DeviceC-rrpp-domain1] quit
# Enable RRPP.
3-22

[DeviceC] rrpp enable
[DeviceD-GigabitEthernet1/0/1] link-delay 0
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan all
[DeviceD-GigabitEthernet1/0/1] qos trust dot1p
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan all
[DeviceD] rrpp domain 1
[DeviceD-rrpp-domain1] control-vlan 4092
[DeviceD-rrpp-domain1] protected-vlan reference-instance 0 to 16
# Configure Device D as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary
[DeviceD-rrpp-domain1] ring 1 node-mode transit primary-port gigabitethernet 1/0/1
[DeviceD-rrpp-domain1] ring 1 enable
[DeviceD-rrpp-domain1] quit
# Enable RRPP.
[DeviceD] rrpp enable
[DeviceE-GigabitEthernet1/0/1] link-delay 0
[DeviceE-GigabitEthernet1/0/1] undo stp enable
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan all
[DeviceE-GigabitEthernet1/0/1] qos trust dot1p
3-23

[DeviceE-GigabitEthernet1/0/2] port trunk permit vlan all
[DeviceE] rrpp domain 1
[DeviceE-rrpp-domain1] control-vlan 4092
[DeviceE-rrpp-domain1] protected-vlan reference-instance 0 to 16
# Configure Device E as the master node of subring 2, with GigabitEthernet 1/0/1 as the primary port
[DeviceE-rrpp-domain1] ring 2 node-mode master primary-port gigabitethernet 1/0/1
[DeviceE-rrpp-domain1] ring 2 enable
[DeviceE-rrpp-domain1] quit
# Enable RRPP.
[DeviceE] rrpp enable
6) Verification
After the configuration, you can use the display command to view RRPP configuration and operational
information on each device.
Intersecting-Ring Load Balancing Configuration Example
z Device A, Device B, Device C, Device D, and Device F constitute RRPP domain 1, and VLAN 100
is the primary control VLAN of the RRPP domain. Device A is the master node of the primary ring
Ring 1; Device D is the transit node of the primary ring Ring 1; Device F is the master node of the
subring Ring 3; Device C is the edge node of the subring Ring 3; Device B is the assistant-edge
node of the subring Ring 3.
z Device A, Device B, Device C, Device D, and Device E constitute RRPP domain 2, and VLAN 105
is the primary control VLAN of the RRPP domain. Device A is the master node of the primary ring
Ring 1; Device D is the transit node of the primary ring Ring 1; Device E is the master node of the
subring Ring 2; Device C is the edge node of the subring Ring 2; Device B is the assistant-edge
node of the subring Ring 2.
z Specify VLAN 10 as the protected VLAN of domain 1, and VLAN 20 as the protected VLAN of
domain 2. Thus, you can achieve VLAN-based load balancing on the primary ring.
z As the edge node and assistant-edge node of subring Ring 2 is the same as those of subring Ring
3, and the two subrings have the same SRPTs, you can add subrings Ring 2 and Ring 3 to the
RRPP ring group to reduce Edge-Hello traffic.
3-24

Figure 3-10 Network diagram for intersecting-ring load balancing configuration
# Create VLANs 10 and 20, map VLAN 10 to MSTI 1 and VLAN 20 to MSTI 2, and activate MST region
configuration.
[DeviceA] vlan 10
[DeviceA] vlan 20
[DeviceA] stp region-configuration
[DeviceA-mst-region] active region-configuration
[DeviceA-mst-region] quit

GigabitEthernet 1/0/2 as zero, disable STP, configure the two ports as trunk ports, remove them from
VLAN 1, and assign them to VLAN 10 and VLAN 20, and configure them to trust the 802.1p
precedence of the received packets.
[DeviceA-GigabitEthernet1/0/1] port trunk permit vlan 10 20
3-25

[DeviceA-GigabitEthernet1/0/2] port trunk permit vlan 10 20
configure the VLAN mapped to MSTI 1 as the protected VLAN of RRPP domain 1.
[DeviceA-rrpp-domain1] protected-vlan reference-instance 1
[DeviceA-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device A as the master node of primary ring 1, with GigabitEthernet 1/0/2 as the master
# Enable RRPP.
configuration.
[DeviceB] vlan 10
[DeviceB] vlan 20
[DeviceB] stp region-configuration
[DeviceB-mst-region] active region-configuration
[DeviceB-mst-region] quit
3-26

[DeviceB-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceB-GigabitEthernet1/0/1] port trunk permit vlan 10 20
[DeviceB-GigabitEthernet1/0/2] port trunk permit vlan 10 20
# Configure the suppression time of physical-link-state changes on GigabitEthernet 1/0/3 as zero,

disable STP, configure the port as a trunk port, remove it from VLAN 1, and assign it to VLAN 20, and
configure it to trust the 802.1p precedence of the received packets.
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 20

[DeviceB-GigabitEthernet1/0/4] port trunk permit vlan 10
3-27

[DeviceB-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device B as a transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet 1/0/1
as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
# Configure Device B as the assistant-edge node of subring 3 in RRPP domain 1, with GigabitEthernet
1/0/4 as the edge port, and enable subring 3.
[DeviceB-rrpp-domain1] ring 3 node-mode assistant-edge edge-port gigabitethernet 1/0/4
[DeviceB-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device B as the transit node of primary ring 1, with GigabitEthernet 1/0/1 as the primary
# Configure Device B as the assistant-edge node of subring 2 in RRPP domain 2, with GigabitEthernet
1/0/3 as the edge port, and enable subring 2.
[DeviceB-rrpp-domain2] ring 2 node-mode assistant-edge edge-port gigabitethernet 1/0/3
# Enable RRPP.
configuration.
[DeviceC] vlan 10
[DeviceC] vlan 20

3-28

[DeviceC-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceC-GigabitEthernet1/0/1] port trunk permit vlan 10 20
[DeviceC-GigabitEthernet1/0/2] port trunk permit vlan 10 20

[DeviceC-GigabitEthernet1/0/3] port trunk permit vlan 20

[DeviceC-GigabitEthernet1/0/4] port trunk permit vlan 10
[DeviceC-rrpp-domain1] protected-vlan reference-instance 1
3-29

# Configure Device C as the transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet
1/0/1 as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable ring 1.
# Configure Device C as the edge node of subring 3 in RRPP domain 1, with GigabitEthernet 1/0/4 as
the edge port, and enable subring 3.
[DeviceC-rrpp-domain1] ring 3 node-mode edge edge-port gigabitethernet 1/0/4
[DeviceC-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device C as the transit node of primary ring 1 in RRPP domain 2, with GigabitEthernet
# Configure Device C as the edge node of subring 2 in RRPP domain 2, with GigabitEthernet 1/0/3 as
the edge port, and enable subring 2.
[DeviceC-rrpp-domain2] ring 2 node-mode edge edge-port gigabitethernet 1/0/3
# Enable RRPP.
[DeviceC] rrpp enable
configuration.
[DeviceD] vlan 10
[DeviceD-vlan10] quit
[DeviceD] vlan 20
[DeviceD-vlan20] quit

3-30

[DeviceD-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceD-GigabitEthernet1/0/1] port trunk permit vlan 10 20
[DeviceD-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceD-GigabitEthernet1/0/2] port trunk permit vlan 10 20
[DeviceD-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device D as the transit node of primary ring 1 in RRPP domain 1, with GigabitEthernet
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN of RPPP domain 2, and
[DeviceD-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device D as the transit node of primary ring 1 in RRPP domain 2, with GigabitEthernet
# Enable RRPP.
[DeviceD] rrpp enable
# Create VLAN 20, map VLAN 20 to MSTI 2, and activate MST region configuration.
[DeviceE] vlan 20
3-31

[DeviceE-vlan20] quit
[DeviceE] stp region-configuration
[DeviceE-mst-region] instance 2 vlan 20
[DeviceE-mst-region] active region-configuration
[DeviceE-mst-region] quit

VLAN 1, and assign them to VLAN 20, and configure them to trust the 802.1p precedence of the
received packets.
[DeviceE-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceE-GigabitEthernet1/0/1] port trunk permit vlan 20
[DeviceE-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceE-GigabitEthernet1/0/2] port trunk permit vlan 20
# Create RRPP domain 2, configure VLAN 105 as the primary control VLAN, and configure the VLAN
mapped to MSTI 2 as the protected VLAN.
[DeviceE] rrpp domain 2
[DeviceE-rrpp-domain2] control-vlan 105
[DeviceE-rrpp-domain2] protected-vlan reference-instance 2
# Configure Device E as the master mode of subring 2 in RRPP domain 2, with GigabitEthernet 1/0/2
as the primary port and GigabitEthernet 1/0/1 as the secondary port, and enable ring 2.
[DeviceE-rrpp-domain2] ring 2 node-mode master primary-port gigabitethernet 1/0/2
[DeviceE-rrpp-domain2] ring 2 enable
[DeviceE-rrpp-domain2] quit
# Enable RRPP.
[DeviceE] rrpp enable
6) Configuration on Device F
# Create VLAN 10, map VLAN 10 to MSTI 1, and activate MST region configuration.
<DeviceF> system-view
[DeviceF] vlan 10
[DeviceF-vlan10] quit
[DeviceF] stp region-configuration
[DeviceF-mst-region] instance 1 vlan 10
3-32

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

VLAN 1, and assign them to VLAN 10, and configure them to trust the 802.1p precedence of the
received packets.
[DeviceF] interface gigabitethernet 1/0/1
[DeviceF-GigabitEthernet1/0/1] link-delay 0
[DeviceF-GigabitEthernet1/0/1] undo stp enable
[DeviceF-GigabitEthernet1/0/1] port link-type trunk
[DeviceF-GigabitEthernet1/0/1] undo port trunk permit vlan 1
[DeviceF-GigabitEthernet1/0/1] port trunk permit vlan 10
[DeviceF-GigabitEthernet1/0/1] qos trust dot1p
[DeviceF-GigabitEthernet1/0/1] quit
[DeviceF] interface gigabitethernet 1/0/2
[DeviceF-GigabitEthernet1/0/2] link-delay 0
[DeviceF-GigabitEthernet1/0/2] undo stp enable
[DeviceF-GigabitEthernet1/0/2] port link-type trunk
[DeviceF-GigabitEthernet1/0/2] undo port trunk permit vlan 1
[DeviceF-GigabitEthernet1/0/2] port trunk permit vlan 10
[DeviceF-GigabitEthernet1/0/2] qos trust dot1p
[DeviceF-GigabitEthernet1/0/2] quit
# Create RRPP domain 1, configure VLAN 100 as the primary control VLAN, and configure the VLAN
mapped to MSTI 1 as the protected VLAN.
[DeviceF] rrpp domain 1
[DeviceF-rrpp-domain1] control-vlan 100
[DeviceF-rrpp-domain1] protected-vlan reference-instance 1
# Configure Device F as the master node of subring 3 in RRPP domain 1, with GigabitEthernet 1/0/1
as the primary port and GigabitEthernet 1/0/2 as the secondary port, and enable subring 3.
[DeviceF-rrpp-domain1] ring 3 node-mode master primary-port gigabitethernet 1/0/1
[DeviceF-rrpp-domain1] ring 3 enable
[DeviceF-rrpp-domain1] quit
# Enable RRPP.
[DeviceF] rrpp enable
7) RRPP ring group configurations on Device B and Device C after the configurations above
# Create RRPP ring group 1 on Device B, and add subrings 2 and 3 to the RRPP ring group.
[DeviceB] rrpp ring-group 1
[DeviceB-rrpp-ring-group1] domain 2 ring 2
[DeviceB-rrpp-ring-group1] domain 1 ring 3
# Create RRPP ring group 1 on Device C, and add subrings 2 and 3 to the RRPP ring group.
[DeviceC] rrpp ring-group 1
[DeviceC-rrpp-ring-group1] domain 2 ring 2
[DeviceC-rrpp-ring-group1] domain 1 ring 3
3-33

8) Verification
After the configuration, you can use the display command to view RRPP configuration and operational
information on each device.
Troubleshooting
Symptom:
When the link state is normal, the master node cannot receive Hello packets, and the master node
unblocks the secondary port.
Analysis:
The reasons may be:
z RRPP is not enabled on some nodes in the RRPP ring.
z The domain ID or primary control VLAN ID is not the same for the nodes in the same RRPP ring.
z Some ports are abnormal.
Solution:
z Use the display rrpp brief command to check whether RRPP is enabled for all nodes. If not, use
the rrpp enable command and the ring enable command to enable RRPP and RRPP rings for all
nodes.
z Use the display rrpp brief command to check whether the domain ID and primary control VLAN
ID are the same for all nodes. If not, set the same domain ID and primary control VLAN ID for the
nodes.
z Use the display rrpp verbose command to check the link state of each port in each ring.
z Use the debugging rrpp command on each node to check whether a port receives or transmits
Hello packets. If not, Hello packets are lost.
3-34

4 DLDP Configuration
When performing DLDP configuration, go to these sections for information you are interested in:
z Overview
z DLDP Configuration Task List
z Enabling DLDP
z Setting DLDP Mode
z Setting the Interval for Sending Advertisement Packets
z Setting the DelayDown Timer
z Setting the Port Shutdown Mode
z Configuring DLDP Authentication
z Resetting DLDP State
z Displaying and Maintaining DLDP
z DLDP Configuration Example
z Troubleshooting
Overview
Background
Sometimes, unidirectional links may appear in networks. On a unidirectional link, one end can receive
packets from the other end but the other end cannot. Unidirectional links result in problems such as
loops in an STP-enabled network.
As for fiber links, two kinds of unidirectional links exist. One occurs when fibers are cross-connected,
as shown in Figure 4-1. The other occurs when one end of a fiber is not connected or one fiber of a
fiber pair gets disconnected, as illustrated by the hollow arrows in Figure 4-2.
Figure 4-1 Unidirectional fiber link: cross-connected fibers
Device A
GE1/0/50 GE1/0/51
GE1/0/50 GE1/0/51
Device B
PC
4-1

Figure 4-2 Unidirectional fiber link: a fiber not connected or disconnected
Device A
GE1/0/50 GE1/0/51
GE1/0/50 GE1/0/51
Device B
PC
The Device Link Detection Protocol (DLDP) can detect the link status of a fiber cable or twisted pair.
On detecting a unidirectional link, DLDP, as configured, can shut down the related port automatically or
prompt users to take actions to avoid network problems.
As a data link layer protocol, DLDP cooperates with physical layer protocols to monitor link status.
While the auto-negotiation mechanism provided by the physical layer detects physical signals and
faults, DLDP performs operations such as identifying peer devices, detecting unidirectional links, and
shutting down unreachable ports. The cooperation of physical layer protocols and DLDP ensures that
physical/logical unidirectional links can be detected and shut down and prevents failure of other
protocols such as STP. If both ends of a link are operating normally at the physical layer, DLDP detects
whether the link is correctly connected at the link layer and whether the two ends can exchange
packets properly. This is beyond the capability of the auto-negotiation mechanism at the physical layer.
How DLDP Works
DLDP link states
A device is in one of these DLDP link states: Initial, Inactive, Active, Advertisement, Probe, Disable,
and DelayDown, as described in Table 4-1.
Table 4-1 DLDP link states
State Indicates
Initial DLDP is disabled.
Inactive DLDP is enabled but the link is down.
DLDP is enabled and the link is up, or the neighbor entries have
Active
been cleared.
All neighbors are bi-directionally reachable or DLDP has been in
Advertisement active state for more than five seconds. This is a relatively state
where no unidirectional link has been detected.
DLDP enters this state if it receives a packet from an unknown

neighbor. In this state, DLDP sends packets to check whether the
Probe link is unidirectional. As soon as DLDP transits to this state, a probe
timer starts and an echo timeout timer starts for each neighbor to be
probed.
4-2

State Indicates
A port enters this state when:
z A unidirectional link is detected.
Disable z The contact with the neighbor in enhanced mode gets lost.
In this state, the port does not receive or send packets other than
DLDPDUs.
A port in the Active, Advertisement, or Probe DLDP link state
transits to this state rather than removes the corresponding
DelayDown neighbor entry and transits to the Inactive state when it detects a
port-down event. When a port transits to this state, the DelayDown
timer is triggered.
DLDP timers
Table 4-2 DLDP timers
DLDP timer Description

Determines the Interval for sending Advertisement packets with RSY
tags, which defaults to 1 second. That is, a device in the active DLDP
Active timer link state sends one Advertisement packet with RSY tags every second
by default. The maximum number of advertisement packets with RSY
tags that can be sent successively is 5.
Determines the interval to send advertisement packets, which defaults
Advertisement timer
to 5 seconds.
Determines the interval to send Probe packets, which defaults to 0.5
seconds. That is, a device in the probe state sends two Probe packets
Probe timer
every second by default. The maximum number of Probe packets that
can be sent successively is 10.
This timer is set to 10 seconds and is triggered when a device transits
to the Probe state or an enhanced detect is launched. When the Echo
timer expires and no Echo packet has been received from a neighbor
device, the state of the link is set to unidirectional and the device
Echo timer
transits to the Disable state. In this case, the device sends Disable
packets, prompts the user to shut down the port or shuts down the port
automatically (depending on the DLDP down mode configured), and
removes the corresponding neighbor entries.
When a new neighbor joins, a neighbor entry is created and the
corresponding entry timer is triggered. When a DLDP packet is
received, the device updates the corresponding neighbor entry and the
entry aging timer.
In the normal mode, if no packet is received from a neighbor when the
Entry timer corresponding entry aging timer expires, DLDP sends advertisement
packets with RSY tags and removes the neighbor entry.
In the enhanced mode, if no packet is received from a neighbor when
the Entry timer expires, DLDP triggers the enhanced timer.
The setting of an Entry timer is three times that of the Advertisement
timer.
In the enhanced mode, this timer is triggered if no packet is received
from a neighbor when the entry aging timer expires. Enhanced timer is
Enhanced timer set to 1 second.
After the Enhanced timer is triggered, the device sends up to eight
probe packets to the neighbor at a frequency of one packet per second.
4-3

DLDP timer Description
A device in the Active, Advertisement, or Probe DLDP link state transits
to DelayDown state rather than removes the corresponding neighbor
entry and transits to the Inactive state when it detects a port-down
event.
When a device transits to this state, the DelayDown timer is triggered.
DelayDown timer
A device in DelayDown state only responds to port-up events.
A device in the DelayDown state resumes its original DLDP state if it
detects a port-up event before the DelayDown timer expires.
Otherwise, it removes the corresponding DLDP neighbor information
and transits to the Inactive state.
This timer is set to 2 seconds. That is, a port in the Disable state sends
RecoverProbe timer one RecoverProbe packet every two seconds to detect whether a
unidirectional link has restored.
DLDP mode
DLDP can operate in two modes: normal mode and enhanced mode, as described below.
z In normal DLDP mode, when an entry timer expires, the device removes the corresponding
neighbor entry and sends an Advertisement packet with RSY tag.
z In enhanced DLDP mode, when an entry timer expires, the Enhanced timer is triggered and the
device sends up to eight Probe packets at a frequency of one packet per second to test the
neighbor. If no Echo packet is received from the neighbor when the Echo timer expires, the device
transits to the Disable state.
Table 4-3 DLDP mode and neighbor entry aging
Detecting a neighbor Removing the neighbor Triggering the Enhanced

DLDP mode after the corresponding entry immediately after timer after an Entry timer
neighbor entry ages out the Entry timer expires expires
Normal
No Yes No
DLDP mode
Enhanced
Yes No Yes
DLDP mode
The enhanced DLDP mode is designed for addressing black holes. It prevents the cases where one
end of a link is up and the other is down. If you configure the speed and the duplex mode by force on a
device, the situation shown in Figure 4-3 may occur, where Port B is actually down but the state of Port
B cannot be detected by common data link protocols, so Port A is still up. In enhanced DLDP mode,
however, Port A tests Port B after the Entry timer concerning Port B expires. Port A then transits to the
Disable state if it receives no Echo packet from Port A when the Echo timer expires. As Port B is
physically down, it is in the Inactive DLDP state.
Figure 4-3 A case for Enhanced DLDP mode
4-4

z In normal DLDP mode, only fiber cross-connected unidirectional links (as shown in Figure 4-1 )
can be detected.
z In enhanced DLDP mode, two types of unidirectional links can be detected. One is fiber
cross-connected links (as shown in Figure 4-1). The other refers to fiber pairs with one fiber not
connected or disconnected (as shown in Figure 4-2). To detect unidirectional links that are of the
latter type, you need to configure the ports to operate at specific speed and in full duplex mode.
Otherwise, DLDP cannot take effect. When a fiber of a fiber pair is not connected or gets
disconnected, the port that can receive optical signals is in Disable state; the other port is in
Inactive state.
DLDP authentication mode
You can prevent network attacks and illegal detect through DLDP authentication. Three DLDP
authentication modes exist, as described below.
z Non-authentication. In this mode, the sending side sets the Authentication field and the
Authentication type field of DLDP packets to 0. The receiving side checks the values of the two
fields of received DLDP packets and drops the packets with the two fields conflicting with the
corresponding local configuration.
z Plain text authentication. In this mode, before sending a DLDP packet, the sending side sets the
Authentication field to the password configured in plain text and sets the Authentication type field
to 1. The receiving side checks the values of the two fields of received DLDP packets and drops
the packets with the two fields conflicting with the corresponding local configuration.
z MD5 authentication. In this mode, before sending a packet, the sending side encrypts the user
configured password using MD5 algorithm, assigns the digest to the Authentication field, and sets
the Authentication type field to 2. The receiving side checks the values of the two fields of received
DLDP packets and drops the packets with the two fields conflicting with the corresponding local
configuration.
DLDP implementation
1) On a DLDP-enabled link that is in up state, DLDP sends DLDP packets to the peer device and
processes the DLDP packets received from the peer device. DLDP packets sent vary with DLDP
states. Table 4-4 lists DLDP states and the corresponding packets.
Table 4-4 DLDP packet types and DLDP states
DLDP state Type of DLDP packets sent

Active Advertisement packet with RSY tag
Advertisement Normal Advertisement packet
Probe Probe packet
Disable Disable packet and RecoverProbe packet
4-5

When a device transits from a DLDP state other than Inactive state or Disable state to Initial state, it
sends Flush packets.
2) A received DLDP packet is processed as follows.

z In any of the three authentication modes, the packet is dropped if it fails to pass the authentication.
z The packet is dropped if the setting of the interval for sending Advertisement packets it carries
conflicts with the corresponding local setting.
z Other processes.
Table 4-5 Procedures for processing different types of DLDP packets
Packet type Processing procedure

If the corresponding neighbor entry does not exist,
Advertisement Retrieving the creates the neighbor entry, triggers the Entry timer, and
packet with RSY neighbor transits to Probe state.
tag information. If the corresponding neighbor entry already exists, resets
the Entry timer and transits to Probe state.
Normal Retrieves the creates the neighbor entry, triggers the Entry timer, and
Advertisement neighbor transits to Probe state.
packet information. If the corresponding neighbor entry already exists, resets
the Entry timer.
Determines If yes, no process is performed.
whether or not the
Flush packet
local port is in If not, removes the corresponding neighbor entry (if any).
Disable state.
Retrieves the creates the neighbor entry, transits to Probe state, and
Probe packet neighbor returns Echo packets.
information. If the corresponding neighbor entry already exists, resets
the Entry timer and returns Echo packets.
creates the neighbor entry, triggers the Entry timer, and
transits to Probe state.
If the neighbor information it carries
conflicts with the corresponding locally
Retrieves the The maintained neighbor entry, drops the
Echo packet neighbor correspondi packet.
information. ng neighbor Otherwise, sets the flag of the neighbor
entry as two-way connected. In addition, if the
already flags of all the neighbors are two-way
exists connected, the device transits from Probe
state to Advertisement state and disables
the Echo timer.
Check to see if the If yes, no process is performed.
Disable packet local port is in
Disable state. If not, the local port transits to Disable state.
4-6

Packet type Processing procedure
Check to see if the If not, no process is performed.
local port is in
RecoverProbe
Disable or
packet If yes, returns RecoverEcho packets.
Advertisement
state.
If not, no process is performed.
Check to see if the
RecoverEcho If yes, the local port transits to Active state if the neighbor
local port is in
packet information the packet carries is consistent with the local
Disable state.
port information.
Check to see if the If not, no process is performed.

local port operates
LinkDown packet
in Enhanced
mode. If yes and the local port is not in Disable state, the local
transits to Disable state.
3) If no echo packet is received from the neighbor, DLDP performs the following processing.
Table 4-6 Processing procedure when no echo packet is received from the neighbor
No echo packet received from the

Processing procedure
neighbor
In normal mode, no echo packet is DLDP transits to the Disable state, outputs log and
received when the Echo timer expires. tracking information, and sends Disable packets. In
addition, depending on the user-defined DLDP down
In enhanced mode, no echo packet is mode, DLDP shuts down the local port or prompts
received when the enhanced timer users to shut down the port, and removes the
expires. corresponding neighbor entry.
Link auto-recovery mechanism
If the port shutdown mode upon detection of a unidirectional link is set to auto, DLDP sets the state of
the port where a unidirectional link is detected to DLDP down automatically. A DLDP down port cannot
forward service traffic or send/receive any PDUs except DLDPDUs.
On a DLDP down port, DLDP monitors the unidirectional link. Once DLDP finds out that the state of the
link has restored to bidirectional, it brings up the port. The specific process is as follows:
The DLDP down port sends out a RecoverProbe packet, which carries only information about the local
port, every two seconds. Upon receiving the RecoverProbe packet, the remote end returns a
RecoverEcho packet. Upon receiving the RecoverEcho packet, the local port checks whether neighbor
information in the RecoverEcho packet is the same as the local port information. If they are the same,
the link between the local port and the neighbor is considered to have been restored to a bidirectional
link, and the port will transit from Disable state to Active state and re-establish neighborship with the
neighbor.
Only DLDP down ports can send and process Recover packets, including RecoverProbe packets and
RecoverEcho packets. The auto-recovery mechanism does not take effect on ports manually shut
down.
DLDP neighbor state
A DLDP neighbor can be in one of the three states described in Table 4-7.
4-7

Table 4-7 Description on DLDP neighbor states
DLDP neighbor state Description

A neighbor is in this state when it is just detected and is being probed.
No information indicating the state of the neighbor is received. A
Unknown
neighbor is in this state only when it is being probed. It transits to Two
way state or Unidirectional state after the probe operation finishes.
A neighbor is in this state after it receives response from its peer. This
Two way
state indicates the link is a two-way link.
A neighbor is in this state when the link connecting it is detected to be a
Unidirectional unidirectional link. After a device transits to this state, the corresponding
neighbor entries maintained on other devices are removed.
DLDP Configuration Task List

Complete the following tasks to configure DLDP:
Task Remarks
Enabling DLDP Required
Setting DLDP Mode Optional
Setting the Interval for Sending Advertisement Packets Optional
Setting the DelayDown Timer Optional
Setting the Port Shutdown Mode Optional
Configuring DLDP Authentication Optional
Resetting DLDP State Optional
Note that:
z DLDP takes effects only on Ethernet interfaces.
z DLDP can detect unidirectional links only after all links are connected. Therefore, before enabling
DLDP, make sure that optical fibers or copper twisted pairs are connected.
z To ensure unidirectional links can be detected, make sure these settings are the same on the both
sides: DLDP state (enabled/disabled), the interval for sending Advertisement packets,
authentication mode, and password.
z Keep the interval for sending Advertisement packets adequate to enable unidirectional links to be
detected in time. If the interval is too long, unidirectional links cannot be terminated in time; if the
interval is too short, network traffic may increase in vain.
z DLDP does not process any link aggregation control protocol (LACP) events. The links in an
aggregation group are treated individually in DLDP.
z When connecting two DLDP-enabled devices, make sure the DLDP software version ID fields of
the DLDP packets exchanged between the two devices are the same. Otherwise, DLDP may
operate improperly.
Enabling DLDP
To properly configure DLDP on the device, you need to first enable DLDP globally, and then enable it
on each port.
4-8

Follow these steps to enable DLDP:

Required
Enable DLDP globally dldp enable
Globally disabled by default
Enter Enter Either of the two is required.

Ethernet Ethernet port Configurations made in Ethernet port
interface-number
port view view view apply to the current port only;
or port configurations performed in port group
group Enter port port-group manual view apply to all the ports in the port
view group view port-group-name group.
Required
Enable DLDP dldp enable
Disabled on a port by default
You can enable or disable DLDP on a Layer 2 Ethernet port (an optical port or electrical port).
Setting DLDP Mode

There are two DLDP modes:
z Normal mode: In this mode, DLDP does not actively detect neighbors when the corresponding
neighbor entries age out. The system can identify only one type of unidirectional links:
cross-connected fibers.
z Enhanced mode: In this mode, DLDP actively detects neighbors when the corresponding neighbor
entries age out. The system can identify two types of unidirectional links: cross-connected fibers
and disconnected fibers.
Follow these steps to set DLDP mode:

dldp work-mode { enhance | Optional

Set DLDP mode
normal } Normal by default
Setting the Interval for Sending Advertisement Packets

You can set the interval for sending Advertisement packets to enable unidirectional links to be detected
in time.
Follow these steps to set the interval for sending Advertisement packets:

4-9

Set the interval for Optional
sending Advertisement dldp interval time
packets 5 seconds by default
z The interval for sending Advertisement packets applies to all DLDP-enabled ports.
z Set the interval for sending Advertisement packets to a value no longer than one-third of the STP
convergence time. If the interval is too long, STP loops may occur before unidirectional links are
torn down, and it takes a long time for the device to detect unidirectional links, thus causing more
traffic forwarding errors; if the interval is too short, unnecessary Advertisement packets can be
generated to consume bandwidth. Therefore, you are recommended to use the default value.
z To enable DLDP to operate properly, make sure the intervals for sending Advertisement packets
on both sides of a link are the same.
Setting the DelayDown Timer

On some ports, when the Tx line fails, the port goes down and then comes up again, causing optical
signal jitters on the Rx line. When a port goes down due to a Tx failure, the device transits to the
DelayDown state instead of the Inactive state to prevent the corresponding neighbor entries from being
removed. In the same time, the device triggers the DelayDown timer. If the port goes up before the
timer expires, the device restores the original state; if the port remains down when the timer expires,
the devices transits to the Inactive state.
Follow these steps to set the DelayDown timer

Optional
Set the DelayDown timer dldp delaydown-timer time
1 second by default
DelayDown timer setting applies to all DLDP-enabled ports.
Setting the Port Shutdown Mode

On detecting a unidirectional link, the ports can be shut down in one of the following two modes.
z Manual mode. This mode applies to networks with low performance, where normal links may be
treated as unidirectional links. It protects service packet transmission against false unidirectional
4-10

links. In this mode, DLDP only detects unidirectional links and generates log and traps. The
operations to shut down unidirectional link ports are accomplished by the administrator.
z Auto mode. In this mode, when a unidirectional link is detected, DLDP transits to Disable state,
generates log and traps, and set the port as DLDP Down.
Follow these steps to set port shutdown mode:

dldp unidirectional-shutdown Optional

Set port shutdown mode
{ auto | manual } auto by default
z On a port with both remote OAM loopback and DLDP enabled, if the port shutdown mode is auto
mode, the port will be shut down by DLDP when it receives a packet sent by itself, causing remote
OAM loopback to operate improperly. To prevent this, you need to set the port shutdown mode to
auto mode.
z If the device is busy, or the CPU utilization is high, normal links may be treated as unidirectional
links. In this case, you can set the port shutdown mode to manual mode to eliminate the effects
caused by false unidirectional link report.
Configuring DLDP Authentication

Follow these steps to configure DLDP authentication:

dldp authentication-mode Required

Configure DLDP
{ md5 md5-password | none |
authentication none by default
simple simple-password }
To enable DLDP to operate properly, make sure the DLDP authentication modes and the passwords of
the both sides of a link are the same.
Resetting DLDP State

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

z If the port is shut down with the shutdown command manually, use the undo shutdown
command on the port.
z If the port is shut down by DLDP automatically, use the dldp reset command on the port.
Alternatively, you can leave the work to DLDP, which can enable the port automatically upon
detecting that the link has been restored to bidirectional. For how to reset DLDP state with the
dldp reset command, refer to Resetting DLDP State in System View and Resetting DLDP State in
Port view/Port Group View.
The DLDP state that the port transits to upon the DLDP state reset operation depends on its physical
state. If the port is physically down, it transits to Inactive state; if the port is physically up, it transits to
Active state.
Resetting DLDP State in System View
Resetting DLDP state in system view applies to all the ports shut down by DLDP.
Follow these steps to reset DLDP in system view:

Reset DLDP state dldp reset Required
Resetting DLDP State in Port view/Port Group View
Resetting DLDP state in port view or port group view applies to the current port or all the ports in the
port group shut down by DLDP.
Follow these steps to reset DLDP state in port view/port group view:

Enter Ethernet interface interface-type Either is required.
Enter port view interface-number
Ethernet Configurations made in Ethernet
port port view apply to the current port
view/port Enter port group port-group manual only; configurations performed in
group view view port-group-name port group view apply to all the ports
in the port group.
Reset DLDP state dldp reset Required
Displaying and Maintaining DLDP

Display the DLDP configuration display dldp [ interface-type
of a port interface-number ]
Display the statistics on DLDP display dldp statistics
packets passing through a port [ interface-type interface-number ]
Clear the statistics on DLDP reset dldp statistics
packets passing through a port [ interface-type interface-number ]
4-12

DLDP Configuration Example
z Device A and Device B are connected through two fiber pairs, in which two fibers are
cross-connected, as shown in Figure 4-4.
z It is desired that the unidirectional links can be disconnected on being detected; and the ports shut
down by DLDP can be restored after the fiber connections are corrected.
Figure 4-4 Network diagram for DLDP configuration
Device A
GE1/0/50 GE1/0/51
GE1/0/50 GE1/0/51
Device B
PC
# Enable DLDP on GigabitEthernet1/0/50 and GigabitEthernet 1/0/51.
[DeviceA-GigabitEthernet1/0/50] dldp enable
[DeviceA-GigabitEthernet1/0/51] dldp enable
# Set the interval for sending Advertisement packets to 6 seconds.

[DeviceA] dldp interval 6
# Set the DelayDown timer to 2 seconds.

[DeviceA] dldp delaydown-timer 2
# Set the DLDP mode as enhanced mode.

[DeviceA] dldp work-mode enhance
# Set the port shutdown mode as auto mode.

[DeviceA] dldp unidirectional-shutdown auto
# Enable DLDP globally.

[DeviceA] dldp enable
4-13

Configure Device B as you configure Device A.
You can use the display dldp command to display the DLDP configuration information on ports.
# Display the DLDP configuration information on all the DLDP-enabled ports of Device A.
[DeviceA] display dldp
DLDP global status : enable
DLDP interval : 6s
DLDP work-mode : enhance
DLDP authentication-mode : none
DLDP unidirectional-shutdown : auto
DLDP delaydown-timer : 2s
The number of enabled ports is 2.
Interface GigabitEthernet1/0/50
DLDP port state : disable
DLDP link state : down
The neighbor number of the port is 0.
DLDP port state : disable
DLDP link state : down
The output information indicates that both GigabitEthernet 1/0/50 and GigabitEthernet 1/0/51 are in
Disable state and the links are down, which means unidirectional links are detected and the two ports
are thus shut down.
Correct the fiber connections after detecting the problem, and perform the following operations:
# Reset DLDP state for the ports shut down by DLDP.
[DeviceA] dldp reset
# Display the DLDP configuration information on all the DLDP-enabled ports of Device A.
[DeviceA] display dldp
DLDP global status : enable
DLDP interval : 6s
DLDP work-mode : enhance
DLDP authentication-mode : none
DLDP unidirectional-shutdown : auto
DLDP delaydown-timer : 2s
The number of enabled ports is 2.
DLDP port state : advertisement
DLDP link state : up
Neighbor mac address : 0000-0000-0101
Neighbor port index : 59
Neighbor state : two way
4-14

Neighbor aged time : 11
DLDP port state : advertisement
DLDP link state : up
Neighbor mac address : 0000-0000-0102
Neighbor port index : 59
Neighbor state : two way
Neighbor aged time : 11
The output information indicates that both GigabitEthernet 1/0/50 and GigabitEthernet 1/0/51 are in
Advertisement state and the links are up, which means unidirectional links are not detected and the
two ports are restored.
Troubleshooting
Symptom:
Two DLDP-enabled devices, Device A and Device B, are connected through two fiber pairs, in which
two fibers are cross-connected. The unidirectional links cannot be detected; all the four ports involved
are in Advertisement state.
Analysis:
The problem can be caused by the following.
z The intervals for sending Advertisement packets on Device A and Device B are not the same.
z DLDP authentication modes/passwords on Device A and Device B are not the same.
Solution:
Make sure the interval for sending Advertisement packets, the authentication mode, and the password
on Device A and Device B are the same.
4-15

5 Ethernet OAM Configuration
When configuring the Ethernet OAM function, go to these sections for information you are interested
in:
z Ethernet OAM Overview
z Ethernet OAM Configuration Task List
z Configuring Basic Ethernet OAM Functions
z Configuring Link Monitoring
z Enabling OAM Remote Loopback
z Displaying and Maintaining Ethernet OAM Configuration
z Ethernet OAM Configuration Example
Ethernet OAM Overview

Background
With features such as ease of use and low price, Ethernet has gradually become the major underlying
technology for todays local area networks (LANs). Recently, with the emergence of Gigabit Ethernet
and 10-Gigabit Ethernet, Ethernet is gaining popularity in metropolitan area networks (MANs) and
wide area networks (WANs) as well.
In the beginning, Ethernet is mainly used in LANs, which have low reliability and stability requirements.
This is why an effective management and maintenance mechanism for Ethernet has been absent all
along, hindering the usage of Ethernet in MANs and WANs. Implementing Operation, Administration
and Maintenance (OAM) on Ethernet networks has now become an urgent matter.
As a tool monitoring Layer 2 link status, Ethernet OAM is mainly used to address common link-related
issues on the last mile. You can monitor the status of the point-to-point link between two directly
connected devices by enabling Ethernet OAM on them.
Major Functions of Ethernet OAM
Ethernet OAM can effectively promote your management and maintenance capabilities over Ethernet
networks, guaranteeing the stability of the networks. Its major functions include:
z Link performance monitoring: Monitors the performance indices of a link, including packet loss,
delay, and jitter, and collects traffic statistics of various types.
z Fault detection and alarm: Checks the connectivity of a link by sending OAM protocol data units
(OAMPDUs) and reports to the network administrators when a link error occurs.
z Remote loopback: Detects link errors by looping back non-OAMPDUs.
Ethernet OAMPDUs
Figure 5-1 shows the formats of different types of OAMPDUs.
5-1

Figure 5-1 Formats of different types of Ethernet OAMPDUs
The fields in an OAMPDU are described as follows:
Table 5-1 Description of the fields in an OAMPDU
Field Description
Destination MAC address of the Ethernet OAMPDU.
Dest addr It is a slow protocol multicast address 0180c2000002. As slow
protocol packet cannot be forwarded by bridges, Ethernet
OAMPDUs cannot be forwarded.
Source MAC address of the Ethernet OAMPDU.
Source addr It is the bridge MAC address of the sending side and is a unicast
MAC address.
Type of the encapsulated protocol in the Ethernet OAMPDU.
Type
The value is 0x8809.
The specific protocol being encapsulated in the Ethernet
Subtype OAMPDU.
The value is 0x03.
Flags Status information of an Ethernet OAM entity.
Code Type of the Ethernet OAMPDU
Throughout this document, a port with Ethernet OAM enabled is called an Ethernet OAM entity or an
OAM entity.
Table 5-2 shows the function of the three types of OAMPDUs.
5-2

Table 5-2 Functions of different types of OAMPDUs
OAMPDU type Function

Used for transmitting state information of an Ethernet OAM entity (including the
Information information about the local device and remote devices, and customized
OAMPDU information) to the remote Ethernet OAM entity and maintaining OAM
connections
Event Used by link monitoring to notify the remote OAM entity when it detects
Notification problems on the link in between.
OAMPDU
Loopback Used for remote loopback control. By inserting the information used to
Control enable/disable loopback to a loopback control OAMPDU, you can
OAMPDU enable/disable loopback on a remote OAM entity.
How Ethernet OAM Works
This section describes the working procedures of Ethernet OAM.
Ethernet OAM connection establishment
Ethernet OAM connection is the base of all the other Ethernet OAM functions. OAM connection
establishment is also known as the Discovery phase, where an Ethernet OAM entity discovers remote
OAM entities and establishes sessions with them.
In this phase, interconnected OAM entities notify the peer of their OAM configuration information and
the OAM capabilities of the local nodes by exchanging Information OAMPDUs and determine whether
Ethernet OAM connections can be established. An Ethernet OAM connection can be established only
when the settings concerning Loopback, link detecting, and link event of the both sides match. After an
Ethernet OAM connection is established, Ethernet OAM takes effect on it.
As for Ethernet OAM connection establishment, a device can operate in active Ethernet OAM mode or
passive Ethernet OAM mode. Table 5-3 compares active Ethernet OAM mode with passive Ethernet
OAM mode.
Table 5-3 Active Ethernet OAM mode and passive Ethernet OAM mode
Passive Ethernet
Item Active Ethernet OAM mode
OAM mode
Initiating OAM Discovery Available Unavailable
Responding to OAM Discovery Available Available
Transmitting Information OAMPDUs Available Available
Transmitting Event Notification

Available Available
OAMPDUs
Transmitting Information OAMPDUs
Available Available
with the Data/Pad field being empty
Transmitting Loopback Control
Available Unavailable
OAMPDUs
Responding to Loopback Control Available (if both sides
Available
OAMPDUs operate in active OAM mode)
5-3

z OAM connections can be initiated only by OAM entities operating in active OAM mode, while
those operating in passive mode wait and respond to the connection requests sent by their peers.
z No OAM connection can be established between OAM entities operating in passive OAM mode.
After an Ethernet OAM connection is established, the Ethernet OAM entities on both sides exchange
Information OAMPDUs periodically to keep the Ethernet OAM connection valid. If an Ethernet OAM
entity receives no Information OAMPDU for five seconds, the Ethernet OAM connection is
disconnected.
The interval to send Information OAMPDUs is determined by a timer. Up to ten Information OAMPDUs
can be sent in a second.
Link monitoring
Error detection in an Ethernet is difficult, especially when the physical connection in the network is not
disconnected but network performance is degrading gradually. Link monitoring is used to detect and
indicate link faults in various environments. Ethernet OAM implements link monitoring through the
exchange of Event Notification OAMPDUs. Upon detecting a link error event listed in Table 5-4, the
local OAM entity sends an Event Notification OAMPDU to notify the remote OAM entity. With the log
information, network administrators can keep track of network status in time. Table 5-4 describes the
link events.
Table 5-4 Ethernet OAM link error events
Ethernet OAM link events Description

An errored symbol event occurs when the number of detected
Errored symbol event symbol errors over a specific detection interval exceeds the
predefined threshold.
An errored frame event occurs when the number of detected
Errored frame event error frames over a specific interval exceeds the predefined
threshold.
An errored frame period event occurs if the number of frame
Errored frame period event errors in specific number of received frames exceeds the
predefined threshold.
When the number of error frame seconds detected on a port
Errored frame seconds event over a detection interval reaches the error threshold, an errored
frame seconds event occurs.
5-4

z The system transforms the period of detecting errored frame period events into the maximum
number of 64-byte frames that a port can send in the specific period, that is, the system takes the
maximum number of frames sent as the period. The maximum number of frames sent is
calculated using this formula: the maximum number of frames = interface bandwidth (bps)
errored frame period event detection period (in ms)/(64 8 1000)
z If errored frames appear in a certain second, this second is called an errored frame second.
Remote fault detection
In a network where traffic is interrupted due to device failures or unavailability, the flag field defined in
Ethernet OAMPDUs allows an Ethernet OAM entity to send error information to its peer. It can identify
the critical link error events listed in Table 5-5.
Table 5-5 Critical link error events
Ethernet OAM link events Description

Link Fault Peer link signal is lost.
Dying Gasp An unexpected fault, such as power failure, occurred.
Critical event An undetermined critical event happened.
As Information OAMPDUs are exchanged periodically across established OAM connections, an

Ethernet OAM entity can inform one of its OAM peers of link faults through Information OAMPDUs.
Therefore, the network administrator can keep track of link status in time through the log information
and troubleshoot in time.
Remote loopback
Remote loopback is available only after the Ethernet OAM connection is established. With remote
loopback enabled, the Ethernet OAM entity operating in active Ethernet OAM mode sends
non-OAMPDUs to its peer. After receiving these PDUs, the peer does not forward them according to
their destination addresses. Instead, it returns them to the sender along the original path.
Remote loopback enables you to check the link status and locate link failures. Performing remote
loopback periodically helps to detect network faults in time. Furthermore, performing remote loopback
by network segments helps to locate network faults.
Standards and Protocols
Ethernet OAM is defined in IEEE 802.3h (Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications. Amendment: Media Access Control
Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks).
Ethernet OAM Configuration Task List

Complete the following tasks to configure Ethernet OAM:
5-5

Task Remarks
Configuring Basic Ethernet OAM Functions Required
Configuring Errored Symbol Event Detection Optional
Configuring Link Configuring Errored Frame Event Detection Optional

Monitoring Configuring Errored Frame Period Event Detection Optional
Configuring Errored Frame Seconds Event Detection Optional
Enabling OAM Remote Loopback Optional
Configuring Basic Ethernet OAM Functions

As for Ethernet OAM connection establishment, a device can operate in active mode or passive mode.
After Ethernet OAM is enabled on an Ethernet port, according to its Ethernet OAM mode, the Ethernet
port establishes an Ethernet OAM connection with its peer port.
Follow these steps to configure basic Ethernet OAM functions:

Enter system view System-view
interface-number
Optional
Set Ethernet OAM operating
oam mode { active | passive } The default is active Ethernet
mode
OAM mode.
Required
Enable Ethernet OAM on the
oam enable Ethernet OAM is disabled by
current port
default.
To change the Ethernet OAM operating mode on an Ethernet OAM-enabled port, you need to first
disable Ethernet OAM on the port.
Configuring Link Monitoring
After Ethernet OAM connections are established, the link monitoring periods and thresholds
configured in this section take effect on all Ethernet ports automatically.
5-6

Configuring Errored Symbol Event Detection
An errored symbol event occurs when the number of detected symbol errors over a specific detection
interval exceeds the predefined threshold.
Follow these steps to configure errored symbol event detection:

Configure the errored symbol oam errored-symbol period Optional

event detection interval period-value 1 second by default
Configure the errored symbol oam errored-symbol threshold Optional

event triggering threshold threshold-value 1 by default
Configuring Errored Frame Event Detection
An errored frame event occurs when the number of detected error frames over a specific interval
exceeds the predefined threshold.
Follow these steps to configure errored frame event detection:

Configure the errored frame Optional

oam errored-frame period period-value
event detection interval 1 second by default
Configure the errored frame oam errored-frame threshold Optional

event triggering threshold threshold-value 1 by default
Configuring Errored Frame Period Event Detection
An errored frame period event occurs if the number of frame errors in specific number of received
frames exceeds the predefined threshold.
Follow these steps to configure errored frame period event detection:

Configure the errored Optional

oam errored-frame-period period
frame period event
period-value 1000 milliseconds by default
detection period
oam errored-frame-period
frame period event
threshold threshold-value 1 by default
triggering threshold
Configuring Errored Frame Seconds Event Detection
An errored frame seconds event occurs when the number of error frame seconds detected on a port
over a detection interval exceeds the error threshold.
5-7

Follow these steps to configure errored frame seconds event detection:


oam errored-frame-seconds period
frame seconds event
period-value 60 second by default
detection interval
oam errored-frame-seconds
frame seconds event
threshold threshold-value 1 by default
triggering threshold
Make sure the errored frame seconds triggering threshold is less than the errored frame seconds
detection interval. Otherwise, no errored frame seconds event can be generated.
Enabling OAM Remote Loopback

After enabling OAM remote loopback on a port, you can send loopback frames from the port to a
remote port and then observe how many of these loopback frames are returned. In this way, you can
calculate the packet loss ratio on the link, thus evaluating the link performance.
Follow these steps to enable Ethernet OAM remote Loopback:

Enter system view System-view
interface-number
Enable Ethernet OAM remote Required

oam loopback
loopback Disabled by default.
5-8

z Ethernet OAM remote loopback is available only after the Ethernet OAM connection is established
and can be performed only by the Ethernet OAM entities operating in active Ethernet OAM mode.
z Remote loopback is available only on full-duplex links that support remote loopback at both ends.
z Ethernet OAM remote loopback needs the support of the peer hardware.
z Enabling Ethernet OAM remote loopback interrupts data communications. After Ethernet OAM
remote loopback is disabled, all the ports involved will shut down and then come up. Ethernet
OAM remote loopback is disabled when you execute the undo oam enable command to disable
Ethernet OAM, when you execute the undo oam loopback command to disable Ethernet OAM
remote loopback, or when the Ethernet OAM connection times out.
z Ethernet OAM remote loopback is only applicable to individual links. It is not applicable to link
aggregation member ports. In addition, you cannot assign ports where Ethernet OAM remote
loopback is being performed to link aggregation groups. For more information about link
aggregation groups, refer to Link Aggregation Configuration in the Access Volume.
z Enabling internal loopback test on a port in remote loopback test can terminate the remote
loopback test. For more information about loopback test, refer to Ethernet Interface Configuration
in the Access Volume.
Displaying and Maintaining Ethernet OAM Configuration

Display global Ethernet OAM configuration display oam configuration
Display the statistics on critical events

display oam critical-event [ interface
after an Ethernet OAM connection is
interface-type interface-number ]
established
Display the statistics on Ethernet OAM link Available
display oam link-event { local | in any
error events after an Ethernet OAM
remote } [ interface interface-type view
connection is established or after you
interface-number ]
clear the statistics
display oam { local | remote }
Display the information about an Ethernet
[ interface interface-type
OAM connection
interface-number ]
Available
Clear statistics on Ethernet OAM packets reset oam [ interface interface-type
in user
and Ethernet OAM link error events interface-number ]
view only
Ethernet OAM Configuration Example

z Enable Ethernet OAM on Device A and Device B to auto-detect link errors between the two
devices.
z Monitor the performance of the link between Device A and Device B by collecting statistics about
the error frames received by Device A..
5-9

Figure 5-2 Network diagram for Ethernet OAM configuration
# Configure GigabitEthernet 1/0/1 to operate in passive Ethernet OAM mode and enable Ethernet
OAM for it.
[DeviceA-GigabitEthernet1/0/1] oam mode passivez
[DeviceA-GigabitEthernet1/0/1] oam enable
# Set the errored frame detection interval to 20 seconds and set the errored frame event triggering
threshold to 10.
[DeviceA] oam errored-frame period 20
[DeviceA] oam errored-frame threshold 10
# Configure GigabitEthernet 1/0/1 to operate in active Ethernet OAM mode (the default) and enable
Ethernet OAM for it.
[DeviceA-GigabitEthernet1/0/1] oam mode active
[DeviceB-GigabitEthernet1/0/1] oam enable
Use the display oam configuration command to display the Ethernet OAM configuration. For
example:
# Display the Ethernet OAM configuration on Device A.
[DeviceA] display oam configuration
Configuration of the link event window/threshold :
--------------------------------------------------------------------------
Errored-symbol Event period(in seconds) : 1
Errored-symbol Event threshold : 1
Errored-frame Event period(in seconds) : 20
Errored-frame Event threshold : 10
Errored-frame-period Event period(in ms) : 1000
Errored-frame-period Event threshold : 1
Errored-frame-seconds Event period(in seconds) : 60
Errored-frame-seconds Event threshold : 1
According to the above output information, the detection period of errored frame events is 20 seconds,
the detection threshold is 10 seconds, and all the other parameters use the default values.
5-10

You can use the display oam link-event command to display the statistics about Ethernet OAM link
events and use the display oam critical-event command to display the Ethernet OAM configuration
information. For example:
# Display the statistics of Ethernet OAM critical link events on all the ports of Device A.
[DeviceA] display oam critical-event
Port : GigabitEthernet1/0/1
Link Status : Up
Event statistic :
-------------------------------------------------------------------------
Link Fault :0 Dying Gasp : 0 Critical Event : 0
According to the above output information, no critical link event occurred on the link between Device A
and Device B.
# Display Ethernet OAM link event statistics of the remote end of Device B.
[DeviceB] display oam link-event remote
Port :GigabitEthernet1/0/1
Link Status :Up
OAMRemoteErrFrameEvent : (ms = milliseconds)
---------------------------------------------------------------------
Event Time Stamp : 5789 Errored FrameWindow : 10(100ms)
Errored Frame Threshold : 1 Errored Frame : 3
Error Running Total : 35 Event Running Total : 17
The above information indicates that 35 errors occurred since Ethernet OAM is enabled on Device A,
17 of which are caused by error frames. The link is instable.
5-11

6 Connectivity Fault Detection Configuration
When configuring CFD, go to these sections for information you are interested in:
z Overview
z CFD Configuration Task List
z Basic Configuration Tasks
z Configuring CC on MEPs
z Configuring LB on MEPs
z Configuring LT on MEPs
z Displaying and Maintaining CFD
z CFD Configuration Examples
Overview
Connectivity Fault Detection (CFD) is an end-to-end per-VLAN link layer Operations, Administration
and Maintenance (OAM) mechanism used for link connectivity detection, fault verification, and fault
location.
Basic Concepts in CFD
Maintenance domain
A maintenance domain (MD) defines the network where CFD plays its role. The MD boundary is
defined by some maintenance association end points MEPs configured on the ports. A MD is identified
by an MD name.
To locate faults exactly, CFD introduces eight levels (from 0 to 7) to MDs. The bigger the number, the
higher the level and the larger the area covered. Domains can touch or nest (if the outer domain has a
higher level than the nested one) but cannot intersect or overlap.
MD levels facilitate fault location and make fault location more accurate. As shown in Figure 6-1, MD_A
in light blue nests MD_B in dark blue. If a connectivity fault is detected at the boundary of MD_A, any of
the devices in MD_A, including Device A through Device E, may fail. In this case, if a connectivity fault
is also detected at the boundary of MD_B, the failure points may be any of Device B through Device D.
If the devices in MD_B operate normally, you can be sure that at least Device C is operational.
6-1

Figure 6-1 Two nested MDs
CFD exchanges messages and performs operations on a per-domain basis. By planning MDs properly
in a network, you can use CFD to locate failure points rapidly.
Maintenance association
A maintenance association (MA) is a set of maintenance points (MPs) in a MD. An MA is identified by

the MD name + MA name.
An MA serves a VLAN. Packets sent by the MPs in an MA carry the corresponding VLAN tag. An MP
can receive packets sent by other MPs in the same MA.
Maintenance point
An MP is configured on a port and belongs to an MA. MPs fall into two types: maintenance association
end points (MEPs) and maintenance association intermediate points (MIPs).
z MEP
Each MEP is identified by an integer called a MEP ID. The MEPs of an MD define the range and
boundary of the MD. The MA and MD that a MEP belongs to define the VLAN attribute and level of the
packets sent by the MEP. MEPs fall into inward-facing MEPs and outward-facing MEPs.
The level of a MEP determines the levels of packets that the MEP can process. The packets
transmitted from a MEP carry the level of the MEP. An MEP forwards packets at a higher level and
processes packet of its level or lower. The processing procedure is specific to packets in the same
VLAN. Packets of different VLANs are independent.
The direction of a MEP determines the position of the MD relative to the port. In Figure 6-2,
outward-facing MEPs are configured on the two ports. In Figure 6-3, inward-facing MEPs are
configured on the two ports.
An outward-facing MEP communicates through the wire side connected to the port; an inward-facing
MEP communicates through the relay function side.
6-2

Figure 6-2 Outward-facing MEP
Figure 6-3 Inward-facing MEP
z MIP
A MIP is internal to an MD. It cannot send CFD packets actively; however, it can handle and respond to
CFD packets. The MA and MD that a MIP belongs to define the VLAN attribute and level of the packets
received.
By cooperating with MEPs, a MIP can perform a function similar to ping and traceroute. Like a MEP, a
MIP forwards packets at a higher level without any processing.
Figure 6-4 demonstrates a grading example of the CFD module. In the figure, there are six devices,
labeled 1 through 6 respectively. Suppose each device has two ports, and MEPs and MIPs are
configured on some of these ports. Four levels of MDs are designed in this example, the bigger the
number, the higher the level and the larger the area covered. In this example, the X port of device 2 is
configured with the following MPs: a level 5 MIP, a level 3 inward-facing MEP, a level 2 inward-facing
MEP, and a level 0 outward-facing MEP.
6-3

Figure 6-4 Levels of MPs
Basic Functions of CFD
CFD works effectively only in properly-configured networks. Its functions, which are implemented
through the MPs, include:
z Continuity check (CC);
z Loopback (LB)
z Linktrace (LT)
Continuity check
Continuity check is responsible for checking the connectivity between MEPs. Connectivity faults are
usually caused by device faults or configuration errors. This function is implemented through periodic
sending of continuity check messages (CCMs) by the MEPs. As a multicast message, a CCM sent by
one MEP is intended to be received by all the other MEPs in the same MA. If a MEP fails to receive the
CCMs within 3.5 sending periods, the link is regarded as faulty and a corresponding log is generated.
When multiple MEPs send CCMs at the same time, the multipoint-to-multipoint link check is achieved.
Loopback
Similar to ping at the IP layer, loopback is responsible for verifying the connectivity between a local
device and a remote device. To implement this function, the local MEP sends loopback messages
(LBMs) to the remote MEP. Depending on whether the local MEP can receive a loopback reply
message (LBR) from the remote MEP, the link state between the two can be verified. LBMs and LBRs
are unicast messages. They are used to verify the connectivity between two points.
Linktrace
Linktrace is responsible for identifying the path between the source MEP and the destination MEP. This
function is implemented in the following way: the source MEP multicasts linktrace messages (LTMs) to
the destination MEP. After receiving the messages, the destination MEP and the MIPs that the LTMs
pass send back linktrace reply messages (LTRs) to the source MEP. Based on the reply messages,
6-4

the source MEP can identify the path to the destination MEP. Note that LTMs are multicast frames
while LTRs are unicast frames.
The CFD function is implemented in accordance with IEEE P802.1ag.
CFD Configuration Task List

For CFD to work effectively, you should first design the network by performing the following tasks:
z Grade the MDs in the entire network, and define the boundary of each MD.
z Assign a name for each MD. Make sure that the same MD has the same name on different
devices.
z Define the MA in each MD according to the VLAN you want to monitor.
z Assign a name for each MA. Make sure that the same MA in the same MD has the same name on
different devices.
z At the edges of MD and MA, MPs should be designed at the device port. MEPs can be designed
on devices or ports that are not at the edges.
Complete the following tasks to configure CFD:
Tasks Remarks
Required
Basic Configuration Tasks
These configurations are the foundation for other configuration tasks.
Required
Configuring CC on MEPs
Configuring the MEPs to send CCMs to manage link connectivity
Optional
Configuring LB on MEPs
Checking link state by testing link connectivity
Optional
Configuring LT on MEPs Tracing link fault and finding the path between the source MEP and
target MEP
z A port blocked by STP cannot receive, send, or respond to CFD messages, however, if the port is
configured as an outward-facing MEP, it can still receive and send CCM messages even if it is
blocked by STP.
z Only Ethernet ports support CFD.
Basic Configuration Tasks

Basic configuration tasks include:
z Configuring Service Instance
z Configuring MEP
z Configuring MIP Generation Rules
6-5

Based on the network design, you should configure MEPs or the rules for generating MIPs on each
device. However, before doing this you must first configure the service instance.
Configuring Service Instance
A service instance is indicated by an integer to represent an MA in an MD. The MD and MA define the
level and VLAN attribute of the messages handled by the MPs in a service instance.
Follow these steps to configure a service instance:

Required
Enable CFD cfd enable
CFD is disabled by default.
Required
Create an MD cfd md md-name level level-value
Not created by default
cfd ma ma-name md md-name Required

Create an MA
vlan vlan-id Not created by default
cfd service-instance instance-id Required

Create a service instance
md md-name ma ma-name Not created by default
z These configuration tasks are the foundation for other CFD configuration tasks.
z The last three steps in the table above must be performed strictly in order.
Configuring MEP
MEPs are functional entities in a service instance. CFD is implemented through operations on MEPs,
which provides such functions as CC, LB, LT and gives prompts on error CCMs and cross connections.
As a MEP is configured on a service instance, the MD level and VLAN attribute of the service instance
become the attribute of the MEP.
Follow these steps to configure a MEP:

interface-number
cfd mep mep-id Required
Configure a MEP service-instance instance-id
{ inbound | outbound } Not configured by default
6-6

cfd remote-mep Required
Configure a remote MEP for a
remote-mep-id
MEP in the same service No remote MEP is configured
service-instance instance-id
instance for a MEP by default.
mep mep-id
cfd mep service-instance Required
Enable the MEP instance-id mep mep-id
Configuring MIP Generation Rules
As functional entities in a service instance, MIPs deal with LBM and LTM messages.
MIPs are generated on each port according to some rules. You can choose appropriate MIP
generation rules based on your network design.
Follow these steps to configure the rules for generating MIPs:

Required
cfd mip-rule { explicit |
Configure the rules for By default, neither the MIPs nor the
default } service-instance
generating MIPs rules for generating MIPs are
instance-id
configured.
MIPs are generated on each port automatically according to the rules specified in the cfd mip-rule
command. If a port has no MIP, the system will check the MAs in each MD (from low to high levels),
and follow the rules in Table 6-1 to create or not create MIPs (within a single VLAN):
Table 6-1 Rules for generating MIP
The cfd mip-rule

MIP exists on low MEP exists on low
command is Create MIP or not
level MA level MA
configured as
Yes No
No No
Explicit
No Yes Yes
Default Yes
Each of the following actions or cases can cause MIPs to be created or deleted after you have
configured the cfd mip-rule command:
z Enabling CFD (use the cfd enable command)
z Creating or deleting the MEPs on a port
z Changes occur to the VLAN attribute of a port
z The rule specified in the cfd mip-rule command changes
6-7

Configuring CC on MEPs
After the CC function is configured, MEPs can send CCMs mutually to check the connectivity between
them.
Before configuring this function, you should first complete the MEP configuration.
Configuring Procedure
Follow these steps to configure CC on a MEP:

Configure the interval field cfd cc interval Optional

value in the CCM messages interval-field-value By default, the interval filed
sent by MEPs service-instance instance-id value is 4.
interface-number
cfd cc service-instance Required
Enable CCM sending on a
instance-id mep mep-id
MEP Disabled by default
enable
The relationship between the interval field value in the CCM messages, the interval between CCM
messages and the timeout time of the remote MEP is illustrated in Table 6-2.
Table 6-2 Relationship of the interval field value, the interval between CCM messages and the timeout
time of the remote MEP
The interval between CCM The timeout time of the
The interval field value
messages remote MEP
4 1 second 3.5 seconds
5 10 second 35 seconds
6 60 seconds 210 seconds
7 600 seconds 2100 seconds
On different devices, the MEPs belonging to the same MD and MA should be configured with the same
time interval for CCMs sending.
The LB function can verify the link state between two ends after CC detects a link fault.
6-8

Before configuring this function, you should first complete the MEP and MIP configuration tasks.
Follow these steps to configure LB on MEP:

cfd loopback service-instance instance-id mep Required

Enable LB mep-id { target-mep target-mep-id | target-mac Disabled by
mac-address } [ number loopback-number ] default
Configuring LT on MEPs
LT can trace the path between the specified MEP and the target MEP, and can also locate link faults by
sending LT messages automatically. The two functions are implemented in the following way:
z To implement the first function, the specified MEP first sends LTM messages to the target MEP.
Based on the LTR messages in response to the LTM messages, the path between the two MEPs
can be identified.
z In the latter case, after LT messages automatic sending is enabled, if a MEP fails to receive the
CCMs from the remote MEP within 3.5 sending intervals, the link between the two is regarded as
faulty and LTMs will be sent out. Based on the LTRs that echo back, the fault source can be
located.
Before configuring this function, you should first complete MEP and MIP configuration tasks.
Finding the Path Between a Source MEP and a Target MEP
Follow these steps to find the path between a source MEP and a target MEP:
cfd linktrace service-instance instance-id

Find the path between a mep mep-id { target-mep target-mep-id |
Required
source MEP and a target MEP target-mac mac-address } [ ttl ttl-value ]
[ hw-only ]
Enabling Automatic LT Messages Sending
Follow these steps to enable automatic LT messages sending:

Enable automatic LT cfd linktrace auto-detection Required

messages sending [ size size-value ] Disabled by default
6-9

Displaying and Maintaining CFD
Display CFD status display cfd status Available in any view
Display MD configuration
display cfd md Available in any view
information
Display MA configuration display cfd ma [ [ ma-name ]
information md md-name ]
Display service instance display cfd service-instance
configuration information [ instance-id ]
display cfd mp [ interface
Display MP information interface-type Available in any view
interface-number ]
Display the attribute and
display cfd mep mep-id
running information of the Available in any view
service-instance instance-id
MEPs
display cfd linktrace-reply
Display LTR information
[ service-instance instance-id Available in any view
received by a MEP
[ mep mep-id ] ]
display cfd remote-mep
Display the information of a
service-instance instance-id Available in any view
remote MEP
mep mep-id
Display the content of the LTR display cfd linktrace-reply
that responds to LTM auto-detection [ size Available in any view
messages size-value ]
CFD Configuration Examples

Configuring Service Instance
As shown in Figure 6-5, there are five devices in the MDs. Each device has four ports belonging to
VLAN 100. The light blue square frame and the blue one specify two different MDs.
z Two MDs, MD_A (indicated by the light blue square frame, with level 5) and MD_B (indicated by
the blue square frame, with level 3)) are designed in this network.
z Define the edge ports of each MD, and define the MD of each port.
z The VLAN IDs of each MA in the two MDs are all 100.
According to the network diagram as shown in Figure 6-5, You should perform the following
configurations:
z Configure MD_A on Device A and Device E
z Configure MD_B on Device C
z Configure MD_A and MD_B on Device B and Device D
z Configure an MA in each MD
z Configure a service instance for each MA
6-10

Figure 6-5 Network diagram for MD configuration
1) Configuration on Device A (configuration on Device E is the same as that on Device A)

[DeviceA] cfd enable
[DeviceA] cfd md MD_A level 5
[DeviceA] cfd ma MA_MD_A md MD_A vlan 100
[DeviceA] cfd service-instance 1 md MD_A ma MA_MD_A
[DeviceC] cfd enable
[DeviceC] cfd md MD_B level 3
[DeviceC] cfd ma MA_MD_B md MD_B vlan 100
[DeviceC] cfd service-instance 2 md MD_B ma MA_MD_B
3) Configuration on Device B (configuration on Device D is the same as that on Device B)
[DeviceB] cfd enable
[DeviceB] cfd md MD_A level 5
[DeviceB] cfd ma MA_MD_A md MD_A vlan 100
[DeviceB] cfd service-instance 1 md MD_A ma MA_MD_A
[DeviceB] cfd md MD_B level 3
[DeviceB] cfd ma MA_MD_B md MD_B vlan 100
[DeviceB] cfd service-instance 2 md MD_B ma MA_MD_B
After the above configuration, you can use the commands display cfd md, display cfd ma and
display cfd service-instance to verify your configuration.
Configuring MEP and Enabling CC on it
After finishing service instance configuration, you can start to design the MEPs.
z MEPs are configured at the edge or border of MDs. Find the edge port of each MD.
z Decide the MEP direction (inward-facing or outward-facing) on each edge port based on the MD
position.
z Assign a unique ID to each MEP in an MA.
6-11

z Decide the remote MEP for each MEP, and enable these MEPs.
According to the network diagram as shown in Figure 6-6, perform the following configurations:
z In MD_A, there are three edge ports: GigabitEthernet 1/0/1 on Device A, GigabitEthernet 1/0/3 on
Device D and GigabitEthernet 1/0/4 on Device E. Configure inward-facing MEPs on these ports
respectively.
z In MD_B, there are two edge ports: GigabitEthernet 1/0/3 on Device B and GigabitEthernet 1/0/1
on Device D. Configure outward-facing MEPs on the two ports respectively.
z In MD_A and MD_B, each MEP checks the messages from other MEPs.
Figure 6-6 Network diagram of MD and MEP configuration
1) On Device A
[DeviceA-GigabitEthernet1/0/1] cfd mep 1001 service-instance 1 inbound
[DeviceA-GigabitEthernet1/0/1] cfd remote-mep 5001 service-instance 1 mep 1001
[DeviceA-GigabitEthernet1/0/1] cfd remote-mep 4002 service-instance 1 mep 1001
[DeviceA-GigabitEthernet1/0/1] cfd mep service-instance 1 mep 1001 enable
[DeviceA-GigabitEthernet1/0/1] cfd cc service-instance 1 mep 1001 enable
2) On Device B
[DeviceB-GigabitEthernet1/0/3] cfd mep 2001 service-instance 2 outbound
[DeviceB-GigabitEthernet1/0/3] cfd remote-mep 4001 service-instance 2 mep 2001
[DeviceB-GigabitEthernet1/0/3] cfd mep service-instance 2 mep 2001 enable
[DeviceB-GigabitEthernet1/0/3] cfd cc service-instance 2 mep 2001 enable
3) On Device D
[DeviceD-GigabitEthernet1/0/1] cfd mep 4001 service-instance 2 outbound
[DeviceD-GigabitEthernet1/0/1] cfd remote-mep 2001 service-instance 2 mep 4001
[DeviceD-GigabitEthernet1/0/1] cfd mep service-instance 2 mep 4001 enable
[DeviceD-GigabitEthernet1/0/1] cfd cc service-instance 2 mep 4001 enable
[DeviceD-GigabitEthernet1/0/1] interface gigabitethernet 1/0/3
[DeviceD-GigabitEthernet1/0/3] cfd mep 4002 service-instance 1 inbound
6-12

[DeviceD-GigabitEthernet1/0/3] cfd mep service-instance 1 mep 4002 enable
[DeviceD-GigabitEthernet1/0/3] cfd cc service-instance 1 mep 4002 enable
4) On Device E
[DeviceE-GigabitEthernet1/0/4] cfd mep 5001 service-instance 1 inbound
[DeviceE-GigabitEthernet1/0/4] cfd remote-mep 1001 service-instance 1 mep 5001
[DeviceE-GigabitEthernet1/0/4] cfd remote-mep 4002 service-instance 1 mep 5001
[DeviceE-GigabitEthernet1/0/4] cfd mep service-instance 1 mep 5001 enable
[DeviceE-GigabitEthernet1/0/4] cfd cc service-instance 1 mep 5001 enable
After the above configuration, you can use the commands display cfd mp and display cfd mep to
verify your configuration.
Configuring the Rules for Generating MIPs
After finishing MEP configuration, you can continue to configure the MIPs.
MIPs, which are generated by some rules, are configured in the following way:
z Decide the device on which MIPs are to be configured.
z Choose suitable rules for MIP generation. By default, MIP is not configured on a device. If MIPs
are to be configured on each port in the MD, you should choose the default rule. If MIPs are to be
configured only when the low level MDs having MEP, you should choose the explicit rule.
According to the diagram as shown in Figure 6-7, perform the following configurations:
z In MD_A, Device B is designed to have MIPs when its port is configured with low level MEPs. In
this case, port GigabitEthernet 1/0/3 is configured with MEPs of MD_B, and the MIPs of MD_A
can be configured on this port. Based on the design, you should configure the MIP generation rule
of MD_A to explicit on Device B.
z The MIPs of MD_B are designed on Device C, and are configured on all ports. Based on this
design, the MIP generation rule should be configured as default.
Figure 6-7 Network diagram of MD and MP configuration
6-13

[DeviceB] cfd mip-rule explicit service-instance 1
2) Configure Device C
[DeviceC] cfd mip-rule default service-instance 2
After the above operation, you can use the display cfd mp command to verify your configuration.
Use the LB function to trace the fault source after CC detects a link fault.
As shown in Figure 6-6, enable LB on Device A so that Device A can send LBM messages to MEPs on
Device D.
# Configure Device A
[DeviceA] cfd loopback service-instance 1 mep 1001 target-mep 4002
Configuring LT on MEPs
Use the LT function to find the path and locate the fault after you obtain the state of the entire network
through the CC.
As shown in Figure 6-6, enable LT on Device A so that Device A can send LTM messages to the MEP
on Device D.
# Configure Device A
[DeviceA] cfd linktrace service-instance 1 mep 1001 target-mep 4002
6-14

7 Track Configuration
When configuring Track, go to these sections for information you are interested in:
z Track Overview
z Track Configuration Task List
z Configuring Collaboration Between the Track Module and the Detection Modules
z Configuring Collaboration Between the Track Module and the Application Modules
z Displaying and Maintaining Track Object(s)
z Track Configuration Examples
Track Overview
Figure 7-1 Collaboration through the Track module
Application modules Detection

modules
Track
Static routing NQA
modules
The Track module is used to implement collaboration between different modules.

The collaboration here involves three parts: the application modules, the Track module, and the
detection modules. These modules collaborate with one another through collaboration objects. That is,
the detection modules trigger the application modules to perform certain operations through the Track
module. More specifically, the detection modules probe the link status, network performance and so on,
and inform the application modules of the detection result through the Track module. After the
application modules are aware of the changes of network status, they deal with the changes
accordingly to avoid communication interruption and network performance degradation.
The Track module works between the application modules and the detection modules and is mainly
used to obscure the difference of various detection modules to provide a unified interface for
application modules.
Collaboration Between the Track Module and the Detection Modules
You can establish the collaboration between the Track module and the detection modules through
configuration. A detection module probes the link status and informs the Track module of the probe
result. The Track module then changes the status of the Track object accordingly:
z If the probe succeeds, the status of the corresponding Track object is Positive;
z If the probe fails, the status of the corresponding Track object is Negative.
7-1

At present, the detection modules that can collaborate with the Track module is the Network Quality
Analyzer (NQA). Refer to NQA Configuration in the System Volume for details of NQA.
Collaboration Between the Track Module and the Application Modules
You can establish the collaboration between the Track module and the application modules through
configuration. If the status of the Track object changes, the Track module tells the application modules
to deal with the change accordingly.
At present, the application modules that can collaborate with the Track module is static routing
Track Configuration Task List

To implement the collaboration function, you need to establish collaboration between the Track module
and the detection modules, and between the Track module and the application modules.
Complete these tasks to configure Track module:
Task Remarks
Configuring Collaboration Between the Track Configuring Track-NQA
Required
Module and the Detection Modules Collaboration
Configuring Collaboration Between the Track Configuring Track-Static

Required
Module and the Application Modules Routing Collaboration
Configuring Collaboration Between the Track Module and the

Detection Modules
Configuring Track-NQA Collaboration
Through the following configuration, you can establish the collaboration between the Track module and
the NQA, which probes the link status and informs the Track module of the probe result.
Follow these steps to configure Track-NQA collaboration:

Create a Track object and track track-entry-number nqa Required

associate it with the specified entry admin-name
Reaction entry of the NQA test operation-tag reaction No Track object is created by
group item-num default.
When you configure a Track object, the specified NQA test group and Reaction entry can be
nonexistent. In this case, the status of the configured Track object is Invalid.
7-2

Configuring Collaboration Between the Track Module and the
Application Modules
Configuring Track-Static Routing Collaboration
You can check the validity of a static route in real time by establishing collaboration between Track and
static routing.
If you specify the next hop but not the egress interface when configuring a static route, you can
associate the static route with a Track object and thus check the validity of the static route according to
the status of the Track object.
z If the status of the Track object is Positive, then the next hop of the static route is reachable, and
the configured static route is valid.
z If the status of the Track object is Negative, then the next hop of the static route is unreachable,
and the configured static route is invalid.
Follow these steps to configure the Track-Static Routing collaboration:

ip route-static dest-address
Configure the Track-Static next-hop-address track
Routing collaboration, so as to track-entry-number Required
check the reachability of the [ preference Not configured by default.
next hop of the static route preference-value ] [ tag
tag-value ] [ description
description-text ]
z For the configuration of Track-Static Routing collaboration, the specified static route can be an
existent or nonexistent one. For an existent static route, the static route and the specified Track
object are associated directly; for a nonexistent static route, the system creates the static route
and then associates it with the specified Track object.
z The Track object to be associated with the static route can be a nonexistent one. After you use the
track command to create the Track object, the association takes effect.
z If a static route needs route recursion, the associated Track object must monitor the next hop of
the recursive route instead of that of the static route; otherwise, a valid route may be considered
invalid.
z For details of static route configuration, refer to Static Routing Configuration in the IP Routing
Volume.
7-3

Displaying and Maintaining Track Object(s)
display track
specified Track object or all Available in any view
{ track-entry-number | all }
Track objects
Track Configuration Examples

Static Routing-Track-NQA Collaboration Configuration Example
z The next hop of the static route from Switch A to Switch C is Switch B.
z Configure Static Routing-Track-NQA collaboration on Switch A to implement real-time monitoring
of the validity of the static route to Switch C.
Figure 7-2 Network diagram for Static Routing-Track-NQA collaboration configuration
Switch B
Vlan-int3 Vlan-int2
10.2.1.1/24 10.1.1.1/24
Vlan-int3 Vlan-int2
10.2.1.2/24 10.1.1.2/24
Switch A Switch C
1) Configure the IP address of each interface as shown in Figure 7-2.

2) Configure a static route on Switch A and associate it with the Track object.
# Configure the address of the next hop of the static route to Switch C as 10.2.1.1, and configure the
static route to associate with Track object 1.
[SwitchA] ip route-static 10.1.1.2 24 10.2.1.1 track 1
3) Configure an NQA test group on Switch A.
# Create an NQA test group with the administrator admin and the operation tag test.
[SwitchA] nqa entry admin test
# Configure the test type as ICMP-echo.

[SwitchA-nqa-admin-test] type icmp-echo
# Configure the destination address as 10.2.1.1

[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.2.1.1
# Configure the test frequency as 100 ms.

[SwitchA-nqa-admin-test-icmp-echo] frequency 100
7-4

# Configure Reaction entry 1, specifying that five consecutive probe failures trigger the Static
Routing-Track-NQA collaboration.
[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type
consecutive 5 action-type trigger-only
[SwitchA-nqa-admin-test-icmp-echo] quit
# Start NQA probes.

[SwitchA] nqa schedule admin test start-time now lifetime forever
4) Configure a Track object on Switch A.
# Configure Track object 1, and associate it with Reaction entry 1 of the NQA test group (with the
administrator admin, and the operation tag test).
[SwitchA] track 1 nqa entry admin test reaction 1
# Display information of the Track object on Switch A.
[SwitchA] display track all
Track ID: 1
Status: Positive
Reference object:
NQA entry: admin test
Reaction: 1

10.1.1.0/24 Static 60 0 10.2.1.1 Vlan3

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3
10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The output information above indicates the NQA test result, that is, the next hop 10.2.1.1 is reachable
(the status of the Track object is Positive), and the configured static route is valid.
# Remove the IP address of interface VLAN-interface 3 on Switch B.
[SwitchB-Vlan-interface3] undo ip address
# Display information of the Track object on Switch A.

Track ID: 1
Status: Negative
Reference object:
Reaction: 1
7-5

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The output information above indicates the NQA test result, that is, the next hop 10.2.1.1 is
unreachable (the status of the Track object is Negative), and the configured static route is invalid.
7-6

Table of Contents
1 Logging In to an Ethernet Switch ............................................................................................................1-1

Logging In to an Ethernet Switch ............................................................................................................1-1
Introduction to User Interface..................................................................................................................1-1
Supported User Interfaces ..............................................................................................................1-1
Users and User Interfaces...............................................................................................................1-2
User Interface Number ....................................................................................................................1-2
Common User Interface Configuration............................................................................................1-2
2 Logging In Through the Console Port.....................................................................................................2-1

Introduction .............................................................................................................................................2-1
Setting Up the Connection to the Console Port ......................................................................................2-1
Console Port Login Configuration ...........................................................................................................2-3
Common Configuration....................................................................................................................2-3
Console Port Login Configurations for Different Authentication Modes..........................................2-5
Console Port Login Configuration with Authentication Mode Being None..............................................2-5
Configuration Procedure..................................................................................................................2-5
Configuration Example ....................................................................................................................2-6
Console Port Login Configuration with Authentication Mode Being Password ......................................2-7
Console Port Login Configuration with Authentication Mode Being Scheme .........................................2-9
Configuration Example ..................................................................................................................2-10
Configuring Command Authorization ....................................................................................................2-11
Configuring Command Accounting .......................................................................................................2-12
3 Logging In Through Telnet/SSH...............................................................................................................3-1

Logging In Through Telnet......................................................................................................................3-1
Introduction......................................................................................................................................3-1
Telnet Connection Establishment....................................................................................................3-1
Common Configuration....................................................................................................................3-3
Telnet Login Configuration Task List...............................................................................................3-4
Telnet Login Configuration with Authentication Mode Being None.................................................3-5
Telnet Login Configuration with Authentication Mode Being Password..........................................3-6
Telnet Login Configuration with Authentication Mode Being Scheme ............................................3-8
Logging In Through SSH ......................................................................................................................3-10
Configuring Command Authorization ....................................................................................................3-10
Configuring Command Accounting .......................................................................................................3-11
4 User Interface Configuration Examples ..................................................................................................4-1

User Authentication Configuration Example ...........................................................................................4-1
Network diagram .............................................................................................................................4-1
Configuration procedure ..................................................................................................................4-1
Command Authorization Configuration Example....................................................................................4-2
Network diagram .............................................................................................................................4-2

Command Accounting Configuration Example .......................................................................................4-4
Network diagram .............................................................................................................................4-4
5 Logging in Through Web-based Network Management System ..........................................................5-1

Introduction .............................................................................................................................................5-1
Web Server Configuration.......................................................................................................................5-1
Displaying Web Users.............................................................................................................................5-2
Configuration Example............................................................................................................................5-2
6 Logging In Through NMS..........................................................................................................................6-1

Introduction .............................................................................................................................................6-1
Connection Establishment Using NMS ...................................................................................................6-1
7 Specifying Source for Telnet Packets .....................................................................................................7-1

Introduction .............................................................................................................................................7-1
Specifying Source IP address/Interface for Telnet Packets....................................................................7-1
Displaying the source IP address/Interface Specified for Telnet Packets ..............................................7-2
8 Controlling Login Users............................................................................................................................8-1

Introduction .............................................................................................................................................8-1
Controlling Telnet Users .........................................................................................................................8-1
Prerequisites....................................................................................................................................8-1
Controlling Telnet Users by Source IP Addresses ..........................................................................8-1
Controlling Telnet Users by Source and Destination IP Addresses................................................8-2
Controlling Telnet Users by Source MAC Addresses .....................................................................8-3
Controlling Network Management Users by Source IP Addresses ........................................................8-4
Prerequisites....................................................................................................................................8-4
Controlling Network Management Users by Source IP Addresses.................................................8-4
Controlling Web Users by Source IP Addresses ....................................................................................8-6
Prerequisites....................................................................................................................................8-6
Controlling Web Users by Source IP Addresses.............................................................................8-6
Forcing Online Web Users Offline...................................................................................................8-6
9 Basic System Configurations...................................................................................................................9-1

Configuration Display ..............................................................................................................................9-1
Basic Configurations ...............................................................................................................................9-1
Entering/Exiting System View .........................................................................................................9-2
Configuring the Device Name .........................................................................................................9-2
Configuring the System Clock .........................................................................................................9-2
Enabling/Disabling the Display of Copyright Information ................................................................9-5
Configuring a Banner.......................................................................................................................9-6
Configuring CLI Hotkeys..................................................................................................................9-7
Configuring Command Aliases........................................................................................................9-8
Configuring User Privilege Levels and Command Levels ...............................................................9-9
Displaying and Maintaining Basic Configurations .........................................................................9-14
CLI Features .........................................................................................................................................9-15
ii

Introduction to CLI .........................................................................................................................9-15
Online Help with Command Lines .................................................................................................9-16
Synchronous Information Output...................................................................................................9-17
Undo Form of a Command............................................................................................................9-17
Editing Features ............................................................................................................................9-17
CLI Display ....................................................................................................................................9-18
Saving History Commands............................................................................................................9-21
Command Line Error Information ..................................................................................................9-22
10 Device Management ..............................................................................................................................10-1

Device Management Overview .............................................................................................................10-1
Device Management Configuration Task List .......................................................................................10-1
Configuring the Exception Handling Method ........................................................................................10-1
Rebooting a Device...............................................................................................................................10-2
Configuring the Scheduled Automatic Execution Function...................................................................10-3
Upgrading Device Software ..................................................................................................................10-4
Device Software Overview ............................................................................................................10-4
Upgrading the Boot ROM Program Through Command Lines .....................................................10-5
Upgrading the Boot File Through Command Lines.......................................................................10-5
Disabling Boot ROM Access.................................................................................................................10-6
Configuring a Detection Interval............................................................................................................10-6
Clearing the 16-bit Interface Indexes Not Used in the Current System................................................10-7
Identifying and Diagnosing Pluggable Transceivers.............................................................................10-7
Introduction to pluggable transceivers...........................................................................................10-7
Identifying pluggable transceivers .................................................................................................10-8
Diagnosing pluggable transceivers ...............................................................................................10-9
Displaying and Maintaining Device Management Configuration ..........................................................10-9
Device Management Configuration Examples....................................................................................10-10
Remote Scheduled Automatic Upgrade Configuration Example (Centralized Device) ..............10-10
Remote Scheduled Automatic Upgrade Configuration Example (Centralized IRF Device)...........10-11
11 File System Management Configuration.............................................................................................11-1

File System Management .....................................................................................................................11-1
File System Overview....................................................................................................................11-1
Filename Formats..........................................................................................................................11-1
Directory Operations......................................................................................................................11-2
File Operations ..............................................................................................................................11-3
Batch Operations...........................................................................................................................11-5
Storage Medium Operations .........................................................................................................11-6
Setting File System Prompt Modes ...............................................................................................11-6
File System Operations Example ..................................................................................................11-7
Configuration File Management............................................................................................................11-7
Configuration File Overview ..........................................................................................................11-8
Saving the Current Configuration ..................................................................................................11-9
Setting Configuration Rollback ....................................................................................................11-11
Specifying a Startup Configuration File for the Next System Startup .........................................11-15
Backing Up the Startup Configuration File ..................................................................................11-15
Deleting the Startup Configuration File for the Next Startup .......................................................11-16
Restoring the Startup Configuration File .....................................................................................11-16
iii

Displaying and Maintaining Device Configuration ..............................................................................11-17
12 FTP Configuration .................................................................................................................................12-1

FTP Overview .......................................................................................................................................12-1
Introduction to FTP ........................................................................................................................12-1
Operation of FTP ...........................................................................................................................12-1
Configuring the FTP Client....................................................................................................................12-3
Establishing an FTP Connection ...................................................................................................12-3
Configuring the FTP Client ............................................................................................................12-4
FTP Client Configuration Example........................................................................................................12-6
Single Device Upgrade..................................................................................................................12-6
IRF System Upgrade .....................................................................................................................12-7
Configuring the FTP Server ..................................................................................................................12-9
Configuring FTP Server Operating Parameters ............................................................................12-9
Configuring Authentication and Authorization on the FTP Server ..............................................12-10
FTP Server Configuration Example.............................................................................................12-11
Single Device Upgrade................................................................................................................12-11
IRF System Upgrade ...................................................................................................................12-13
Displaying and Maintaining FTP .........................................................................................................12-15
13 TFTP Configuration ...............................................................................................................................13-1

TFTP Overview .....................................................................................................................................13-1
Introduction to TFTP......................................................................................................................13-1
Operation of TFTP.........................................................................................................................13-1
Configuring the TFTP Client .................................................................................................................13-2
Displaying and Maintaining the TFTP Client.........................................................................................13-3
TFTP Client Configuration Example .....................................................................................................13-4
Single Device Upgrade..................................................................................................................13-4
IRF System Upgrade .....................................................................................................................13-5
14 HTTP Configuration...............................................................................................................................14-1
HTTP Overview.....................................................................................................................................14-1
How HTTP Works..........................................................................................................................14-1
Logging In to the Device Through HTTP.......................................................................................14-1
Protocols and Standards ...............................................................................................................14-1
Enabling the HTTP Service...................................................................................................................14-1
Configuring the Port Number of the HTTP Service...............................................................................14-2
Associating the HTTP Service with an ACL..........................................................................................14-2
Displaying and Maintaining HTTP.........................................................................................................14-2
15 HTTPS Configuration ............................................................................................................................15-1

HTTPS Overview ..................................................................................................................................15-1
HTTPS Configuration Task List ............................................................................................................15-1
Associating the HTTPS Service with an SSL Server Policy .................................................................15-2
Enabling the HTTPS Service ................................................................................................................15-2
Associating the HTTPS Service with a Certificate Attribute Access Control Policy..............................15-3
Configuring the Port Number of the HTTPS Service ............................................................................15-3
Associating the HTTPS Service with an ACL .......................................................................................15-4
Displaying and Maintaining HTTPS ......................................................................................................15-4
HTTPS Configuration Example.............................................................................................................15-4
iv

16 SNMP Configuration..............................................................................................................................16-1
SNMP Overview....................................................................................................................................16-1
SNMP Mechanism.........................................................................................................................16-1
SNMP Protocol Version.................................................................................................................16-2
MIB Overview ................................................................................................................................16-2
SNMP Configuration .............................................................................................................................16-3
Configuring SNMP Logging ..................................................................................................................16-5
Introduction to SNMP Logging ......................................................................................................16-5
Enabling SNMP Logging ...............................................................................................................16-5
SNMP Trap Configuration.....................................................................................................................16-6
Enabling the Trap Function ...........................................................................................................16-6
Configuring Trap Parameters ........................................................................................................16-7
Displaying and Maintaining SNMP........................................................................................................16-8
SNMP Configuration Example ..............................................................................................................16-9
SNMP Logging Configuration Example ..............................................................................................16-10
MIB Style Configuration ........................................................................................................................16-1
Setting the MIB Style .....................................................................................................................16-1
Displaying and Maintaining MIB ....................................................................................................16-1
17 RMON Configuration .............................................................................................................................17-1

RMON Overview ...................................................................................................................................17-1
Introduction....................................................................................................................................17-1
Working Mechanism ......................................................................................................................17-1
RMON Groups...............................................................................................................................17-2
Configuring RMON................................................................................................................................17-3
Configuration Prerequisites ...........................................................................................................17-3
Configuration Procedure................................................................................................................17-3
Displaying and Maintaining RMON .......................................................................................................17-5
RMON Configuration Example..............................................................................................................17-5
18 MAC Address Table Management Configuration...............................................................................18-1

Introduction to MAC Address Table ......................................................................................................18-1
How a MAC Address Table Entry is Generated............................................................................18-1
Types of MAC Address Table Entries ...........................................................................................18-2
MAC Address Table-Based Frame Forwarding ............................................................................18-2
Configuring MAC Address Table Management ....................................................................................18-3
Configuring MAC Address Table Entries.......................................................................................18-3
Disabling MAC Address Learning on a VLAN...............................................................................18-3
Configuring the Aging Timer for Dynamic MAC Address Entries..................................................18-4
Configuring the MAC Learning Limit .............................................................................................18-4
Displaying and Maintaining MAC Address Table Management ...........................................................18-5
MAC Address Table Management Configuration Example ..................................................................18-5
19 MAC Information Configuration ...........................................................................................................19-1

Overview ...............................................................................................................................................19-1
Introduction to MAC Information....................................................................................................19-1
How MAC Information Works ........................................................................................................19-1
Configuring MAC Information................................................................................................................19-1
Enabling MAC Information Globally ..............................................................................................19-1
Enabling MAC Information on an Interface ...................................................................................19-2

Configuring MAC Information Mode ..............................................................................................19-2
Configuring the Interval for Sending Syslog or Trap Messages....................................................19-2
Configuring the MAC Information Queue Length ..........................................................................19-2
MAC Information Configuration Example..............................................................................................19-3
MAC Information Configuration Example ......................................................................................19-3
20 System Maintenance and Debugging..................................................................................................20-1

System Maintenance and Debugging ...................................................................................................20-1
Ping .......................................................................................................................................................20-1
Introduction....................................................................................................................................20-1
Configuring Ping ............................................................................................................................20-1
Ping Configuration Example..........................................................................................................20-2
Tracert...................................................................................................................................................20-4
Introduction....................................................................................................................................20-4
Configuring Tracert........................................................................................................................20-4
System Debugging................................................................................................................................20-5
Introduction to System Debugging ................................................................................................20-5
Configuring System Debugging.....................................................................................................20-6
Ping and Tracert Configuration Example ..............................................................................................20-6
21 Information Center Configuration........................................................................................................21-1

Information Center Overview ................................................................................................................21-1
Introduction to Information Center.................................................................................................21-1
System Information Format ...........................................................................................................21-4
Configuring Information Center.............................................................................................................21-6
Information Center Configuration Task List...................................................................................21-6
Outputting System Information to the Console .............................................................................21-6
Outputting System Information to a Monitor Terminal...................................................................21-7
Outputting System Information to a Log Host ...............................................................................21-8
Outputting System Information to the Trap Buffer.........................................................................21-9
Outputting System Information to the Log Buffer ........................................................................21-10
Outputting System Information to the SNMP Module .................................................................21-11
Configuring Synchronous Information Output .............................................................................21-11
Disabling a Port from Generating Link Up/Down Logging Information .......................................21-12
Displaying and Maintaining Information Center ..................................................................................21-13
Information Center Configuration Examples.......................................................................................21-13
Outputting Log Information to a Unix Log Host ...........................................................................21-13
Outputting Log Information to a Linux Log Host..........................................................................21-15
Outputting Log Information to the Console .................................................................................21-17
22 Hotfix Configuration ..............................................................................................................................22-1

Hotfix Overview .....................................................................................................................................22-1
Basic Concepts in Hotfix ...............................................................................................................22-1
Patch Status ..................................................................................................................................22-1
Hotfix Configuration Task List ...............................................................................................................22-4
Configuration Prerequisites...................................................................................................................22-5
One-Step Patch Installation ..................................................................................................................22-5
Step-by-Step Patch Installation.............................................................................................................22-6
Step-by-Step Patch Installation Task List......................................................................................22-6
Configuring the Patch File Location ..............................................................................................22-6
vi

Loading a Patch File......................................................................................................................22-6
Activating Patches .........................................................................................................................22-7
Confirm Running Patches .............................................................................................................22-7
One-Step Patch Uninstallation..............................................................................................................22-8
Step-by-Step Patch Uninstallation ........................................................................................................22-8
Step-by-Step Patch Uninstallation Task List .................................................................................22-8
Stop Running Patches...................................................................................................................22-8
Deleting Patches ...........................................................................................................................22-8
Displaying and Maintaining Hotfix.........................................................................................................22-9
Hotfix Configuration Examples..............................................................................................................22-9
Hotfix Configuration Example (Single Device) ..............................................................................22-9
Hotfix Configuration Example (IRF Device).................................................................................22-10
23 NQA Configuration ................................................................................................................................22-1

NQA Overview ......................................................................................................................................22-1
Introduction to NQA .......................................................................................................................22-1
Features of NQA............................................................................................................................22-1
Basic Concepts of NQA.................................................................................................................22-3
NQA Test Operation ......................................................................................................................22-4
NQA Configuration Task List ................................................................................................................22-4
Configuring the NQA Server .................................................................................................................22-5
Enabling the NQA Client .......................................................................................................................22-5
Creating an NQA Test Group................................................................................................................22-5
Configuring an NQA Test Group...........................................................................................................22-6
Configuring an ICMP Echo Test....................................................................................................22-6
Configuring a DHCP Test..............................................................................................................22-7
Configuring an FTP Test ...............................................................................................................22-8
Configuring an HTTP Test.............................................................................................................22-9
Configuring a UDP Jitter Test......................................................................................................22-10
Configuring an SNMP Test..........................................................................................................22-12
Configuring a TCP Test ...............................................................................................................22-13
Configuring a UDP Echo Test .....................................................................................................22-14
Configuring a Voice Test .............................................................................................................22-15
Configuring a DLSw Test.............................................................................................................22-17
Configuring the Collaboration Function...............................................................................................22-18
Configuring Trap Delivery ...................................................................................................................22-19
Configuring the NQA Statistics Function.............................................................................................22-20
Configuring Optional Parameters Common to an NQA Test Group...................................................22-20
Scheduling an NQA Test Group .........................................................................................................22-22
Displaying and Maintaining NQA ........................................................................................................22-23
NQA Configuration Examples .............................................................................................................22-23
ICMP Echo Test Configuration Example.....................................................................................22-23
DHCP Test Configuration Example.............................................................................................22-24
FTP Test Configuration Example ................................................................................................22-25
HTTP Test Configuration Example..............................................................................................22-26
UDP Jitter Test Configuration Example.......................................................................................22-28
SNMP Test Configuration Example.............................................................................................22-30
TCP Test Configuration Example................................................................................................22-31
UDP Echo Test Configuration Example ......................................................................................22-33
vii

Voice Test Configuration Example ..............................................................................................22-34
DLSw Test Configuration Example .............................................................................................22-37
NQA Collaboration Configuration Example .................................................................................22-38
24 NTP Configuration .................................................................................................................................24-1

NTP Overview .......................................................................................................................................24-1
Applications of NTP .......................................................................................................................24-1
Advantages of NTP .......................................................................................................................24-1
How NTP Works ............................................................................................................................24-2
NTP Message Format ...................................................................................................................24-3
Operation Modes of NTP...............................................................................................................24-4
Multiple Instances of NTP .............................................................................................................24-6
NTP Configuration Task List .................................................................................................................24-6
Configuring the Operation Modes of NTP.............................................................................................24-7
Configuring NTP Client/Server Mode ............................................................................................24-7
Configuring the NTP Symmetric Peers Mode ...............................................................................24-8
Configuring NTP Broadcast Mode.................................................................................................24-9
Configuring NTP Multicast Mode...................................................................................................24-9
Configuring Optional Parameters of NTP ...........................................................................................24-10
Specifying the Source Interface for NTP Messages ...................................................................24-10
Disabling an Interface from Receiving NTP Messages...............................................................24-11
Configuring the Maximum Number of Dynamic Sessions Allowed .............................................24-11
Configuring Access-Control Rights .....................................................................................................24-11
Configuration Prerequisites .........................................................................................................24-12
Configuration Procedure..............................................................................................................24-12
Configuring NTP Authentication..........................................................................................................24-12
Configuration Prerequisites .........................................................................................................24-12
Configuration Procedure..............................................................................................................24-13
Displaying and Maintaining NTP.........................................................................................................24-14
NTP Configuration Examples..............................................................................................................24-15
Configuring NTP Client/Server Mode ..........................................................................................24-15
Configuring the NTP Symmetric Mode........................................................................................24-16
Configuring NTP Broadcast Mode...............................................................................................24-18
Configuring NTP Multicast Mode.................................................................................................24-19
Configuring NTP Client/Server Mode with Authentication...........................................................24-22
Configuring NTP Broadcast Mode with Authentication ...............................................................24-23
25 Cluster Management Configuration.....................................................................................................25-1

Cluster Management Overview.............................................................................................................25-1
Cluster Management Definition .....................................................................................................25-1
Roles in a Cluster ..........................................................................................................................25-1
How a Cluster Works.....................................................................................................................25-2
Cluster Configuration Task List.............................................................................................................25-5
Configuring the Management Device....................................................................................................25-7
Enabling NDP Globally and for Specific Ports ..............................................................................25-7
Configuring NDP Parameters........................................................................................................25-8
Enabling NTDP Globally and for Specific Ports ............................................................................25-8
Configuring NTDP Parameters......................................................................................................25-8
Manually Collecting Topology Information ....................................................................................25-9
viii

Enabling the Cluster Function .....................................................................................................25-10
Establishing a Cluster..................................................................................................................25-10
Enabling Management VLAN Auto-negotiation...........................................................................25-11
Configuring Communication Between the Management Device and the Member Devices Within a
Cluster .........................................................................................................................................25-11
Configuring Cluster Management Protocol Packets ...................................................................25-11
Cluster Member Management.....................................................................................................25-12
Configuring the Member Devices........................................................................................................25-13
Enabling NDP ..............................................................................................................................25-13
Enabling NTDP............................................................................................................................25-13
Manually Collecting Topology Information ..................................................................................25-13
Enabling the Cluster Function .....................................................................................................25-13
Deleting a Member Device from a Cluster ..................................................................................25-13
Configuring Access Between the Management Device and Its Member Devices..............................25-13
Adding a Candidate Device to a Cluster .............................................................................................25-14
Configuring Advanced Cluster Functions............................................................................................25-15
Configuring Topology Management ............................................................................................25-15
Configuring Interaction for a Cluster............................................................................................25-16
SNMP Configuration Synchronization Function ..........................................................................25-17
Configuring Web User Accounts in Batches ...............................................................................25-18
Displaying and Maintaining Cluster Management ..............................................................................25-19
Cluster Management Configuration Example .....................................................................................25-19
26 IRF Configuration ..................................................................................................................................25-1

IRF Overview ........................................................................................................................................25-1
Introduction....................................................................................................................................25-1
Application and Advantages..........................................................................................................25-1
IRF Working Process ............................................................................................................................25-2
IRF Connections............................................................................................................................25-2
Topology Collection .......................................................................................................................25-7
Role Election .................................................................................................................................25-7
IRF Management...........................................................................................................................25-8
IRF Configuration Task List ................................................................................................................25-11
IRF Configuration ................................................................................................................................25-12
Configuring IRF Ports ..................................................................................................................25-12
Setting a Member ID for a Device ...............................................................................................25-13
Specifying a Priority for an IRF Member .....................................................................................25-14
Specifying the Preservation Time of IRF Bridge MAC Address ..................................................25-14
Enabling Auto Upgrade of Boot Files ..........................................................................................25-15
Setting the Delay Time for the Link Layer to Report a Link-Down Event....................................25-16
Logging In to an IRF............................................................................................................................25-17
Logging In to the Master..............................................................................................................25-17
Logging In to a Slave...................................................................................................................25-17
Displaying and Maintaining IRF ..........................................................................................................25-18
IRF Configuration Examples ...............................................................................................................25-18
IRF Connection Configuration Example ......................................................................................25-18
27 IPC Configuration ..................................................................................................................................27-1

IPC Overview ........................................................................................................................................27-1
ix

Introduction to IPC.........................................................................................................................27-1
Enabling IPC Performance Statistics ....................................................................................................27-2
Displaying and Maintaining IPC ............................................................................................................27-3
28 Automatic Configuration ......................................................................................................................28-1

Introduction to Automatic Configuration................................................................................................28-1
Typical Networking of Automatic Configuration ....................................................................................28-1
How Automatic Configuration Works ....................................................................................................28-2
Work Flow of Automatic Configuration ..........................................................................................28-2
Obtaining the IP Address of an Interface and Related Information Through DHCP .....................28-3
Obtaining the Configuration File from the TFTP Server................................................................28-5
Executing the Configuration File ...................................................................................................28-7

1 Logging In to an Ethernet Switch
When logging in to an Ethernet switch, go to these sections for information you are interested in:
z Logging In to an Ethernet Switch
z Introduction to User Interface
z Specifying Source for Telnet Packets
z Controlling Login Users
Logging In to an Ethernet Switch

You can log in to an switch 4510G in one of the following ways:
z Logging In Through the Console Port
z Logging In Through Telnet/SSH
z User Interface Configuration Examples
z Logging in Through Web-based Network Management System
z Logging In Through NMS
Introduction to User Interface

Supported User Interfaces
Switch 4510G supports two types of user interfaces: AUX and VTY.
z AUX port: Used to manage and monitor users logging in via the console port. The device provides
AUX ports of EIA/TIA-232 DTE type. The port is usually used for the first access to the switch.
z VTY (virtual type terminal): Used to manage and monitor users logging in via VTY. VTY port is
usually used when you access the device by means of Telnet or SSH.
Table 1-1 Description on user interface
User interface Applicable user Port used Description

Users logging in through Each switch can accommodate
AUX Console port
the Console port one AUX user.
Telnet users and SSH Each switch can accommodate
VTY Ethernet port
users up to five VTY users.
As the AUX port and the Console port of a 3Com Switch 4510G family are the same one, you will be in
the AUX user interface if you log in through this port.
1-1

Users and User Interfaces
A device can support one Console ports and multiple Ethernet interfaces, and thus multiple user
interfaces are supported. These user interfaces do not associate with specific users.
z When the user initiates a connection request, based on the login type the system automatically
assigns a type of idle user interface with the smallest number to the user.
z During the login, the configuration in the user interface view takes effect. The user interface varies
depending on the login type and the login time.
At a time, only one user can use the user interface. The user interface configuration applies to the user
that has logged in. For example, if user A uses the console port to log in, the configuration in user
interface view of the console port applies to user A; if user A logs in through VTY 1, the configuration in
user interface view of VTY 1 applies.
User Interface Number
User interfaces can be numbered in two ways: absolute numbering and relative numbering.
Absolute numbering
Absolute numbering allows you to uniquely specify a user interface or a group of user interfaces. The
numbering system starts from number 0 with a step of 1. The numbering approach numbers the two
types of user interfaces in the sequence of AUX port and VTY.
Relative numbering
Relative numbering can specify a user interface or a group of user interfaces of a specific type. The
number is valid only when used under that type of user interface. It makes no sense when used under
other types of user interfaces.
Relative numbering numbers a user interface in the form of user interface type + number. The rules
of relative numbering are as follows:
z AUX user interface number is 0.
z VTYs are numbered from 0 in ascending order, with a step of 1.
Common User Interface Configuration
Follow these steps to perform common user interface configuration:

Optional
Execute this command in user
Lock the current user interface lock view.
A user interface is not locked
by default.
Specify to send messages to Optional

send { all | number | type
all user interfaces/a specified Execute this command in user
number }
user interface view.
Optional
Disconnect a specified user free user-interface [ type ]
interface number Execute this command in user
view.
1-2

Display the information about
You can execute this command
the current user interface/all display users [ all ]
in any view.
user interfaces
Display the physical attributes
and configuration of the display user-interface [ type You can execute this command
current/a specified user number | number ] [ summary ] in any view.
interface
1-3

2 Logging In Through the Console Port
When logging in through the Console port, go to these sections for information you are interested in:
z Introduction
z Setting Up the Connection to the Console Port
z Console Port Login Configuration
z Console Port Login Configuration with Authentication Mode Being None
z Console Port Login Configuration with Authentication Mode Being Password
z Console Port Login Configuration with Authentication Mode Being Scheme
Introduction
To log in through the Console port is the most common way to log in to a switch. It is also the
prerequisite to configure other login methods. By default, you can log in to an 3Com Switch 4510G
family through its Console port only.
To log in to an Ethernet switch through its Console port, the related configuration of the user terminal
must be in accordance with that of the Console port.
Table 2-1 lists the default settings of a Console port.
Table 2-1 The default settings of a Console port
Setting Default
Baud rate 19,200 bps
Flow control Off

Check mode No check bit
Stop bits 1
Data bits 8
After logging in to a switch, you can perform configuration for AUX users. Refer to Console Port Login
Configuration for details.
Setting Up the Connection to the Console Port

z Connect the serial port of your PC/terminal to the Console port of the switch, as shown in Figure
2-1.
Figure 2-1 Diagram for setting the connection to the Console port
2-1

z If you use a PC to connect to the Console port, launch a terminal emulation utility (such as
Terminal in Windows 3.X or HyperTerminal in Windows 9X/Windows 2000/Windows XP) and
perform the configuration shown in Figure 2-2 through Figure 2-4 for the connection to be created.
Normally, the parameters of a terminal are configured as those listed in Table 2-1.
Figure 2-2 Create a connection
Figure 2-3 Specify the port used to establish the connection
2-2

Figure 2-4 Set port parameters terminal window
z Turn on the switch. The user will be prompted to press the Enter key if the switch successfully
completes POST (power-on self test). The prompt (such as <4510G>) appears after the user
presses the Enter key.
The username is admin and none of the password.
z You can then configure the switch or check the information about the switch by executing
commands. You can also acquire help by type the ? character. Refer to the following chapters for
information about the commands.
Console Port Login Configuration

Common Configuration
Table 2-2 lists the common configuration of Console port login.
Table 2-2 Common configuration of Console port login
Configuration Description
Enter AUX user interface view user-interface aux 0
Console (AUX Optional

user Baud rate speed speed-value The default baud rate is 19,200
interface)port bps.
2-3

configuration Optional
parity { even | mark | By default, the check mode of
Check mode the Console port is set to
none | odd | space }
none, which means no check
bit.
Optional
Stop bits stopbits { 1 | 1.5 | 2 } The default stop bits of a
Console port is 1.
Optional
Data bits databits { 5 | 6 | 7 | 8 } The default data bits of a
Console port is 8.
Define a shortcut Optional

escape-key { default |
key for terminating By default, you can use Ctrl+C
character }
tasks. to terminate a task.
Configure the type Optional
of terminal display terminal type { ansi |
under the current vt100 } By default, the terminal display
user interface. type is ANSI.

command level
available to the By default, commands of level
user privilege level level 3 are available to the users
users logging in to
the AUX user logging in to the AUX user
interface interface.
Set the maximum Optional

screen-length
number of lines the By default, the screen can
screen-length
screen can contain contain up to 24 lines.
Optional
Set history
history-command By default, the history
command buffer
max-size value command buffer can contain
size
up to 10 commands.
Set the timeout Optional

idle-timeout minutes
time of a user The default timeout time is 10
[ seconds ]
interface minutes.
Changing of Console port configuration terminates the connection to the Console port. To establish the
connection again, you need to modify the configuration of the termination emulation utility running on
your PC accordingly. Refer to Setting Up the Connection to the Console Port for details.
2-4

Console Port Login Configurations for Different Authentication Modes
Table 2-3 lists Console port login configurations for different authentication modes.
Table 2-3 Console port login configurations for different authentication modes
Authenticati
on mode
Refer to Console Port Login
None Configure not to authenticate users Configuration with Authentication
Mode Being None for details.
Configure to authenticate users using Refer to Console Port Login

Password the local password Configuration with Authentication
Set the local password Mode Being Password for details.
Configure to authenticate users

locally or remotely
Configure the authentication mode Refer to Console Port Login
Scheme Configuration with Authentication
Create or enter a local user, set the Mode Being Scheme for details.
authentication password, specifies
the level and service type for AUX
users
Changes of the authentication mode of Console port login will not take effect unless you exit and enter
again the CLI.
Console Port Login Configuration with Authentication Mode Being

None
Follow these steps to perform Console port login configuration (with authentication mode being none):

Required
Configure not to authenticate By default, users logging in through
authentication-mode none
users the Console port are not
authenticated.
2-5

Assume the switch is configured to allow you to login through Telnet, and your user level is set to the
administrator level (level 3). After you telnet to the switch, you need to limit the console user at the
following aspects.
z The user is not authenticated when logging in through the Console port.
z Commands of level 2 are available to user logging in to the AUX user interface.
z The baud rate of the Console port is 19200 bps.
z The screen can contain up to 30 lines.
z The history command buffer can contain up to 20 commands.
z The timeout time of the AUX user interface is 6 minutes.
Network diagram
Figure 2-5 Network diagram for AUX user interface configuration (with the authentication mode being
none)

# Enter AUX user interface view.

[Sysname] user-interface aux 0
# Specify not to authenticate the user logging in through the Console port.
[Sysname-ui-aux0] authentication-mode none
# Specify commands of level 2 are available to the user logging in to the AUX user interface.
[Sysname-ui-aux0] user privilege level 2
# Set the baud rate of the Console port to 19200 bps.

[Sysname-ui-aux0] speed 19200
# Set the maximum number of lines the screen can contain to 30.
[Sysname-ui-aux0] screen-length 30
# Set the maximum number of commands the history command buffer can store to 20.
[Sysname-ui-aux0] history-command max-size 20
# Set the timeout time of the AUX user interface to 6 minutes.
2-6

[Sysname-ui-aux0] idle-timeout 6
After the above configuration, to ensure a successful login, the console user needs to change the
corresponding configuration of the terminal emulation program running on the PC, to make the
configuration consistent with that on the switch. Refer to Setting Up the Connection to the Console
Port for details.

Password
Follow these steps to perform Console port login configuration (with authentication mode being
password):

Enter AUX user interface

user-interface aux 0
view
Required
Configure to authenticate By default, users logging in through the
authentication-mode Console port are not authenticated,
users using the local
password while users logging in through the Telnet
password
need to pass the password
authentication.
set authentication Required
Set the local password password { cipher |
simple } password By default,no password is configured.
administrator level (level 3). After you telnet to the switch, you need to limit the Console user at the
following aspects.
z The user is authenticated against the local password when logging in through the Console port.
z The local password is set to 123456 (in plain text).
z The commands of level 2 are available to users logging in to the AUX user interface.
z The baud rate of the Console port is 19,200 bps.
z The history command buffer can store up to 20 commands.
2-7

Network diagram
password)


# Specify to authenticate the user logging in through the Console port using the local password.
[Sysname-ui-aux0] authentication-mode password
# Set the local password to 123456 (in plain text).

[Sysname-ui-aux0] set authentication password simple 123456
# Specify commands of level 2 are available to the user logging in to the AUX user interface.
[Sysname-ui-aux0] user privilege level 2


After the above configuration, to ensure a successful login, the console user needs to change the
corresponding configuration of the terminal emulation program running on the PC, to make the
configuration consistent with that on the switch. Refer to Setting Up the Connection to the Console
Port for details.
2-8

Scheme
Follow these steps to perform Console port login configuration (with authentication mode being
scheme):

Enter AUX user interface

user-interface aux 0
view
Required
The specified AAA scheme
determines whether to
Configure to
authenticate users locally or
authenticate users authentication-mode scheme
remotely.
locally or remotely
By default, users logging in
through the Console port are not
authenticated
Enter the Optional

default ISP By default, the local AAA scheme
domain domain name
domain is applied. If you specify to apply
view the local AAA scheme, you need
to perform the configuration
concerning local user as well.
Specify the
authentication default If you specify to apply an existing
AAA
{ hwtacacs- scheme scheme by providing the
Configure scheme to
hwtacacs-scheme-name [ local ] | radius-scheme-name argument,
the be applied
local | none | radius-scheme you need to perform the following
authentica to the
radius-scheme-name [ local ] } configuration as well:
tion mode domain
z Perform AAA-RADIUS
configuration on the switch.
(Refer to AAA Configuration in
the Security Volume for
Quit to details.)
system quit z Configure the user name and
view password accordingly on the
AAA server. (Refer to the user
manual of AAA server.)
Create a local user Required
local-user user-name
(Enter local user view.) No local user exists by default.
Set the authentication Required

password { simple | cipher }
password for the local By default, a user is authorized
password
user with no password
By default, no authorization
Specifies the level of the
authorization-attribute level level attribute is configured for a local
local user
user
Required
Specify the service type
service-type terminal By default, a user is authorized
for AUX users
with no service
2-9

Note that, when you log in to an Ethernet switch using the scheme authentication mode, your access
rights depend on your user level defined in the AAA scheme.
When the local authentication mode is used, the user levels are specified using the
authorization-attribute level level command.
When the RADIUS or HWTACACS authentication mode is used, the user levels are set on the
corresponding RADIUS or HWTACACS servers.
For more information about AAA, RADIUS, and HWTACACS, see AAA Configuration in the Security
Volume.
administrator level (level 3). After you telnet to the switch, you need to limit the console user at the
following aspects.
z Configure the name of the local user to be guest.
z Set the authentication password of the local user to 123456 (in plain text).
z Set the service type of the local user to Terminal.
z Configure to authenticate the user logging in through the Console port in the scheme mode.
z The baud rate of the Console port is 19,200 bps.
scheme)
GE1/0/1
Ethernet
Telnet client

2-10

# Create a local user named guest and enter local user view.
[Sysname] local-user guest
# Set the authentication password to 123456 (in plain text).

[Sysname-luser-guest] password simple 123456
# Set the service type to Terminal.

[Sysname-luser-guest] service-type terminal
[Sysname-luser-guest] quit

# Configure to authenticate the user logging in through the Console port in the scheme mode.
[Sysname-ui-aux0] authentication-mode scheme


2) Configure the authentication scheme

Configure the authentication server by referring to related parts in AAA Configuration.
After the above configurations, you need to modify the configurations of the terminal emulation utility
running on the user PC accordingly, as shown in Figure 2-4, thus ensuring the consistency between
the configurations of the terminal emulation utility and those of the switch. Otherwise, you will fail to log
in to the switch.
Configuring Command Authorization

By default, command level for a login user depends on the user level. The user is authorized the
command with the default level not higher than the user level. With the command authorization
configured, the command level for a login user is decided by both the user level and AAA authorization.
If a user executes a command of the corresponding user level, the authorization server checks
whether the command is authorized. If yes, the command can be executed.
The authorization server checks the commands authorized for users through the username, and thus
the command authorization configuration involves three steps:
1) Configure to use username and password authentication when users log in.
2) Enable command authorization. See the following table for details.
3) Configure an authorization scheme. Specify the IP address and other related parameters for the
accounting server. For details, refer to the AAA Configuration in the Security Volume.
Follow these steps to enable command authorization:

2-11

Required
Enable command authorization command authorization Disabled by default, that is,
users can execute commands
without authorization.
Configuring Command Accounting

Command accounting allows the HWTACACS server to record all commands executed on the device
regardless of the command execution result. This helps control and monitor the user operations on the
device.
If command accounting is enabled and command authorization is not enabled, every executed
command will be recorded on the HWTACACS server. If both command accounting and command
authorization are enabled, only the authorized and executed commands will be recorded on the
HWTACACS server.
The command accounting configuration involves two steps:
1) Enable command accounting. See the following table for details.
2) Configure a command accounting scheme. Specify the IP address and other related parameters
for the accounting server. For details, refer to the AAA Configuration in the Security Volume.
Follow these steps to enable command accounting:

Required
Disabled by default, that is, the
Enable command accounting command accounting accounting server does not
record the commands the
users execute.
2-12

3 Logging In Through Telnet/SSH
Logging In Through Telnet

When logging in through Telnet, go to these sections for information you are interested in:
z Introduction
z Common Configuration
z Telnet Login Configuration with Authentication Mode Being None
z Telnet Login Configuration with Authentication Mode Being Password
z Telnet Login Configuration with Authentication Mode Being Scheme
Introduction
You can telnet to a remote switch to manage and maintain the switch. To achieve this, you need to
configure both the switch and the Telnet terminal properly.
Table 3-1 Requirements for Telnet to a switch
Item Requirement
Start the Telnet Server
The IP address of the VLAN of the switch is configured and the route
Switch between the switch and the Telnet terminal is available.
The authentication mode and other settings are configured. Refer to
Table 3-2 and Table 3-3.
Telnet is running.
Telnet terminal
The IP address of the management VLAN of the switch is available.
Telnet Connection Establishment
Telnetting to a Switch from a Terminal
You can telnet to a switch and then configure the switch if the interface of the management VLAN of
the switch is assigned with an IP address. (By default, VLAN 1 is the management VLAN.)
Following are procedures to establish a Telnet connection to a switch:
Step 1: Log in to the switch through the Console port, enable the Telnet server function and assign an
IP address to the management VLAN interface of the switch.
z Connect to the Console port. Refer to Setting Up the Connection to the Console Port.
z Execute the following commands in the terminal window to enable the Telnet server function and
assign an IP address to the management VLAN interface of the switch.
# Enable the Telnet server function and configure the IP address of the management VLAN interface
as 202.38.160.92, and .the subnet mask as 255.255.255.0.
3-1

[Sysname] telnet server enable
[Sysname-Vlan-interface1] ip address 202.38.160.92 255.255.255.0
Step 2: Before Telnet users can log in to the switch, corresponding configurations should have been
performed on the switch according to different authentication modes for them. Refer to Telnet Login
Configuration with Authentication Mode Being None, Telnet Login Configuration with Authentication
Mode Being Password, and Telnet Login Configuration with Authentication Mode Being Scheme for
details. By default, Telnet users need to pass the password authentication to login.
Step 3: Connect your PC to the Switch, as shown in Figure 3-1. Make sure the Ethernet port to which
your PC is connected belongs to the management VLAN of the switch and the route between your PC
and the switch is available.
Figure 3-1 Network diagram for Telnet connection establishment
Workstation
Ethernet port
Ethernet
Server Workstation Configuration PC

running Telnet
Step 4: Launch Telnet on your PC, with the IP address of the management VLAN interface of the
switch as the parameter, as shown in the following figure.
Figure 3-2 Launch Telnet
Step 5: Enter the password when the Telnet window displays Login authentication and prompts for
login password. The CLI prompt (such as <4510G>) appears if the password is correct. If all VTY user
interfaces of the switch are in use, you will fail to establish the connection and receive the message
that says All user interfaces are used, please try later!. A switch 4510G can accommodate up to five
Telnet connections at same time.
Step 6: After successfully Telnetting to a switch, you can configure the switch or display the information
about the switch by executing corresponding commands. You can also type ? at any time for help.
Refer to the following chapters for the information about the commands.
3-2

z A Telnet connection will be terminated if you delete or modify the IP address of the VLAN interface
in the Telnet session.
z By default, commands of level 0 are available to Telnet users authenticated by password. Refer to
Basic System Configuration in the System Volume for information about command hierarchy.
Telnetting to Another Switch from the Current Switch
You can Telnet to another switch from the current switch. In this case, the current switch operates as
the client, and the other operates as the server. If the interconnected Ethernet ports of the two switches
are in the same LAN segment, make sure the IP addresses of the two management VLAN interfaces
to which the two Ethernet ports belong to are of the same network segment, or the route between the
two VLAN interfaces is available.
As shown in Figure 3-3, after Telnetting to a switch (labeled as Telnet client), you can Telnet to another
switch (labeled as Telnet server) by executing the telnet command and then to configure the later.
Figure 3-3 Network diagram for Telnetting to another switch from the current switch
Step 1: Configure the user name and password for Telnet on the switch operating as the Telnet server.
Refer to section Telnet Login Configuration with Authentication Mode Being None, section Telnet
Login Configuration with Authentication Mode Being Password, and Telnet Login Configuration with
Authentication Mode Being Scheme for details. By default, Telnet users need to pass the password
authentication to login.
Step 2: Telnet to the switch operating as the Telnet client.
Step 3: Execute the following command on the switch operating as the Telnet client:
<Sysname> telnet xxxx
Where xxxx is the IP address or the host name of the switch operating as the Telnet server. You can
use the ip host to assign a host name to a switch.
Step 4: Enter the password. If the password is correct, the CLI prompt (such as <4510G>) appears. If
all VTY user interfaces of the switch are in use, you will fail to establish the connection and receive the
message that says All user interfaces are used, please try later!.
Step 5: After successfully Telnetting to the switch, you can configure the switch or display the
information about the switch by executing corresponding commands. You can also type ? at any time
for help. Refer to the following chapters for the information about the commands.
Common Configuration
Table 3-2 lists the common Telnet configuration.
3-3

Table 3-2 Common Telnet configuration
Configuration Remarks
By default, a switch does

Make the switch to operate as a Telnet
telnet server enable not operate as a Telnet
Server
server
user-interface vty
Enter one or more VTY user interface
first-number
views
[ last-number ]
Optional
Make terminal By default, terminal
shell
services available services are available in all
user interfaces
Set the command that Optional

is automatically By default, no command is
auto-execute command
executed when a user automatically executed
text
logs into the user when a user logs into a
interface user interface.

protocol inbound { all |
protocols the user By default, Telnet and SSH
ssh | telnet }
interface supports protocol are supported.
Optional
Define a shortcut key escape-key { default |
for terminating tasks. character } By default, you can use
Ctrl+C to terminate a task.
Configure the type of Optional
VTY user terminal display under
terminal type { ansi | vt100 } By default, the terminal
interface the current user
configuration interface. display type is ANSI.

command level By default, commands of
available to users user privilege level level level 0 are available to
logging in to the VTY users logging in to a VTY
user interface user interface.
Set the maximum Optional

screen-length
number of lines the By default, the screen can
screen-length
screen can contain contain up to 24 lines.
Optional
Set history command history-command By default, the history
buffer size max-size value command buffer can
contain up to 10
commands.
Optional
Set the timeout time of idle-timeout minutes
a user interface [ seconds ] The default timeout time is
10 minutes.
Telnet Login Configuration Task List
Telnet login configurations vary when different authentication modes are adopted.
3-4

Table 3-3 Telnet login configuration tasks when different authentication modes are adopted
Task Description
Telnet Login Configuration with Authentication Configure not to authenticate users logging in user
Mode Being None interfaces
Configure to authenticate users logging in to user
Telnet Login Configuration with Authentication
interfaces using a local password and configure
Mode Being Password
the local password
z Configure to authenticate users using the

scheme authentication mode;
Telnet Login Configuration with Authentication z Set the authentication scheme, which can be
Mode Being Scheme local authentication or remote server
authentication;
z Configure the authentication usernames and
passwords for local users.
Telnet Login Configuration with Authentication Mode Being None
Follow these steps to perform Telnet configuration (with authentication mode being none):

Enter one or more VTY user user-interface vty

interface views first-number [ last-number ]
Configure not to authenticate Required

users logging in to VTY user authentication-mode none By default, VTY users are
interfaces authenticated after logging in.
Note that if you configure not to authenticate the users, the command level available to users logging
in to a switch depends on both the authentication-mode none command and the user privilege
level level command.
Assume that you are a level 3 AUX user and want to perform the following configuration for Telnet
users logging in to VTY 0:
z Do not authenticate users logging in to VTY 0.
z Commands of level 2 are available to users logging in to VTY 0.
z Telnet protocol is supported.
z The timeout time of VTY 0 is 6 minutes.
2) Network diagram
3-5

Figure 3-4 Network diagram for Telnet configuration (with the authentication mode being none)
# Enter system view, and enable the Telnet service.
# Enter VTY 0 user interface view.

[Sysname] user-interface vty 0
# Configure not to authenticate Telnet users logging in to VTY 0.

[Sysname-ui-vty0] authentication-mode none
# Specify commands of level 2 are available to users logging in to VTY 0.

[Sysname-ui-vty0] user privilege level 2
# Configure Telnet protocol is supported.

[Sysname-ui-vty0] protocol inbound telnet
[Sysname-ui-vty0] screen-length 30
[Sysname-ui-vty0] history-command max-size 20
# Set the timeout time to 6 minutes.

[Sysname-ui-vty0] idle-timeout 6
Telnet Login Configuration with Authentication Mode Being Password
Follow these steps to perform Telnet configuration (with authentication mode being password):

Enter one or more VTY user user-interface vty

interface views first-number [ last-number ]
Configure to authenticate users
logging in to VTY user authentication-mode
Required
interfaces using the local password
password
set authentication password
Set the local password Required
{ cipher | simple } password
Note that if you configure to authenticate the users in the password mode, the command level
available to users logging in to a switch depends on both the authentication-mode password
command and the user privilege level level command.
3-6

z Authenticate users logging in to VTY 0 using the local password.
z Set the local password to 123456 (in plain text).
z Commands of level 2 are available to users logging in to VTY 0.
z Telnet protocol is supported.
2) Network diagram
Figure 3-5 Network diagram for Telnet configuration (with the authentication mode being password)

# Configure to authenticate users logging in to VTY 0 using the local password.

[Sysname-ui-vty0] authentication-mode password
# Set the local password to 123456 (in plain text).

[Sysname-ui-vty0] set authentication password simple 123456
# Specify commands of level 2 are available to users logging in to VTY 0.

[Sysname-ui-vty0] user privilege level 2


3-7

Telnet Login Configuration with Authentication Mode Being Scheme
Follow these steps to perform Telnet configuration (with authentication mode being scheme):

Enter one or more VTY user-interface vty

user interface views first-number [ last-number ]
Required
The specified AAA scheme
Configure to authenticate authentication-mode determines whether to authenticate
users locally or remotely scheme users locally or remotely.
Users are authenticated locally by
default.
Enter the Optional
default ISP domain domain name By default, the local AAA scheme is
domain view applied. If you specify to apply the
authentication default local AAA scheme, you need to
Configure perform the configuration concerning
{ hwtacacs-scheme
the AAA local user as well.
hwtacacs-schemename
scheme to
[ local ] | local | none | If you specify to apply an existing
be applied
Configure radius-scheme scheme by providing the
to the
the radius-scheme-name radius-scheme-name argument, you
domain
authenticati [ local ] } need to perform the following
on scheme configuration as well:
z Perform AAA-RADIUS
configuration on the switch. (Refer
to AAA Configuration in the
Quit to Security Volume for details.)
quit
system view
z Configure the user name and
password accordingly on the AAA
server. (Refer to the user manual
of AAA server.)
Create a local user and
local-user user-name No local user exists by default.
enter local user view
Required
Set the authentication password { simple |
password for the local user cipher } password By default, a user is authorized with
no password
Specifies the level of the authorization-attribute By default, no authorization attribute
local user level level is configured for a local user
Required
Specify the service type for
service-type telnet By default, a user is authorized with
AUX users
no service
Note that, when you log in to an Ethernet switch using the scheme authentication mode, your access
rights depend on your user level defined in the AAA scheme.
When the local authentication mode is used, the user levels are specified using the
authorization-attribute level level command.
When the RADIUS or HWTACACS authentication mode is used, the user levels are set on the
corresponding RADIUS or HWTACACS servers.
3-8

For more information about AAA, RADIUS, and HWTACACS, see AAA Configuration in the Security
Volume.
z Configure the name of the local user to be guest.
z Set the authentication password of the local user to 123456 (in plain text).
z Set the service type of VTY users to Telnet.
z Configure to authenticate users logging in to VTY 0 in scheme mode.
z The commands of level 2 are available to users logging in to VTY 0.
z Telnet protocol is supported in VTY 0.
2) Network diagram
Figure 3-6 Network diagram for Telnet configuration (with the authentication mode being scheme)
z Configure the switch
# Create a local user named guest and enter local user view.
[Sysname] local-user guest
# Set the authentication password of the local user to 123456 (in plain text).
[Sysname-luser-guest] password simple 123456
# Set the service type to Telnet.

[Sysname-luser-guest] service-type

# Configure to authenticate users logging in to VTY 0 in the scheme mode.

[Sysname-ui-vty0] authentication-mode scheme
3-9


z Configure the authentication scheme
Configure the authentication server by referring to related parts in AAA Configuration.
Logging In Through SSH

Secure Shell (SSH) offers an approach to logging into a remote device securely. With encryption and
strong authentication, it protects devices against attacks such as IP spoofing and plain text password
interception. For the security features provided by SSH, see SSH Configuration in the Security
Volume.
Configuring Command Authorization

By default, command level for a login user depends on the user level. The user is authorized the
command with the default level not higher than the user level. With the command authorization
configured, the command level for a login user is decided by both the user level and AAA authorization.
If a user executes a command of the corresponding user level, the authorization server checks
whether the command is authorized. If yes, the command can be executed.
The authorization server checks the commands authorized for users through the username, and thus
the command authorization configuration involves three steps:
1) Configure to use username and password authentication when users log in.
2) Enable command authorization. See the following table for details.
3) Configure an authorization scheme. Specify the IP address and other related parameters for the
accounting server. For details, refer to the AAA Configuration in the Security Volume.
Follow these steps to enable command authorization:

user-interface vty
Enter AUX user interface view
first-number [ last-number ]
Required
Enable command authorization command authorization Disabled by default, that is,
users can execute commands
without authorization.
3-10

Configuring Command Accounting
Command accounting allows the HWTACACS server to record all commands executed on the device
regardless of the command execution result. This helps control and monitor the user operations on the
device.
If command accounting is enabled and command authorization is not enabled, every executed
command will be recorded on the HWTACACS server. If both command accounting and command
authorization are enabled, only the authorized and executed commands will be recorded on the
HWTACACS server.
The command accounting configuration involves two steps:
1) Enable command accounting. See the following table for details.
2) Configure a command accounting scheme. Specify the IP address and other related parameters
for the accounting server. For details, refer to the AAA Configuration in the Security Volume.
Follow these steps to enable command accounting:

user-interface vty
Enter AUX user interface view
Required
Disabled by default, that is, the
Enable command accounting command accounting accounting server does not
record the commands the
users execute.
3-11

4 User Interface Configuration Examples
User Authentication Configuration Example

Network diagram
As shown in Figure 4-1, command levels should be configured for different users to secure Device:
z The device administrator accesses Device through the console port on Host A. When the
administrator logs in to the device, username and password are not required.
z Users access Device through an Ethernet interface on Host B. When a user logs in to Device,
both username and password are required. Only the authenticated users can log in and perform
configurations. RADIUS authentication is of higher priority, and local authentication is used when
the RADIUS server or the link fails. The local username is monitor and password is 123.
Figure 4-1 Network diagram for configuring user authentication
# Assign an IP address to Device to make Device be reachable from Host A, Host B, Host C, and
RADIUS server. The configuration is omitted.
# Enable telnet services on Device.
[Device] telnet server enable
# Set that no authentication is needed when users use the console port to log in to Device. Set the
privilege level of the administrator logging in from the console port to 3, that is, the administrator can
execute all the device commands.
[Device] user-interface aux 0
[Device-ui-aux0] authentication-mode none
[Device-ui-aux0] user privilege level 3
[Device-ui-aux0] quit
# Set to use username and password authentication when users use VTY interface to log in to Device
from Host B. The command level that a login user on VTY can access depends on the user
configuration on the AAA server.
[Device] user-interface vty 0 4
[Device-ui-vty0-4] authentication-mode scheme
4-1

[Device-ui-vty0-4] quit
# Create a RADIUS scheme and configure the IP address and UDP port for the primary authentication
server for the scheme. Ensure that the port number be consistent with that on the RADIUS server. Set
the shared key for authentication packets to expert for the scheme and the RADIUS server type of the
scheme to extended. Specify Device to remove the domain name in the username sent to the
RADIUS server for the RADIUS scheme.
[Device] radius scheme rad
[Device-radius-rad] primary authentication 192.168.2.20 1812
[Device-radius-rad] key authentication expert
[Device-radius-rad] server-type extended
[Device-radius-rad] user-name-format without-domain
[Device-radius-rad] quit
# Configure the default ISP domain system to use RADIUS authentication scheme rad for login users
and use local authentication as the backup.
[Device-isp-system] authentication login radius-scheme rad local
[Device-isp-system] authorization login radius-scheme rad local
# Add a local user named monitor, set the user password to 123, and specify to display the password
in cipher text. Authorize user monitor to use the telnet service and specify the level of the user as 1,
that is, the monitor level.
[Device] local-user monitor
[Device-luser-admin] password cipher 123
[Device-luser-admin] service-type telnet
[Device-luser-admin] authorization-attribute level 1
Command Authorization Configuration Example

Network diagram
As shown in Figure 4-2, command levels should be configured for different users to secure Device:
After a user logs in to Device, the commands the user enter must be authorized by the HWTACACS
server first before being executed. If the HWTACACS server fails to authorize the commands, local
authorization is used.
Figure 4-2 Network diagram for configuring command authorization
4-2

# Assign an IP address to Device to make Device be reachable from Host A and HWTACACS server
respectively. The configuration is omitted.
# Enable the telnet service on Device.
# Set to use username and password authentication when users use VTY 0 to log in to Device. The
command that the user can execute depends on the authentication result.
[Device-ui-vty0-4] authentication-mode scheme
# Enable command authorization to restrict the command level for login users.
[Device-ui-vty0-4] command authorization
# Create a HWTACACS scheme named tac and configure the IP address and TCP port for the primary
authorization server for the scheme. Ensure that the port number be consistent with that on the
HWTACACS server. Set the shared key for authentication packets to expert for the scheme and the
HWTACACS server type of the scheme to standard. Specify Device to remove the domain name in
the username sent to the HWTACACS server for the scheme.
[Device] hwtacacs scheme tac
[Device-hwtacacs-tac] primary authentication 192.168.2.20 49
[Device-hwtacacs-tac] primary authorization 192.168.2.20 49
[Device-hwtacacs-tac] key authentication expert
[Device-hwtacacs-tac] key authorization expert
[Device-hwtacacs-tac] server-type standard
[Device-hwtacacs-tac] user-name-format without-domain
[Device-hwtacacs-tac] quit
# Configure the default ISP domain system to use HWTACACS scheme tac for login users and use
local authorization as the backup.
[Device-isp-system] authentication login hwtacacs-scheme tac local
[Device-isp-system] authorization command hwtacacs-scheme tac local
# Add a local user named monitor, set the user password to 123, and specify to display the password
in cipher text. Authorize user monitor to use the telnet service and specify the level of the user as 1,
that is, the monitor level.
[Device] local-user monitor
[Device-luser-admin] password cipher 123
[Device-luser-admin] service-type telnet
[Device-luser-admin] authorization-attribute level 1
4-3

Command Accounting Configuration Example
Network diagram
As shown in Figure 4-3, configure the commands that the login users execute to be recorded on the
HWTACACS server to control and monitor user operations.
Figure 4-3 Network diagram for configuring command accounting
HWTACAS server
192.168.2.20/24
Console Connection
Internet
Device
Host A Host C
10.10.10.10/24
Intranet
Host B
192.168.1.20/24
# Enable the telnet service on Device.

# Enable command accounting for users logging in through the console port.
[Device] user-interface aux 0
[Device-ui-aux0] command accounting
[Device-ui-aux0] quit
# Enable command accounting for users logging in through telnet or SSH.

[Device-ui-vty0-4] command accounting
# Create a HWTACACS scheme named tac and configure the IP address and TCP port for the primary
authorization server for the scheme. Ensure that the port number be consistent with that on the
HWTACACS server. Set the shared key for authentication packets to expert for the scheme. Specify
Device to remove the domain name in the username sent to the HWTACACS server for the scheme.
[Device] hwtacacs scheme tac
[Device-hwtacacs-tac] primary accounting 192.168.2.20 49
[Device-radius-rad] key accounting expert
[Device-radius-rad] user-name-format without-domain
4-4

[Device-radius-rad] quit
# Create ISP domain system, and configure the ISP domain system to use HWTACACS scheme tac
for accounting of command line users
[Device-isp-system] accounting command hwtacacs-scheme tac
4-5

5 Logging in Through Web-based Network
Management System
Introduction
An switch 4510G has a built-in Web server. You can log in to an switch 4510G through a Web browser
and manage and maintain the switch intuitively by interacting with the built-in Web server.
To log in to an switch 4510G through the built-in Web-based network management system, you need
to perform the related configuration on both the switch and the PC operating as the network
management terminal.
Table 5-1 Requirements for logging in to a switch through the Web-based network management
system
Item Requirement
Start the Web server
The IP address of the management VLAN of the switch is configured.

The route between the switch and the network management terminal
Switch is available. (Refer to the module IP Addressing and Performance
and IP Routing for more.)
The user name and password for logging in to the Web-based
network management system are configured.
PC operating as the IE is available.

network management The IP address of the management VLAN interface of the switch is
terminal available.
Web Server Configuration

Logging in Through Web-based Network Management configuration

Enter system view system-view -
Required
Start the Web server ip http enable Execute this command in
system view.
Add a local user and enter local Required

user view No local user exists by default.
Configure a password for the password { cipher | simple } Required

local user password No password exists by default.
5-1

Optional
Configure the authorization authorization-attribute level By default, no authorization
attributes for the local user level attribute is configured for a
local user.
Optional
Specify the service types for
service-type telnet By default, no service is
the local user
authorized to a user.
Displaying Web Users

After the above configurations, execute the display command in any view to display the information
about Web users, and thus to verify the configuration effect.
Table 5-2 Display information about Web users
To do Use the command

Display information about Web users display web users
Step 1: Log in to the switch through the console port and assign an IP address to the management
VLAN interface of the switch. By default, VLAN 1 is the management VLAN.
z Connect to the console port. Refer to section Setting Up the Connection to the Console Port.
z Execute the following commands in the terminal window to assign an IP address to the
management VLAN interface of the switch.
# Configure the IP address of the management VLAN interface to be 10.153.17.82 with the mask
255.255.255.0.
Step 2: Configure the user name and the password for the Web-based network management system.
# Configure the user name to be admin.
[Sysname] local-user admin
# Set the password to admin.

[Sysname-luser-admin] password simple admin
Step 3: Establish an HTTP connection between your PC and the switch, as shown in the following
figure.
Figure 5-1 Establish an HTTP connection between your PC and the switch
5-2

Step 4: Log in to the switch through IE. Launch IE on the Web-based network management terminal
(your PC) and enter the IP address of the management VLAN interface of the switch (here it is
http://10.153.17.82). (Make sure the route between the Web-based network management terminal and
the switch is available.)
Step 5: When the login interface (shown in Figure 5-2) appears, enter the user name and the password
configured in step 2 and click <Login> to bring up the main page of the Web-based network
management system.
Figure 5-2 The login page of the Web-based network management system
5-3

6 Logging In Through NMS
When logging in through NMS, go to these sections for information you are interested in:
z Introduction
z Connection Establishment Using NMS
Introduction
You can also log in to a switch through an NMS (network management station), and then configure and
manage the switch through the agent module on the switch.
z The agent here refers to the software running on network devices (switches) and as the server.
z SNMP (simple network management protocol) is applied between the NMS and the agent.
To log in to a switch through an NMS, you need to perform related configuration on both the NMS and
the switch.
Table 6-1 Requirements for logging in to a switch through an NMS
Item Requirement
The IP address of the management VLAN of the switch is configured. The
route between the NMS and the switch is available.
Switch
The basic SNMP functions are configured. (Refer to SNMP Configuration in
the System Volume for details.)
The NMS is properly configured. (Refer to the user manual of the NMS for
NMS
details.)
Connection Establishment Using NMS

Figure 6-1 Network diagram for logging in through an NMS
Switch
Network
NMS
6-1

7 Specifying Source for Telnet Packets
When specifying source IP address/interface for Telnet packets, go to these sections for information
you are interested in:
z Introduction
z Specifying Source IP address/Interface for Telnet Packets
z Displaying the source IP address/Interface Specified for Telnet Packets
Introduction
To improve security and make it easier to manage services, you can specify source IP
addresses/interfaces for Telnet clients.
Usually, VLAN interface IP addresses and Loopback interface IP addresses are used as the source IP
addresses of Telnet packets. After you specify the IP address of a VLAN interface or a Loopback
interface as the source IP address of Telnet packets, all the packets exchanged between the Telnet
client and the Telnet server use the IP address as their source IP addresses, regardless of the ports
through which they are transmitted. In such a way, the actual IP addresses used are concealed. This
helps to improve security. Specifying source IP address/interfaces for Telnet packets also provides a
way to successfully connect to servers that only accept packets with specific source IP addresses.
Specifying Source IP address/Interface for Telnet Packets

The configuration can be performed in user view and system view. The configuration performed in user
view only applies to the current session. Whereas the configuration performed in system view applies
to all the subsequent sessions. Priority in user view is higher than that in system view.
Specifying source IP address/interface for Telnet packets in user view
Follow these steps to specify source IP address/interface for Telnet packets in user view:

telnet remote-system
Specify source IP Optional
[ port-number ] [ source { ip
address/interface for Telnet
ip-address | interface By default, no source IP
packets (the switch operates
interface-type address/interface is specified.
as a Telnet client)
interface-number } ]
Specifying source IP address/interface for Telnet packets in system view
Follow these steps to specify source IP address/interface for Telnet packets in system view:

7-1

telnet client source { ip Optional
Specify source IP
ip-address | interface
address/interface for Telnet By default, no source IP
interface-type
packets address/interface is specified.
interface-number }
z The IP address specified must be a local IP address.

z When specifying the source interface for Telnet packets, make sure the interface already exists.
z Before specifying the source IP address/interface for Telnet packets, make sure the route
between the interface and the Telnet server is reachable.
Displaying the source IP address/Interface Specified for Telnet

Packets
Follow these steps to display the source IP address/interface specified for Telnet packets:

Display the source IP
address/interface specified for display telnet client configuration Available in any view
Telnet packets
7-2

8 Controlling Login Users
When controlling login users, go to these sections for information you are interested in:
z Introduction
z Controlling Telnet Users
z Controlling Network Management Users by Source IP Addresses
Introduction
Multiple ways are available for controlling different types of login users, as listed in Table 8-1.
Table 8-1 Ways to control different types of login users
Login mode Control method Implementation Related section

Through basic Controlling Telnet Users by
By source IP addresses
ACLs Source IP Addresses
Controlling Telnet Users by
By source and destination Through advanced
Telnet Source and Destination IP
IP addresses ACLs
Addresses
By source MAC Through Layer 2 Controlling Telnet Users by

addresses ACLs Source MAC Addresses
Controlling Network
Through basic
SNMP By source IP addresses Management Users by Source
ACLs
IP Addresses
Controlling Telnet Users

Prerequisites
The controlling policy against Telnet users is determined, including the source and destination IP
addresses to be controlled and the controlling actions (permitting or denying).
Controlling Telnet Users by Source IP Addresses
This configuration needs to be implemented by basic ACL; a basic ACL ranges from 2000 to 2999. For
the definition of ACL, refer to ACL Configuration in the Security Volume.
Follow these steps to control Telnet users by source IP addresses:

acl [ ipv6 ] number acl-number As for the acl number

Create a basic ACL or enter
[ match-order { config | command, the config keyword
basic ACL view
auto } ] is specified by default.
8-1

rule [ rule-id ] { permit | deny }
[ source { sour-addr
Define rules for the ACL sour-wildcard | any } | Required
time-range time-name |
fragment | logging ]*
user-interface [ type ]
Enter user interface view
Required
The inbound keyword
specifies to filter the users
trying to Telnet to the current
Apply the ACL to control Telnet acl [ ipv6 ] acl-number
switch.
users by source IP addresses { inbound | outbound }
The outbound keyword
specifies to filter users trying to
Telnet to other switches from
the current switch.
Controlling Telnet Users by Source and Destination IP Addresses
This configuration needs to be implemented by advanced ACL; an advanced ACL ranges from 3000 to
3999. For the definition of ACL, refer to ACL Configuration in the Security Volume.
Follow these steps to control Telnet users by source and destination IP addresses:

acl [ ipv6 ] number acl-number As for the acl number

Create an advanced ACL or
enter advanced ACL view
Required
rule [ rule-id ] { permit | deny } You can define rules as
Define rules for the ACL needed to filter by specific
rule-string
source and destination IP
addresses.
Required
The inbound keyword
specifies to filter the users
Apply the ACL to control Telnet trying to Telnet to the current
acl [ ipv6 ] acl-number
users by specified source and switch.
{ inbound | outbound }
destination IP addresses The outbound keyword
specifies to filter users trying to
Telnet to other switches from
the current switch.
8-2

Controlling Telnet Users by Source MAC Addresses
This configuration needs to be implemented by Layer 2 ACL; a Layer 2 ACL ranges from 4000 to 4999.
For the definition of ACL, refer to ACL Configuration in the Security Volume.
Follow these steps to control Telnet users by source MAC addresses:

acl number acl-number As for the acl number
Create a basic ACL or enter
basic ACL view
Required
rule [ rule-id ] { permit | deny } You can define rules as
Define rules for the ACL
rule-string needed to filter by specific
source MAC addresses.
Required
Apply the ACL to control Telnet The inbound keyword
users by source MAC acl acl-number inbound specifies to filter the users
addresses trying to Telnet to the current
switch.
Layer 2 ACL is invalid for this function if the source IP address of the Telnet client and the interface IP
address of the Telnet server are not in the same subnet.
Only the Telnet users sourced from the IP address of 10.110.100.52 and 10.110.100.46 are permitted
to log in to the switch.
Figure 8-1 Network diagram for controlling Telnet users using ACLs
10.110.100.46
Host A
IP network
Switch
Host B
10.110.100.52
8-3

# Define a basic ACL.

[Sysname] acl number 2000 match-order config
[Sysname-acl-basic-2000] rule 1 permit source 10.110.100.52 0
[Sysname-acl-basic-2000] rule 3 deny source any
# Apply the ACL.

[Sysname] user-interface vty 0 4
[Sysname-ui-vty0-4] acl 2000 inbound
Controlling Network Management Users by Source IP Addresses

You can manage a 3Com Switch 4510G family through network management software. Network
management users can access switches through SNMP.
You need to perform the following two operations to control network management users by source IP
addresses.
z Defining an ACL
z Applying the ACL to control users accessing the switch through SNMP
Prerequisites
The controlling policy against network management users is determined, including the source IP
addresses to be controlled and the controlling actions (permitting or denying).
Controlling Network Management Users by Source IP Addresses
Follow these steps to control network management users by source IP addresses:

As for the acl

number
Create a basic ACL or acl [ ipv6 ] number acl-number [ match-order command, the
enter basic ACL view { config | auto } ] config keyword
is specified by
default.
rule [ rule-id ] { permit | deny } [ source
Define rules for the ACL { sour-addr sour-wildcard | any } | time-range Required
time-name | fragment | logging ]*
Apply the ACL while snmp-agent community { read | write } Required

configuring the SNMP community-name [ mib-view view-name | acl According to the
community name acl-number ]* SNMP version
8-4

snmp-agent group { v1 | v2c } group-name and
[ read-view read-view ] [ write-view write-view ] configuration
[ notify-view notify-view ] [ acl acl-number ] customs of NMS
Apply the ACL while
users, you can
configuring the SNMP snmp-agent group v3 group-name reference an
group name [ authentication | privacy ] [ read-view ACL when
read-view ] [ write-view write-view ] [ notify-view configuring
notify-view ] [ acl acl-number ] community
name, group
snmp-agent usm-user { v1 | v2c } user-name name or
group-name [ acl acl-number ] username. For
Apply the ACL while snmp-agent usm-user v3 user-name the detailed
configuring the SNMP group-name [ [ cipher ] authentication-mode configuration,
user name { md5 | sha } auth-password [ privacy-mode refer to SNMP
{ 3des | aes128 | des56 } priv-password ] ] [ acl Configuration in
acl-number ] the System
Volume.
Only SNMP users sourced from the IP addresses of 10.110.100.52 and 10.110.100.46 are permitted to
access the switch.
Figure 8-2 Network diagram for controlling SNMP users using ACLs
10.110.100.46
Host A
IP network
Switch
Host B
10.110.100.52
# Define a basic ACL.

[Sysname-acl-basic-2000] rule 3 deny source any
# Apply the ACL to only permit SNMP users sourced from the IP addresses of 10.110.100.52 and
10.110.100.46 to access the switch.
[Sysname] snmp-agent community read 3com acl 2000
[Sysname] snmp-agent group v2c 3comgroup acl 2000
[Sysname] snmp-agent usm-user v2c 3comuser 3comgroup acl 2000
8-5

Controlling Web Users by Source IP Addresses
The switch 4510G support Web-based remote management, which allows Web users to access the
switches using the HTTP protocol. By referencing access control lists (ACLs), you can control the
access of Web users to the switches.
Prerequisites
The control policies to be implemented on Web users are decided, including the source IP addresses
to be controlled and the control action, that is, whether to allow or deny the access.
Controlling Web Users by Source IP Addresses
This feature is achieved through the configuration of basic ACLs, the numbers of which are in the
range 2000 to 2999. For the definition of ACLs, see ACL Configuration in the Security Volume.
Follow these steps to configure controlling Web users by source IP addresses:

Required
Create a basic ACL or enter acl [ ipv6 ] number acl-number
basic ACL view [ match-order { config | auto } ] The config keyword is
specified by default.
rule [ rule-id ] { permit | deny } [ source
{ sour-addr sour-wildcard | any } |
Define rules for the ACL Required
time-range time-name | fragment |
logging ]*
Reference the ACL to control

ip http acl acl-number Required
Web users
Forcing Online Web Users Offline
The network administrators can run a command to force online Web users offline.
Perform the following operation to force online Web users offline:

Required
free web-users { all | user-id user-id |
Force online Web users offline Use this command in
user-name user-name }
user view
Configure a basic ACL to allow only Web users using IP address 10.110.100.52 to access the switch.
8-6

Figure 8-3 Configure an ACL to control the access of HTTP users to the switch
10.110.100.46
Host A
IP network
Switch
Host B
10.110.100.52
# Create a basic ACL.

# Reference the ACL to allow only Web users using IP address 10.110.100.52 to access the switch.
[Sysname] ip http acl 2030
8-7

9 Basic System Configurations
While performing basic configurations of the system, go to these sections for information you are
interested in:
z Configuration Display
z Basic Configurations
z CLI Features
Configuration Display
To avoid duplicate configuration, you can use the display commands to view the current configuration
of the device before configuring the device. The configurations of a device fall into the following
categories:
z Factory defaults: When devices are shipped, they are installed with some basic configurations,
which are called factory defaults. These default configurations ensure that a device can start up
and run normally when it has no configuration file or the configuration file is damaged.
z Current configuration: The currently running configuration on the device.
z Saved configuration: Configurations saved in the startup configuration file.
Follow these steps to display device configurations:

Display the factory defaults of
display default-configuration
the device
[ [ configuration [ configuration ] | interface
Display the current validated
[ interface-type ] [ interface-number ] ] Available in
configurations of the device
[ by-linenum ] [ | { begin | exclude | include } any view.
regular-expression ] ]
Display the configuration saved
on the storage media of the display saved-configuration [ by-linenum ]
device
For details of the display saved-configuration command, refer to File System Management
Commands in the System Volume.
Basic Configurations
z Entering/Exiting System View
9-1

z Configuring the Device Name
z Configuring the System Clock
z Enabling/Disabling the Display of Copyright Information
z Configuring a Banner
z Configuring CLI Hotkeys
z Configuring Command Aliases
z Configuring User Privilege Levels and Command Levels
z Displaying and Maintaining Basic Configurations
Entering/Exiting System View
Follow these steps to enter/exit system view:

Enter system view from user view system-view
Return to user view from system view quit
With the quit command, you can return to the previous view. You can execute the return command or
press the hot key Ctrl+Z to return to user view.
Configuring the Device Name
The device name is used to identify a device in a network. Inside the system, the device name
corresponds to the prompt of the CLI. For example, if the device name is Sysname, the prompt of user
view is <Sysname>.
Follow these steps to configure the device name:

Optional
Configure the device name sysname sysname The device name is 4510G by
default.
Configuring the System Clock
Configuring the system clock
The system clock, displayed by system time stamp, is decided by the configured relative time, time
zone, and daylight saving time. You can view the system clock by using the display clock command.
Follow these steps to configure the system clock:
9-2

Optional
Set time and date clock datetime time date
Available in user view.
clock timezone zone-name { add | minus }

Set the time zone Optional
zone-offset
clock summer-time zone-name one-off
Set a daylight saving start-time start-date end-time end-date add-time Optional
time scheme clock summer-time zone-name repeating Use either command
start-time start-date end-time end-date add-time
Displaying the system clock
The system clock is decided by the commands clock datetime, clock timezone and clock
summer-time. If these three commands are not configured, the display clock command displays the
original system clock. If you combine these three commands in different ways, the system clock is
displayed in the ways shown in Table 9-1. The meanings of the parameters in the configuration column
are as follows:
z 1 indicates date-time has been configured with the clock datetime.
z 2 indicates time-zone has been configured with the clock timezone command and the offset time
is zone-offset.
z 3 indicates daylight saving time has been configured with the clock summer-time command and
the offset time is summer-offset.
z [1] indicates the clock datetime command is an optional configuration.
z The default system clock is 2005/1/1 1:00:00 in the example.
Table 9-1 Relationship between the configuration and display of the system clock
System clock displayed by the

display clock command
Configure: clock datetime 1:00 2007/1/1
1 date-time
Display: 01:00:00 UTC Mon 01/01/2007
Configure: clock timezone zone-time add
The original system clock 1
2
zone-offset Display: 02:00:00 zone-time Sat
01/01/2005
and clock timezone zone-time add 1
1 and 2 date-time zone-offset
Display: 03:00:00 zone-time Fri
02/02/2007
1 and clock datetime 3:00 2007/3/3
[1], 2 and 1 date-time
Display: 03:00:00 zone-time Sat
03/03/2007
If the original system clock is not in Configure: clock summer-time ss one-off

3 the daylight saving time range, the 1:00 2006/1/1 1:00 2006/8/8 2
original system clock is displayed. Display: 01:00:00 UTC Sat 01/01/2005
9-3

If the original system clock is in the Configure: clock summer-time ss one-off
daylight saving time range, the 00:30 2005/1/1 1:00 2005/8/8 2
original system clock +
summer-offset is displayed. Display: 03:00:00 ss Sat 01/01/2005

If date-time is not in the daylight and clock summer-time ss one-off 1:00
saving time range, date-time is 2006/1/1 1:00 2006/8/8 2
displayed.
Display: 01:00:00 UTC Mon 01/01/2007
1 and 3
If date-time is in the daylight saving and clock summer-time ss one-off 1:00
time range, date-time + 2007/1/1 1:00 2007/8/8 2
summer-offset is displayed.
Display: 10:00:00 ss Mon 01/01/2007
Configure: clock summer-time ss one-off
If date-time is not in the daylight 1:00 2007/1/1 1:00 2007/8/8 2 and clock
saving time range, date-time is datetime 1:00 2008/1/1
displayed.
Display: 01:00:00 UTC Tue 01/01/2008
date-time is in the daylight saving Configure: clock summer-time ss one-off
[1], 3 and 1 time range: 1:00 2007/1/1 1:00 2007/8/8 2 and clock
If the value of date-time - datetime 1:30 2007/1/1
summer-offset is not in the Display: 23:30:00 UTC Sun 12/31/2006
summer-time range, date-time -
summer-offset is displayed; Configure: clock summer-time ss one-off
If the value of date-time - 1:00 2007/1/1 1:00 2007/8/8 2 and clock
summer-offset is in the datetime 3:00 2007/1/1
summer-time range, date-time is
Display: 03:00:00 ss Mon 01/01/2007
displayed.
1 and clock summer-time ss one-off 1:00
2007/1/1 1:00 2007/8/8 2
If the value of the original system
clock zone-offset is not in the Display: 02:00:00 zone-time Sat
summer-time range, the original 01/01/2005
system clock zone-offset is Configure: clock timezone zone-time add
displayed. 1 and clock summer-time ss one-off 1:00
2 and 3 or 3 2005/1/1 1:00 2005/8/8 2
and 2
Display: 04:00:00 ss Sat 01/01/2005
Configure: clock datetime 1:00 2007/1/1,

If the value of the original system clock timezone zone-time add 1 and
clock zone-offset is in the clock summer-time ss one-off 1:00
summer-time range, the original 2008/1/1 1:00 2008/8/8 2
system clock zone-offset
+ summer-offset is displayed. Display: 02:00:00 zone-time Mon
01/01/2007
If the value of Configure: clock datetime 1:00 2007/1/1,

"date-time""zone-offset" is not in clock timezone zone-time add 1 and
the summer-time range, clock summer-time ss one-off 1:00
"date-time""zone-offset" is 2007/1/1 1:00 2007/8/8 2
displayed. Display: 04:00:00 ss Mon 01/01/2007
1, 2 and 3 or 1, 3
and 2 Configure: clock timezone zone-time add
If the value of 1, clock summer-time ss one-off 1:00
"date-time""zone-offset" is in the 2008/1/1 1:00 2008/8/8 2 and clock
summer-time range, datetime 1:00 2007/1/1
"date-time""zone-offset"+summer-
offset is displayed. Display: 01:00:00 zone-time Mon
01/01/2007
9-4

1, clock summer-time ss one-off 1:00
If date-time is not in the daylight 2008/1/1 1:00 2008/8/8 2 and clock
saving time range, date-time is datetime 1:30 2008/1/1
displayed.
Display: 23:30:00 zone-time Mon
12/31/2007
date-time is in the daylight saving
[1], 2, 3 and 1 or time range:
[1], 3, 2 and 1 If the value of
date-time-summer-offset is not in Configure: clock timezone zone-time add
the summer-time range, 1, clock summer-time ss one-off 1:00
date-time-summer-offset is 2008/1/1 1:00 2008/8/8 2 and clock
displayed; datetime 3:00 2008/1/1
If the value of Display: 03:00:00 ss Tue 01/01/2008
date-time-summer-offset is in the
summer-time range, date-time is
displayed.
Enabling/Disabling the Display of Copyright Information
z With the display of copyright information enabled, the copyright information is displayed when a
user logs in through Telnet or SSH, or when a user quits user view after logging in to the device
through the console port, AUX port, or asynchronous serial interface. The copyright information
will not be displayed under other circumstances. The display format of copyright information is as
shown below:
******************************************************************************
* Copyright (c) 2004-2009 3Com Corp. and its licensors. All rights reserved. *
* This software is protected by copyright law and international treaties. *
* Without the prior written permission of 3Com Corporation and its licensors,*
* any reproduction republication, redistribution, decompiling, reverse *
* engineering is strictly prohibited. Any unauthorized use of this software *
* or any portion of it may result in severe civil and criminal penalties, and*
* will be prosecuted to the maximum extent possible under the applicable law.*
******************************************************************************
z With the display of copyright information disabled, under no circumstances will the copyright
information be displayed.
Follow these steps to enable/disable the display of copyright information:

Enable the display of copyright Optional

copyright-info enable
information Enabled by default.
Disable the display of copyright Required

undo copyright-info enable
information Enabled by default.
9-5

Configuring a Banner
Introduction to banners
Banners are prompt information displayed by the system when users are connected to the device,
perform login authentication, and start interactive configuration. The administrator can set
corresponding banners as needed.
At present, the system supports the following five kinds of welcome information.
z shell banner, also called session banner, displayed when a non TTY Modem user enters user
view.
z incoming banner, also called user interface banner, displayed when a user interface is activated
by a Modem user.
z login banner, welcome information at login authentications, displayed when password and
scheme authentications are configured.
z motd (Message of the Day) banner, welcome information displayed before authentication.
z legal banner, also called authorization information. The system displays some copyright or
authorization information, and then displays the legal banner before a user logs in, waiting for the
user to confirm whether to continue the authentication or login. If entering Y or pressing the Enter
key, the user enters the authentication or login process; if entering N, the user quits the
authentication or login process. Y and N are case insensitive.
Configuring a banner
When you configure a banner, the system supports two input modes. One is to input all the banner
information right after the command keywords. The start and end characters of the input text must be
the same but are not part of the banner information. In this case, the input text, together with the
command keywords, cannot exceed 510 characters. The other is to input all the banner information in
multiple lines by pressing the Enter key. In this case, up to 2000 characters can be input.
The latter input mode can be achieved in the following three ways:
z Press the Enter key directly after the command keywords, and end the setting with the %
character. The Enter and % characters are not part of the banner information.
z Input a character after the command keywords at the first line, and then press the Enter key. End
the setting with the character input at the first line. The character at the first line and the end
character are not part of the banner information.
z Input multiple characters after the command keywords at the first line (with the first and last
characters being different), then press the Enter key. End the setting with the first character at the
first line. The first character at the first line and the end character are not part of the banner
information.
Follow these steps to configure a banner:

Configure the banner to be displayed at login

header incoming text Optional
(available for Modem login users)
Configure the banner to be displayed at login
header login text Optional
authentication
Configure the authorization information before login header legal text Optional
9-6

Configure the banner to be displayed when a user
header shell text Optional
enters user view (non Modem login users)
Configure the banner to be displayed before login header motd text Optional
Configuring CLI Hotkeys
Follow these steps to configure CLI hotkeys:

hotkey { CTRL_G | CTRL_L Optional

Configure CLI
| CTRL_O | CTRL_T | The Ctrl+G, Ctrl+L and Ctrl+O hotkeys are
hotkeys
CTRL_U } command specified with command lines by default.
Available in any view. Refer to Table 9-2 for
Display hotkeys display hotkey
hotkeys reserved by the system.
By default, the Ctrl+G, Ctrl+L and Ctrl+O hotkeys are configured with command line and the Ctrl+T
and Ctrl+U commands are NULL.
z Ctrl+G corresponds to the display current-configuration command.
z Ctrl+L corresponds to the display ip routing-table command.
z Ctrl+O corresponds to the undo debugging all command.
Table 9-2 Hotkeys reserved by the system
Hotkey Function
Ctrl+A Moves the cursor to the beginning of the current line.
Ctrl+B Moves the cursor one character to the left.
Ctrl+C Stops performing a command.
Ctrl+D Deletes the character at the current cursor position.
Ctrl+E Moves the cursor to the end of the current line.
Ctrl+F Moves the cursor one character to the right.

Ctrl+H Deletes the character to the left of the cursor.
Ctrl+K Terminates an outgoing connection.
Ctrl+N Displays the next command in the history command buffer.
Ctrl+P Displays the previous command in the history command buffer.
Ctrl+R Redisplays the current line information.
Ctrl+V Pastes the content in the clipboard.
Ctrl+W Deletes all the characters in a continuous string to the left of the cursor.
9-7

Hotkey Function
Ctrl+X Deletes all the characters to the left of the cursor.
Ctrl+Y Deletes all the characters to the right of the cursor.
Ctrl+Z Exits to user view.
Ctrl+] Terminates an incoming connection or a redirect connection.

Moves the cursor to the leading character of the continuous string to the
Esc+B
left.
Deletes all the characters of the continuous string at the current cursor
Esc+D
position and to the right of the cursor.
Esc+F Moves the cursor to the front of the next continuous string to the right.
Esc+N Moves the cursor down by one line (available before you press Enter)
Esc+P Moves the cursor up by one line (available before you press Enter)
Esc+< Specifies the cursor as the beginning of the clipboard.

Esc+> Specifies the cursor as the ending of the clipboard.
These hotkeys are defined by the device. When you interact with the device from terminal software,
these keys may be defined to perform other operations. If so, the definition of the terminal software will
dominate.
Configuring Command Aliases
You can replace the first keyword of a command supported by the device with your preferred keyword
by configuring the command alias function. For example, if you configure show as the replacement of
the display keyword for each display command, you can input the command alias show xx to
execute the display xx command.
Note the following when you configure command aliases:
z When you input a command alias, the system displays and saves the command in its original
format instead of its alias. That is, you can define and use a command alias but the command is
not saved and restored in its alias.
z When you define a command alias, the cmdkey and alias arguments must be in complete form.
z With the command alias function enabled, when you input an incomplete keyword, which partially
matches both a defined alias and the keyword of a command, the alias wins; to execute the
command whose keyword partially matches your input, you need to input the complete keyword.
When you input a character string that matches multiple aliases partially, the system prompts you
for various matched information.
z If you press Tab after you input the keyword of an alias, the original format of the keyword will be
displayed.
z You can replace only the first keyword of a non-undo command instead of the complete command;
and you can replace only the second keyword of undo commands.
Follow these steps to configure command aliases:
9-8

Required
Enable the command alias Disabled by default, that is, you
command-alias enable
function cannot configure command
aliases.
command-alias mapping Required

Configure command aliases
cmdkey alias Not configured by default.
Configuring User Privilege Levels and Command Levels
Introduction
To restrict the different users access to the device, the system manages the users by their privilege
levels. User privilege levels correspond to command levels. After users at different privilege levels log
in, they can only use commands at their own, or lower, levels. All the commands are categorized into
four levels, which are visit, monitor, system, and manage from low to high, and identified respectively
by 0 through 3. Table 9-3 describes the levels of the commands.
Table 9-3 Default command levels
Level Privilege Description

Involves commands for network diagnosis and commands for accessing
an external device. Commands at this level are not allowed to be saved
0 Visit after being configured. After the device is restarted, the commands at
this level will be restored to the default settings. Commands at this level
include ping, tracert, telnet and ssh2.
Includes commands for system maintenance and service fault diagnosis.
Commands at this level are not allowed to be saved after being
1 Monitor configured. After the device is restarted, the commands at this level will
be restored to the default settings. Commands at this level include
debugging, terminal, refresh, reset, and send.
Provides service configuration commands, including routing and
commands at each level of the network for providing services. By
2 System
default, commands at this level include all configuration commands
except for those at manage level.
Influences the basic operation of the system and the system support
modules for service support. By default, commands at this level involve
file system, FTP, TFTP, Xmodem command download, user
3 Manage
management, level setting, as well as parameter setting within a system
(the last case involves those non-protocol or non RFC provisioned
commands).
Configuring user privilege level
User privilege level can be configured by using AAA authentication parameters or under a user
interface.
1) Configure user privilege level by using AAA authentication parameters
If the user interface authentication mode is scheme when a user logs in, and username and password
are needed at login, then the user privilege level is specified in the configuration of AAA authentication.
9-9

Follow these steps to configure user privilege level by using AAA authentication parameters:

Required
Configure the authentication
authentication-mode scheme By default, the authentication
mode for logging in to the user
[ command-authorization ] mode for VTY and AUX users
interface as scheme
is password.
Required if users use SSH to

Configure the authentication For the details, refer to SSH2.0
log in, and username and
mode for SSH users as Configuration in the Security
password are needed at
password Volume.
authentication
z Use the local-user
command to create a local User either approach
user and enter local user
Using local view. z For local authentication, if
authentication you do not configure the
z Use the level keyword in user level, the user level is
Configure the the authorization-attribute
user privilege 0, that is, users of this level
command to configure the can use commands with
level by using user level.
AAA level 0 only.
authentication Using remote z For remote authentication, if
parameters authentication you do not configure the
(RADIUS, user level, the user level
Configure user level on the
HWTACACS, depends on the default
authentication server
and LDAP configuration of the
authentication authentication server.
s)
z For the description of user interface, refer to Login Configuration in the System Volume; for the
description of the user-interface, authentication-mode and user privilege level commands,
refer to User Interface Commands in the System Volume.
z For the introduction to AAA authentication, refer to AAA Configuration in the Security Volume; for
the description of the local-user and authorization-attribute commands, refer to AAA
Commands in the Security Volume.
z For the introduction to SSH, refer to SSH 2.0 Configuration in the Security Volume.
2) Example of configuring user privilege level by using AAA authentication parameters

# Authenticate the users telnetting to the device through VTY 1, verify their usernames and passwords
locally, and specify the user privilege level as 3.
[Sysname-ui-vty1] authentication-mode scheme
[Sysname-ui-vty1] quit
[Sysname] local-user test
9-10

[Sysname-luser-test] password cipher 123
[Sysname-luser-test] service-type telnet
After the above configuration, when users telnet to the device through VTY 1, they need to input
username test and password 123. After passing the authentication, users can only use the commands
of level 0. If the users need to use commands of levels 0, 1, 2 and 3, the following configuration is
required:
[Sysname-luser-test] authorization-attribute level 3
3) Configure the user privilege level under a user interface
If the user interface authentication mode is scheme when a user logs in, and SSH publickey
authentication type (only username is needed for this authentication type) is adopted, then the user
privilege level is the user interface level; if a user logs in using the none or password mode (namely,
no username is needed), the user privilege level is the user interface level.
Follow these steps to configure the user privilege level under a user interface (SSH publickey
authentication type):

Required if users adopt the
SSH login mode, and only
username, instead of password
Configure the authentication For the details, refer to SSH2.0 is needed at authentication.
type for SSH users as Configuration in the Security
publickey Volume. After the configuration, the
authentication mode of the
corresponding user interface
must be set to scheme.
Configure the authentication Optional

mode when a user uses the authentication-mode scheme By default, the authentication
current user interface to log in [ command-authorization ] mode for VTY and AUX user
to the device interfaces is password.
Optional
Configure the privilege level of By default, the user privilege
the user logging in from the user privilege level level level for users logging in from
current user interface the console user interface is 3,
and that for users logging from
the other user interfaces is 0.
Follow these steps to configure the user privilege level under a user interface (none or password
authentication mode):

Configure the authentication Optional

mode when a user uses the authentication-mode { none | By default, the authentication
current user interface to log in password } mode for VTY and AUX user
to the device interfaces is password.
9-11

Optional
Configure the privilege level of By default, the user privilege
the user logging in from the user privilege level level level for users logging in from
current user interface the console user interface is 3,
and that for users logging from
the other user interfaces is 0.
4) Example of configuring user privilege level under a user interface

z Perform no authentication to the users telnetting to the device, and specify the user privilege level
as 1. (This configuration brings potential security problem. Therefore, you are recommended to
use it only in a lab environment.)
[Sysname-ui-vty0-4] authentication-mode none
[Sysname-ui-vty0-4] user privilege level 1
By default, when users telnet to the device, they can only use the following commands after passing
the authentication:
<Sysname> ?
User view commands:
cluster Run cluster command
display Display current system information
ping Ping function
quit Exit from current command view
ssh2 Establish a secure shell client connection
super Set the current user priority level
telnet Establish one TELNET connection
tracert Trace route function
After you set the user privilege level under the user interface, users can log in to the device through
Telnet without any authentication and use the following commands:
<Sysname> ?
User view commands:
debugging Enable system debugging functions
display Display current system information
ipc Interprocess communication
ping Ping function
quit Exit from current command view
refresh Do soft reset
reset Reset operation
screen-length Specify the lines displayed on one screen
send Send information to other user terminal interface
ssh2 Establish a secure shell client connection
super Set the current user priority level
telnet Establish one TELNET connection
terminal Set the terminal line characteristics
tracert Trace route function
9-12

undo Cancel current setting
z Authenticate the usesr logging in to the device through Telnet, verify their passwords, and specify
the user privilege levels as 2.
[Sysname-ui-vty0-4] authentication-mode password
[Sysname-ui-vty0-4] set authentication password cipher 123
[Sysname-ui-vty0-4] user privilege level 2
By default, when users log in to the device through Telnet, they can use the commands of level 0 after
passing the authentication. After you set the user privilege level under the user interface, when users
log in to the device through Telnet, they need to input password 123, and then they can use commands
of levels 0, 1, and 2.
Switching user privilege level
Users can switch their user privilege level temporarily without logging out and disconnecting the
current connection; after the switch, users can continue to configure the device without the need of
relogin and reauthentication, but the commands that they can execute have changed. For example, if
the current user privilege level is 3, the user can configure system parameters; after switching the user
privilege level to 0, the user can only execute some simple commands, like ping and tracert, and only
a few display commands. The switching of user privilege level is temporary, and effective for the
current login; after the user relogs in, the user privilege restores to the original level.
To avoid misoperations, the administrators are recommended to log in to the device by using a lower
privilege level and view device operating parameters, and when they have to maintain the device, they
can switch to a higher level temporarily; when the administrators need to leave for a while or ask
someone else to manage the device temporarily, they can switch to a lower privilege level before they
leave to restrict the operation by others.
Users can switch from a high user privilege level to a low user privilege level without entering a
password; when switching from a low user privilege level to a high user privilege level, only the console
login users do not have to enter the password, and users that log in from VTY user interfaces need to
enter the password for securitys sake. This password is for level switching only and is different from
the login password. If the entered password is incorrect or no password is configured, the switching
fails. Therefore, before switching a user to a higher user privilege level, you should configure the
password needed.
Follow these steps to switch user privilege level:

Configure the password for super password [ level Required

switching the user privilege user-level ] { simple | cipher } By default, no password is
level password configured.
Exit to user view quit
Required
Switch the user privilege When logging in to the device, a
super [ level ] user has a user privilege level,
level
which is decided by user interface
or authentication user level.
9-13

z When you configure the password for switching user privilege level with the super password
command, the user privilege level is 3 if no user privilege level is specified.
z The password for switching user privilege level can be displayed in both cipher text and simple
text. You are recommended to adopt the former as the latter is easily cracked.
Modifying command level
All the commands in a view are defaulted to different levels, as shown in Table 9-3. The administrator
can modify the command level based on users needs to make users of a lower level use commands
with a higher level or improve device security.
Follow these steps to modify the command level:

Required
Configure the command level command-privilege level
in a specified view level view view command Refer to Table 9-3 for the
default settings.
You are recommended to use the default command level or modify the command level under the
guidance of professional staff; otherwise, the change of command level may bring inconvenience to
your maintenance and operation, or even potential security problem.
Displaying and Maintaining Basic Configurations

Display information on system version display version
Display information on the system clock display clock
Display defined command aliases and the

display command-alias
corresponding commands
Display information on terminal users display users [ all ] Available in
any view
Display the valid configuration under
display this [ by-linenum ]
current view
Display clipboard information display clipboard
Display and save statistics of each

display diagnostic-information
modules running status
9-14

During daily maintenance or when the system is operating abnormally, you need to view each
modules running status to find the problem. Therefore, you are required to execute the corresponding
display commands one by one. To collect more information one time, you can execute the display
diagnostic-information command in any view to display or save statistics of each modules running
status. The execution of the display diagnostic-information command has the same effect as that of
the commands display clock, display version, display device, and display current-configuration.
z For the detailed description of the display users command, refer to Login Commands in the
System Volume.
z Support for the display configure-user and display current-configuration command depends on the
device model.
z The display commands discussed above are for the global configuration. Refer to the
corresponding section for the display command for specific protocol and interface.
CLI Features
z Introduction to CLI
z Online Help with Command Lines
z Synchronous Information Output
z Undo Form of a Command
z Editing Features
z CLI Display
z Saving History Command
z Command Line Error Information
Introduction to CLI
CLI is an interaction interface between devices and users. Through CLI, you can configure your
devices by entering commands and view the output information and verify your configurations, thus
facilitating your configuration and management of your devices.
CLI provides the following features for you to configure and manage your devices:
z Hierarchical command protection where you can only execute the commands at your own or lower
levels. Refer to Configuring User Privilege Levels and Command Levels for details.
z Easy access to on-line help by entering ?
z Abundant debugging information for fault diagnosis
z Saving and executing commands that have been executed
z Fuzzy match for convenience of input. When you execute a command, you can input part of the
characters in a keyword. However, to enable you to confirm your operation, the command can be
executed only when you input enough characters to make the command unique. Take the
commands save, startup saved-configuration, and system-view which start with s as an
example. To save the current configuration, you need to input sa at least; to set the configuration
9-15

file for next startup, you need to input st s at least; to enter system view, you need to input sy at
least. You can press Tab to complement the command, or you can input the complete command.
Online Help with Command Lines
The following are the types of online help available with the CLI:
z Full help
z Fuzzy help
To obtain the desired help information, you can:
1) Enter ? in any view to access all the commands in this view and brief description about them as
well.
<Sysname> ?
User view commands:
backup Backup next startup-configuration file to TFTP server
boot-loader Set boot loader
bootrom Update/read/backup/restore bootrom
cd Change current directory
clock Specify the system clock
copy Copy from one file to another
debugging Enable system debugging functions
delete Delete a file
dir List files on a file system
display Show running system information
......omitted......
2) Enter a command and a ? separated by a space. If ? is at the position of a keyword, all the
keywords are given with a brief description.
<Sysname> terminal ?
debugging Send debug information to terminal
logging Send log information to terminal
monitor Send information output to current terminal
trapping Send trap information to terminal
3) Enter a command and a ? separated by a space. If ? is at the position of a parameter, the
description about this parameter is given.
[Sysname] interface vlan-interface ?
<1-4094> VLAN interface number
[Sysname] interface vlan-interface 1 ?
<cr>
Where, <cr> indicates that there is no parameter at this position. The command is then repeated in the
next command line and executed if you press Enter.
4) Enter a character string followed by a ?. All the commands starting with this string are displayed.
<Sysname> c?
cd
clock
copy
9-16

5) Enter a command followed by a character string and a ?. All the keywords starting with this string
are listed.
<Sysname> display ver?
version
6) Press Tab after entering the first several letters of a keyword to display the complete keyword,
provided these letters can uniquely identify the keyword in this command. If several matches are
found, the complete keyword which is matched first is displayed (the matching rule is: the letters
next to the input letters are arranged in alphabetic order, and the letter in the first place is matched
first.). If you repeatedly press Tab, all the keywords starting with the letter that you enter are
displayed in cycles.
Synchronous Information Output
Synchronous information output refers to the feature that if the users input is interrupted by system
output, then after the completion of system output the system will display a command line prompt and
your input so far, and you can continue your operations from where you were stopped.
You can use the info-center synchronous command to enable synchronous information output. For
the detailed description of this function, refer to Information Center Configuration in the System
Volume.
Undo Form of a Command
Adding the keyword undo can form an undo command. Almost every configuration command has an
undo form. undo commands are generally used to restore the system default, disable a function or
cancel a configuration. For example, the info-center enable command is used to enable the
information center, while the undo info-center enable command is used to disable the information
center. (By default, the information center is enabled.)
Editing Features
The CLI provides the basic command editing functions and supports multi-line editing. When you
execute a command, the system automatically goes to the next line if the maximum length of the
command is reached. You cannot press Enter to go to the next line; otherwise, the system will
automatically execute the command. The maximum length of each command is 510 characters. Table
9-4 lists these functions.
Table 9-4 Edit functions
Key Function
If the editing buffer is not full, insert the character at the position
Common keys
of the cursor and move the cursor to the right.
Deletes the character to the left of the cursor and move the
Backspace
cursor back one character.
Left-arrow key or Ctrl+B The cursor moves one character space to the left.
Right-arrow key or Ctrl+F The cursor moves one character space to the right.
Up-arrow key or Ctrl+P

Displays history commands
Down-arrow key or Ctrl+N
9-17

Key Function
Pressing Tab after entering part of a keyword enables the
fuzzy help function. If finding a unique match, the system
substitutes the complete keyword for the incomplete one and
displays it in the next line; when there are several matches, if
Tab
you repeatedly press Tab, all the keywords starting with the
letter that you enter are displayed in cycles. If there is no match
at all, the system does not modify the incomplete keyword and
displays it again in the next line.
When editing the command line, you can use other shortcut keys (For details, see Table 9-2) besides
the shortcut keys defined in Table 9-4, or you can define shortcut keys by yourself. (For details, see
Configuring CLI Hotkeys.)
CLI Display
By filtering the output information, you can find the wanted information effectively. If there is a lot of
information to be displayed, the system displays the information in multiple screens. When the
information is displayed in multiple screens, you can also filter the output information to pick up the
wanted information.
Filtering the output information
The device provides the function to filter the output information. You can specify a regular expression
(that is, the output rule) to search information you need.
You can use one of the following two ways to filter the output information:
z Input the keyword begin, exclude, or include as well as the regular expression at the command
line to filter the output information.
z Input slash (/), minus (-), or plus (+) as well as the regular expression to filter the rest output
information. Slash (/) is equal to the keyword begin, minus (-) is equal to the keyword exclude,
and plus (+) is equal to the keyword include.
Keywords begin, exclude, and include have the following meanings:
z begin: Displays the line that matches the regular expression and all the subsequent lines.
z exclude: Displays the lines that do not match the regular expression.
z include: Displays only the lines that match the regular expression.
The regular expression is a string of 1 to 256 characters, case sensitive. It also supports special
characters as shown in Table 9-5.
Table 9-5 Special characters in a regular expression
Character Meaning Remarks

For example, regular expression ûser
Starting sign, string appears only at the
^string only matches a string beginning with
beginning of a line.
user, not Auser.
9-18

For example, regular expression "user$
Ending sign, string appears only at the
string$ only matches a string ending with
end of a line.
user, not userA.
Full stop, a wildcard used in place of any
For example, .l can match vlan or
. character, including single character,
mpls.
special character and blank.
Asterisk, used to match a character or
For example, zo* can match z and
* character group before it zero or multiple
zoo; (zo)* can match zo and zozo.
times.
Addition, used to match a character or
For example, zo+ can match zo and
+ character group one or multiple times
zoo, but not z.
before it
Vertical bar, used to match the whole For example, def|int can only match a
|
string on the left or right of it character string containing def or int.
Underline. If it is at the beginning or the For example, a_b can match a b or
end of a regular expression, it equals ^ or a(b; _ab can only match a line
_
$; in other cases, it equals comma, starting with ab; ab_ can only match
space, round bracket, or curly bracket. a line ending with ab.
Hyphen. It connects two values (the
For example, 1-9 means numbers
smaller one before it and the bigger one
- from 1 to 9 (inclusive); a-h means from
after it) to indicate a range together with
a to h (inclusive).
[ ].
For example, [16A] can match a string
containing any character among 1, 6,
and A; [1-36A] can match a string
containing any character among 1, 2, 3,
A range of characters, Matches any 6, and A (with - being a hyphen).
[]
character in the specified range.
] can be matched only when it is put at
the beginning of [ ] if it is used as a
common character in [ ], for example
[ ]string]. There is no such limit on [.
For example, (123A) means a character
A character group. It is usually used with group 123A; 408(12)+ can match
()
+ or *. 40812 or 408121212. But it cannot
match 408.
For example, (string)\1 means to repeat

string for once, and (string)\1 must
Repeats a specified character group for
match a string containing stringstring;
once. A character group refers to the
(string1)(string2)\2 means to repeat
string in () before \. index refers to the
string2 for once, and (string1)(string2)\2
sequence number (starting from 1 from
must match a string containing
left to right) of the character group before
\index string1string2string2;
\: if only one character group appears
(string1)(string2)\1\2 means to repeat
before \, then index can only be 1; if n
string1 for once first, and then repeat
character groups appear before index,
string2 for once, and
then index can be any integer from 1 to
(string1)(string2)\1\2 must match a
n.
string containing
string1string2string1string2.
For example, [^16A] means to match a
string containing any character except
1, 6 or A, and the string can also contain
Used to match any character not in a
[^] 1, 6 or A, but cannot contain these three
specified range.
characters only. For example, [^16A]
can match abc and m16, but not 1,
16, or 16A.
9-19

Used to match a character string starting For example, \<do can match word
\<string
with string. domain or string doa.
Used to match a character string ending For example, do\> can match word
string\>
with string. undo or string abcdo.
Used to match character1character2. For example, \ba can match -a, with -
character1 can be any character except represents character1, and a represents
\bcharacter2
number, letter or underline, and \b character2; while \ba cannot match 2a
equals [Â-Za-z0-9_]. or ba.
It must match a string containing
For example, \Bt can match t in
\Bcharacter character, and there can no spaces
install, but not t in big top.
before character.
For example, v\w can match vlan,
Used to match character1character2.
with v being character1, and l being
character1\w character2 must be a number, letter or
character2. v\w can also match
underline, and \w equals [Â-Za-z0-9_].
service, with i being character2.
For example, \Wa can match -a, with
- representing character1, and a
\W Equals \b.
representing character2; while \ba
cannot match 2a or ba.
Escape character. If single special For example, \\ can match a string
characters listed in this table follow \, the containing \, \^ can match a string
\
specific meanings of the characters will containing ^, and \\b can match a
be removed. string containing \b.
Multiple-screen output
When there is a lot of information to be output, the system displays the information in multiple screens.
Generally, 24 lines are displayed on one screen, and you can also use the screen-length command to
set the number of lines displayed on the next screen. (For the details of this command, refer to Login
Commands in the System Volume.) You can follow the step below to disable the multiple-screen output
function of the current user.

Required
By default, a login user uses the settings of the
screen-length command. The default settings of the
Disable the
screen-length command are: multiple-screen output
multiple-screen
is enabled and 24 lines are displayed on the next
output function screen-length disable
screen.
of the current
user This command is executed in user view, and
therefore is applicable to the current user only. When
a user re-logs in, the settings restore to the system
default.
Display functions
CLI offers the following feature:

When the information displayed exceeds one screen, you can pause using one of the methods shown
in Table 9-6.
9-20

Table 9-6 Display functions
Action Function
Continues to display information of the next
Press Space when information display pauses
screen page.
Press Enter when information display pauses Continues to display information of the next line.
Press Ctrl+C when information display pauses Stops the display and the command execution.
Ctrl+E Moves the cursor to the end of the current line.
PageUp Displays information on the previous page.
PageDown Displays information on the next page.
Saving History Commands
The CLI can automatically save the commands that have been used lately to the history buffer. You
can know the operations that have been executed successfully, invoke and repeatedly execute them
as needed. By default, the CLI can save up to ten commands for each user. You can use the
history-command max-size command to set the capacity of the history commands buffer for the
current user interface (For the detailed description of the history-command max-size command, refer
to Login Commands in the System Volume). In addition:
z The CLI saves the commands in the format that you have input, that is, if you input a command in
its incomplete form, the saved history command is also incomplete.
z If you execute a command for multiple times successively, the CLI saves the earliest one.
However, if you execute the different forms of a command, the CLI saves each form of this
command. For example, if you execute the display cu command for multiple times successively,
the CLI saves only one history command; if you execute the display cu command and then the
display current-configuration command, the CLI saves two history commands.
Follow these steps to access history commands:
To do Use the key/command Result

Displays the commands that
View the history commands display history-command
you have entered
Access the previous history Displays the earlier history
Up-arrow key or Ctrl+P
command command, if there is any.
Access the next history Displays the next history
Down-arrow key or Ctrl+N
command command, if there is any.
You may use arrow keys to access history commands in Windows 200X and XP Terminal or Telnet.
However, the up-arrow and down-arrow keys are invalid in Windows 9X HyperTerminal, because they
are defined in a different way. You can press Ctrl+P or Ctrl+N instead.
9-21

Command Line Error Information
The commands are executed only if they have no syntax error. Otherwise, error information is reported.
Table 9-7 lists some common errors.
Table 9-7 Common command line errors
Error information Cause

The command was not found.
The keyword was not found.
% Unrecognized command found at '^' position. Parameter type error
The parameter value is beyond the allowed

range.
% Incomplete command found at '^' position. Incomplete command
% Ambiguous command found at '^' position. Ambiguous command,
Too many parameters Too many parameters
% Wrong parameter found at '^' position. Wrong parameter
9-22

10 Device Management
When configuring device management, go to these sections for information you are interested in:
z Device Management Overview
z Device Management Configuration Task List
z Configuring the Exception Handling Method
z Rebooting a Device
z Configuring the Scheduled Automatic Execution Function
z Upgrading Device Software
z Disabling Boot ROM Access
z Configuring a Detection Interval
z Clearing the 16-bit Interface Indexes Not Used in the Current System
z Identifying and Diagnosing Pluggable Transceivers
z Displaying and Maintaining Device Management Configuration
z Device Management Configuration Examples
Device Management Overview

Through the device management function, you can view the current working state of a device,
configure running parameters, and perform daily device maintenance and management.
Device Management Configuration Task List

Complete these tasks to configure device management:
Task Remarks
Configuring the Exception Handling Method Optional
Rebooting a Device Optional
Configuring the Scheduled Automatic Execution Function Optional
Upgrading Device Software Optional
Disabling Boot ROM Access Optional
Configuring a Detection Interval Optional

Clearing the 16-bit Interface Indexes Not Used in the Current System Optional
Identifying and Diagnosing Pluggable Transceivers Optional
Configuring the Exception Handling Method

When the system detects any software abnormality, it handles the situation with one of the following
two methods:
z reboot: The system recovers itself through automatic reboot.
10-1

z maintain: The system maintains the current situation, and does not take any measure to recover
itself. Therefore, you need to recover the system manually, such as reboot the system.
Sometimes, it is difficult for the system to recover, or some prompts that are printed during the
failure are lost after the reboot. In this case, you can use this method to maintain the abnormal
state to locate problems and recover the system.
Follow these steps to configure exception handling method:

Optional
Configure exception handling system-failure { maintain | By default, all member devices
method on all member devices reboot } adopt the reboot method to
handle exceptions.
z After this command is configured, all the member devices adopt the same method to handle
exceptions.
z The exception handling method is effective to the failed member device only, and does not
influence the operations of other IRF members.
Rebooting a Device
When a fault occurs to a running device, you can remove the fault by rebooting the device, depending
on the actual situation. This operation equals to powering on the device after powering it off. It is mainly
used to reboot a device in remote maintenance, without performing hardware reboot of the device.
According to the actual environment:
z You can reboot a member device or the whole system.
z You can trigger the immediate reboot through command lines, or set a time at which the device
can automatically reboot, or you can also set a delay so that the device can automatically reboot
in the delay.
Follow these steps to reboot a device:
Reboot a member device or the Optional

reboot [ slot slot-number ]
whole IRF system Available in user view
Enable the scheduled reboot

function of all member devices schedule reboot at hh:mm
and specify a specific reboot [ date ] Optional
time and date The scheduled reboot function
Enable the scheduled reboot is disabled by default.
function of all member devices schedule reboot delay Available in user view
and specify a reboot waiting { hh:mm | mm }
time
10-2

z Use the save command to save the current configuration before you reboot the device to avoid
configuration lost. (For details of the save command, refer to File System Management
Configuration in the System Volume.)
z Use the display startup command and the display boot-loader command to verify the
configuration files and the startup file to be used at the next system startup before you reboot the
device. (For details of the display startup command, refer to File System Management
Configuration in the System Volume.)
z The precision of the rebooting timer is 1 minute. One minute before the rebooting time, the device
will prompt REBOOT IN ONE MINUTE and will reboot in one minute.
z When you execute the reboot command on the master, if you specify the slot keyword, the
member device with the specified number will reboot; if you do not specify the slot keyword, all
member devices in the IRF will reboot.
z Device reboot may result in the interruption of the ongoing services. Use these commands with
caution.
z If a main boot file fails or does not exist, the device cannot be rebooted with the reboot command.
In this case, you can re-specify a main boot file to reboot the device, or you can power off the
device then power it on and the system automatically uses the backup boot file to restart the
device.
z If you are performing file operations when the device is to be rebooted, the system does not
execute the command for the sake of security.
Configuring the Scheduled Automatic Execution Function

The scheduled automatic execution function means that the system automatically executes a specified
command at a specified time in a specified view. This function is used for scheduled system upgrade
or configuration.
Follow these steps to configure the scheduled automatic execution function:

Automatically execute the
schedule job at time [ date ]
specified command at the Optional
view view command
specified time If you configure the function,
Automatically execute the use either command
schedule job delay time view
specified command after the Available in user view
view command
specified delay
Note that:
z At present, you can specify user view and system view only. To automatically execute the
specified command in another view or automatically execute multiple commands at a time, you
can configure the system to automatically execute a batch file at the specified time (note that you
must provide a complete file path for the system to execute the batch file.).
z The system does not check the values of the view and command arguments. Therefore, ensure
the correctness of the command argument (including the correct format of command and the
correct relationship between the command and view arguments).
10-3

z After the specified automatic execution time is reached, the system executes the specified
command in the background without displaying any information except system information such
as log, trap and debug.
z The system does not require any interactive information when it is executing the specified
command. If there is information for you to confirm, the system automatically inputs Y or Yes; if
characters need to be input, the system automatically inputs a default character string, or inputs
an empty character string when there is no default character string.
z For the commands used to switch user interfaces, such as telnet, ftp, and ssh2, the commands
used to switch views, such as system-view, quit, and the commands used to modify status of a
user that is executing commands, such as super, the operation interface, command view and
status of the current user are not changed after the automatic execution function is performed.
z If the system time is modified after the automatic execution function is configured, the scheduled
automatic execution configuration turns invalid automatically.
z Only the last configuration takes effect if you execute the schedule job command repeatedly.
z After you configure this feature on the master, the configuration is not backed up to the slaves;
after the change of the master, this configuration will be ineffective.
Upgrading Device Software

Device Software Overview
Device software consists of the Boot ROM program and the system boot file. After the device is
powered on, the device runs the Boot ROM program, initializes the hardware, and displays the
hardware information. Then the device runs the boot file. The boot file provides drivers and adaption
for hardware, and implements service features. The Boot ROM program and system boot file are
required for the startup and running of a device. Figure 10-1 illustrates their relationship.
Figure 10-1 Relationship between the Boot ROM program and the system boot file
Select the Reboot option
to reboot the device
Start
Boot ROM runs
Enter Boot ROM

Yes menu to upgrade the
Press Ctrl+B
Boot ROM program
or boot File
No
Run boot file
Enter CLI
Finish
10-4

The Boot ROM program and system boot file can both be upgraded through the Boot ROM menu or
command lines. The following sections describe the upgrading through command lines. For
instructions about how to upgrade them through the Boot ROM menu, refer to the installation menu of
your device.
Upgrading the Boot ROM Program Through Command Lines
Follow these steps to upgrade the Boot ROM program:

1) Copy the Boot ROM program to the root directory of the device's storage medium using FTP or
TFTP.
2) Use a command to specify the Boot ROM program for the next boot.
3) Reboot the device to make the specified Boot ROM program take effect.
Since the Boot ROM programs of member devices vary with devices, users are easily confused to
make mistakes when upgrading the Boot ROM. With the validity check function enabled, the device
can strictly check the Boot ROM upgrade files for correctness and the version configuration
information to ensure a successful upgrade.
Follow these steps to upgrade the Boot ROM program:

Optional
Enable the validity check
bootrom-update By default, the validity check
function when upgrading the
security-check enable function is enabled at the time
Boot ROM
of upgrading Boot ROM.
Return to user view quit
Upgrade the Boot ROM bootrom update file file-url Required

program on member devices slot slot-number-list Available in user view.
To execute the bootrom command successfully, you must save the Boot ROM file under the root
directory of the storage media on a member device.
Upgrading the Boot File Through Command Lines
Follow the steps to upgrade the boot file:

1) Save the boot file to the root directory of the master device's storage medium using FTP, TFTP, or
other approaches.
2) Copy the new boot file to the root directory of the storage medium of a slave.
3) Use commands to specify the boot file for the next boot of the master and slave respectively.
4) Reboot the device to make the new boot file take effect.
10-5

When multiple Boot ROM files are available on the storage media, you can specify a file for the next
device boot by executing the following command. A main boot file is used to boot a device and a
backup boot file is used to boot a device only when a main boot file is unavailable.
Follow the step below to upgrade the boot file:
Specify a boot file for the next boot-loader file file-url slot { all | Required
boot of a member device slot-number } { main | backup } Available in user view.
z To execute the boot-loader command successfully, you must save the file for the next device
boot under the root directory of the storage media on a member device.
z The names of the files for the next boot of the master and slaves may be different, but the versions
of the files must be the same; otherwise, a slave will reboot by using the master's boot file and join
the IRF again.
Disabling Boot ROM Access

By default, you can press Ctrl+B to enter the Boot ROM menu to configure the Boot ROM. However,
this may bring security problems to the device. Therefore, the device provides the function of disabling
the Boot ROM access to enhance security of the device. After this function is configured, no matter
whether you press Ctrl+B or not, the system does not enter the Boot ROM menu, but enters the
command line configuration interface directly.
In addition, you need to set the Boot ROM access password when you enter the Boot ROM menu for
the first time to protect the Boot ROM against operations of illegal users.
You can use the display startup command to view the status of the Boot ROM access function. For
the detailed description of the display startup command, refer to File System Management in the
System Volume.
Follow the step below to disable Boot ROM access:

Required
undo startup
Disable Boot ROM access By default, Boot ROM access is enabled.
bootrom-access enable
Configuring a Detection Interval

When detecting an exception on a port, the operation, administration and maintenance (OAM) module
will automatically shut down the port. The device will detect the status of the port when a detection
interval elapses. If the port is still shut down, the device will recover it.
Follow these steps to configure a detection interval:
10-6

Optional
Configure a detection interval shutdown-interval time The detection interval is 30
seconds by default.
Clearing the 16-bit Interface Indexes Not Used in the Current

System
In practical networks, the network management software requires the device to provide a uniform,
stable 16-bit interface index. That is, a one-to-one relationship should be kept between the interface
name and the interface index in the same device.
For the purpose of the stability of an interface index, the system will save the 16-bit interface index
when a board or logical interface is removed.
If you repeatedly insert and remove different subboards to create or delete a large number of logical
interfaces, the interface indexes will be used up, which will result in interface creation failures. To avoid
such a case, you can clear all 16-bit interface indexes saved but not used in the current system in user
view.
After the above operation,
z For a re-created interface, the new interface index may not be consistent with the original one.
z For existing interfaces, their interface indexes remain unchanged.
Follow these steps to clear the 16-bit interface indexes not used in the current system:

Clear the 16-bit interface
indexes saved but not in use in Required
reset unused porttag
the current systems of all Available in user view
member devices
A confirmation is required when you execute this command. If you fail to make a confirmation within 30
seconds or enter N to cancel the operation, the command will not be executed.
Identifying and Diagnosing Pluggable Transceivers

Introduction to pluggable transceivers
At present, four types of pluggable transceivers are commonly used, as shown in Table 10-1. They can
be further divided into optical transceivers and electrical transceivers based on transmission medium.
10-7

Table 10-1 Commonly used pluggable transceivers
Application Whether can be an Whether can be an

Transceiver type
environment optical transceiver electrical transceiver
Generally used for
SFP (Small 100M/1000M Ethernet
Form-factor interfaces or POS Yes Yes
Pluggable) 155M/622M/2.5G
interfaces
SFP+(Enhanced 8.5
Generally used for
and 10 Gigabit Small
10G Ethernet Yes Yes
Form-factor
interfaces
Pluggable)
Generally used for
GBIC (Gigabit
1000M Ethernet Yes Yes
Interface Converter)
interfaces
XFP (10-Gigabit small Generally used for
Form-factor 10G Ethernet Yes No
Pluggable) interfaces
XENPAK (10-Gigabit Generally used for
Ethernet Transceiver 10G Ethernet Yes Yes
Package) interfaces
Identifying pluggable transceivers
As pluggable transceivers are of various types and from different vendors, you can use the following
commands to view the key parameters of the pluggable transceivers, including transceiver type,
connector type, central wavelength of the laser sent, transfer distance and vendor name or name of
the vendor who customizes the transceivers to identify the pluggable transceivers.
Follow these steps to identify pluggable transceivers:

display transceiver interface
Display key parameters of the Available for all pluggable
[ interface-type
pluggable transceiver(s) transceivers.
interface-number ]
Display part of the electrical
display transceiver manuinfo Available for anti-spoofing
label information of the
interface [ interface-type pluggable transceiver(s)
anti-spoofing transceiver(s)
interface-number ] customized by H3C only.
customized by H3C
z You can use the Vendor Name field in the prompt information of the display transceiver
command to identify an anti-spoofing pluggable transceiver customized by H3C. If the field is H3C,
it is considered an H3C-customized pluggable transceiver.
z Electrical label information is also called permanent configuration data or archive information,
which is written to the storage component of a board during device debugging or testing. The
information includes name of the board, device serial number, and vendor name or name of the
vendor who customizes the transceiver.
10-8

Diagnosing pluggable transceivers
The system outputs alarm information for you to diagnose and troubleshoot faults of pluggable
transceivers. Optical transceivers customized by H3C also support the digital diagnosis function, which
monitors the key parameters of a transceiver, such as temperature, voltage, laser bias current, TX
power, and RX power. When these parameters are abnormal, you can take corresponding measures
to prevent transceiver faults.
Follow these steps to diagnose pluggable transceivers:

Display the current alarm display transceiver alarm
Available for all pluggable
information of the pluggable interface [ interface-type
transceivers.
transceiver(s) interface-number ]
Display the currently measured
display transceiver
value of the digital diagnosis Available for anti-spoofing
diagnosis interface
parameters of the anti-spoofing pluggable optical transceiver(s)
[ interface-type
optical transceiver(s) customized by H3C only.
interface-number ]
customized by H3C
Displaying and Maintaining Device Management Configuration

Follow these steps to display and maintain device management configuration:

Display information of the boot Available in any
display boot-loader [ slot slot-number ]
file view
Display the statistics of the display cpu-usage [ number [ offset ] Available in any
CPU usage [ verbose ] [ from-device ] ] view
Display history statistics of the display cpu-usage history [ task task-id ] Available in any
CPU usage in a chart [ slot slot-number [ cpu cpu-number ] ] view
display device [ [ shelf shelf-number ]
Display information about a Available in any
[ frame frame-number ] [ slot slot-number
board, subboard on the device view
[ subslot subslot-number ] ] | verbose ]
Display electrical label Available in any
display device manuinfo
information of the device view
Display the temperature Available in any
display environment
information of devices view
Display the operating state of Available in any
display fan [ slot slot-number [ fan-id ] ]
fans in the device view
Display the usage of the display memory [ slot slot-number [ cpu Available in any
memory of the device cpu-number ] ] view
Display the power state of a display power [ slot slot-number Available in any
device [ power-id ] ] view
Available in any
Display state of the RPS display rps [ slot slot-number [ rps-id ] ]
view
Display the reboot mode of a Available in any
display reboot-type [ slot slot-number ]
device view
Display the reboot time of a Available in any
display schedule reboot
device view
10-9

Display detailed configurations
Available in any
of the scheduled automatic display schedule job
view
execution function
Display the exception handling Available in any
display system-failure
methods view
Device Management Configuration Examples

Remote Scheduled Automatic Upgrade Configuration Example (Centralized Device)
Network requirement
z As shown in Figure 10-2, the current software version is soft-version1 for Device. Upgrade the
software version of Device to soft-version2 and configuration file to new-config at a time when
few services are processed (for example, at 3 am) through remote operations.
z The newest application soft-version2.bin and the newest configuration file new-config.cfg are
both saved under the aaa directory of the FTP server.
z The IP address of Device is 1.1.1.1/24, the IP address of the FTP server is 2.2.2.2/24, and the
FTP server is reachable.
z User can log in to Device via Telnet and a route exists between User and Device.
Figure 10-2 Network diagram for remote scheduled automatic upgrade
FTP Server
2.2.2.2/24
Internet
Telnet
FTP Client
Device
User
1.1.1.1/24
1) Configuration on the FTP server (Note that configurations may vary with different types of servers)
z Set the access parameters for the FTP client (including enabling the FTP server function, setting
the FTP username to aaa and password to hello, and setting the user to have access to the
flash:/aaa directory).
<FTP-Server> system-view
[FTP-Server] ftp server enable
[FTP-Server] local-user aaa
[FTP-Server-luser-aaa] password cipher hello
[FTP-Server-luser-aaa] service-type ftp
[FTP-Server-luser-aaa] authorization-attribute work-directory flash:/aaa
10-10

z Use text editor on the FTP server to edit batch file auto-update.txt. The following is the content of
the batch file:
return
startup saved-configuration new-config.cfg
boot-loader file soft-version2.bin main
reboot
2) Configuration on Device
# Log in to the FTP server (note that the prompt may vary with servers.)
<Device> ftp 2.2.2.2
Trying 2.2.2.2 ...
220 WFTPD 2.0 service (by Texas Imperial Software) ready for new user
User(2.2.2.2:(none)):aaa
331 Give me your password, please
Password:
230 Logged in successfully
[ftp]
# Download file auto-update.txt on the FTP server.

[ftp] ascii
[ftp] get auto-update.txt
# Download file new-config.cfg on the FTP server.

[ftp]get new-config.cfg
# Download file soft-version2.bin on the FTP server.

[ftp] binary
[ftp] get soft-version2.bin
[ftp] bye
<Device>
# Modify the extension of file auto-update.txt as .bat.

<Device> rename auto-update.txt auto-update.bat
To ensure correctness of the file, you can use the more command to view the content of the file.
# Execute the scheduled automatic execution function to enable the device to be automatically
upgraded at 3 am.
<Device> schedule job at 03:00 view system execute auto-update.bat
Info: Command execute auto-update.bat in system view will be executed at 03:00 12/11/2007(in
12 hours and 0 minutes).
Remote Scheduled Automatic Upgrade Configuration Example (Centralized IRF

Device)
Network requirement
z As shown in Figure 10-3, the current software version is soft-version1 for the IRF system.
Upgrade the software version of the IRF system to soft-version2 and configuration file to
new-config.
10-11

z The newest application soft-version2.bin and the newest configuration file new-config.cfg are
both saved under the TFTP server.
z The IP address of the IRF system is 1.1.1.1/24, the IP address of the TFTP server is 2.2.2.2/24,
and the TFTP server is reachable.
Figure 10-3 Network diagram for remote scheduled automatic upgrade
1) Configuration on the TFTP server (Note that configurations may vary with different types of
servers)
Obtain the boot file and configuration file through legitimate channels, such as the official website of
3COM, agents, and technical staff. Save these files under the working path of the TFTP server for the
access of the TFTP clients.
2) Configuration on the IRF members
# Download file new-config.cfg on the TFTP server to Master (Note that configurations may vary with
different types of servers).
<IRF> tftp 2.2.2.2 get new-config.cfg
..
File will be transferred in binary mode
Downloading file from remote TFTP server, please wait.....
TFTP: 917 bytes received in 1 second(s)
File downloaded successfully.
# Download file new-config.cfg to Slave with the member ID of 2.

<IRF> tftp 2.2.2.2 get new-config.cfg slot2#flash:/new-config.cfg
# Download file soft-version2.bin on the TFTP server to Master and Slave.

<IRF> tftp 2.2.2.2 get soft-version2.bin
...
File will be transferred in binary mode
Downloading file from remote TFTP server, please wait............
TFTP: 10058752 bytes received in 141 second(s)
File downloaded successfully.

<IRF> tftp 2.2.2.2 get soft-version2.bin slot2#flash:/soft-version2.bin
# Specify file new-config.cfg as the configuration file for the next boot for all members.
<IRF> startup saved-configuration new-config.cfg main
10-12

Please wait ...
Setting the master board ...
... Done!
Setting the slave board ...
Slot 2:
Set next configuration file successfully
# Specify file soft-version2.bin as the boot file for the next boot for all members.
<IRF> boot-loader file soft-version2.bin slot all main
This command will set the boot file of the specified board. Continue? [Y/N]:y
The specified file will be used as the main boot file at the next reboot on slot 1!
# Reboot the device. The software version is upgraded now.

<IRF> reboot
10-13

11 File System Management Configuration
When configuring file system management, go to these sections for information you are interested in:
z File System Management
z Configuration File Management
z Displaying and Maintaining Device Configuration
File System Management

z File System Overview
z Filename Formats
z Directory Operations
z File Operations
z Batch Operations
z Storage Medium Operations
z Setting File System Prompt Modes
z File System Operations Example
File System Overview
A major function of the file system is to manage storage media. It allows you to perform operations
such as directory create and delete, and file copy and display. If an operation, delete or overwrite for
example, causes problems such as data loss or corruption, the file system will prompt you to confirm
the operation by default.
Depending on the managed object, file system operations fall into Directory Operations, File
Operations, Batch Operations, Storage Medium Operations, and Setting File System Prompt Modes.
Filename Formats
When you specify a file, you must enter the filename in one of the following formats.
Filename formats:
Format Description Length Example

a.txt: Indicates that a file
named a.txt is under the
current working directory. If the
current working directory is on
Specifies a file under the 1 to 91
file-name the master, a.txt represents file
current working directory. characters
a.txt on the master; if the
current working directory is on
a slave, a.txt represents file
a.txt on the slave.
11-1

Format Description Length Example
Specifies a file in the specified
folder under the current
test/a.txt: Indicates that a file
working directory. path
1 to 135 named a.txt is in the test folder
path/file-name represents the folder name.
characters under the current working
You can specify multiple
directory.
folders, indicating a file under a
multi-level folder.
Specifies a file in the specified
storage medium on the device. flash:/test/a.txt: Indicates that a
drive represents the storage file named a.txt is in the test
medium name. The S4510G folder under the root directory
series switches use flashes as of the flash memory on the
their storage media. The master.
drive:/[path]/file- storage medium on the master 1 to 135
name is flash; the storage medium on characters To read and write the a.txt file
a slave is slot2#flash, where 2 under the root directory of the
represents the member ID of flash on a slave (with the
the slave. You can use the member ID 2), input
display irf command to view slot2#flash:/a.txt for the
the correspondence between a filename.
device and its member ID.
For the S4510G series, when you specify a configuration file (.cfg file), startup file (.bin file), or Boot
ROM file by inputting its name in the format of drive:/[path]/file-name), the total length of the name
cannot exceed 63 characters.
Directory Operations
Directory operations include creating/removing a directory, displaying the current working directory,
displaying the specified directory or file information, and so on.
Displaying directory information
Display directory or file Required

dir [ /all ] [ file-url ]
information Available in user view
Displaying the current working directory
Display the current working Required

pwd
directory Available in user view
11-2

Changing the current working directory
Change the current working Required

cd { directory | .. | / }
directory Available in user view
Creating a directory

Required
Create a directory mkdir directory
Removing a directory

Required
Remove a directory rmdir directory
z The directory to be removed must be empty, meaning that before you remove a directory, you
must delete all the files and the subdirectory under this directory. For file deletion, refer to the
delete command; for subdirectory deletion, refer to the rmdir command.
z After you execute the rmdir command successfully, the files in the recycle bin under the directory
will be automatically deleted.
File Operations
File operations include displaying the specified directory or file information; displaying file contents;
renaming, copying, moving, removing, restoring, and deleting files.
You can create a file by copying, downloading or using the save command.
11-3

Displaying file information
Display file or directory Required

dir [ /all ] [ file-url ]
information Available in user view
Displaying the contents of a file

Required
Display the contents of
more file-url Currently only a .txt file can be displayed.
a file
Renaming a file
rename fileurl-source Required

Rename a file
fileurl-dest Available in user view
Copying a file

Required
Copy a file copy fileurl-source fileurl-dest
Moving a file

Required
Move a file move fileurl-source fileurl-dest
Deleting a file
Move a file to the recycle bin or Required

delete [ /unreserved ] file-url
delete it permanently Available in user view
11-4

z The files in the recycle bin still occupy storage space. To delete a file in the recycle bin, you need
to execute the reset recycle-bin command in the directory that the file originally belongs. It is
recommended to empty the recycle bin timely with the reset recycle-bin command to save
storage space.
z The delete /unreserved file-url command deletes a file permanently and the action cannot be
undone. Execution of this command equals that you execute the delete file-url command and then
the reset recycle-bin command in the same directory.
Restoring a file from the recycle bin
Restore a file from the recycle Required

undelete file-url
bin Available in user view
Emptying the recycle bin

Optional
If the original directory of the
Enter the original working
file to be deleted is not the
directory of the file to be cd { directory | .. | / }
current working directory, this
deleted
command is required.
Delete the file under the Required
current directory and in the reset recycle-bin [ /force ]
recycle bin Available in user view
Batch Operations
A batch file is a set of executable commands. Executing a batch file equals executing the commands in
the batch file one by one.
The following steps are recommended to execute a batch file:
1) Edit the batch file on your PC.
2) Download the batch file to the device. If the suffix of the file is not .bat, use the rename command
to change the suffix to .bat.
3) Execute the batch file.
Follow the steps below to execute a batch file:

Execute a batch file execute filename Required
11-5

Execution of a batch file does not guarantee the successful execution of every command in the batch
file. If a command has error settings or the conditions for executing the command are not satisfied, the
system will skip the command to the next one.
Storage Medium Operations
Managing space of the storage medium
When some space of a storage medium becomes inaccessible due to abnormal operations for
example, you can use the fixdisk command to restore the space of the storage medium. The
execution of the format command will format the storage medium, and all the data on the storage
medium will be deleted.
Use the following commands to manage the storage medium space:
Restore the space of a storage Optional

fixdisk device
medium Available in user view
Optional
Format a storage medium format device
z When you format a storage medium, all the files stored on it are erased and cannot be restored. In
particular, if there is a startup configuration file on the storage medium, formatting the storage
medium results in loss of the startup configuration file.
z You can execute the fixdisk command for the storage medium on the master, but you cannot
execute the command for a storage medium on the slave.
Setting File System Prompt Modes
The file system provides the following two prompt modes:

z alert: In this mode, the system warns you about operations that may bring undesirable
consequences such as file corruption or data loss.
z quiet: In this mode, the system does not prompt confirmation for any operation.
11-6

To prevent undesirable consequence resulting from misoperations, the alert mode is preferred.

Set the operation prompt mode Optional

file prompt { alert | quiet }
of the file system The default is alert.
File System Operations Example
# Display the files and the subdirectories under the current directory.
<Sysname> dir
Directory of flash:/
0 -rw- 10197108 Jul 17 2007 18:30:04 4510G.bin
1 -rw- 478164 Apr 26 2007 14:40:07 4510G_505.btm
2 -rw- 1586 Aug 24 2007 12:00:03 startup.cfg
3 -rw- 11053555 Aug 22 2007 17:25:16 4510GD.bin
4 drw- - Apr 26 2007 19:58:11 test
31496 KB total (9943 KB free)
# Create a new folder called mytest under the test directory.

<Sysname> cd test
<Sysname> mkdir mytest
%Created dir flash:/test/mytest.
# Display the current working directory.

<Sysname> pwd
flash:/test
# Display the files and the subdirectories under the test directory.
<Sysname> dir
Directory of flash:/test/
0 drw- - Apr 26 2007 19:58:39 mytest
# Return to the upper directory.

<Sysname> cd ..
# Display the current working directory.

<Sysname> pwd
flash:
Configuration File Management

The device provides the configuration file management function with a user-friendly command line
interface (CLI) for you to manage the configuration files conveniently.
z Configuration File Overview
11-7

z Saving the Current Configuration
z Setting Configuration Rollback
z Specifying a Startup Configuration File for the Next System Startup
z Backing Up the Startup Configuration File
z Deleting the Startup Configuration File for the Next Startup
z Restoring the Startup Configuration File
z Displaying and Maintaining Device Configuration
Configuration File Overview
A configuration file saves the device configurations in command lines in text format. You can view
configuration information conveniently through configuration files.
Types of configuration
The configuration of a device falls into two types:

z Startup configuration, a configuration file used for initialization when the device boots. If this file
does not exist, the system boots using null configuration, that is, using the default parameters.
z Current configuration, which refers to the currently running configuration of the system. The
current configuration may include the startup configuration if the startup configuration is not
modified during system operation, and it also includes the new configuration added during the
system operation. The current configuration is stored in the temporary storage medium of the
device, and will be removed when the device reboots if not saved.
Format of a configuration file
A configuration file is saved as a text file. It:

z Saves configuration in the form of commands.
z Saves only non-default configuration settings.
z Lists commands in sections by views, usually in the order of system view, interface view, and
routing protocol view. Sections are separated with one or multiple blank lines or comment lines
that start with a pound sign #.
z Ends with a return.
Coexistence of multiple configuration files
Multiple configuration files can be stored on a storage medium of a device. You can save the
configuration used in different environments as different configuration files. In this case, when the
device moves between these networking environments, you just need to specify the corresponding
configuration file as the startup configuration file for the next boot of the device and restart the device,
so that the device can adapt to the network rapidly, saving the configuration workload.
A device boots using only one configuration file. However, you can specify two startup configuration
files, main and backup startup configuration file, for the next startup of the device as needed and when
the device supports this feature. When the device boots, the system uses the main startup
configuration file, and if the main startup configuration file is corrupted or lost, the system will use the
backup startup configuration file for device boot and configuration. The devices supporting the
configuration of the main and backup startup configuration files, compared with the devices that do not
support this feature, are more secure and reliable.
11-8

At a moment, there are at most one main startup configuration file and one backup startup
configuration file. You can specify neither of the two files (displayed as NULL), or specify the two files
as the same configuration file.
You can specify the main and backup startup configuration files for the next boot of the device in the
following two methods:
z Specify them when saving the current configuration. For detailed configuration, refer to Saving the
Current Configuration.
z Specify them when specifying the startup configuration file for the next system startup. For
detailed configuration, refer to Specifying a Startup Configuration File for the Next System Startup.
Startup with the configuration file
The device takes the following steps when it boots:

1) If the main startup configuration file exists, the device initializes with this configuration file.
2) If the main startup configuration file does not exist but the backup startup configuration file exists,
the device initializes with the backup startup configuration file.
3) If neither the main nor the backup startup configuration file exists, the device will boot with null
configuration (boot with null configuration means to boot with the factory default configuration).
Saving the Current Configuration
Introduction
You can modify the current configuration on your device using command line interface. However, the
current configuration is temporary. To make the modified configuration take effect at the next boot of
the device, you must save the current configuration to the startup configuration file before the device
reboots.
Complete these tasks to save the current configuration:
Task Remarks
Enabling configuration file auto-save Optional
Modes in saving the configuration Required
Enabling configuration file auto-save
z After the configuration file auto-save function is enabled, when you save the current configuration
by executing the save [ safely ] [ backup | main ] command or executing the save filename all
command and then pressing Enter, the master and a slave will automatically save the current
configuration to the specified configuration file, and use the file as the configuration file for the next
startup, thus keeping the consistency of the configuration files on the master and the slave.
z If the configuration file auto-save function is not enabled, when you save the current configuration
by executing the save [ safely ] [ backup | main ] command or executing the save filename all
command and then pressing Enter, only the master will automatically save the current
configuration to the specified configuration file, and use the file as the configuration file for the next
startup; the slaves will neither save the configuration file nor configure the file for the next startup.
Follow these steps to configure the configuration file auto-save function:
11-9

Enable configuration file Optional

slave auto-update config
auto-save Enabled by default.
Modes in saving the configuration
z Fast saving mode. This is the mode when you use the save command without the safely keyword.
The mode saves the file more quickly but is likely to lose the existing configuration file if the device
reboots or the power fails during the process.
z Safe mode. This is the mode when you use the save command with the safely keyword. The
mode saves the file more slowly but can retain the configuration file in the device even if the
device reboots or the power fails during the process.
The fast saving mode is suitable for environments where power supply is stable. The safe mode,
however, is preferred in environments where stable power supply is unavailable or remote
maintenance is involved.

Save the current configuration to the specified
save file-url [ all | slot
file, but the configuration file will not be set as
slot-number ] Required
the file for the next startup
Use either
Save the current configuration to the root command
directories of the storage media of all the
save [ safely ] [ backup | Available in any
member devices and specify the file as the
main ] view
startup configuration file that will be used at
the next system startup
z The configuration file must be with extension .cfg.

z Whether the save [ safely ] [ backup | main ] command or the save filename all command+Enter
takes effect on all the member devices or on the master only depends on whether the
configuration file auto-save function is enabled. For the configuration file auto-save function, refer
to Enabling configuration file auto-save. (centralized IRF device)
z The execution of the save [ safely ] and save [ safely ] main commands has the same effect: The
system will save the current configuration and specify the configuration file as the main startup
configuration file to be used at the next system startup.
z During the execution of the save [ safely ] [ backup | main ] command, the startup configuration
file to be used at the next system startup may be lost if the device reboots or the power supply fails.
In this case, the device will boot with the null configuration, and after the device reboots, you need
to re-specify a startup configuration file for the next system startup (refer to Specifying a Startup
Configuration File for the Next System Startup).
11-10

Setting Configuration Rollback
Configuration rollback allows you to revert to a previous configuration state based on a specified
configuration file. The specified configuration file must be a valid .cfg file, namely, it can be generated
by using either the backup function (manually or automatically) or the save command, and even the
compatible configuration file of another device. You are recommended to use the configuration file that
is generated by using the backup function (manually or automatically). Configuration rollback is applied
in the following situations:
z The current configurations are wrong; and there are too many wrong configurations to locate or to
correct one by one. Rolling back the current configuration to a correct one is needed.
z The application environment has changed and the device has to run in a configuration state based
on a previous configuration file without being rebooted.
Set configuration rollback following these steps:
1) Specify the filename prefix and path for saving the current configuration.
2) Save the current running configuration with the specified filename (filename prefix + serial number)
to the specified path. The current running configuration can be saved in two ways: the system
saves the current running configuration at a specified interval; or you can save the current running
configuration as needed.
3) Roll back the current running configuration to the configuration state based on a saved
configuration file. When the related command is entered, the system first compares and then
processes the differences between the current running configuration and the specified
replacement configuration file:
z The rollback operation does not execute the commands that are the same in the replacement
configuration file and in the current configuration file.
z The rollback operation removes the commands only present in the current configuration file but
not in the replacement configuration file; namely, the corresponding undo form commands are
executed.
z The rollback operation executes the commands only present in the replacement configuration file
but not in the current configuration file.
z The rollback operation removes the commands that are different in the replacement configuration
file and in the current configuration file, and then executes them according to the replacement
configuration file.
The current running configuration is only saved to the master, and only the configuration on the master
can be rolled back. However, the related configuration will be synchronized to the slaves to ensure the
rollback of the configuration after the master is changed.
11-11

Configuration task list
Complete these tasks to configure the configuration rollback:
Task Remarks
Configuring parameters for saving the current running configuration Required
Saving the current running configuration automatically Required
Saving the current running configuration manually Use at least one approach
Setting configuration rollback Required
Configuring parameters for saving the current running configuration
Before the current running configuration is saved manually or automatically, the file path and filename
prefix must be configured. After that, the system saves the current running configuration with the
specified filename (filename prefix_serial number.cfg) to the specified path. The filename of a saved
configuration file is like 20080620archive_1.cfg, or 20080620archive_2.cfg. The saved configuration
files are numbered automatically, from 1 to 1,000 (with increment of 1). If the serial number reaches
1,000, it restarts from 1. If you change the path or filename prefix, or reboot the device, the saved file
serial number restarts from 1, and the system recounts the saved configuration files. If you change the
path of the saved configuration files, the files in the original path become common configuration files,
and are not processed as saved configuration files.
The number of saved configuration files has an upper limit. After the maximum number of files is saved,
the system deletes the oldest files when the next configuration file is saved.
Follow these steps to configure parameters for saving the current running configuration:

Required
archive configuration By default, the path and
Configure the path and filename of the saved
location directory
filename prefix of a saved configuration file are not
filename-prefix
configuration file configured, and the system
filename-prefix
does not save the configuration
file at a specified interval.
archive configuration max
configuration files that can be
file-number The default number is 5.
saved
11-12

z The saving and rollback operations are executed only on the master. To make the configuration
rollback take effect on the new master after an active/standby switchover, execute the archive
configuration location command to specify the path and filename prefix of the saved
configuration file on both the master and slaves. Therefore, before the execution of this command,
ensure that the specified path is available on both the master and the slaves, and the path cannot
include any member ID.
z If the undo archive configuration location command is executed, the current running
configuration can neither be saved manually nor automatically, and the configuration by executing
the archive configuration interval and archive configuration max commands restores to the
default, meanwhile, the saved configuration files are cleared.
z The value of the file-number argument is determined by the memory space. You are
recommended to set a comparatively small value for the file-number argument if the available
memory space is small.
Saving the current running configuration automatically
You can configure the system to save the current running configuration at a specified interval, and use
the display archive configuration command to view the filenames and save time of the saved
configuration files, so as to roll back the current configuration to a previous configuration state.
Configure an automatic saving interval according to the storage medium performance and the
frequency of configuration modification:
z If the configuration of the device does not change frequently, you are recommended to save the
current running configuration manually as needed
z Because the S4510G uses a low-speed storage medium, you are recommended either to save
the current running configuration manually, or to configure automatic saving with an interval longer
than 1,440 minutes (24 hours).
Follow these steps to automatically save the current running configuration:

Enable the automatic saving of the Optional

archive configuration
current running configuration, and set
interval minutes Disabled by default
the interval
The path and filename prefix of a saved configuration file must be specified before you configure the
automatic saving period.
11-13

Saving the current running configuration manually
Automatic saving of the current running configuration occupies system resources, and frequent saving
greatly affects system performance. Therefore, if the system configuration does not change frequently,
you are recommended to disable the automatic saving of the current running configuration and save it
manually.
If the modification to the configuration fails, or is complicated, you can save the current running
configuration manually before you modify it. Therefore, if it really fails, the device can revert to the
configuration state before the modification.
Follow the step below to save the current running configuration manually:
Save the current running Required

archive configuration
configuration manually Available in user view
The path and filename prefix of a saved configuration file must be specified before you save the
current running configuration manually; otherwise, the operation fails.
Setting configuration rollback
Follow these steps to set configuration rollback:

Set configuration rollback configuration replace file filename Required
Configuration rollback may fail if one of the following situations is present (if a command cannot be
rolled back, the system skips it and processes the next one):
z The complete undo form of a command is not supported, namely, you cannot get the actual undo
form of the command by simply putting the keyword undo in front of the command, so the
complete undo form of the command cannot be recognized by the device.
z The configuration cannot be removed, such as hardware-related commands
z Commands in different views are dependent on each other
z If the replacement configuration file is not a complete file generated by using the save or archive
configuration command, or the file is copied from a different type of device, the configuration
cannot be rolled back. Ensure that the replacement configuration file is correct and compatible
with the current device.
11-14

Specifying a Startup Configuration File for the Next System Startup
A startup configuration file is the configuration file to be used at the next system startup. You can
specify a configuration file as the startup configuration file to be used at the next system startup in the
following two ways:
z Use the save command. If you save the current configuration to the specified configuration file in
the interactive mode, the system automatically sets the file as the main startup configuration file to
be used at the next system startup.
z Use the command dedicated to specify a startup configuration file, which is described in the
following table:
Follow the step below to specify a configuration file as the startup configuration file for the next system
startup:

Specify a startup configuration file Required
startup saved-configuration cfgfile
for the next system startup of all
[ backup | main ] Available in user view
the member devices
A configuration file must use .cfg as its extension name and the startup configuration file must be
saved under the root directory of the storage medium.
Backing Up the Startup Configuration File
The backup function allows you to copy the startup configuration file to be used at the next system
startup from the device to the TFTP server for backup.
The backup operation backs up the startup configuration file to the TFTP server.
Follow the step below to back up the startup configuration file to be used at the next system startup:
Back up the configuration file to be Required

backup startup-configuration to
used at the next system startup to Available in user
dest-addr [dest- filename ]
the specified TFTP server view
11-15

Before the backup operation, you should:
z Ensure that the server is reachable, the server is enabled with TFTP service, and the client has
permission to read and write.
z Use the display startup command (in user view) to see whether you have set the startup
configuration file, and use the dir command to see whether this file exists. If the file is set as NULL
or does not exist, the backup operation will fail.
Deleting the Startup Configuration File for the Next Startup
You can delete the startup configuration file to be used at the next system startup using commands. On
a device that has the main and backup startup configuration files, you can choose to delete either the
main or backup startup configuration file. However, in the case that the main and backup startup
configuration files are the same, if you perform the delete operation for once, the system will not delete
the configuration file but only set the corresponding startup configuration file (main or backup,
according to which one you specified in the command) to NULL.
You may need to delete the startup configuration file for the next startup for one of these reasons:
z After you upgrade system software, the existing configuration file does not match the new system
software.
z The configuration file is corrupted (often caused by loading a wrong configuration file).
After the startup configuration file is deleted, the system will use the null configuration when the device
reboots.
Follow the step below to delete the startup configuration file for the next startup:

Delete the startup configuration Required
reset saved-configuration
file for the next startup from the
[ backup | main ] Available in user view
storage medium
This command will permanently delete the configuration file from all the member devices. Use it with
caution.
Restoring the Startup Configuration File
z The restore function allows you to copy a configuration file from TFTP server to the root directory
of the storage media of all the member devices and specify the file as the startup configuration file
to be used at the next system startup.
Follow the step below to restore the startup configuration file to be used at the next system startup:
11-16

Restore the startup Required
restore startup-configuration
configuration file to be used at
from src-addr src-filename Available in user view
the next system startup
z The restore operation restores the main startup configuration file.

z Before restoring a configuration file, you should ensure that the server is reachable, the server is
enabled with TFTP service, and the client has read and write permission.
z After the command is successfully executed, you can use the display startup command (in user
view) to verify that the filename of the configuration file to be used at the next system startup is the
same with that specified by the filename argument, and use the dir command to verify that the
restored startup configuration file exists.
Displaying and Maintaining Device Configuration

Display the information about Available in any
display archive configuration
configuration rollback view
Display the currently running
display saved-configuration Available in any
configuration file saved on the
[ by-linenum ] view
storage medium of the device
Display the configuration files
Available in any
for this and the next system display startup
view
startup
Display the validated Available in any
display this [ by-linenum ]
configuration in current view view
[ [ configuration [ configuration ] |
Display the current Available in any
interface [ interface-type ]
configuration view
[ interface-number ] ] [ by-linenum ] [ |
{ begin | include | exclude } text ] ]
For detailed description of the display this and display current-configuration commands, refer to
Basic System Configuration Commands in the System Volume.
11-17

12 FTP Configuration
When configuring FTP, go to these sections for information you are interested in:
z FTP Overview
z Configuring the FTP Client
z Configuring the FTP Server
z Displaying and Maintaining FTP
FTP Overview
Introduction to FTP
The File Transfer Protocol (FTP) is an application layer protocol for sharing files between server and
client over a TCP/IP network.
FTP uses TCP ports 20 and 21 for file transfer. Port 20 is used to transmit data, and port 21 to transmit
control commands. Refer to RFC 959 for details of FTP basic operation.
FTP transfers files in two modes:
z Binary mode for program file transmission, like files with the suffixes .app, .bin, or .btm.
z ASCII mode for text file transmission, like files with the suffixes .txt, .bat, or .cfg.
Operation of FTP
FTP adopts the client/server model. Your device can function either as the client or as the server (as
shown in Figure 12-1).
z When the device serves as the FTP client, the user first connects to the device from a PC through
Telnet or an emulation program, and then executes the ftp command to establish a connection to
the remote FTP server and gain access to the files on the server.
z When the device serves as the FTP server, FTP clients (users running the FTP client program) log
in to the device to access files on the device (the administrator must configure the IP address of
the device as the FTP server IP address before user login).
Figure 12-1 Network diagram for FTP
When the device serves as the FTP client, you need to perform the following configuration:
12-1

Table 12-1 Configuration when the device serves as the FTP client
Device Configuration Remarks

If the remote FTP server supports
anonymous FTP, the device can
Use the ftp command to establish the log in to it directly; if not, the
Device (FTP client)
connection to the remote FTP server device must obtain the FTP
username and password first to
log in to the remote FTP server.
Enable FTP server on the PC, and
PC (FTP server) configure the username, password,
user privilege level, and so on.
When the device serves as the FTP server, you need to perform the following configuration:
Table 12-2 Configuration when the device serves as the FTP server

You can use the display
Enable the FTP server function ftp-server command to view the
FTP server configuration on the
device.
Configure the username,
password, authorized working
directory for an FTP user.
Device (FTP server) The device does not support
Configure authentication and anonymous FTP for security
authorization reasons. Therefore, you must use
a valid username and password.
By default, authenticated users
can access the root directory of
the device.
Configure the FTP server operating Parameters such as the FTP
parameters connection timeout time
You can log in to the FTP server
Use the FTP client program to log in to
PC (FTP client) only after you input the correct
the FTP server.
FTP username and password.
z The FTP function is available when a reachable route exists between the FTP server and the FTP
client.
z When you use IE to log in to the device serving as the FTP server, part of the FTP functions is not
available. This is because multiple connections are established during the login process but the
device supports only one connection at a time.
12-2

Configuring the FTP Client
Establishing an FTP Connection
To access an FTP server, an FTP client must establish a connection with the FTP server. Two ways are
available to establish a connection: using the ftp command to establish the connection directly; using
the open command in FTP client view.
Source address binding means to configure an IP address on a stable interface such as a loopback
interface or Dialer interface, and then use this IP address as the source IP address of an FTP
connection. The source address binding function simplifies the configuration of ACL rules and security
policies. You just need to specify the source or destination address argument in an ACL rule as this
address to filter inbound and outbound packets on the device, ignoring the difference between
interface IP addresses as well as the affect of interface statuses. You can configure the source address
by configuring the source interface or source IP address. The primary IP address configured on the
source interface is the source address of the transmitted packets. The source address of the
transmitted packets is selected following these rules:
z If no source address is specified, the FTP client uses the IP address of the interface determined
by the matched route as the source IP address to communicate with an FTP server.
z If the source address is specified with the ftp client source or ftp command, this source address
is used to communicate with an FTP server.
z If you use the ftp client source command and the ftp command to specify a source address
respectively, the source address specified with the ftp command is used to communicate with an
FTP server.
The source address specified with the ftp client source command is valid for all FTP connections and
the source address specified with the ftp command is valid only for the current FTP connection.
Follow these steps to establish an FTP connection (In IPv4 networking):

Optional
A device uses the IP address
ftp client source { interface of the interface determined by
Configure the source address
interface-type interface-number the matched route as the
of the FTP client
| ip source-ip-address } source IP address to
communicate with the FTP
server by default.
ftp [ server-address
[ service-port ] [ source
Log in to the remote FTP
{ interface interface-type Use either approach.
server directly in user view
interface-number | ip The ftp command is available
source-ip-address } ] ] in user view; and the open
ftp command is available in FTP
Log in to the remote FTP client view.
server indirectly in FTP client open server-address
view [ service-port ]
12-3

z If no primary IP address is configured on the specified source interface, no FTP connection can be
established.
z If you use the ftp client source command to first configure the source interface and then the
source IP address of the transmitted packets, the newly configured source IP address will take
effect instead of the current source interface, and vice versa.
Follow these steps to establish an FTP connection (In IPv6 networking):

ftp ipv6 [ server-address
Log in to the remote FTP [ service-port ] [ source ipv6
server directly in user view source-ipv6-address ] [ -i
interface-type interface-number ] ] The ftp ipv6 command
is available in user view;
ftp ipv6 and the open ipv6
Log in to the remote FTP command is available in
server indirectly in FTP client open ipv6 server-address FTP client view.
view [ service-port ] [ -i interface-type
interface-number ]
Configuring the FTP Client
After a device serving as the FTP client has established a connection with the FTP server (For how to
establish an FTP connection, refer to Establishing an FTP Connection.), you can perform the following
operations in the authorized directories of the FTP server:

Display help information of FTP-related
remotehelp
commands supported by the remote FTP Optional
[ protocol-command ]
server
Enable information display in a detailed Optional

verbose
manner Enabled by default
Enable FTP related debugging when the Optional

debugging
device acts as the FTP client Disabled by default
Use another username to relog after

user username [ password ] Optional
logging in to the FTP server successfully
Optional
Set the file transfer mode to ASCII ascii
ASCII by default
Optional
Set the file transfer mode to binary binary
ASCII by default
Change the working path on the remote

cd directory Optional
FTP server
Exit the current directory and enter the
cdup Optional
upper level directory
12-4

View the detailed information of the
dir [ remotefile [ localfile ] ] Optional
files/directories on the FTP server
View the names of the files/directories on
ls [ remotefile [ localfile ] ] Optional
the FTP server
Download a file from the FTP server get remotefile [ localfile ] Optional
Upload a file to the FTP server put localfile [ remotefile ] Optional
View the currently accessed directory on
pwd Optional
the remote FTP server
View the working directory of the FTP
lcd Optional
client
Create a directory on the FTP server mkdir directory Optional
Optional
Set the data transfer mode to passive passive
Passive by default
Permanently delete the specified file on

delete remotefile Optional
the FTP server
Delete specified directory on the FTP
rmdir directory Optional
server
Optional
Disconnect from the FTP server without
disconnect Equal to the close
exiting the FTP client view
command
Optional
Disconnect from the FTP server without Equal to the
close
exiting the FTP client view disconnect
command
Disconnect from the FTP server and exit
bye Optional
to user view
Optional
Terminate the connection with the Available in FTP
quit
remote FTP server, and exit to user view client view, equal to
the bye command
z FTP uses two modes for file transfer: ASCII mode and binary mode.
z The Is command can only display the file/directory name, while the dir command can display
more information, such as the sizes of and date of creation of files or directories.
z The commands listed in the above table are only available for level 3 (manage level) users logging
in to the device which serves as the FTP client. However, whether the users can successfully
execute the commands depends on the FTP servers authorization.
12-5

FTP Client Configuration Example
Single Device Upgrade
z As shown in Figure 12-2, use Device as an FTP client and PC as the FTP server. Their IP
addresses are 10.2.1.1/16 and 10.1.1.1/16 respectively. An available route exists between Device
and PC.
z Device downloads a startup file from PC for device upgrade, and uploads the configuration file to
PC for backup.
z On PC, an FTP user account has been created for the FTP client, with the username being abc
and the password being pwd.
Figure 12-2 Network diagram for FTPing a startup file from an FTP server
If the available memory space of the device is not enough, use the fixdisk command to clear the
memory or use the delete /unreserved file-url command to delete the files not in use and then perform
the following operations.
# Log in to the server through FTP.

<Sysname> ftp 10.1.1.1
Trying 10.1.1.1
Connected to 10.1.1.1
User(10.1.1.1:(none)):abc
Password:
# Set the file transmission mode to binary to transmit startup file.

[ftp] binary
200 Type set to I.
# Download the startup file newest.bin from PC to Device.

[ftp] get newest.bin
# Upload the configuration file config.cfg of Device to the server for backup.
12-6

[ftp] ascii
[ftp] put config.cfg back-config.cfg
125 ASCII mode data connection already open, transfer starting for /config.cfg.
FTP: 3494 byte(s) sent in 5.646 second(s), 618.00 byte(s)/sec.
[ftp] bye
# Specify newest.bin as the main startup file to be used at the next startup.
<Sysname> boot-loader file newest.bin main
# Reboot the device, and the startup file is updated at the system reboot.
<Sysname> reboot
The startup file used for the next startup must be saved under the root directory of the storage medium.
You can copy or move a file to the root directory of the storage medium. For the details of the
boot-loader command, refer to Device Management Commands in the System Volume.
IRF System Upgrade
z As shown in Figure 12-3, use Device as an FTP client and PC as the FTP server. Their IP
and PC.
z Device downloads a startup file from PC for device upgrade, and uploads the configuration file to
PC for backup.
z On PC, an FTP user account has been created for the FTP client, with the username being abc
and the password being pwd.
Figure 12-3 Network diagram for FTPing a startup file from an FTP server
12-7

# Log in to the server through FTP.

<Sysname> ftp 10.1.1.1
Trying 10.1.1.1 ...
Password:
# Set the file transmission mode to binary to transmit startup file.

[ftp] binary
200 Type set to I.
# Download the startup file newest.bin from PC to the device.

z Download the startup file newest.bin from PC to the root directory of the storage medium on the
master.
[ftp] get newest.bin
z Download the startup file newest.bin from PC to the root directory of the storage medium of a
slave (with member ID of 2).
[ftp] get newest.bin slot2#flash:/newest.bin
# Upload the configuration file config.cfg of the device to the server for backup.
[ftp] ascii
[ftp] put config.cfg back-config.cfg
125 ASCII mode data connection already open, transfer starting for /config.cfg.
FTP: 3494 byte(s) sent in 5.646 second(s), 618.00 byte(s)/sec.
[ftp] bye
# Specify newest.bin as the main startup file to be used at the next startup for all the member devices.
<Sysname> boot-loader file newest.bin slot all main
# Reboot the device, and the startup file is updated at the system reboot.
12-8

<Sysname> reboot
Configuring the FTP Server

Configuring FTP Server Operating Parameters
The FTP server uses one of the two modes to update a file when you upload the file (use the put
command) to the FTP server:
z In fast mode, the FTP server starts writing data to the storage medium after a file is transferred to
the memory. This prevents the existing file on the FTP server from being corrupted in the event
that anomaly, power failure for example, occurs during a file transfer.
z In normal mode, the FTP server writes data to the storage medium while receiving data. This
means that any anomaly, power failure for example, during file transfer might result in file
corruption on the FTP server. This mode, however, consumes less memory space than the fast
mode.
Follow these steps to configure the FTP server:

Required
Enable the FTP server ftp server enable
Optional
Control the access to the
device from FTP clients ftp server acl acl-number By default, the access to the
through ACL device from FTP clients is not
controlled.
Optional
30 minutes by default.
Within the idle-timeout time, if
Configure the idle-timeout there is no information
ftp timeout minutes
timer interaction between the FTP
server and client, the
connection between them is
terminated.
Optional
Set the file update mode for the
ftp update { fast | normal } Normal update is used by
FTP server
default.
Quit to user view quit
12-9

Manually release the FTP Optional
connection established with the free ftp user username
specified username Available in user view
Configuring Authentication and Authorization on the FTP Server
To allow an FTP user to access certain directories on the FTP server, you need to create an account
for the user, authorizing access to the directories and associating the username and password with the
account.
The following configuration is used when the FTP server authenticates and authorizes a local FTP user.
If the FTP server needs to authenticate a remote FTP user, you need to configure authentication,
authorization and accounting (AAA) policy instead of the local user. For detailed configuration, refer to
AAA Configuration in the Security Volume.
Follow these steps to configure authentication and authorization for FTP server:

Required
Create a local user No local user exists by default, and the
and enter its view system does not support FTP
anonymous user access.
Assign a password to password { simple | cipher }
Required
the user password
Required
By default, the system does not
Assign the FTP support anonymous FTP access, and
service-type ftp does not assign any service. If the
service to the user
FTP service is assigned, the root
directory of the device is used by
default.
authorization-attribute { acl Optional
acl-number | callback-number
callback-number | idle-cut By default, the FTP/SFTP users can
Configure user access the root directory of the device,
minute | level level | user-profile
properties and the user level is 0. You can
profile-name | vlan vlan-id |
work-directory directory-name } change the default configuration by
* using this command.
12-10

z For more information about the local-user, password, service-type ftp, and
authorization-attribute commands, refer to AAA Command in the Security Volume.
z When the device serves as the FTP server, if the client is to perform the write operations (upload,
delete, create, and delete for example) on the devices file system, the FTP login users must be
level 3 users; if the client is to perform other operations, for example, read operation, the device
has no restriction on the user level of the FTP login users, that is, any level from 0 to 3 is allowed.
FTP Server Configuration Example
z As shown in Figure 12-4, use Device as an FTP server, and the PC as the FTP client. Their IP
and PC.
z PC keeps the updated startup file of the device. Use FTP to upgrade the device and back up the
configuration file.
z Set the username to ftp and the password to pwd for the FTP client to log in to the FTP server.
Figure 12-4 Smooth upgrading using the FTP server
1) Configure Device (FTP Server)

# Create an FTP user account ftp, set its password to pwd and the user privilege level to level 3 (the
manage level).
[Sysname] local-user ftp
[Sysname-luser-ftp] password simple pwd
[Sysname-luser-ftp] authorization-attribute work-directory level 3
# Authorize ftps access to the root directory of the flash.

[Sysname-luser-ftp] authorization-attribute work-directory flash:/
# Specify ftp to use FTP.

[Sysname-luser-ftp] service-type ftp
[Sysname-luser-ftp] quit
# Enable FTP server.

[Sysname] ftp server enable
[Sysname] quit
12-11

# Check files on your device. Remove those redundant to ensure adequate space for the startup file to
be uploaded.
<Sysname> dir
0 -rw- 10471471 Sep 18 2008 02:45:15 4510G-d501.bin

1 -rw- 9989823 Jul 14 2008 19:30:46 4510G_b57.bin
2 -rw- 6 Apr 26 2000 12:04:33 patchstate
3 -rw- 2337 Apr 26 2000 14:18:45 config.cfg
4 drw- - Apr 26 2000 13:10:56 test
5 -rw- 2337 Apr 26 2000 13:47:32 archive_1.cfg
6 -rw- 478164 Apr 26 2000 14:52:35 4510G.btm
7 -rw- 368 Apr 26 2000 12:04:04 patch_xxx.bin
8 -rw- 2337 Apr 26 2000 14:16:48 sfp.cfg
9 -rw- 2195 Apr 26 2000 14:10:41 4510GD.cfg

<Sysname> delete /unreserved flash:/sfp.cfg
2) Configure the PC (FTP Client)
# Log in to the FTP server through FTP.
c:\> ftp 1.1.1.1
331 Password required for abc.
Password:
230 User logged in.
# Download the configuration file config.cfg of the device to the PC for backup.
ftp> get config.cfg back-config.cfg
# Upload the configuration file newest.bin to Device.

ftp> put newest.bin
ftp> bye
z You can take the same steps to upgrade configuration file with FTP. When upgrading the
configuration file with FTP, put the new file under the root directory of the storage medium (For a
device that has been partitioned, the configuration file must be saved on the first partition.).
z After you finish upgrading the Boot ROM program through FTP, you must execute the bootrom
update command to upgrade the Boot ROM.
3) Upgrade Device
12-12

# Reboot the device and the startup file is updated at the system reboot.
<Sysname> reboot
IRF System Upgrade
z As shown in Figure 12-5, use Device as an FTP server, and the PC as the FTP client. An available
route exists between Device and PC.
z PC keeps the updated startup file of the device. Use FTP to upgrade the device and back up the
configuration file.
z Set the username to ftp and the password to pwd for the FTP client to log in to the FTP server.
Figure 12-5 Smooth upgrading using the FTP server
1) Configure Device (FTP Server)

# Create an FTP user account ftp, set its password to pwd and the user privilege level to level 3 (the
manage level).
[Sysname] local-user ftp
[Sysname-luser-ftp] password simple pwd
[Sysname-luser-ftp] authorization-attribute work-directory level 3
# Authorize ftps access to the root directory of the flash on the master.
[Sysname-luser-ftp] authorization-attribute work-directory flash:/
# To access the root directory of storage medium of a slave (with the member ID 2):
[Sysname-luser-ftp] authorization-attribute work-directory slot2#flash:/
# Specify ftp to use FTP.
12-13

[Sysname-luser-ftp] service-type ftp
[Sysname-luser-ftp] quit
# Enable FTP server.

[Sysname] ftp server enable
[Sysname] quit
# Check files on your device. Remove those redundant to ensure adequate space for the startup file to
be uploaded.
<Sysname> dir
0 -rw- 10471471 Sep 18 2008 02:45:15 4510G-d501.bin

1 -rw- 9989823 Jul 14 2008 19:30:46 4510G_b57.bin
2 -rw- 6 Apr 26 2000 12:04:33 patchstate
3 -rw- 2337 Apr 26 2000 14:18:45 startup.cfg
4 drw- - Apr 26 2000 13:10:56 test
5 -rw- 2337 Apr 26 2000 13:47:32 archive_1.cfg
6 -rw- 478164 Apr 26 2000 14:52:35 4510G_505.btm
7 -rw- 368 Apr 26 2000 12:04:04 patch_xxx.bin
8 -rw- 2337 Apr 26 2000 14:16:48 sfp.cfg
9 -rw- 2195 Apr 26 2000 14:10:41 4510G.cfg

2) Configure the PC (FTP Client)
# Log in to the FTP server through FTP.
c:\> ftp 1.1.1.1
331 Password required for abc.
Password:
230 User logged in.
# Download the configuration file config.cfg of the device to the PC for backup.
ftp> get config.cfg back-config.cfg
# Upload the configuration file newest.bin to the root directory of the storage medium on the master.
ftp> put newest.bin
ftp> bye
12-14

z You can take the same steps to upgrade configuration file with FTP. When upgrading the
configuration file with FTP, put the new file under the root directory of the storage medium.
z After you finish upgrading the Boot ROM program through FTP, you must execute the bootrom
update command to upgrade the Boot ROM.
3) Upgrade Device
# Copy the startup file newest.bin to the root directory of the storage medium on a slave (with the
member ID 2).
<Sysname> copy newest.bin slot2#flash:/
# Reboot the device and the startup file is updated at the system reboot.
<Sysname> reboot
Displaying and Maintaining FTP

Display the configuration of the FTP
display ftp client configuration Available in any view
client
Display the configuration of the FTP
display ftp-server Available in any view
server
Display detailed information about
display ftp-user Available in any view
logged-in FTP users
12-15

13 TFTP Configuration
When configuring TFTP, go to these sections for information you are interested in:
z TFTP Overview
z Configuring the TFTP Client
z Displaying and Maintaining the TFTP Client
z TFTP Client Configuration Example
TFTP Overview
Introduction to TFTP
The Trivial File Transfer Protocol (TFTP) provides functions similar to those provided by FTP, but it is
less complex than FTP in interactive access interface and authentication. Therefore, it is more suitable
in environments where complex interaction is not needed between client and server.
TFTP uses the UDP port 69 for data transmission. For TFTP basic operation, refer to RFC 1986.
In TFTP, file transfer is initiated by the client.
z In a normal file downloading process, the client sends a read request to the TFTP server, receives
data from the server, and then sends the acknowledgement to the server.
z In a normal file uploading process, the client sends a write request to the TFTP server, sends data
to the server, and receives the acknowledgement from the server.
TFTP transfers files in two modes:
z Binary mode for program file transmission, like files with the suffixes .app, .bin, or .btm.
z ASCII mode for text file transmission, like files with the suffixes .txt, .bat, or .cfg.
Operation of TFTP
Only the TFTP client service is available with your device at present.
Figure 13-1 TFTP configuration diagram
Before using TFTP, the administrator needs to configure IP addresses for the TFTP client and server,
and make sure that there is a reachable route between the TFTP client and server.
13-1

When the device serves as the TFTP client, you need to perform the following configuration:
Table 13-1 Configuration when the device serves as the TFTP client

z Configure the IP address and routing function, and
ensure that the route between the device and the
TFTP server is available.
Device (TFTP client)
z Use the tftp command to establish a connection to
the remote TFTP server to upload/download files
to/from the TFTP server
Enable TFTP server on the PC, and configure the
PC (TFTP server)
TFTP working directory.
Configuring the TFTP Client

When a device acts as a TFTP client, you can upload a file on the device to a TFTP server and
download a file from the TFTP server to the local device. You can use either of the following ways to
download a file:
z Normal download: The device writes the obtained file to the storage medium directly. In this way, if
you use a filename that exists in the directory, the original system file will be overwritten and if file
download fails (for example, due to network disconnection), the device cannot start up normally
because the original system file has been deleted.
z Secure download: The device saves the obtained file to its memory and does not write it to the
storage medium until the whole file is obtained. In this way, if file download fails (for example, due
to network disconnection), the device can still start up because the original system file is not
overwritten. This mode is more secure but consumes more memory.
You are recommended to use the secure mode or, if you use the normal mode, specify a filename not
existing in the current directory as the target filename when downloading the startup file or the startup
configuration file.
Source address binding means to configure an IP address on a stable interface such as a loopback
interface, and then use this IP address as the source IP address of a TFTP connection. The source
address binding function simplifies the configuration of ACL rules and security policies. You just need
to specify the source or destination address argument in an ACL rule as this address to filter inbound
and outbound packets on the device, ignoring the difference between interface IP addresses as well as
the affect of interface statuses. You can configure the source address by configuring the source
interface or source IP address. The primary IP address configured on the source interface is the
source address of the transmitted packets. The source address of the transmitted packets is selected
following these rules:
z If no source address of the TFTP client is specified, a device uses the IP address of the interface
determined by the matched route as the source IP address to communicate with a TFTP server.
z If the source address is specified with the tftp client source or tftp command, this source
address is adopted.
z If you use the tftp client source command and the tftp command to specify a source address
respectively, the source address configured with the tftp command is used to communicate with a
TFTP server.
The source address specified with the tftp client source command is valid for all TFTP connections
and the source address specified with the tftp command is valid only for the current tftp connection.
13-2

Follow these steps to configure the TFTP client:

Optional
Control the access to the TFTP
tftp-server [ ipv6 ] acl By default, the access to the
servers from the device
acl-number TFTP servers from the device
through ACL
is not controlled.
Optional
tftp client source { interface A device uses the source
Configure the source address address determined by the
interface-type interface-number
of the TFTP client matched route to communicate
| ip source-ip-address }
with the TFTP server by
default.
Return to user view quit
tftp server-address { get | put |

sget } source-filename
Download or upload a file in an [ destination-filename ] Optional
IPv4 network [ source { interface Available in user view
interface-type interface-number
| ip source-ip-address } ]
tftp ipv6 tftp-ipv6-server [ -i
Download or upload a file in an interface-type Optional
IPv6 network interface-number ] { get | put } Available in user view
source-file [ destination-file ]
z If no primary IP address is configured on the source interface, no TFTP connection can be

established.
z If you use the ftp client source command to first configure the source interface and then the
source IP address of the packets of the TFTP client, the new source IP address will overwrite the
current one, and vice versa.
Displaying and Maintaining the TFTP Client

Display the configuration of the display tftp client
TFTP client configuration
13-3

TFTP Client Configuration Example
z As shown in Figure 13-2, use a PC as the TFTP server and Device as the TFTP client. Their IP
and PC.
z Device downloads a startup file from PC for upgrading and uploads a configuration file named
config.cfg to PC for backup.
Figure 13-2 Smooth upgrading using the TFTP client function
1) Configure PC (TFTP Server), the configuration procedure is omitted.

z On the PC, enable the TFTP server
z Configure a TFTP working directory
2) Configure Device (TFTP Client)

# Download application file newest.bin from PC.

<Sysname> tftp 1.2.1.1 get newest.bin
# Upload a configuration file config.cfg to the TFTP server.

<Sysname> tftp 1.2.1.1 put config.cfg configback.cfg
# Reboot the device and the software is upgraded.

<Sysname> reboot
13-4

IRF System Upgrade
z As shown in Figure 13-3, use a PC as the TFTP server and Device as the TFTP client. Their IP
and PC.
z Device downloads a startup file from PC for upgrading and uploads a configuration file named
config.cfg to PC for backup.
Figure 13-3 Smooth upgrading using the TFTP client function
1) Configure PC (TFTP Server), the configuration procedure is omitted.

z On the PC, enable the TFTP server
z Configure a TFTP working directory
2) Configure Device (TFTP Client)

# Download application file newest.bin from PC to Device.
13-5

z Download application file newest.bin from PC to the root directory of the storage medium on the
master.
<Sysname> tftp 1.2.1.1 get newest.bin
z Download application file newest.bin from PC to the root directory of the storage medium on a
slave (with the member ID 2).
<Sysname> tftp 1.2.1.1 get newest.bin slot2#flash:/newest.bin
# Upload a configuration file config.cfg to the TFTP server.

<Sysname> tftp 1.2.1.1 put config.cfg configback.cfg
# Reboot the device and the software is upgraded.

<Sysname> reboot
13-6

14 HTTP Configuration
When configuring HTTP, go to these sections for information you are interested in:
z HTTP Overview
z Enabling the HTTP Service
z HTTP Configuration
z Associating the HTTP Service with an ACL
z Displaying and Maintaining HTTP
HTTP Overview
The Hypertext Transfer Protocol (HTTP) is used for transferring web page information across the
Internet. It is an application-level protocol in the TCP/IP protocol suite. The connection-oriented
Transport Control Protocol (TCP) is adopted on the transport layer.
Currently, HTTP/1.0 is supported on the device.
How HTTP Works
In the HTTP, the client/server mode is used for communication. The client and the server exchange
messages following these procedures:
1) A TCP connection is created between the client and the server. Typically, the port number is 80.
2) The client sends a request to the server.
3) The server processes the request and sends back a response.
4) The TCP connection is closed.
Logging In to the Device Through HTTP
You can log onto the device using the HTTP protocol with HTTP service enabled, accessing and
controlling the device with Web-based network management.
To implement security management on the device, you can use the following methods to enhance the
security of the device.
z Enable HTTP service only when necessary.
z Change the port number of the HTTP service as a port number not commonly used (8080), thus
reducing attacks from illegal users on the HTTP service.
z Associate the HTTP service with an ACL to let pass only the filtered clients.
RFC 1945: Hypertext Transfer Protocol HTTP/1.0
Enabling the HTTP Service

The device can act as the HTTP server and the users can access and control the device through the
Web function only after the HTTP service is enabled.
14-1

Follow these steps to enable the HTTP service:

Enable the HTTP service ip http enable Required
Configuring the Port Number of the HTTP Service

Configuration of the port number of the HTTP service can reduce the attacks from illegal users on the
HTTP service.
Follow these steps to configure the port number of the HTTP service:

Required
Configure the port number of
ip http port port-number By default, the port number of
the HTTP service
the HTTP service is 80.
If you execute the ip http port command for multiple times, the last configured port number is used.
Associating the HTTP Service with an ACL

By associating the HTTP service with an ACL, only the clients that pass ACL filtering are allowed to
access the device.
Follow these steps to associate the HTTP service with an ACL:

Enters system view system-view
Required
Associate the HTTP service The HTTP service is not
ip http acl acl-number
with an ACL associated with an ACL by
default.
Displaying and Maintaining HTTP

display ip http Available in any view
HTTP
14-2

15 HTTPS Configuration
When configuring HTTPS, go to these sections for information you are interested in:
z HTTPS Overview
z HTTPS Configuration Task List
z Associating the HTTPS Service with an SSL Server Policy
z Enabling the HTTPS Service
z Associating the HTTPS Service with a Certificate Attribute Access Control Policy
z Configuring the Port Number of the HTTPS Service
z Associating the HTTPS Service with an ACL
z Displaying and Maintaining HTTPS
z HTTPS Configuration Example
HTTPS Overview
The Secure HTTP (HTTPS) refers to the HTTP protocol that supports the Security Socket Layer (SSL)
protocol.
The SSL protocol of HTTPS enhances the security of the device in the following ways:
z Uses the SSL protocol to ensure the legal clients to access the device securely and prohibit the
illegal clients;
z Encrypts the data exchanged between the HTTPS client and the device to ensure the data
security and integrity, thus realizing the security management of the device;
z Defines certificate attribute-based access control policy for the device to control the access right of
the client, in order to further avoid attacks from illegal clients.
z The total number of HTTP connections and HTTPS connections on a device cannot exceed ten.
z For SSL details, refer to SSL Configuration in the Security Volume.
HTTPS Configuration Task List

Complete these tasks to configure HTTPS:

Associating the HTTPS Service with an SSL Server Policy Required
Enabling the HTTPS Service Required
Associating the HTTPS Service with a Certificate Attribute Access Control

Optional
Policy
15-1

Configuring the Port Number of the HTTPS Service Optional
Associating the HTTPS Service with an ACL Optional
Associating the HTTPS Service with an SSL Server Policy

You need to associate the HTTPS service with a created SSL server policy before enabling the HTTPS
service.
Follow these steps to associate the HTTPS service with an SSL server policy:

Associate the HTTPS service ip https ssl-server-policy Required

with an SSL server policy policy-name Not associated by default
z If the ip https ssl-server-policy command is executed repeatedly, the HTTPS service is only
associated with the last specified SSL server policy.
z When the HTTPS service is disabled, the association between the HTTPS service and the SSL
server is automatically removed. To enable it again, you need to re-associate the HTTPS service
with an SSL server policy.
z When the HTTPS service is enabled, no modification of its associated SSL server policy takes
effect.
Enabling the HTTPS Service

The device can act as the HTTPS server and users can access and control the device through the
Web function only when the HTTPS service is enabled.
Follow these steps to enable the HTTPS service:

Required
Enable the HTTPS service ip https enable
15-2

z After the HTTPS service is enabled, you can use the display ip https command to view the state
of the HTTPS service and verify the configuration.
z Enabling of the HTTPS service will trigger an SSL handshake negotiation process. During the
process, if the local certificate of the device already exists, the SSL negotiation is successfully
performed, and the HTTPS service can be started normally. If no local certificate exists, a
certificate application process will be triggered by the SSL negotiation. Since the application
process takes much time, the SSL negotiation may fail and the HTTPS service cannot be started
normally. Therefore, the ip https enable command must be executed for multiple times to ensure
normal startup of the HTTPS service.
Associating the HTTPS Service with a Certificate Attribute Access

Control Policy
Associating the HTTPS service with a configured certificate access control policy helps control the
access right of the client, thus providing the device with enhanced security.
Follow these steps to associate the HTTPS service with a certificate attribute access control policy:

Associate the HTTPS service ip https certificate Required

with a certificate attribute access-control-policy
access control policy policy-name Not associated by default.
z If the ip https certificate access-control-policy command is executed repeatedly, the HTTPS

server is only associated with the last specified certificate attribute access control policy.
z If the HTTPS service is associated with a certificate attribute access control policy, the
client-verify enable command must be configured in the SSL server policy. Otherwise, the client
cannot log onto the device.
z If the HTTPS service is associated with a certificate attribute access control policy, the latter must
contain at least one permit rule. Otherwise, no HTTPS client can log onto the device.
z For the configuration of an SSL server policy, refer to PKI Configuration in the Security Volume.
Configuring the Port Number of the HTTPS Service

Configuration of the port number of the HTTPS service can reduce the attacks from illegal users on the
HTTPS service.
Follow these steps to configure the port number of the HTTPS service:
15-3

Optional
Configure the port number of
ip https port port-number By default, the port number of
the HTTPS service
the HTTPS service is 443.
If you execute the ip https port command for multiple times, the last configured port number is used.
Associating the HTTPS Service with an ACL

Associating the HTTPS service with an ACL can filter out requests from some clients to let pass only
clients that pass the ACL filtering.
Follow these steps to associate the HTTPS service with an ACL:

Associate the HTTPS service Required

ip https acl acl-number
with an ACL Not associated by default.
Displaying and Maintaining HTTPS

display ip https Available in any view
HTTPS
HTTPS Configuration Example

z Host acts as the HTTPS client and Device acts as the HTTPS server.
z Host accesses Device through Web to control Device.
z CA (Certificate Authority) issues certificate to Device. The common name of CA is new-ca.
In this configuration example, Windows Server serves as CA and you need to install Simple Certificate
Enrollment Protocol (SCEP) component.
15-4

Figure 15-1 Network diagram for HTTPS configuration
Perform the following configurations on Device:

1) Apply for a certificate for Device
# Configure a PKI entity.
[Device] pki entity en
[Device-pki-entity-en] common-name http-server1
[Device-pki-entity-en] fqdn ssl.security.com
[Device-pki-entity-en] quit
# Configure a PKI domain.

[Device] pki domain 1
[Device-pki-domain-1] ca identifier new-ca
[Device-pki-domain-1] certificate request url http://10.1.2.2:8080/certsrv/mscep/mscep.dll
[Device-pki-domain-1] certificate request from ra
[Device-pki-domain-1] certificate request entity en
[Device-pki-domain-1] quit
# Generate a local RSA key pair.

[Device] public-key local create rsa
# Obtain a server certificate from CA.

[Device] pki retrieval-certificate ca domain 1
# Apply for a local certificate.

[Device] pki request-certificate domain 1
2) Configure an SSL server policy associated with the HTTPS service
# Configure an SSL server policy.
[Device] ssl server-policy myssl
[Device-ssl-server-policy-myssl] pki-domain 1
[Device-ssl-server-policy-myssl] client-verify enable
[Device-ssl-server-policy-myssl] quit
3) Configure a certificate access control policy
# Configure a certificate attribute group.
[Device] pki certificate attribute-group mygroup1
[Device-pki-cert-attribute-group-mygroup1] attribute 1 issuer-name dn ctn new-ca
[Device-pki-cert-attribute-group-mygroup1] quit
15-5

# Configure certificate access control policy myacp and create a control rule.
[Device] pki certificate access-control-policy myacp
[Device-pki-cert-acp-myacp] rule 1 permit mygroup1
[Device-pki-cert-acp-myacp] quit
4) Reference an SSL server policy
# Associate the HTTPS service with the SSL server policy myssl.
[Device] ip https ssl-server-policy myssl
5) Associate the HTTPS service with a certificate attribute access control policy
# Associate the HTTPS service with certificate attribute access control policy myacp.
[Device] ip https certificate access-control-policy myacp
6) Enable the HTTPS service
# Enable the HTTPS service.
[Device] ip https enable
Launch the IE explorer on Host, and enter https://10.1.1.1. You can log in to Device and control it.
z The URL of the HTTPS server starts with https://, and that of the HTTP server starts with http://.
z For details of PKI commands, refer to PKI Commands in the Security Volume.
z For details of the public-key local create rsa command, refer to Public Key Commands in the
Security Volume.
z For details of SSL commands, refer to SSL Commands in the Security Volume.
15-6

16 SNMP Configuration
When configuring SNMP, go to these sections for information you are interested in:
z SNMP Overview
z SNMP Configuration
z Configuring SNMP Logging
z SNMP Trap Configuration
z Displaying and Maintaining SNMP
z SNMP Configuration Example
z SNMP Logging Configuration Example
SNMP Overview
Simple Network Management Protocol (SNMP) offers a framework to monitor network devices through
TCP/IP protocol suite. It provides a set of basic operations in monitoring and maintaining the Internet
and has the following characteristics:
z Automatic network management: SNMP enables network administrators to search and modify
information, find and diagnose network problems, plan for network growth, and generate reports
on network nodes.
z SNMP shields the physical differences between various devices and thus realizes automatic
management of products from different manufacturers. Offering only the basic set of functions,
SNMP makes the management tasks independent of both the physical features of the managed
devices and the underlying networking technology. Thus, SNMP achieves effective management
of devices from different manufacturers, especially in small, high-speed and low cost network
environments.
SNMP Mechanism
An SNMP enabled network comprises a Network Management Station (NMS) and an agent.
z An NMS is a station that runs the SNMP client software. It offers a user friendly interface, making it
easier for network administrators to perform most network management tasks.
z An agent is a program on the device. It receives and handles requests sent from the NMS. Only
under certain circumstances, such as interface state change, will the agent inform the NMS.
An NMS manages an SNMP enabled network, whereas agents are the managed network device. They
exchange management information through the SNMP protocol.
SNMP provides the following four basic operations:
z Get operation: The NMS gets the value of one or more objects of the agent through this operation.
z Set operation: The NMS can reconfigure the value of one or more objects in the agent MIB
(Management Information Base) by means of this operation.
z Trap operation: The agent sends traps to the NMS through this operation.
z Inform operation: The NMS sends traps to other NMSs through this operation.
16-1

SNMP Protocol Version
Currently, SNMP agents support SNMPv3 and are compatible with SNMPv1 and SNMPv2c.
z SNMPv1 uses community name for authentication, which defines the relationship between an
SNMP NMS and an SNMP agent. SNMP packets with community names that did not pass the
authentication on the device will simply be discarded. A community name performs a similar role
as a key word and can be used to regulate access from NMS to agent.
z SNMPv2c uses community name for authentication. Compatible with SNMPv1, it extends the
functions of SNMPv1. SNMPv2c provides more operation modes such as GetBulk and
InformRequest; it supports more data types such as Counter64; and it provides various error
codes, thus being able to distinguish errors in more detail.
z SNMPv3 offers an authentication that is implemented with a User-Based Security Model (USM).
You can set the authentication and privacy functions. The former is used to authenticate the
validity of the sending end of the authentication packets, preventing access of illegal users; the
latter is used to encrypt packets between the NMS and agent, preventing the packets from being
intercepted. USM ensures a more secure communication between SNMP NMS and SNMP agent
by authentication with privacy, authentication without privacy, or no authentication no privacy.
Successful interaction between NMS and agent requires consistency of SNMP versions configured on
them. You can configure multiple SNMP versions for an agent to interact with different NMSs.
MIB Overview
Any managed resource can be identified as an object, which is known as the managed object.
Management Information Base (MIB) is a collection of all the managed objects. It defines a set of
characteristics associated with the managed objects, such as the object identifier (OID), access right
and data type of the objects. Each agent has its own MIB. NMS can read or write the managed objects
in the MIB. The relationship between an NMS, agent and MIB is shown in Figure 16-1.
Figure 16-1 Relationship between NMS, agent and MIB
MIB stores data using a tree structure. The node of the tree is the managed object and can be uniquely
identified by a path starting from the root node. As illustrated in the following figure, the managed
object B can be uniquely identified by a string of numbers {1.2.1.1}. This string of numbers is the OID
of the managed object B.
16-2

Figure 16-2 MIB tree
1 2
1 2
1 2
B
5 6
A
SNMP Configuration
As configurations for SNMPv3 differ substantially from those of SNMPv1 and SNMPv2c, their SNMP
functionalities is introduced separately below.
Follow these steps to configure SNMPv3:

Optional
Disabled by default
Enable SNMP agent snmp-agent You can enable SNMP agent
through this command or any
commands that begin with
snmp-agent.
Optional
snmp-agent sys-info The defaults are as follows:
Configure SNMP agent system { contact sys-contact | 3Com Corporation. for contact,
information location sys-location | version
Marlborough, MA 01752 USA
{ all | { v1 | v2c | v3 }* } }
for location, and SNMP v3 for
the version.
snmp-agent group v3
group-name [ authentication |
Configure an SNMP agent privacy ] [ read-view
Required
group read-view ] [ write-view
write-view ] [ notify-view
notify-view ] [ acl acl-number ]
snmp-agent
calculate-password
Convert the user-defined plain
plain-password mode { md5 |
text password to a cipher text Optional
sha | 3desmd5 | 3dessha }
password
{ local-engineid |
specified-engineid engineid }
snmp-agent usm-user v3
user-name group-name Required
[ [ cipher ]
authentication-mode { md5 | If the cipher keyword is
Add a new user to an SNMP specified, the arguments
sha } auth-password
agent group auth-password and
[ privacy-mode { 3des |
aes128 | des56 } priv-password are considered
priv-password ] ] [ acl as cipher text password.
acl-number ]
16-3

Configure the maximum size of
an SNMP packet that can be snmp-agent packet max-size Optional
received or sent by an SNMP byte-count 1,500 bytes by default
agent
Optional
Configure the engine ID for a snmp-agent local-engineid
local SNMP agent engineid Company ID and device ID by
default
snmp-agent mib-view Optional
Create or update the MIB view { excluded | included }
content for an SNMP agent view-name oid-tree [ mask MIB view name is ViewDefault
mask-value ] and OID is 1 by default.
Follow these steps to configure SNMPv1 and SNMPv2c:

Optional
Disabled by default
Enable SNMP agent snmp-agent You can enable SNMP agent
through this command or any
commands that begin with
snmp-agent.
Required
snmp-agent sys-info The defaults are as follows:
Configure SNMP agent system { contact sys-contact | 3Com Corporation. for contact,
information location sys-location | version
Marlborough, MA 01752 USA
{ { v1 | v2c | v3 }* | all } }
for location and SNMP v3 for
the version.
Create snmp-agent community
Configur an { read | write }
e SNMP community-name [ acl
directly commun acl-number | mib-view Use either approach.
ity view-name ]*
Both commands can be used to
snmp-agent group { v1 | v2c } configure SNMP NMS access
Configur Configur
group-name [ read-view rights. The second command
e SNMP e an
read-view ] [ write-view was introduced to be
NMS SNMP
write-view ] [ notify-view compatible with SNMPv3.
access Configur group
notify-view ] [ acl acl-number ] The community name
right e
Add a configured on NMS should be
indirectl
new consistent with the username
y snmp-agent usm-user { v1 |
user to configured on the agent.
v2c } user-name group-name
an
[ acl acl-number ]
SNMP
group
Configure the maximum size of
an SNMP packet that can be snmp-agent packet max-size Optional
received or sent by an SNMP byte-count 1500 bytes by default
agent
Optional
Configure the engine ID for a snmp-agent local-engineid
local SNMP agent engineid Company ID and device ID by
default
16-4

snmp-agent mib-view
Create or update MIB view { excluded | included } Optional
content for an SNMP agent view-name oid-tree [ mask ViewDefault by default
mask-value ]
The validity of a USM user depends on the engine ID of the SNMP agent. If the engine ID when the
USM user is created is not identical to the current engine ID, the USM user is invalid.
Configuring SNMP Logging

Introduction to SNMP Logging
SNMP logs the GET and SET operations that the NMS performs on the SNMP agent. When the GET
operation is performed, the agent logs the IP address of the NMS, node name of the GET operation
and OID of the node. When the SET operation is performed, the agent logs the IP address of the NMS,
node name of the SET operation, OID of the node, the value set and the error code and error index of
the SET response. These logs will be sent to the information center, and the level of them is
informational, that is, they are taken as the system prompt information. With parameters for the
information center set, the output rules for SNMP logs are decided (that is, whether the logs are
permitted to output and the output destinations).
SNMP logs GET request, SET request and SET response, but does not log GET response.
Enabling SNMP Logging

snmp-agent log { all | Required
Enable SNMP logging get-operation |
set-operation } Disabled by default.
Optional
info-center source
{ module-name | default } By default, SNMP logs are
channel { channel-number | output to loghost and logfile
Configure SNMP log output channel-name } [ debug { level only. To output SNMP logs to
rules severity | state state } * | log other destinations such as
{ level severity | state state } * | console or monitor terminal,
trap { level severity | state you need to set the output
state } * ] * destinations with this
command.
16-5

z Logs occupy storage space of the device, thus affecting the performance of the device. Therefore,
it is recommended to disable SNMP logging.
z The size of SNMP logs cannot exceed that allowed by the information center, and the total length
of the node field and value field of each log record cannot exceed 1K bytes; otherwise, the
exceeded part will not be output.
z For the detailed description of system information, the information center and the info-center
source command, refer to Information Center Configuration in the System Volume.
SNMP Trap Configuration

Enabling the Trap Function
The SNMP agent sends traps to the NMS to inform the NMS of critical and important events (such as
reboot of a managed device). Two types of traps are available: generic traps and self-defined traps.
Generic traps supported on the device include: authentication, coldstart, linkdown, linkup and
warmstart. The others are self-defined traps, which are generated by different modules. As traps that
occupy large device memory affect device performance, it is recommended not to enable the trap
function for all the modules but for the specific modules as needed.
With the trap function enabled on a module, the traps generated by the module will be sent to the
information center. The information center has seven information output destinations. By default, traps
of all modules are allowed to be output to the console, monitor terminal (monitor), loghost, and logfile;
traps of all modules and with level equal to or higher than warnings are allowed to be output to the
trapbuffer and SNMP module (snmpagent); and traps cannot be sent to the logbuffer. You can set
parameters for the information center based on the levels of the traps generated by each module, and
thus decide the output rules of traps (that is, whether traps are allowed to be output and the output
destinations). For the configuration of the information center, refer to Information Center Configuration
in the System Volume.
Follow these steps to enable the trap function:

snmp-agent trap enable [ configuration | Optional

Enable the trap function flash | standard [ authentication |
globally coldstart | linkdown | linkup | warmstart ] By default, the trap
* | system ] function is enabled.
Enable the trap function of Optional

enable snmp trap updown
interface state changes Enabled by default.
16-6

To enable an interface to send linkUp/linkDown traps when its state changes, you need to enable the
trap function of interface state changes on an interface and globally. Use the enable snmp trap
updown command to enable the trap function on an interface, and use the snmp-agent trap enable
[ standard [ linkdown | linkup ] * ] command to enable this function globally.
Configuring Trap Parameters
To send traps to the NMS, you need to prepare the following:

z Basic SNMP configurations have been completed. These configurations include version
configuration: community name is needed when SNMPv1 and v2c are adopted; username and
MIB view are needed if SNMPv3 is adopted.
z A connection has bee established between the device and the NMS, and they can operate each
other.
After traps are sent to the SNMP module, the SNMP module saves the traps in the trap queue. You can
set the size of the queue and the holding time of the traps in the queue, and you can also send the
traps to the specified destination host (usually the NMS).
Follow these steps to configure trap parameters:

snmp-agent target-host trap

address udp-domain Optional
{ ip-address | ipv6
Configure target host attribute ipv6-address } [ udp-port To send the traps to the NMS,
for traps port-number ] params this command is required, and
securityname security-string you must specify ip-address as
[ v1 | v2c | v3 [ authentication the IP address of the NMS.
| privacy ] ]
Configure the source address snmp-agent trap source
Optional
for traps interface-type interface-number
Optional
Extend the standard
snmp-agent trap if-mib link Standard linkUp/linkDown
linkUp/linkDown traps defined
extended traps defined in RFC are used
in RFC
by default.
Configure the size of the trap snmp-agent trap queue-size Optional

sending queue size 100 by default
16-7

Configure the holding time of Optional

snmp-agent trap life seconds
the traps in the queue 120 seconds by default
z An extended linkUp/linkDown trap is the standard linkUp/linkDown trap (defined in RFC)

appended with interface description and interface type information. If the extended messages are
not supported on the NMS, disable this function to let the device send standard linkUp/linkDown
traps.
z If the sending queue of traps is full, the system will automatically delete some oldest traps to
receive new traps.
z The system will automatically delete the traps whose lifetime expires.
Displaying and Maintaining SNMP

Display SNMP-agent system
information, including the contact, display snmp-agent sys-info [ contact |
location, and version of the location | version ]*
SNMP
Display SNMP agent statistics display snmp-agent statistics
Display the SNMP agent engine
display snmp-agent local-engineid
ID
Display SNMP agent group
display snmp-agent group [ group-name ]
information
Display basic information of the
display snmp-agent trap queue Available in
trap queue
any view
Display the modules that can
send traps and whether their trap display snmp-agent trap-list
sending is enabled or not
display snmp-agent usm-user [ engineid
Display SNMP v3 agent user
engineid | username user-name | group
information
group-name ] *
Display SNMP v1 or v2c agent display snmp-agent community [ read |
community information write ]
Display MIB view information for display snmp-agent mib-view [ exclude |
an SNMP agent include | viewname view-name ]
16-8

SNMP Configuration Example
z The NMS connects to the agent, a switch, through an Ethernet.

z The IP address of the NMS is 1.1.1.2/24.
z The IP address of the VLAN interface on the switch is 1.1.1.1/24.
z The NMS monitors and manages the agent using SNMPv2c. The agent reports errors or faults to
the NMS.
Figure 16-3 Network diagram for SNMP
1) Configuring the SNMP agent

# Configure the SNMP basic information, including version and community name.
[Sysname] snmp-agent sys-info version v2c
[Sysname] snmp-agent community read public
[Sysname] snmp-agent community write private
# Configure VLAN-interface 2 (with the IP address of 1.1.1.1/24). Add the port GigabitEthernet 1/0/1 to
VLAN 2.
[Sysname] vlan 2
[Sysname-vlan2] port GigabitEthernet 1/0/1
[Sysname-Vlan2] quit
[Sysname-Vlan-interface2] quit
# Configure the contact person and physical location information of the switch.
[Sysname] snmp-agent sys-info contact Mr.Wang-Tel:3306
[Sysname] snmp-agent sys-info location telephone-closet,3rd-floor
# Enable the sending of traps to the NMS with an IP address of 1.1.1.2/24, using public as the
community name.
[Sysname] snmp-agent trap enable
[Sysname] snmp-agent target-host trap address udp-domain 1.1.1.2 udp-port 5000 params
securityname public
2) Configuring the SNMP NMS
16-9

With SNMPv2c, the user needs to specify the read only community, the read and write community, the
timeout time, and number of retries. The user can inquire and configure the device through the NMS.
The configurations on the agent and the NMS must match.
SNMP Logging Configuration Example

z The NMS and the agent are connected through an Ethernet

z The IP address of the NMS is 1.1.1.2/24
z The IP address of the VLAN interface on the agent is 1.1.1.1/24
z Configure community name, access right and SNMP version on the agent
Figure 16-4 Network diagram for SNMP logging
The configurations for the NMS and agent are omitted.
# Enable logging display on the terminal. (This function is enabled by default, so that you can omit this
configuration).
<Sysname> terminal monitor
<Sysname> terminal logging
# Enable the information center to output the system information with the severity level equal to or
higher than informational to the console port.
[Sysname] info-center source snmp channel console log level informational
16-10

# Enable SNMP logging on the agent to log the GET and SET operations of the NMS.
[Sysname] snmp-agent log get-operation
[Sysname] snmp-agent log set-operation
z The following log information is displayed on the terminal when the NMS performs the GET
operation to the agent.
%Jan 1 02:49:40:566 2006 Sysname SNMP/6/GET:
seqNO = <10> srcIP = <1.1.1.2> op = <get> node = <sysName(1.3.6.1.2.1.1.5.0)> value=<>
z The following log information is displayed on the terminal when the NMS performs the SET
operation to the agent.
%Jan 1 02:59:42:576 2006 Sysname SNMP/6/SET:
seqNO = <11> srcIP = <1.1.1.2> op = <set> errorIndex = <0> errorStatus =<noError> node =
<sysName(1.3.6.1.2.1.1.5.0)> value = <Sysname>
Table 16-1 Description on the output field of SNMP log
Field Description
Jan 1 02:49:40:566 2006 The time when SNMP log is generated
seqNO Sequence number of the SNMP log ()

srcIP IP address of NMS
op SNMP operation type (GET or SET)
node Node name of the SNMP operations and OID of the instance
erroIndex Error index, with 0 meaning no error
errorstatus Error status, with noError meaning no error
Value set when the SET operation is performed (This field is null,
meaning the value obtained with the GET operation is not logged.)
value When the value is a string of characters and the string contains
characters not in the range of ASCII 0 to 127 or invisible characters,
the string is displayed in hexadecimal. For example, value =
<81-43>[hex]
The system information of the information center can be output to the terminal or to the log buffer. In
this example, SNMP log is output to the terminal. For configuration of SNMP log output to other
destinations, see Information Center Configuration in the System Volume.
16-11

MIB Style Configuration
3Com private MIB involves two styles, 3Com compatible MIB and 3Com new MIB. In the 3Com
compatible MIB style, the device sysOID is under the 3Coms enterprise ID 25506, and the private MIB
is under the enterprise ID 2011. In the 3Com new MIB style, both the device sysOID and the private
MIB are under the 3Coms enterprise ID 25506. These two styles of MIBs implement the same
management function except for their root nodes. A device is shipped with MIB loaded and the MIB
style may vary depending on the device. To implement NMSs flexible management of the device, the
device allows you to configure MIB style, that is, you can switch between the two styles of MIBs.
However, you need to ensure that the MIB style of the device is the same as that of the NMS.
Setting the MIB Style
Follow these steps to set the MIB style:

Optional
Set the MIB style of the device mib-style [ new | compatible ]
new by default
The modified MIB style takes effect only after you reboot the device. Therefore, you are recommended
to reboot the device after setting the MIB style to ensure that the modification of the MIB style takes
effect.
Displaying and Maintaining MIB

Display the MIB style display mib-style Available in any view
16-1

17 RMON Configuration
When configuring RMON, go to these sections for information you are interested in:
z RMON Overview
z Configuring RMON
z Displaying and Maintaining RMON
z RMON Configuration Example
RMON Overview
z Introduction
z RMON Groups
Introduction
Remote Monitoring (RMON) is implemented based on the Simple Network Management Protocol
(SNMP) and is fully compatible with the existing SNMP framework without the need of any modification
on SNMP.
RMON provides an efficient means of monitoring subnets and allows SNMP to monitor remote network
devices in a more proactive and effective way. It reduces traffic between network management station
(NMS) and agent, facilitating large network management.
RMON comprises two parts: NMSs and agents running on network devices.
z Each RMON NMS administers the agents within its administrative domain.
z An RMON agent resides on a network monitor or a network probe. It monitors and collects
statistics on traffic over the network segments connected to its interfaces, such as the total
number of packets passed through a network segment over a specified period, or the total number
of good packets sent to a host.
Working Mechanism
RMON allows multiple monitors. A monitor provides two ways of data gathering:
z Using RMON probes. NMSs can obtain management information from RMON probes directly and
control network resources. In this approach, RMON NMSs can obtain all RMON MIB information.
z Embedding RMON agents in network devices such as routers, switches, and hubs to provide the
RMON probe function. RMON NMSs exchange data with RMON agents using basic SNMP
commands to gather network management information, which, due to system resources limitation,
may not cover all MIB information but four groups of information, alarm, event, history, and
statistics, in most cases.
The device adopts the second way. By using RMON agents on network monitors, an NMS can obtain
information about traffic size, error statistics, and performance statistics for network management.
17-1

RMON Groups
Among the ten RMON groups defined by RMON specifications (RFC 1757), the device supports the
event group, alarm group, history group and statistics group. Besides, 3Com also defines and
implements the private alarm group, which enhances the functions of the alarm group. This section
describes the five kinds of groups in general.
Event group
The event group defines event indexes and controls the generation and notifications of the events
triggered by the alarms defined in the alarm group and the private alarm group. The events can be
handled in one of the following ways:
z Logging event related information in the event log table
z Sending traps to NMSs
z Logging event information in the event log table and sending traps to NMSs
z No action
Alarm group
The RMON alarm group monitors specified alarm variables, such as statistics on a port. If the sampled
value of the monitored variable is bigger than or equal to the upper threshold, an upper event is
triggered; if the sampled value of the monitored variable is lower than or equal to the lower threshold, a
lower event is triggered. The event is then handled as defined in the event group.
The following is how the system handles entries in the RMON alarm table:
1) Samples the alarm variables at the specified interval.
2) Compares the sampled values with the predefined threshold and triggers events if all triggering
conditions are met.
If a sampled alarm variable overpasses the same threshold multiple times, only the first one can cause
an alarm event. That is, the rising alarm and falling alarm are alternate.
Private alarm group
The private alarm group calculates the sampled values of alarm variables and compares the result with
the defined threshold, thereby realizing a more comprehensive alarming function.
System handles the prialarm alarm table entry (as defined by the user) in the following ways:
z Periodically samples the prialarm alarm variables defined in the prialarm formula.
z Calculates the sampled values based on the prialarm formula.
z Compares the result with the defined threshold and generates an appropriate event.
17-2

If the count result overpasses the same threshold multiple times, only the first one can cause an alarm
event. That is, the rising alarm and falling alarm are alternate.
History group
The history group periodically collects statistics on data at interfaces and saves the statistics in the
history record table for query convenience. The statistics data includes bandwidth utilization, number
of error packets, and total number of packets.
Once you successfully create a history entry in the specified interface, the history group starts to
periodically collect statistics on packet at the specified interface. Each statistical value is a cumulative
sum of packets sent/received on the interface during a sampling period.
Ethernet statistics group
The statistics group monitors port utilization. It provides statistics about network collisions, CRC
alignment errors, undersize/oversize packets, broadcasts, multicasts, bytes received, packets received,
bytes sent, packets sent, and so on.
After the creation of a statistics entry on an interface, the statistics group starts to collect traffic
statistics on the current interface. The result of the statistics is a cumulative sum.
Configuring RMON
Before configuring RMON, configure the SNMP agent as described in SNMP Configuration in the
System Volume.
Follow these steps to configure RMON:

rmon event entry-number [ description
Create an event entry in the
string ] { log | log-trap log-trapcommunity | Optional
event table
none | trap trap-community } [ owner text ]
Enter Ethernet interface view interface interface-type interface-number
Create an entry in the history rmon history entry-number buckets number

Optional
table interval sampling-interval [ owner text ]
Create an entry in the statistics
rmon statistics entry-number [ owner text ] Optional
table
Exit Ethernet interface view quit
17-3

rmon alarm entry-number alarm-variable
sampling-interval { absolute | delta }
Create an entry in the alarm table rising-threshold threshold-value1 Optional
event-entry1 falling-threshold
threshold-value2 event-entry2 [ owner text ]
rmon prialarm entry-number
prialarm-formula prialarm-des
sampling-interval { absolute | changeratio |
Create an entry in the private
delta } rising-threshold threshold-value1 Optional
alarm table
event-entry1 falling-threshold
threshold-value2 event-entry2 entrytype
{ forever | cycle cycle-period } [ owner text ]
z A new entry cannot be created if its parameters are identical with the corresponding parameters of
an existing entry Refer to Table 17-1 for the parameters to be compared for different entries.
z The system limits the total number of each type of entries (Refer to Table 17-1 for the detailed
numbers). When the total number of an entry reaches the maximum number of entries that can be
created, the creation fails.
z When you create an entry in the history table, if the specified buckets number argument exceeds
the history table size supported by the device, the entry will be created. However, the validated
value of the buckets number argument corresponding to the entry is the history table size
supported by the device.
Table 17-1 Restrictions on the configuration of RMON
Maximum number of
Entry Parameters to be compared entries that can be
created
Event description (description string), event type (log,
Event trap, logtrap or none) and community name 60
(trap-community or log-trapcommunity)
History Sampling interval (interval sampling-interval) 100
Only one statistics entry can be created on an

Statistics 100
interface.
Alarm variable (alarm-variable), sampling interval
(sampling-interval), sampling type (absolute or delta),
Alarm 60
rising threshold (threshold-value1) and falling
threshold (threshold-value2)
Alarm variable formula (alarm-variable), sampling
interval (sampling-interval), sampling type (absolute,
Prialarm changeratio or delta), rising threshold 50
(threshold-value1) and falling threshold
(threshold-value2)
17-4

Displaying and Maintaining RMON
display rmon statistics
Display RMON statistics Available in any view
Display the RMON history
display rmon history
control entry and history Available in any view
sampling information
Display RMON alarm display rmon alarm
configuration information [ entry-number ]
Display RMON prialarm display rmon prialarm
Display RMON events display rmon event
Display log information for the display rmon eventlog
specified or all event entries. [ entry-number ]
RMON Configuration Example

Agent is connected to a configuration terminal through its console port and to a remote NMS across
the Internet.
Create an entry in the RMON Ethernet statistics table to gather statistics on GigabitEthernet 1/0/1, and
enable logging after received bytes exceed the specified threshold.
Figure 17-1 Network diagram for RMON
# Configure RMON to gather statistics for interface GigabitEthernet 1/0/1.

[Sysname-GigabitEthernet1/0/1] rmon statistics 1 owner user1-rmon
# Display RMON statistics for interface GigabitEthernet 1/0/1.

<Sysname> display rmon statistics GigabitEthernet 1/0/1
Statistics entry 1 owned by user1-rmon is VALID.
Interface : GigabitEthernet1/0/1<ifIndex.3>
etherStatsOctets : 21657 , etherStatsPkts : 307
17-5

etherStatsBroadcastPkts : 56 , etherStatsMulticastPkts : 34
etherStatsUndersizePkts : 0 , etherStatsOversizePkts : 0
etherStatsFragments : 0 , etherStatsJabbers : 0
etherStatsCRCAlignErrors : 0 , etherStatsCollisions : 0
etherStatsDropEvents (insufficient resources): 0
Packets received according to length:
64 : 235 , 65-127 : 67 , 128-255 : 4
256-511: 1 , 512-1023: 0 , 1024-1518: 0
# Create an event to start logging after the event is triggered.

[Sysname] rmon event 1 log owner 1-rmon
# Configure an alarm group to sample received bytes on GigabitEthernet 1/0/1. When the received
bytes exceed the upper or below the lower limit, logging is enabled.
[Sysname] rmon alarm 1 1.3.6.1.2.1.16.1.1.1.4.1 10 delta rising-threshold 1000 1
falling-threshold 100 1 owner 1-rmon
[Sysname] display rmon alarm 1
Alarm table 1 owned by 1-rmon is VALID.
Samples type : delta
Variable formula : 1.3.6.1.2.1.16.1.1.1.4.1<etherStatsOctets.1>
Sampling interval : 10(sec)
Rising threshold : 1000(linked with event 1)
Falling threshold : 100(linked with event 1)
When startup enables : risingOrFallingAlarm
Latest value : 2552
17-6

18 MAC Address Table Management Configuration
When configuring MAC address table management, go to these sections for information you are
interested in:
z Introduction to MAC Address Table
z Configuring MAC Address Table Management
z MAC Address Table Management Configuration Example
z MAC Information Configuration
z MAC Information Configuration Example
z Interfaces that MAC address table management involves can only be Layer 2 Ethernet ports.
z This manual covers only the management of static, dynamic and blackhole MAC address table
entries (source and destination). For the management of multicast MAC address table entries,
refer to Multicast Routing and Forwarding Configuration in the IP Multicast Volume.
Introduction to MAC Address Table

A device maintains a MAC address table for frame forwarding. Each entry in this table indicates the
MAC address of a connected device, ID of the interface to which this device is connected and ID of the
VLAN to which the interface belongs. When forwarding a frame, the device looks up the MAC address
table according to the destination MAC address of the frame to rapidly determine the egress port, thus
reducing broadcasts.
How a MAC Address Table Entry is Generated
A MAC address table entry can be dynamically learned or manually configured.
Dynamically learn a MAC address table entry
Usually, MAC address tables are automatically generated during the source MAC address learning
process of devices.
The following is how a device learns a MAC address after it receives a frame from a port, Port 1 for
example:
1) Check the source MAC address (MAC-SOURCE for example) of the frame, that is, the MAC
address of the device that sends the frame.
2) Look up the MAC address table for an entry corresponding to the MAC address and do the
following:
z If an entry is found for the MAC address, update the entry.
18-1

z If no entry is found, add an entry for the MAC address to indicate from which port the frame is
received.
When receiving a frame destined for MAC-SOURCE, the device then looks up the MAC address table
and forwards it from Port 1.
To adapt to network changes, MAC address table entries need to be constantly updated. Each
dynamically learned MAC address table entry has a life period, that is, an aging timer. If an entry is not
updated before the aging timer expires, it will be deleted. If yes, the aging timer restarts the timing.
Manually configure a MAC address table entry
When a device dynamically learns MAC address table entries through source MAC address learning, it
cannot tell frames of legal users from those of hackers. This brings potential security hazards. For
example, if a hacker forges the MAC address of a legal user and uses it as the source MAC address of
the attack frames, and accesses the device from a different port than that used by the legal user, the
device will learn a forged MAC address entry, and forward frames destined for the legal user to the
hacker instead.
To enhance the security of a port, you can manually add MAC address entries into the MAC address
table of the device to bind specific user devices to the port, thus preventing hackers from stealing data
using forged MAC addresses. Manually configured MAC address table entries have a higher priority
than dynamically learned ones.
Types of MAC Address Table Entries
A MAC address table may contain the following types of entries:

z Static entries, which are manually configured and never age out.
z Dynamic entries, which can be manually configured or dynamically learned and may age out.
z Blackhole entries, which are manually configured and never age out. Blackhole entries are
configured to filter frames with specific destination MAC addresses.
Dynamically-learned MAC addresses cannot overwrite static or blackhole MAC address entries, but
the latter can overwrite the former.
MAC Address Table-Based Frame Forwarding
When forwarding a frame, the device adopts the following two forwarding modes based on the MAC
address table:
z Unicast mode: If an entry is available for the destination MAC address, the device forwards the
frame out the outgoing interface indicated by the MAC address table entry.
z Broadcast mode: If the device receives a frame with the destination address being all ones, or no
entry is available for the destination MAC address, the device broadcasts the frame to all the
interfaces except the receiving interface.
18-2

Figure 18-1 Forward frames using the MAC address table
Configuring MAC Address Table Management

The MAC address table management configuration tasks include:
z Configuring MAC Address Table Entries
z Disabling MAC Address Learning on a VLAN
z Configuring the Aging Timer for Dynamic MAC Address Entries
z Configuring the MAC Learning Limit
These configuration tasks are all optional and randomly sorted. You can choose some of the
configuration tasks as required.
Configuring MAC Address Table Entries
Follow these steps to add, modify, or remove entries in the MAC address table globally:

mac-address blackhole mac-address vlan vlan-id

Add/modify a MAC
mac-address { dynamic | static } mac-address Required
address entry
interface interface-type interface-number vlan vlan-id
Follow these steps to add, modify, or remove entries in the MAC address table on an interface:

Add/modify MAC address

mac-address { dynamic | static }
entries under the specified Required
mac-address vlan vlan-id
interface view
Disabling MAC Address Learning on a VLAN
You may disable MAC address learning on a per-VLAN basis.
18-3

Follow these steps to disable MAC address learning on a VLAN:

Disable MAC address learning mac-address mac-learning Required

on the VLAN disable Enabled by default
Once MAC learning is disabled in a VLAN, all MAC address entries learnt in the VLAN are removed.
Configuring the Aging Timer for Dynamic MAC Address Entries
The MAC address table on your device is available with an aging mechanism for dynamic entries to
prevent its resources from being exhausted. Set the aging timer appropriately: a long aging interval
may cause the MAC address table to retain outdated entries and fail to accommodate the latest
network changes; a short interval may result in removal of valid entries and hence unnecessary
broadcasts which may affect device performance.
Follow these steps to configure the aging timer for dynamic MAC address entries:

Configure the aging timer for mac-address timer { aging Optional

dynamic MAC address entries seconds | no-aging } 300 by default.
The aging timer for dynamic MAC address entries takes effect globally on dynamic MAC address
entries (learned or administratively configured) only.
Configuring the MAC Learning Limit
To prevent a MAC address table from getting so large that it may degrade forwarding performance, you
may restrict the number of MAC addresses that can be learned on a per-port, port group basis.
Follow these steps to configure the MAC learning limit:

18-4

Required
Enter Ethernet interface interface-type Use any of these three
interface view interface-number commands.
Enter
Ethernet The configuration you make in
interface Ethernet interface view takes
view, port effect on the current interface
group view Enter port group port-group manual only; the configuration you
view port-group-name make in port group view takes
effect on all the member ports
in the port group.
Configure the maximum number Required

of MAC addresses that can be mac-address The default maximum number
learned on an Ethernet port view max-mac-count count of MAC addresses that can be
or port group learned is not configured.
Displaying and Maintaining MAC Address Table Management

display mac-address blackhole [ vlan
vlan-id ] [ count ]
Display MAC address table display mac-address [ mac-address [ vlan
information vlan-id ] | [ dynamic | static ] [ interface
interface-type interface-number ] [ vlan Available in any
vlan-id ] [ count ] ] view
Display the aging timer for

display mac-address aging-time
dynamic MAC address entries
Display MAC address statistics display mac-address statistics
MAC Address Table Management Configuration Example

Log onto your device from the Console port to configure MAC address table management as follows:
z Set the aging timer to 500 seconds for dynamic MAC address entries.
z Add a static entry 000f-e235-dc71 for port GigabitEthernet 1/0/1 in VLAN 1.
# Add a static MAC address entry.

[Sysname] mac-address static 000f-e235-dc71 interface gigabitethernet 1/0/1 vlan 1
# Set the aging timer for dynamic MAC address entries to 500 seconds.
[Sysname] mac-address timer aging 500
# Display the MAC address entry for port GigabitEthernet 1/0/1.

[Sysname] display mac-address interface gigabitethernet 1/0/1
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
18-5

000f-e235-dc71 1 Config static GigabitEthernet 1/0/1 NOAGED
--- 1 mac address(es) found ---
18-6

19 MAC Information Configuration
When configuring MAC Information, go to these sections for information you are interested in:
z Overview
z Configuring MAC Information
z MAC Information Configuration Example
Overview
Introduction to MAC Information
To monitor a network, you need to monitor users joining and leaving the network. Because a MAC
address uniquely identifies a network user, you can monitor users joining and leaving a network by
monitoring their MAC addresses.
With the MAC Information function, Layer-2 Ethernet interfaces send Syslog or Trap messages to the
monitor end in the network when they learn or delete MAC addresses. By analyzing these messages,
the monitor end can monitor users accessing the network.
How MAC Information Works
When a new MAC address is learned or an existing MAC address is deleted on a device, the device
writes related information about the MAC address to the buffer area used to store user information.
When the timer set for sending MAC address monitoring Syslog or Trap messages expires, or when
the buffer is used up, the device sends the Syslog or Trap messages to the monitor end immediately.
Configuring MAC Information

The MAC Information configuration tasks include:
z Enabling MAC Information Globally
z Enabling MAC Information on an Interface
z Configuring MAC Information Mode
z Configuring the Interval for Sending Syslog or Trap Messages
z Configuring the MAC Information Queue Length
Enabling MAC Information Globally
Follow these steps to enable MAC Information globally:

Enable MAC Required

mac-address information enable
Information globally Disabled by default
19-1

Enabling MAC Information on an Interface
Follow these steps to enable MAC Information on an interface:

interface-number
Enable MAC Information on mac-address information enable Required

the interface { added | deleted } Disabled by default
To enable MAC Information on an Ethernet interface, enable MAC Information globally first.
Configuring MAC Information Mode
Follow these steps to configure MAC Information mode:

Configure MAC mac-address information mode Optional

Information mode { syslog | trap } trap by default
Configuring the Interval for Sending Syslog or Trap Messages
To prevent Syslog or Trap messages being sent too frequently and thus affecting system performance,
you can set the interval for sending Syslog or Trap messages.
Follow these steps to set the interval for sending Syslog or Trap messages:

Set the interval for Optional

mac-address information interval
sending Syslog or Trap
interval-time One second by default.
messages
Configuring the MAC Information Queue Length
To avoid losing user MAC address information, when the buffer storing user MAC address information
is used up, the user MAC address information in the buffer is sent to the monitor end in the network,
even if the timer set for sending MAC address monitoring Syslog or Trap messages has not expired
yet.
Follow these steps to configure the MAC Information queue length:
19-2

Configure the MAC Optional
mac-address information
Information queue
queue-length value 50 by default
length
Setting the MAC Information queue length to 0 indicates that the device sends a Syslog or Trap
message to the network management device as soon as a new MAC address is learned or an existing
MAC address is deleted.
MAC Information Configuration Example

MAC Information Configuration Example
z Host A is connected to a remote server (Server) through Device.

z Enable MAC Information on GigabitEthernet 1/0/1 on Device. Device sends MAC address change
information using Syslog messages to Host B through GigabitEthernet 1/0/3. Host B analyzes and
displays the Syslog messages.
Figure 19-1 Network diagram for MAC Information configuration
1) Configure Device to send Syslog messages to Host B.

Refer to Information Center Configuration in the System Volume for details.
2) Enable MAC Information.
# Enable MAC Information on Device.
[Device] mac-address information enable
# Configure MAC Information mode as Syslog.
19-3

[Device] mac-address information mode syslog
# Enable MAC Information on GigabitEthernet 1/0/1

[Device-GigabitEthernet1/0/1] mac-address information enable added
[Device-GigabitEthernet1/0/1] mac-address information enable deleted
# Set the MAC Information queue length to 100.

[Device] mac-address information queue-length 100
# Set the interval for sending Syslog or Trap messages to 20 seconds.

[Device] mac-address information interval 20
19-4

20 System Maintenance and Debugging
When maintaining and debugging the system, go to these sections for information you are interested
in:
z System Maintenance and Debugging
z Ping
z Tracert
z System Debugging
z Ping and Tracert Configuration Example
System Maintenance and Debugging

You can use the ping command and the tracert command to verify the current network connectivity,
and use the debug command to enable debugging and thus to diagnose system faults based on the
debugging information.
Ping
Introduction
You can use the ping command to verify whether a device with a specified address is reachable, and
to examine network connectivity.
The ping function is implemented through the Internet Control Message Protocol (ICMP):
1) The source device sends an ICMP echo request to the destination device.
2) The source device determines whether the destination is reachable based on whether it receives
an ICMP echo reply; if the destination is reachable, the source device determines the link quality
based on the numbers of ICMP echo requests sent and replies received, determines the distance
between the source and destination based on the round trip time of ping packets.
Configuring Ping
Follow the step below to configure the ping function:

ping [ ip ] [ -a source-ip | -c count | -f | -h ttl | -i Required
interface-type interface-number | -m interval | -n | Use either approach
Check
-p pad | -q | -r | -s packet-size | -t timeout | -tos tos
whether a The ping command is
| -v | -vpn-instance vpn-instance-name ] * host
specified applicable in an IPv4
address in an network; the ping ipv6
IP network is ping ipv6 [ -a source-ipv6 | -c count | -m interval | command is applicable in an
reachable -s packet-size | -t timeout ] * host [ -i interface-type IPv6 network.
interface-number ]
20-1

z For a low-speed network, you are recommended to set a larger value for the timeout timer
(indicated by the -t parameter in the command) when configuring the ping command.
z Only the directly connected segment address can be pinged if the outgoing interface is specified
with the -i argument
Ping Configuration Example
As shown in Figure 20-1, check whether an available route exists between Device A and Device C. If
there is an available route exists between the two devices, get the detailed information of routes from
Device A to Device C.
Figure 20-1 Ping network diagram
# Use the ping command to display whether an available route exists between Device A and Device C.
<DeviceA> ping 1.1.2.2

0.00% packet loss
# Get the detailed information of routes from Device A to Device C.

<DeviceA> ping -r 1.1.2.2
20-2

Record Route:
1.1.2.1
1.1.2.2
1.1.1.2
1.1.1.1
Record Route:
1.1.2.1
1.1.2.2
1.1.1.2
1.1.1.1
Record Route:
1.1.2.1
1.1.2.2
1.1.1.2
1.1.1.1
Record Route:
1.1.2.1
1.1.2.2
1.1.1.2
1.1.1.1
Record Route:
1.1.2.1
1.1.2.2
1.1.1.2
1.1.1.1
0.00% packet loss
The principle of ping r is as shown in Figure 20-1.

1) The source (Device A) sends an ICMP echo request with the RR option being empty to the
destination (Device C).
2) The intermediate device (Device B) adds the IP address (1.1.2.1) of its outbound interface to the
RR option of the ICMP echo request, and forwards the packet.
3) Upon receiving the request, the destination device copies the RR option in the request and adds
the IP address (1.1.2.2) of its outbound interface to the RR option. Then the destination device
sends an ICMP echo reply.
4) The intermediate device adds the IP address (1.1.1.2) of its outbound interface to the RR option in
the ICMP echo reply, and then forwards the reply.
20-3

5) Upon receiving the reply, the source device adds the IP address (1.1.1.1) of its inbound interface
to the RR option. Finally, you can get the detailed information of routes from Device A to Device C:
1.1.1.1 <-> {1.1.1.2; 1.1.2.1} <-> 1.1.2.2.
Tracert
Introduction
By using the tracert command, you can trace the Layer 3 devices involved in delivering an IP packet
from source to destination to check whether a network is available. This is useful for identification of
failed node(s) in the event of network failure.
Figure 20-2 Tracert diagram
The tracert function is implemented through ICMP, as shown in Figure 20-2:

2) The source (Device A) sends a packet with a TTL value of 1 to the destination (Device D). The
UDP port of the packet is a port number that will not be used by any application of the destination.
3) The first hop (Device B) (the Layer 3 device that first receives the packet) responds by sending a
TTL-expired ICMP error message to the source, with its IP address 1.1.1.2 encapsulated. In this
way, the source device can get the address (1.1.1.2) of the first Layer 3 device.
4) The source device sends a packet with a TTL value of 2 to the destination device.
5) The second hop (Device C) responds with a TTL-expired ICMP error message, which gives the
source device the address (1.1.2.2) of the second Layer 3 device.
6) The above process continues until the ultimate destination device is reached. No application of the
destination uses this UDP port. Therefore, the destination replies a port unreachable ICMP error
message with the destination IP address 1.1.3.2.
7) When the source device receives the port unreachable ICMP error message, it knows that the
packet has reached the destination, and it can get the addresses of all the Layer 3 devices
involved to get to the destination device (1.1.1.2, 1.1.2.2, 1.1.3.2).
Configuring Tracert
Follow these steps to configure tracert:

20-4

Enable sending of Required
ICMP timeout ip ttl-expires enable
packets Disabled by default.
Enable sending of Required

ICMP destination ip unreachables enable
unreachable packets Disabled by default.
tracert [ -a source-ip | -f first-ttl | -m max-ttl | Required

-p port | -q packet-number | -vpn-instance Use either approach
vpn-instance-name | -w timeout ] * host
Display the routes The tracert command is
from source to applicable in an IPv4
destination network; the tracert ipv6
tracert ipv6 [ -f first-ttl | -m max-ttl | -p port | command is applicable in an
-q packet-number | -w timeout ] * host IPv6 network.
System Debugging
Introduction to System Debugging
The device provides various debugging functions. For the majority of protocols and features supported,
the system provides corresponding debugging information to help users diagnose errors.
The following two switches control the display of debugging information:
z Protocol debugging switch, which controls protocol-specific debugging information.
z Screen output switch, which controls whether to display the debugging information on a certain
screen.
As Figure 20-3 illustrates, suppose the device can provide debugging for the three modules 1, 2, and 3.
Only when both the protocol debugging switch and the screen output switch are turned on can
debugging information be output on a terminal.
Figure 20-3 The relationship between the protocol and screen debugging switch
Debugging
information Debugging
1 2 3 information 1 2 3
Protocol
Protocol
ON OFF ON debugging ON OFF ON
debugging
switch
switch
1 3 1 3
Screen output Screen output ON

switch OFF switch
1 3
20-5

Configuring System Debugging
Output of the debugging information may reduce system efficiency. The debugging commands are
usually used by administrators in diagnosing network failure. After completing the debugging, disable
the corresponding debugging function, or use the undo debugging all command to disable all the
debugging functions.
Output of debugging information is related to the configurations of the information center and the
debugging commands of each protocol and functional module. Displaying the debugging information
on a terminal (including console or VTY) is a common way to output debugging information. You can
also output debugging information to other destinations. For the detailed configurations, refer to
Information Center Commands in the System Volume. By default, you can output debugging
information to a terminal by following these steps:

Optional
The terminal monitoring on the
Enable the terminal monitoring console is enabled by default
terminal monitor
of system information and that on the monitoring
terminal is disabled by default.
Required
Enable the terminal display of
terminal debugging Disabled by default
debugging information
debugging { all [ timeout Required

Enable debugging for a
time ] | module-name Disabled by default
specified module
[ option ] } Available in user view
display debugging [ interface
Display the enabled debugging interface-type Optional
functions interface-number ] Available in any view
[ module-name ]
You must configure the debugging, terminal debugging and terminal monitor commands first to
display the detailed debugging information on the terminal. For the detailed description on the
terminal debugging and terminal monitor commands, refer to Information Center Commands in the
System Volume.
Ping and Tracert Configuration Example

As shown in Figure 20-4, Device A failed to telnet Device C. Now it is required to determine whether an
available route exists between Device A and Device C. If no such a route exists, you need to locate the
failed nodes in the network.
20-6

Figure 20-4 Ping and tracert network diagram
# Use the ping command to display whether an available route exists between Device A and Device C.
<DeviceA> ping 1.1.2.2
Request time out
Request time out
Request time out
Request time out
Request time out

100.00% packet loss
# No such a route exists. Use the tracert command to determine failed nodes.
[DeviceA] ip ttl-expires enable
[DeviceA] ip unreachables enable
[DeviceA] tracert 1.1.2.2
traceroute to 1.1.2.2(1.1.2.2) 30 hops max,40 bytes packet, press CTRL_C to bre
ak
1 1.1.1.2 14 ms 10 ms 20 ms
2 * * *
3 * * *
4 * * *
5
<DeviceA>
The above output shows that no available route exists between Device A and Device C; an available
router exists between Device A and Device B; an error occurred on the connection between Device B
and Device C. In this case, you can use the debugging ip icmp command to enable ICMP debugging
on Device A and Device C to check whether the devices send or receive the specified ICMP packets,
or you can use the display ip routing-table command to display whether a route exists between the
two devices.
20-7

21 Information Center Configuration
When configuring information center, go to these sections for information you are interested in:
z Information Center Configuration
z Configuring Information Center
z Displaying and Maintaining Information Center
z Information Center Configuration Examples
Information Center Overview

Introduction to Information Center
Acting as the system information hub, information center classifies and manages system information,
offering a powerful support for network administrators and developers in monitoring network
performance and diagnosing network problems.
The following describes the working process of information center:
z Receives the log, trap, and debugging information generated by each module.
z Outputs the above information to different information channels according to the user-defined
output rules.
z Outputs the information to different destinations based on the information channel-to-destination
associations.
To sum up, information center assigns the log, trap and debugging information to the ten information
channels according to the eight severity levels and then outputs the information to different
destinations. The following describes the working process in details.
By default, the information center is enabled. An enabled information center affects the system
performance in some degree due to information classification and output. Such impact becomes more
obvious in the event that there is enormous information waiting for processing.
Classification of system information
The system information of the information center falls into three types:
z Log information
z Trap information
z Debugging information
21-1

Eight levels of system information
The information is classified into eight levels by severity. The severity levels in the descending order
are emergency, alert, critical, error, warning, notice, informational and debug. When the system
information is output by level, the information with severity level higher than or equal to the specified
level is output. For example, in the output rule, if you configure to output information with severity level
being informational, the information with severity level being emergency through informational is all
allowed to be output.
Table 21-1 Severity description
Severity Severity value Description

Emergency 0 The system is unusable.
Alert 1 Action must be taken immediately
Critical 2 Critical conditions

Error 3 Error conditions
Warning 4 Warning conditions
Notice 5 Normal but significant condition

Informational 6 Informational messages
Debug 7 Debug-level messages
Six output destinations and ten channels of system information
The system supports six information output destinations, including the console, monitor terminal
(monitor), log buffer, log host, trap buffer and SNMP module. The specific destinations supported vary
with devices.
The system supports ten channels. The six channels 0 through 5 are configured with channel names,
output rules, and are associated with output destinations by default. The channel names, output rules
and the associations between the channels and output destinations can be changed through
commands. Besides, you can configure channels 6, 7, 8, and 9 without changing the default
configuration of the six channels.
Table 21-2 Information channels and output destinations
Information channel
Default channel name Default output destination
number
Console (Receives log, trap and debugging
0 console
information)
Monitor terminal (Receives log, trap and
1 monitor debugging information, facilitating remote
maintenance)
Log host (Receives log, trap and debugging
2 loghost information and information will be stored in files
for future retrieval.)
Trap buffer (Receives trap information, a buffer
3 trapbuffer
inside the router for recording information.)
21-2

Information channel
Default channel name Default output destination
number
Log buffer (Receives log and debugging
4 logbuffer information, a buffer inside the router for
recording information.)
5 snmpagent SNMP module (Receives trap information)
Not specified (Receives log, trap, and debugging
6 channel6
information)
7 channel7
information)
8 channel8
information)
Configurations for the six output destinations function independently and take effect only after the
information center is enabled.
Outputting system information by source module
The system is composed of a variety of protocol modules, board drivers, and configuration modules.
The system information can be classified, filtered, and output according to source modules. You can
use the info-center source ? command to view the supported information source modules.
Default output rules of system information
The default output rules define the source modules allowed to output information on each output
destination, the output information type, and the output information level as shown in Table 21-3, which
indicates that by default and in terms of all modules:
z Log information with severity level equal to or higher than informational is allowed to be output to
the log host; log information with severity level equal to or higher than warning is allowed to be
output to the console, monitor terminal, and log buffer; log information is not allowed to be output
to the trap buffer and the SNMP module.
z All trap information is allowed to be output to the console, monitor terminal and log host; trap
information with severity level equal to or higher than warning is allowed to be output to the trap
buffer and SNMP module; trap information is not allowed to be output to the log buffer.
z All debugging information is allowed to be output to the console and monitor terminal; debugging
information is not allowed to be output to the log host, log buffer, trap buffer and the SNMP
module.
21-3

Table 21-3 Default output rules for different output destinations
Output LOG TRAP DEBUG

Modules
destinati
allowed Enabled/ Enabled/ Enabled/
on Severity Severity Severity
disabled disabled disabled
default
Console (all Enabled Warning Enabled Debug Enabled Debug
modules)
default
Monitor
(all Enabled Warning Enabled Debug Enabled Debug
terminal
modules)
default
Informatio
Log host (all Enabled Enabled Debug Disabled Debug
nal
modules)
default
Trap Informatio
(all Disabled Enabled Warning Disabled Debug
buffer nal
modules)
default
Log buffer (all Enabled Warning Disabled Debug Disabled Debug
modules)
default
SNMP
(all Disabled Debug Enabled Warning Disabled Debug
module
modules)
System Information Format
The format of system information varies with the output destinations.

z If the output destination is not the log host (such as console, monitor terminal, logbuffer, trapbuffer,
SNMP), the system information is in the following format:
timestamp sysname module/level/digest:content
For example, a monitor terminal connects to the device. When a terminal logs in to the device, the log
information in the following format is displayed on the monitor terminal:
%Jun 26 17:08:35:809 2008 Sysname SHELL/4/LOGIN: VTY login from 1.1.1.1
z If the output destination is the log host, the system information is in the following format according
to RFC 3164 (The BSD Syslog Protocol):
<Int_16>timestamp sysname %%nnmodule/level/digest: source content
z The closing set of angel brackets < >, the space, the forward slash /, and the colon are all required
in the above format.
z The format in the previous part is the original format of system information, so you may see the
information in a different format. The displayed format depends on the tools you use to view the
logs.
21-4

What follows is a detailed explanation of the fields involved:
Int_16 (priority)
The priority is calculated using the following formula: facility*8+severity, in which facility represents the
logging facility name and can be configured when you set the log host parameters. The facility ranges
from local0 to local7 (16 to 23 in decimal integers) and defaults to local7. The facility is mainly used to
mark different log sources on the log host, query and filter the logs of the corresponding log source.
Severity ranges from 0 to 7. Table 21-1 details the value and meaning associated with each severity.
Note that the priority field takes effect only when the information has been sent to the log host.
timestamp
Timestamp records the time when system information is generated to allow users to check and identify
system events. You can use the info-center timestamp command to configure whether to include a
timestamp in the system information as well as the timestamp format if it is included. The time stamp of
the system information sent from the information center to the log host is with a precision of seconds,
whereas that of the system information sent from the information center to the other destinations is
with a precision of milliseconds.
sysname
Sysname is the system name of the current host. You can use the sysname command to modify the
system name. (Refer to Basic System Configuration Commands in the System Volume for details)
%%
This field is a preamble used to identify a vendor. It is displayed only when the output destination is log
host.
nn
This field is a version identifier of syslog. It is displayed only when the output destination is log host.
module
The module field represents the name of the module that generates system information. You can enter
the info-center source ? command in system view to view the module list.
level (severity)
System information can be divided into eight levels based on its severity, from 0 to 7. Refer to Table
21-1 for definition and description of these severity levels. The levels of system information generated
by modules are predefined by developers, and you cannot change the system information levels.
However, you can configure to output information of the specified level using the info-center source
command.
digest
The digest field is a string of up to 32 characters, outlining the system information.

For system information destined to the log host:
z If the character string ends with (l), the information is log information
z If the character string ends with (t), the information is trap information
z If the character string ends with (d), the information is debugging information
For system information destined to other destinations:
21-5

z If the timestamp starts with a %, the information is log information
z If the timestamp starts with a #, the information is trap information
z If the timestamp starts with a *, the information is debugging information
source
This field indicates the source of the information, such as the IRF member ID, or the source IP
address of the log sender. This field is optional and is displayed only when the output destination is the
log host.
content
This field provides the content of the system information.
Configuring Information Center

Information Center Configuration Task List
Complete the following tasks to configure information center:
Task Remarks
Outputting System Information to the Console Optional
Outputting System Information to a Monitor Terminal Optional
Outputting System Information to a Log Host Optional
Outputting System Information to the Trap Buffer Optional
Outputting System Information to the Log Buffer Optional
Outputting System Information to the SNMP Module Optional

Configuring Synchronous Information Output Optional
Outputting System Information to the Console
Outputting system information to the console

Optional
Enable information center info-center enable
Enabled by default
info-center channel Optional

Name the channel with a
channel-number name Refer to Table 21-2 for default
specified channel number
channel-name channel names.
Optional
Configure the channel through info-center console channel
which system information can { channel-number | By default, system information
be output to the console channel-name } is output to the console through
channel 0 (known as console).
21-6

info-center source
{ module-name | default }
channel { channel-number | Optional
Configure the output rules of channel-name } [ debug { level
system information severity | state state } * | log Refer to Default output rules of
{ level severity | state state } * | system information.
trap { level severity | state
state } * ] *
Optional
info-center timestamp
Configure the format of the The time stamp format for log,
{ debugging | log | trap }
time stamp trap and debugging information
{ boot | date | none }
is date by default.
Enabling the display of system information on the console
After setting to output system information to the console, you need to enable the associated display
function to display the output information on the console.
Follow these steps in user view to enable the display of system information on the console:

Optional
Enable the monitoring of
system information on the terminal monitor Enabled on the console and
console disabled on the monitor
terminal by default.
Enable the display of Required
debugging information on the terminal debugging
console Disabled by default
Enable the display of log Optional

terminal logging
information on the console Enabled by default
Enable the display of trap Optional

terminal trapping
information on the console Enabled by default
Outputting System Information to a Monitor Terminal
System information can also be output to a monitor terminal, which is a user terminal that has login
connections through the AUX, VTY user interface.
Outputting system information to a monitor terminal

Optional
Enabled by default

21-7

Optional
Configure the channel through info-center monitor channel By default, system information
which system information can { channel-number | is output to the monitor terminal
be output to a monitor terminal channel-name } through channel 1 (known as
monitor).
info-center source
the system information severity | state state } * | log Refer to Default output rules of
state } * ] *
Optional
Configure the format of the By default, the time stamp
time stamp format for log, trap and
debugging information is date.
Enabling the display of system information on a monitor terminal
After setting to output system information to a monitor terminal, you need to enable the associated
display function in order to display the output information on the monitor terminal.
Follow these steps to enable the display of system information on a monitor terminal:

Required
Enable the monitoring of
system information on a terminal monitor Enabled on the console and
monitor terminal disabled on the monitor
terminal by default.
Enable the display of Required
debugging information on a terminal debugging
monitor terminal Disabled by default
Enable the display of log Optional

information on a monitor terminal logging
terminal Enabled by default
Enable the display of trap Optional

information on a monitor terminal trapping
terminal Enabled by default
Outputting System Information to a Log Host

Optional
Enabled by default

21-8

Required
Specify a log host and info-center loghost host-ip By default, the system does not
configure the parameters when [ channel { channel-number | output information to a log host.
system information is output to channel-name } | facility If you specify to output system
the log host local-number ] * information to a log host, the
system uses channel 2
(loghost) by default.
info-center source
state } * ] *
Optional
By default, the source interface
Specify the source IP address info-center loghost source is determined by the matched
for the log information interface-type interface-number route, and the primary IP
address of this interface is the
source IP address of the log
information.
Configure the format of the
info-center timestamp Optional
time stamp for system
loghost { date | no-year-date |
information output to the log date by default.
none }
host
Outputting System Information to the Trap Buffer
The trap buffer receives the trap information only, and discards the log and debugging information
even if you have configured to output them to the trap buffer.

Optional
Enabled by default

Optional
Configure the channel through info-center trapbuffer By default, system information
which system information can [ channel { channel-number | is output to the trap buffer
be output to the trap buffer and channel-name } | size through channel 3 (known as
specify the buffer size buffersize ] * trapbuffer) and the default
buffer size is 256.
21-9

info-center source
state } * ] *
Optional
time stamp trap and debugging information
is date by default.
Outputting System Information to the Log Buffer
You can configure to output log, trap, and debugging information to the log buffer, but the log buffer
receives the log and debugging information only, and discards the trap information.

Optional
Enabled by default.

Optional
Configure the channel through info-center logbuffer By default, system information
which system information can [ channel { channel-number | is output to the log buffer
be output to the log buffer and channel-name } | size through channel 4 (known as
specify the buffer size buffersize ] * logbuffer) and the default buffer
size is 512.
info-center source
state } * ] *
Optional
timestamp trap and debugging information
is date by default.
21-10

Outputting System Information to the SNMP Module
The SNMP module receives the trap information only, and discards the log and debugging information
even if you have configured to output them to the SNMP module.
To monitor the device running status, trap information is usually sent to the SNMP network
management station (NMS). In this case, you need to configure to send traps to the SNMP module,
and then set the trap sending parameters for the SNMP module to further process traps. For details,
refer to SNMP Configuration in the System Volume.
Follow these steps to configure to output system information to the SNMP module:

Optional
Enabled by default

Optional
Configure the channel through info-center snmp channel By default, system information
which system information can { channel-number | is output to the SNMP module
be output to the SNMP module channel-name } through channel 5 (known as
snmpagent).
info-center source
state } * ] *
Optional
timestamp trap and debugging information
is date by default.
Configuring Synchronous Information Output
Synchronous information output refers to the feature that if the users input is interrupted by system
output such as log, trap, or debugging information, then after the completion of system output the
system will display a command line prompt (a prompt in command editing mode, or a [Y/N] string in
interaction mode) and your input so far.
This command is used in the case that your input is interrupted by a large amount of system output.
With this feature enabled, you can continue your operations from where you were stopped.
21-11

Follow these steps to enable synchronous information output:

Enable synchronous Required

info-center synchronous
information output Disabled by default
z If system information, such as log information, is output before you input any information under the
current command line prompt, the system will not display the command line prompt after the
system information output.
z If system information is output when you are inputting some interactive information (non Y/N
confirmation information), then after the system information output, the system will not display the
command line prompt but your previous input in a new line.
Disabling a Port from Generating Link Up/Down Logging Information
By default, all the ports of the device generate link up/down logging information when the port state
changes. Therefore, you may need to use this function in some cases, for example:
z You only concern the states of some of the ports. In this case, you can use this function to disable
the other ports from generating link up/down logging information.
z The state of a port is not stable, and therefore redundant logging information will be generated. In
this case, you can use this function to disable the port from generating link up/down logging
information.
Follow the steps below to disable a port from generating link up/down logging information:

interface-number
Required
Disable the port from By default, all ports are allowed
generating link up/down undo enable log updown to generate link up/down
logging information logging information when the
port state changes.
With this feature applied to a port, when the state of the port changes, the system does not generate
port link up/down logging information. In this case, you cannot monitor the port state changes
conveniently. Therefore, it is recommended to use the default configuration in normal cases.
21-12

Displaying and Maintaining Information Center
display channel
[ channel-number | Available in any view
information channels
channel-name ]
Display the information of each
display info-center Available in any view
output destination
display logbuffer [ reverse ]

Display the state of the log [ level severity | size buffersize
buffer and the log information | slot slot-number ] * [ | { begin Available in any view
recorded | exclude | include }
display logbuffer summary
Display a summary of the log
[ level severity | slot Available in any view
buffer
slot-number ] *
Display the content of the log
display logfile buffer Available in any view
file buffer
Display the configuration of the
display logfile summary Available in any view
log file
Display the state of the trap
display trapbuffer [ reverse ]
buffer and the trap information Available in any view
[ size buffersize ]
recorded
Reset the log buffer reset logbuffer Available in user view
Reset the trap buffer reset trapbuffer Available in user view
Information Center Configuration Examples

Outputting Log Information to a Unix Log Host
z Send log information to a Unix log host with an IP address of 1.2.0.1/16;

z Log information with severity higher than informational will be output to the log host;
z The source modules are ARP and IP.
Figure 21-1 Network diagram for outputting log information to a Unix log host
Before the configuration, make sure that there is a route between Device and PC.
1) Configure the device
# Enable information center.
21-13

[Sysname] info-center enable
# Specify the host with IP address 1.2.0.1/16 as the log host, use channel loghost to output log
information (optional, loghost by default), and use local4 as the logging facility.
[Sysname] info-center loghost 1.2.0.1 channel loghost facility local4
# Disable the output of log, trap, and debugging information of all modules on channel loghost.
[Sysname] info-center source default channel loghost debug state off log state off trap state
off
As the default system configurations for different channels are different, you need to disable the output
of log, trap, and debugging information of all modules on the specified channel (loghost in this
example) first and then configure the output rule as needed so that unnecessary information will not be
output.
# Configure the information output rule: allow log information of ARP and IP modules with severity
equal to or higher than informational to be output to the log host. (Note that the source modules
allowed to output information depend on the device model.)
[Sysname] info-center source arp channel loghost log level informational state on
[Sysname] info-center source ip channel loghost log level informational state on
2) Configure the log host
The following configurations were performed on SunOS 4.0 which has similar configurations to the
Unix operating systems implemented by other vendors.
Step 1: Log in to the log host as a root user.
Step 2: Create a subdirectory named Device under directory /var/log/, and create file info.log under
the Device directory to save logs of Device.
# mkdir /var/log/Device
# touch /var/log/Device/info.log
Step 3: Edit file /etc/syslog.conf and add the following contents.

# Device configuration messages
local4.info /var/log/Device/info.log
In the above configuration, local4 is the name of the logging facility used by the log host to receive
logs. info is the information level. The Unix system will record the log information with severity level
equal to or higher than informational to file /var/log/Device/info.log.
21-14

Be aware of the following issues while editing file /etc/syslog.conf:
z Comments must be on a separate line and begin with the # sign.
z No redundant spaces are allowed after the file name.
z The logging facility name and the information level specified in the /etc/syslog.conf file must be
identical to those configured on the device using the info-center loghost and info-center source
commands; otherwise the log information may not be output properly to the log host.
Step 4: After log file info.log is created and file /etc/syslog.conf is modified, you need to issue the
following commands to display the process ID of syslogd, kill the syslogd process and then restart
syslogd using the r option to make the modified configuration take effect.
# ps -ae | grep syslogd
147
# kill -HUP 147
# syslogd -r &
After the above configurations, the system will be able to record log information into the log file.
Outputting Log Information to a Linux Log Host
z Send log information to a Linux log host with an IP address of 1.2.0.1/16;

z Log information with severity higher than informational will be output to the log host;
z All modules can output log information.
Figure 21-2 Network diagram for outputting log information to a Linux log host
Before the configuration, make sure that there is a route between Device and PC.
1) Configure the device
# Specify the host with IP address 1.2.0.1/16 as the log host, use channel loghost to output log
information (optional, loghost by default), and use local5 as the logging facility.
[Sysname] info-center loghost 1.2.0.1 channel loghost facility local5
# Disable the output of log, trap, and debugging information of all modules on channel loghost.
21-15

[Sysname] info-center source default channel loghost debug state off log state off trap state
off
of log, trap, and debugging information of all modules on the specified channel (loghost in this
output.
# Configure the information output rule: allow log information of all modules with severity equal to or
higher than informational to be output to the log host.
[Sysname] info-center source default channel loghost log level informational state on
2) Configure the log host
Step 1: Log in to the log host as a root user.
Step 2: Create a subdirectory named Device under directory /var/log/, and create file info.log under
the Device directory to save logs of Device.
# mkdir /var/log/Device
# touch /var/log/Device/info.log
Step 3: Edit file /etc/syslog.conf and add the following contents.

# Device configuration messages
local5.info /var/log/Device/info.log
In the above configuration, local5 is the name of the logging facility used by the log host to receive
logs. info is the information level. The Linux system will record the log information with severity level
equal to or higher than informational to file /var/log/Device/info.log.
Be aware of the following issues while editing file /etc/syslog.conf:

z Comments must be on a separate line and begin with the # sign.
z No redundant spaces are allowed after the file name.
z The logging facility name and the information level specified in the /etc/syslog.conf file must be
identical to those configured on the device using the info-center loghost and info-center source
commands; otherwise the log information may not be output properly to the log host.
Step 4: After log file info.log is created and file /etc/syslog.conf is modified, you need to issue the
following commands to display the process ID of syslogd, kill the syslogd process, and restart
syslogd using the -r option to make the modified configuration take effect.
# ps -ae | grep syslogd
147
# kill -9 147
21-16

# syslogd -r &
Ensure that the syslogd process is started with the -r option on a Linux log host.
After the above configurations, the system will be able to record log information into the log file.
Outputting Log Information to the Console
z Log information with a severity higher than informational will be output to the console;
z The source modules are ARP and IP.
Figure 21-3 Network diagram for sending log information to the console

# Use channel console to output log information to the console (optional, console by default).
[Sysname] info-center console channel console
# Disable the output of log, trap, and debugging information of all modules on channel console.
[Sysname] info-center source default channel console debug state off log state off trap state
off
of log, trap, and debugging information of all modules on the specified channel (console in this
output.
# Configure the information output rule: allow log information of ARP and IP modules with severity
equal to or higher than informational to be output to the console. (Note that the source modules
allowed to output information depend on the device model.)
[Sysname] info-center source arp channel console log level informational state on
[Sysname] info-center source ip channel console log level informational state on
21-17

[Sysname] quit
# Enable the display of log information on a terminal. (Optional, this function is enabled by default.)
<Sysname> terminal monitor
% Current terminal monitor is on
<Sysname> terminal logging
% Current terminal logging is on
After the above configuration takes effect, if the specified module generates log information, the
information center automatically sends the log information to the console, which then displays the
information.
21-18

22 Hotfix Configuration
When configuring hotfix, go to these sections for information you are interested in:
z Hotfix Overview
z Hotfix Configuration Task List
z Displaying and Maintaining Hotfix
z Hotfix Configuration Examples
Hotfix Overview
Hotfix is a fast and cost-effective method to repair software defects of a device. Compared with another
method, software version upgrade, hotfix can upgrade the software without interrupting the running
services of the device, that is, it can repair the software defects of the current version without rebooting
the device.
Basic Concepts in Hotfix
Patch and patch file
A patch, also called patch unit, is a package to fix software defects. Generally, patches are released as
patch files A patch file may contain one or more patches for different defects. After loaded from the
Flash to the memory area, each patch is assigned a unique number, which starts from 1, for
identification, management, and operation. For example, if a patch file has three patch units, they will
be numbered as 1, 2, and 3 respectively.
Incremental patch
Patches in a patch file are all incremental patches. An incremental patch means that the patch is
dependent on the previous patch units. For example, if a patch file has three patch units, patch 3 can
be running only after patch 1 and 2 take effect. You cannot run patch 3 separately.
Common patch and temporary patch
Patches fall into two types, common patches and temporary patches.
z Common patches are those formally released through the version release flow.
z Temporary patches are those not formally released through the version release flow, but
temporarily provided to solve the emergent problems.
The common patches always include the functions of the previous temporary patches, so as to replace
them. The patch type affects the patch loading process only: the system will delete all the temporary
patches before it loads the common patch.
Patch Status
Each patch has its status, which can be switched by command lines. The relationship between patch
state changes and command actions is shown in Figure 22-1. The patch can be in the state of IDLE,
DEACTIVE, ACTIVE, and RUNNING. Load, run temporarily, confirm running, stop running, delete,
22-1

install, and uninstall represent operations, corresponding to commands of patch load, patch active,
patch run, patch deactive, patch delete, patch install, and undo patch install. For example, if you
execute the patch active command for the patches in the DEACTIVE state, the patches turn to the
ACTIVE state.
Figure 22-1 Relationship between patch state changes and command actions
Information about patch states is saved in file patchstate on the flash. It is recommended not to
operate this file.
IDLE state
Patches in the IDLE state are not loaded. You cannot install or run the patches, as shown in Figure
22-2 (suppose the memory patch area can load up to eight patches). The patches that are in the IDLE
state will be still in the IDLE state after system reboot.
22-2

Figure 22-2 Patches are not loaded to the memory patch area
Currently, the system patch area supports up to 200 patches.
DEACTIVE state
Patches in the DEACTIVE state have been loaded to the memory patch area but have not run in the
system yet. Suppose that there are seven patches in the patch file to be loaded. After the seven
patches successfully pass the version check and CRC check, they will be loaded to the memory patch
area and are in the DEACTIVE state. At this time, the patch states in the system are as shown in
Figure 22-3.
The patches that are in the DEACTIVE state will be still in the DEACTIVE state after system reboot.
Figure 22-3 A patch file is loaded to the memory patch area
ACTIVE state
Patches in the ACTIVE state are those that have run temporarily in the system and will become
DEACTIVE after system reboot. For the seven patches in Figure 22-3, if you activate the first five
patches, the state of them will change from DEACTIVE to ACTIVE. At this time, the patch states in the
system are as shown in Figure 22-4.
The patches that are in the ACTIVE state will be in the DEACTIVE state after system reboot.
22-3

Figure 22-4 Patches are activated
RUNNING state
After you confirm the running of the ACTIVE patches, the state of the patches will become RUNNING
and will be in the RUNNING state after system reboot. For the five patches in Figure 22-4, if you
confirm the running the first three patches, their states will change from ACTIVE to RUNNING. At this
time, the patch states of the system are as shown in Figure 22-5.
Figure 22-5 Patches are running
The patches that are in the RUNNING state will be still in the RUNNING state after system reboot.
Hotfix Configuration Task List

Task Remarks
One-Step Patch Installation Use either approach.
Install patches The step-by-step patch installation allows you
Step-by-Step Patch Installation to control the patch status.
One-Step Patch Uninstallation Use either approach.
Uninstall
patches The step-by-step patch uninstallation allows
Step-by-Step Patch Uninstallation you to control the patch status.
22-4

Patches are released per device model type. Before patching the system, you need to save the
appropriate patch files to the storage media of the device using FTP or TFTP. When saving the patch
files, note that:
z The patch files match the device model and software version. If they are not matched, the
hotfixing operation will fail.
z Name the patch file properly. Otherwise, the system cannot locate the patch file and the hotfixing
operation will fail. The name is in the format of "patch_PATCH-FLAG suffix.bin". The
PATCH-FLAG is pre-defined and support for the PATCH-FLAG depends on device model. The
first three characters of the version item (using the display patch information command)
represent the PATCH-FLAG suffix. The system searches the root directory of the storage medium
(flash by default) for patch files based on the PATCH-FLAG. If there is a match, the system loads
patches to or install them on the memory patch area.
Table 22-1 describes the default patch name for device.
Table 22-1 Default patch names for device
Product PATCH-FLAG Default patch name

4510G PATCH-XXX patch_xxx.bin
The loading and installation are performed on all member devices. Before these operations, save the
same patch files to the root directories in the storage media of all member devices.
One-Step Patch Installation

You can use the patch install command to install patches in one step. After you execute the command,
the system displays the message "Do you want to continue running patches after reboot? [Y/N]:".
z Entering y or Y: All the specified patches are installed, and turn to the RUNNING state from IDLE.
This equals execution of the commands patch location, patch load, patch active, and patch
run. The patches remain RUNNING after system reboot.
z Entering n or N: All the specified patches are installed and turn to the ACTIVE state from IDLE.
This equals execution of the commands patch location, patch load and patch active. The
patches turn to the DEACTIVE state after system reboot.
Follow these steps to install the patches in one step:

Install the patches in one step patch install patch-location Required
22-5

z The patch matches the device type and software version.
z The patch install command changes the patch file location specified with the patch location
command to the directory specified by the patch-location argument of the patch install command.
Step-by-Step Patch Installation

Step-by-Step Patch Installation Task List
Task Remarks
Configuring the Patch File Location Optional
Loading a Patch File Required
Activating Patches Required
Confirm Running Patches Optional
Configuring the Patch File Location
Follow these steps to configure the patch file location:

Configure the patch file Optional

patch location patch-location
location flash: by default
z The directory specified by the patch-location argument must exist on each member device. If one
member device does not have such directory, the system cannot locate the patch file on the
member device.
z The patch install command changes patch file location specified with the patch location
command to the directory specified by the patch-location argument of the patch install command.
For example, if you execute the patch location xxx command and then the patch install yyy
command, the patch file location automatically changes from xxx to yyy.
Loading a Patch File
Loading the right patch files is the basis of other hotfixing operations. The system loads a patch file
from the flash by default. It will failed if the system cannot find the patch file on the flash.
22-6

Set the file transfer mode to binary mode before using FTP or TFTP to upload/download patch files
to/from the flash of the device. Otherwise, patch file cannot be parsed properly.
Follow the steps below to load a patch file:

Load the patch file on from the storage medium
patch load slot slot-number Required
to the specified memory patch area
Activating Patches
After you activate a patch, the patch will take effect and is in the test-run stage. After the device is reset
or rebooted, the patch becomes invalid.
If you find that an ACTIVE patch is of some problem, you can reboot the device to deactivate the patch,
so as to avoid a series of running faults resulting from patch error.
Follow the steps below to activate patches:

Activate the specified patches patch active patch-number slot slot-number Required
Confirm Running Patches
After you confirm the running of a patch, the patch state becomes RUNNING, and the patch is in the
normal running stage. After the device is reset or rebooted, the patch is still valid.
Follow the steps below to confirm the running of patches:

Confirm the running of the patch run patch-number [ slot

Required
specified patches slot-number ]
This operation is applicable to patches in the ACTIVE state only.
22-7

One-Step Patch Uninstallation
You can use the undo patch install command to uninstall patches from all the member devices. The
patches then turn to the IDLE state. This equals the execution of the commands patch deactive and
patch delete on each member device.
Follow these steps to uninstall the patches in one step:

Uninstall the patches undo patch install Required
Step-by-Step Patch Uninstallation

Step-by-Step Patch Uninstallation Task List
Task Remarks
Stop Running Patches Required
Deleting Patches Required
Stop Running Patches
After you stop running a patch, the patch state becomes DEACTIVE, and the system runs in the way
before it is installed with the patch.
Follow the steps below to stop running patches:

Stop running the specified patch deactive patch-number

Required
patches slot slot-number
Deleting Patches
Deleting patches only removes the patches from the memory patch area, and does not delete them
from the storage medium. The patches turn to IDLE state after this operation. After a patch is deleted,
the system runs in the way before it is installed with the patch.
Follow the steps below to delete patches:

Delete the specified patches patch delete patch-number

Required
from the memory patch area slot slot-number
22-8

Displaying and Maintaining Hotfix
Display the patch information display patch information Available in any view
Hotfix Configuration Examples

Hotfix Configuration Example (Single Device)
z The software running on Device is of some problem, and thus hotfixing is needed.
z The patch file patch_xxx.bin is saved on the TFTP server.
z The IP address of Device is 1.1.1.1/24, and IP address of TFTP Server is 2.2.2.2/24. An available
route exists between Device and TFTP server.
Figure 22-6 Network diagram of hotfix configuration
1) Configure TFTP Server. Note that the configuration varies depending on server type and the
z Enable the TFTP server function.
z Save the patch file patch_xxx.bin to the directory of the TFTP server.
2) Configure Device
Make sure the free flash space of the device is big enough to store the patch file.
# Before upgrading the software, use the save command to save the current system configuration.
The configuration procedure is omitted.
# Load the patch file patch_xxx.bin from the TFTP server to the root directory of the device storage
medium.
<Device> tftp 2.2.2.2 get patch_xxx.bin
# Install the patch.

[Device] patch install flash:
Patches will be installed. Continue? [Y/N]:y
22-9

Do you want to continue running patches after reboot? [Y/N]:y
Installing patches........
Installation completed, and patches will continue to run after reboot.
Hotfix Configuration Example (IRF Device)
z IRF refers to an IRF in this example and it consists of two IRF devices, Master and Slave. The
software running on the IRF devices are of some problem, and thus hotfixing is needed.
z The patch file patch_xxx.bin is saved on the TFTP server.
z The IP address of IRF is 1.1.1.1/24, and IP address of TFTP Server is 2.2.2.2/24. An available
route exists between IRF and TFTP server.
Figure 22-7 Network diagram for hotfix configuration
1) Configure the TFTP server. Note that the configuration varies depending on server type, and the
z Enable the TFTP server function.
z Save the patch file patch_xxx.bin to the directory of TFTP server.
2) Configure Device.
Make sure the free flash space of the device is big enough to store the patch files.
# Before upgrading the software, use the save command to save the current system configuration.
The configuration procedure is omitted.
# Load the patch file patch_xxx.bin from the TFTP server to the root directory of the Master's storage
medium.
<Device> tftp 2.2.2.2 get patch_xxx.bin
# Load the patch file patch_xxx.bin from the TFTP server to the root directory of the Slave's storage
medium.
<Device> tftp 2.2.2.2 get patch_xxx.bin slot2#flash:/patch_xxx.bin
# Install the patch.

22-10

[Device] patch install flash:
Patches will be installed. Continue? [Y/N]:y
Do you want to continue running patches after reboot? [Y/N]:y
Installing patches........
Installation completed, and patches will continue to run after reboot.
22-11

23 NQA Configuration
When configuring NQA, go to these sections for information you are interested in:
z NQA Overview
z NQA Configuration Task List
z Configuring the NQA Server
z Enabling the NQA Client
z Creating an NQA Test Group
z Configuring an NQA Test Group
z Configuring the Collaboration Function
z Configuring Trap Delivery
z Configuring the NQA Statistics Function
z Configuring Optional Parameters Common to an NQA Test Group
z Scheduling an NQA Test Group
z Displaying and Maintaining NQA
z NQA Configuration Examples
NQA Overview
Introduction to NQA
Network Quality Analyzer (NQA) analyzes network performance, services and service quality through
sending test packets, and provides you with network performance and service quality parameters such
as jitter, TCP connection delay, FTP connection delay and file transfer rate.
With the NQA test results, you can:
1) Know network performance in time and then take corresponding measures.
2) Diagnose and locate network faults.
Features of NQA
Supporting multiple test types
Ping can use only the Internet Control Message Protocol (ICMP) to test the reachability of the
destination host and the roundtrip time of a packet to the destination. As an enhancement to the Ping
tool, NQA provides multiple test types and more functions.
At present, NQA supports ten test types: ICMP echo, DHCP, FTP, HTTP, UDP jitter, SNMP, TCP, UDP
echo, voice and DLSw.
In an NQA test, the client sends different types of test packets to the peer to detect the availability and
the response time of the peer, helping you know protocol availability and network performance based
on the test results.
Supporting the collaboration function
Collaboration is implemented by establishing collaboration objects to monitor the detection results of

the current test group. If the number of consecutive probe failures reaches a certain limit, NQAs
22-1

collaboration with other modules is triggered. The implementation of collaboration is shown in Figure
23-1.
Figure 23-1 Implementation of collaboration
The collaboration here involves three parts: the application modules, the Track module, and the
detection modules.
z The detection modules monitor the link status, network performance and so on, and inform the
Track module of the detection result.
z Upon receiving the detection result, the Track module changes the status of the Track object
accordingly and informs the application modules. The Track module works between the
application modules and the detection modules and is mainly used to obscure the difference of
various detection modules to provide a unified interface for application modules.
z The application modules then deal with the changes accordingly based on the status of the Track
object, and thus collaboration is implemented.
Take static routing as an example. You have configured a static route with the next hop 192.168.0.88. If
192.168.0.88 is reachable, the static route is valid; if 192.168.0.88 is unreachable, the static route is
invalid. With the collaboration between NQA, Track module and application modules, real time
monitoring of reachability of the static route can be implemented:
2) Monitor reachability of the destination 192.168.0.88 through NQA.
3) If 192.168.0.88 is detected to be unreachable, NQA will inform the static routing module through
Track module.
4) The static routing module then can know that the static route is invalid.
z At present, VRRP is not supported on Switch 4510G.

z For the detailed description of the Track module, see Track Configuration in the High Availability
Volume.
Supporting delivery of traps
You can set whether to send traps to the network management server when an NQA test is performed.
When a probe fails or a test is completed, the network management server can be notified, and the
network administrator can know the network running status and performance in time through the traps
sent.
22-2

Basic Concepts of NQA
Test group
Before performing an NQA test, you need to create an NQA test group, and configure NQA test
parameters such as test type, destination address and destination port.
Each test group has an administrator name and operation tag, which can uniquely define a test group.
Test and probe
After an NQA test is started, one test is performed at a regular interval and you can set the interval as
needed.
One NQA test involves multiple consecutive probes and you can set the number of the probes.
Only one probe can be made in one voice test.
In different test types, probe has different meanings:

z For a TCP or DLSw test, one probe means one connection;
z For a UDP jitter or a voice test, multiple packets are sent successively in one probe, and the
number of packets sent in one probe depends on the configuration of the probe packet-number
command;
z For an FTP, HTTP or DHCP test, one probe means to carry out a corresponding function;
z For an ICMP echo or UDP echo test, one packet is sent in one probe;
z For an SNMP test, three packets are sent in one probe.
NQA client and server
NQA client is the device initiating an NQA test and the NQA test group is created on the NQA client.
NQA server processes the test packets sent from the NQA client, as shown in Figure 23-2. The NQA
server makes a response to the request originated by the NQA client by listening to the specified
destination address and port number.
Figure 23-2 Relationship between the NQA client and NQA server
In most NQA tests, you only need to configure the NQA client; while in TCP, UDP echo, UDP jitter, and
voice tests, you must configure the NQA server.
You can create multiple TCP or UDP listening services on the NQA server, with each listening service
corresponding to a specified destination address and port number. The IP address and port number
specified for a listening service on the server must be consistent with those on the client and must be
different from those of an existing listening service.
22-3

NQA Test Operation
An NQA test operation is as follows:

1) The NQA client constructs packets with the specified type, and sends them to the peer device;
2) Upon receiving the packet, the peer device replies with a response with a timestamp.
3) The NQA client computes the packet loss rate and RTT based on whether it has received the
response and the timestamp in the response.
NQA Configuration Task List

For TCP, UDP jitter, UDP echo or voice tests, you need to configure the NQA server on the peer
device.
Follow these steps to enable the NQA server:
Task Remarks
Configuring the NQA Server Required for TCP, UDP echo, UDP jitter and voice tests
To perform an NQA test successfully, make the following configurations on the NQA client:
1) Enable the NQA client;
2) Create a test group and configure test parameters according to the test type. The test parameters
may vary with test types;
3) Start the NQA test;
After the test, you can view test results using the display or debug commands.
Complete these tasks to configure NQA client:
Task Remarks
Enabling the NQA Client Required
Creating an NQA Test Group Required
Configuring an ICMP Echo Test
Configuring a DHCP Test
Configuring an FTP Test
Configuring an HTTP Test
Configuring an NQA Configuring a UDP Jitter Test Required

Test Group Configuring an SNMP Test Use any of the approaches
Configuring a TCP Test

Configuring a UDP Echo Test
Configuring a Voice Test
Configuring a DLSw Test
Configuring the Collaboration Function Optional
Configuring Trap Delivery Optional
Configuring the NQA Statistics Function Optional
22-4

Task Remarks
Configuring Optional Parameters Common to an NQA Test Group Optional
Scheduling an NQA Test Group Required
Configuring the NQA Server

Before performing TCP, UDP echo, UDP jitter or voice tests, you need to configure the NQA server on
the peer device. The NQA server makes a response to the request originated by the NQA client by
listening to the specified destination address and port number.
Follow these steps to configure the NQA server:

Required
Enable the NQA server nqa server enable
Required
The IP address and port
Configure the UDP or TCP nqa server { tcp-connect | number must be consistent
listening function on the NQA udp-echo } ip-address with those configured on the
server port-number NQA client and must be
different from those of an
existing listening service.
Enabling the NQA Client

Configurations on the NQA client take effect only when the NQA client is enabled.
Follow these steps to enable the NQA client:

Optional
Enable the NQA client nqa agent enable
Enabled by default.
Creating an NQA Test Group

One test corresponds to one test group. You can configure test types after you create a test group and
enter the test group view.
Follow theses steps to create an NQA test group:

Create an NQA test group and nqa entry admin-name

Required
enter the NQA test group view operation-tag
22-5

If you execute the nqa entry command to enter the test group view with test type configured, you will
enter the test type view of the test group directly.
Configuring an NQA Test Group

Configuring an ICMP Echo Test
An ICMP echo test is used to test reachability of the destination host according to the ICMP echo reply
or timeout information. An ICMP echo test has the same function with the ping command but has more
abundant output information. You can use the ICMP echo test to locate connectivity problems in a
network.
Follow these steps to configure an ICMP echo test:

nqa entry admin-name
Enter NQA test group view
operation-tag
Configure the test type as
ICMP echo and enter test type type icmp-echo Required
view
Required
Configure the destination destination ip
address for a test operation ip-address By default, no destination IP address
is configured for a test operation.
Configure the size of probe Optional

data-size size
packets sent 100 bytes by default.
Optional
Configure the filler string of a By default, the filler string of a probe
data-fill string
probe packet sent packet is the hexadecimal number
00010203040506070809.
Optional
By default, no interface address is
specified as the source IP address of
ICMP probe requests.
Specify the IP address of an
source interface If you use the source ip command to
interface as the source IP
interface-type configure the source IP address of
address of an ICMP echo
interface-number ICMP echo probe requests, the
request
source interface command is invalid.
The interface specified by this
command must be up. Otherwise, the
probe will fail.
22-6

Optional
By default, no source IP address is
specified.
If no source IP address is specified,
but the source interface is specified,
Configure the source IP the IP address of the source interface
source ip ip-address
address of a probe request is taken as the source IP address of
ICMP probe requests.
The source IP address must be that of
an interface on the device and the
interface must be up. Otherwise, the
probe will fail.
Configure the next hop IP Optional

address for an ICMP echo next-hop ip-address By default, no next hop IP address is
request configured.
See Configuring
Configure common optional Optional Parameters
Optional
parameters Common to an NQA
Test Group
Configuring a DHCP Test
A DHCP test is mainly used to test the existence of a DHCP server on the network as well as the time
necessary for the DHCP server to respond to a client request and assign an IP address to the client.
Before performing a DHCP test, you need to configure the DHCP server. If the NQA (DHCP client) and
the DHCP server are not in the same network segment, you need to configure a DHCP relay. For the
configuration of DHCP server and DHCP relay, see DHCP Configuration in the IP Services Volume.
Configuring a DHCP test
Follow these steps to configure a DHCP test:

operation-tag
type dhcp Required
DHCP and enter test type view
Required
By default, no interface is
specified to perform a DHCP
Specify an interface for a operation interface test.
DHCP test interface-type interface-number The interface specified by the
source interface command
must be up; otherwise, the test
fails.
22-7

See Configuring Optional

Configure common optional
Parameters Common to an Optional
parameters
NQA Test Group
z As DHCP test is a process to simulate address allocation in DHCP, the IP address of the interface
performing the DHCP test will not be changed.
z After the DHCP test is completed, the NQA client will send a DHCP-RELEASE packet to release
the obtained IP address.
Configuring an FTP Test
An FTP test is mainly used to test the connection between the NQA client and a specified FTP server
and the time necessary for the FTP client to transfer a file to or download a file from the FTP server.
Before an FTP test, you need to perform some configurations on the FTP server. For example, you
need to configure the username and password used to log onto the FTP server. For the FTP server
configuration, see File System Management Configuration in the System Volume.
Configuring an FTP test
Follow these steps to configure an FTP test:

operation-tag
Configure the test type as FTP
type ftp Required
and enter test type view
Required
By default, no destination IP
address is configured for a test
Configure the destination
destination ip ip-address operation.
address for a test operation
The destination IP address for a test
operation is the IP address of the
FTP server.
Required
specified.
Configure the source IP
source ip ip-address The source IP address must be that
address of a probe request
of an interface on the device and
the interface must be up.
Otherwise, the test will fail.
22-8

Optional
Configure the operation type operation { get | put } By default, the operation type for
the FTP is get, that is, obtaining
files from the FTP server.
Required
Configure a login username username name By default, no login username is
configured.
Required
Configure a login password password password By default, no login password is
configured.
Specify a file to be transferred Required
between the FTP server and filename file-name
the FTP client By default, no file is specified.

Parameters Common to Optional
parameters
an NQA Test Group
z When you execute the put command, a file file-name with fixed size and content is created on the
FTP server; when you execute the get command, the device does not save the files obtained from
the FTP server.
z When you execute the get command, the FTP test cannot succeed if a file named file-name does
not exist on the FTP server.
z When you execute the get command, please use a file with a smaller size as a big file may result
in test failure because of timeout, or may affect other services because of occupying too much
network bandwidth.
Configuring an HTTP Test
An HTTP test is used to test the connection between the NQA client and a specified HTTP server and
the time required to obtain data from the HTTP server, thus detecting the connectivity and performance
of the HTTP server.
Before performing an HTTP test, you need to configure the HTTP server.
Configuring an HTTP test
Follow these steps to configure an HTTP test:

operation-tag
22-9


type http Required
HTTP and enter test type view
Required
Configure the destination
destination ip ip-address operation.
address for a test operation
The destination IP address for a test
operation is the IP address of the
HTTP server.
Optional
specified.
source ip ip-address The source IP address must be that
address of a probe request
of an interface on the device and
Optional
Configure the operation type operation { get | post } By default, the operation type for
the HTTP is get, that is, obtaining
data from the HTTP server.
Configure the website that an
url url Required
HTTP test visits
Optional
Configure the HTTP version
http-version v1.0 By default, HTTP 1.0 is used in an
used in the HTTP test
HTTP test.
parameters
an NQA Test Group
The TCP port number for the HTTP server must be 80 in an HTTP test. Otherwise, the test will fail.
Configuring a UDP Jitter Test
It is recommended not to perform an NQA UDP jitter test on known ports, namely, ports from 1 to 1023.
Otherwise, the NQA test will fail or the corresponding services of this port will be unavailable.
Real-time services such as voice and video have high requirements on delay jitters. With the UDP jitter
test, uni/bi-directional delay jitters can be obtained to judge whether a network can carry real-time
services.
22-10

Delay jitter refers to the difference between the interval of receiving two packets consecutively and the
interval of sending these two packets. The procedure of a UDP jitter test is as follows:
z The source sends packets at regular intervals to the destination port.
z The destination affixes a time stamp to each packet that it receives and then sends it back to the
source.
z Upon receiving the packet, the source calculates the delay jitter, and the network status can be
analyzed.
A UDP jitter test requires cooperation between the NQA server and the NQA client. Before the UDP
jitter test, make sure that the UDP listening function is configured on the NQA server. For the
configuration of the UDP listening function, see Configuring the NQA Server.
Configuring a UDP jitter test
Follow these steps to configure a UDP jitter test:


operation-tag
Configure the test type as UDP
type udp-jitter Required
jitter and enter test type view
Required
Configure the destination operation.
destination ip ip-address
address for a test operation The destination IP address
must be consistent with that of
the existing listening service on
the NQA server.
Required
By default, no destination port
number is configured for a test
Configure the destination port operation.
destination port port-number
for a test operation The destination port must be
consistent with that of the
existing listening service on the
NQA server.
Optional
Specify the source port number
source port port-number By default, no source port
for a request
number is specified.
Configure the size of a probe Optional

data-size size
packet sent 100 bytes by default.
Optional
Configure the filler string of a By default, the filler string of a
data-fill string probe packet is the
probe packet sent
hexadecimal number
00010203040506070809.
22-11

Configure the number of probe packet-number Optional
packets sent in a UDP jitter
probe packet-number 10 by default.
Configure the interval for Optional

probe packet-interval
sending packets in a UDP jitter
packet-interval 20 milliseconds by default.
probe
Configure the time for waiting Optional
probe packet-timeout
for a response in a UDP jitter
packet-timeout 3000 milliseconds by default.
test
Optional
By default, no source IP
address is specified.
address of a probe request in a source ip ip-address The source IP address must be
test operation that of an interface on the
device and the interface must
be up. Otherwise, the test will
fail.
parameters
NQA Test Group
The number of probes made in a UDP jitter test depends on the probe count command, while the
number of probe packets sent in each probe depends on the configuration of the probe
packet-number command.
Configuring an SNMP Test
An SNMP query test is used to test the time the NQA client takes to send an SNMP query packet to the
SNMP agent and then receive a response packet.
The SNMP agent function must be enabled on the device serving as an SNMP agent before an SNMP
test. For the configuration of SNMP agent, see SNMP Configuration in the System Volume.
Configuring an SNMP test
Follow these steps to configure an SNMP test:

operation-tag
type snmp Required
SNMP and enter test type view
22-12

Required
Configure the destination By default, no destination IP
address for a test operation address is configured for a test
operation.
Specify the source port number Optional

for a probe request in a test source port port-number By default, no source port
operation number is specified.
Optional
By default, no source IP address
Configure the source IP is specified.
test operation that of an interface on the device
and the interface must be up.
parameters
NQA Test Group
Configuring a TCP Test
A TCP test is used to test the TCP connection between the client and the specified port on the NQA
server and the setup time for the connection, thus judge the availability and performance of the
services provided on the specified port on the server.
A TCP test requires cooperation between the NQA server and the NQA client. The TCP listening
function needs to be configured on the NQA server before the TCP test. For the configuration of the
TCP listening function, see Configuring the NQA Server.
Configuring a TCP test
Follow these steps to configure a TCP test:


operation-tag
Configure the test type as TCP
type tcp Required
and enter test type view
Required
address for a test operation The destination address must be
the IP address of the listening
service configured on the NQA
server.
22-13

Required
destination port operation.
Configure the destination port
port-number The destination port number must
be consistent with port number of
the listening service configured on
the NQA server.
Optional
Configure the source IP specified.
address of a probe request in a source ip ip-address The source IP address must be that
test operation of an interface on the device and
parameters
an NQA Test Group
Configuring a UDP Echo Test
A UDP echo test is used to test the connectivity and roundtrip time of a UDP echo packet from the
client to the specified UDP port on the NQA server.
A UDP echo test requires cooperation between the NQA server and the NQA client. The UDP listening
function needs to be configured on the NQA server before the UDP echo test. For the configuration of
the UDP listening function, see Configuring the NQA Server.
Configuring a UDP echo test
Follow these steps to configure a UDP echo test


operation-tag
Configure the test type as UDP
type udp-echo Required
echo and enter test type view
Required
By default, no destination IP address is
Configure the destination destination ip configured for a test operation.
address for a test operation ip-address The destination address must be the IP
address of the listening service
configured on the NQA server.
22-14

Required
By default, no destination port number
destination port is configured for a test operation.
Configure the destination port
port-number The destination port number must be
the port number of the listening service
configured on the NQA server.
Configure the size of probe Optional

data-size size
packets sent 100 bytes by default.
Optional
Configure the filler string of a By default, the filler string of a probe
data-fill string
probe packet sent packet is the hexadecimal number
00010203040506070809.
Specify a source port number Optional

source port
for a probe request in a test By default, no source port number is
port-number
operation specified.
Optional
Configure the source IP specified.
address of a probe request in a source ip ip-address The source IP address must be that of
test operation an interface on the device and the
interface must be up. Otherwise, the
test will fail.
See Configuring
Configure common optional Optional Parameters
Optional
parameters Common to an NQA
Test Group
Configuring a Voice Test
It is recommended not to perform an NQA UDP jitter test on known ports, namely, ports from 1 to 1023.
Otherwise, the NQA test will fail or the corresponding services of these ports will be unavailable.
A voice test is used to test voice over IP (VoIP) network status, and collect VoIP network parameters so
that users can adjust the network according the network status. The procedure of a voice test is as
follows:
1) The source (NQA client) sends voice packets of G.711 A-law, G.711 -law or G.729 A-law codec
type at regular intervals to the destination (NQA server).
2) The destination affixes a time stamp to each packet that it receives and then sends it back to the
source.
3) Upon receiving the packets, the source calculates the delay jitter and delay by calculating the
difference between the interval for the destination to receive two successive packets and the
22-15

interval for the source to send these two successive packets, and thus the network status can be
analyzed.
The voice parameter values that indicate VoIP network status can also be calculated in a voice test,
including:
z Calculated Planning Impairment Factor (ICPIF): Measures attenuation of voice data in a network,
depending on packet loss and delay. A higher value represents a lower network quality.
z Mean Opinion Scores (MOS): Measures quality of a VoIP network. A MOS value can be evaluated
by using the ICPIF value, in the range 1 to 15. A higher value represents a higher quality of a VoIP
network.
The evaluation of voice quality depends on users tolerance to voice quality, and this factor should be
taken into consideration. For users with higher tolerance to voice quality, you can use the
advantage-factor command to configure the advantage factor. When the system calculates the ICPIF
value, this advantage factor is subtracted to modify ICPIF and MOS values and thus both the objective
and subjective factors are considered when you evaluate the voice quality.
A voice test requires cooperation between the NQA server and the NQA client. Before a voice test,
make sure that the UDP listening function is configured on the NQA server. For the configuration of
UDP listening function, see Configuring the NQA Server.
Configuring a voice test
Follow these steps to configure a voice test:

operation-tag
type voice Required
voice and enter test type view
Required
address for a test operation The destination IP address
must be consistent with that of
the existing listening service on
the NQA server.
Required
Configure the destination port operation.
destination port port-number
for a test operation The destination port must be
consistent with that of the
existing listening service on the
NQA server.
Optional
codec-type { g711a | g711u |
Configure the codec type By default, the codec type is
g729a }
G.711 A-law.
22-16

Configure the advantage factor Optional

for calculating MOS and ICPIF advantage-factor factor By default, the advantage
values factor is 0.
Optional
Specify the source IP address
for the requests in a test source ip ip-address The source IP address must be
operation that of an interface on the
fail.
Specify the source port number Optional

for the requests in a test source port port-number By default, no source port
operation number is specified.
Optional
By default, the probe packet
size depends on the codec
Configure the size of a probe type. The default packet size is
data-size size
packet to be sent 172 bytes for G.711A-law and
G.711 -law codec type, and is
32 bytes for G.729 A-law codec
type.
Optional
Configure the filler string of a By default, the filler string of a
data-fill string probe packet is the
probe packet sent
hexadecimal number
00010203040506070809.
Configure the number of probe packet-number Optional

packets sent in a voice probe packet-number 1000 by default.
probe packet-interval
sending packets in a voice
packet-interval 20 milliseconds by default.
probe
Configure the timeout for Optional
probe packet-timeout
waiting for a response in a
packet-timeout 5000 milliseconds by default.
voice test
parameters
NQA Test Group
Only one probe can be made in one voice test, and the number of probe packets sent in each probe
depends on the configuration of the probe packet-number command.
Configuring a DLSw Test
A DLSw test is used to test the response time of the DLSw device.
22-17

Enable the DLSw function on the peer device before DLSw test.
Configuring a DLSw test
Follow these steps to configure a DLSw test:


operation-tag
type dlsw Required
DLSw and enter test type view
Required
Configure the destination By default, no destination IP
address for a test operation address is configured for a test
operation.
Optional
test operation that of an interface on the
fail.
parameters
NQA Test Group
Configuring the Collaboration Function

Collaboration is implemented by establishing collaboration objects to monitor the detection results of
the current test group. If the number of consecutive probe failures reaches the threshold, the
configured action is triggered.
Follow these steps to configure the collaboration function:

Enter NQA test group view nqa entry admin-name operation-tag
The collaboration function
Enter test type view of the type { dhcp | dlsw | ftp | http |
is not supported in UDP
test group icmp-echo | snmp | tcp | udp-echo }
jitter or voice tests.
reaction item-num checked-element

Create a collaboration probe-fail threshold-type Required
object consecutive occurrences [ action-type Not created by default.
{ none | trigger-only } ]
22-18

Create a Track object and
associate it with the track entry-number nqa entry Required
specified collaboration admin-name operation-tag reaction
object of the NQA test item-num Not created by default.
group
z You cannot modify the content of a reaction entry using the reaction command after the
collaboration object is created.
z The collaboration function is not supported in a UDP jitter or voice test.
Configuring Trap Delivery

Traps can be sent to the network management server when test is completed, test fails or probe fails.
Before configuring trap delivery, you need to configure the destination address of the trap message
with the snmp-agent target-host command, create an NQA test group, and configure related
parameters. For the introduction to the snmp-agent target-host command, see SNMP Commands in
the System Volume.
Configuring trap delivery
Follow these steps to configure trap delivery:

operation-tag
type { dhcp | dlsw | ftp | http |
Enter test type view of the test
icmp-echo | snmp | tcp |
group
udp-echo | udp-jitter | voice }
reaction trap { probe-failure Optional

Configure to send traps to
consecutive-probe-failures | No traps are sent to the
network management server
test-complete | test-failure network management server
under specified conditions
cumulate-probe-failures } by default.
Only the reaction trap test-complete command is supported in a voice test, namely, in a voice test,
traps are sent to the NMS only if the test succeeds.
22-19

Configuring the NQA Statistics Function
NQA puts the NQA tests completed in a specified interval into one group, and calculates the statistics
of the test results of the group. These statistics form a statistics group. You can use the display nqa
statistics command to view information of the statistics group, and use the statistics interval
command to set the interval for collecting statistics.
When the number of statistics groups kept reaches the upper limit, if a new statistics group is
generated, the statistics group that is kept for the longest time is deleted. You can use the statistics
max-group command to set the maximum number of statistics groups that can be kept.
A statistics group is formed after the last test is completed within the specified interval. A statistics
group has the aging mechanism. A statistics group will be deleted after it is kept for a period of time.
You can use the statistics hold-time command to set the hold time of a statistics group.
Follow these steps to configure the NQA statistics function:

operation-tag
type { dlsw | ftp | http |
Enter test type view of the test
group
collecting the statistics of the statistics interval interval
test results 60 minutes by default.
Optional
Configure the maximum 2 by default.
number of statistics groups that statistics max-group number If the maximum number is 0, it
can be kept indicates that no statistics is
performed.
Configure the hold time of a Optional

statistics hold-time hold-time
statistics group 120 minutes by default.
z The NQA statistics function is not supported in a DHCP test.

z If you specify the interval argument in the frequency interval command as 0, no statistics group
information is generated.
Configuring Optional Parameters Common to an NQA Test Group

Optional parameters common to an NQA test group are valid only for tests in this test group.
Unless otherwise specified, the following parameters are applicable to all test types and they can be
configured according to the actual conditions.
Follow these steps to configure optional parameters common to an NQA test group:
22-20

operation-tag
type { dhcp | dlsw | ftp | http |
Enter test type view of a test
group
Optional
Configure the descriptive string
description text By default, no descriptive string
for a test group
is available for a test group.
Optional
By default, the interval between
two consecutive tests for a test
group is 0 milliseconds, that is,
Configure the interval between
only one test is performed.
two consecutive tests for a test frequency interval
group If the last test is not completed
when the interval specified by
the frequency command is
reached, a new test is not
started.
Optional
By default, one probe is
performed in a test.
Configure the number of
probe count times Only one probe can be made in
probes in an NQA test
one voice test. Therefore, this
command is not available in a
voice test.
Optional
By default, the timeout time is
Configure the NQA probe
probe timeout timeout 3000 milliseconds.
timeout time
This parameter is not available
for a UDP jitter test.
number of history records that history-records number
can be saved in a test group 50 by default.
Optional
20 by default.
number of hops a probe packet ttl value
traverses in the network This parameter is not available
for a DHCP test.
Optional
Configure the ToS field in an IP
0 by default.
packet header in an NQA tos value
probe packet This parameter is not available
for a DHCP test.
Optional
Enable the routing table Disabled by default.
route-option bypass-route
bypass function This parameter is not available
for a DHCP test.
22-21

Scheduling an NQA Test Group
With this configuration, you can set the start time and test duration for a test group to perform NQA
tests. The start time can take a specific value or can be now, which indicates that a test is started
immediately; the test duration can take a specific value or can be forever, which indicates that a test
will not stop until you use the undo nqa schedule command to stop the test.
A test group performs tests when the system time is between the start time and the end time (the start
time plus test duration). If the system time is behind the start time when you execute the nqa schedule
command, a test is started when the system time reaches the start time; if the system time is between
the start time and the end time, a test is started at once; if the system time is ahead of the end time, no
test is started. You can use the display clock command to view the current system time.
Before scheduling an NQA test group, make sure:

z Required test parameters corresponding to a test type have been configured;
z For the test which needs the cooperation with the NQA server, configuration on the NQA server
has been completed.
Scheduling an NQA test group
Follow these steps to schedule an NQA test group:

nqa schedule admin-name operation-tag

Schedule an NQA test group start-time { hh:mm:ss [ yyyy/mm/dd ] | Required
now } lifetime { lifetime | forever }
number of the tests that the Optional
nqa agent max-concurrent number
NQA client can simultaneously 2 by default.
perform
z After an NQA test group is scheduled, you cannot enter the test group view or test type view.
z A started test group or a test group that has completed tests will not be influenced by the system
time change; only a test group that is waiting to perform tests will be influenced by the system time
change.
22-22

Displaying and Maintaining NQA
Display history records of NQA display nqa history [ admin-name
test operation information operation-tag ]
Display the results of the last display nqa result [ admin-name
NQA test operation-tag ] Available in any
view
Display the statistics of a type display nqa statistics [ admin-name
of NQA test operation-tag ]
Display NQA server status display nqa server status
NQA Configuration Examples

ICMP Echo Test Configuration Example
Use the NQA ICMP function to test whether the NQA client (Device A) can send packets to the
specified destination (Device B) and test the roundtrip time of packets.
Figure 23-3 Network diagram for ICMP echo tests
# Create an ICMP echo test group and configure related test parameters.
[DeviceA] nqa entry admin test
[DeviceA-nqa-admin-test] type icmp-echo
[DeviceA-nqa-admin-test-icmp-echo] destination ip 10.2.2.2
# Configure optional parameters.

[DeviceA-nqa-admin-test-icmp-echo] probe count 10
[DeviceA-nqa-admin-test-icmp-echo] probe timeout 500
[DeviceA-nqa-admin-test-icmp-echo] frequency 5000
[DeviceA-nqa-admin-test-icmp-echo] history-records 10
[DeviceA-nqa-admin-test-icmp-echo] quit
# Enable ICMP echo test.

[DeviceA] nqa schedule admin test start-time now lifetime forever
# Disable ICMP echo test after the test begins for a period of time.
[DeviceA] undo nqa schedule admin test
# Display results of the last ICMP echo test.

[DeviceA] display nqa result admin test
22-23

NQA entry(admin admin, tag test) test results:
Destination IP address: 10.2.2.2
Send operation times: 10 Receive response times: 10
Min/Max/Average round trip time: 2/5/3
Square-Sum of round trip time: 96
Last succeeded probe time: 2007-08-23 15:00:01.2
Extended results:
Packet lost in test: 0%
Failures due to timeout: 0
Failures due to disconnect: 0
Failures due to no connection: 0
Failures due to sequence error: 0
Failures due to internal error: 0
Failures due to other errors: 0
Packet(s) arrived late: 0
# Display the history of ICMP echo tests.

[DeviceA] display nqa history admin test
NQA entry(admin admin, tag test) history record(s):
Index Response Status Time
370 3 Succeeded 2007-08-23 15:00:01.2
369 3 Succeeded 2007-08-23 15:00:01.2
368 3 Succeeded 2007-08-23 15:00:01.2
367 5 Succeeded 2007-08-23 15:00:01.2
366 3 Succeeded 2007-08-23 15:00:01.2
365 3 Succeeded 2007-08-23 15:00:01.2
364 3 Succeeded 2007-08-23 15:00:01.1
363 2 Succeeded 2007-08-23 15:00:01.1
362 3 Succeeded 2007-08-23 15:00:01.1
361 2 Succeeded 2007-08-23 15:00:01.1
DHCP Test Configuration Example
Use the NQA DHCP function to test the time necessary for Switch A to obtain an IP address from the
DHCP server Switch B.
Figure 23-4 Network diagram for DHCP
NQA client DHCP server

Vlan-int2 Vlan-int2
10.1.1.1/16 10.2.2.2/16
IP network
Switch A Switch B
# Create a DHCP test group and configure related test parameters.

22-24

[SwitchA-nqa-admin-test] type dhcp
[SwitchA-nqa-admin-test-dhcp] operation interface vlan-interface 2
[SwitchA-nqa-admin-test-dhcp] quit
# Enable DHCP test.

# Disable DHCP test after the test begins for a period of time.
[SwitchA] undo nqa schedule admin test
# Display the result of the last DHCP test.

[SwitchA] display nqa result admin test
Extended results:
# Display the history of DHCP tests.

[SwitchA] display nqa history admin test
1 624 Succeeded 2007-11-22 09:56:03.2
FTP Test Configuration Example
Use the NQA FTP function to test the connection with a specified FTP server and the time necessary
for Device A to upload a file to the FTP server. The login username is admin, the login password is
systemtest, and the file to be transferred to the FTP server is config.txt.
Figure 23-5 Network diagram for FTP tests
# Create an FTP test group and configure related test parameters.

22-25

[DeviceA-nqa-admin-test] type ftp
[DeviceA-nqa-admin-test-ftp] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-ftp] source ip 10.1.1.1
[DeviceA-nqa-admin-test-ftp] operation put
[DeviceA-nqa-admin-test-ftp] username admin
[DeviceA-nqa-admin-test-ftp] password systemtest
[DeviceA-nqa-admin-test-ftp] filename config.txt
[DeviceA-nqa-admin-test-ftp] quit
# Enable FTP test.

# Disable FTP test after the test begins for a period of time.
# Display results of the last FTP test.

Extended results:
# Display the history of FTP tests.

1 173 Succeeded 2007-11-22 10:07:28.6
HTTP Test Configuration Example
Use the HTTP function to test the connection with a specified HTTP server and the time required to
obtain data from the HTTP server.
22-26

Figure 23-6 Network diagram for the HTTP tests
# Create an HTTP test group and configure related test parameters.

[DeviceA-nqa-admin-test] type http
[DeviceA-nqa-admin-test-http] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-http] operation get
[DeviceA-nqa-admin-test-http] url /index.htm
[DeviceA-nqa-admin-test-http] http-version v1.0
[DeviceA-nqa-admin-test-http] quit
# Enable HTTP test.

# Disable HTTP test after the test begins for a period of time.
# Display results of the last HTTP test.

Extended results:
Failures due to other errors:
# Display the history of HTTP tests.

1 64 Succeeded 2007-11-22 10:12:47.9
22-27

UDP Jitter Test Configuration Example
Use the NQA UDP jitter function to test the delay jitter of packet transmission between Device A and
Device B.
Figure 23-7 Network diagram for UDP jitter tests
1) Configure Device B.
# Enable the NQA server and configure the listening IP address as 10.2.2.2 and port number as 9000.
[DeviceB] nqa server enable
[DeviceB] nqa server udp-echo 10.2.2.2 9000
2) Configure Device A.
# Create a UDP jitter test group and configure related test parameters.
[DeviceA-nqa-admin-test] type udp-jitter
[DeviceA-nqa-admin-test-udp-jitter] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-udp-jitter] destination port 9000
[DeviceA-nqa-admin-test-udp-jitter] frequency 1000
[DeviceA-nqa-admin-test-udp-jitter] quit
# Enable UDP jitter test.

# Disable UDP jitter test after the test begins for a period of time.
# Display the result of the last UDP jitter test.

Extended results:
22-28

UDP-jitter results:
RTT number: 10
Min positive SD: 4 Min positive DS: 1
Max positive SD: 21 Max positive DS: 28
Positive SD number: 5 Positive DS number: 4
Positive SD sum: 52 Positive DS sum: 38
Positive SD average: 10 Positive DS average: 10
Positive SD square sum: 754 Positive DS square sum: 460
Min negative SD: 1 Min negative DS: 6
Max negative SD: 13 Max negative DS: 22
Negative SD number: 4 Negative DS number: 5
Negative SD sum: 38 Negative DS sum: 52
Negative SD average: 10 Negative DS average: 10
Negative SD square sum: 460 Negative DS square sum: 754
One way results:
Max SD delay: 15 Max DS delay: 16
Min SD delay: 7 Min DS delay: 7
Number of SD delay: 10 Number of DS delay: 10
Sum of SD delay: 78 Sum of DS delay: 85
Square sum of SD delay: 666 Square sum of DS delay: 787
SD lost packet(s): 0 DS lost packet(s): 0
Lost packet(s) for unknown reason: 0
# Display the statistics of UDP jitter tests.

[DeviceA] display nqa statistics admin test
NQA entry(admin admin, tag test) test statistics:
NO. : 1
Start time: 2008-05-29 13:56:14.0
Life time: 47
Extended results:
UDP-jitter results:
RTT number: 410
22-29

One way results:
The display nqa history command cannot show you the results of UDP jitter tests. Therefore, to know
the result of a UDP jitter test, you are recommended to use the display nqa result command to view
the probe results of the latest NQA test, or use the display nqa statistics command to view the
statistics of NQA tests.
SNMP Test Configuration Example
Use the NQA SNMP query function to test the time it takes for Device A to send an SNMP query packet
to the SNMP agent and receive a response packet.
Figure 23-8 Network diagram for SNMP tests
1) Configurations on SNMP agent.

# Enable the SNMP agent service and set the SNMP version to all, the read community to public, and
the write community to private.
22-30

[DeviceB] snmp-agent sys-info version all
[DeviceB] snmp-agent community read public
[DeviceB] snmp-agent community write private
2) Configurations on Device A.
# Create an SNMP query test group and configure related test parameters.
[DeviceA-nqa-admin-test] type snmp
[DeviceA-nqa-admin-test-snmp] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-snmp] quit
# Enable SNMP query test.

# Disable SNMP query test after the test begins for a period of time.
# Display results of the last SNMP test.

Extended results:
# Display the history of SNMP tests.

1 50 Timeout 2007-11-22 10:24:41.1
TCP Test Configuration Example
Use the NQA TCP function to test the time for establishing a TCP connection between Device A and
Device B. The port number used is 9000.
22-31

Figure 23-9 Network diagram for TCP tests
[DeviceB] nqa server tcp-connect 10.2.2.2 9000
# Create a TCP test group and configure related test parameters.
[DeviceA-nqa-admin-test] type tcp
[DeviceA-nqa-admin-test-tcp] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-tcp] destination port 9000
[DeviceA-nqa-admin-test-tcp] quit
# Enable TCP test.

# Disable TCP test after the test begins for a period of time.
# Display results of the last TCP test.

Extended results:
# Display the history of TCP tests.

22-32

1 13 Succeeded 2007-11-22 10:27:25.1
UDP Echo Test Configuration Example
Use the NQA UDP echo function to test the round trip time between Device A and Device B. The port
number is 8000.
Figure 23-10 Network diagram for the UDP echo tests
# Create a UDP echo test group and configure related test parameters.
[DeviceA-nqa-admin-test] type udp-echo
[DeviceA-nqa-admin-test-udp-echo] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-udp-echo] destination port 8000
[DeviceA-nqa-admin-test-udp-echo] quit
# Enable UDP echo test.

# Disable UDP echo test after the test begins for a period of time.
# Display results of the last UDP echo test.

Extended results:
22-33

# Display the history of UDP echo tests.

1 25 Succeeded 2007-11-22 10:36:17.9
Voice Test Configuration Example
Use the NQA voice function to test the delay jitter of voice packet transmission and voice quality
between Device A and Device B.
Figure 23-11 Network diagram for voice tests
# Create a voice test group and configure related test parameters.
[DeviceA-nqa-admin-test] type voice
[DeviceA-nqa-admin-test-voice] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-voice] destination port 9000
[DeviceA-nqa-admin-test-voice] quit
# Enable voice test.

# Disable the voice test after the test begins for a period of time.
# Display the result of the last voice test.

22-34

Extended results:
Voice results:
RTT number: 1000
One way results:
Voice scores:
MOS value: 4.38 ICPIF value: 0
# Display the statistics of voice tests.

[DeviceA] display nqa statistics admin test
NQA entry(admin admin, tag test) test statistics:
NO. : 1
Start time: 2008-06-13 09:45:37.8
Life time: 331
22-35

Extended results:
Voice results:
RTT number: 4000
One way results:
Voice scores:
Max MOS value: 4.38 Min MOS value: 4.38
Max ICPIF value: 0 Min ICPIF value: 0
The display nqa history command cannot show you the results of voice tests. Therefore, to know the
result of a voice test, you are recommended to use the display nqa result command to view the probe
results of the latest NQA test, or use the display nqa statistics command to view the statistics of NQA
tests.
22-36

DLSw Test Configuration Example
Use the NQA DLSw function to test the response time of the DLSw device.
Figure 23-12 Network diagram for the DLSw tests
# Create a DLSw test group and configure related test parameters.

[DeviceA-nqa-admin-test] type dlsw
[DeviceA-nqa-admin-test-dlsw] destination ip 10.2.2.2
[DeviceA-nqa-admin-test-dlsw] quit
# Enable DLSw test.

# Disable DLSw test after the test begins for a period of time.
# Display the result of the last DLSw test.

Extended results:
# Display the history of DLSw tests.

1 19 Succeeded 2007-11-22 10:40:27.7
22-37

NQA Collaboration Configuration Example
As shown in Figure 23-13, configure a static route to Switch C on Switch A, with Switch B as the next
hop. Associate the static route, track entry, and NQA test group to verify whether static route is active
in real time.
Figure 23-13 Network diagram for NQA collaboration configuration example
Switch B
Vlan-int3 Vlan-int2
10.2.1.1/24 10.1.1.1/24
Vlan-int3 Vlan-int2
10.2.1.2/24 10.1.1.2/24
Switch A Switch C
1) Assign each interface an IP address. (omitted)

2) On Switch A, configure a unicast static route and associate the static route with a track entry.
# Configure a static route, whose destination address is 10.2.1.1, and associate the static route with
track entry 1.
[SwitchA] ip route-static 10.1.1.2 24 10.2.1.1 track 1
3) On Switch A, create an NQA test group.
# Create an NQA test group with the administrator name being admin and operation tag being test.
# Configure the test type of the NQA test group as ICMP echo.
[SwitchA-nqa-admin-test] type icmp-echo
# Configure the destination IP address of the ICMP echo test operation as 10.2.1.1.
[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.2.1.1
# Configure the interval between two consecutive tests as 100 milliseconds.

[SwitchA-nqa-admin-test-icmp-echo] frequency 100
# Create collaboration entry 1. If the number of consecutive probe failures reaches 5, collaboration
with other modules is triggered.
[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type
consecutive 5 action-type trigger-only
[SwitchA-nqa-admin-test-icmp-echo] quit
# Configure the test start time and test duration for the test group.
4) On Switch A, create the Track entry.
# Create Track entry 1 to associate it with Reaction entry 1 of the NQA test group (admin-test).
22-38

[SwitchA] track 1 nqa entry admin test reaction 1
5) Verify the configuration.
# On Switch A, display information about all the Track entries.
Track ID: 1
Status: Positive
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
Reaction: 1
# Display brief information about active routes in the routing table on Switch A.
10.1.1.0/24 Static 60 0 10.2.1.1 Vlan3

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3
10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The above information shows that the static route with the next hop 10.2.1.1 is active, and the status of
the track entry is positive. The static route configuration works.
# Remove the IP address of VLAN-interface 3 on Switch B.
[SwitchB-Vlan-interface3] undo ip address
# On Switch A, display information about all the Track entries.

Track ID: 1
Status: Negative
Notification delay: Positive 0, Negative 0 (in seconds)
Reference object:
Reaction: 1
# Display brief information about active routes in the routing table on Switch A.
10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
22-39

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The above information shows that the next hop 10.2.1.1 of the static route is not reachable, and the
status of the track entry is negative. The static route does not work.
22-40

24 NTP Configuration
When configuring NTP, go to these sections for information you are interested in:
z NTP Overview
z NTP Configuration Task List
z Configuring the Operation Modes of NTP
z Configuring Optional Parameters of NTP
z Configuring Access-Control Rights
z Configuring NTP Authentication
z Displaying and Maintaining NTP
z NTP Configuration Examples
NTP Overview
Defined in RFC 1305, the Network Time Protocol (NTP) synchronizes timekeeping among distributed
time servers and clients. NTP runs over the User Datagram Protocol (UDP), using UDP port 123.
The purpose of using NTP is to keep consistent timekeeping among all clock-dependent devices within
the network so that the devices can provide diverse applications based on the consistent time.
For a local system running NTP, its time can be synchronized by other reference sources and can be
used as a reference source to synchronize other clocks.
Applications of NTP
An administrator can by no means keep time synchronized among all the devices within a network by
changing the system clock on each station, because this is a huge amount of workload and cannot
guarantee the clock precision. NTP, however, allows quick clock synchronization within the entire
network while it ensures a high clock precision.
NTP is used when all devices within the network must be consistent in timekeeping, for example:
z In analysis of the log information and debugging information collected from different devices in
network management, time must be used as reference basis.
z All devices must use the same reference clock in a charging system.
z To implement certain functions, such as scheduled restart of all devices within the network, all
devices must be consistent in timekeeping.
z When multiple systems process a complex event in cooperation, these systems must use that
same reference clock to ensure the correct execution sequence.
z For incremental backup between a backup server and clients, timekeeping must be synchronized
between the backup server and all the clients.
Advantages of NTP
z NTP uses a stratum to describe the clock precision, and is able to synchronize time among all
devices within the network.
z NTP supports access control and MD5 authentication.
24-1

z NTP can unicast, multicast or broadcast protocol messages.
How NTP Works
Figure 24-1 shows the basic workflow of NTP. Device A and Device B are interconnected over a
network. They have their own independent system clocks, which need to be automatically
synchronized through NTP. For an easy understanding, we assume that:
z Prior to system clock synchronization between Device A and Device B, the clock of Device A is set
to 10:00:00 am while that of Device B is set to 11:00:00 am.
z Device B is used as the NTP time server, namely, Device A synchronizes its clock to that of
Device B.
z It takes 1 second for an NTP message to travel from one device to the other.
Figure 24-1 Basic work flow of NTP
NTP message 10:00:00 am
IP network
1. Device A Device B
NTP message 10:00:00 am 11:00:01 am
IP network
NTP message 10:00:00 am 11:00:01 am 11:00:02 am
IP network
Device A Device B
3.
NTP message received at 10:00:03 am
IP network
The process of system clock synchronization is as follows:

z Device A sends Device B an NTP message, which is timestamped when it leaves Device A. The
time stamp is 10:00:00 am (T1).
z When this NTP message arrives at Device B, it is timestamped by Device B. The timestamp is
11:00:01 am (T2).
z When the NTP message leaves Device B, Device B timestamps it. The timestamp is 11:00:02 am
(T3).
z When Device A receives the NTP message, the local time of Device A is 10:00:03 am (T4).
Up to now, Device A has sufficient information to calculate the following two important parameters:
z The roundtrip delay of NTP message: Delay = (T4T1) (T3-T2) = 2 seconds.
z Time difference between Device A and Device B: Offset = ((T2-T1) + (T3-T4))/2 = 1 hour.
Based on these parameters, Device A can synchronize its own clock to the clock of Device B.
This is only a rough description of the work mechanism of NTP. For details, refer to RFC 1305.
24-2

NTP Message Format
NTP uses two types of messages, clock synchronization message and NTP control message. An NTP
control message is used in environments where network management is needed. As it is not a must for
clock synchronization, it will not be discussed in this document.
All NTP messages mentioned in this document refer to NTP clock synchronization messages.
A clock synchronization message is encapsulated in a UDP message, in the format shown in Figure
24-2.
Figure 24-2 Clock synchronization message format
0 1 4 7 15 23 31
LI VN Mode Stratum Poll Precision
Root delay (32 bits)
Root dispersion (32 bits)
Reference identifier (32 bits)
Reference timestamp (64 bits)
Originate timestamp (64 bits)
Receive timestamp (64 bits)
Transmit timestamp (64 bits)
Authenticator (optional 96 bits)
Main fields are described as follows:

z LI: 2-bit leap indicator. When set to 11, it warns of an alarm condition (clock unsynchronized);
when set to any other value, it is not to be processed by NTP.
z VN: 3-bit version number, indicating the version of NTP. The latest version is version 3.
z Mode: a 3-bit code indicating the work mode of NTP. This field can be set to these values: 0
reserved; 1 symmetric active; 2 symmetric passive; 3 client; 4 server; 5 broadcast or
multicast; 6 NTP control message; 7 reserved for private use.
z Stratum: an 8-bit integer indicating the stratum level of the local clock, with the value ranging from
1 to 16. The clock precision decreases from stratum 1 through stratum 16. A stratum 1 clock has
the highest precision, and a stratum 16 clock is not synchronized and cannot be used as a
reference clock.
24-3

z Poll: 8-bit signed integer indicating the poll interval, namely the maximum interval between
successive messages.
z Precision: an 8-bit signed integer indicating the precision of the local clock.
z Root Delay: roundtrip delay to the primary reference source.
z Root Dispersion: the maximum error of the local clock relative to the primary reference source.
z Reference Identifier: Identifier of the particular reference source.
z Reference Timestamp: the local time at which the local clock was last set or corrected.
z Originate Timestamp: the local time at which the request departed from the client for the service
host.
z Receive Timestamp: the local time at which the request arrived at the service host.
z Transmit Timestamp: the local time at which the reply departed from the service host for the client.
z Authenticator: authentication information.
Operation Modes of NTP
Devices running NTP can implement clock synchronization in one of the following modes:
z Client/server mode
z Symmetric peers mode
z Broadcast mode
z Multicast mode
You can select operation modes of NTP as needed. In case that the IP address of the NTP server or
peer is unknown and many devices in the network need to be synchronized, you can adopt the
broadcast or multicast mode; while in the client/server and symmetric peers modes, a device is
synchronized from the specified server or peer, and thus clock reliability is enhanced.
Client/server mode
Figure 24-3 Client/server mode
When working in the client/server mode, a client sends a clock synchronization message to servers,
with the Mode field in the message set to 3 (client mode). Upon receiving the message, the servers
automatically work in the server mode and send a reply, with the Mode field in the messages set to 4
(server mode). Upon receiving the replies from the servers, the client performs clock filtering and
selection, and synchronizes its local clock to that of the optimal reference source.
In this mode, a client can be synchronized to a server, but not vice versa.
24-4

Symmetric peers mode
Figure 24-4 Symmetric peers mode
A device working in the symmetric active mode periodically sends clock synchronization messages,
with the Mode field in the message set to 1 (symmetric active); the device that receives this message
automatically enters the symmetric passive mode and sends a reply, with the Mode field in the
message set to 2 (symmetric passive). By exchanging messages, the symmetric peers mode is
established between the two devices. Then, the two devices can synchronize, or be synchronized by
each other. If the clocks of both devices have been already synchronized, the device whose local clock
has a lower stratum level will synchronize the clock of the other device.
Broadcast mode
Figure 24-5 Broadcast mode
Server Client
Network
After receiving the first
Periodically broadcasts clock broadcast message, the
synchronization messages (Mode 5) client sends a request
Clock synchronization message Calculates the network delay

exchange (Mode 3 and Mode 4) between client and the server
and enters the broadcast
client mode
Periodically broadcasts clock
synchronization messages (Mode 5) Receives broadcast
messages and synchronizes
its local clock
In the broadcast mode, a server periodically sends clock synchronization messages to the broadcast
address 255.255.255.255, with the Mode field in the messages set to 5 (broadcast mode). Clients
listen to the broadcast messages from servers. After a client receives the first broadcast message, the
client and the server start to exchange messages, with the Mode field set to 3 (client mode) and 4
(server mode) to calculate the network delay between client and the server. Then, the client enters the
broadcast client mode and continues listening to broadcast messages, and synchronizes its local clock
based on the received broadcast messages.
24-5

Multicast mode
Figure 24-6 Multicast mode
Server Client
Network
After receiving the first
Periodically multicasts clock multicast message, the
synchronization messages (Mode 5) client sends a request
Clock synchronization message Calculates the network delay

exchange (Mode 3 and Mode 4) between client and the server
and enters the multicast
client mode
Periodically multicasts clock
synchronization messages (Mode 5) Receives multicast
messages and synchronizes
its local clock
In the multicast mode, a server periodically sends clock synchronization messages to the
user-configured multicast address, or, if no multicast address is configured, to the default NTP
multicast address 224.0.1.1, with the Mode field in the messages set to 5 (multicast mode). Clients
listen to the multicast messages from servers. After a client receives the first multicast message, the
client and the server start to exchange messages, with the Mode field set to 3 (client mode) and 4
(server mode) to calculate the network delay between client and the server. Then, the client enters the
multicast client mode and continues listening to multicast messages, and synchronizes its local clock
based on the received multicast messages.
In symmetric peers mode, broadcast mode and multicast mode, the client (or the symmetric active
peer) and the server (the symmetric passive peer) can work in the specified NTP working mode only
after they exchange NTP messages with the Mode field being 3 (client mode) and the Mode field being
4 (server mode). During this message exchange process, NTP clock synchronization can be
implemented.
Multiple Instances of NTP
The client/server mode and symmetric mode support multiple instances of NTP and thus support clock
synchronization within more than one VPN network. Namely, network devices at different physical
location can get their clocks synchronized through NTP, as long as they are in the same VPN.
NTP Configuration Task List

Complete the following tasks to configure NTP:
Task Remarks
Configuring the Operation Modes of NTP Required
Configuring Optional Parameters of NTP Optional
24-6

Task Remarks
Configuring Access-Control Rights Optional
Configuring NTP Authentication Optional
Configuring the Operation Modes of NTP

Devices can implement clock synchronization in one of the following modes:
z Client/server mode
z Symmetric mode
z Broadcast mode
z Multicast mode
For the client/server mode or symmetric mode, you need to configure only clients or symmetric-active
peers; for the broadcast or multicast mode, you need to configure both servers and clients.
A single device can have a maximum of 128 associations at the same time, including static
associations and dynamic associations. A static association refers to an association that a user has
manually created by using an NTP command, while a dynamic association is a temporary association
created by the system during operation. A dynamic association will be removed if the system fails to
receive messages from it over a specific long time. In the client/server mode, for example, when you
carry out a command to synchronize the time to a server, the system will create a static association,
and the server will just respond passively upon the receipt of a message, rather than creating an
association (static or dynamic). In the symmetric mode, static associations will be created at the
symmetric-active peer side, and dynamic associations will be created at the symmetric-passive peer
side; in the broadcast or multicast mode, static associations will be created at the server side, and
dynamic associations will be created at the client side.
Configuring NTP Client/Server Mode
For devices working in the client/server mode, you only need to make configurations on the clients, but
not on the servers.
Follow these steps to configure an NTP client:

ntp-service unicast-server [ vpn-instance Required

vpn-instance-name ] { ip-address | No NTP
Specify an NTP server for the
server-name } [ authentication-keyid keyid | server is
device
priority | source-interface interface-type specified by
interface-number | version number ] * default.
24-7

z In the ntp-service unicast-server command, ip-address must be a unicast address, rather than a
broadcast address, a multicast address or the IP address of the local clock.
z When the source interface for NTP messages is specified by the source-interface argument, the
source IP address of the NTP messages will be configured as the primary IP address of the
specified interface.
z A device can act as a server to synchronize the clock of other devices only after its clock has been
synchronized. If the clock of a server has a stratum level higher than or equal to that of a clients
clock, the client will not synchronize its clock to the servers.
z You can configure multiple servers by repeating the ntp-service unicast-server command. The
clients will choose the optimal reference source.
Configuring the NTP Symmetric Peers Mode
For devices working in the symmetric mode, you need to specify a symmetric-passive peer on a
symmetric-active peer.
Following these steps to configure a symmetric-active device:

ntp-service unicast-peer [ vpn-instance Required

vpn-instance-name ] { ip-address | No
Specify a symmetric-passive
peer-name } [ authentication-keyid keyid | symmetric-passive
peer for the device
priority | source-interface interface-type peer is specified by
interface-number | version number ] * default.
z In the symmetric mode, you should use any NTP configuration command in Configuring the
Operation Modes of NTP to enable NTP; otherwise, a symmetric-passive peer will not process
NTP messages from a symmetric-active peer.
z In the ntp-service unicast-peer command, ip-address must be a unicast address, rather than a
broadcast address, a multicast address or the IP address of the local clock.
z When the source interface for NTP messages is specified by the source-interface argument, the
source IP address of the NTP messages will be configured as the primary IP address of the
specified interface.
z Typically, at least one of the symmetric-active and symmetric-passive peers has been
synchronized; otherwise the clock synchronization will not proceed.
z You can configure multiple symmetric-passive peers by repeating the ntp-service unicast-peer
command.
24-8

Configuring NTP Broadcast Mode
The broadcast server periodically sends NTP broadcast messages to the broadcast address
255.255.255.255. After receiving the messages, the device working in NTP broadcast client mode
sends a reply and synchronizes its local clock.
For devices working in the broadcast mode, you need to configure both the server and clients.
Because an interface needs to be specified on the broadcast server for sending NTP broadcast
messages and an interface also needs to be specified on each broadcast client for receiving broadcast
messages, the NTP broadcast mode can be configured only in the specific interface view.
Configuring a broadcast client

Required
Enter interface view Enter the interface used to receive
interface-number
NTP broadcast messages.
Configure the device to work in ntp-service
Required
the NTP broadcast client mode broadcast-client
Configuring the broadcast server

Enter the interface used to
Enter interface view send NTP broadcast
interface-number
messages.
Configure the device to work in ntp-service broadcast-server
the NTP broadcast server [ authentication-keyid keyid | Required
mode version number ] *
A broadcast server can synchronize broadcast clients only after its clock has been synchronized.
Configuring NTP Multicast Mode
The multicast server periodically sends NTP multicast messages to multicast clients, which send
replies after receiving the messages and synchronize their local clocks.
For devices working in the multicast mode, you need to configure both the server and clients. The NTP
multicast mode must be configured in the specific interface view.
24-9

Configuring a multicast client

Enter the interface used to

Enter interface view receive NTP multicast
interface-number
messages.
Configure the device to work in ntp-service multicast-client
Required
the NTP multicast client mode [ ip-address ]
Configuring the multicast server

interface interface-type Enter the interface used to
interface-number send NTP multicast message.
ntp-service multicast-server
Configure the device to
[ ip-address ] [ authentication-keyid
work in the NTP Required
keyid | ttl ttl-number | version
multicast server mode
number ] *
z A multicast server can synchronize broadcast clients only after its clock has been synchronized.
z You can configure up to 1024 multicast clients, among which 128 can take effect at the same time.
Configuring Optional Parameters of NTP

Specifying the Source Interface for NTP Messages
If you specify the source interface for NTP messages, the device sets the source IP address of the
NTP messages as the primary IP address of the specified interface when sending the NTP messages.
When the device responds to an NTP request received, the source IP address of the NTP response is
always the IP address of the interface that received the NTP request.
Following these steps to specify the source interface for NTP messages:

Required
ntp-service By default, no source interface is specified
Specify the source
source-interface for NTP messages, and the system uses
interface for NTP
interface-type the IP address of the interface determined
messages
interface-number by the matching route as the source IP
address of NTP messages.
24-10

z If you have specified the source interface for NTP messages in the ntp-service unicast-server or
ntp-service unicast-peer command, the interface specified in the ntp-service unicast-server or
ntp-service unicast-peer command serves as the source interface of NTP messages.
z If you have configured the ntp-service broadcast-server or ntp-service multicast-server
command, the source interface of the broadcast or multicast NTP messages is the interface
configured with the respective command.
Disabling an Interface from Receiving NTP Messages
When NTP is enabled, NTP messages can be received from all the interfaces by default, and you can
disable an interface from receiving NTP messages through the following configuration.

interface-number
Required
Disable the interface from ntp-service in-interface
receiving NTP messages disable An interface is enabled to receive
NTP messages by default.
Configuring the Maximum Number of Dynamic Sessions Allowed

Configure the maximum number of Required

ntp-service
dynamic sessions allowed to be
max-dynamic-sessions number 100 by default
established locally
Configuring Access-Control Rights

With the following command, you can configure the NTP service access-control right to the local
device. There are four access-control rights, as follows:
z query: control query permitted. This level of right permits the peer devices to perform control
query to the NTP service on the local device but does not permit a peer device to synchronize its
clock to that of the local device. The so-called control query refers to query of some states of the
NTP service, including alarm information, authentication status, clock source information, and so
on.
z synchronization: server access only. This level of right permits a peer device to synchronize its
clock to that of the local device but does not permit the peer devices to perform control query.
z server: server access and query permitted. This level of right permits the peer devices to perform
synchronization and control query to the local device but does not permit the local device to
synchronize its clock to that of a peer device.
24-11

z peer: full access. This level of right permits the peer devices to perform synchronization and
control query to the local device and also permits the local device to synchronize its clock to that of
a peer device.
From the highest NTP service access-control right to the lowest one are peer, server,
synchronization, and query. When a device receives an NTP request, it will perform an
access-control right match and will use the first matched right.
Prior to configuring the NTP service access-control right to the local device, you need to create and
configure an ACL associated with the access-control right. For the configuration of ACL, refer to ACL
Configuration in the Security Volume.
Follow these steps to configure the NTP service access-control right to the local device:

Configure the NTP service ntp-service access { peer | Required

access-control right for a peer query | server |
device to access the local device synchronization } acl-number peer by default
The access-control right mechanism provides only a minimum degree of security protection for the
system running NTP. A more secure method is identity authentication.
Configuring NTP Authentication

The NTP authentication feature should be enabled for a system running NTP in a network where there
is a high security demand. This feature enhances the network security by means of client-server key
authentication, which prohibits a client from synchronizing with a device that has failed authentication.
The configuration of NTP authentication involves configuration tasks to be implemented on the client
and on the server.
When configuring the NTP authentication feature, pay attention to the following principles:
z For all synchronization modes, when you enable the NTP authentication feature, you should
configure an authentication key and specify it as a trusted key. Namely, the ntp-service
authentication enable command must work together with the ntp-service authentication-keyid
command and the ntp-service reliable authentication-keyid command. Otherwise, the NTP
authentication function cannot be normally enabled.
z For the client/server mode or symmetric mode, you need to associate the specified authentication
key on the client (symmetric-active peer if in the symmetric peer mode) with the corresponding
24-12

NTP server (symmetric-passive peer if in the symmetric peer mode). Otherwise, the NTP
authentication feature cannot be normally enabled.
z For the broadcast server mode or multicast server mode, you need to associate the specified
authentication key on the broadcast server or multicast server with the corresponding NTP server.
Otherwise, the NTP authentication feature cannot be normally enabled.
z For the client/server mode, if the NTP authentication feature has not been enabled for the client,
the client can synchronize with the server regardless of whether the NTP authentication feature
has been enabled for the server or not. If the NTP authentication is enabled on a client, the client
can be synchronized only to a server that can provide a trusted authentication key.
z For all synchronization modes, the server side and the client side must be consistently configured.
Configuring NTP authentication for a client
Follow these steps to configure NTP authentication for a client:

Enable NTP Required

ntp-service authentication enable
authentication Disabled by default
ntp-service authentication-keyid Required

Configure an NTP
keyid authentication-mode md5 No NTP authentication key by
authentication key
value default
Required
Configure the key as a ntp-service reliable No authentication key is
trusted key authentication-keyid keyid configured to be trusted by
default.
Client/server mode: Required
ntp-service unicast-server You can associate a
{ ip-address | server-name } non-existing key with an NTP
Associate the specified authentication-keyid keyid server. To enable NTP
key with an NTP server authentication, you must
Symmetric peers mode: configure the key and specify it
ntp-service unicast-peer as a trusted key after
{ ip-address | peer-name } associating the key with the
authentication-keyid keyid NTP server.
After you enable the NTP authentication feature for the client, make sure that you configure for the
client an authentication key that is the same as on the server and specify that the authentication key is
trusted; otherwise, the client cannot be synchronized to the server.
24-13

Configuring NTP authentication for a server
Follow these steps to configure NTP authentication for a server:

ntp-service authentication Required

Enable NTP authentication
ntp-service Required
Configure an NTP authentication-keyid keyid
authentication key authentication-mode md5 No NTP authentication key by
value default
Required
Configure the key as a trusted ntp-service reliable No authentication key is
key authentication-keyid keyid configured to be trusted by
default.
interface-number
Required
Broadcast server mode:
You can associate a
ntp-service broadcast-server
non-existing key with an NTP
authentication-keyid keyid
Associate the specified key server. To enable NTP
with an NTP server authentication, you must
Multicast server mode: configure the key and specify it
as a trusted key after
ntp-service multicast-server
associating the key with the
authentication-keyid keyid
NTP server.
The procedure of configuring NTP authentication on a server is the same as that on a client, and the
same authentication key must be configured on both the server and client sides.
Displaying and Maintaining NTP

View the information of NTP
display ntp-service status Available in any view
service status
View the information of NTP display ntp-service sessions
sessions [ verbose ]
View the brief information of
the NTP servers from the local
display ntp-service trace Available in any view
device back to the primary
reference source
24-14

NTP Configuration Examples
Configuring NTP Client/Server Mode
z The local clock of Switch A is to be used as a master clock, with the stratum level of 2.
z Switch B works in the client/server mode and Switch A is to be used as the NTP server of Switch
B.
Figure 24-7 Network diagram for NTP client/server mode configuration
# View the NTP status of Switch B before clock synchronization.

<SwitchB> display ntp-service status
Clock status: unsynchronized
Clock stratum: 16
Reference clock ID: none
Nominal frequency: 64.0000 Hz
Actual frequency: 64.0000 Hz
Clock precision: 2^7
Clock offset: 0.0000 ms
Root delay: 0.00 ms
Root dispersion: 0.00 ms
Peer dispersion: 0.00 ms
Reference time: 00:00:00.000 UTC Jan 1 1900 (00000000.00000000)
# Specify Switch A as the NTP server of Switch B so that Switch B is synchronized to Switch A.
[SwitchB] ntp-service unicast-server 1.0.1.11
# View the NTP status of Switch B after clock synchronization.

[SwitchB] display ntp-service status
Clock status: synchronized
Clock stratum: 3
Reference clock ID: 1.0.1.11
Root delay: 31.00 ms
Reference time: 14:53:27.371 UTC Sep 19 2005 (C6D94F67.5EF9DB22)
24-15

As shown above, Switch B has been synchronized to Switch A, and the clock stratum level of Switch B
is 3, while that of Switch A is 2.
# View the NTP session information of Switch B, which shows that an association has been set up
between Switch B and Switch A.
[SwitchB] display ntp-service sessions
source reference stra reach poll now offset delay disper
**************************************************************************
[12345] 1.0.1.11 127.127.1.0 2 63 64 3 -75.5 31.0 16.5
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations : 1
Configuring the NTP Symmetric Mode
z The local clock of Switch A is to be used as the master clock, with a stratum level of 2.
z Switch B works in the client mode and Switch A is to be used as the NTP server of Switch B.
z Switch C works in the symmetric-active mode and Switch B will act as peer of Switch C. Switch C
is the symmetric-active peer while Switch B is the symmetric-passive peer.
Figure 24-8 Network diagram for NTP symmetric peers mode configuration
Switch A
3.0.1.31/24
3.0.1.32/24 3.0.1.33/24
Switch B Switch C
1) Configuration on Switch B:
# Specify Switch A as the NTP server of Switch B.
[SwitchB] ntp-service unicast-server 3.0.1.31
2) Configuration on Switch C (after Switch B is synchronized to Switch A):
# Specify the local clock as the reference source, with the stratum level of 1.
[SwitchC] ntp-service refclock-master 1
# Configure Switch B as a symmetric peer after local synchronization.

[SwitchC] ntp-service unicast-peer 3.0.1.32
24-16

In the step above, Switch B and Switch C are configured as symmetric peers, with Switch C in the
symmetric-active mode and Switch B in the symmetric-passive mode. Because the stratus level of
Switch C is 1 while that of Switch B is 3, Switch B is synchronized to Switch C.
Clock stratum: 2
Clock offset: -21.1982 ms
Reference time: 15:22:47.083 UTC Sep 19 2005 (C6D95647.153F7CED)
As shown above, Switch B has been synchronized to Switch C, and the clock stratum level of Switch B
is 2, while that of Switch C is 1.
between Switch B and Switch C.
**************************************************************************
[245] 3.0.1.31 127.127.1.0 2 15 64 24 10535.0 19.6 14.5
[1234] 3.0.1.33 LOCL 1 14 64 27 -77.0 16.0 14.8
24-17

Configuring NTP Broadcast Mode
z The local clock of Switch C is to be used as the master clock, with a stratum level of 2.
z Switch C works in the broadcast server mode and sends out broadcast messages from
VLAN-interface 2.
z Switch A and Switch D work in the broadcast client mode. Switch A listens to broadcast messages
through its VLAN-interface 3 and Switch D from its VLAN-interface 2.
Figure 24-9 Network diagram for NTP broadcast mode configuration
Vlan-int2
3.0.1.31/24
Switch C
Vlan-int3 Vlan-int3 Vlan-int2

1.0.1.11/24 1.0.1.10/24 3.0.1.30/24
Switch A Switch B
Vlan-int2
3.0.1.32/24
Switch D
1) Configuration on Switch C:
# Configure Switch C to work in the broadcast server mode and send broadcast messages through
VLAN-interface 2.
[SwitchC-Vlan-interface2] ntp-service broadcast-server
2) Configuration on Switch D:
# Configure Switch D to work in the broadcast client mode and receive broadcast messages on
VLAN-interface 2.
[SwitchD] interface vlan-interface 2
[SwitchD-Vlan-interface2] ntp-service broadcast-client
3) Configuration on Switch A:
# Configure Switch A to work in the broadcast client mode and receive broadcast messages on
VLAN-interface 3.
[SwitchA-Vlan-interface3] ntp-service broadcast-client
24-18

Because Switch A and Switch C are on different subnets, Switch A cannot receive the broadcast
messages from Switch C. Switch D gets synchronized upon receiving a broadcast message from
Switch C.
# View the NTP status of Switch D after clock synchronization.
[SwitchD-Vlan-interface2] display ntp-service status
Clock stratum: 3
Reference time: 16:01:51.713 UTC Sep 19 2005 (C6D95F6F.B6872B02)
As shown above, Switch D has been synchronized to Switch C, and the clock stratum level of Switch D
# View the NTP session information of Switch D, which shows that an association has been set up
between Switch D and Switch C.
[SwitchD-Vlan-interface2] display ntp-service sessions
**************************************************************************
[1234] 3.0.1.31 127.127.1.0 2 254 64 62 -16.0 32.0 16.6
Configuring NTP Multicast Mode
z Switch C works in the multicast server mode and sends out multicast messages from
VLAN-interface 2.
z Switch A and Switch D work in the multicast client mode and receive multicast messages through
VLAN-interface 3 and VLAN-interface 2 respectively.
In this example, Switch B is a L3 switch and it must support the IGMP function.
24-19

Figure 24-10 Network diagram for NTP multicast mode configuration
# Configure Switch C to work in the multicast server mode and send multicast messages through
VLAN-interface 2.
[SwitchC-Vlan-interface2] ntp-service multicast-server
# Configure Switch D to work in the multicast client mode and receive multicast messages on
VLAN-interface 2.
[SwitchD-Vlan-interface2] ntp-service multicast-client
Because Switch D and Switch C are on the same subnet, Switch D can receive the multicast
messages from Switch C without being enabled with the multicast functions and can be synchronized
to Switch C.
Clock stratum: 3
24-20

**************************************************************************
[1234] 3.0.1.31 127.127.1.0 2 254 64 62 -16.0 31.0 16.6
3) Configuration on Switch B:
Because Switch A and Switch C are on different subnets, you must enable the multicast functions on
Switch B before Switch A can receive multicast messages from Switch C.
# Enable IP multicast routing and IGMP.
[SwitchB] multicast routing-enable
[SwitchB-Vlan-interface2] pim dm
[SwitchB] vlan 3
[SwitchB-Vlan-interface3] igmp enable
[SwitchB-GigabitEthernet1/0/1] igmp-snooping static-group 224.0.1.1 vlan 3
4) Configuration on Switch A:
# Enable IP multicast routing and IGMP.
# Configure Switch A to work in the multicast client mode and receive multicast messages on
VLAN-interface 3.
[SwitchA-Vlan-interface3] ntp-service multicast-client
# View the NTP status of Switch A after clock synchronization.

[SwitchA-Vlan-interface3] display ntp-service status
Clock stratum: 3
24-21

As shown above, Switch A has been synchronized to Switch C, and the clock stratum level of Switch A
# View the NTP session information of Switch A, which shows that an association has been set up
between Switch A and Switch C.
[SwitchA-Vlan-interface3] display ntp-service sessions
**************************************************************************
[1234] 3.0.1.31 127.127.1.0 2 255 64 26 -16.0 40.0 16.6
Refer to IGMP Configuration in the IP Multicast volume for how to configure IGMP and PIM.
Configuring NTP Client/Server Mode with Authentication
z The local clock of Switch A is to be used as the master clock, with a stratum level of 2.
z Switch B works in the client mode and Switch A is to be used as the NTP server of Switch B, with
Switch B as the client.
z NTP authentication is to be enabled on both Switch A and Switch B.
Figure 24-11 Network diagram for configuration of NTP client/server mode with authentication
Configuration on Switch B:
# Enable NTP authentication on Switch B.
[SwitchB] ntp-service authentication enable
# Set an authentication key.

[SwitchB] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey
# Specify the key as a trusted key.

[SwitchB] ntp-service reliable authentication-keyid 42
# Specify Switch A as the NTP server.

[SwitchB] ntp-service unicast-server 1.0.1.11 authentication-keyid 42
24-22

Before Switch B can synchronize its clock to that of Switch A, you need to enable NTP authentication
for Switch A.
Perform the following configuration on Switch A:
# Enable NTP authentication.
[SwitchA] ntp-service authentication enable
# Set an authentication key.

[SwitchA] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey
# Specify the key as a trusted key.

[SwitchA] ntp-service reliable authentication-keyid 42

Clock stratum: 3
Reference time: 14:53:27.371 UTC Sep 19 2005 (C6D94F67.5EF9DB22)
As shown above, Switch B has been synchronized to Switch A, and the clock stratum level of Switch B
is 3, while that of Switch A is 2.
Switch B and Switch A.
**************************************************************************
[12345] 1.0.1.11 127.127.1.0 2 63 64 3 -75.5 31.0 16.5
Configuring NTP Broadcast Mode with Authentication
24-23

z Switch C works in the broadcast server mode and sends out broadcast messages from
VLAN-interface 2.
z Switch D works in the broadcast client mode and receives broadcast messages through
VLAN-interface 2.
z NTP authentication is enabled on both Switch C and Switch D.
Figure 24-12 Network diagram for configuration of NTP broadcast mode with authentication
# Configure NTP authentication.
[SwitchC] ntp-service authentication enable
[SwitchC] ntp-service authentication-keyid 88 authentication-mode md5 123456
[SwitchC] ntp-service reliable authentication-keyid 88
# Specify Switch C as an NTP broadcast server, and specify an authentication key.

[SwitchC-Vlan-interface2] ntp-service broadcast-server authentication-keyid 88
# Configure NTP authentication.
[SwitchD] ntp-service authentication enable
[SwitchD] ntp-service authentication-keyid 88 authentication-mode md5 123456
[SwitchD] ntp-service reliable authentication-keyid 88
# Configure Switch D to work in the NTP broadcast client mode.

[SwitchD-Vlan-interface2] ntp-service broadcast-client
Now, Switch D can receive broadcast messages through VLAN-interface 2, and Switch C can send
broadcast messages through VLAN-interface 2. Upon receiving a broadcast message from Switch C,
Switch D synchronizes its clock to that of Switch C.
24-24

Clock stratum: 4
**************************************************************************
[1234] 3.0.1.31 127.127.1.0 3 254 64 62 -16.0 32.0 16.6
24-25

25 Cluster Management Configuration
When configuring cluster management, go to these sections for information you are interested in:
z Cluster Management Overview
z Cluster Configuration Task List
z Configuring the Management Device
z Configuring the Member Devices
z Configuring Access Between the Management Device and Its Member Devices
z Adding a Candidate Device to a Cluster
z Configuring Advanced Cluster Functions
z Displaying and Maintaining Cluster Management
z Cluster Management Configuration Example
Cluster Management Overview

Cluster Management Definition
A cluster is a group of network devices. Cluster management is to implement management of large

numbers of distributed network devices. Cluster management offers the following advantages:
z Saving public IP address resource
z Simplifying configuration and management tasks. By configuring a public IP address on one
device, you can configure and manage a group of devices without the trouble of logging in to each
device separately.
z Providing topology discovery and display function, which is useful for network monitoring and
debugging
z Allowing simultaneous software upgrading and parameter configuration on multiple devices, free
of topology and distance limitations
Roles in a Cluster
The devices in a cluster play different roles according to their different functions and status. You can
specify the following three roles for the devices:
z Management device (Administrator): The device providing management interfaces for all devices
in a cluster and the only device configured with a public IP address. You can specify one and only
one management device for a cluster. Any configuration, management, and monitoring of the
other devices in a cluster can only be implemented through the management device. When a
device is specified as the management device, it collects related information to discover and
define candidate devices.
z Member device (Member): A device managed by the management device in a cluster.
z Candidate device (Candidate): A device that does not belong to any cluster but can be added to a
cluster. Different from a member device, its topology information has been collected by the
management device but it has not been added to the cluster.
25-1

Figure 25-1 Network diagram for a cluster
As shown in Figure 25-1, the device configured with a public IP address and performs the
management function is the management device, the other managed devices are member devices,
and the device that does not belong to any cluster but can be added to a cluster is a candidate device.
The management device and the member devices form the cluster.
Figure 25-2 Role change in a cluster
As shown in Figure 25-2, a device in a cluster changes its role according to the following rules:
z A candidate device becomes a management device when you create a cluster on it. A
management device becomes a candidate device only after the cluster is removed.
z A candidate device becomes a member device after being added to a cluster. A member device
becomes a candidate device after it is removed from the cluster.
How a Cluster Works
Cluster management is implemented through HW Group Management Protocol version 2 (HGMPv2),

which consists of the following three protocols:
z Neighbor Discovery Protocol (NDP)
z Neighbor Topology Discovery Protocol (NTDP)
z Cluster
A cluster configures and manages the devices in it through the above three protocols. Cluster
management involves topology information collection and the establishment and maintenance of a
cluster. Topology information collection and cluster maintenance are independent from each other, with
the former starting before the cluster is created:
z All devices use NDP to collect the information of the directly connected neighbors, including their
software version, host name, MAC address and port number.
z The management device uses NTDP to collect the information of the devices within user-specified
hops and the topology information of all devices and specify the candidate devices of the cluster.
z The management device adds or deletes a member device and modifies cluster management
configuration according to the candidate device information collected through NTDP.
25-2

Introduction to NDP
NDP is used to discover the information about directly connected neighbors, including the device
name, software version, and connecting port of the adjacent devices. NDP works in the following ways:
z A device running NDP periodically sends NDP packets to its neighbors. An NDP packet carries
NDP information (including the device name, software version, and connecting port, etc.) and the
holdtime, which indicates how long the receiving devices will keep the NDP information. At the
same time, the device also receives (but does not forward) the NDP packets from its neighbors.
z A device running NDP stores and maintains an NDP table. The device creates an entry in the
NDP table for each neighbor. If a new neighbor is found, meaning the device receives an NDP
packet sent by the neighbor for the first time, the device adds an entry in the NDP table. If the
NDP information carried in the NDP packet is different from the stored information, the
corresponding entry and holdtime in the NDP table are updated; otherwise, only the holdtime of
the entry is updated. If no NDP information from the neighbor is received when the holdtime times
out, the corresponding entry is removed from the NDP table.
NDP runs on the data link layer, and therefore supports different network layer protocols.
Introduction to NTDP
NTDP provides information required for cluster management; it collects topology information about the
devices within the specified hop count. Based on the neighbor information stored in the neighbor table
maintained by NDP, NTDP on the management device advertises NTDP topology collection requests
to collect the NDP information of all the devices in a specific network range as well as the connection
information of all its neighbors. The information collected will be used by the management device or
the network management software to implement required functions.
When a member device detects a change on its neighbors through its NDP table, it informs the
management device through handshake packets. Then the management device triggers its NTDP to
collect specific topology information, so that its NTDP can discover topology changes timely.
The management device collects topology information periodically. You can also administratively
launch a topology information collection. The process of topology information collection is as follows:
z The management device periodically sends NTDP topology collection request from the
NTDP-enabled ports.
z Upon receiving the request, the device sends NTDP topology collection response to the
management device, copies this response packet on the NTDP-enabled port and sends it to the
adjacent device. Topology collection response includes the basic information of the NDP-enabled
device and NDP information of all adjacent devices.
z The adjacent device performs the same operation until the NTDP topology collection request is
sent to all the devices within specified hops.
When the NTDP topology collection request is advertised in the network, large numbers of network
devices receive the NTDP topology collection request and send NTDP topology collection response at
the same time, which may cause congestion and the management device busyness. To avoid such
case, the following methods can be used to control the speed of the NTDP topology collection request
advertisement:
z Upon receiving an NTDP topology collection request, each device does not forward it, instead, it
waits for a period of time and then forwards the NTDP topology collection request on the first
NTDP-enabled port.
z On the same device, except the first port, each NTDP-enabled port waits for a period of time and
25-3

then forwards the NTDP topology collection request after its prior port forwards the NTDP
topology collection request.
Cluster management maintenance
1) Adding a candidate device to a cluster

You should specify the management device before creating a cluster. The management device
discovers and defines a candidate device through NDP and NTDP protocols. The candidate device
can be automatically or manually added to the cluster.
After the candidate device is added to the cluster, it can obtain the member number assigned by the
management device and the private IP address used for cluster management.
2) Communication within a cluster
In a cluster the management device communicates with its member devices by sending handshake
packets to maintain connection between them. The management/member device state change is
shown in Figure 25-3.
Figure 25-3 Management/member device state change
Active
als ts
Dis
pa hake
erv acke
ts
c
cke
on
s
v e ak e p
me hand
ne
ct
i nt
nt
sta
na the
s
ns nd
t
ei
uti
ge
ma s
co h a
or ceive
sr
ec
ee eive
ec
Re
ov
i n o r ec
ere
th r
d
t
ils
Fa
Connect Disconnect
State holdtime exceeds
the specified value
z After a cluster is created, a candidate device is added to the cluster and becomes a member
device, the management device saves the state information of its member device and identifies it
as Active. And the member device also saves its state information and identifies itself as Active.
z After a cluster is created, its management device and member devices begin to send handshake
packets. Upon receiving the handshake packets from the other side, the management device or a
member device simply remains its state as Active, without sending a response.
z If the management device does not receive the handshake packets from a member device in an
interval three times of the interval to send handshake packets, it changes the status of the
member device from Active to Connect. Likewise, if a member device fails to receive the
handshake packets from the management device in an interval three times of the interval to send
handshake packets, the status of itself will also be changed from Active to Connect.
z If this management device, in information holdtime, receives the handshake or management
packets from its member device which is in Connect state, it changes the state of its member
device to Active; otherwise, it changes the state of its member device to Disconnect, in which case
the management device considers its member device disconnected. If this member device, which
is in Connect state, receives handshake or management packets from the management device in
information holdtime, it changes its state to Active; otherwise, it changes its state to Disconnect.
z If the communication between the management device and a member device is recovered, the
25-4

member device which is in Disconnect state will be added to the cluster. After that, the state of the
member device locally and on the management device will be changed to Active.
Besides, a member device informs the management device using handshake packets when there is a
neighbor topology change.
Management VLAN
The management VLAN is a VLAN used for communication in a cluster; it limits the cluster
management range. Through configuration of the management VLAN, the following functions can be
implemented:
z Management packets (including NDP, NTDP and handshake packets) are restricted within the
management VLAN, therefore isolated from other packets, which enhances security.
z The management device and the member devices communicate with each other through the
management VLAN.
For a cluster to work normally, you must set the packets from the management VLAN to pass the
ports connecting the management device and the member/candidate devices (including the cascade
ports). Therefore:
z If the packets from the management VLAN cannot pass a port, the device connected with the port
cannot be added to the cluster. Therefore, if the ports (including the cascade ports) connecting the
management device and the member/candidate devices prohibit the packets from the
management VLAN, you can set the packets from the management VLAN to pass the ports on
candidate devices with the management VLAN auto-negotiation function.
z Only when the default VLAN ID of the cascade ports and the ports connecting the management
device and the member/candidate devices is that of the management VLAN can you set the
packets without tags from the management VLAN to pass the ports; otherwise, only the packets
with tags from the management VLAN can pass the ports.
z If a candidate device is connected to a management device through another candidate device, the
ports between the two candidate devices are cascade ports.
z For information about VLAN, refer to VLAN Configuration in the Access Volume.
Cluster Configuration Task List

Before configuring a cluster, you need to determine the roles and functions the devices play. You also
need to configure the related functions, preparing for the communication between devices within the
cluster.
25-5

Complete these tasks to configure a cluster:
Task Remarks
Enabling NDP Globally and for Specific Ports Optional
Configuring NDP Parameters Optional

Enabling NTDP Globally and for Specific Ports Optional
Configuring NTDP Parameters Optional
Manually Collecting Topology Information Optional

Enabling the Cluster Function Optional
Configuring the
Management Device Establishing a Cluster Required
Enabling Management VLAN Auto-negotiation Required

Configuring Communication Between the
Management Device and the Member Devices Within Optional
a Cluster
Configuring Cluster Management Protocol Packets Optional
Cluster Member Management Optional

Enabling NDP Optional
Enabling NTDP Optional
Configuring the
Manually Collecting Topology Information Optional
Member Devices
Enabling the Cluster Function Optional
Deleting a Member Device from a Cluster Optional
Configuring Access Between the Management Device and Its Member

Optional
Devices
Adding a Candidate Device to a Cluster Optional
Configuring Topology Management Optional
Configuring Configuring Interaction for a Cluster Optional
Advanced Cluster
Functions SNMP Configuration Synchronization Function Optional
Configuring Web User Accounts in Batches Optional
25-6

z Disabling the NDP and NTDP functions on the management device and member devices after a
cluster is created will not cause the cluster to be dismissed, but will influence the normal operation
of the cluster.
z When both the cluster function and the 802.1x function (or the MAC address authentication) are
enabled on devices, you need to enable HABP on the devices. Otherwise, the management
device of the cluster cannot manage the devices connected with it. For description of HABP, refer
to HABP Configuration in the Security Volume.
z If the routing table of the management device is full when a cluster is established, that is, entries
with the destination address as a candidate device cannot be added to the routing table, all
candidate devices will be added to and removed from the cluster repeatedly.
z If the routing table of a candidate device is full when the candidate device is added to a cluster,
that is, the entry with the destination address as the management device cannot be added to the
routing table, the candidate device will be added to and removed from the cluster repeatedly.
Configuring the Management Device

Enabling NDP Globally and for Specific Ports
For NDP to work normally, you must enable NTDP both globally and on specific ports.
Follow these steps to enable NDP globally and for specific ports:

Optional
Enable NDP globally ndp enable
Enabled by default.
In system
ndp enable interfaceinterface-list
view
Enable the Use either command
In Ethernet interface interface-type
NDP feature port view or interface-number By default, NDP is enabled
for the port(s) Layer 2 globally and also on all ports.
aggregate ndp enable
interface view
You are recommended to disable NDP on the port which connects with the devices that do not need to
join the cluster, preventing the management device from adding the device which needs not to join the
cluster and collecting the topology information of this device.
25-7

Configuring NDP Parameters
A port enabled with NDP periodically sends NDP packets to its neighbors. If no NDP information from
the neighbor is received when the holdtime times out, the corresponding entry is removed from the
NDP table.
Follow these steps to configure NDP parameters:


ndp timer hello hello-time
sending NDP packets 60 seconds by default.
Configure the period for the Optional

receiving device to keep the ndp timer aging aging-time
NDP packets 180 seconds by default.
The time for the receiving device to hold NDP packets cannot be shorter than the interval for sending
NDP packets; otherwise, the NDP table may become instable.
Enabling NTDP Globally and for Specific Ports
For NTDP to work normally, you must enable NTDP both globally and on specific ports.
Follow these steps to enable NTDP globally and for specific ports:

Optional
Enable NTDP globally ntdp enable
Enabled by default
interface interface-type Optional

Enable NTDP for the port interface-number
NTDP is enabled on all ports
ntdp enable by default.
You are recommended to disable NTDP on the port which connects with the devices that do not need
to join the cluster, preventing the management device from adding the device which needs not to join
the cluster and collecting the topology information of this device.
Configuring NTDP Parameters
By configuring the maximum hops for collecting topology information, you can get topology information
25-8

of the devices in a specified range, thus avoiding unlimited topology collection.
After the interval for collecting topology information is configured, the device collects the topology
information at this interval.
To avoid network congestion caused by large amounts of topology responses received in short
periods:
z Upon receiving an NTDP topology collection request, a device does not forward it, instead, it waits
for a period of time and then forwards the NTDP topology collection request on its first
NTDP-enabled port.
z On the same device, except the first port, each NTDP-enabled port waits for a period of time and
then forwards the NTDP topology collection request after the previous port forwards the NTDP
topology collection request.
Follow these steps to configure NTDP parameters:

Configure the maximum hops Optional

ntdp hop hop-value
for topology collection 3 by default.
Configure the interval to collect Optional

ntdp timer interval-time
topology information 1 minute by default.
Configure the delay to forward Optional

topology-collection request ntdp timer hop-delay time
packets on the first port 200 ms by default.
Configure the port delay to Optional

forward topology collection ntdp timer port-delay time
request on other ports 20 ms by default.
The two delay values should be configured on the topology collecting device. A topology collection
request sent by the topology collecting device carries the two delay values, and a device that receives
the request forwards the request according to the delays.
Manually Collecting Topology Information
The management device collects topology information periodically after a cluster is created. In addition,
you can configure to manually initiate topology information collection, thus managing and monitoring
the device on real time, regardless of whether a cluster is created.
Follow these steps to configure to manually collect topology information:

Manually collect topology information ntdp explore Required
25-9

Enabling the Cluster Function

Enable the cluster function Optional

cluster enable
globally Enabled by default.
Establishing a Cluster
Before establishing a cluster, you need to specify the management VLAN, and you cannot modify the
management VLAN after a device is added to the cluster.
In addition, you need to configure a private IP address pool for the devices to be added to the cluster
on the device to be configured as the management device before establishing a cluster. Meanwhile,
the IP addresses of the VLAN interfaces of the management device and member devices cannot be in
the same network segment as that of the cluster address pool; otherwise, the cluster cannot work
normally. When a candidate device is added to a cluster, the management device assigns it a private
IP address for it to communicate with other devices in the cluster.
You can establish a cluster in two ways: manually and automatically. With the latter, you can establish
a cluster according to the prompt information. The system:
1) Prompts you to enter a name for the cluster you want to establish;
2) Lists all the candidate devices within your predefined hop count;
3) Starts to automatically add them to the cluster.
You can press Ctrl+C anytime during the adding process to exit the cluster auto-establishment
process. However, this will only stop adding new devices into the cluster, and devices already added
into the cluster are not removed.
Follow these steps to manually establish a cluster:

Optional
Specify the management VLAN management-vlan vlan-id By default, VLAN 1 is the
management VLAN.
Enter cluster view cluster
ip-pool Required
Configure the private IP address
administrator-ip-address
range for member devices Not configured by default.
Manually
establish a build name Required
Establish a cluster Use either approach
cluster Automatically By default, the device is not
establish a auto-build [ recover ] the management device.
cluster
25-10

Enabling Management VLAN Auto-negotiation
The management VLAN limits the cluster management range. If the device discovered by the
management device does not belong to the management VLAN, meaning the cascade ports and the
ports connecting with the management device do not allow the packets from the management VLAN to
pass, and the new device cannot be added to the cluster. Through the configuration of the
management VLAN auto-negotiation function, the cascade ports and the ports directly connected to
the management device can be automatically added to the management VLAN.
Follow these steps to configure management VLAN auto-negotiation:

Enable management VLAN management-vlan Required

auto-negotiation synchronization enable Disabled by default.
Configuring Communication Between the Management Device and the Member

Devices Within a Cluster
In a cluster, the management device and member devices communicate by sending handshake
packets to maintain connection between them. You can configure interval of sending handshake
packets and the holdtime of a device on the management device. This configuration applies to all
member devices within the cluster. For a member device in Connect state:
z If the management device does not receive handshake packets from a member device within the
holdtime, it changes the state of the member device to Disconnect. When the communication is
recovered, the member device needs to be re-added to the cluster (this process is automatically
performed).
z If the management device receives handshake packets from the member device within the
holdtime, the state of the member device remains Active.
Follow these steps to configure communication between the management device and the member
devices within a cluster:
Configure the interval to send Optional

timer interval-time
handshake packets 10 seconds by default
Configure the holdtime of a Optional

holdtime seconds
device 60 seconds by default
Configuring Cluster Management Protocol Packets
By default, the destination MAC address of cluster management protocol packets (including NDP,
NTDP and HABP packets) is a multicast MAC address 0180-C200-000A, which IEEE reserved for
later use. Since some devices cannot forward the multicast packets with the destination MAC address
25-11

of 0180-C200-000A, cluster management packets cannot traverse these devices. For a cluster to work
normally in this case, you can modify the destination MAC address of a cluster management protocol
packet without changing the current networking.
The management device periodically sends MAC address negotiation broadcast packets to advertise
the destination MAC address of the cluster management protocol packets.
Follow these steps to configure the destination MAC address of the cluster management protocol
packets:

Configure the destination MAC Required

address for cluster cluster-mac mac-address The destination MAC address
management protocol packets is 0180-C200-000A by default.
Configure the interval to send Optional
cluster-mac syn-interval
MAC address negotiation
interval-time One minute by default.
broadcast packets
When you configure the destination MAC address for cluster management protocol packets:
z If the interval for sending MAC address negotiation broadcast packets is 0, the system
automatically sets it to 1 minute.
z If the interval for sending MAC address negotiation broadcast packets is not 0, the interval
remains unchanged.
Cluster Member Management
You can manually add a candidate device to a cluster, or remove a member device from a cluster.
If a member device needs to be rebooted for software upgrade or configuration update, you can
remotely reboot it through the management device.
Adding a member device

add-member [ member-number ]
Add a candidate device to the
mac-address mac-address [ password Required
cluster
password ]
25-12

Removing a member device

Remove a member device from delete-member member-number

Required
the cluster [ to-black-list ]
Rebooting a member device

Reboot a specified member reboot member { member-number |

Required
device mac-address mac-address } [ eraseflash ]
Configuring the Member Devices

Enabling NDP
Refer to Enabling NDP Globally and for Specific Ports.
Enabling NTDP
Refer to Enabling NTDP Globally and for Specific Ports.
Manually Collecting Topology Information
Refer to Manually Collecting Topology Information.
Enabling the Cluster Function
Refer to Enabling the Cluster Function.
Deleting a Member Device from a Cluster

Delete a member device from the cluster undo administrator-address Required
Configuring Access Between the Management Device and Its

Member Devices
After having successfully configured NDP, NTDP and cluster, you can configure, manage and monitor
25-13

the member devices through the management device. You can manage member devices in a cluster
through switching from the operation interface of the management device to that of a member device
or configure the management device by switching from the operation interface of a member device to
that of the management device.
Follow these steps to configure access between member devices of a cluster:

Switch from the operation interface of cluster switch-to { member-number |
the management device to that of a mac-address mac-address | sysname Required
member device member-sysname }
Switch from the operation interface of
a member device to that of the cluster switch-to administrator Required
management device
Telnet connection is used in the switching between the management device and a member device.
Note the following when switching between them:
z Authentication is required when you switch from a member device to the management device.
The switching fails if authentication is not passed. Your user level is allocated according to the
predefined level by the management device if authentication is passed.
z When a candidate device is added to a cluster and becomes a member device, its super
password will be automatically synchronized to the management device. Therefore, after a cluster
is established, it is not recommended to modify the super password of any member (including the
management device and member devices) of the cluster; otherwise, the switching may fail
because of an authentication failure.
z If the member specified in this command does not exist, the system prompts error when you
execute the command; if the switching succeeds, your user level on the management device is
retained.
z If the Telnet users on the device to be logged in reach the maximum number, the switching fails.
z To prevent resource waste, avoid ring switching when configuring access between cluster
members. For example, if you switch from the operation interface of the management device to
that of a member device and then need to switch back to that of the management device, use the
quit command to end the switching, but not the cluster switch-to administrator command to
switch to the operation interface of the management device.
Adding a Candidate Device to a Cluster

Follow these steps to add a candidate device to a cluster:

25-14

Add a candidate device to the administrator-address
Required
cluster mac-address name name
Configuring Advanced Cluster Functions

z Configuring Topology Management
z Configuring Interaction for a Cluster
z SNMP Configuration Synchronization Function
z Configuring Web User Accounts in Batches
Configuring Topology Management
The concepts of blacklist and whitelist are used for topology management. An administrator can
diagnose the network by comparing the current topology (namely, the information of a node and its
neighbors in the cluster) and the standard topology.
z Topology management whitelist (standard topology): A whitelist is a list of topology information
that has been confirmed by the administrator as correct. You can get the information of a node
and its neighbors from the current topology. Based on the information, you can manage and
maintain the whitelist by adding, deleting or modifying a node.
z Topology management blacklist: Devices in a blacklist are not allowed to join a cluster. A blacklist
contains the MAC addresses of devices. If a blacklisted device is connected to a network through
another device not included in the blacklist, the MAC address and access port of the latter are also
included in the blacklist. The candidate devices in a blacklist can be added to a cluster only if the
administrator manually removes them from the list.
The whitelist and blacklist are mutually exclusive. A whitelist member cannot be a blacklist member,
and vice versa. However, a topology node can belong to neither the whitelist nor the blacklist. Nodes of
this type are usually newly added nodes, whose identities are to be confirmed by the administrator.
You can back up and restore the whitelist in the following two ways:
z Backing them up on the FTP server shared by the cluster. You can manually restore the whitelist
and blacklist from the FTP server.
z Backing them up in the Flash of the management device. When the management device restarts,
the whitelist and blacklist will be automatically restored from the Flash. When a cluster is
re-established, you can choose whether to restore the whitelist and blacklist from the Flash
automatically, or you can manually restore them from the Flash of the management device.
Follow these steps to configure cluster topology management:

Add a device to the blacklist black-list add-mac mac-address Optional

Remove a device from the
black-list delete-mac { all | mac-address } Optional
blacklist
25-15

Confirm the current topology topology accept { all [ save-to { ftp-server |
and save it as the standard local-flash } ] | mac-address mac-address | Optional
topology member-id member-number }
Save the standard topology to
the FTP server or the local topology save-to { ftp-server | local-flash } Optional
Flash
Restore the standard topology
topology restore-from { ftp-server |
information from the FTP Optional
local-flash }
server or the local Flash
Configuring Interaction for a Cluster
After establishing a cluster, you can configure FTP/TFTP server, NM host and log host for the cluster
on the management device.
z After you configure an FTP/TFTP server for a cluster, the members in the cluster access the
FTP/TFTP server configured through the management device.
z After you configure a log host for a cluster, all the log information of the members in the cluster will
be output to the configured log host in the following way: first, the member devices send their log
information to the management device, which then converts the addresses of log information and
sends them to the log host.
z After you configure an NM host for a cluster, the member devices in the cluster send their Trap
messages to the shared SNMP NM host through the management device.
If the port of an access NM device (including FTP/TFTP server, NM host and log host) does not allow
the packets from the management VLAN to pass, the NM device cannot manage the devices in a
cluster through the management device. In this case, on the management device, you need to
configure the VLAN interface of the access NM device (including FTP/TFTP server, NM host and log
host) as the NM interface.
Follow these steps to configure the interaction for a cluster:
ftp-server ip-address Required

Configure the FTP server [ user-name username
shared by the cluster password { simple | cipher } By default, no FTP server is
password ] configured for a cluster.
Required
Configure the TFTP server
tftp-server ip-address By default, no TFTP server is
shared by the cluster
configured for a cluster.
Configure the log host shared Required

by the member devices in the logging-host ip-address By default, no log host is
cluster configured for a cluster.
snmp-host ip-address Required

Configure the SNMP NM host
[ community-string read By default, no SNMP host is
shared by the cluster
string1 write string2 ] configured.
25-16

Configure the NM interface of nm-interface vlan-interface
Optional
the management device vlan-interface-id
To isolate management protocol packets of a cluster from packets outside the cluster, you are
recommended to configure to prohibit packets from the management VLAN from passing the ports that
connect the management device with the devices outside the cluster and configure the NM interface
for the management device.
SNMP Configuration Synchronization Function
SNMP configuration synchronization function facilitates management of a cluster, with which you can
perform SNMP-related configurations on the management device and synchronize them to the
member devices on the whitelist. This operation is equal to configuring multiple member devices at
one time, simplifying the configuration process. Follow these steps to configure the SNMP
configuration synchronization function:

Configure the SNMP cluster-snmp-agent community

community name { read | write } community-name Required
shared by a cluster [ mib-view view-name ]
cluster-snmp-agent group v3
Configure the SNMPv3 group-name [ authentication |
group shared by a privacy ] [ read-view read-view ] Required
cluster [ write-view write-view ] [ notify-view
notify-view ]
Required
Create or update By default, the name of the MIB
cluster-snmp-agent mib-view
information of the MIB view shared by a cluster is
included view-name oid-tree
view shared by a cluster ViewDefault and a cluster can
access the ISO subtree.
cluster-snmp-agent usm-user v3
Add a user for the user-name group-name
SNMPv3 group shared [ authentication-mode { md5 | sha } Required
by a cluster auth-password ] [ privacy-mode
des56 priv-password ]
25-17

z The SNMP-related configurations are retained when a cluster is dismissed or the member devices
are removed from the whitelist.
z For information about SNMP, refer to SNMP Configuration in the System Volume.
Configuring Web User Accounts in Batches
Configuring Web user accounts in batches enables you to configure on the management device the
username and password used to log in to the devices (including the management device and member
devices) within a cluster through Web and synchronize the configurations to the member devices in the
whitelist. This operation is equal to performing the configurations on the member devices. You need to
enter your username and password when you log in to the devices (including the management device
and member devices) in a cluster through Web.
Follow these steps to configure Web user accounts in batches:

Configure Web user accounts cluster-local-user username password

Required
in batches { cipher | simple } password
If a cluster is dismissed or the member devices are removed from the whitelist, the configurations of
Web user accounts are still retained.
25-18

Displaying and Maintaining Cluster Management
Display NDP configuration
display ndp [ interface interface-list ]
information
Display the global NTDP
display ntdp
information
Display the device information
display ntdp device-list [ verbose ]
collected through NTDP
Display the detailed NTDP
display ntdp single-device mac-address
information of a specified
mac-address
device
View cluster state and statistics display cluster
display cluster base-topology
View the standard topology Available in any
[ mac-address mac-address | member-id
information view
member-number ]
View the current blacklist of the
display cluster black-list
cluster
View the information of display cluster candidates [ mac-address
candidate devices mac-address | verbose ]
display cluster current-topology

Display the current topology [ mac-address mac-address
information or the topology [ to-mac-address mac-address ] |
path between two devices member-id member-number [ to-member-id
member-number ] ]
display cluster members [ member-number
Display members in a cluster
| verbose ]
Available in user
Clear NDP statistics reset ndp statistics [ interface interface-list ]
view
Cluster Management Configuration Example

z Three switches form cluster abc, whose management VLAN is VLAN 10. In the cluster, Switch B
serves as the management device (Administrator), whose network management interface is
VLAN-interface 2; Switch A and Switch C are the member devices (Member).
z All the devices in the cluster use the same FTP server and TFTP server on host 63.172.55.1/24,
and use the same SNMP NMS and log services on host IP address: 69.172.55.4/24.
z Add the device whose MAC address is 000f-e201-0013 to the blacklist.
25-19

Figure 25-4 Network diagram for cluster management configuration
1) Configure the member device Switch A

# Enable NDP globally and for port GigabitEthernet 1/0/1.
[SwitchA] ndp enable
[SwitchA-GigabitEthernet1/0/1] ndp enable
# Enable NTDP globally and for port GigabitEthernet 1/0/1.

[SwitchA] ntdp enable
[SwitchA-GigabitEthernet1/0/1] ntdp enable
# Enable the cluster function.

[SwitchA] cluster enable
2) Configure the member device Switch C
As the configurations of the member devices are the same, the configuration procedure of Switch C is
omitted here.
3) Configure the management device Switch B
# Enable NDP globally and for ports GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3.
[SwitchB] ndp enable
[SwitchB-GigabitEthernet1/0/2] ndp enable
[SwitchB-GigabitEthernet1/0/3] ndp enable
25-20

# Configure the period for the receiving device to keep NDP packets as 200 seconds.
[SwitchB] ndp timer aging 200
# Configure the interval to send NDP packets as 70 seconds.

[SwitchB] ndp timer hello 70
# Enable NTDP globally and for ports GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3.
[SwitchB] ntdp enable
[SwitchB-GigabitEthernet1/0/2] ntdp enable
[SwitchB-GigabitEthernet1/0/3] ntdp enable
# Configure the hop count to collect topology as 2.

[SwitchB] ntdp hop 2
# Configure the delay to forward topology-collection request packets on the first port as 150 ms.
[SwitchB] ntdp timer hop-delay 150
# Configure the delay to forward topology-collection request packets on the first port as 15 ms.
[SwitchB] ntdp timer port-delay 15
# Configure the interval to collect topology information as 3 minutes.

[SwitchB] ntdp timer 3
# Configure the management VLAN of the cluster as VLAN 10.

[SwitchB] vlan 10
[SwitchB] management-vlan 10
# Configure ports GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 as Trunk ports and allow packets
from the management VLAN to pass.
# Enable the cluster function.

[SwitchB] cluster enable
# Configure a private IP address range for the member devices, which is from 172.16.0.1 to
172.16.0.7.
[SwitchB] cluster
[SwitchB-cluster] ip-pool 172.16.0.1 255.255.255.248
# Configure the current device as the management device, and establish a cluster named abc.
25-21

[SwitchB-cluster] build abc
Restore topology from local flash file,for there is no base topology.
(Please confirm in 30 seconds, default No). (Y/N)
N
# Enable management VLAN auto-negotiation.

[abc_0.SwitchB-cluster] management-vlan synchronization enable
# Configure the holdtime of the member device information as 100 seconds.

[abc_0.SwitchB-cluster] holdtime 100
# Configure the interval to send handshake packets as 10 seconds.

[abc_0.SwitchB-cluster] timer 10
# Configure the FTP Server, TFTP Server, Log host and SNMP host for the cluster.
[abc_0.SwitchB-cluster] ftp-server 63.172.55.1
[abc_0.SwitchB-cluster] tftp-server 63.172.55.1
[abc_0.SwitchB-cluster] logging-host 69.172.55.4
[abc_0.SwitchB-cluster] snmp-host 69.172.55.4
# Add the device whose MAC address is 00E0-FC01-0013 to the blacklist.

[abc_0.SwitchB-cluster] black-list add-mac 00e0-fc01-0013
[abc_0.SwitchB-cluster] quit
# Add port GigabitEthernet 1/0/1 to VLAN 2, and configure the IP address of VLAN-interface 2.
[abc_0.SwitchB] vlan 2
[abc_0.SwitchB-vlan2] port gigabitethernet 1/0/1
[abc_0.SwitchB] quit
[abc_0.SwitchB] interface vlan-interface 2
[abc_0.SwitchB-Vlan-interface2] ip address 163.172.55.1 24
[abc_0.SwitchB-Vlan-interface2] quit
# Configure VLAN-interface 2 as the network management interface.

[abc_0.SwitchB] cluster
[abc_0.SwitchB-cluster] nm-interface vlan-interface 2
25-22

26 IRF Configuration
When configuring IRF, go to these sections for information you are interested in:
z IRF Overview
z IRF Working Process
z IRF Configuration Task List
z IRF Configuration
z Logging In to an IRF
z Displaying and Maintaining IRF
z IRF Configuration Examples
IRF Overview
Introduction
Intelligent Resilient Framework (IRF) allows you to build an IRF, namely a united device, by
interconnecting multiple devices through IRF ports. You can manage all the devices in the IRF by
managing the united device.
In an IRF, every single device is an IRF member, and plays one of the following two roles according to
its function:
z Master: A member device. It is elected to manage the entire IRF. An IRF has only one master at
one time.
z Slave: A member device. It is managed by the master and operates as a backup of the master. In
an IRF, except for the master, all the other devices are the slaves.
For details of role election, refer to Role Election.
Application and Advantages
Typically, you can use an IRF in the distribution layer; and you can also apply it in the access layer. An
IRF is a single logical device to the users and devices of the upper layer and lower layer, as shown in
Figure 26-1.
25-1

Figure 26-1 IRF networking
IP network IP network
Master Slave Slave
Equals IRF
IRF cable IRF cable
IRF has the following advantages:

z Simple management
After an IRF is formed, you can log in to the IRF system by connecting to a port of any IRF member.
When you log in to the IRF, actually you log in to the master device of the IRF. You can manage all IRF
members by configuring the master, for example, allocating IP addresses to the members,
interconnecting the members, and running routing protocols.
z Powerful network expansion capability
By adding member devices, you can increase the number of IRF ports, expand network bandwidth,
and improve processing capability of the IRF system.
z High reliability
Not only the physical IRF ports of members can be aggregated, but also the physical links between the
IRF system and the upper or lower layer devices can be aggregated, and thus the reliability of the IRF
system is increased through the link backup.
The IRF system comprises multiple member devices: the master runs, manages and maintains the IRF,
whereas the slaves process services as well as functioning as the backups. When the master fails, the
IRF system elects a new master immediately to prevent service interruption and implement 1:N
backup.
IRF Working Process

The life cycle of an IRF involves four stages: IRF Connections, Topology Collection, Role Election, and
IRF Management.
IRF Connections
Pysical IRF port
To make an IRF operate normally, you need to connect the IRF members physically. Physical ports
that are dedicated to IRF connection on devices are called physical IRF ports. For the Switch 4510G
series, the 10 GE interface modules can be inserted into the expansion module slots on the rear panel
25-2

of the switch to provide physical IRF ports. The following 10 GE interface modules can be used to
provide physical IRF ports:
z One-port 10 GE XFP interface module
z Dual-port 10 GE XFP interface module
z Short-haul dual-port 10 GE CX4 interface module
z Dual-port 10 GE SFP+ interface module
For the details of the interface modules, refer to the user manual.
You can connect physical IRF ports of the Switch 4510G series with either the CX4 dedicated cables
or fibers according to the interface type on the interface module. Dedicated cables provide higher
reliability and performance; whereas fibers connect physical devices located very far from each other
and provide flexible application.
The physical IRF ports are numbered according to their physical locations on the rear panel of the
Switch 4510G series. With the rear panel facing you, the physical IRF ports are numbered
successively from left to right: ports on the interface module in slot 1 are numbered 1 and 2, and ports
on the interface module in slot 2 are numbered 3 and 4, as shown in Figure 26-2, which illustrates an
example of inserting a CX4 dual-port interface module.
Figure 26-2 Numbering physical IRF ports
If you insert a one-port interface module into the slot, then the number of the physical IRF port
corresponding to the module in slot 1 is 1, and the number of the physical IRF port corresponding to
the module in slot 2 is 3. For the number of physical IRF ports, see Configuring IRF Ports.
Physical IRF ports can be used for both IRF connection and service data transmission. When
establishing an IRF, you need to specify that the physical IRF ports are used for the IRF, that is, bind
them with IRF port(s) to implement IRF connection and establishment.
IRF port
You can set a physical IRF port as an IRF port, which is used to transfer data and protocol packets
among IRF members. An Switch 4510G series can be configured with two IRF ports, which are
numbered 1 and 2, to connect other devices in an IRF.
25-3

An IRF typically has a bus connection or a ring connection:
z Bus connection: Given a device, its IRF port 1 is connected to IRF port 2 of another device, and its
IRF port 2 is connected to IRF port 1 of a third one; devices are connected to form a single straight
connection, as shown in Figure 26-3.
z Ring connection: Given a device, its IRF port 1 is connected to IRF port 2 of another device, and
its IRF port 2 is connected to IRF port 1 of a third one, as shown in Figure 26-3.
Figure 26-3 Physical connections of IRF
A ring connection is more reliable than a bus connection. The failure of one link in a ring connection
does not affect the function and performance of the IRF, whereas the failure of one link in a bus
connection causes the split of the IRF.
You can connect at most four Switch 4510G series switches to form an IRF.
Correspondence between an IRF port and a physical IRF port
The connection of IRF ports is based on that of physical IRF ports; therefore, you need to bind an IRF
port with physical IRF port(s). AN IRF port can be bound to one physical IRF port or, to realize link
backup and bandwidth expansion, bound to two physical IRF ports (aggregated as an aggregate IRF
port).
You need to specify the correspondence between an IRF port and physical IRF port(s) through
command line. When you specify that an IRF port is bound to one physical IRF port, the serial number
of the physical IRF port bound to IRF port 1 must be smaller than that of the physical IRF port bound to
IRF port 2; when you specify that an IRF port is bound to two physical IRF ports (aggregate IRF port),
these two physical IRF ports must be on the same module.
As shown in Figure 26-4. Switch A connects to Switch B and Switch C through IRF ports IRF-port 1
and IRF-port 2 respectively.
25-4

Figure 26-4 IRF port correspondence
Based on the type and number of the interface module inserted on Switch A, you can adopt one of the
following typical correspondences to establish an IRF connection.
z The dual-port 10 GE CX4 interface module is used in the following examples to introduce
correspondence between the IRF port and the physical IRF port(s).
z When the dual-port 10 GE SFP interface module is used, the correspondence between the IRF
port and the physical IRF port(s) is similar.
2) IRF port correspondence for one interface module

Figure 26-5 IRF port correspondence for one interface module
When a dual-port interface module is installed, you need to bind IRF-port 1 to physical IRF port 1, and
IRF-port 2 to physical IRF port 2 (as shown in Figure 26-5), because the serial number of the physical
IRF port bound to IRF-port 1 must be smaller than that of the physical IRF port bound to IRF-port 2.
Therefore, you cannot bind IRF-port 1 to physical IRF port 2, and IRF-port 2 to physical port 1.
z If only one single-port interface module is installed, the device can be used only as Switch B or
Switch C in Figure 26-4, that is, the device should be at either end of a bus connection.
z In this situation, because only one IRF port is needed on Switch B or Switch C, IRF-port 2 or
IRF-port 1 can be bound to any physical port on the device.
3) IRF port correspondence for two interface modules

z Correspondence in non-aggregate mode
25-5

Figure 26-6 Correspondence in non-aggregate mode for two interface modules
When two dual-port interface modules are installed, if the correspondence is not in the aggregate
mode, you can bind an IRF port to any physical IRF port (Figure 26-6 only shows one possibility).
However, you must ensure that the serial number of the physical IRF port bound to IRF-port 1 is
smaller than that of the physical IRF port bound to IRF-port 2, namely, the physical IRF port bound to
IRF-port 2 should be located on the right side of the physical IRF port bound to IRF-port 1. The two
physical IRF ports bound to the IRF ports can be located either on one interface module or on different
interface modules.
z If two single-port interface modules are installed, you need to bind IRF-port 1 to physical IRF port
1, and IRF-port 2 to physical IRF port 3.
z If one dual-port interface module and one single-port interface module are installed, the
correspondence is the same with that when you install two dual-port interface modules. In this
situation, IRF-port 2 or IRF-port 1 can be bound to any physical port on the device, because only
one IRF port is needed on Switch B or Switch C.
z Correspondence in aggregate mode

Figure 26-7 Correspondence in aggregate mode for two interface modules
Because the two physical IRF ports bound to an aggregate IRF port must be located on the same
interface module, two IRF ports (that is, two aggregate IRF ports) can only be bound to the two
physical IRF ports on each of the two interface modules respectively (as shown in Figure 26-7). In
25-6

addition, you can only bind IRF-port 1 to physical IRF ports 1 and 2, and IRF-port 2 to physical ports 3
and 4.
If one dual-port interface module and one single-port interface module are installed, you can bind two
physical IRF ports on the dual-port interface module to the IRF port in aggregate mode, and bind the
physical IRF port on the single-port interface module to the other IRF port in non-aggregate mode. In
this situation, IRF-port 2 or IRF-port 1 can be bound to any physical port on the device, because only
one IRF port is needed on Switch B or Switch C.
Topology Collection
Each device in an IRF exchanges hello packets with the directly connected neighbors to collect
topology of the entire IRF. The hello packets carry topology information, including IRF port connection
states, member IDs, priorities, and bridge MAC addresses.
Each member records its known topology information locally. At the initiation of the collection, the
members record their own topology information. When an IRF port of a member becomes up, the
member sends its known topology information from this port periodically. Upon receiving the topology
information, the directly connected neighbor updates the local topology information.
The collection process lasts for a period of time. When all members have obtained the complete
topology information (known as topology convergence), the IRF will enter the next stage: role election.
Role Election
An IRF is composed of multiple member devices; each member has a role, which is either master or
slave. The process of defining the role of IRF members is role election.
Role election is held when the topology is instable, such as, forming an IRF, adding a new member,
IRF split, or IRF merge. The master is elected according to the following principles one by one, until
the only winner is found out:
z The current master wins, even if a new member has a higher priority. (When an IRF is being
formed, there is no master, and all member devices consider themselves as the master, so this
principle will be skipped)
z A member with a higher priority wins.
z A member with the longest system up-time wins.
z A member with the lowest bridge MAC address wins.
In this stage, member ID collision, software version loading and IRF merging are also handled, which
are discussed in the later sections.
When a device is booted, it first collects topology information and then participates in the role election.
After that, the IRF system can run normally. When the role election is finished, the IRF enters the next
stage: IRF maintenance.
25-7

z The precision of the system up-time is six minutes. For example, if two devices with the same
priority values reboot one after another within six minutes, they will have the same system up-time
and the last role election principle will be followed, that is, the one with the lowest bridge MAC
address wins.
z IRF merge: The process of connecting two existing IRFs with IRF cables. After the mergence, IRF
election is held, and members of the loser side reboot and join the winner side as slaves.
z IRF split: In an IRF, the failure of IRF cables or power-off of a member causes physical
disconnection between two devices, and the process is IRF split.
IRF Management
Member ID
An IRF uses member IDs to uniquely identify and manage member devices. For a device that does not
support IRF, an interface is named GigabitEthernet 1/0/1, where the first number is always 1; for a
device that supports IRF, if its member ID is 2, the name of the interface changes to GigabitEthernet
2/0/1, where the first number indicates the member ID of the device.
A member ID is a natural number in the range 1 to 10; the default member ID is 1. To ensure the
uniqueness of member IDs, you can plan and configure member IDs for IRF members before they join
the IRF.
After multiple devices form an IRF, a logical distributed device is formed. Each member device acts as
a card on the distributed device. The master acts as the active main board (AMB) and the slaves act as
the standby main boards (SMBs), and meantime, each member device also acts as an interface board.
As shown in Figure 26-8, an IRF system comprises four members, which are numbered 1, 2, 3 and 4.
After the IRF is established, the IRF system functions like a distributed device: slots 1,2, 3 and 4 are
inserted with boards, and each board has its own power supply unit (PSU), fan, CPU, console port and
Ethernet interfaces.
Figure 26-8 IRF
Virtual logical device

Master
Main
(member-id1) slot 1
IRF link Slave 1

slot 2
Slave1
(member-id2) Slave 2
After the IRF is slot 3
IRF link established
Slave2 Slave 3
(member-id3) slot 4
IRF link
Slave3
(member-id4)
25-8

Interface name
For a device operating independently (that is, the device does not belong to any IRF), its interface
name is in the following format: member ID/slot number/interface serial number, where
z By default, member ID is 1.
z After a device leaves an IRF, it continues using the member ID when it was in the IRF as its
device ID.
z Subslot number is the number of the slot in which the LPU resides. For a box-type device, LPUs
are fixed on the device, so the slot number is a fixed value. On the Switch 4510G series, the
subslot on the front panel is numbered 0, and subslots of the two expansion slots on the rear
panel are numbered 1 and 2 from left to right.
z Interface serial number is dependent on the number of interfaces supported by the device. View
the silkscreen on the interface card for the number of supported interfaces.
For example, GigabitEthernet 1/0/1 is an interface on the independently operating device Sysname.
To set the link type of GigabitEthernet 1/0/1 to trunk, perform the following steps:
For an IRF member, the interface name also adopts the previously introduced format: member ID/slot
number/interface serial number, where
z The member ID identifies the IRF member on which the interface resides
z Meaning and value of the subslot number and the interface serial number are the same as those
on an independently operating device.
For example, GigabitEthernet 1/0/1 is an interface on IRF member slave 3 (member ID is 3). To set the
link type of GigabitEthernet 1/0/1 to trunk, perform the following steps:
<Master> system-view
[Master] interface gigabitethernet 3/0/1
[Master-GigabitEthernet3/0/1] port link-type trunk
File system name
You can use the name of the storage device to access the file system of an independently operating
device. For the naming rules of a storage device, refer to the File System Management Configuration
in the System Volume.
For example, flash is the storage device on the independently operating device Sysname. To back up
the file aa.cfg under the root directory of the flash to the test folder, perform the following steps:
<Sysname> mkdir test
...
%Created dir flash:/test.
<Sysname>copy aa.cfg test/aa(20080714).cfg

Copy flash:/aa.cfg to flash:/test/aa(20080714).cfg?[Y/N]:y
..
%Copy file flash:/aa.cfg to flash:/test/aa(20080714).cfg...Done.
<Sysname> cd test
<Sysname> dir
Directory of flash:/test/
25-9

0 -rw- 1568 Jul 14 2008 11:54:04 aa(20080714).cfg
To access the file system of the master, use the name of the storage device; to access the file system
of a slave, use the name in the following format: Member-ID#Storage-device-name.
For example:
1) To access the test folder under the root directory of the flash on the master, perform the following
steps:
<Master> mkdir test
...
%Created dir flash:/test.
<Master> dir
0 -rw- 10105088 Apr 26 2000 13:44:57 test.bin
1 -rw- 2445 Apr 26 2000 15:18:19 config.cfg
2 drw- - Jul 14 2008 15:20:35 test
2) To create and access the test folder under the root directory of the flash on IRF member slave 3,
perform the following steps:
<Master> mkdir slot3#flash:/test
%Created dir slot3#flash:/test.
<Master> cd slot3#flash:/test
<Master> pwd
slot3#flash:/test
Or:
<Master> cd slot3#flash:/
<Master> mkdir test
%Created dir slot3#flash:/test.
3) To copy the test.bin file on the master to the root directory of the flash on IRF member slave 3,
perform the following steps:
<Master> pwd
slot3#flash:
//The above information indicates that the current working path is the root directory of the flash on
slave 3.
<Master> cd flash:/
<Master> pwd
flash:
// The above operations indicate that the current working path is the root directory of the flash on the
master.
<Master> copy test.bin slot3#flash:/
Copy flash:/test.bin to slot3#flash:/test.bin?[Y/N]:y
%Copy file flash:/test.bin to slot3#flash:/test.bin...Done.
Configuration file management
1) Configuration file synchronization
25-10

IRF uses a strict configuration file synchronization mechanism to ensure that devices in an IRF can
work as a single device on the network, and to ensure that after the master fails, the other devices can
operate normally.
z When a slave starts up, it automatically finds out the master, synchronizes the master's
configuration file, and executes the configuration file; if all devices in an IRF start up
simultaneously, the slaves synchronize the master's initial configuration file and execute it.
z When the IRF operates normally, all your configurations will be recorded into the current
configuration file of the master, and are synchronized to each device in the IRF; when you save
the current configuration file of the master as the initial configuration file by using the save
command, all slaves execute the same saving operation to make the initial configuration files of all
devices consistent.
Through the real-time synchronization, all devices in the IRF keep the same configuration file. If the
master fails, all the other devices can execute various functions according to the same configuration
file.
2) Configuration file application
The configuration file can be divided into two parts: global configuration and port configuration. When a
slave applies these two kinds of configurations of the master, it deals with them in different ways:
z Global configuration: All slaves execute the current global configuration on the master exactly,
that is, all members in the IRF apply the same global configuration.
z Port configuration: When a slave applies the port configuration on the master, it cares about the
configuration related to its own port, for example, the slave with the member ID of 3 only cares
about the configuration related to the GigabitEthernet 3/0/x port on the master. If there is a
configuration related to its own port, it will apply the configuration; if not, no matter what
configuration has been made to the port before the slave joins the IRF, the slave will function
using null-configuration.
IRF maintenance
In an IRF, direct neighbors exchange hello packets periodically (the period is 200 ms). Without
receiving any hello packet from a direct neighbor for ten periods, a member considers that the hello
packets timed out, and the IRF isolates the expired device in the topology and updates its topology
database.
When an IRF port of a member becomes down, the member broadcasts the information to all the other
members immediately. If the IRF port of the master is down, an election is triggered.
IRF Configuration Task List

Before configuring an IRF, you need to define the roles and functions of all the members for better
planning. Because the configuration of some parameters takes effect after device reboot, you are
recommended to first configure parameters, power off the devices, connect devices physically, power
on the devices, and finally the devices will join in the IRF automatically. After an IRF is formed, you can
configure and manage the IRF by logging in to any device in the IRF. The operations you make take
effect on the master, and will be applied to the member devices in the IRF. For easy fault location and
device maintenance, the Switch 4510G provides slave view, where you can execute the display,
terminal, and debug commands.
25-11

Complete the following tasks to configure IRF:
Task Remarks
Configuring IRF Ports Required
Setting a Member ID for a Device Optional
Specifying a Priority for an IRF Member Required
IRF Configuration Specifying the Preservation Time of IRF Bridge

Optional
MAC Address
Enabling Auto Upgrade of Boot Files Optional
Setting the Delay Time for the Link Layer to
Optional
Report a Link-Down Event
Connect the physical IRF ports of devices by using IRF cables (a ring connection is recommended)
or fibers, and then power on the devices.
Logging In to the Master Required
Logging In to an IRF
Logging In to a Slave Optional
IRF Configuration
Configuring IRF Ports
IRF can be enabled on a device only after the IRF ports are bound with physical IRF ports).
For how to bind the IRF port and physical IRF port(s) on an Switch 4510G series, see Correspondence
between an IRF port and a physical IRF port.
Follow these steps to configure IRF ports

Bind physical IRF ports to an Required

irf member member-id irf-port
IRF port, and enable IRF on By default, no IRF port is
irf-port-id port port-list
the current device configured.
25-12

z The above configuration takes effect after the reboot of the device.
z AN IRF port that is bound with multiple physical IRF ports is an aggregation IRF port, which
increases the bandwidth and reliability on the IRF port. If you specify multiple physical IRF ports
with the port-list argument, you can configure an aggregation IRF port. You can configure at most
two physical IRF ports as an aggregation IRF port for an Switch 4510G series switch, and you can
only aggregate physical IRF ports 1 and 2, and physical IRF ports 3 and 4.
z The irf-port-id argument represents the IRF port number. The port-list argument represents the
physical IRF port number. For the correspondence of IRF ports, refer to Correspondence between
an IRF port and a physical IRF port.
z When you insert a one-port interface module into the slot on the rear panel, if the interface module
is in slot 1, the port on it will be numbered 1; and if the interface module is in slot 2, the port on it
will be numbered 3.
Setting a Member ID for a Device
The member ID of a device defaults to 1. During the establishment of an IRF, when the devices that
form the IRF have duplicated member IDs, the member ID of the master is decided first, and then the
member IDs of slaves are decided one by one according to their distances to the master, that is, the
nearest slave gets the smallest available ID, and the nearer slave gets the smaller available ID, and so
forth; after the IRF is established, if the newly added device and another member have duplicated IDs,
the IRF system assigns the smallest available ID for the new member. You can also set the member
IDs according to network planning.
For a device that is already in an IRF, you can use commands in Table 26-1 to modify the member ID
of the device, and this modification will be effective after the reboot of the device.
For a device that is not in an IRF, you are recommended to set its member ID in the following way:
1) Plan the member IDs in advance. You can view the member IDs of an IRF, and find out an unused
ID for the new device.
2) Log in to the device to be added into the IRF, and change its member ID to the unused ID found
out in step 1.
3) Save the current configuration. Power off the device, connect the device with IRF cables and
power it on. Use the configuration introduced in this section to enable IRF on the device and add it
into the IRF.
Table 26-1 Set a member ID for a device

Optional
irf member member-id renumber
Set a member ID for a device The member ID of a device
new-id
defaults to 1
25-13

z The above setting takes effect after the reboot of the device.
z You can use the display irf configuration command to view the current member ID of the device
and the member ID will be used after the device reboot.
z In an IRF, member IDs are not only used to identify devices, but also used to identify the port
configurations on different member devices in the configuration file. Therefore, modifying a
member ID may cause device configuration changes or even losses, so modify member ID with
caution. For example, three members (of same device model) with the member IDs of 1, 2 and 3
are connected to an IRF port. Suppose that each member has several ports: change the member
ID of device 2 to 3, change that of device 3 to 2, reboot both devices, and add them into the IRF
again. Then device 2 will use the original port configurations of device 3, and device 3 will use
those of device 2.
Specifying a Priority for an IRF Member
Each IRF member has a priority. During the master election, a member with the greatest priority will be
elected as the master.
The priority of a device defaults to 1. You can modify the priority through command lines. The greater
the priority value, the higher the priority. A member with a higher priority is more likely to be a master,
and more likely to preserve its ID in a member ID collision.
Follow these steps to specify a priority for an IRF member:

Optional
Specify a priority for an IRF irf member member-id priority
member priority The priority of an IRF
member defaults to 1
The setting of priority takes effect right after your configuration without the need of rebooting the
device.
Specifying the Preservation Time of IRF Bridge MAC Address
A device uses the bridge MAC address when it communicates with the outside as a network bridge. A
bridge device on the network has its unique bridge MAC address. Some Layer 2 protocols (like LACP)
use bridge MAC addresses to identify different devices. During the forwarding of Layer 2 packets, if the
destination MAC address of a packet is the bridge MAC address of a device, it means that the packet
is sent to this device.
25-14

In an IRF, the bridge MAC address of a member device is called member bridge MAC address. The
IRF communicates with the outside as a single device; therefore, it also has a bridge MAC address,
which is called the IRF bridge MAC address. Typically, an IRF uses the bridge MAC address of the
master device as the IRF bridge MAC address.
You are recommended to configure the preservation time of IRF bridge MAC address properly,
otherwise, network problems will occur:
z If a master leaves an IRF to join another IRF or to operate independently and the IRF is
configured to preserve the bridge MAC address permanently, bridge MAC address collision
occurs and thus causes network communication problem.
z If the master leaves the IRF because of reboot or link failure and the IRF is configured to change
the IRF bridge MAC address as soon as the master leaves, the unnecessary switch of bridge
MAC address occurs and thus causes flow interruption.
Therefore, configure the preservation time IRF bridge MAC address according to your network status:
z Preserve for six minutes: After the master leaves, the bridge MAC address will not change within
six minutes. If the master does not come back after six minutes, the IRF system will use the bridge
MAC address of the newly elected master as that of the IRF.
z Preserve permanently: No matter the master leaves the IRF or not, the IRF bridge MAC address
remains unchanged.
z Not preserved: As soon as the master leaves, the system will use the bridge MAC address of the
newly elected master as that of the IRF.
Follow these steps to specify preservation time of IRF bridge MAC address:

Configure the IRF bridge MAC
irf mac-address persistent
address to be preserved permanently
always Optional
after the master leaves
By default, IRF
Specify the preservation time of the bridge MAC
IRF bridge MAC address as 6 irf mac-address persistent timer address is
minutes after the master leaves preserved for 6
minutes after the
Configure that the IRF bridge MAC master leaves.
address changes as soon as the undo irf mac-address persistent
master leaves
The change of the bridge MAC address may cause a temporary flow interruption.
Enabling Auto Upgrade of Boot Files
If this function is disabled, when the boot files of slaves and that of the master are in different versions,
the new member or the member with a low priority will not boot normally. You need to update the
device version manually and add the device into the IRF again.
25-15

If this function is enabled, as soon as a device is added into an IRF, the system compares its software
version with that of the master. If the versions are not consistent, the device downloads the boot file
from the master automatically, reboots with the new boot file, and joins the IRF again. If the
downloaded boot file and the local file have duplicate file names, the local file is overwritten.
Follow these steps to enable auto upgrade of boot files in an IRF:

Enable auto upgrade of boot Optional

irf auto-update enable
files in an IRF Enabled by default
z Although IRF supports the auto upgrade of boot files, to shorten the time for IRF establishment
and reduce the influences caused by the IRF establishment to the network, you are recommended
to ensure that the device and the IRF master have the same software version before adding a
device into an IRF.
z After loading the masters boot file automatically, a slave configures the file as the boot file for the
next boot and reboots automatically.
z Because system boot file occupies large memory space, to make the auto upgrade succeed,
ensure that there is enough space on the storage media of the slave.
Setting the Delay Time for the Link Layer to Report a Link-Down Event
During the suppression time, the system cannot be aware of the switch between IRF link states; after
the suppression time, the link layer reports the link state changes to the system. Use this function to
avoid the reboots of devices caused by the frequent link state changes of IRF ports in a short time (for
example, an IRF splits and then merges quickly), preventing service interruption.
Follow these steps to set the delay time for the link layer to report a link-down event of an IRF:

Set the delay time for the link Optional

layer to report a link-down irf link-delay interval The function is disabled by
event of an IRF default.
Do not set the time interval to a very long time; otherwise, the IRF system will not be aware of the IRF
topology changes in time and thus the service will be recovered slowly.
25-16

Logging In to an IRF
Logging In to the Master
After an IRF is formed, you can access the console of the IRF system through the AUX or console port
of any member device. Configure an IP address for the VLAN interface of a member device and make
sure that the route is reachable, and then you can access the IRF system remotely through Telnet,
Web, or SNMP.
When you log in to the IRF, actually you log in to the master device of the IRF. The master is the
configuration and control center of an IRF. After you configure the IRF on the master, the IRF system
synchronizes the configurations to the slaves.
Logging In to a Slave
When you log in to an IRF, actually you log in to the master device of the IRF. The operation interface
of the access terminal displays the master console. However, the device can redirect you to a specified
slave device. After you are redirected to a slave device, the user access terminal displays the console
of the slave device instead of that of the master device. The system enters user view of the salve
device and the command prompt is changed to <Sysname-member ID>, for example, <Sysname-2>.
What you have input on the access terminal will be redirected to the specified slave device for
processing. At present, only the following commands are allowed to be executed on a slave device:
z display
z quit
z return
z system-view
z debugging
z terminal debugging
z terminal trapping
z terminal logging
You can press Ctrl+K or use the quit or return command to return to the master console. At this time,
the master console is reactivated, and therefore it can output system information and logs.
Follow the steps below to log in to the specified slave device:

Required
Log in to the specified slave By default, you actually log in to the
irf switch-to member-id
device of an IRF master device of an IRF when you log
in to the IRF.
Because users login to the IRF system occupies large memory space, an IRF system allows at most
six users to log in at the same time. The permitted login user types are console and virtual type
terminal (VTY).
25-17

Displaying and Maintaining IRF
Display related information of the IRF display irf Available in any view
Display topology information of the IRF display irf topology Available in any view
Display the pre-configurations of all

members of the IRF (The
display irf configuration Available in any view
pre-configuration takes effect after the
reboot of the device.)
Display the master/slave switchover display switchover state
states of IRF members [ member-id ]
IRF Configuration Examples

IRF Connection Configuration Example
Three Switch 4510G series switches in an IRF form a bus connection. Their member IDs are 1, 2, and
3, as shown in Figure 26-9.
Figure 26-9 Network diagram for IRF
1 2 3 4 Switch 1
1 2 3 4 Switch 2
1 2 3 4 Switch 3
1) The three devices are not connected. Power them on and configure them separately.
# Configure Switch 1.
<Switch1> system-view
[Switch1] irf member 1 renumber 1
Warning: Renumbering the switch number may result in configuration change or loss.
Continue?[Y/N]:y
[Switch1] irf member 1 irf-port 1 port 2
<Switch2>system-view
25-18

Continue?[Y/N]:y
<Switch3> system-view
Continue?[Y/N]:y
2) Power off the three devices. Connect them as shown in Figure 26-9 with IRF cables. Power them
on, and the IRF is formed.
25-19

27 IPC Configuration
When configuring IPC, go to these sections for information you are interested in:
z IPC Overview
z Enabling IPC Performance Statistics
z Displaying and Maintaining IPC
IPC Overview
Introduction to IPC
Inter-Process Communication (IPC) is a reliable communication mechanism among different nodes.

The following are the basic concepts in IPC.
Node
An IPC node is an entity supporting IPC; it is an independent processing unit. In actual application, an
IPC node corresponds to one CPU.
z One centralized device has only one CPU, therefore corresponding to one node.
z An Intelligent Resilient Framework (IRF) is an interconnection of several centralized devices, with
each member device corresponding to one node. Therefore, an IRF corresponds to multiple
nodes.
z Typically a distributed device is available with multiple boards, each having one CPU, some
boards are available with multiple CPUs. Some distributed devices may be available with multiple
CPUs, for example service CPU and OAM CPU. Therefore, a distributed device corresponds to
multiple nodes.
Therefore, in actual application, IPC is mainly applied on an IRF or distributed device; it provides a
reliable transmission mechanism between different devices and boards.
Link
An IPC link is a connection between any two IPC nodes. There is one and only one link between any
two nodes for packet sending and receiving. All IPC nodes are fully connected.
IPC links are created when the system is initialized: When a node starts up, it sends handshake
packets to other nodes; a connection is established between them if the handshake succeeds.
The system identifies the link connectivity between two nodes using link status. An IPC node can have
multiple links, each having its own status.
Channel
A channel is a communication interface for an upper layer application module of a node to

communicate with an application module of a peer node. Each node assigns a locally unique channel
number to each upper layer application module.
27-1

Data of an upper layer application module is sent to the IPC module through a channel, and the IPC
module sends the data to a peer node through the link. The relationship between a node, link and
channel is as shown in Figure 27-1.
Figure 27-1 Relationship between a node, link and channel
Node 1
Application 2
Application 1 IPC Application 3

Ch
2
a nn
el
el
nn
1
ha
C
Application 1 IPC Application 3
Application 2
Node 2
Packet sending modes
IPC supports three packet sending modes: unicast, multicast (broadcast is considered as a special
multicast), and mixcast, each having a corresponding queue. The upper layer application modules can
select one as needed.
z Unicast: packet sending between two single nodes.
z Multicast: packet sending between a single node and multiple nodes. To use the multicast mode,
a multicast group needs to be created first. Multicasts will be sent to all the nodes in the multicast
group. An application can create multiple multicast groups. The creation and deletion of a
multicast group and multicast group members depend on the application module.
z Mixcast, namely, both unicast and multicast are supported.
Enabling IPC Performance Statistics

When IPC performance statistics is enabled, the system collects statistics for packet sending and
receiving of a node in a specified time range (for example, in the past 10 seconds, or in the past 1
minute). When IPC performance statistics is disabled, statistics collection is stopped. At this time, if
you execute the display command, the system displays the statistics information at the time when IPC
performance statistics was disabled.
Follow these steps to enable IPC performance statistics:
ipc performance enable Required

Enable IPC performance
{ node node-id | self-node } Disabled by default
statistics
[ channel channel-id ] Available in user view
27-2

Displaying and Maintaining IPC
Display IPC node information display ipc node
Display channel information of display ipc channel { node node-id |

a node self-node }
Display queue information of a display ipc queue { node node-id |
node self-node }
Display multicast group display ipc multicast-group { node
information of a node node-id | self-node }
Display packet information of a display ipc packet { node node-id |
node self-node }
Display link status information display ipc link { node node-id |
of a node self-node }
display ipc performance { node
Display IPC performance
node-id | self-node } [ channel
statistics information of a node
channel-id ]
Clear IPC performance reset ipc performance [ node node-id |
statistics information of a node self-node ] [ channel channel-id ]
27-3

28 Automatic Configuration
When configuring automatic configuration, go to these sections for information you are interested in:
z Introduction to Automatic Configuration
z Typical Networking of Automatic Configuration
z How Automatic Configuration Works
Introduction to Automatic Configuration

Automatic configuration enables a device to automatically obtain and execute the configuration file
when it starts up without loading the configuration file.
Automatic configuration simplifies network configuration, facilitating centralized management of
devices. Currently, enterprise networks are facing the problems of large distribution of devices and less
administrators, resulting in the huge cost for administrators to manually configure each device. With
the automatic configuration function, network administrators can save the configuration files on a
specified server and the device can automatically obtain and execute the configuration files, therefore
greatly reducing the workload of administrators.
Typical Networking of Automatic Configuration

Figure 28-1 Network diagram for automatic configuration
As shown in Figure 28-1, the device implements automatic configuration with the cooperation of a
DHCP server, TFTP server and DNS server:
z DHCP server: Assigns an IP address, configure file name, TFTP server IP address, and DNS
server IP address for the device that performs automatic configuration.
z TFTP server: Saves files needed in automatic configuration. A device obtains files needed from a
TFTP server, for example, network intermediate file and the configuration file of the device.
z DNS server: Used for IP address-to-host name resolution. A device that performs automatic
configuration can resolve an IP address to a host name through a DNS server to get the
configuration file with the name hostname.cfg from a TFTP server; if the device gets the domain
28-1

name of the TFTP server from a DHCP response, the device can also resolve the domain name of
the TFTP server to the IP address of the TFTP server through the DNS server.
If the DHCP server, TFTP server, DNS server, and the device that performs automatic configuration
are not in the same segment, you need to configure DHCP relay on a device working as a gateway.
How Automatic Configuration Works

Basically, automatic configuration works in the following ways:
1) When a device starts up without loading any configuration file, the system sets the first active
interface (if an active Layer 2 Ethernet interface exists, this first interface is a virtual interface
corresponding with the default VLAN) as the DHCP client to request from the DHCP server for
parameters, such as an IP address and name of a TFTP server, IP address of a DNS server, and
the configuration file name.
2) After getting related parameters, the device 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 performs system initialization without loading any configuration file.
z To implement auto-configuration, you need to configure some parameters on the DHCP server,
DNS server and TFTP server, but you do not need to perform any configuration on the device that
starts up without loading any configuration file. The configuration mode depends on the device
model; it is omitted here.
z If you need to use the automatic configuration function, you are recommended to connect only the
interfaces needed in automatic configuration to the network.
Work Flow of Automatic Configuration
The work flow of automatic configuration is as shown in Figure 28-2.
28-2

Figure 28-2 Work flow of automatic configuration
Start the device
without loading the
configuration file
The interface obtains No

parameters through
DHCP
Yes
Is the TFTP server address No

contained in the parameters?
Yes
Is the TFTP server domain No
name contained in the
parameters?
Yes
Resolve domain name No Broadcast a TFTP Fails

of the TFTP server request to obtain the
configuration file
Yes Succeeds
Fails Unicast a TFTP
request to obtain the
configuration file
Succeeds
Remove the temporary Remove the temporary
configurations and the device configurations and execute the
starts with null configuration obtained configuration file
Remove the temporary

End configurations and the device
starts with null configuration
Obtaining the IP Address of an Interface and Related Information Through DHCP
Obtaining an IP address
When a device starts up without loading the configuration file, the system automatically configures the
first active interface (if an active Layer 2 Ethernet interface exists, this first interface is a virtual
interface corresponding with the default VLAN) of the device as obtaining its IP address through DHCP.
The device broadcasts a DHCP request through this interface. The Option 55 field specifies the
information (for example, the configuration file name, domain name and IP address of the TFTP server
and DNS server needed for obtaining the automatic configuration files) that the device can obtain from
the DHCP server.
Upon successfully obtaining its IP address through DHCP, the device resolves the Option 67 (or the file
field, configuration file name) field, Option 66 (domain name of the TFTP server) field, Option 150 (IP
address of the TFTP server) field and Option 6 (IP address of the DNS server) field. If failing to obtain
its IP address, the device removes the temporary configuration and starts up without loading the
configuration file.
28-3

z The configuration file name is saved in the Option 67 or file field of the DHCP response. The
device first resolves the Option 67 field; if this field contains the configuration file name, the device
does not resolve the file field; otherwise, it resolves the file field.
z Temporary configuration contains two parts: the configuration on the interface where automatic
configuration is performed when the device starts up with default configuration; and the executed
ip host command when the device is resolving the network intermediate file (For the detailed
description of the ip host command, refer to Domain Name Resolution Commands in the IP
Services Volume.). Removal of the temporary configuration is to execute the undo commands.
z For the detailed introduction to DHCP, refer to DHCP Configuration in the IP Services Volume.
Principles for selecting an address pool on the DHCP server
The DHCP server selects IP addresses and other network configuration parameters from an address
pool when assigning an IP address to a client. DHCP supports two mechanisms for IP address
allocation.
z Dynamic address allocation: The DHCP server assigns an IP address and other configuration
parameters in an address pool to a client.
z Manual address allocation: The DHCP server will select an address pool where an IP address is
statically bound to the MAC address or ID of the client and assign the statically bound IP address
and other configuration parameters to the client.
You can configure an address allocation mode as needed:
z Different devices with the same configuration file: You can configure dynamic address allocation
on the DHCP server to assign IP addresses and the same configuration parameters (for example,
configuration file name) to the devices. If this address allocation mode is adopted, the
configuration file can only contain common configurations of the devices, and the specific
configurations of each device need to be performed in other ways. For example, you need to
specify to enable Telnet on a device through the configuration file obtained in automatic
configuration and create a local user to facilitate the administrator to Telnet to each device to
perform specific configurations (for example, configure the IP address of each interface).
z Different devices with different configuration files: You need to configure an address pool where
an IP address is statically bound to the MAC address or ID of the client, to ensure that a specific
client can be assigned with a fixed IP address and other configuration parameters. Through this
address allocation mode, you can specify different configuration commands for each device,
without the need to configure the device through other modes.
28-4

You need to configure a client ID (when a device works as the DHCP client, it uses the client ID as its
ID) of the static binding when you configure manual address allocation. Therefore, you need to obtain
the client ID in this way: start the device that performs automatic configuration, enable the interface
that performs automatic configuration to obtain its IP address through DHCP, after the IP address is
successfully obtained, use the display dhcp server ip-in-use command to display address binding
information on the DHCP server, thus to obtain the client ID of the device.
Obtaining the Configuration File from the TFTP Server
Configuration file type
The device can obtain the following types of configuration file from the TFTP server with the automatic
configuration function enabled:
z The configuration file specified by the Option 67 or file field in the DHCP response
z The intermediate file, with the file name as network.cfg, used to save the mapping between the
IP address and the host name. The mapping is defined in the following format:
ip host hostname ip-address
For example, the intermediate file can include the following:
ip host host1 101.101.101.101
ip host host2 101.101.101.102
ip host client1 101.101.101.103
ip host client2 101.101.101.104
z There must be a space before the keyword ip host.

z The host name saved in the intermediate file must be the same with the configuration file name of
the host. This host name is not the one saved in the DNS server, and their names can be the
same or different.
z The configuration file corresponding with the host name of the device, with its file name as
hostname.cfg. For example, if the host name of the device is aaa, then the configuration file
name is aaa.cfg.
z Default configuration file, with the name as device.cfg.
28-5

Obtaining the configuration file
Figure 28-3 Obtain the configuration file
Is the configuration file Yes

contained in the DHCP
response?
No
No Obtain the network

intermediate file
Yes
Yes Search the domain name

corresponding to the IP address
in the network intermediate file
No
Resolve an IP No
address to a domain
name through DNS
Yes
Yes Obtain the configuration

file corresponding to the
domain name
No
Yes Obtain the default No Obtain the specified

configuration file configuration file in the
response
No Yes
configurations and the device
configurations and execute the starts without loading the
obtained configuration file configuration file
The device obtains the configuration file from the TFTP server based on its resolution of the
configuration file name in the DHCP response:
z If the DHCP response contains information such as configuration file name, the device requests
the specified configuration file from the TFTP server.
z If no information such as configuration file name is contained in the DHCP response, the device
should obtain its host name first and then requests the configuration file corresponding with the
host name. The device can obtain its host name in two steps: obtaining the intermediate file from
the TFTP server and then searching in the intermediated file for its host name corresponding with
the IP address of the device; if fails, the device obtains the host name from the DNS server.
z If the device fails to obtain the specified configuration file and resolve its host name or fails to
obtain the configuration file corresponding with the host name, it requests the default configuration
file from the TFTP server.
Sending mode of a TFTP request
The device selects the sending mode of the TFTP request based on its resolution of the TFTP servers
domain name and IP address in the DHCP response:
z If a legitimate TFTP server IP address is contained in the DHCP response, the device unicasts a
TFTP request to the TFTP server and does not resolve the domain name of the TFTP server.
Otherwise, the device resolves the TFTP domain name.
z If a legitimate TFTP server domain name is contained in the DHCP response, the device resolves
the IP address of the TFTP server through DNS server. If succeeds, the device unicasts a TFTP
request to the TFTP server; if fails, the device broadcasts a TFTP request to the TFTP server.
28-6

z If the IP address and the domain name of the TFTP server are not contained in the DHCP
response or they are illegitimate, the device broadcasts a TFTP request to the TFTP server.
z When broadcasting a TFTP request, the device obtains the configuration file from the TFTP server
who responds the first. If the required configuration file does not exist on the TFTP server, then
obtaining the configuration file fails, and the device removes the temporary configuration and
starts up without loading the configuration file.
z When the device broadcasts a TFTP request to the TFTP server, you need to configure the UDP
Helper function on a gateway to transfer broadcasts to unicasts and forwards the unicasts to the
specified TFTP server if the device performs the automatic configuration and the TFTP server are
not in the same segment because broadcasts can only be transmitted in a segment. For the
detailed description of the UDP Helper function, refer to UDP Helper Configuration in the IP
Services Volume.
Executing the Configuration File
Upon successfully obtaining the configuration file, the device removes the temporary configuration and
executes the obtained configuration file; otherwise, it removes the temporary configuration and starts
up without loading the configuration file.
After the device executes the configuration file obtained, the configuration file will be deleted.
Therefore, you are recommended to save the configuration using the save command; otherwise, the
device needs to perform the automatic configuration function after system reboot. For the detailed
description of the save command, refer to File System Management Configuration in the System
Volume.
28-7

3com Switch 4510G Family: Configuration Guide

Uploaded by

Copyright:

Available Formats

3com Switch 4510G Family: Configuration Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3com Switch 4510G Family: Configuration Guide

Uploaded by

Copyright:

Available Formats

3Com Switch 4510G Family

Switch 4510G 24-Port

Switch 4510G 48-Port

Downloaded from www.Manualslib.com manuals search engine

UNITED STATES GOVERNMENT LEGEND

Improving our environmental record on a continual basis.

End of Life Statement

Regulated Materials Statement

Environmental Statement about the Documentation

Downloaded from www.Manualslib.com manuals search engine

IPv6 Basics Dual Stack sFlow

ACL Application for

07-High Smart Link Monitor Link RRPP DLDP

Downloaded from www.Manualslib.com manuals search engine

italic Command arguments are in italic.

[] Items (keywords or arguments) in square brackets [ ] are optional.

Downloaded from www.Manualslib.com manuals search engine

Means a complementary description.

Downloaded from www.Manualslib.com manuals search engine

Table 1-1 Feature list

IPv6 Basics Dual Stack sFlow

Downloaded from www.Manualslib.com manuals search engine

ACL Application for

07-High Smart Link Monitor Link RRPP DLDP

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

GVRP z GARP/GVRP overview

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Multicast Listener Discovery Snooping (MLD Snooping) is an IPv6

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

High Availability Volume

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

ALG Application Layer Gateway

ASIC Application Specific Integrated Circuit

BDR Backup Designated Router

Downloaded from www.Manualslib.com manuals search engine

BPDU Bridge Protocol Data Unit

CBS Committed Burst Size

CPOS Channelized POS

CST Common Spanning Tree

Downloaded from www.Manualslib.com manuals search engine

DCE Data Circuit-terminal Equipment

DoS Denial of Service

EBS Excess Burst Size

ES-IS End System-Intermediate System

Downloaded from www.Manualslib.com manuals search engine

HSB Hot Standby

HVRP Hierarchy VLAN Register Protocol

IANA Internet Assigned Number Authority