iTN8800 (P100R002) Configuration Guide (Rel - 07)
iTN8800 (P100R002) Configuration Guide (Rel - 07)
com
iTN8800 (P100R002)
Configuration Guide
(Rel_07)
Raisecom Technology Co., Ltd. provides customers with comprehensive technical support and services. For any
assistance, please contact our local office or company headquarters.
Website: http://www.raisecom.com
Tel: 8610-82883305
Fax: 8610-82883056
Email: export@raisecom.com
Address: Raisecom Building, No. 11, East Area, No. 10 Block, East Xibeiwang Road, Haidian District, Beijing,
P.R.China
Postal code: 100094
-----------------------------------------------------------------------------------------------------------------------------------------
Notice
Copyright © 2019
Raisecom
All rights reserved.
No part of this publication may be excerpted, reproduced, translated or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in Writing from Raisecom
Technology Co., Ltd.
Preface
Objectives
This document introduces features and related configurations supported by the iTN8800,
including basic principles and configuration procedures of IP routing, MPLS, MPLS-TP, VPN,
Ethernet, QoS, OAM, and security. In addition, this document provides related configuration
examples. The appendix provides terms, acronyms, and abbreviations involved in this guide.
This document helps you master principles and configurations of the iTN8800 systematically,
as well as networking with the iTN8800.
Versions
The following table lists the product versions related to this document.
Conventions
Symbol conventions
The symbols that may be found in this document are defined as below.
Symbol Description
Indicate a hazard with a medium or low level of risk which, if
not avoided, could result in minor or moderate injury.
Symbol Description
Indicate a tip that may help you solve a problem or save time.
General conventions
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Arial Paragraphs in Warning, Caution, Notes, and Tip are in Arial.
Boldface Names of files, directories, folders, and users are in boldface.
For example, log in as user root.
Italic Book titles are in italics.
Lucida Console Terminal display is in Lucida Console.
Book Antiqua
Heading 1, Heading 2, Heading 3, and Block are in Book
Antiqua.
Command conventions
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in square brackets [ ] are
optional.
{ x | y | ... } Alternative items are grouped in braces and separated by
vertical bars. Only one is selected.
[ x | y | ... ] Optional alternative items are grouped in square brackets and
separated by vertical bars. One or none is selected.
{ x | y | ... } * Alternative items are grouped in braces and separated by
vertical bars. A minimum of one or a maximum of all can be
selected.
[ x | y | ... ] * Optional alternative items are grouped in square brackets and
separated by vertical bars. A minimum of none or a maximum
of all can be selected.
interface/sub-interface
fastethernet: out-of-band network management interface
port-channel: Trunk interface/sub-interface
tdm: TDM interface
NULL: Null0 interface
slot ID, which is an integer and ranges from 1 to 8. The port is the
interface ID, which is an integer and ranges from 1 to 16.
When the interface is a NULL interface. The interface ID is an
integer and is 0.
number parameters indicate the interface type and interface ID. For details about interface
types and interface IDs, see interface type and value range conventions.
Actual screen outputs are shown as below.
Change history
Updates between document versions are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Issue 07 (2019-01-10)
Seventh commercial release
Modified the command line for the loopback function.
Modified Y.1546 configurations.
Fixed known bugs.
Issue 06 (2018-02-10)
Sixth commercial release
Added configurations of the multi-interface U0.
Added configurations of hierarchical bandwidths.
Added configurations of remote zero-configuration dual-uplink NAT.
Upgraded configurations of interface management.
Added configurations of Proxy ARP.
Added configurations of MPLS load balancing.
Upgraded configurations of MPLS VPN.
Issue 05 (2017-03-30)
Fifth commercial release
Added LDP MD5.
Added support for EBGP by L3VPN PE-CE.
Added terminal virtualization.
Issue 04 (2016-09-30)
Fourth commercial release
Added commands for configuring IP equal-cost multi-path load balancing.
Added commands for configuring RIP.
Added commands for configuring IPv6 ACL.
Added commands for configuring IPv6 ISIS.
Added commands for configuring H-QoS.
Added commands for maximizing the OSPF LSA metric value.
Added commands for configuring OSPFv3.
Added commands for configuring IPv6 address and IPv6 neighbor discovery.
Added commands for configuring ARP active acknowledgement and updated the chapter
Configuring ARP.
Added commands for configuring MLD.
Added commands for configuring PIM.
Raisecom Proprietary and Confidential
v
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide Preface
Issue 03 (2015-08-20)
Third commercial release
Added commands for overall upgrade.
Added commands for suppressing MAC address drifting.
Added the function of supporting LAG mirroring.
Added the function of supporting LAG loopback.
Added zero-configuration on the OSPF DCN remote device.
Upgraded commands for configuring interfaces.
Added the commands for interface backup.
Added commands for configuring ISIS.
Added commands for configuring VLAN mapping.
Added commands for configuring URPF.
Added commands for configuring L2CP.
Added commands for configuring the SDH interface.
Added commands for configuring clock synchronization.
Added contents in basic configuration, memory monitoring, CPU monitoring, device
monitoring, fault detection, optical module DDM, and other chapters.
Issue 02 (2015-03-20)
Second commercial release
Added the following features: DHCP, MPLS-TP OAM, SLA, TDMoP, VRRP, loop
detection, Loopback, link aggregation, mLACP, ELPS, ERPS, MPLS linear protection,
ICCP, and HA.
Raisecom Proprietary and Confidential
vi
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide Preface
Issue 01 (2014-01-20)
Initial commercial release
Contents
4 Zero-configuration ...................................................................................................................... 64
4.1 Configuring CO zero-configuration ............................................................................................................... 64
4.1.1 Preparing for configurations ................................................................................................................. 64
4.1.2 Configuring zero-configuration Server based on extended OAM......................................................... 65
4.1.3 Configuring zero-configuration Server based on DHCP....................................................................... 67
4.1.4 Configuring zero-configuration based on DCN NMS self-connection ................................................. 72
4.1.5 Checking configurations ....................................................................................................................... 74
4.2 Configuration examples ................................................................................................................................. 74
4.2.1 Example for configuring remote zero-configuration in private network under IP RAN CO device ..... 74
5 Ethernet ......................................................................................................................................... 78
5.1 Configuring VLAN ........................................................................................................................................ 78
5.1.1 Preparing for configurations ................................................................................................................. 78
5.1.2 Configuring VLAN properties .............................................................................................................. 79
5.1.3 Configuring VLANs based on Access interface .................................................................................... 79
5.1.4 Configuring VLANs based on Trunk interface ..................................................................................... 80
5.1.5 Checking configurations ....................................................................................................................... 80
5.2 Configuring MAC address table..................................................................................................................... 81
5.2.1 Preparing for configurations ................................................................................................................. 81
5.2.2 Configuring static MAC address table .................................................................................................. 81
5.2.3 Configuring dynamic MAC address table ............................................................................................. 81
5.2.4 Configuring blackhole MAC address .................................................................................................... 82
5.2.5 Checking configurations ....................................................................................................................... 82
5.2.6 Maintenance .......................................................................................................................................... 83
5.3 Configuring QinQ .......................................................................................................................................... 83
5.3.1 Preparing for configurations ................................................................................................................. 83
5.3.2 Configuring basic QinQ ........................................................................................................................ 84
5.3.3 Configuring QinQ VLAN mapping ...................................................................................................... 84
5.3.4 Checking configurations ....................................................................................................................... 85
5.4 Configuring LLDP ......................................................................................................................................... 85
5.4.1 Preparing for configurations ................................................................................................................. 85
5.4.2 Enabling global LLDP .......................................................................................................................... 85
5.4.3 Enabling interface LLDP ...................................................................................................................... 86
5.4.4 Configuring LLDP basic functions ....................................................................................................... 86
5.4.5 Configuring LLDP Trap ........................................................................................................................ 86
5.4.6 Checking configurations ....................................................................................................................... 87
5.5 Configuring loop detection ............................................................................................................................. 87
5.5.1 Preparing for configurations ................................................................................................................. 87
5.5.2 Configuring loop detection ................................................................................................................... 87
14 Security...................................................................................................................................... 342
14.1 Configuring storm control .......................................................................................................................... 342
14.1.1 Preparing for configurations ............................................................................................................. 342
14.1.2 Configuring storm control ................................................................................................................. 343
14.1.3 Checking configurations ................................................................................................................... 343
14.2 Configuring CPU protection ...................................................................................................................... 343
14.2.1 Preparing for configurations ............................................................................................................. 343
14.2.2 Configuring global CPU CAR .......................................................................................................... 344
14.2.3 Configuring interface CPU CAR ...................................................................................................... 344
14.2.4 Checking configurations ................................................................................................................... 344
14.3 Configuring memory monitoring ............................................................................................................... 345
14.3.1 Preparing for configurations ............................................................................................................. 345
14.3.2 Configuring memory monitoring ...................................................................................................... 345
14.3.3 Checking configurations ................................................................................................................... 345
14.4 Configuring CPU monitoring ..................................................................................................................... 345
14.4.1 Preparing for configurations ............................................................................................................. 345
14.4.2 Viewing CPU monitoring information .............................................................................................. 346
14.4.3 Configuring CPU monitoring alarm .................................................................................................. 346
14.4.4 Checking configruations ................................................................................................................... 346
15.10.4 (Optional) configuring ping function of VRRP virtual IP address .................................................. 384
15.10.5 Configuring VRRP monitoring interface ........................................................................................ 384
15.10.6 Configuring VRRP fast switching ................................................................................................... 384
15.10.7 Checking configurations ................................................................................................................. 385
15.11 Configuring PRBS test ............................................................................................................................. 385
15.11.1 Preparing for configurations ............................................................................................................ 385
15.11.2 Configuring PRBS .......................................................................................................................... 385
15.11.3 Checking configurations ................................................................................................................. 386
15.12 Maintenance ............................................................................................................................................. 386
15.13 Configuration examples ........................................................................................................................... 386
15.13.1 Example for configuring manual link aggregation .......................................................................... 386
15.13.2 Example for configuring static LACP link aggregation .................................................................. 389
15.13.3 Example for configuring PW dual-homed protection switching ..................................................... 390
15.13.4 Examples for configuring PW redundancy protection .................................................................... 397
Figures
Figure 4-1 Networking with remote zero-configuration in the private network under the IP RAN CO device ... 75
Figure 10-1 Configuring static bidirectional LSP without IP capability ............................................................ 182
Figure 11-2 Configuring static Tunnel to carry static VPWS services ............................................................... 236
Figure 11-3 Configuring RSVP-TE-based dynamic Tunnel to carry dynamic VPWS services ......................... 238
Figure 11-4 Configuring MPLS L2VPN services .............................................................................................. 241
Figure 12-1 Configuring rate limiting based on traffic policy ........................................................................... 282
Figure 12-2 Configuring queue scheduling and congestion avoidance .............................................................. 285
Figure 13-1 BFD for sub-interface directly-connected single hop detection ..................................................... 328
1 Basic configurations
This chapter describes basic information and configuration procedures of the iTN8800, as
well as related configuration examples, including following sections:
CLI
Accessing device
Backup and upgrade
Device management
Configuring RMON
Configuration examples
1.1 CLI
1.1.1 Overview
The Command Line Interface (CLI) is a medium for you to communicate with the iTN8800.
You can configure, monitor, and manage the iTN8800 through the CLI.
You can log in to the iTN8800 through the terminal equipment or through a computer that
runs the terminal emulation program. Enter commands at the system prompt.
The CLI supports the following features:
Configure the iTN8800 locally through the Console interface.
Configure the iTN8800 locally or remotely through Telnet/Secure Shell v2 (SSHv2).
Commands are classified into different levels. You can execute the commands that
correspond to your level only.
The commands available to you depend on which mode you are currently in.
Shortcut keys can be used to execute commands.
Check or execute a historical command by checking command history. The last 20
historical commands can be saved on the iTN8800.
Enter a question mark (?) at the system prompt to obtain online help.
The iTN8800 supports multiple intelligent analysis methods, such as fuzzy match and
context association.
1.1.2 Levels
The iTN8800 classifies commands into 16 levels in a descending order:
0–4: checking level. You can execute basic commands, such as clear and history, for
clearing system information and showing command history.
5–10: monitoring level. You can execute commands, such as show, for system
maintenance.
11–14: configuration level. You can execute commands for configuring services, such as
Virtual Local Area Network (VLAN) and Internet Protocol (IP) routing.
15: management level. You can execute commands for system running.
1.1.3 Modes
The command mode is an environment where a command is executed. A command can be
executed in one or multiple certain modes. The commands available to you depend on which
mode you are currently in.
After connecting the iTN8800, if the iTN8800 adopts default configurations, a Login prompt
will be displayed. Enter the user name (raisecom) and password (raisecom) to enter the user
EXEC mode, where the following command is displayed:
Raisecom>
Enter the enable command and press Enter. Then enter the correct password, and press Enter
to enter privileged EXEC mode. The default password is raisecom.
Raisecom>enable
Password:
Raisecom#
In privileged EXEC mode, enter the config command to enter global configuration mode.
Raisecom#config
Raisecom(config)#
The CLI prompts Raisecom is a default host name. You can modify it by executing
the hostname string command in privileged EXEC mode.
Commands executed in global configuration mode can also be executed in other
modes. The functions vary on command modes.
You can enter the exit or quit command to return to the upper command mode.
However, in privileged EXEC mode, you need to execute the disable command to
return to user EXEC mode. In address family configuration mode, you need to
execute the exit-address-family command to return to BGP configuration mode.
You can enter the end command to return to privileged EXEC mode from any
modes but user EXEC mode and privileged EXEC mode.
Command modes supported by the iTN8800 are listed in the following table.
Complete help
You can acquire complete help under following three conditions:
You can enter a question mark (?) at the system prompt to display a list of commands
and brief descriptions available for each command mode.
Raisecom>?
After you enter a keyword, press the Space bar and enter a question mark (?), all
correlated commands and their brief descriptions are displayed if the question mark (?)
matches another keyword.
Raisecom(config)#show ?
After you enter a parameter, press the Space bar and enter a question mark (?),
associated parameters and descriptions of these parameters are displayed if the question
mark (?) matches a parameter.
Raisecom(config)#interface tunnel ?
Incomplete help
You can acquire incomplete help under following three conditions:
After you enter part of a particular character string and a question mark (?), a list of
commands that begin with a particular character string is displayed.
Raisecom(config)#c?
After you enter a command, press the Space, and enter a particular character string and a
question mark (?), a list of commands that begin with a particular character string is
displayed.
Raisecom(config)#show li?
license license
link-aggregation Link aggregation
After you enter a partial command name and press the Tab, the full form of the keyword
is displayed if there is a unique match command. Otherwise, after you press the Tab,
different keywords will be displayed circularly and you can select one as required.
Error messages
The following table lists error messages that you may encounter while configure the iTN8800
on the CLI.
The Console interface of the iTN8800 is a Universal Serial Bus (USB) A-shaped
female interface, which is translated into a Universal Asynchronous
Receiver/Transmitter (UART) in the device.
The Console interface is used as an interface for the iTN8800 being connected to a PC that
runs the terminal emulation program. You can configure and manage the iTN8800 through
this interface. This management method does not involve network communication.
You must log in to the iTN8800 through the Console interface under the following 2
conditions:
The iTN8800 is powered on for the first time.
You cannot log in to the iTN8800 through Telnet.
To log in to the iTN8800 through the Console interface, follow these steps:
Before logging in to the iTN8800 through the USB interface, install the driver for
translating the USB interface into the UART interface to the PC.
Step 1 Use the configuration cable with dual USB male interfaces to connect the Console interface of
the iTN8800 with the USB interface of the PC.
Step 2 Run the terminal emulation program on the PC, such as Hyper Terminal on Microsoft
Windows XP. Enter the connection name at the Connection Description dialog box and then
click OK.
Step 3 Select COM N (N refers to the COM interface ID into which the USB interface is translated.)
at the Connect To dialog box and then click OK.
Step 4 Configure parameters as shown in Figure 1-1 and then click OK
Step 5 Enter the configuration interface and then enter the user name and password to log in to the
iTN8800. By default, both the user name and password are set to raisecom.
Before logging in to the iTN8800 through Telnet, you must log in to the iTN8800
through the Console interface and configure the IP address of the SNMP interface.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#interface fastethernet Enter SNMP interface configuration mode.
1/0/1
3 Raisecom(config-fastethernet1/0/1)#ip Configure the IP address of the SNMP
address ip-address [ ip-mask ] interface and return to global configuration
Raisecom(config-fastethernet1/0/1)#exit mode.
By default, it is 192.168.4.28.
4 Raisecom(config)#telnet-server accept (Optional) configure the interface that
interface-type interface-list supports Telnet.
5 Raisecom(config)#telnet-server close (Optional) close the specified Telnet session.
terminal-telnet session-number
6 Raisecom(config)#telnet-server max- (Optional) configure the maximum number of
session session-number Telnet sessions supported by the iTN8800.
By default, it is 5.
7 Raisecom(config)#telnet-server listen vrf Configure VRF monitored by Telnet to
vpn-instance-name manage VRFs.
Telnet Client: after connecting the iTN8800 through the terminal emulation program
running on the PC, you can log in to another device by entering the telnet command and
then configure and manage the device. As shown in Figure 1-3, iTN A works as Telnet
Server and Telnet Client.
System file
System files refer to the software and files required for operating the iTN8800, including the
BootROM file, system configuration file, system startup file and FPGA file. These files are
saved to the memory of the iTN8800.
File management includes backup, update, load and deletion of files.
PAF file
PAF is used to control functions and specifications of the device. The PAF file defines all
specification parameters supported by the device, such as, local and remote zero-configuration
mode. It is able to confirm specifications supported by the device according to the parameter
range. The following examples show several important parameter ranges:
ZERO_CONFIG_MODE_CLIENT: the value 0 indicates disabling remote zero-
configuration while the value 1 indicates enabling remote zero-configuration.
ZERO_CONFIG_MODE_CLIENT: if ZERO_CONFIG_MODE_CLIENT=1, the value
0 indicates disabling China Telecom zero-configuration while the value 1 indicates
enabling China Telecom zero-configuration. The zero-configuration scheme for China
Telecom is to request the IP address on the first uplink interface.
ZERO_CONFIG_MANAGE_VLAN: the value 0 indicates that the VLAN management
is not configured. All VLANs are covered when the IP address is automatically obtained.
After configuring parameters is complete, you could download parameters to the device
through the download command and reboot the iTN8800 through the reboot command. Then
the iTN8800 will take effect.
Other functions of the PAF file are as below:
Support customizing the default IP address of the NMS interface.
Support the naming convention of the product version, such as "product version.paf" for
the PAF file.
Backup
Backup means saving system files by copying them from the device memory and save them
into the server memory to recover files if the iTN8800 fails. By doing so, the iTN8800 will
run normally as before. The pervious system file should be restored under the following
conditions:
System files are lost or damaged due to the device fault.
Raisecom Proprietary and Confidential
15
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 1 Basic configurations
Upgrade
After features are added or known bugs are fixed, a new software version will be released.
Then you can upgrade the software.
The iTN8800 supports 2 upgrade modes:
FTP upgrade in BootROM mode
FTP/TFTP upgrade in system configuration mode
The iTN8800 complies with FTP/TFTP based on IPv4.
Step Operation
1 Log in to the iTN8800 with the identity of an administrator and then enter privileged EXEC mode.
Restart the iTN8800 through the reboot command.
Raisecom#reboot
Please input 'yes' to confirm:yes
Rebooting ...
begin...
Step Operation
2 When it prompts "Press space into Bootstrap menu...", press Space bar to enter the [raisecom] page.
Enter "?" to show the command lists.
[Raisecom]:?
? print this list
h print this list
b boot system
uf filename upload file
ls list files
R filename remove file
i modify network manage port ip address
r reboot system
ss switch system
u update system
ub update bootrom
ul update license
Ensure that the accuracy of the entered file name. The length of the file name should be
not more than 80 bytes.
Step Operation
4 Enter "ss" to select the system startup file which is to be loaded by the device during next startup.
[Raisecom]:ss
Current boot info:
primary:core/iTN8800_package.z
current:core/iTN8800_package.z
Index Partition Free Size(byte)
--------------------------------------------------
1 core/ 36143104
Please select a partition: 1
Index Filename system-version
---------------------------------------------------------------------------
1 iTN8800_package.z v1.0.0_20140619
Please select a image for next booting: 1
Save boot info...successful!
5 Enter "r" to rapidly execute the bootstrap file. The iTN8800 will automatically restart and load the
downloaded system startup file,
When upgrading files in BootROM file, ensure that the iTN8800-II-NXU is inserted
into slot 1.
Working mechanism
SNMP is divided into two parts: Agent and NMS. The Agent is someone being managed in
the SNMP network while the NMS is the manager for the SNMP network. The Agent and
NMS communicate with each other by sending SNMP packets through UDP.
The iTN8800 communicates with the NView NNM system through SNMP packets. Raisecom
Nview NNM system can provide friendly Human Machine Interface (HMI) to facilitate
network management. The following functions can be implemented through it:
Send request packets to the iTN8800.
Receive reply packets and Trap packets from the iTN8800, and show result.
The Agent is a program installed in the iTN8800, implementing the following functions:
Receive/reply request packets from Nview NNM system
Read/write packets and generate response packets according to the packets type, then
return the result to Nview NNM system
Define trigger condition according to protocol modules, enter/exit from system or reboot
device when conditions are satisfied; the replying module sends Trap packets to NView NNM
system through Agent to report current status of device.
An Agent can be configured with several versions concurrently, and different versions
communicate with different NMSs. However, the SNMP version of the NMS must be
consistent with that of the connected agent so that they can intercommunicate
properly.
Protocol versions
Till now, SNMP has three versions: v1, v2c, and v3, described as below.
SNMPv1 uses community name authentication mechanism. The community name, a
string defined by an agent, acts like a password. The NMS can visit the agent only by
specifying its community name correctly. If the community name carried in a SNMP
packet is not authenticated by the iTN8800, the packet will be dropped.
Compatible with SNMPv1, SNMPv2c also uses community name authentication
mechanism. SNMPv2c supports more operation types, data types, and errored codes, and
thus better identifying errors.
SNMPv3 uses User-based Security Model (USM) and View-based Access Control Model
(VACM) security mechanism. You can configure whether USM authentication is enabled
MIB
Management Information Base (MIB) is the collection of all objects managed by NMS. It
defines attributes for the managed objects:
Name
Access right
Data type
The device-related statistic contents can be reached by accessing data items. Each proxy has
its own MIB. MIB can be taken as an interface between NMS and Agent, through which NMS
can read/write every managed object in Agent to manage and monitor the iTN8800.
MIB stores information in a tree structure, with unnamed root on the top. Nodes of the tree are
the managed objects, which take a unique path starting from root (OID) for identification.
SNMP protocol packets can access network devices by checking the nodes in MIB tree
directory.
The iTN8800 supports standard MIB and Raisecom-customized MIB.
Scenario
To log in to the iTN8800 through the NMS, you should first configure SNMP basic functions.
Prerequisite
Configure the IP addresses on the SNMP interface.
Configure static router to link iTN8800 and NMS through the router.
Configuration steps in SNMP v1, v2c and v3 are the same except the configuration of
the target host. Choose it as required.
A Trap is used by the iTN8800 to send unrequested information to the NView NNM system
automatically, which is used to report some critical events.
Finish the following tasks before configuring Trap:
Configure SNMP basic functions. SNMP v3 requires configuring the user name and
SNMP view.
Configure routing protocols, and ensure routing between the iTN8800 and the NView
NNM system is available.
Raisecom Proprietary and Confidential
22
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 1 Basic configurations
To avoid multiple devices to concurrently send KeepAlive Trap in the same period
and overburdened network management, configure the KeepAlive Trap packets to be
sent within a random period of "sending period+5s".
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#snmp-server Enable sending KeepAlive Trap packets.
keepalive-trap enable
By default, it is disable to send KeepAlive Trap packets.
3 Raisecom(config)#snmp-server (Optional) configure the period for sending KeepAlive
keepalive-trap interval period Trap packets.
By default, the period for sending KeepAlive Trap
packets is 300s.
4 Raisecom(config)#snmp-server (Optional) suspend the sending of KeepAlive Trap
keepalive-trap pause packets.
Scenario
RMON helps monitor and gather statistics about network traffics.
Raisecom Proprietary and Confidential
24
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 1 Basic configurations
Compared with SNMP, RMON is a more high-efficient monitoring method. After you specify
an alarm threshold, the iTN8800 actively sends alarms when the threshold is exceeded
without obtaining variable information. This helps reduce traffic of Central Office (CO) and
managed devices and facilitates network management.
Prerequisite
The route between the iTN8800 and the NView NNM system is reachable.
Raisecom#config
Raisecom(config)#exit
Raisecom#download system ftp 192.168.27.72 111111 111111 iTN8800-NXU.z
Step 4 Wait for downloading the file. The file is downloaded successfully when the prompt "Set
successfully" is displayed.
Waiting...Start
OK
OK
Downloading 12204KK
Set successfully
Step 5 Configure the file to the system file used for rebooting the device at the next time.
Raisecom#reboot
Please input 'yes' to confirm:yes
When upgrading files in BootROM file, ensure the iTN8800-II-NXU is inserted into
slot 1.
Step 1 Power on or reboot the device.
Raisecom#reboot
Step 2 Press Space to enter BootROM configuration mode when "Press space into Bootrom menu..."
appears on the screen.
Step 3 Input "i" to configure the IP address of the device. Ensure that the IP address is in the same
network segment with the IP address of the PC.
[Raisecom]:i
[Raisecom]:u
Step 6 Input "2" to select transmitting the file through FTP, that is, transmitting the file through the
network. Compared with the mode for transmitting the file through the serial interface, this
mode provides a greater speed.
-----------------------------------
- 1. | serial -
-----------------------------------
- 2. | network -
-----------------------------------
Step 8 Input the FTP user name, password, and file name.
usr:111111
passwd:111111
filename:iTN8800-NXU.z
Step 10 Wait for downloading the file. The file is downloaded successfully when the prompt of
success is displayed.
[Raisecom]:r
2 System management
For example, if DST starts from 02:00 a.m. second Monday of April to 02:00 a.m.
second Monday of September, the clock is moved ahead 60 minutes. Thus, the
period between 02:00 and 03:00 second Monday of April does not exist.
Configuring time during this period will fail.
DST in the Southern Hemisphere is opposite to that in the Northern Hemisphere.
It is from September this year to April next year. If the starting month is later than
the ending month, the system judges that it is located in the Southern Hemisphere.
2.4.5 Maintenance
No. Command Description
1 Raisecom(config)#clear logging buffer Clear contents from the log buffer.
System files
System files are the software/files required for running, including the system Bootrom file,
system configuration file, system startup file, and FPGA file. In general, these files are saved
to the memory of the device.
File management refers to backing up, upgrading, loading, and deleting system files.
Alarm classification
There are 3 kinds of alarms according to properties of an alarm:
Fault alarm: alarms generated because of hardware failure or anomaly of important
functions, such as port Down alarm
Recovery alarm: alarms generated when device failure or abnormal function returns to
normal, such as port Up alarm;
Event alarm: prompted alarms or alarms that are generated because the fault alarm and
recovery alarm cannot be related, such as alarms generated because of failing to Ping.
Alarms are divided into 4 types according to functions:
Service quality alarm: alarms caused by service quality degradation, including
congestion, performance decline, high resource utilization rate, and the bandwidth
reducing
Processing error alarm: alarms caused by software or processing errors, including
software errors, memory overflow, version mismatching, and abnormal program aborts
Environmental alarm: alarms caused by equipment location-related problems, including
the temperature, humidity, ventilation. and other abnormal working conditions
Device alarm: alarms caused by failure of physical resources, including the power supply,
fan, processor, clock, input/output interface, and other hardware.
Raisecom Proprietary and Confidential
37
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 2 System management
Alarm output
There are 2 alarm output modes:
Alarm buffer: alarms are recorded in tabular form, including the current alarm table and
history alarm table.
– Current alarm table: records alarms which are not cleared or restored.
– History alarm table: consists of restored alarms and records the cleared and auto-
restored alarms.
Trap: alarms sent to the NView NNM system when the NView NNM system is
configured
Alarms will be broadcasted according to various terminals configured on the iTN8800,
including CLI terminal and NView NNM system.
Related concepts
Related concepts about alarm management are displayed as below:
Alarm inhibition
The iTN8800 only records root-cause alarms but incidental alarms when enabling alarm
inhibition. For example, the generation of alarm A will inevitably produce alarm B, then
alarm B is inhibited and does not appear in the alarm buffer when enabling alarm inhibition.
By enabling alarm inhibition, the iTN8800 can effectively reduce the number of alarms.
The root-cause alarm and all other incidental alarms will be recorded on the iTN8800 when
alarm inhibition is disabled.
Alarm auto-report
Auto-report refers that an alarm will be reported to the NView NNM system automatically
with its generation and the NView NNM system does not need to query or synchronize alarms
actively.
You can set auto-report to some alarm, some alarm source, or the specified alarm from
specified alarm source.
The alarm source refers to an entity that generates related alarms, such as interfaces,
devices, or cards.
Alarm monitoring
Alarm monitoring is used to process alarms generated by modules:
– When alarm monitoring is enabled, the alarm module will receive alarms generated
by modules, and process them according to configurations of the alarm module, such
as recording alarm in the alarm buffer, etc.
– When alarm monitoring is disabled, the alarm module will discard alarms generated
by modules without follow-up treatment. In addition, alarms will not be recorded on
the iTN8800.
You can perform alarm monitoring on some alarm, alarm source, or specified alarm from
specified alarm source.
Alarm inverse
Alarm inverse (taking alarms of the interface for examples) refers that the reported alarm
status of the interface is opposite to the actual alarm status. The interface will not report an
alarm if it is unused but it will report alarms if it is used. If the interface returns to the unused
status, the reported alarm will be cleared. There are 3 alarm inverse modes available:
– Non- inverse mode: alarms are reported normally
– Manual inverse mode: in this mode, whatever the current alarm status of the interface
is, the reported alarm status of the interface is changed to the one opposite to the
actual alarm status. It means that the interface reports the related recovery alarm if
there is an alarm and reports an alarm if there is no alarm.
– Auto inverse mode: in this mode, if there is no alarm to be inversed, operations are
configured successfully but not take effect. If there is an alarm to be inversed,
operations are configured successfully. The related recovery alarm is reported and the
interface will enter the inverse mode, which means status of all reported alarms is
opposite to the real one. After the alarm is completed, the interface enters the non-
inverse mode automatically and reports alarms properly.
Alarm delay
Alarm delay refers that the device will record alarms and report them to the NView NNM
system after a delay but not immediately when alarms generate. Delay for recording and
reporting alarms are identical.
By default, an alarm is reported 5s later after it is generated and an alarm is cleared 5s later
after it is finished.
Alarm storage mode
Alarm storage mode refers to how to record new generated alarms when the alarm buffer is
full. There are two ways:
− stop: stop mode, when the alarm buffer is full, new generated alarms will be
discarded without recording.
− loop: loop mode, when the alarm buffer is full, the new generated alarms will replace
old alarm information and take rolling records.
For the iTN8800, the current alarm table can record up to 1000 alarms and the historical alarm
table can record up to 500 alarms. Use the configured alarm storage mode to deal with newly-
generated alarms when the alarm table is full.
Alarm clearance
Clear the current alarm, which means deleting current alarms from the current alarm table.
The cleared alarms will be saved to the historical alarm table.
Viewing alarms
The administrator can view alarms and monitor alarms directly on the iTN8800. If the
iTN8800 is configured with the NView NNM system, the administrator can monitor alarms
on the NView NNM system.
reduce the number of alarms. The root-cause alarm and all other incidental alarms will be
recorded on the iTN8800 when alarm inhibition is disabled.
information sent by the device to the NView NNM system. Trap is used to report some
emergent and critical events (for example, the managed device is restarted).
2.6.9 Maintenance
No. Command Description
1 Raisecom(config)#alarm clear interface-type interface- Clear specified alarms.
number [ module_name [ group-name ] ]
Raisecom(config)#alarm clear index index
The iTN8800 supports realizing task scheduling by combining the program list to commands.
You just need to specify the start time of the task, period, and end time in the program list, and
then bind the program list with commands to implement periodical execution of commands.
2.8.2 Ping
No. Command Description
1 Raisecom#ping ip-address [ count Check connectivity of the IPv4 network through the
count ] [ size size ] [ waittime ping command.
period ] [ source ip-address ]
Raisecom#ping ipv6 ipv6-address
[ count count ] [ size size ]
Check the connectivity of the IPv6 network through
[ waittime time ] [ interface
the ping command.
interface-type interface-number ]
[ source ipv6-address ]
No other operations can be done during executing the ping command. You have to
wait till the end of the process or forcedly interrupt it by pressing Ctrl+B.
2.8.3 Traceroute
Before using this function, you should configure the IP address and default gateway.
Scenario
Banner is a prompt displayed when you log in to or exit the iTN8800, such as the precautions
or disclaimer.
You can configure the Banner of the iTN8800 as required. In addition, the iTN8800 provides
the Banner switch. After Banner display is enabled, the configured Banner information
appears when you log in to or exit the iTN8800.
After configuring Banner, you should use the write command to save configurations.
Otherwise, Banner information will be lost when the iTN8800 is restarted.
Prerequisite
N/A
Scenario
RCLink, a protocol developed by Raisecom, is used to manage remote transceivers. As shown
in Figure 2-1, the iTN8800 is connected to the remote transceiver RC512-FE (B) through the
iTN8800-RF8. RCLink works between the CO device and remote device to implement remote
configuration and management, including configuring parameters of the optical/electrical
interface, Maximum Transmission Unit (MTU), flow control, device restarting, link-state
tracking, and showing device information. RCLink supports the following transceivers:
Raisecom Proprietary and Confidential
46
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 2 System management
Prerequisite
The iTN8800-RF8 is in position.
Scenario
The carrier adopts a third-party integrated NMS. Therefore, the network elements in IP RAN
must comply with the related requirements of the carrier's NMS auto-connection protocol to
implement the plug-and-play and related service management through the third-party NMS.
As a U device, the iTN8800 meets the requirements of the carrier's NMS auto-connection
protocol and can be managed by a third-party NMS upon being connected.
The iTN152 connected upstream to the iTN8800 is a newly developed U0 device by
Raisecom. It can be used for accessing user services on the carrier's network. However, the
U0 devices are IP-free, OSPF-free, and LLDP-free. They are simple devices that do not
support the vast majority of MIB nodes and cannot be managed by a third-party NMS. You
can configure terminal virtualization on the U device so that the U0 device can be managed
by the third-party NMS upon being connected.
Raisecom U0 devices support separate service configuration and device installation. If you
want to unbind the U0 device, you need to log in to the third-party NMS to configure service
limits.
Prerequisite
Establish an extended OAM channel between the U device and U0 device.
Step 1 When U0 device is not connected to the U device, you need to configure the U0 device to
make it online on the third-party integrated NMS and save the configurations sent by the
third-party NMS.
Step 2 After the U0 device established extended OAM connections with the U device, the U device
will automatically send the saved configurations to the U0 device.
After extended OAM is enabled on the U device and loopback is enabled among
DCN sub-interfaces on the U device, the system will automatically performs terminal
virtualization of the U0 device. When the default condition is changed or the user has
special requirements, it supports configuring features during the terminal
virtualization process.
Networking requirements
As shown in Figure 2-2, you can configure hardware monitoring to monitor the temperature
of the iTN device. When the temperature exceeds the threshold, the alarm Trap will be sent to
the NView NNM system to inform the network administrator to take actions in case of failure.
Configuration steps
Step 1 Configure the IP address of the iTN device.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/1/1
Raisecom(config-gigaethernet 1/1/1)#ip address 20.0.0.6 255.255.255.0
Raisecom(config-gigaethernet 1/1/1)#exit
Checking results
Use the show snmp config command on the iTN device to show configurations of Trap
sending.
Use the show snmp host command to show configurations of the Trap target host.
3 Interface management
Scenario
Optical module DDM provides a method to detect SFP performance parameters. You can
predict the service life of optical module, isolate system fault, and check its compatibility
during installation through analyzing monitoring data.
Prerequisite
N/A
Scenario
Through interface loopback, the network maintenance personnel can detect and analyze faults
of the device and network.
Prerequisite
The interface should be Up.
The first 3 bytes of the destination MAC address cannot be set to 0x0180C2.
The source MAC address cannot be a multicast/broadcast MAC address.
4 Zero-configuration
Scenario
When the CO iTN8800 connects with remote devices, the iTN8800 can discover these
remote devices by using the extended OAM protocol and configure the management IP
address, management VLAN, and default route for them. Therefore, the NView NNM
system can quickly manage remote devices through the public IP address and global
interface ID of the iTN8800 without being configured manually.
When the CO iTN8800 and remote devices are connected directly/indirectly, both the
CO and remote devices can provide zero-configuration through Dynamic Host
Configuration Protocol (DHCP).
Prerequisite
The iTN8800 is a CO device.
The CO zero-configuration server is connected to the NView NNM system and remote
devices properly.
Perform the following operations on the CO device based on extended OAM protocol:
– Create and activate the management VLAN.
– The interface of the remote device used for direct connection is configured to work in
Trunk mode and allows the management VLAN to pass.
– Manually enable the OAM active mode on the interface.
Based on the DHCP, the remote device is connected to the network and is configured to
the zero-configuration client.
– Create and activate the management VLAN.
Configuring NAT
Network Address Translation (NAT) is used to convert the private management IP address of
the remote device to the public IP address. Through zero-configuration, the remote device
obtains a private IP address from the CO device. NAT can be used to translate the private IP
address into the public IP address of the management network and distinguish different
remote devices in a form of public IP address+global interface ID. Network management
information transmitted between remote devices and the NView NNM system is forwarded
through the public IP address. Therefore, you should configure the public IP address and
related management VLAN of the CO device.
Configuring NAT
NAT is used to convert the private management IP address of the remote device to the public
IP address. Through zero-configuration, the remote device obtains a private IP address from
the CO device. NAT can be used to translate the private IP address into the public IP address
of the management network and distinguish different remote devices in a form of public IP
address+global interface ID. Network management information transmitted between remote
devices and the NView NNM system is forwarded through the public IP address. Therefore,
you should configure the public IP address and related management VLAN of the CO device.
address or ACL ID of the two interfaces must be the same. Otherwise, the configuration will
fail.
The two interfaces configured with the Outband function can also borrow the IP addresses of
other Loopback interfaces. For details, see the description in step 7.
The iTN8800 supports saving and synchronizing the lease file automatically, as well
as deleting the lease file.
When changing the CO zero-configuration server, you can upload assigned IP addresses in a
form of lease to the TFTP/FTP server (such as a PC) for backup. After changing the CO
device, you can download the backup lease file to the local device to confirm that these
assigned IP addresses are not lost.
When the Raisecom IP RAN CO device is connected downlink to the private network,
you have to configure the Trap Server on the remote device after the remote device
network management channel is established and use the snmp-server keepalive-
trap enable command to enable the Keepalive to prevent the NAT entries from being
aged.
Networking requirements
As shown in Figure 4-1, as the IP RAN CO device, the iTN8800 is connected downlink to a
private network. The IP address of the NView NNM server and that of the iTN8800 are also
shown. The network management self-connection required through OSPF DCN remote zero-
configuration after the remote device iTN100 is powered on.
Figure 4-1 Networking with remote zero-configuration in the private network under the IP RAN
CO device
Configuration steps
Configure the zero-configuration server iTN8800 as below:
Step 1 Configure the downlink physical interface. Enable DCN.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/1/1
Raisecom(config-gigaethernet1/1/1)# dcn enable
Raisecom(config)#router ospf 32
Raisecom(config-router-ospf)#network 132.4.4.4 0.0.0.0 area 0.0.0.0
Raisecom(config-router-ospf)#capability opaque
Raisecom(config-router-ospf)#capability dcn
Raisecom#config
Raisecom(config)#access-list 2000
Raisecom(config-acl-ipv4-advanced)#rule 10 permit ip any any
Raisecom(config-acl-ipv4-advanced)#exit
Raisecom(config)#class-map c1
Raisecom(config-cmap)#match acl 2000
Raisecom(config-cmap)#exit
Raisecom(config)#policy-map p1
Raisecom(config-pmap)#class-map c1
Raisecom(config-pmap)#forward-to-cpu
Raisecom#config
Raisecom(config)#interface gigaethernet 1/1/1
Raisecom(config-gigaethernet1/1/1)#service-policy ingress p1
Raisecom(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
Raisecom(config-gigaethernet1/1/2)#service-policy ingress p1
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/1
Raisecom(config-gigaethernet1/2/1)#ip address 10.0.0.2 255.0.0.0
Raisecom(config-gigaethernet1/2/1)#nat outbound 2000
The IP address of the SNMP interface on the connected device cannot be in the
segment of the NView NNM server; otherwise, a static IP address should be
configured.
Checking results
Check NE information collected by the iTN8800 and obtain the IP address of the remote
device (the following example shows information about two remote devices of them).
After the CO device is configured, log in to each remote device and configure Trap Server and
Keepalive.
The NView NNM system receives a Trap that the network management channel of the remote
device is established.
The NView NNM system periodically receives the Keepalive messages, and NAT entries of
the CO device keep being updated and will not be aged.
5 Ethernet
Scenario
The main function of VLAN is to carve up logic network segments. There are 2 typical
application modes:
Small LAN: on one Layer 2 device, the LAN is carved up to several VLANs. Hosts that
connect to the device are carved up by VLANs. So hosts in the same VLAN can
communicate, but hosts between different VLANs cannot communicate. For example,
the financial department needs to be separated from other departments and they cannot
access each other. In general, the port connected to the host is in Access mode.
Big LAN or enterprise network: multiple Layer 2 devices connect to multiple hosts and
these devices are concatenated. Packets take VLAN Tag for forwarding. Ports of multiple
devices, which have identical VLAN, can communicate, but hosts between different
VLANs cannot communicate. This mode is used for enterprises that have many people
and need a lot of hosts, and the people and hosts are in the same department but different
positions. Hosts in one department can access each other, so you have to partition
VLANs on multiple devices. Layer-3 devices like a router are required if you want to
communicate among different VLANs. The concatenated ports among devices are in
Trunk mode.
Prerequisite
N/A
VLANs that are created by using the vlan vlan-id command are in active status.
All configurations of a VLAN cannot take effect until the VLAN is activated.
6 Raisecom(config-port)#switchport access Configure the VLAN list available for the Access
egress-allowed vlan { all | vlan-list } interface.
[ confirm ]
Scenario
When configuring the MAC address table, you can configure static MAC addresses for fixed
and important devices to prevent illegal users from accessing the network from other locations.
To avoid saving too many dynamic MAC addresses to the MAC address table and exhausting
resources of the MAC address table, you need to configure the aging time of dynamic MAC
addresses to ensure upgrading dynamic MAC addresses effectively.
Prerequisite
N/A
Raisecom(config)#mac-address static
unicast mac-address vsi vsi-name
It must be a unicast MAC address. The
interface-type interface-number local MAC address, multicast address, all-
Raisecom(config)#mac-address static F, and all-0 MAC addresses cannot be set
unicast mac-address vsi vsi-name vc-id to the static MAC address.
vc-id peer ip-address
5.2.6 Maintenance
No. Command Description
1 Raisecom(config)#clear mac-address dynamic Clear MAC
Raisecom(config)#clear mac-address dynamic [ vlan vlan-id ] addresses.
[ interface-type interface-number ]
Raisecom(config)#clear mac-address dynamic vsi vsi-name
[ interface-type interface-number ]
Raisecom(config)#clear mac-address dynamic vsi vsi-name [ vc-id
vc-id peer ip-address ]
Raisecom(config)#clear mac-address dynamic mac-address [ vlan
vlan-id | vsi vsi-name ]
Scenario
With basic QinQ, you can add outer VLAN Tag and freely plan your own private VLAN ID.
Therefore, the data between devices on both ends of the Internet Service Provider (ISP)
network can be transparently transmitted, without conflicting with the VLAN ID in the ISP
network.
QinQ-based VLAN mapping can meet the following conditions:
Prerequisite
Connect interfaces and configure physical parameters of interfaces. Make the physical
layer Up.
Create a VLAN.
Scenario
When you obtain connection information between devices through the NView NNM system
for topology discovery, you need to enable LLDP on the iTN8800. Therefore, the iTN8800
can notify its information to the neighbours mutually, and store neighbour information to
facilitate the NView NNM system querying information.
Prerequisite
N/A
After global LLDP is disabled, you cannot re-enable it immediately. Global LLDP
cannot be enabled unless the restart timer times out.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#lldp enable Enable global LLDP.
By default, it is disabled.
When configuring the delivery delay timer and the delivery period timer, set the value
of the delivery delay timer to be smaller than or equal to one quarter of the value of
the delivery period timer.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#lldp message- (Optional) configure the delivery period timer of the
transmission interval second LLDP packet.
By default, it is 30s.
3 Raisecom(config)#lldp message- (Optional) configure the delivery delay timer of the
transmission delay second LLDP packet.
By default, it is 2s.
4 Raisecom(config)#lldp message- (Optional) configure the aging coefficient of the
transmission hold-multiplier LLDP packet.
coefficient
By default, it is 4.
5 Raisecom(config)#lldp restart-delay (Optional) configure the restart timer. After global
second LLDP is disabled, it cannot be enabled unless the
restart timer times out.
By default, it is 2s.
After enabled with LLDP Trap, the iTN8800 will send Traps after detecting aged
neighbors, newly-added neighbors, and changed neighbor information.
Scenario
In the network, hosts or Layer 2 devices connected to access devices may form a loopback
intentionally or involuntary. Enable loop detection on downlink interfaces of all access
devices to avoid the network congestion generated by unlimited copies of data traffic. Once a
loop is detected on a port, the interface will be blocked.
Prerequisite
Configure physical parameters on an interface and make the physical layer Up.
Loop detection and STP are mutually exclusive. They cannot be enabled
simultaneously.
For directly connected devices, you cannot enable loop detection on both ends
simultaneously. Otherwise, interfaces of these 2 devices are blocked.
5.5.4 Maintenance
Command Description
Raisecom(config)#clear loopback-detection statistic Clear statistics of loop detection.
[ interface-type interface-list ]
Scenario
You can configure the mode for process processing Layer 2 control packets of the customer
network on the access device within MAN according to the services provided by carriers. This
configuration is done on the network-side interface of the customer.
Prerequisite
N/A
6 Clock synchronization
Scenario
In the PTN, to communicate properly, the sender must put the pulse in the specified timeslot
when sending the digital pulse signal and the receiver can extract the pulse from the specified
timeslot. To realize this, you must resolve the synchronization problem.
The Synchronous Ethernet (SyncE) technology can perform clock synchronization in the PTN.
Because it does not support phase synchronization but frequency synchronization only, it is
applied to Base Stations (BSs), fixed network TDM relay, leased clock network relay, and
radio BSs which have no requirement on phase synchronization, such as Global System for
Mobile Communications (GSM) and Wideband Code Division Multiple Access (WCDMA).
The iTN8800 supports automatically selecting the optimum clock source. You just need to
configure clock source properties of SyncE. In addition, the iTN8800 supports manually
selecting the specified clock source.
Prerequisite
N/A
Scenario
The synchronous Ethernet technology supports frequency synchronization only, which fails to
meet the strict requirements of 3G mobile backhaul and power market on the accuracy of
clock synchronization. However, PTP supports both frequency synchronization and phase
synchronization. Therefore, PTP is adopted for time synchronization over the full-mesh
network.
Prerequisite
The iTN8800-TAU is in position.
The 1pps-tod interface is for receiving the GPS time information and transfer the time
information between devices or base stations
6.3 Maintenance
Command Description
Raisecom#ptp statistics clear Clear statistics of PTP packets on all interfaces.
Networking requirements
As shown in Figure 6-1, the Radio Network Controller (RNC) transmits clock signals to iTN
A through the SyncE. iTN A is connected to the carrier's NodeB. Clock signals are transmitted
to the NodeB through the downlink GE interface.
Configuration steps
Configure properties of the clock source.
Configure iTN A.
Raisecom#hostname iTNA
iTNA#config
iTNA(config)#synce enable
iTNA(config)#synce ssm standard
iTNA(config)#synce source interface gigaethernet 1/2/1 priority 1
quality-level 2
iTNA(config)#synce operation-type auto-select
Configure iTN B.
Raisecom#hostname iTNB
iTNB#config
iTNB(config)#synce enable
iTNB(config)#synce ssm standard
iTNB(config)#synce source interface gigaethernet 1/1/1 priority 1 1
iTNB(config)#synce operation-type auto-select
Checking results
Use the show synce command to show configurations of clock synchronization in the SyncE.
iTNA#show synce
Synce : enable
Synce running status(PLL): locked(auto-select)
Current clock source: gigaethernet 1/2/1(Ql:2)
Previous clock source: null(Ql:--)
Revertive mode : enable
Latest switch time : 2000-11-07,02:49:45.083
Holdoff time(ms) : 1800
Wait restore time(min): 5
iTNB#show synce
Synce : enable
Synce running status(PLL): freerun(auto-select)
Current clock source: gigaethernet 1/2/1 (Ql:2)
Previous clock source: null(Ql:--)
Revertive mode : enable
Latest switch time : 2000-11-07,02:49:45.083
Holdoff time(ms) : 1800
Wait restore time(min): 5
Use the show synce ssm command to show SSM status of the SyncE.
7 TDMoP
This chapter describes principles and configuration procedures of Time Division Multiplex
over Packet (TDMoP), including following sections:
Configuring TDM interface
Configuring SDH interface
Configuring Tunnel
Configuring PW
Configuring TDMoP clock
Maintenance
Scenario
The iTN8800 accesses TDM services through the RE16 card. Each interface can be
configured independently. When initiating circuit emulation services, you need to configure
basic properties and related features of TDM interfaces, such as the link type and Rx clock
source of TDM interfaces, and codes of TDM idle timeslots.
Circuit emulation services are encapsulated based on TDM interface type. When a TDM
interface is in framed/multiframed mode, TDM frame structure can be recognized and
structured encapsulation mode is adopted. When a TDM interface is in unframed mode,
unstructured encapsulation mode is adopted.
In structured encapsulation mode, PW can be only related to timeslots that carry services.
Timeslots related to the PW are occupied timeslots and the ones does not carry services are
idle timeslots.
Prerequisite
The RE16 card is inserted into the iTN8800.
Scenario
The front panel of the RS4 card provides 4 SFP interfaces, which can access 4 ways of STM-1
services or 1 way of STM-4 services. The rate of the first SFP interface can be configured to
STM-1 or STM-4 while the rate of other interfaces is fixed to STM-1.
The iTN8800 accesses SDH services through the RS4 card. You can configure the related
parameters, such as error code threshold and overhead byte, as required.
The STM1 interface on the RS4 card has 63 SDH sub-interfaces. The STM4 interface has 252
sub-interfaces, which can map up to 252 ways of E1 services to the SDH. When configuring
TDM emulation services, you can configure the basic attributes of TDM services on the SDH
sub-interfaces, such as TDM service line type and clock recovery.
Prerequisite
The RS4 card is in position.
Scenario
The Tunnel is the tunnel to carry the Pseudo Wire (PW) to traverse the Packet Switching
Network (PSN). Before configuring the PW, you must create the Tunnel.
Prerequisite
N/A
7.4 Configuring PW
7.4.1 Preparing for configurations
Scenario
After being received by the TDM interface, TDM service data flows are encapsulated into PW
packets. PW packets of the same type will form PW service flows and traverse the PSN. After
reaching the other end of the PSN, PW service flows are decapsulated to TDM service flows,
which are forwarded through the TDM interface.
Prerequisite
N/A
Scenario
The TDMoP system supports clock synchronization in nature. The PTN is an STDM-based
best-effort network. It may cause end-to-end delay. TDM services are encapsulated into
Ethernet packets and then are transmitted cross the PTN. This also influences the performance
for de-encapsulating TDM services. However, TDMoP clock recovery technology can reduce
impact caused by PTN delay.
The clock recovery mechanism adopted by the TDMoP system depends on the Rx clock
source of the TDM interface.
Prerequisite
Create a PW.
7.6 Maintenance
Command Description
Raisecom(config-tdm- Configure the loopback mode of TDM interfaces.
port)#loopback
{ internal | By default, there is no loopback on the TDM interface.
external | You can use the no loopback command to configure the TDM interface not to
bidirectional } perform loopback.
8 IP services
Scenario
Configure interface information, such as the IP address and the MTU.
Prerequisite
N/A
8.2.2 PING
Step Command Description
1 Raisecom#ping ip-address [ count count ] (Optional) use the ping command to test
[ size size ] [ waittime period ] [ source- IPv4 network connectivity.
ip ip-address ] [ df-bit ]
The iTN8800 cannot perform other operations in the process of Ping. It can perform
other operations only when Ping is complete or Ping is broken off by pressing Ctrl+C.
8.2.3 Traceroute
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#interface interface-type Enter Layer 3 interface configuration mode.
interface-number
3 Raisecom(config-port)#ip address ip- Configure the IP address of the interface.
address [ ip-mask ]
4 Raisecom(config-port)#exit Exit Layer 3 interface configuration mode and
enter global configuration mode.
5 Raisecom(config)#exit Exit global configuration mode and enter
privileged EXEC mode.
6 Raisecom#traceroute ip-address [ firstttl (Optional) use the traceroute command to
first-ttl ] [ maxttl max-ttl ] [ port test the IPv4 network connectivity and view
port-number ] [ waittime period ] [ count nodes passed by the packet.
times ] [ size size ]
By default, the initial TTL is 1; the maximum
TTL is 30; the interface ID is 33433; the
timeout is 3s; the number of detection packets
is 3.
Scenario
Address Resolution Protocol (ARP) is a protocol used for resolution of IP addresses into
Ethernet MAC addresses (physical addresses).
Prerequisite
Configure the IP address of the interface. For details, see section 8.1 Configuring interface.
Scenario
When the iTN8800 works as the DHCP v4 Relay, the DHCP v4 clients can communicate with
DHCP v4 servers in other network segments through the DHCP v4 Relay to obtain IP
addresses. Therefore, DHCP v4 clients in different network segments can apply for IP
addresses from a DHCP v4 server. This facilitates saving costs and managing all devices
together.
Prerequisite
The iTN8800 is disabled with DHCP v4 Client or DHCP v4 Server.
Before enabling DHCP v4 Relay on the interface, ensure that the Layer 3 interface is
not configured by the portswitch command or is not configured to work in mode l2
mode.
Scenario
When the iTN8800 works as the DHCP v4 server, the DHCP v4 client can obtain the IP
address from the iTN8800.
Prerequisite
The iTN8800 is not enabled with DHCP v4 Client. In addition, the DHCP v4 server works in
common DHCP v4 server mode.
8.6 Maintenance
Command Description
Raisecom(config)#clear arp [ all | vrf vrf-name ] [ ip-address | Clearing ARP
interface interface-type interface-number | [ vid vlan-id ] [ cevid entries.
vlan-id ] ]
Networking requirements
As shown in Figure 8-3, the iTN8800 works as the DHCP v4 Relay with the host name being
set to raisecom. The iTN8800 accesses to the DHCP v4 server and the NView NNM system
through the service interface. The DHCP v4 server assigns an IP address to the iTN8800.
Therefore, the NView NNM system can discover and manage the iTN8800.
Configuration steps
Step 1 Enable interface DHCP.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/4/1
Raisecom(config-gigaethernet1/4/1)#ip dhcp relay
Raisecom(config-gigaethernet1/4/1)#interface gigaethernet 1/1/2
Raisecom(config-gigaethernet1/4/2)#ip dhcp relay
Raisecom(config-gigaethernet1/4/2)#exit
Checking results
Use the show ip dhcp relay command to show DHCP v4 Relay configurations.
Networking requirements
As shown in Figure 8-4, the iTN8800 works as the DHCP v4 Server for assigning IP address
to DHCP v4 clients. Parameters are configured as below:
Lease time: 8 hours
Name of IP address pool: pool
IP address range: 172.31.1.2–172.31.1.100
IP address of the DNS: 172.31.100.1
Configuration steps
Step 1 Create and configure the IP address pool.
Raisecom#config
Raisecom(config)#ip dhcp server pool pool
Raisecom(config-pool)#address 172.31.1.2 172.31.1.100 mask 24
Raisecom(config-pool)#lease expired 480
Raisecom(config-pool)#dns-server 172.31.100.1
Raisecom(config-pool)#exit
Checking results
Use the show ip dhcp server command to show configurations of DHCP v4 Server.
Use the show ip server pool command to show configurations of the IP address pool of the
DHCP v4 server.
9 IP routing
Scenario
The static route has the following advantages:
Consume less time for the CPU to process them.
Facilitate the administrator to learn the route.
Be configured easily.
However, when configuring the static route, you need to consider the whole network. If the
network structure is changed, you need to modify the routing table manually. Once the
network scale is enlarged, it will consume lots of time to configure and maintain the network.
In addition, it may cause more errors.
The default route is a specific static route. It will be used when no matched route is found in
the routing table.
Prerequisite
N/A
If one record is in permit type, all mismatched routes are in deny type by default.
Only matched routes can pass filtering of the IP prefix-list.
If one record is in deny type, all mismatched routes are in deny type by default.
Even matched routes cannot pass filtering of the IP prefix-list. Therefore, you need
to add a permit record after multiple deny records to allow other routes to pass.
If there are multiple records in the IP prefix-list, there must be a record in permit
type.
OSPF runs on L3 interfaces. By default, the interface is in routed mode. If the current
interface is configured to the switch mode, you have to use the no portswitch
command to return the interface to the routed mode.
If you manually configure the router-id parameter through the optional parameters
in the router ospf process-id [ router-id router-id ] command, the OSPF process
will select the router-id parameter first. Otherwise, the parameter is selected
automatically.
If the OSPF process is configured or selects the router-id parameter, after being
modified, the router-id parameter takes effect after the OSPF process is rebooted.
After the routing cost is manually configured through the ip ospf cost command,
the manually-configured routing cost takes effect.
If the routing cost is not configured manually but the link bandwidth reference
value is configured, the routing cost is automatically configured based on link
bandwidth reference value. The formula is: cost = link bandwidth reference value
(bit/s) / link bandwidth. If the cost value is greater than 65535, it is configured to
65535. If no link bandwidth reference value is configured, it is configured to 100
Mbit/s by default.
Priorities configured by the neighbour and ip ospf priority priority commands are
different:
The priority configured by the neighbor command indicates that whether the
neighbor has the right to vote. If you set the priority to 0 when configuring the
neighbor, the local router believes that the neighbor has no right to vote and will
not sent Hello packets to the neighbor. This method helps reduce the number of
Hello packets transmitted through the network during DR and BDR election
processes. However, if the local router is a DR or BDR, it will send the Hello
packet to the neighbor, whose priority is configured to 0, to establish the
neighboring relationship.
The priority configured by the ip ospf priority priority command is used for actual
DR election.
All routers in the Stub area must be configured with the Stub property through the
area area-id stub command.
To set an area to a Totally Stub area, all routers in the area must be configured by
the area area-id stub command. In addition, all ABRs in the area must be
configured by the area area-id stub no-summary command.
The backbone area cannot be set to the Stub area.
ASBR should not be in the Stub area. It means that routers besides the AS cannot
be transmitted in the Stub area.
Raisecom Proprietary and Confidential
134
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 9 IP routing
Before configuring OSPF receiving policy, ensure that the IP ACL used by the
OSPF receiving policy has been created.
When the iTN8800 performs filtering based on IP ACL, if the ACL mode is
configured to permit, all routes, which match with the ACL, can pass. Others are
filtered.
You cannot modify the IP ACL unless it is not used by any routing policy.
Different from IP ACL, the IP prefix-list can be modified even it is being used.
If the configured IP prefix-list does not exist, do not filter received routes.
Before configuring OSPF global releasing policy, ensure that the IP ACL used by
the OSPF global releasing policy has been created.
You cannot modify the IP ACL unless it is not used by any routing policy.
Different from IP ACL, the IP prefix-list can be modified even it is being used.
After global releasing policy is configured, routes cannot be redistributed to the
local LSDB unless it passes the global releasing policy. After protocol releasing
policy is configured, the route can be redistributed through the protocol releasing
policy.
After protocol releasing policy is configured, the redistributed protocol route can
be redistributed to the local LSDB through the protocol releasing policy. If global
releasing policy is also configured, the route must be redistributed through the
global releasing policy.
If the configured filtering policy does not exist, it believes that the command fails to
configure the filtering policy and no filtering operation is performed on received routes.
If global BFD is enabled through the bfd all-interfaces command, no matter what
BFD configurations are set on the interface, BFD is enabled.
If global BFD is disabled, BFD configurations on the interface take effect.
9.4.16 Maintenance
Command Description
Rasiecom#clear ip ospf [ process-id | vrf vrf-name ] Restart the OSPF process.
process [ graceful ]
Configuring overhead
The ISIS overhead can be configured automatically or manually. After the automatic
calculation of the overhead on the interface is enabled, the ISIS will automatically calculate
the overhead on the interface according to the following rules:
When the type of overhead is configured to wide, ISIS will automatically calculate the
value according to the interface rate, the formula is: overhead on the interface =
reference rate/interface rate × 10, and the max value obtained is 16777214.
When the type of overhead is configured to narrow, the interface overhead is:
– 60 for interface rate between 1 and 10 Mbit/s
– 50 for interface rate between 1 and 100 Mbit/s
– 40 for interface rate between 101 and 155 Mbit/s
– 30 for interface rate between 156 and 622 Mbit/s
– 20 for interface rate between 623 and 2500 Mbit/s
– 10 for other conditions
Adjacencies
This configuration is only applied to Level-1-2 routers.
If the host is Level-1-2 router, it needs to establish association with peer router in certain
area (Level-1 or Level-2). Configuring an area for establishing adjacency can restrain the
interface from receiving and sending the Hello packet only from that certain area.
In the point-to-point link, the interface can only receive and send one type of Hello
packet. Configuring an area for establishing adjacency can reduce the processing time
between routers and save bandwidth.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#interface Enter interface configuration mode.
interface-type interface-number
3 Raisecom(config-port)#isis Configure an area for establishing interface adjacency.
circuit-type { level-1 | level-1-
2 | level-2-only }
By default, it is Level-1-2.
Configuring LSP
Step Command Description
9.5.11 Maintenance
No. Command Description
1 Rasiecom#clear isis area-tag [ graceful-restart ] Clear ISIS.
2 Rasiecom#clear isis neighbor [ system-id ] Clear ISIS neighbors.
Configuring RR
Prefix notification rules of the Router Reflector (RR) are shown as below:
Rule 1: the RR just notifies or reflects the optimum path to which it returns.
Rule 2: the RR always notifies the prefix to the BGP neighbor.
Rule 3: when notifying the prefix, the RR client follows the common IBGP loopback
prevention rule.
Rule 4: to notify the IBGP neighbor, client, or non-client of the prefix, follow rules 5, 6,
and 7.
Rule 5: the RR will notify all its clients and non-clients of the prefix, which is learned
from the external BGP neighbor.
Rule 6: the RR will notify all its clients of the prefix, which reaches the RR through a
non-client IBGP neighbor.
Rule 7: the RR will notify other clients and non-clients of the route, if the prefix reaches
the RR through a client.
9.6.10 Maintenance
Command Description
Rasiecom#clear ip bgp dampening [ network-address Clear all route dampening information.
[ network-mask ] ]
Rasiecom#clear ip bgp { all | ip-address | external Reset all or specified BGP connections of
| internal } [ ipv4 unicast | vpnv4 unicast ] the public network.
Rasiecom#clear ip bgp [ ipv4 unicast | vpnv4
unicast ]as-id
Rasiecom#clear ip bgp { all | ip-address | external Update all or specified BGP routes of the
| internal } [ ipv4 unicast | vpnv4 unicast ] { in public network without breaking the BGP
| out | soft } connecting.
Rasiecom#clear ip bgp [ ipv4 unicast | vpnv4
unicast ] as-id { in | out | soft }
You can configure RIP version globally and on the interface of the iTN8800. If the
interface is configured with RIP version, then this RIP version prevails.
If poison reverse and split horizon are enabled together, split horizon will be invalid.
9.7.11 Maintenance
Command Description
Rasiecom#clear rip database Clear information about RIP routing database.
Rasiecom#clear rip statistics Clear RIP interface statistics.
10 MPLS
Scenario
Configurations on MPLS basic functions are prerequisites for making other MPLS functions
effective. The Label Switching Router (LSR) is the network device, which can exchange and
forward the MPLS label. The LSR is also called the MPLS node. The LSR is the basic
element in the MPLS network. All LSRs support MPLS. To enable global MPLS function,
you must enable the LSR ID.
Prerequisite
N/A
Scenario
The static LSP is established by the administrator by manually assigning labels for all FECs.
It is suitable for simple and stable small-size network. To manually assign labels, the outgoing
label value of the last node is the incoming label value of the next mode.
The static LSP does not use the label distribution protocol and does not exchange the control
packet. Therefore, it consumes fewer resources. However, the LSP, established by statically
assigning labels, cannot be dynamically adjusted according to the network topology changes.
The administrator needs to manually adjust the static LSP.
Prerequisite
Configure MPLS basic functions.
To configure static bidirectional LSP without IP capability, you must configure the
physical interface to Layer 3 physical interface mode; otherwise, the configuration will
fail.
Scenario
The LDP is used to dynamically assign labels for LSRs to establish the LSP dynamically. The
LDP is used to exchange label information among LSRs. Therefore, when forwarding the
packet, the LSR can add related Tag to the packet based on label requirement of the next-hop
LSP. Then, the packet can be processed properly at the next-hop LSR.
Prerequisite
Enable MPLS.
Scenario
MPLS TE is for solving the traffic congestion on the link caused by unbalanced load which
cannot be resolved by traditional routing. It can accurately control traffic paths to avoid
congestion nodes, thus solving the problem of some paths being overloaded but some paths
being unoccupied.
RSVP is used for dynamically creating public network LSP tunnel in the MPLS TE. It can
create, maintain, and remove MPLS TE LSP and provide false alarm.
The device supports choosing the shortest path through Constraint-based Shortest Path First
(CSPE) and supports 32 neighbors at most.
Prerequisite
The MPLS is enabled.
Scenario
At the MPLS control plane, you cannot detect the fault when the traffic is forwarded along the
LSP. However, you can acknowledge and locate the fault through Ping and Traceroute
operations.
Prerequisite
Establish the path before the Ping test is performed.
Establish the path before the Traceroute test is performed.
Scenario
MPLS L2VPN can be transmitted through multiple types of Tunnels, such as LSP, LDP LSP,
MPLS-TE, and Generic Routing Encapsulation (GRE) Tunnels. This chapter describes the
function of GRE Tunnel and the configuration process of Tunnel policy.
When configuring L2VPN, you need to select GRE as the Tunnel policy. The destination IP
address of the L2VPN services should be the same as that of the GRE Tunnel. Then L2VPN
services can be transmitted through GRE Tunnel.
Prerequisite
Configure MPLS LSR-ID
Enable MPLS.
Scenario
When there are multiple equal-cost paths (ECMP, Equal-Cost MultiPath) between the start PE
and the end PE, the traffic load should be equally allocated on the equal-cost multipath to
implement load balancing of the network so that the network congestion is reduced and the
link bandwidth is fully used. When some of the paths fail, the traffic can be switched to other
paths for forwarding, thus implementing LSP path redundancy backup.
For the same forwarding equivalence class, LDP can receive different label mapping
information from different downstream nodes and create corresponding ingress nodes for
these different equal-cost paths. Meanwhile, LDP can send label mapping information to the
upstream nodes and create corresponding Transit nodes for different equal-cost paths, thereby
creating multiple equal-cost LSPs. The IP services that are forwarded from the device or the
services with the MPLS label can be forwarded to different LSPs according to the load
balancing mode to implement load balancing of the MPLS network.
If L2VPN and L3VPN services are needed, you can select multiple LSPs for load balancing
based on the configured tunnel policy.
Prerequisite
Configure MPLS basic functions.
Configure LDP LSP.
Configure L2VPN or L3VPN and specify a tunnel policy.
Networking requirements
As shown in Figure 10-1, the user has branches in areas A and B. Branches need to transmit
point-to-point VPN leased-line services. Because the network scale is small and the topology
is stable, you can configure bidirectional static LSP between PE A and PE B to work as the
public Tunnel of the L2VPN. By default, devices are configured with IP addresses.
Data preparation
Table 10-1 shows data preparation.
loopback 2 1.1.1.1/32
Configuration steps
Step 1 Configure the IP address of Loopback interface and network-side interface.
The method for configuring the IP address of PEB and P is the same as that for
configuring PEA.
PEA#config
PEA(config)#interface loopback 2
PEA(config-loopback2)#ip address 1.1.1.1 255.255.255.255
PEA(config-loopback2)#interface gigaethernet 1/1/1
PEA(config-gigaethernet1/1/1)#ip address 192.168.1.1 255.255.255.0
PEA(config-gigaethernet1/1/1)#exit
Configure P.
Configure PE B.
Configure PE B.
PEB(config)#interface tunnel 1/1/1
Raisecom Proprietary and Confidential
183
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 10 MPLS
PEB(config-tunnel1/1/1)#destination 192.168.1.1
PEB(config-tunnel1/1/1)#mpls tunnel-id 11PEB(config-tunnel1/1/1)#mpls te
commit
PEB(config-tunnel1/1/1)#exit
Checking configurations
Use the show mpls bidirectional static-lsp command to show configurations of the static
bidirectional LSP on PE A, P, and PE B.
Configurations on Ingress node PE A are shown as below.
Egress-Lsr-Id: 192.168.4.2
Forward Destination: 192.168.4.0
Forward In-Label: --
Forward Out-Label: 1001
Forward In-Interface: --
Forward Out-Interface: gigaethernet1/1/1
Forward Next-Hop: --
Forward Next-Mac: 000E.5E11.1112
Forward Vlan-Id: --
Forward XcIndex: 1
Forward Ds mode: Uniform
Forward PipeServClass: --
Forward Exp2LocalPriMap: 0
Forward LocalPri2ExpMap: 0
Backward Destination: --
Backward In-Label: 2001
Backward Out-Label: --
Backward In-Interface: all interfaces
Backward Out-Interface: --
Backward Next-Hop: --
Backward Next-Mac: --
Backward Vlan-Id: --
Backward XcIndex: 1
Backward Ds mode: Uniform
Backward PipeServClass: --
Backward Exp2LocalPriMap: 0
Backward LocalPri2ExpMap: 0
Tunnel-Id: 1
LSP Status: Down
Networking requirements
As shown in Figure 10-2, the user has branches in areas A and B. Branches need to transmit
point-to-point VPN leased-line services. To facilitate network maintenance and reduce manual
intervention, you can configure the dynamic LSP between PE A and PE B to work as the
public Tunnel of the L2VPN. By default, devices are configured with IP addresses.
Data preparation
Table 10-2 shows data preparation.
loopback 2 1.1.1.1/32
Configuration steps
Step 1 Enable MPLS and LDP globally.
Configure PE A.
PEA(config)#mpls enable
PEA(config)#mpls ldp
Configure P.
Step 2 Enable LDP on the interface and configure LDP basic properties.
Configure PE A.
Configure P.
Configure PE B.
Step 3 PEB(config-port)#exitConfigure the IP address of the Loopback interface and OSPF route.
Configure PE A.
PEA(config)#interface loopback 2
PEA(config-loopbackif)#ip address 192.168.1.1 255.255.255.0
PEA(config-loopbackif)#exit
PEA(config)#router ospf 1
PEA(config-router-ospf)#network 192.168.1.1 255.255.255.255 0.0.0.0
PEA(config-router-ospf)#network 1.1.1.1 255.255.255.255 0.0.0.0
PEA(config-router-ospf)#exit
Configure P.
P(config)#interface loopback 2
P(config-loopbackif)#ip address 192.168.1.2
P(config)#router ospf 1
P(config-router-ospf)#network 2.2.2.2 255.255.255.255 area 0.0.0.0
P(config-router-ospf)#network 192.168.1.2 255.255.255.255 area 0.0.0.0
P(config-router-ospf)#network 192.168.4.1 255.255.255.255 area 0.0.0.0
P(config-router-ospf)#exit
Configure PE B.
PEB(config)#interface loopback 2
PEB(config-loopbackif)#ip address 192.168.4.2 255.255.255.0
PEB(config)#router ospf 1
PEB(config-router-ospf)#network 3.3.3.3 255.255.255.255 area 0.0.0.0
PEB(config-router-ospf)#network 192.168.4.2 255.255.255.255 area 0.0.0.0
PEB(config-router-ospf)#exit
Checking results
Use the show mpls lsp ldp command to show LSP configurations on PE A, P, and PE B.
Networking requirements
As shown in Figure 10-3, the user has branches in areas A and B, which communicate with
each other by exchanging point-to-point VPN leased-line services. To provide accurate
bandwidth guarantee, you can configure the RSVP-TE LSP between PE A and PE B to work
as the public Tunnel of the L2VPN. By default, devices are configured with IP addresses.
Data preparation
Table 10-3 shows data preparation.
loopback 2 1.1.1.1/32
Configuration steps
Step 1 Configure RSVP-TE basic functions.
Configure PE A.
Configure P.
Configure PE B.
PEA(config-tunnel1/1/1)#mpls te commit
Configure PE B.
Checking results
Use the show mpls rsvp-te lsp command to show LSP configurations on PE A, P, and PE B.
Configurations on PE A
Configurations on P
Configurations on PE B
Networking requirements
Manual LDP FRR is suitable for the stable networks with simple structure. As shown in
Figure 10-4, iTN A↔iTN B serves as the active LDP LSP link while the iTN A↔iTN
C↔iTN B serves as the standby LDP LSP link. When links between iTN A↔iTN B fail, the
devices are required to fast respond to the faults and switch services to the standby route iTN
A↔iTN C↔iTN B to recover services as soon as possible.
After manual LDP FRR is configured, a standby LSP link will be generated. Therefore, when
the active link fails, services can be fast switched to the standby link.
The following example shows the manual configuration of LDP FRR. This
configuration will generate a unidirectional backup LSP. For the peer device, the
configuration of generating a backup LSP is similar.
Configuration principle
Enable OSPF routes on each device respectively and make routes among devices
available.
Configure LDP sessions on each device respectively and create LDP LSP.
Configure LDP FRR on the active LSP interface of iTN A and specify the next hop IP
address of the standby FRR LSP.
Configure dynamic BFD LDP LSP on iTN A and iTN B to implement fast detection of
LSP faults.
Data preparation
Table 10-4 lists the data required for configuring manual LDP FRR.
Configuration steps
Step 1 Configure the IP address of the interface.
iTN A
iTNA#config
iTNA(config)#interface loopback 2
iTNA(config-loopback2)#ip address 1.1.1.1 255.255.255.255
iTNA(config-loopback2)#interface gigaethernet 1/1/1.10
iTNA(config-gigaethernet1/1/1.10)#encapsulation dot1Q 10
iTNA(config-gigaethernet1/1/1.10)#ip address 10.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/1.10)#interface gigaethernet 1/1/2.20
iTNA(config-gigaethernet1/1/2.20)#encapsulation dot1Q 20
iTNA(config-gigaethernet1/1/2.20)#ip address 20.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/2.20)#exit
iTN B
iTNB#config
iTNB(config)#interface loopback 2
iTNB(config-loopback2)#ip address 2.2.2.2 255.255.255.255
iTNB(config-loopback2)#interface gigaethernet 1/1/1.10
iTNB(config-gigaethernet1/1/1.10)#encapsulation dot1Q 10
iTNB(config-gigaethernet1/1/1.10)#ip address 10.10.10.2 255.255.255.0
iTNB(config-gigaethernet1/1/1.10)#interface gigaethernet 1/1/2.20
iTNB(config-gigaethernet1/1/2.20)#encapsulation dot1Q 20
iTNB(config-gigaethernet1/1/2.20)#ip address 30.10.10.2 255.255.255.0
iTNB(config-gigaethernet1/1/2.20)#exit
iTN C
iTNC#config
iTNC(config)#interface loopback 2
iTNC(config-loopback2)#ip address 3.3.3.3 255.255.255.255
iTNC(config-loopback2)#interface gigaethernet 1/1/1.20
iTNC(config-gigaethernet1/1/1.20)#encapsulation dot1Q 10
iTNC(config-gigaethernet1/1/1.20)#ip address 20.10.10.2 255.255.255.0
iTNC(config-gigaethernet1/1/1.20)#interface gigaethernet 1/1/2.20
iTNC(config-gigaethernet1/1/2.20)#encapsulation dot1Q 20
iTNC(config-gigaethernet1/1/2.20)#ip address 30.10.10.1 255.255.255.0
iTNC(config-gigaethernet1/1/2.20)#exit
Step 2 Start an OSPF process, define the interface or network which participates in the OSPF process,
and specify the local area of the interface or network.
iTN A
iTNA(config)#router ospf 1
iTNA(config-router-ospf)#network 1.1.1.1 0.0.0.0 area 0
iTNA(config-router-ospf)#network 10.10.10.1 0.0.0.255 area 0
iTNA(config-router-ospf)#network 20.10.10.1 0.0.0.255 area 0
iTNA(config-router-ospf)#exit
iTN B
iTNB(config)#router ospf 1
iTNB(config-router-ospf)#network 2.2.2.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 10.10.10.2 0.0.0.255 area 0
iTNB(config-router-ospf)#network 30.10.10.2 0.0.0.255 area 0
iTNB(config-router-ospf)#exit
iTN C
iTNC(config)#router ospf 1
iTNC(config-router-ospf)#network 3.3.3.3 0.0.0.0 area 0
iTNC(config-router-ospf)#network 20.10.10.2 0.0.0.255 area 0
iTNC(config-router-ospf)#network 30.10.10.1 0.0.0.255 area 0
iTNC(config-router-ospf)#exit
iTNC(config)#interface gigaethernet 1/1/1.20
/*enter the interface which connects iTN A.*/
iTNC(config-gigaethernet1/1/1.20)#ip ospf cost 10
/*configure the cost value which ensures that the data can optimally
select the active link and arrive at the peer device iTN A.*/
iTNC(config-gigaethernet1/1/1.20)#interface gigaethernet 1/1/2.20
/*enter the interface which connects iTN B.*/
iTNC(config-gigaethernet1/1/2.20)#ip ospf cost 10
/* configure the cost value which ensures that the data can optimally
select the active link and arrive at the peer device iTN B.*/
iTN B
iTN C
Step 4 Configure LDP FRR manually on the active LDP LSP interface on the iTN A and specify the
next-hop IP address. After a standby LSP path is generated, specify the next hop IP address.
Step 5 (Enabled by default, optional) trigger the device to assign a LSP label for the host route IP
prefix.
iTN A
iTNA(config)#lsp-trigger host
iTN B
iTNB(config)#lsp-trigger host
iTN C
iTNc(config)#lsp-trigger host
Step 6 Configure BFD for single-hop IP address on iTN A and iTN B to fast detect LSP faults and
switch services.
iTN A
iTN B
Checking results
Use the show ip route command to show the routing table learned by each node.
iTNA(config)#show ip route
Routing Tables: Default-IP-Routing-Table
-------------------------------------------------------------------------
--
Flag: C - connected, S - static, R - RIP, B - BGP, O - OSPF, I - IS-IS
P - Protocol, s - States, > - selected , * - active, Dis - Distance
P&s Destination/Mask Dis/Metric NextHop Age Interface
C>* 1.0.0.0/8 0/0 1.1.1.1 01w2d02h Loopback2
C>* 1.1.1.1/32 0/0 127.0.0.1 01w2d02h lo0
O>* 2.2.2.2/32 110/2 10.10.10.2 02:56:23 GE1/1/1.10
O>* 3.3.3.3/32 110/2 20.10.10.2 00:09:04 GE1/1/2.20
C>* 20.10.10.0/24 0/0 20.10.10.1 01w0d22h GE1/1/2.20
C>* 20.10.10.1/32 0/0 127.0.0.1 01w0d22h lo0
O>* 30.10.10.0/24 110/2 10.10.10.2 00:09:04 GE1/1/1.10
Use the show mpls lsp command to show the creation status of LDP FRR standby path.
Common questions
When creating LDP FRR standby path fails, you can operate as below:
Check whether the IP address of the interface is correctly configured.
Check whether there is a route to the destination network in the routing table.
Check whether the egress interface of the routes is the corresponding service interface.
Check whether the next-hop address of the specified LDP FRR is the IP address of the
service interface of the standby device.
Networking requirements
As shown in Figure 10-5, enable automatic LDP LSP on the links between iTN A and iTN C.
When links between iTN A↔iTN B↔iTN C fail, the devices are required to fast respond to
the faults and switch services to the standby LSP link which passes through iTN D to recover
services as soon as possible.
After automatic LDP FRR is configured, a standby LSP path will be generated. Therefore,
when the active link fails, services can be fast switched to the standby LSP link, which
protects the active link and avoids data loss.
The following example shows the process of automatic LDP FRR configurations. This
configuration will generate a unidirectional backup LSP. For the peer device, the
configuration of generating a backup LSP is similar.
Configuration principle
Enable OSPF routes on each device respectively and make routes among devices
available.
Configure LDP sessions on each device respectively and create LDP LSP.
Configure a routing policy on iTN A and iTN C respectively, enable IP FRR, and
meanwhile apply the policy.
Configure dynamic BFD LDP LSP on iTN A, iTN B, and iTN C to implement fast
detection of LSP faults.
Configure all devices to assign active/standby LSP labels based on IP prefix.
Data preparation
Table 10-5 lists the data required for configuring automatic LDP FRR.
Configuration steps
Step 1 Configure the IP address of the interface.
iTN A
iTNA#config
iTNA(config)#interface loopback 2
iTNA(config-loopback2)#ip address 1.1.1.1 255.255.255.255
iTNA(config-loopback2)#interface gigaethernet 1/1/1
iTNA(config-gigaethernet1/1/1)#ip address 10.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNA(config-gigaethernet1/1/2)#ip address 30.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/2)#exit
iTN B
iTNB#config
iTNB(config)#interface loopback 2
iTNB(config-loopback2)#ip address 2.2.2.2 255.255.255.255
iTNB(config-loopback2)#interface gigaethernet 1/1/1
iTNB(config-gigaethernet1/1/1)#ip address 10.10.10.2 255.255.255.0
iTNB(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNB(config-gigaethernet1/1/2)#ip address 20.10.10.1 255.255.255.0
iTNB(config-gigaethernet1/1/2)#exit
iTN C
iTNC#config
iTNC(config)#interface loopback 2
iTNC(config-loopback2)#ip address 3.3.3.3 255.255.255.255
iTNC(config-loopback2)#interface gigaethernet 1/1/1
iTNC(config-gigaethernet1/1/1)#ip address 20.10.10.2 255.255.255.0
iTNC(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNC(config-gigaethernet1/1/2)#ip address 40.10.10.2 255.255.255.0
iTNC(config-gigaethernet1/1/2)#exit
iTN D
iTND#config
iTND(config)#interface loopback 2
iTND(config-loopback2)#ip address 4.4.4.4 255.255.255.255
iTND(config-loopback2)#interface gigaethernet 1/1/1
iTND(config-gigaethernet1/1/1)#ip address 30.10.10.2 255.255.255.0
iTND(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTND(config-gigaethernet1/1/2)#ip address 40.10.10.1 255.255.255.0
iTND(config-gigaethernet1/1/2)#exit
Step 2 Create an OSPF routing process, and define the interface or network on which OSPF runs and
the local area of the interface or network.
iTN A
iTNA(config)#router opsf 1
iTNA(config-router-ospf)#network 1.1.1.1 0.0.0.0 area 0
iTNA(config-router-ospf)#network 10.10.10.1 0.0.0.0 area 0
iTNA(config-router-ospf)#network 30.10.10.1 0.0.0.0 area 0
iTNA(config-router-ospf)#exit
iTN B
iTNB(config)#router opsf 1
iTNB(config-router-ospf)#network 2.2.2.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 10.10.10.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 20.10.10.1 0.0.0.0 area 0
iTNB(config-router-ospf)#exit
iTN C
iTNC(config)#router opsf 1
iTNCconfig-router-ospf)#network 3.3.3.3 0.0.0.0 area 0
iTNC(config-router-ospf)#network 20.10.10.2 0.0.0.0 area 0
iTNC(config-router-ospf)#network 40.10.10.2 0.0.0.0 area 0
iTNC(config-router-ospf)#exit
iTN D
iTND(config)#router opsf 1
iTND(config-router-ospf)#network 4.4.4.4 0.0.0.0 area 0
iTND(config-router-ospf)#network 30.10.10.2 0.0.0.0 area 0
iTND(config-router-ospf)#network 40.10.10.1 0.0.0.0 area 0
iTND(config-router-ospf)#exit
iTNA(config)#mpls ldp
/*enable LDP globally.*/
iTNA(config)#interface gigaethernet 1/1/1
iTNA(config-gigaethernet1/1/1)#mpls ldp
/*enable LDP on the interface*/
iTNA(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNA(config-gigaethernet1/1/2)#mpls ldp
/*enable LDP on the interface.*/
iTN B
iTN C
iTNC(config)#mpls lsr-id 3.3.3.3
iTNC(config)#mpls enable
iTNC(config)#mpls ldp
/*enable LDP globally.*/
iTNC(config)#interface gigaethernet 1/1/1
iTNC(config-gigaethernet1/1/1)#mpls ldp
/*enable LDP on the interface.*/
iTNC(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNC(config-gigaethernet1/1/2)#mpls ldp
/*enable LDP on the interface.P*/
iTN D
Step 4 Configure a routing policy which is to match IP address based on IP prefix list and specify the
next-hop IP address of the standby route to implement IP FRR.
iTN A
Automatic LDP FRR is implemented through IP FRR. After IP FRR is enabled, the
system will automatically establish a LDP FRR standby LSP path.
Step 5 (Optional) trigger the device to assign LSP labels for all route prefixes and assign labels of the
standby LSP path which is based on automatic LDP FRR.
iTN A
iTNA(config)#lsp-trigger all
/*assign LSP labels for all route prefixes of the device.*/
iTNA(config)#mpls ldp auto-frr lsp-trigger all
/*assign standby LSP labels for all route prefixes of the device.*/
iTN B
iTNB(config)#lsp-trigger all
/*assign LSP labels for all route prefixes of the device.*/
iTNB(config)#mpls ldp auto-frr lsp-trigger all
/*assign standby LSP labels for all route prefixes of the device.*/
iTN C
iTNC(config)#lsp-trigger all
/*assign LSP labels for all route prefixes of the device.*/
iTNC(config)#mpls ldp auto-frr lsp-trigger all
/*assign standby LSP labels for all route prefixes of the device.*/
iTN D
iTND(config)#lsp-trigger all
/*assign LSP labels for all route prefixes of the device.*/
iTND(config)#mpls ldp auto-frr lsp-trigger all
/*assign standby LSP labels for all route prefixes of the device.*/
Step 6 Configure BFD for IP single-hop detection to implement fast service switching from the
active path to the standby LSP path.
iTN A
iTN B
iTN C
Checking results
Use the show ip route command to show the routing table learned by each node.
iTNA(config)#show ip route
Routing Tables: Default-IP-Routing-Table
-------------------------------------------------------------------------
Flag: C - connected, S - static, R - RIP, B - BGP, O - OSPF, I - IS-IS
P - Protocol, s - States, > - selected , * - active, Dis - Distance
P&s Destination/Mask Dis/Metric NextHop Age Interface
C>* 1.0.0.0/8 0/0 1.1.1.1 01w3d00h Loopback2
C>* 1.1.1.1/32 0/0 127.0.0.1 01w3d00h lo0
O>* 2.2.2.2/32 110/2 10.10.10.2 01:33:00 GE1/1/1
O>* 3.3.3.3/32 110/2 10.10.10.2 01:33:00 GE1/1/1
O>* 4.4.4.4/32 110/2 30.10.10.2 00:00:28 GE1/1/2
C>* 10.10.10.0/24 0/0 10.10.10.1 01:33:49 GE1/1/1
C>* 10.10.10.1/32 0/0 127.0.0.1 01:33:49 lo0
Use the show ip route detail command to show active routes and standby routes.
Use the show mpls lsp command to show whether configuration results are correct.
Common questions
Why do I need to configure IP FRR when configuring automatic LDP FRR?
Because the device will automatically generate the backup LSP path based on the already
configured IP FRR backup route.
Networking requirements
As shown in Figure 10-6, enable active LSP links between iTN A↔iTN B↔iTN C↔iTN D.
FRR should be configured to protect the directly connected route between iTN B↔iTN C.
Configure a bypass LSP link through iTN E. The bypass LSP link should be created by the
routes between iTN B↔iTN E↔iTN C. The iTNB serves as a Point of Local Repair (PLR)
and iTN C serves as a Merge Point (MP). The primary tunnel and bypass tunnel should be
created through MPLS-TE.
The following example shows the process of configuring MPLS-TE FRR. This
configuration will generate a unidirectional backup LSP. For the peer device, the
configuration of generating a backup LSP is similar.
Configuration principle
Enable OSPF routes on each device respectively and make routes among devices
available.
Configure MPLS basic functions on all devices and enable MPLS TE.
Configure an active Tunnel on iTN A and configure related attributes of the active
Tunnel, and then enable TE FRR on the active Tunnel interface.
Create a bypass Tunnel interface on PLR node iTN B and configure related attributes of
the bypass tunnel.
Bind the active Tunnel egress interface of iTN B, namely, the egress interface of the link
under protection, with the bypass Tunnel.
Data preparation
Table 10-6 lists the data required for configuring manual TE FRR.
Configuration steps
Step 1 Configure the IP address of the interface. The method for configuring the interface IP address
of iTN C, iTN D, and iTN E is similar to that for iTN A and iTN B.
iTN A
iTNA#config
iTNA(config)#interface loopback 2
iTNA(config-loopback2)#ip address 1.1.1.1 255.255.255.255
iTNA(config-loopback2)#interface gigaethernet 1/1/1
iTNA(config-gigaethernet1/1/1)#ip address 10.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/1)#exit
iTN B
iTNB#config
iTNB(config)#interface loopback 2
iTNB(config-loopback2)#ip address 2.2.2.2 255.255.255.255
iTNB(config-loopback2)#interface gigaethernet 1/1/1
iTNB(config-gigaethernet1/1/1)#ip address 10.10.10.2 255.255.255.0
iTNB(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNB(config-gigaethernet1/1/2)#ip address 20.10.10.1 255.255.255.0
Step 2 Enable the OSPF routing process, define the interface or network which participates in the
OSPF process, and define the local area of the specified interface or network.
iTN A
iTNA(config)#router opsf 1
iTNA(config-router-ospf)#network 1.1.1.1 0.0.0.0 area 0
iTNA(config-router-ospf)#network 10.10.10.1 0.0.0.0 area 0
iTNA(config-router-ospf)#exit
iTN B
iTNB(config)#router opsf 1
iTNB(config-router-ospf)#network 2.2.2.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 10.10.10.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 20.10.10.1 0.0.0.0 area 0
iTNB(config-router-ospf)#network 40.10.10.1 0.0.0.0 area 0
iTNB(config-router-ospf)#exit
iTN C
iTNC(config)#router opsf 1
iTNCconfig-router-ospf)#network 3.3.3.3 0.0.0.0 area 0
iTNC(config-router-ospf)#network 20.10.10.2 0.0.0.0 area 0
iTNC(config-router-ospf)#network 30.10.10.1 0.0.0.0 area 0
iTNC(config-router-ospf)#network 50.10.10.1 0.0.0.0 area 0
iTNC(config-router-ospf)#exit
iTN D
iTND(config)#router opsf 1
iTND(config-router-ospf)#network 4.4.4.4 0.0.0.0 area 0
iTND(config-router-ospf)#network 30.10.10.2 0.0.0.0 area 0
iTND(config-router-ospf)#exit
iTN E
iTNE(config)#router opsf 1
iTNE(config-router-ospf)#network 5.5.5.5 0.0.0.0 area 0
iTNE(config-router-ospf)#network 40.10.10.2 0.0.0.0 area 0
Step 3 Configure MPLS basic functions and enable global RSVP-TE and interface RSVP-TE.
iTN A
iTN B
iTN C
iTN D
iTN E
Configure the related attributes of the active tunnel interface and bind the active tunnel
with the LSP explicit path.
iTNA(config-tunnel1/1/1)#mpls te fast-reroute
iTNA(config-tunnel1/1/1)#mpls te commit
iTNA(config-tunnel1/1/1)#exit
Configure related attributes of the bypass tunnel and bind the bypass tunnel with the
bypass LSP explicit path.
Step 6 Bind the bypass tunnel with the active LSP egress interface of the iTN B.
Checking results
Check tunnel configurations through the show te tunnel command on the ingress node
iTN A and PLR node iTN B respectively.
When links between the iTN B and iTN C run normally, use the show mpls te frr
protecting command to check the information about the bypass tunnel.
When the link between the iTN B and iTN C fails, use the show mpls te frr protecting
command to check the information about the bypass tunnel.
Common questions
After configurations are complete, TE FRR backup link cannot be successfully created.
Check whether the active Tunnel and bypass Tunnel are Up.
Check whether the destination address of the bypass Tunnel is on the node of the active
Tunnel path.
Networking requirements
As shown in Figure 10-7, enable active LSP links between iTN A↔ iTN B↔iTN C↔iTN D.
The LSP link should pass the FRR protection node iTN Z. Configure a bypass LSP link which
passes the iTN E. The bypass link is created by routes between iTN B↔iTN E↔iTN C. The
iTN B serves as the PLR. The active tunnel and bypass tunnel should be created through
MPLS-TE.
The following example shows the process of configuring MPLS-TE FRR. This
configuration will generate a unidirectional backup LSP. For the peer device, the
configuration of generating a backup LSP is similar.
Configuration principle
Enable OSPF routes on all devices and make routes among devices available.
Configure MPLS basic functions on all devices and enable MPLS TE.
Configure an active Tunnel on iTN A and configure related attributes of the active
Tunnel, and then enable TE FRR on the active Tunnel interface.
Create a bypass Tunnel interface on PLR node iTN B and configure related attributes of
the bypass tunnel.
Bind the active Tunnel egress interface of iTN B, namely, the egress interface of the link
under protection, with the bypass Tunnel.
Data preparation
Table 10-7 lists the data required for configuring manual TE FRR.
Configuration steps
Step 1 Configure the IP address of the interface. The method for configuring the interface IP address
of iTN C, iTN D, iTN E, and iTN Z is similar to that for iTN A and iTN B.
iTN A
iTNA#config
iTNA(config)#interface loopback 2
iTNA(config-loopback2)#ip address 1.1.1.1 255.255.255.255
iTNA(config-loopback2)#interface gigaethernet 1/1/1
iTNA(config-gigaethernet1/1/1)#ip address 10.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/2)#exit
iTN B
iTNB#config
iTNB(config)#interface loopback 2
iTNB(config-loopback2)#ip address 2.2.2.2 255.255.255.255
iTNB(config-loopback2)#interface gigaethernet 1/1/1
iTNB(config-gigaethernet1/1/1)#ip address 10.10.10.2 255.255.255.0
iTNB(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
iTNB(config-gigaethernet1/1/2)#ip address 20.10.10.1 255.255.255.0
iTNB(config-gigaethernet1/1/2)#interface gigaethernet 1/1/3
iTNB(config-gigaethernet1/1/3)#ip address 40.10.10.1 255.255.255.0
iTNB(config-gigaethernet1/1/3)#exit
Step 2 Create an OSPF routing process, define the interface or network which participates in the
OSPF process, and specify the local area of the interface or network. The method for
configuring other devices is the similar to that for iTN A and iTN B.
iTN A
iTNA(config)#router opsf 1
iTNA(config-router-ospf)#network 1.1.1.1 0.0.0.0 area 0
iTNA(config-router-ospf)#network 10.10.10.1 0.0.0.0 area 0
iTNA(config-router-ospf)#exit
iTN B
iTNB(config)#router opsf 1
iTNB(config-router-ospf)#network 2.2.2.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 10.10.10.2 0.0.0.0 area 0
iTNB(config-router-ospf)#network 20.10.10.1 0.0.0.0 area 0
iTNB(config-router-ospf)#network 40.10.10.1 0.0.0.0 area 0
iTNB(config-router-ospf)#exit
Step 3 Configure MPLS basic functions and enable global RSVP-TE and interface RSVP-TE. The
method for configuring other devices is similar to that for iTN A and iTN B.
iTN A
iTN B
Configure the related attributes of the active tunnel interface and bind the active tunnel
with the LSP explicit path.
Configure related attributes of the bypass tunnel and bind the bypass tunnel with the
bypass LSP explicit path.
Step 6 Bind the bypass tunnel with the active LSP egress interface of the iTN B.
Checking results
Check tunnel configurations through the show te tunnel command on the ingress node
iTN A and PLR node iTN B respectively.
Interface: tunnel1/1/2
Tunnel state:UP, Is bypass: YES, working LSPID:7
/*Tunnel is Up, which indicates that the bypass tunnel is successfully
configured.*/
Primary lsp explicit path Name:a-c status:Ready
LSPID:7, XcIndex:178
Ingress LSR ID:2.2.2.2 Egress LSR ID:3.3.3.3 Tunnel ID: 2
Signaling Protocol:Rsvp QosMode:-- BandWidth Cir:-- Pir:-- Used:--
Weight:--
DsMode:Uniform Exp2LocalPriMap:Default LocalPri2ExpMap:Default
PipeServClass --
Record Route:NO Record Label:NO
FRR Type: --
IncludeAnyAffinity:0 ExcludeAnyAffinity:0
When node iTN Z works normally, use the show mpls te frr protecting command to
check the information about the bypass tunnel.
When node iTN Z fails, use the show mpls te frr protecting command to check
information about the bypass tunnel.
Common questions
After configurations are complete, TE FRR backup link cannot be successfully created.
Check whether the active Tunnel and bypass Tunnel are Up.
Check whether the destination address of the bypass Tunnel is on the node of the active
Tunnel path.
11 VPN
This chapter describes principles and configuration procedures of MPLS VPN, as well as
related configuration examples, including following sections:
Configuring MPLS VPWS
Configuring MPLS VPLS
Configuring VPWS to access VPLS
Configuring MPLS L3VPN
Maintainance
Configuration examples
Scenario
VPWS is a point-to-point L2VPN technology. It forms a service mode that multiple services
can be provided in a network. Therefore, the carrier can provide Layer 2 services and Layer 3
services in a MPLS network.
The access modes for the L2VPN to extract sub-interface services are different. Therefore, the
modes adopted by the system to process the VLAN Tags of Ethernet packets are also
differently, which are divided into symmetric mode and asymmetric mode as shown in Table
11-1 and Table 11-2.
Dot1q sub- Ingress interface Remove the outer Tag of Remove the outer Tag of the packet first
interface the packet. and then add outer Tag according to the
Use the vlan translation interface configurations.
svlan untag command to Use the vlan translation svlan untag
enable the interface to command to enable the interface to remove
remove the outer Tag. the outer Tag. Otherwise, the Tag cannot
Otherwise, the Tag cannot be removed.
be removed. By default, the TPID and the VLAN Tag
of the added outer Tag are 0x8100 and 0
respectively.
Egress interface Add the outer Tag to the Replace the outer Tag of the packet.
packet. Use the vlan translation svlan untag
Use the vlan translation command to enable the interface to add the
svlan untag command to outer Tag. Otherwise, the Tag cannot be
enable the interface to add added. The added Tag is the SVLAN
the outer Tag. Otherwise, encapsulated by the sub-interface.
the Tag cannot be added.
The added Tag is the
SVLAN encapsulated by
the sub-interface.
QinQ sub- Ingress interface Remove the outer Tag of Remove the outer Tag of the packet first
interface the packet. and then add outer Tag according to the
Use the vlan translation interface configurations.
svlan untag command to Use the vlan translation svlan untag
enable the interface to command to enable the interface to remove
remove the outer Tag. the outer Tag. Otherwise, the Tag cannot
Otherwise, the Tag cannot be removed.
be removed. By default, the TPID and the VLAN Tag
of the added outer Tag are 0x8100 and 0
respectively.
Remove the outer Tag of Remove the outer double Tag of the packet
the packet. first and then add outer Tag according to
Use the vlan translation the interface configurations.
svlan untag cvlan untag Use the vlan translation svlan untag
command to enable the cvlan untag command to enable the
interface to remove the interface to remove the outer double Tag.
outer double Tag. Otherwise, the Tag cannot be removed.
Otherwise, the Tag cannot By default, the TPID and the VLAN Tag
be removed. of the added outer Tag are 0x8100 and 0
respectively.
egress interface Add the outer Tag to the Replace the outer Tag of the packet.
packet. Use the vlan translation svlan untag
Use the vlan translation command to enable the interface to add the
svlan untag command to outer Tag. Otherwise, the Tag cannot be
enable the interface to add added. The added Tag is the SVLAN
the outer Tag. Otherwise, encapsulated by the sub-interface.
the Tag cannot be added.
The added Tag is the
SVLAN encapsulated by
the sub-interface.
Remove the outer double Remove the outer Tag of the packet first
Tag of the packet. and then add outer double Tag according
Use the vlan translation to the interface configurations.
svlan untag cvlan untag Use the vlan translation svlan untag
command to enable the cvlan untag command to enable the
interface to add the outer interface to remove the outer Tag and then
double Tag. Otherwise, the add outer double Tag. Otherwise, the Tag
Tag cannot be removed. cannot be added.
The added Tag is the
SVLAN and CVLAN
encapsulated by the
interface.
Prerequisite
Configure the basic attributes of Layer 3 physical interface, sub-interface, and LAG
interface.
Configure MPLS basic functions.
Configure Tunnel-related functions.
The Tunnel Tag and PW Tag belong to the same Tag domain, they cannot be
configured together.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#interface interface-type Enter Layer 3 physical interface
interface-number configuration mode.
Raisecom(config)#interface interface-type Enter sub-interface configuration mode.
interface-number.subif
Raisecom(config-port)#encapsulation dot1Q Configure the VLAN ID or segment
vlan-id-1 [ to vlan-id-2 ] VLAN ID encapsulated into the ingress
packets on the sub-interface.
That is, the device supports service
extraction based on VLAN ID or VLAN
ID list.
3 Raisecom(config-port)#mode l2 Configure the VPN mode of Layer 3
physical interface to L2VPN.
By default, it is L3VPN.
4 Raisecom(config-port)#mpls static-l2vc Configure the static L2VC by specifying
destination ip-address raw vc-id vc-id in- the incoming label and outgoing label.
label in-label out-label out-label [ tunnel- Configure the encapsulation mode of the
policy policy-name | tunnel tunnel-number ] PW packet to RAW, that is, no VLAN
[ no-control-word ] [ mtu mtu ] [ tpid tpid ] Tag.
[ backup | bypass ]
Raisecom(config-port)#mpls static-l2vc Configure the static L2VC by specifying
destination ip-address [ tagged ] vc-id vc-id the incoming label and outgoing label.
in-label in-label out-label out-label Configure the encapsulation mode of PW
[ tunnel-policy policy-name | tunnel tunnel- packet to Tagged. You can configure the
number ] [ no-control-word ] [ mtu mtu ] VLAN ID of the service provider as
[ tpid tpid ] [ svlan vlan-id ] [ backup | required.
bypass ]
Raisecom(config-port)# mpls static-l2vc Configure static L2VC based on TDM
destination ip-address vc-id vc-id in-label services.
in-label out-label out-label [ tunnel-policy
policy-name | tunnel tunnel-number ]
[ jitter-buffer buffer ] [ tdm-encapsulation
number ] [ rtp-header ]
5 Raisecom(config-port)#interface interface- (Optional) configure the sub-interface
type interface-number configuration mode.
Scenario
VPLS is a L2VPN technology which is based on MPLS and Ethernet technology. VPLS can
provide point-to-multipoint VPN networking topology. VPLS provides a more perfect
solution for carriers, who use point-to-point L2VPN services. In addition, it does not need to
manage internal routing information of users, which is required in L3VPN.
Prerequisite
Enable MPLS basic functions.
Scenario
Virtual Pseudo Wire Service (VPWS) provides end-to-end connection between 2 nodes while
VPLS can realize multipoint-to-multipoint interconnection. By accessing VPWS to VPLS,
you can provide services in the following 2 scenarios:
Point-to-multipoint aggregation access
Dual-homed protection of 2 destination nodes in the VPLS network accessed by the UPE
Prerequisite
Complete VPLS configurations.
Scenario
MPLS L3VPN is a PE-based L3VPN technology for ISP's solutions. It uses the BGP to
release the VPN route and uses MPLS to forward VPN packets in the ISP network.
As shown in Figure 11-1, in MPLS L3 VPN topology, the PE device and CE device exchange
routes through EBGP.
MPLS L3VPN provides a flexible networking mode and is of good expansibility. In addition,
it supports MPLS QoS and MPLS TE well. Therefore, it is applied to increasing larger scales.
Prerequisite
Configure basic attributes, such as Layer 3 physical interface, sub-interface, and link
aggregation interface.
Configure MPLS basic functions.
Configure Tunnel related functions.
11.5 Maintainance
Command Description
Raisecom(config)#clean pw-proxy { arp | ndp } vpn- Clear the learned ARP and NDP
interface interface-type interface-number entries.
Rasiecom#clear ip bgp [ all | ip-address | external ] Reset all or the specified BGP
vrf vrf-name [ as-id ] connections in VRF.
Rasiecom#clear ip bgp [ all | ip-address | external ] Update all or the specified BGP routes
vrf vrf-name [ as-id ] { in | out | soft } in VRF. Do not disconnect BGP
connections, namely, soft reset.
Networking requirements
As shown in Figure 11-2, the user has branches in areas A and B. Branches need to exchange
point-to-point VPN leased-line services. Because the network scale is small and the topology
is stable, you can configure bidirectional static LSP between PE A and PE B to work as the
public Tunnel of the L2VPN. By default, devices are configured with IP addresses.
Configuration steps
Step 1 Configure the static Tunnel. For details, see section 10.8.1 Example for configuring static
bidirectional LSP without IP capability.
Step 2 Configure static L2VC.
Configure PE A.
Configure PE B.
Checking results
Use the show mpls l2vc static command to show static VPWS configurations on PE A and
PE B.
Show static VPWS configurations on PE A.
Vc id : 101
Encapsulation type : raw
Tunnel type : static
Destination : 192.168.4.2
Tunnel policy : --
Tunnel number : 1
Local vc label : 101
Remote vc label : 101
Ac status : UP
Pw state : UP
Vc state : UP
Vc signal : manual
Local cw : enable
Operational cw : enable
Local vc mtu : 9600
Remote vc mtu : --
Tpid : 0x9100
Svlan : --
Pw role : PrimaryPw
Pw work status : Working
Pw access mode : mesh
Pw QosMode : --
Pw Bandwidth Cir : --
Pw Bandwidth Pir : --
Pw Bandwidth Valid : InValid
Pw Weight : --
Pw Flow Queue : --
Pw DsMode : Uniform
Pw PipeServClass : --
Pw Exp2LocalPriMap : 0
Pw LocalPri2ExpMap : 0
Create time : 2000-11-11,14:38:16
Up time : 0 days, 0 hours, 0 minutes, 0 seconds
Last change time : 2000-11-11,14:38:16
Local cw : enable
Operational cw : enable
Local vc mtu : 9600
Remote vc mtu : --
Tpid : 0x9100
Svlan : --
Pw role : PrimaryPw
Pw work status : Working
Pw access mode : mesh
Pw QosMode : --
Pw Bandwidth Cir : --
Pw Bandwidth Pir : --
Pw Bandwidth Valid : InValid
Pw Weight : --
Pw Flow Queue : --
Pw DsMode : Uniform
Pw PipeServClass : --
Pw Exp2LocalPriMap : 0
Pw LocalPri2ExpMap : 0
Create time : 2000-11-11,16:18:27
Up time : 0 days, 0 hours, 0 minutes, 0 seconds
Last change time : 2000-11-11,16:18:27
Networking requirements
As shown in Figure 11-3, the user has branches in areas A and B. Branches need to exchange
point-to-point VPN leased-line services. To facilitate network maintenance and reduce manual
intervention, you can configure the RSVP-TE-based dynamic Tunnel to carry dynamic VPWS
services to meet user's leased-line telecommunication requirements. By default, devices are
configured with IP addresses.
Figure 11-3 Configuring RSVP-TE-based dynamic Tunnel to carry dynamic VPWS services
Configuration steps
Step 1 Configure RSVP-TE-based dynamic Tunnel. For details, see section 10.8.3 Example for
configuring RSVP-TE-based dynamic LSP.
Step 2 Configure dynamic L2VC.
Configure PE A.
Configure PE B.
PEB(config)#interface gigaethernet 1/2/1
PEB(config-gigaethernet 1/2/1)#mode l2
PEB(config-gigaethernet 1/2/1)#mpls l2vc destination 10.1.1.1 raw vc-id 1
tunnel 1 mtu 9600
PEB(config-gigaethernet 1/2/1)#exit
Checking results
Use the show mpls l2vc command to show static VPWS configurations on PE A and PE B.
Show static VPWS configurations on PE A.
Tpid : 0x9100
Svlan : --
Pw role : PrimaryPw
Pw work status : Working
Pw access mode : mesh
Pw QosMode : --
Pw Bandwidth Cir : --
Pw Bandwidth Pir : --
Pw Bandwidth Valid : InValid
Pw Weight : --
Pw Flow Queue : --
Pw DsMode : Uniform
Pw PipeServClass : --
Pw Exp2LocalPriMap : 0
Pw LocalPri2ExpMap : 0
Create time : 2014-07-25,09:58:14
Up time : 0 days, 0 hours, 0 minutes, 0 seconds
Last change time : 2014-07-25,09:58:14
----------------------------------------
Show static VPWS configurations on PE B.
Pw DsMode : Uniform
Pw PipeServClass : --
Pw Exp2LocalPriMap : 0
Pw LocalPri2ExpMap : 0
Create time : 2014-07-25,10:13:17
Up time : 0 days, 0 hours, 0 minutes, 0 seconds
Last change time : 2014-07-25,10:13:17
----------------------------------------
Networking requirements
As shown in Figure 11-4, the headquarter G exchanges leased-line services with branch A
over the IP RAN where end-to-end communication is implemented through multi-section PW
and protection implemented by deploying active/standby Tunnel and active/standby PW. In
this networking topology, the IP RAN device is named based on the network where it resides,
which should be the same with the carrier network name. For example, U1 is the client-side
IPRAN access device. A2 is the network-side access device. And B is the aggregation core
layer device.
Deploy active/standby static PWs between U1-1 and A2-1, and U3 and A2-1.
Deploy active/standby dynamic PWs between A2-1 and B-1, and A2-2 and B-2.
Deploy dynamic PWs between B-1 and B-2, and B-3 and B-4.
Configure static-to-dynamic PW on A2-1 and A2-2 respectively.
Configure dynamic-to-dynamic PW on B-1, B-2, B-3, and B-4.
The configuration process is similar, so this section only takes the configurations of B-
1/B-3 device from the branch side to the core network for example. Configurations for
the headquarter-side devices will not be detailed.
Configuration principle
Configure LSR-ID on U1, A2, and B. Enable MPLS globally. Enable LDP on A2 and B
globally.
Configure the IP address of the service interface and loopback interface planned by U1,
A2, and B.
Configure the active/standby static Tunnel between U1-1 and A2-1 and configure the
active/standby static PW.
Enable OSPF on A2-1, B-1, and B-3. Advertise and learn routes over the entire network.
Enable LDP sessions on A2-1, B-1, and B-3 and establish LDP remote sessions
respectively, preparing for the assignment of PW labels.
Configure active/standby PWs on A2-1, B-1, and B-3 respectively. The labels are
automatically distributed according to LDP.
Configure the static-to-dynamic PW on A2.
Enable BFD and establish PW redundancy protection.
(Optional) configure QoS rate limiting for the PW.
Data preparation
Table 11-3 lists data for configurations.
Configuration steps
Step 1 Configure MPLS globally.
U1-1
A2-1
B-1
B-3
Step 2 Configure the IP address of the planning interface and enable LDP session.
U1-1
U1-1(config)#interface loopback 2
U1-1(config-loopback2)#ip address 1.1.1.1 255.255.255.255
U1-1(config-loopback2)#interface gigaethernet 1/1/1
U1-1(config-gigaethernet1/1/1)#ip address 10.10.1.1 255.255.255.0
U1-1(config-gigaethernet1/1/1)#exit
A2-1
A2-1(config)#interface loopback 2
A2-1(config-loopback2)#ip address 2.2.2.2 255.255.255.255
A2-1(config-loopback2)#interface gigaethernet 1/1/1
A2-1(config-gigaethernet1/1/1)#ip address 10.10.1.2 255.255.255.0
A2-1(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
A2-1(config-gigaethernet1/1/2)#ip address 10.10.2.1 255.255.255.0
A2-1(config-gigaethernet1/1/2)#mpls ldp
A2-1(config-gigaethernet1/1/2)#interface gigaethernet 1/1/3
A2-1(config-gigaethernet1/1/3)#ip address 100.10.1.1 255.255.255.0
A2-1(config-gigaethernet1/1/3)#mpls ldp
/*configure the IP address of the interface on the ring and enable LDP.
B-1
B-1(config)#interface loopback 2
B-1(config-loopback2)#ip address 3.3.3.3 255.255.255.255
B-1(config-loopback2)#interface gigaethernet 1/1/1
B-1(config-gigaethernet1/1/1)#ip address 10.10.2.2 255.255.255.0
B-1(config-gigaethernet1/1/1)#mpls ldp
B-3
B-3(config)#interface loopback 2
B-3(config-loopback2)#ip address 5.5.5.5 255.255.255.255
B-3(config-loopback2)#interface gigaethernet 1/1/1
B-3(config-gigaethernet1/1/1)#ip address 10.10.5.1 255.255.255.0
B-3(config-gigaethernet1/1/1)#mpls ldp
U1-1(config)#router ospf 1
U1-1(config-router-ospf)#network 1.1.1.1 255.255.255.255 area 0
U1-1(config-router-ospf)#network 10.10.1.1 255.255.255.255 area 0
U1-1(config-router-ospf)#exit
A2-1
A2-1(config)#router ospf 1
A2-1(config-router-ospf)#network 2.2.2.2 255.255.255.255 area 0
A2-1(config-router-ospf)#network 10.10.1.2 255.255.255.255 area 0
A2-1(config-router-ospf)#network 10.10.2.1 255.255.255.255 area 0
A2-1(config-router-ospf)#network 100.10.1.1 255.255.255.255 area 0
A2-1(config-router-ospf)#exit
B-1
B-1(config)#router ospf 1
B-1(config-router-ospf)#network 3.3.3.3 255.255.255.255 area 0
B-1(config-router-ospf)#network 10.10.2.2 255.255.255.255 area 0
B-1(config-router-ospf)#exit
B-3
B-3(config)#router ospf 1
B-3(config-router-ospf)#network 5.5.5.5 255.255.255.255 area 0
B-3(config-router-ospf)#network 10.10.5.1 255.255.255.255 area 0
B-3(config-router-ospf)#exit
B-1
B-3
Checking results
After step 4, you can use the show mpls l2vc command to show PW working status.
Tpid : 0x8100
Svlan : --
Pw role : PrimaryPw
Pw work status : Working
Pw access mode : mesh
Pw QosMode : --
Pw Bandwidth Cir : --
Pw Bandwidth Pir : --
Pw Bandwidth Valid : InValid
Pw Weight : --
Pw Flow Queue : --
Pw DsMode : Uniform
Pw PipeServClass : --
Pw Exp2LocalPriMap : Default
Pw LocalPri2ExpMap : Default
Create time : 1970-03-21,12:36:32
Up time : 0 days, 0 hours, 1 minutes, 20 seconds
Last change time : 1970-03-21,12:36:32
----------------------------------------
Client interface : gigaethernet1/2/1.1
Pw index : 3
Vc id : 2
Encapsulation type : raw
Access mode : symmetry
Tunnel type : mplsTe
Destination : 2.2.2.2
Tunnel policy : --
Tunnel number : 1/1/2
Local vc label : 202
Remote vc label : 202
Ac status : up(bfd:up, cc:up)
Pw state : up(bfd:up, cc:up)
Vc state : up
Vc signal : manual
Local cw : enable
Operational cw : enable
Local vc mtu : 9600
Remote vc mtu : --
Tpid : 0x8100
Svlan : --
Pw role : SecondaryPw
Pw work status : NoWorking
Pw access mode : mesh
Pw QosMode : --
Pw Bandwidth Cir : --
Pw Bandwidth Pir : --
Pw Bandwidth Valid : InValid
Pw Weight : --
Pw Flow Queue : --
Pw DsMode : Uniform
Pw PipeServClass : --
Pw Exp2LocalPriMap : Default
Pw LocalPri2ExpMap : Default
Create time : 1970-03-21,12:37:36
Up time : 0 days, 0 hours, 0 minutes, 16 seconds
After step 6, you can use the show mpls ldp targeted neighbour command to check
status of LDP neighbor sessions.
After step 6, you can use the show mpls ldp interface command to show whether
physical layer interface is enabled with LDP.
-------------------------------------------------------------------------
LAM: Label Advertisement Mode IF-Name: Interface name
After step 6, you can use the show mpls ldp session command to show LDP sessions
and the running status.
After step 7, you can use the show mpls switch-l2vc command to show configurations
of PW switching.
---------------------------------------------------------------------
Switch-l2vc type : SVC <---> LDP (BACKUP)
Peer ip address : 1.1.1.1 <---> 3.3.3.3 --
Encapsulation type : raw <---> raw --
Vc id : 2 <---> 15 --
Fault relay : off
Vc state : up <---> up --
Local statuscode : 0x0 <---> 0x0 --
Remote statuscode : 0x0 <---> 0x0 --
Pw state : up <---> up --
Bfd state : up <---> up --
Cc state : up <---> up --
Sd state : up <---> up --
In label : 202 <---> 10248 --
Out label : 202 <---> 10242 --
Local cw : enable <---> enable --
Operational cw : enable <---> enable --
Local vc mtu : 9600 <---> 9600 --
Remote vc mtu : 9600 <---> 9600 --
Tunnel policy : -- <---> -- --
Tunnel number : 1/1/2 <---> -- --
Out xc index : -- <---> 1523 --
Out ecmp index : -- <---> -- --
Pw QosMode : -- <---> -- --
Pw Bandwidth Cir : -- <---> -- --
Pw Bandwidth Pir : -- <---> -- --
Pw Bandwidth Valid : InValid <---> InValid --
Pw Weight : -- <---> -- --
Pw Flow Queue : -- <---> -- --
Work satus : working <---> working --
After all configurations are complete, you can execute the Ping operation based on
MPLS VC to check the connectivity of the L2VPN.
After step 8, you can use the show bfd state command to show BFD status.
Common questions
After a LDP session is configured, it is not Up.
Check whether the network-side interface IP address is correctly configured.
Check whether the OSPF route is enabled and whether routes of the entire network have
been advertised and learned.
Check whether the NNI is enabled with LDP.
Check whether the NNI is up.
After static-to-dynamic PW switching is configured, the PW is not Up.
Check whether the UNI of PE3 is configured with a dynamic PW.
Check whether the UNI of PE3 is Up.
Check whether the binding between the static tunnel and the PW is correct in the PW
switching configuration. That is, the tunnel should be bound to the static PW at the local
end.
Check whether the MTU, Raw/Tag, MTU, TPID, and control word of the two PWs are
the same.
The end-to-end PW cannot be pinged through.
Check whether the configuration of the tunnel parameters is correct and whether the
status is Up.
Check whether LDP is Up.
Check whether the static PW and dynamic PW are up.
Check whether the interface planning is consistent with the network topology.
Check whether the configuration process is correct.
Networking requirements
Figure 11-5 shows a mobile backhaul CE+L3VPN network solution. The base station is
connected to device A which functions as the CE on the service network. CE 1 and CE 2
belong to VPN1, which are accessed to the MPLS L3VPN network through PE 1 and PE 2.
The RT of VPN 1 is 1:100. Different VPN users cannot access each other. Run OSPF between
PE 1 and PE 2 and configure interconnection of public network routes. Configure MP-BGP
between PE 1 and PE 2 for advertising L3VPN private network routes. Configure static routes
between PEs and CEs. This completes the deployment of the mobile backhaul network.
Configuration principle
Configure basic MPLS functions on PE devices and configure VRF.
Configure the IP addresses of the interfaces on PE and CE devices.
After configuring the IP address of the PE client-side interface, bind the VRF to the
client-side interface.
Enable OSPF public network routes between PE 1 and PE 2.
Configure a MPLS static public network tunnel between PE 1 and PE 2.
Enable MP-IBGP routes between PE 1 and PE 2, and enable VPNv4.
Configure a static route between the PE and the CE. Configure the static VRF-based
private network route to the CE on the PE and configure the gateway from the CE to the
PE.
Data preparation
Table 11-4 lists data for configurations.
Configuration steps
Step 1 Configure VRF on PE 1 and PE 2.
PE 1
PE1#config
PE1(config)#ip vrf VPN1
PE1(config-vrf)#rd 100:1
PE1(config-vrf)#route-target import 100:1
PE1(config-vrf)#route-target export 100:1PE1(config-vrf)#exit
PE 2
PE2#config
PE2(config)#ip vrf VPN1
PE2(config-vrf)#rd 100:1
PE2(config-vrf)#route-target import 100:1
PE1(config-vrf)#route-target export 100:1
PE2(config-vrf)#exit
PE 2
PE 2
PE 1
PE1(config)#router ospf 1
PE1(config-router-ospf)#network 10.10.1.0 0.0.0.255 area 0
PE1(config-router-ospf)#network 1.1.1.1 0.0.0.0 area 0
PE1(config-router-ospf)#exit
P
P1(config)#router ospf 1
P1(config-router-ospf)#network 10.10.1.0 0.0.0.255 area 0
P1(config-router-ospf)#network 10.10.3.0 0.0.0.255 area 0
P1(config-router-ospf)#network 2.2.2.2 0.0.0.0 area 0
P1(config-router-ospf)#exit
PE 2
PE2(config)#router ospf 1
PE2(config-router-ospf)#network 10.10.3.0 0 0 0.0.0.255 area 0
PE2(config-router-ospf)#network 4.4.4.4 0.0.0.0 area 0
PE2(config-router-ospf)#exit
Step 6 is for configuring the static public network tunnels. Step 7 is for configuring
dynamic public network tunnels. You can choose one as required.
Step 6 (Optional) configure a static public network tunnel between PE 1 and PE 2.
PE 1
PE 2
PE 2
PE1(config)#router bgp 1
PE1(config-router)#bgp router-id 1.1.1.1
PE1(config-router)#neighbor 4.4.4.4 remote-as 1
/*The ASs at both ends must be the same. If they are the same, the device
is in IBGP routing mode. Otherwise the device is in EBGP mode.*/
PE1(config-router)#neighbor 4.4.4.4 update-source 1.1.1.1
PE1(config-router)#address-family vpnv4
/*Configure a public network neighbor and ensure that the public network
routes are available, that is, the LSR-ID of the peer is reachable. If
there are multiple PE devices, you need to configure multiple public
network neighbors which are irrelevant with IPv4 private network
neighbors.*/
PE1(config-router-af)#neighbor 4.4.4.4 activate
PE1(config-router-af)#neighbor 4.4.4.4 send-community extended
/*You must adopt the extended mode. L3VPN is implemented based on
extended BGP.*/
PE1(config-router-af)#exit-address-family
PE1(config-router)#address-family ipv4 vrf vpn1
/*Configure IPv4 private network neighbors to match VRFs. If there are
multiple VRFs, configure multiple IPv4 neighbors and configure multiple
IPv4 private network neighbors on the peer end. This does not affect
VPNv4 public network neighbors.*/
PE1(config-router-af)#redistribute static
PE1(config-router-af)#redistribute connected
PE1(config-router-af)#exit-address-family
PE1(config-router)#exit
PE 2
PE2(config)#router bgp 1
PE2(config-router)#bgp router-id 4.4.4.4
PE2(config-router)#neighbor 1.1.1.1 remote-as 1
PE2(config-router)#neighbor 1.1.1.1 update-source 4.4.4.4
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#neighbor 1.1.1.1 activate
PE2(config-router-af)#neighbor 1.1.1.1 send-community extended
PE2(config-router-af)#exit-address-family
PE2(config-router)#address-family ipv4 vrf vpn1
PE2(config-router-af)#redistribute static
PE2(config-router-af)#redistribute connected
PE2(config-router-af)#exit-address-family
PE2(config-router)#exit
Step 9 Configure a static route pointing to CE 1 on PE 1 and configure a static route pointing to CE 2
on PE 2.
PE 1
PE 2
CE 2
Checking configurations
Use the show ip vrf detail command to show VRF configurations on PE 1 and PE 2.
PE 1
PE 2
Use the show ip route command to show whether the routes of public network learned
by various PE devices and P devices are correct. Take PE 1 for example.
PE 1
PE1(config)#show ip route
Routing Tables: Default-IP-Routing-Table
-------------------------------------------------------------------------
--
Flag: C - connected, S - static, R - RIP, B - BGP, O - OSPF, I - IS-IS
P - Protocol, s - States, > - selected , * - active, Dis - Distance
Use the show interface tunnel command to show whether Tunnel configurations on PE
1 and PE 2 are correct. Take PE 1 for example.
PE 1
Use the show ip bgp neighbor command to show whether PE 1 and PE 2 have
established BGP neighbors.
Use the show ip bgp vpnv4 all command to check whether PE devices have learned
vpnv4 neighbor.
12 QoS
This chapter describes principles and configuration procedures of QoS, as well as related
configuration examples, including following sections:
Configuring ACL
Configuring priority trust and priority mapping
Configuring traffic classification and traffic policy
Configuring congestion avoidance and queue shaping
Configuring rate limiting
Configuring bandwidth rate limiting
Configuring MPLS QoS CAR
Configuring L3VPN QoS
Configuring MPLS H-QoS
Maintenance
Configuration examples
Scenario
To filter data packets, the device needs to be configured with ACL to identify data packets to
be filtered. Devices allow/disallow related data packets to pass based on pre-configured
policies unless they identify specified data packets.
Prerequisite
N/A
Scenario
For packets from upstream devices, you can select to trust the priorities taken by these packets.
For packets whose priorities are not trusted, you can process them with traffic classification
and traffic policy. In addition, you can modify DSCP priorities by configure interface-based
DSCP priority remarking. After configuring priority trust, the iTN8800 can perform different
operations on packets with different priorities, providing related services.
Before performing queue scheduling, you need to assign a local priority for a packet. For
packets from the upstream device, you can map the outer priorities of these packets to various
local priorities. In addition, you can directly configure local priorities for these packets based
on interfaces. And then device will perform queue scheduling on these packets basing on local
priorities.
In general, for IP packets, you need to configure the mapping between DHCP priority and
local priority. For VLAN packets, you need to configure the mapping between CoS priority
and local priority. For MPLS packets, you need to configure the mapping between the Exp
field and the local priority.
Prerequisite
N/A
Scenario
Traffic classification is the basis of QoS. For packets from upstream devices, you can classify
them according to ACL rules. After traffic classification, the device can provide related
operations for different packets, providing differentiated services.
After configurations, the traffic classification cannot take effect until being bound to traffic
policy. The selection of traffic policy depends on the packet status and current network load
status. In general, when a packet is sent to the network, you need to limit the speed according
to Committed Information Rate (CIR) and remark the packet according to the service feature.
Prerequisite
N/A
Scenario
To prevent network congestion from occurring and to resolve TCP global synchronization,
you can configure congestion avoidance to adjust the network traffic and resolve network
overload. The iTN8800 supports WRED-based congestion avoidance.
When the interface speed of downstream devices is smaller than the one of upstream devices,
congestion avoidance may occur on interfaces of downstream devices. At this time, you can
configure queue and traffic shaping on the egress interface of upstream devices to shape
upstream traffic.
Prerequisite
N/A
Scenario
To avoid/remit network congestion, you can configure interface-based rate limiting. Rate
limiting is used to make packets transmitted at a relative average speed by controlling the
burst traffic on an interface.
Prerequisite
N/A
Scenario
Bandwidth rate limiting is for ensuring users' requirements on service bandwidths and
protecting network resources and interests of carriers.
Prerequisite
N/A
If the hierarchical bandwidth guarantee template is alreardy applied, you will fail to
delete or modify it.
Scenario
The MPLS-TP QoS technology is used to ensure the instantaneity and integrity of services
when the MPLS network is overloaded or congested. In addition, it is used to ensure the
whole MPLS-TP network to run efficiently.
Prerequisite
Connect interfaces and configure physical parameters of interfaces. Make the physical layer
Up.
Scenario
To avoid or remit network congestion, you can configure L3VPN QoS.
Prerequisite
N/A
Scenario
H-QoS is generally used in the conditions which require distinguishing services, users, and
user groups. For example,
User services are divided into voice and internet services. Users are divided into
department manager and employees. User groups are divided into president office and
property management department. All services are accessed to the upper network
through one interface.
Through H-QoS, all services in the president office can be prioritized, all services of the
manager in the president office can be prioritized, and all voice services of the manager
in the president office can be prioritized.
Prerequisite
MPLS QoS CAR and MPLS H-QoS conflict with each other. Make sure that the device is not
configured with MPLS QoS CAR before configuring H-QoS.
12.10 Maintenance
Command Description
Raisecom(config)#clear service-policy statistics Clearing traffic policy statistics.
interface interface-type interface-number { egress |
ingress }
Raisecom(config)#clear service-policy statistics
interface interface-type interface-number { egress |
ingress } policy-map policy-map-name [ class-map class-
map-name ]
Raisecom(config)#clear mls qos queue statistics interface Clear queue statistics of interfaces.
interface-type interface-number [ queueid queue-id ]
Raisecom(config)#clear filter statistics interface Clear ACL statistics.
interface-type interface-number { ingress | egress }
[ access-list acl-number ]
Raisecom(config)# clear mpls te traffic-statistics tunnel Clear LSP statistics.
tunnel-if-num
Raisecom(config)#clear mpls l2vpn pw traffic-statistics Clear PW statistics.
interface-type interface-number [ backup ]
Raisecom(config)#clear mpls vsi traffic-statistics vsi- Clear VPLS statistics.
name [ peer peer-ip-address vc-id vc-id ]
Raisecom(config)#clear vrf traffic-statistics vrf-name Clear L3VPN VRF statistics.
Networking requirements
As shown in Figure 12-1, User A, User B, and User C are respectively connected to the
iTN8800 through Router A, Router B, and Router C.
User A uses voice and video services; User B uses voice, video, and data services; User C
uses video and data services.
According to users' requirements, make the following rules:
For User A, provide 25 Mbit/s bandwidth; configure the burst traffic to 100 KB, and
discard the redundant traffic.
For User B, provide 35 Mbit/s bandwidth; configure the burst traffic to 100 KB, and
discard the redundant traffic.
For User C, provide 30 Mbit/s bandwidth; configure the burst traffic to 100 KB, and
discard the redundant traffic.
Configuration steps
Step 1 Create and configure traffic classification.
Raisecom#config
Raisecom(config)#access-list 1001
Raisecom(config-acl-ipv4-basic)#rule 1 permit 1.1.1.1 255.255.255.0
Raisecom(config-acl-ipv4-basic)#exit
Raisecom(config)#class-map usera
Raisecom(config-cmap)#match acl 1001
Raisecom(config-cmap)#exit
Raisecom(config)#access-list 1002
Raisecom(config-acl-ipv4-basic)#rule 2 permit 1.1.2.1 255.255.255.0
Raisecom(config-acl-ipv4-basic)#exit
Raisecom(config)#class-map userb
Raisecom(config-cmap)#match acl 1002
Raisecom(config-cmap)#exit
Raisecom(config)#access-list 1003
Raisecom(config-acl-ipv4-basic)#rule 3 permit 1.1.3.1 255.255.255.0
Raisecom(config-acl-ipv4-basic)#exit
Raisecom(config)#class-map userc
Raisecom(config-cmap)#match acl 1003
Raisecom(config-cmap)#exit
Step 2 Create traffic policing profiles and configure rate limiting rules.
Raisecom(config)#policy-map usera
Raisecom(config-pmap)#class-map usera
Raisecom(config-pmap-c)#police usera
Raisecom(config-pmap-c)#exit
Raisecom(config-pmap)#exit
Raisecom(config)#interface gigaethernet 1/2/1
Raisecom(config-port)#service-policy ingress usera
Raisecom(config-port)#exit
Raisecom(config)#policy-map userb
Raisecom(config-pmap)#class-map userb
Raisecom(config-pmap-c)# police userb
Raisecom(config-pmap-c)#exit
Raisecom(config-pmap)#exit
Raisecom(config)#interface gigaethernet 1/2/2
Raisecom(config-port)#service-policy ingress userb
Raisecom(config)#policy-map userc
Raisecom(config-pmap)#class-map userc
Raisecom(config-pmap-c)#police userc
Raisecom(config-pmap-c)#exit
Raisecom(config-pmap)#exit
Raisecom(config)#interface gigaethernet 1/2/3
Raisecom(config-port)#service-policy ingress userc
Checking results
Use the show class-map command to show configurations of traffic classification.
Use the show mls qos policer-profile command to show configurations of rate limiting rules.
Use the show policy-map command to show configurations of the traffic policy.
Networking requirements
As shown in Figure 12-2, User A uses voice and video services; User B uses voice, video, and
data services; User C uses video and data services.
CoS priorities for voice, video and, data services are configured to 5, 4, and 2 respectively.
CoS priorities are mapped to local priorities 6, 5, and 2 respectively.
Make the following rules based on service types.
Perform SP scheduling on the voice service to ensure that the traffic is preferentially
transmitted.
Perform WRR scheduling on the video service and configure the weight to 50.
Perform WRR scheduling on the data service and configure the weight to 20. In addition,
you need to configure the discarding threshold to 50 to avoid network congestion caused
by too large instantaneous traffic.
Configuration steps
Step 1 Create a WRED profile.
Raisecom#config
Raisecom(config)#mls qos wred profile 1
Raisecom(wred)#wred start-drop-threshold 50 end-drop-threshold 90 max-
drop-probability 60
Raisecom(wred)#exit
Raisecom(config-port)#exit
Raisecom(config)#interface gigaethernet 1/2/3
Raisecom(config-port)#mls qos trust cos
Raisecom(config-port)#exit
Step 3 Configure the mapping between the CoS priority and local priority.
Checking results
Use the show mls qos mapping cos-to-local-priority command to show mapping
configurations on specified priorities.
Use the show mls qos command to show configurations of priority trust and queue scheduling
mode on specified interfaces.
Use the show mls qos flow-queue command to show configurations of queue scheduling.
Use the show mls qos wred profile command to show configurations of the WRED profile.
Networking requirements
As shown in Figure 12-3, User A, User B, and User C are connected to the iTN8800 through
Switch A, Switch B, and Switch C.
User A uses voice and video services; User B uses voice, video, and data services; User C
uses video and data services.
According to users' requirements, make the following rules:
For User A, provide 25 Mbit/s bandwidth; configure the burst traffic to 100 KB; set the
PIR to 50 Mbit/s, and configure the PBS to 200 KB.
For User B, provide 35 Mbit/s bandwidth; configure the burst traffic to 100 KB; set the
PIR to 70 Mbit/s, and configure the PBS to 200 KB.
For User A, provide 30 Mbit/s bandwidth; configure the burst traffic to 100 KB;
configure the PIR to 60 Mbit/s, and set the PBS to 200 KB.
Configuration steps
Configure interface-based rate limiting.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/1
Raisecom(config-port)#rate-limit ingress cir 25000 cbs 100 pir 50000 pbs
200
Raisecom(config)#interface gigaethernet 1/2/2
Raisecom(config-port)# rate-limit ingress cir 35000 cbs 100 pir 70000 pbs
200
Raisecom(config)#interface gigaethernet 1/2/3
Raisecom(config-port)# rate-limit ingress cir 30000 cbs 100 pir 60000 pbs
200
Checking results
Use the show rate-limit interface command to show configurations of interface-based rate
limiting.
Raisecom#show rate-limit interface
Interface Direction Cir(kbps) Cbs(kB) Pir(kbps) Pbs(kB)
CirOper(kbps) CbsOper(kB) PirOper(kbps) PbsOper(kB)
-------------------------------------------------------------------------
-------------------------------------------------
gigaethernet1/2/1 ingress 25000 100 50000 200 25000
100 50000 200
gigaethernet1/2/2 ingress 35000 100 70000 200 35000
100 70000 200
gigaethernet1/2/3 ingress 30000 100 60000 200 30000
100 60000 200
Networking requirements
As shown in Figure 12-4, User A, User B, and User C are connected to iTN8800 respectively
through the iTN201. The iTN8800 accesses different types of user services through the sub-
interfaces (all sub-interfaces are configured with the IP address, LSP, and so on).
User A requires voice and video services. User B requires voice, video, and data services.
User C requires video and data services. Services of User A, User B, and User C are
aggregated on the iTN8800 in the headquarter.
The headquarter has purchased the leased line services with 150 Mbit/s bandwidth. According
to the service requirements of different users, the following rules are formulated:
The total traffic of User A should not exceed 80 Mbit/s, among which the committed
bandwidth is 50 Mbit/s.
The total traffic of User B should not exceed 50 Mbit/s, among which the committed
bandwidth is 30 Mbit/s.
The total traffic of User C should not exceed 50 Mbit/s, among which the committed
bandwidth is 10 Mbit/s.
The total traffic of User A, User B, and User C together should not exceed 150 Mbit/s.
Once the total traffic of User A, User B, and User C is congested, it is required that the
ratio of the high priority service traffic among User A, User B, and User C should be
5:3:1.
The service priority of all service from high to low is voice, video, and data.
Figure 12-5 shows the priority scheduling of the configuration scheme according to the
above-mentioned networking requirements.
Configuration steps
Step 1 Configure the sub-interface to access different user services and configure the service priority
of the user (distinguish the priority of different services according to weight and traffic queue).
The following configurations are based on accessing User B services.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/2.1
Raisecom(config-gigaethernet1/2/2.1)#mpls l2vc destination 1.1.4.1 tagged
vc-id 1 tunnel-interface 1 svlan 1
Raisecom(config-gigaethernet1/2/2.1)#mpls l2vpn pw bandwidth hqos weight
5 flow-queue 5
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/2.2
Raisecom(config-gigaethernet1/2/2.2)#mpls l2vc destination 1.1.4.1 tagged
vc-id 2 tunnel-interface 1 svlan 1
Raisecom(config-gigaethernet1/2/2.2)#mpls l2vpn pw bandwidth hqos weight
3 flow-queue 12
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/2.3
Raisecom(config-gigaethernet1/2/2.3)#mpls l2vc destination 1.1.4.1 tagged
vc-id 3 tunnel-interface 1 svlan 1
Raisecom(config-gigaethernet1/2/2.3)#mpls l2vpn pw bandwidth hqos weight
1 flow-queue 21
Raisecom#config
Raisecom(config)#interface tunnel 1/2/1
Raisecom(config-tunnel1/2/1)#bandwidth hqos cir 50000 pir 80000 weight 5
Raisecom#config
Raisecom(config)#interface tunnel 1/2/2
Raisecom(config-tunnel1/2/2)#bandwidth hqos cir 30000 pir 50000 weight 3
Raisecom#config
Raisecom(config)#interface tunnel 1/2/3
Raisecom(config-tunnel1/2/3)#bandwidth hqos cir 30000 pir 50000 weight 1
Raisecom#config
Raisecom(config)#interface gigaethernet 1/1/1
Raisecom(config-gigaethernet1/1/1)#rate-limit egress cir 150000 cbs 100
pir 180000 pbs 200
Checking results
Use the show mpls l2vpn pw traffic-statistics command to show PW statistics.
Use the show mpls te traffic-statistics tunnel command to show Tunnel statistics.
Use the show rate-limit interface command to show whether the interface-based
bandwidth limit configurations are correct.
Networking requirements
As shown in Figure 12-6, User B is connected to the iTN8800 through the iTN201. The
iTN8800 accesses voice, video, and data services of User B through its sub-interface
GE1/2/2.1, GE1/2/2.2, and GE1/2/2.3 (these sub-interfaces are configured with the IP address,
LSP, and so on).
User B has purchased the leased line services with a total bandwidth of 20 Mbit/s. According
to the service requirements, the following rules are formulated:
Voice service bandwidth: CIR 500 Kbit/s; video service bandwidth: CIR 4.5 Mbit/s; data
service bandwidth: CIR 5 Mbit/s
The voice service is of the highest priority, followed by the video services, and the data
services.
The idle bandwidth is shared by the three services. Services which have exceeded PIR
will be dropped.
Configuration steps
Step 1 Configure the sub-interface to access different user services and configure the bandwidth limit
and priority for the services.
Configure accessing the highest-priority voice services.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/2.1
Raisecom(config-gigaethernet1/2/2.1)#mpls l2vc destination 1.1.4.1 tagged
vc-id 1 tunnel-interface 1 svlan 1
Raisecom(config-gigaethernet1/2/2.1)#mpls l2vpn pw bandwidth car cir 500
pir 10500
Raisecom(config-gigaethernet1/2/2.1)#mpls l2vpn pw diffserv-mode pipe 5
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/2.2
Raisecom(config-gigaethernet1/2/2.2)#mpls l2vc destination 1.1.4.1 tagged
vc-id 2 tunnel-interface 1 svlan 1
Raisecom(config-gigaethernet1/2/2.2)#mpls l2vpn pw bandwidth car cir 4500
pir 14500
Raisecom(config-gigaethernet1/2/2.2)#mpls l2vpn pw diffserv-mode pipe 3
Raisecom#config
Raisecom(config)#interface gigaethernet 1/2/2.3
Raisecom(config-gigaethernet1/2/2.3)#mpls l2vc destination 1.1.4.1 tagged
vc-id 3 tunnel-interface 1 svlan 1
Raisecom(config-gigaethernet1/2/2.3)#mpls l2vpn pw bandwidth car cir 5000
pir 15000
Raisecom(config-gigaethernet1/2/2.3)#mpls l2vpn pw diffserv-mode pipe 1
Step 2 Configure limit on the total bandwidth of User B, namely, Tunnel bandwidth limit.
Raisecom#config
Raisecom(config)#interface tunnel 1/2/2
Raisecom(config-tunnel1/2/2)#bandwidth car cir 10000 pir 20000
Checking results
Use the show mpls l2vpn pw traffic-statistics command to show PW statistics.
Use the show mpls te traffic-statistics tunnel command to show Tunnel statistics.
When sending 10 Mbit/s voice services, 10 Mbit/s video services, and 10 Mbit/s data services
during a test, the user obtained the practical bandwidth, as shown in Table 12-1.
Table 12-1 Bandwidth statistics in the case of MPLS QoS CAR configurations
Service type Voice service Video service Data service Total
Configured 500 kbit/s 4.5 Mbit/s 5 Mbit/s 10 M (PIR
bandwidth CIR is 20
Mbit/s)
Sent bandwidth 10 Mbit/s 10 Mbit/s 10 Mbit/s 30 Mbit/s
Actual bandwidth 10 Mbit/s 5 Mbit/s 5 Mbit/s 20 Mbit/s
The CIR bandwidth (10 Mbit/s in total) of the three services is met first. The amount
of bandwidth of the three services which has exceeded the CIR is 9.5 Mbit/s, 5.5
Mbit/s, and 5 Mbit/s. According to the service priority, 9.5 Mbit/s bandwidth will be
assigned to voice services first, and the left 0.5 Mbit/s will be assigned to the video
services. There is no extra bandwidth for the data services. Therefore, transmitted
traffic is 10 Mbit/s for voice services, 5 Mbit/s for video services, and 5 Mbit/s for data
services.
13 OAM
This chapter describes principles and configuration procedures of OAM, as well as related
configuration examples, including following sections:
Configuring EFM
Configuring CFM
Configuring MPLS-TP OAM
Configuring BFD
Configuring SLA
Configuring Y.1564
Configuring link quality alarm
Maintenance
Configuration examples
Scenario
Deploying EFM between directly-connected devices can effectively improve the management
and maintenance capability of Ethernet links and ensure network running smoothly.
Prerequisite
Connect interfaces and configure physical parameters of interfaces. Make the physical layer
Up.
EFM active functions can be configured when the iTN8800 is in active mode.
By getting the current variable values of the peer, you can get current link status.
IEEE 802.3 Clause 30 defines and explains supported variables and their denotation
gotten by OAM in details. The variable takes Object as the maximum unit. Each
object contains Package and Attribute. A package contains several attributes.
Attribute is the minimum unit of a variable. When an OAM variable is obtained, object,
package, branch, and leaf description of attributes are defined by Clause 30 to
describe requesting object, and the branch and leaf are followed by variable to
denote object responds variable request. The iTN8800 supports getting OAM
information and interface statistics.
Peer variable cannot be obtained unless EFM connection is established.
Step Command Description
1 Raisecom#show oam peer oam-info [ gigaethernet interface- Show OAM basic
number ] information about the
Raisecom#show oam peer [ gigaethernet interface-number ] peer device.
The peer EFM remote loopback will not take effect until the remote loopback
response is configured on the local device.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#interface Enter GE interface configuration mode.
gigaethernet interface-number
3 Raisecom(config)#oam loopback Configure the interface to ignore/respond to EFM remote
{ ignore | process } loopback sent by the peer device.
By default, the Layer 2 physical interface ignores EFM
remote loopback.
OAM link monitoring is used to detect and report link errors in different conditions.
When detecting a fault on a link, the iTN8800 provides the peer with the generated
time, window, and threshold, etc. by OAM event notification packets. The peer
receives event notification and reports it to the NView NNM system through SNMP
Trap. Besides, the local device can directly report events to the NView NNM system
through SNMP Trap.
By default, the system sets default value for error generated time, window, and
threshold.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#interface Enter GE interface configuration mode.
gigaethernet interface-number
3 Raisecom(config-port)#oam Configure the monitor window and threshold for an error
errored-frame window frame event.
framewindow threshold
framethreshold By default, the monitor window is 1s and the threshold is 1
error frame.
4 Raisecom(config-port)#oam Configure the monitor window and threshold for an error
errored-frame-period window frame period event.
frameperiodwindow threshold
frameperiodthreshold By default, the monitor window is 1000ms and the threshold
is 1 error frame.
5 Raisecom(config-port)#oam Configure the monitor window and threshold for an error
errored-frame-seconds window frame seconds event.
framesecswindow threshold
framesecsthreshold By default, the monitor window is 60s and the threshold is
1s.
6 Raisecom(config-port)#oam Configure the monitor window and threshold for an error
errored-symbol-period window symbol event.
symperiodwindow threshold
symperiodthreshold By default, the monitor window is 1s and the threshold is 1
error frame.
After entering remote configuration mode, you can show the command list supported
by the remote device by using the list command. Then you can manage the remote
device by using those commands. For example:
Use the snmp-server community command to configure the network management
for the remote device.
Use the switch-mode dot1q-vlan native-vlan command to configure VLAN for the
remote device.
Use the reboot command to reboot the remote device.
Use the erase command to delete configuration files from the remote device.
There are multiple commands available for you to monitor and manage the remote
device through extended OAM. They are not listed here one by one, and you can use
them as required. Using some commands remotely on the remote device has the
same effect as using these commands locally on the remote device.
Scenario
To expand application of Ethernet technologies at a Telecom-grade network, the Ethernet
must ensure the same QoS as the Telecom-grade transport network. CFM solves this problem
by providing overall OAM tools for the Telecom-grade Ethernet.
CFM can provide following OAM functions:
Prerequisite
Connect interfaces and configure physical parameters of the interfaces. Make the
physical layer Up.
Create a VLAN.
Add interfaces to the VLAN.
CFM fault detection and CFM fault location functions cannot take effect until the
CFM is enabled.
To enable CFM on an interface, you need to enable global CFM in global
configuration mode and then enable CFM on the interface.
When global CFM is disabled, it does not affect enabling/disabling EFM on the
interface.
Ethernet LM cannot take effect unless CFM is enabled on the ingress interface of
the service packet and MEP-related interfaces.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#ethernet cfm enable Enable global CFM.
By default, it is disabled.
3 Raisecom(config)#interface gigaethernet Enter GE interface configuration mode.
interface-number
CFM concurrently.
If the MD name is specified, it must be globally
unique.
Levels of different MDs must be different.
Raisecom(config-service)#service
remote-mep mep-list remote-mac mac- 802.1ag down MEP needs to manually add
address [ interface-type interface- the remote MEP and specify the interface. It
number ] fails to find the remote MEP automatically.
8 Raisecom(config-service)#service (Optional) configure remote MEP learning. Add
remote-mep learning active dynamically learned remote MEPs to the static
remote MEP list.
9 Raisecom(config-service)#service Enable alarm inhibition.
suppress-alarms enable mep { mep-
list | all } By default, it is enabled.
Before executing this command, ensure that global CFM is enabled. Otherwise,
the Ping operation fails.
If there is no MEP in a service instance, Ping operation will fail because of failing
to find source MEP.
Ping operation will fail if the specified source MEP is invalid. For example, the
specified source MEP does not exist or CFM is disabled on the interface where
the specified source MEP is.
Ping operation will fail if the Ping operation is performed based on specified
destination MEP ID and the MAC address of destination is not found based on
MEP ID.
Ping operation will fail if other users are using the specified source MEP to
perform Ping operation.
If the service instance associates with the emulated Ethernet PW, when LB is
performed, you need to enable global CFM and Ethernet CFM on the AC-side
interface.
Before executing this command, ensure that global CFM is enabled. Otherwise,
the Traceroute operation fails.
If there is no MEP in a service instance, Traceroute operation will fail because of
failing to find source MEP.
Traceroute operation will fail if the specified source MEP is invalid. For example,
the specified source MEP does not exist or CFM is disabled on the interface
where the specified source MEP is.
Traceroute operation will fail if the Ping operation is performed based on specified
destination MEP ID and the MAC address of destination is not found based on
MEP ID.
If the CC feature is invalid, you can ensure Layer 2 Traceroute operation works
normally by configuring static RMEP and specifying MAC address.
Traceroute operation will fail if other users are using the specified source MEP to
perform Traceroute operation.
4 Raisecom(config-service)#service Configure the level for sending the LCK packet. The level
lck level md-level [ vlan vlan- must be higher than the service instance level.
id ]
By default, the level of the MIP is used, which is higher
than the MEP level, to send the LCK packet.
5 Raisecom(config-service)#s (Optional) configure the LCK packet delivery period.
service lck period { 1 | 60 }
By default, it is 1s.
6 Raisecom(config-service)#service Configure the MEP to send the LCK packet.
lck start mep { mep-list | all }
By default, the MEP does not send the LCK packet.
Scenario
To extend the application of MPLS-TP technology in telecom network, the MPLS-TP network
needs to achieve the same service level as the telecom transport network does. Connectivity
Fault Management (CFM) helps the MPLS-TP network to resolve the problem by providing
complete OAM tools.
CFM can provide the following OAM functions for the MPLS-TP network:
Fault detection (Continuity Check, CC)
Fault acknowledgement (LoopBack, LB)
Fault location (LinkTrace, LT)
Alarm Indication Signal (AIS)
Client Signal Fail (CSF)
Lock (LCK)
Packet Delay and Packet Delay Variation Measurements (DM)
Frame Loss Measurements (LM)
The principle of MPLS-TP OAM is similar to the one of Ethernet-based OAM. Only the
carrying modes of related packets are different.
To ensure that users can get quality network services, the carrier and users sign a Service
Level Agreement (SLA). To effectively fulfill the SLA, the carrier needs to deploy the SLA
feature on the device to measure the network performance and takes the measurement result
as the basis for ensuring the network performance.
SLA selects 2 detection points, configures, and schedules the SLA operation on one detection
point to detect the network performance between the 2 detection points.
The SLA feature counts the round-trip packet loss ratio, round-trip/unidirectional (SD/DS)
delay, jitter, jitter variance, and jitter distribution and reports them to the upper monitoring
software (such as the NView NNM system). Then the upper monitoring software analyses the
network performance to get a data meeting users' requirements.
Prerequisite
Connect the interface and configure physical parameters of the interface. Make the
physical layer Up.
Configure MPLS basic functions.
Before configuring SLA, deploy CFM between devices that need to detect the network
performance.
Before enabling CFM packet delivery, associate the service instance with the static
L2VC.
If no MEP is configured for the service instance, the Ping operation will fail
because no source MEP is found.
The Ping operation will fail if the specified source MEP is invalid. For example, the
specified source MEP does not exist or CFM is disabled on the interface where
the specified source MEP is.
The Ping operation will fail if another user is using the specified source MEP to
initiate the Ping operation.
If no MEP is configured for the service instance, the Traceroute operation will fail
because no source MEP is found.
The Traceroute operation will fail if the specified source MEP is invalid. For
example, the specified source MEP does not exist or CFM is disabled on the
interface where the specified source MEP is.
The Traceroute operation will fail if another user is using the specified source MEP
to initiate the Traceroute operation.
Scenario
To reduce effect of faults on the device and improve network availability, the iTN8800 needs
to detect communication faults with adjacent devices. Therefore, it can take actions
immediately to ensure service being transmitted properly.
BFD is a one-way detection. Therefore, both the local device and the peer device should be
enabled with BFD. Otherwise, detection will fail.
Prerequisite
The DUT is configured with an IP address and routes between all devices are reachable.
address.
3 Raisecom(config)#bfd session-id bind peer-ip Create BFD session detection, bind a
default-ip interface interface-type Layer 2 physical interface or Layer 2
interface-number LAG interface, and enter BFD session
mode.
4 Raisecom(config)#bfd session-id bind peer-ip Create static BFD session detection, bind
ip-address interface interface-type Layer 3 physical interface, sub-interface,
interface-number VLAN interface or Layer 3 LAG
interface, and enter BFD session mode.
5 Raisecom(config)#bfd session-id bind peer-ip Create BFD session detection VRF, and
ip-address vrf-name vrf-name enter BFD session mode.
6 Raisecom(config)#bfd session-id bind ldp-lsp Create BFD session detection LDP LSP
peer-ip ip-address ip-mask link, and enter BDF session mode.
7 Raisecom(config)#bfd session-id bind mpls Create BFD session detection CR-LSP
interface tunnel tunnel-if cr-lsp and enter BFD session mode.
Raisecom(config)#bfd session-id bind peer-ip Configure single-hop IP detection.
ip-address interface interface-type
interface-number Use together with BFD CR-LSP.
Otherwise, detection will fail.
Scenario
To provide users with qualified network services, the carrier signs a SLA with users. To carry
out SLA effectively, the ISP needs to deploy SLA feature on devices to measure the network
performance, taking the measured results as an evidence for ensuring the network
performance.
By selecting two detection points (source and destination iTN8800 devices), SLA configures
and schedules SLA operations on a detection point. Therefore, network performance between
these 2 detection points can be detected.
SLA takes statistics on round-trip packet loss ratio, round-trip/unidirectional (SD/DS) delay,
jitter, throughput, and LM packet loss ratio test. In addition, it reports these data to the upper
monitoring software (such as the NView NNM system) to help analyze network performance
for getting an expected result.
Prerequisite
When you configure Layer 2 tests, deploy CFM between local and remote devices that
need to be detected. Layer 2 Ping operation succeeds between local and remote devices.
When you configure Layer 3 tests (icmp-echo and icmp-jitter), Layer 3 Ping operation
succeeds between local and remote devices.
After configuring one operation (differed by operation ID), you cannot modify or
configure it again. You need to delete the operation in advance if you need to
configure it again.
SLA supports scheduling up to 16 operations at one time. Before you stop
scheduling the same operation, you cannot modify scheduling information or re-
schedule the operation. If you need to reschedule the operation, you need to finish
the scheduling (reach scheduling life time or stop scheduling) before performing
the next scheduling.
When configuring LSP-based SLA operation, note the name of lsp-ingress (LSP
Ingress node) is the one of the LSP Ingress node for creating the LSP and the
name of the LSP Egress node is the one of the LSP Egress node for creating the
LSP.
The operation lifetime should not be shorter than the interval for scheduling the
SLA operation.
The interval for scheduling the SLA operation should not be shorter than 20s.
In the MPLS network environment, both the initiating end and the loopback end of the
Y.1564 test are PE devices, which are responsible for encapsulating and
decapsulating Y.1564 test packets. The test process is as below:
The initiating PE encapsulates the Y.1564 test packet into a PW packet and
forwards it to the loopback PE in the MPLS network.
After receiving the PW packet, the loopback PE decapsulates the packet and
restores it to the Y.1564 test packet.
After the Y.1564 test packet exchanges source and destination IP addresses, and
source and destination MAC addresses at the loopback PE, it is encapsulated as
a PW packet again.
The PW packet is forwarded to the initiating PE through the MPLS network,
decapsulated, and restored to the Y.1564 test packet.
The initiating PE collects and processes the test packets and completes the
Y.1564 test.
Raisecom Proprietary and Confidential
323
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 13 OAM
Scenario
By enabling link quality alarm, you can test the transmission error code rate on the interface.
When the error code rate reaches the preconfigured threshold, it will trigger the link status
alarm, thus monitoring the link quality.
Prerequisite
N/A
3 Raisecom(config-port)#link-quality low bit- Configure the error code rate threshold for
error-threshold error-ratio bit-error- triggering link quality alarm and the error
confficient bit-error-power resume-ratio code rate threshold for recovering the link
bit-error-confficient bit-error-power quality.
4 Raisecom(config-port)#bit-error test enable Configure the link quality detection
[ interval interval-value ] [ window window- algorithm and enable detection.
value ] [ period period-value ]
13.8 Maintenance
Command Description
Networking requirements
As shown in Figure 13-1, the Gigaethernet 1/5/1.10 on iTN A and the Gigaethernet 1/5/1 on
iTNB are directly connected through Switch E and Switch F, which is for emulating fault
nodes and detecting BFD alarm. Configure BFD for sub-interface detection on the iTN A and
iTN B.
Configuration steps
The configuration steps of iTN A and iTN B are the same, take iTNA for example.
When configuring the BFD session ID, configure the local end and remote end with
the same ID.
Step 2 Configure the sub-interface to encapsulate the VLAN and IP address. Then iTN A and iTN B
can ping through each other.
Raisecom#hostname iTNA
iTNA#config
iTNA(config)#interface gigaethernet 1/5/1.10
iTNA(config-gigaethernet 1/5/1.10)#encapsulation dot1Q 10
iTNA(config-gigaethernet 1/5/1.10)#ip address 1.1.1.1
iTNA(config-gigaethernet 1/5/1.10)#exit
Step 3 Configure BFD for sub-interface directly-connected single hop detection without configuring
the default value of the parameter.
Checking results
After configuring the IP address of the sub-interface, use the show ip route command to
show the route learning status.
iTNA#show ip route
Routing Tables: Default-IP-Routing-Table
-------------------------------------------------------------------------
Flag: C - connected, S - static, R - RIP, B - BGP, O - OSPF, I - IS-IS
P - Protocol, s - States, > - selected , * - active, Dis - Distance
After configuring BFD for sub-interface, use the show bfd config command to show
BFD configurations.
Disconnect the link between Switch E and Switch F to create a fault. Use the show bfd
state command to show BFD status.
Networking requirements
As shown in Figure 13-2, sub-interface Gigaethernet 1/5/1.10 on iTN A and sub-interface
Gigaethernet 1/5/1 on iTNB are directly connected through Switch E and Switch F which are
for emulating fault nodes and detecting BFD alarm. Configure BFD for IP single-hop
detection on the iTN A and iTN B respectively.
Configuration steps
When configuring the BFD session ID, configure the local end and remote end with
the same ID.
Step 2 Configure the sub-interface to encapsulate the VLAN and IP address. Then iTN A and iTN B
can ping through each other.
iTN A
iTNA#config
iTNA(config)#interface gigaethernet 1/5/1.10
iTNA(config-gigaethernet 1/5/1.10)#encapsulation dot1Q 10
iTNA(config-gigaethernet 1/5/1.10)#ip address 1.1.1.1
iTNA(config-gigaethernet 1/5/1.10)#exit
iTN B
iTNB#config
iTNB(config)#interface gigaethernet 1/5/1.10
iTNB(config-gigaethernet 1/5/1.10)#encapsulation dot1Q 10
iTNB(config-gigaethernet 1/5/1.10)#ip address 1.1.1.2
iTNB(config-gigaethernet 1/5/1.10)#exit
Step 3 Configure BFD for IP single-hop detection without configuring the default value of the
parameter.
iTN A
iTN B
Checking results
After configuring the IP address of the sub-interface, use the show ip route command to
show the route learning status.
iTNA#show ip route
Routing Tables: Default-IP-Routing-Table
-------------------------------------------------------------------------
Flag: C - connected, S - static, R - RIP, B - BGP, O - OSPF, I - IS-IS
P - Protocol, s - States, > - selected , * - active, Dis - Distance
After configuring BFD for IP, use the show bfd config command to show BFD
configurations.
Disconnect the link between Switch E and Switch F to create a fault. Use the show bfd
state command to show BFD status.
Network requirements
As shown in Figure 13-3, iTN A and iTN B access user services through their respective GE
1/2/1.10 interfaces. User services are transmitted to the peer through the PW links deployed
on iTN devices. To detect the connectivity of PW links between iTN devices, enable BFD for
PW on iTN A and iTN B to detect the status of the PW link. Once a fault is detected, an alarm
will be reported.
Configuration principle
Configure the IP address of the device interface.
Configure basic MPLS functions, such as LSP and PW.
Configure BFD for PW detection.
Data preparation
Table 13-1 lists data needed for BFD for PW detection.
Configuration steps
Step 1 Configure the IP address of the device interface. Take iTN A for example. Configuration
steps for iTN B are similar.
iTN A
iTNA#config
iTNA(config)#interface Loopback 2
iTNA(config-Loopback2)#ip address 1.1.1.1 255.255.255.255
iTNA(config-Loopback2)#interface gigaethernet 1/1/1.10
iTNA(config-gigaethernet1/1/1.10)#encapsulation dot1Q 10
iTNA(config-gigaethernet1/1/1.10)#ip address 10.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/1/1.10)#interface gigaethernet 1/2/1.10
iTNA(config-gigaethernet1/2/1.10)#encapsulation dot1Q 10
iTNA(config-gigaethernet1/2/1.10)#ip address 20.10.10.1 255.255.255.0
iTNA(config-gigaethernet1/2/1.10)#exit
iTNA(config-tunnel1/1/1)#destination 2.2.2.2
iTNA(config-tunnel1/1/1)#mpls tunnel-id 1
iTNA(config-tunnel1/1/1)#mpls te commit
iTNA(config-tunnel1/1/1)#exit
iTNA(config)#mpls bidirectional static-lsp ingress lspAB lsr-id 2.2.2.2
tunnel-id 1
iTNA(config-ingress-lsp)#forward 2.2.2.2 255.255.255.255 nexthop
10.10.10.2 gigaethernet 1/1/1.10 out-label 10
iTNA(config-ingress-lsp)#backward in-label 20
iTNA(config-ingress-lsp)#exit
iTNA(config)#interface gigaethernet 1/2/1.10
iTNA(config-gigaethernet1/2/1.10)#encapsulation dot1Q 10
iTNA(config-gigaethernet1/2/1.10)#mode l2
iTNA(config-gigaethernet1/2/1.10)#mpls static-l2vc destination 2.2.2.2
tagged vc-id 1 in-label 101 out-label 101 tunnel 1/1/1 mtu 9600
iTNA(config-gigaethernet1/2/1.10)#exit
iTN B
iTN B
Checking results
After completing configurations, use the show bfd config command to check the
configuration results.
Networking requirements
As shown in Figure 13-4, configure the Y.1564 test type on the iTN A device, create test
services and configure test packet attributes to perform configuration test and performance
test on the target network. Configure loopback on the iTN B to loop the data flow to iTN A for
analysis. The AC-side interface of the iTN A is GE 1/2/1.10, and the AC-side interface of the
iTN B is GE 1/2/1.10, which are used to access user services. Configure Tunnel and PW on
iTN A and iTN B respectively to carry user services for transmission over the IP RAN
network.
Configuration principle
Configure basic MPLS functions, such as LSP, tunnel, and PW on iTN A and iTN B.
Configure the Y.1564 test on iTN A.
Configure loopback on iTN B.
Schedule the Y.1564 test.
Data preparation
Table 13-2 lists data needed for Y.1564 test.
Configuration steps
Step 1 Refer to Table 13-2. Configure the IP addresses of interfaces on iTN A and iTN B.
For details, refer to section 3.1 Basic configurations of interface.
Step 2 Configure OSPF routing.
iTN A
iTN B
Step 3 Configure basic MPLS functions on iTN A and iTN B, such as LSP and PW.
iTN A
iTNA(config-gigaethernet1/2/1.10)#exit
iTN B
Step 5 Configure internal loopback on the AC-side interface (PW service extraction interface) on
iTNB, looping data flow back to iTN A.
Checking results
After step 1, use the show mpls bidirection static-lsp command to show LSP
configuration results.
iTNA(config)#show mpls bidirectional static-lsp
LSP-Index: 1
LSP-Name: lspab
LSR-Role: Ingress
LSP-Flag: Working
Ingress-Lsr-Id: 1.1.1.1
Egress-Lsr-Id: 2.2.2.2
Tunnel-Id: 1
LSP Status: Up
/*LSP is UP.*/
Forward Destination: 2.2.2.2
Forward In-Label: --
Forward Out-Label: 10
Forward In-Interface: --
Forward Out-Interface: gigaethernet1/1/1.10
Forward Next-Hop: 10.10.10.2
Forward Next-Mac: --
Forward Vlan-Id: --
Forward XcIndex: 1
Forward Ds mode: Uniform
Forward PipeServClass: --
Forward Exp2LocalPriMap: Default
Forward LocalPri2ExpMap: Default
Backward Destination: --
Backward In-Label: 20
Backward Out-Label: --
Backward In-Interface: all interfaces
Backward Out-Interface: --
Backward Next-Hop: --
Backward Next-Mac: --
Backward Vlan-Id: --
Backward XcIndex: 2
Backward Ds mode: Uniform
Backward PipeServClass: --
Backward Exp2LocalPriMap: Default
Backward LocalPri2ExpMap: Default
After step 1, use the show mpls l2vc command to show PW configuration results.
Use the ping mpls vc-id destination command to check whether PW path is well
connected.
After configurations are complete, you can use the show sla group-id configuration
command to check configuration results of performance test.
After configurations are complete, use the show sla configuration command to show
configuration results of the throughput test.
Use the show sla group-id result command to show performance test results.
Use the show sla result command to show throughput test results.
14 Security
This chapter describes principles and configuration procedures of security, as well as related
configuration examples, including following sections:
Configuring storm control
Configuring CPU protection
Configuring memory monitoring
Configuring CPU monitoring
Configuring RADIUS
Configuring TACACS+
Configuring dot.1x
Configuring interface isolation
Configuring port mirroring
Configuring URPF
Maintenance
Configuration examples
Scenario
In the Layer 2 network, after storm control is configured, it can inhabit generation of
broadcast storm, when unknown multicast, unknown unicast, and broadcast packets increase,
to ensure forwarding normal packets.
Prerequisite
Configure physical parameters on an interface and make the physical layer Up.
value = 0
When storm control is enabled, you can configure rate limiting. However,
configurations cannot take effect. When storm control is disabled, rate limiting
configurations take effect automatically.
Scenario
When the device receives a great number of attack packets in a short period, the CPU will run
with full load and the CPU utilization rate reaches to 100%. This will cause the normal
functions of the device to fail. CPU CAR helps to efficiently limit the speed of packets, which
enters the CPU.
Prerequisite
N/A
Scenario
This feature enables you to monitor the memory utilization of the system in real time and
configure memory utilization crossing threshold alarms, thus facilitating fault location and
clearance in time or assist NMS personnel in locating faults.
Prerequisite
To output memory utilization alarms as Trap, you must configure the IP address of the target
server for outputting Trap, namely, the IP address of the NMS server.
Scenario
CPU monitoring is used to monitor task status, CPU utilization rate, and stack usage in real
time. It provides CPU utilization threshold alarm to facilitate discovering and eliminating a
hidden danger, helping the administrator locate the fault quickly.
Prerequisite
To output CPU monitoring alarms in a Trap form. You need to configure the IP address of
Trap target host on the iTN8800, that is, the IP address of the NView NNM system.
Scenario
To control users accessing devices and network, you can deploy the RADIUS server at the
network to authenticate and account users. The iTN8800 can be used as a Proxy of the
RADIUS server to authenticate users based on results returned by the RADIUS server.
Prerequisite
N/A
Scenario
To control users accessing devices and network, you can deploy the RADIUS server on the
network to authenticate and account users. Compared with RADIUS, TACACS+ is more
secure and reliable. The iTN8800 can be used as a Proxy of the TACACS+ server to
authenticate users based on results returned by the TACACS+ server.
Prerequisite
N/A
Scenario
The network space of the Wi-Fi LAN features openness and mobility of terminals. It is not
like the wired LAN in which you can determine whether the terminals belong to the network
through physical network space. Therefore, how to prevent illegal access through interface
authentication challenges the Wi-Fi network. However, IEEE 802.1X can solve this problem.
Scenario
To isolate Layer 2 data of interfaces in a VLAN and provide physical isolation between
interfaces, you need to configure interface isolation.
By adding interfaces that need to be controlled to a VLAN protection group, you can enhance
network security and provide flexible networking scheme for users.
Interface isolation helps isolate interfaces in a VLAN, enhance network security, and provide
flexible networking schemes.
Prerequisite
N/A
Scenario
Port mirroring refers to mirroring packets of the specified mirroring port to the destination
port or aggregation group without affecting packet forwarding. With port mirroring, users can
monitor transmitting and receiving status of one or more interfaces for analyzing network
status.
Prerequisite
N/A
Scenario
You can enable Unicast Reverse Path Forwarding (URPF) on the routing interface to avoid
network attacks which are based on source address spoofing. After it is enabled, the interface
will legally check the source address of the packet upon receiving the packet. If the packet
passes the legal check, the interface will match it with the forwarding table and then forward
it, otherwise, it will be discarded.
Prerequisite
N/A
14.11 Maintenance
Command Description
Raisecom(config)#clear cpu-protect car statistics Clear global CPU CAR statistics or CPU
[ interface-type interface-number ] CAR statistics of specified interfaces.
Raisecom(config)#clear dot1x interface-type Clear dot.1x statistics of the specified
interface-number statistics interface.
Networking requirements
As shown in Figure 14-1, to control the influence of the broadcast storm on iTN A, you need
to deploy storm control on iTN A to control broadcast and unknown unicast packets. The
storm control threshold is configured to 2000 pps.
Configuration steps
Configure storm control on iTN A.
Raisecom#config
Raisecom(config)#interface gigaethernet 1/1/1
Raisecom(config-port)#storm-control broadcast enable
Raisecom(config-port)#exit
Raisecom(config)#interface gigaethernet 1/1/2
Raisecom(config-port)#storm-control broadcast enable
Raisecom(config-port)#exit
Raisecom(config)#storm-control pps 2000
Actual Storm control pps: 2000 pps
Checking results
Use the show storm-control interface command to show storm control configurations.
Networking requirements
As shown in Figure 14-2, to control users accessing iTN A, you need to deploy RADIUS
authentication and accounting features on iTN A to authenticate users logging in to iTN A and
record their operations.
Configure the interval for sending accounting update packet to 2min. Configure the
processing policy for accounting failure to offline.
Configuration steps
Step 1 Authenticate login users through RADIUS.
Raisecom#radius 192.168.1.1
Raisecom#radius-key raisecom
Raisecom#user login radius-user
Checking results
Use the show radius-server command to show RADIUS configurations.
Raisecom#show radius-server
Authentication server IP: 192.168.1.1 port:1812
Backup authentication server IP:0.0.0.0 port:1812
Authentication server key: raisecom
Accounting server IP: 192.168.1.1 port:1813
Backup accounting server IP: 0.0.0.0 port:1813
Accounting server key: raisecom
Accounting login: enable
Update interval(min.): 120
Accounting fail policy: offline
Networking requirements
As shown in Figure 14-3, to control users accessing iTN A, you need to deploy TACACS+
authentication on iTN A to authenticate users logging in to iTN A.
Configuration steps
Authenticate login users through TACACS+.
Raisecom#tacacs-server 192.168.1.1
Raisecom#tacacs-serverkey raisecom
Raisecom#user login tacacs-user
Checking results
Use the show tacacs-server command to show TACACS+ configurations.
Raisecom#show tacacs-server
Server Address: 192.168.1.1
Backup Server Address: --
Sever Shared Key: raisecom
Accounting server Address: --
Backup Accounting server Address: --
Total Packet Sent: 0
Total Packet Recv: 0
Num of Error Packets: 0
15 Reliability
This chapter describes principles and configuration procedures of network reliability, as well
as related configuration examples, including following sections:
Configuring link aggregation
Configuring interface backup
Configuring ELPS
Configuring ERPS
Configuring PW redundancy protection
Configuring MPLS linear protection switching
Configuring PW dual-homed protection switching
Configuring VPN FRR
Configuring HA hot backup
Configuring VRRP
Configuring PRBS test
Maintenance
Configuration examples
Scenario
When greater bandwidth and high reliability are needed for network links, you can configure
manual or static LACP link aggregation.
Link aggregation aggregates multiple physical Ethernet interfaces into a logical link to
provide load sharing of uplink and downlink traffic among member interfaces. This helps
increase the bandwidth. In addition, connection reliability is enhanced when member
interfaces back up for each other dynamically.
mLACP link aggregation is used for the AC-side link in dual-homed PW protection to provide
communication between the DHD and 2 destination modes, as well as selection of active
interfaces. It is used to resolve the problem for selecting the path, prevent the loop, and
enhance the network availability.
The GE interface of the iTN8800-RXG8 does not support inter-card link aggregation
but the 10GE interface does.
Prerequisite
Configure physical parameters of the interface and make the physical layer Up.
Ensure not to configure services on interfaces, which are added to the LAG.
In a LAG, member interfaces that share loads must be identically configured.
Otherwise, data cannot be forwarded properly. For example, packets may be lost.
These configurations include STP, QoS, QinQ, VLAN, interface properties, and MAC
address learning.
STP status on the interface, properties (point-to-point/non point-to-point) of the link
connected to the interface, path cost of the interface, STP priority, packet Tx
speed limit, whether the interface is configured with loopback protection, root
protection, and whether the interface is an edge interface.
QoS: traffic policing, traffic shaping, congestion avoidance, rate limiting, SP queue,
WRR queue scheduling, WFQ queue, interface priority, and interface trust mode.
QinQ: QinQ status on the interface, added outer VLAN tag, policies for adding
outer VLAN Tags for different inner VLAN IDs.
VLAN: the allowed VLAN, default VLAN, and the link type (Trunk, Hybrid, and
Access) on the interface, and whether VLAN packets carry Tag.
Interface properties: speed, duplex mode, and link Up/Down status.
MAC address learning: MAC address learning status, MAC address limit, and
whether to forward and control data after the MAC address table is full.
In a static LACP LAG, a member interface can be an active/standby one. Both the
active interface and standby interface can receive and send LACPDU. However,
the standby interface cannot forward user packets.
The system selects a default interface based on following conditions in order:
whether the neighbor is discovered, maximum interface speed, the highest
interface LACP priority, and the smallest interface ID. The default interface is in
active status. Interfaces, which have the same speed, peer device, and operation
key of the operation key with the default interface, are in active status. Other
interfaces are in standby status.
When the number of member interfaces in the static LAG reaches the maximum
number of active interfaces, the later-added interfaces cannot become member
interfaces even they meet all requirements on member interfaces. This helps
make traffic of current member interfaces continuous.
Scenarios
In a dual-uplink networking scenario, you can realize redundancy backup of the primary/slave
link and fast switching of services through interface backup, thus improving service reliability.
Prerequisite
N/A
Scenario
To make the Ethernet reliability up to Telecom-grade (network self-heal time less than 50ms),
you can deploy ELPS at Ethernet. ELPS is used to protect the Ethernet connection. It is an
end-to-end protection technology.
ELPS supports 1+1 and 1:1 protection switching modes. It is divided into unidirectional
protection switching and bidirectional protection switching based on the fact that whether
services of both ends are switched concurrently when the link fails. Unidirectional and
bidirectional protection switching are available in 1+1 protection switching mode only. 1:1
protection switching mode supports bidirectional protection switching only.
ELPS provides 3 modes to detect a fault.
Detect faults based on physical interface status: learning link fault quickly and switching
services immediately, suitable for detecting the fault between neighbor devices.
Detect faults based on CC: suitable for unidirectional detection or multi-device crossing
detection.
Detect faults based on physical interface status and CC.
Prerequisite
Connect interfaces and configure physical parameters for them. Make the physical layer
Up.
Create a VLAN.
Add the interface to the VLAN.
Configure CFM detection and form a neighbor relationship (preparing for CC mode).
one [ non-revertive ] fault, traffic is not switched from the protection line to the
protocol-vlan vlan-id working line.
By default, there is no ELPS protection pair.
3 Raisecom(config)#ethernet (Optional) configure a name for the ELPS protection pair.
line-protection line-
number name string By default, there is no name for the ELPS protection pair.
4 Raisecom(config)#ethernet (Optional) configure the WTR timer. In revertive mode, when the
line-protection line- working line recovers from a fault, traffic is not switched to the
number wtr-timer wtr- working line unless the WTR timer times out.
timer
By default the WTR time value is 5min.
Fault detection modes of the working line and protection line can be different.
However, we recommend that fault detection mode configurations of the working line
and protection line keep consistent.
Step Command Description
1 Raisecom#config Enter global configuration mode.
By default, traffic is automatically switched to the protection line when the working
line fails. Therefore, you need to configure ELPS switching control in some special
cases.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#e Lock protection switching. After this configuration, the traffic is not
thernet line- switched to the protection line even the working line fails.
protection line-
number lockout By default, the traffic is automatically switched to the protection line when
the working line fails.
3 Raisecom(config)#e Switch the traffic from the working line to the protection line forcedly.
thernet line-
protection line-
By default, the traffic is automatically switched to the protection line when
number force- the working line fails.
switch
4 Raisecom(config)#e Switch the traffic from the working line to the protection line manually. Its
thernet line- priority is lower than the one of forced switch and APS.
protection line-
number manual- By default, the traffic is automatically switched to the protection line when
switch the working line fails.
Scenario
With development of Ethernet to Telecom-grade network, voice and video multicast services
bring higher requirements on Ethernet redundant protection and fault-recovery time. The
fault-recovery time of current STP system is in second level that cannot meet requirements.
By defining different roles for nodes on a ring, ERPS can block a loopback to avoid broadcast
storm in normal condition. Therefore, the traffic can be quickly switched to the protection line
when working lines or nodes on the ring fail. This helps eliminate the loopback, perform
protection switching, and automatically recover from faults. In addition, the switching time is
shorter than 50ms.
The iTN8800 supports the single ring, intersecting ring, and tangent ring.
ERPS provides 2 modes to detect a fault:
Detect faults based on physical interface status: learning link fault quickly and switching
services immediately, suitable for detecting the fault between neighbor devices.
Detect faults based on CFM: suitable for unidirectional detection or multi-device
crossing detection.
Prerequisite
Connect interfaces and configure physical parameters for them. Make the physical layer
Up.
Create a VLAN.
Add the interface to the VLAN.
Create the management VLAN and VLANs of the working and protection interfaces.
Configure CFM detection between devices and form a neighbor relationship (preparing
for CFM detection mode).
Only one device on the protection ring can be set to the Ring Protection Link (RPL)
Owner and one device is configured to RPL Neighbor. Other devices are set to
ring forwarding nodes.
In actual, the tangent ring consists of 2 independent single rings. Configurations
on the tangent ring are identical to the ones on the common single ring. The
intersecting ring consists of a master ring and a sub-ring. Configurations on the
master ring are identical to the ones on the common single ring.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#ethernet Create a protection ring and set the node to the RPL Owner.
ring-protection ring-
number east interface-type By default, the protocol VLAN is VLAN 1 and blocked VLANs
interface-number west are VLANs 1–4094.
interface-type interface- If you configure the not-revertive mode, the protection ring is in
number [ node-type rpl- non-revertive mode. In revertive mode, the traffic is switched
owner rpl { east | from the protection line back to the working line when the
west } ] [ not-revertive ] working line recovers from a fault. However, in non-revertive
[ protocol-vlan vlan-id ] mode, the traffic is not switched.
[ block-vlanlist vlan- By default, the protection ring is in revertive mode.
list ]
Only the intersecting ring consists of a master ring and a sub-ring. The master ring
is a complete ring and all its nodes should be configured with double interfaces.
The sub-interface is an incomplete ring and you must configure the single
interface on the intersecting node.
Configurations on the master ring are identical to the ones on the single
ring/tangent ring.
Configurations of non-intersecting nodes of the intersecting ring are identical to
the ones on the single ring/tangent ring.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#ethernet Create the sub-ring on the intersecting node and set the
ring-protection ring-number intersecting node to the RPL Owner.
east interface-type interface-
number west interface-type If you configure the not-revertive mode, the protection ring
interface-number node-type is in non-revertive mode. In revertive mode, the traffic is
rpl-owner rpl { east | west } switched from the protection line back to the working line
[ not-revertive ] [ protocol- when the working line recovers from a fault. However, in
vlan vlan-id ] [ block- non-revertive mode, the traffic is not switched.
vlanlist vlan-list ] By default, the protection ring is in revertive mode.
By default, traffic is automatically switched to the protection line when the working
line fails. Therefore, you need to configure ERPS switching control in some special
cases.
Step Command Description
1 Raisecom#config Enter global configuration mode.
2 Raisecom(config)#ethernet ring- Switch the traffic on the protection ring to the
protection ring-number force-switch west/east interface forcedly.
{ east | west }
3 Raisecom(config)#ethernet ring- Switch the traffic on the protection ring to the
protection ring-number manual-switch west/east interface manually. Its priority is lower
{ east | west } than the one of forced switch and APS.
Scenario
PW redundancy protection is used on the networking scenario of CE connecting to 3 PEs
asymmetrically, multiple CEs connecting to multiple PEs, and CE accessing a networking
with MS-PW, etc.
Prerequisite
The AC link between the dual-homed CE and PE supports E-Trunk or E-APS link
protection.
PEs can access each other through IGP routing protocol.
PW or MS-PW is created.
Scenario
MPLS-TP linear protection switching protects the primary link by providing a backup link.
Therefore, it provides end-to-end protection for LSP links between devices.
Prerequisite
Configure MPLS basic functions.
Scenario
The PW dual-homed protection switching protects user-side access links and network-side
working PWs by cooperating with the working PW, protection PW, and bypass PW. By
bridging any two nodes among the service PW, DNI-PW, and access link, dual-homed
protection can prevent the problem of access-side faults triggering network-side faults, and
vice versa. For example, when the user-side access interface of the PE node fails, the working
node will bridge the working PW and bypass PW to a multi-section PW and the protection
node will bridge the bypass PW with the access link, transmitting the service flow on the
working PW, bypass PW, and access PW. Figure 15-1 shows the application.
Prerequisite
Configure MPLS basic functions, create a LSP, and associate the Tunnel interface.
15.7.4 Configuring PW
For configuring the working PW, see section 11.1.2 Configuring static L2VC or 11.1.3
Configuring dynamic L2VC.
Configuring working PW
For configuring the working PW, see section 11.1.2 Configuring static L2VC or 11.1.3
Configuring dynamic L2VC.
Configure the working PW pointing to the PE B on PEA.
Configure the working PW pointing to the PE A on PE B.
Configuring protection PW
Configure the protection PW pointing to the PE C on PE A.
Configure the DNI-PW pointing to the PE C on the PE B.
Configure the DNI-PW pointing to the PE B on PE C.
Configure the active PW which is pointing to PE A as the protection PW of the
protection node on PE C.
Scenario
VPN FRR implements fast convergence on the services when the PE fails as shown in Figure
15-3, implementing MPLS L3VPN end-to-end protection.
MPLS-TE-FRR is the most commonly used technique to implement fast switching. Through
it, you can establish a tunnel between two PE devices and preconfigure a backup LSP for the
master LSP. When the device detects that the master LSP is unavailable (node fault or link
fault), it will switch the traffic to the backup LSP, thus implementing fast service switching.
However, MPLS-TE can only solve the problem of node faults and link faults instead of the
faults of the starting PE and the ending PE and it only recovers services through route
convergence and LSP convergence.
VPN FRR implements fast route switching based on the VPN route. You can preconfigure the
forwarding entry which points to the master PE and backup PE on the remote PE and combine
with the PE fault fast detection, to solve the problem of long convergence time in the CE dual-
homed MPLS VPN. Under the condition of PE faults, the end-to-end service recovery time is
no longer than 1s.
Prerequisite
PE devices are configured with OSPF and the backbone network is interconnected.
PE devices are configured with MPLS basic functions, and a Tunnel is created.
PE devices are configured with the VPN instance and the CE devices are accessed to the
PE devices at both ends respectively.
PE devices has established EBGP peers with the CE devices and introduced VPN routes.
MP-IBGP peers are established among PE devices.
Scenario
High Availability (HA), including hot backup, batch backup, and realtime backup, is used to
provide high reliability of the system. Devices, which support HA hot backup should be
equipped with 2 cards. The master card works in Master mode and the slave card works in
Slave mode. Whenever the master card fails, the slave card will be activated and continue to
work to ensure that the system can run properly.
Prerequisite
The iTN8800 is inserted with the active and standby MCCs.
Scenario
In general, we configure a default route to the breakout gateway for all devices in a LAN.
Therefore, these devices can communicate with the external network. If the gateway fails,
devices in the LAN fail to communicate with the external network.
The VRRP technology combines multiple routers to form a backup group. By configuring a
virtual IP address for the backup group, you can set the default gateway to the virtual IP
address of the backup group to make devices in the LAN communicate with the external
network.
VRRP helps improve network reliability. It facilitates avoiding network interruption caused
by failure of s single link and prevents changing routing configurations because of link failure.
Raisecom Proprietary and Confidential
382
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 15 Reliability
Prerequisite
N/A
Scenario
The Pseudo-Random Bit Sequence (PRBS) test module is for testing whether the end-to-end
CES runs normally. It can also test the transmission error rate of the high-speed serial channel
by sending PRBS codes.
Prerequisite
When testing the network-side service performance, you should configure CES on the
interface.
15.12 Maintenance
Command Description
Raisecom(config)#clear lacp statistics Clear LACP statistics.
[ interface-type interface-number ]
Raisecom(config)#clear mlacp mlacp-group Clear statistics of received and transmitted packets
[ icg-id ] statistics of the chassis group.
Raisecom(config)#clear ethernet line- Clear statistics of the protection group.
protection statistics
Raisecom(config)#clear ethernet line- Clear end-to-end switching control commands.
protection aps-id end-to-end command
Raisecom(config)#clear ethernet ring- Clear statistics of the protection ring, including the
protection ring-number statistics number of transmitted APS packets, the number of
received APS packets, the last switching time, and
the fault detection mode.
Raisecom(config)#clear ethernet ring- Clear switching control commands of the
protection ring-number command protection ring, including the force-switch and
manual-switch commands.
Raisecom(config)#clear mpls line-protection Clear statistics of the MPLS linear protection pair.
[ aps-id ] statistics
Raisecom(config)#clear vrrp statistics Clear packet statistics of all VRRP backup groups.
Networking requirements
As shown in Figure 15-5, to improve the reliability of the link between iTN A and iTN B, you
can configure manual link aggregation on iTN A and iTN B. Add GE 1/4/1 and GE 1/4/2 to a
LAG to form a single logical interface. The LAG performs load-sharing according to the
source MAC address.
Configuration steps
Step 1 Create a manual LAG.
Configure iTN A.
Raisecom#hostname iTNA
iTNA#config
iTNA(config)#interface port-channel 1
iTNA(config-port-channel1)#mode manual
iTNA(config-port-channel1)#exit
Configure iTN B.
Raisecom#hostname iTNB
iTNB#config
iTNB(config)#interface port-channel 1
iTNB(config-port-channel1)#mode manual
iTNB(config-port-channel1)#exit
iTNA(config)#interface gigaethernet1/4/1
iTNA(config-gigaethernet1/4/1)#port channel 1
iTNA(config-gigaethernet1/4/1)#exit
iTNA(config)#interface gigaethernet1/4/2
iTNA(config-gigaethernet1/4/2)#port channel 1
iTNA(config-gigaethernet1/4/2)#exit
Configure iTN B.
iTNB(config)#interface gigaethernet1/4/1
iTNB(config-gigaethernet1/4/1)#port channel 1
iTNB(config-gigaethernet1/4/1)#exit
iTNB(config)#interface gigaethernet1/4/2
iTNB(config-gigaethernet1/4/2)#port channel 1
iTNB(config-gigaethernet1/4/2)#exit
iTNA(config)#interface port-channel 1
iTNA(config-port-channel1)#load-sharing mode src-mac
Configure iTN B.
iTNB(config)#interface port-channel 1
iTNB(config-port-channel1)#load-sharing mode src-mac
Checking results
Use the show lacp internal command to show global configurations on manual link
aggregation.
Networking requirements
As shown in Figure 15-6, to improve the reliability of the link between iTN A and iTN B, you
can configure static LACP link aggregation on iTN A and iTN B. Add GE 1/4/1 and GE 1/4/2
to a LAG. The GE 1/4/1 works as the primary line and the GE 1/4/2 works as the backup line.
Configuration steps
Step 1 Configure the static LACP LAG on iTN A and configure iTN A as the active end.
Raisecom#hostname iTNA
iTNA#config
iTNA(config)#lacp system-priority 1000
iTNA(config)#interface port-channel 1
iTNA(config-port-channel1)#mode lacp
iTNA(config-port-channel1)#exit
iTNA(config)#interface gigaethernet 1/4/1
iTNA(config-gigaethernet1/4/1)#port-channel 1
iTNA(config-gigaethernet1/4/1)#lacp port-priority 1000
iTNA(config-gigaethernet1/4/1)#exit
iTNA(config)#interface gigaethernet 1/4/2
iTNA(config-gigaethernet1/4/2)#port-channel 1
iTNA(config-gigaethernet1/4/2)#exit
Raisecom#hostname iTNB
iTNB#config
iTNB(config)#interface port-channel 1
iTNB(config-port-channel1)#mode lacp
iTNB(config-port-channel1)#exit
iTNB(config)#interface gigaethernet 1/4/1
iTNB(config-gigaethernet1/4/1)#port-channel 1
iTNB(config-gigaethernet1/4/1)#exit
iTNB(config)#interface gigaethernet 1/4/2
iTNB(config-gigaethernet1/4/2)#port-channel 1
iTNB(config-gigaethernet1/4/2)#exit
Checking results
Use the show lacp internal command on iTN A to show LACP interface status, identifier,
interface priority, administration key, operation key, and interface state machine of the local
system.
Use the show lacp neighbor command on iTN A to show LACP interface status, identifier,
interface priority, administration key, operation key, and interface state machine of the remote
system.
Networking requirements
As shown in Figure 15-7, PW dual-homing protection is applied to the mobile backhaul
network. There is a working PW between PE A and PE B, a protection PW between PE A and
PE C, and a bridge PW (bypass PW) between PE B and PE C. Service data will be switched
to the protection PW for transmission when the working PW fails to work. When an AC at the
RNC side fails, the bypass is bridged with the working/protection PW to form a MS-PW. The
MS-PW provides PW dual-homed protection switching to protect service data. The
configuration parameters are shown in Table 15-1.
Configuration steps
Step 1 Configure the IP address of the Layer 3 physical interface on PE A, PE B, and PE C.
PE A
PEA#config
PEA(config)#interface gigaethernet 1/1/1
PEA(config-gigaethernet1/1/1)#ip address 10.0.0.10 255.0.0.0
PEA(config-gigaethernet1/1/1)#interface gigaethernet 1/1/2
PEA(config-gigaethernet1/1/2)#ip address 30.0.0.10 255.0.0.0
PEA(config-gigaethernet1/1/2)#interface loopback 1
PEA(config-loopback1)#ip address 132.0.0.1 255.255.255.0
PEA(config-loopback1)#exit
PE B
PE C
PE B
PE C
PE C
PE B
PE C
PEC(config-tunnel1/1/1)#mpls te commit
PEC(config-tunnel1/1/1)#interface tunnel 1/1/2
PEC(config-tunnel1/1/2)#destination 30.0.0.10
PEC(config-tunnel1/1/2)#mpls tunnel-id 3
PEC(config-tunnel1/1/2)#mpls te commit
PEC(config-tunnel1/1/2)#exit
PE B
PE C
PEC(config)#mpls static-lsp ingress lspca 30.0.0.10 255.255.255.0 nexthop
30.0.0.10 out-label 200 lsr-id 132.0.0.1 tunnel-id 3
PEC(config)#mpls static-lsp egress lspac in-label 201 lsr-id 132.0.0.1
tunnel-id 3
PEC(config)#mpls static-lsp ingress lspcb 20.0.0.20 255.255.255.0 nexthop
20.0.0.20 out-label 300 lsr-id 132.0.0.2 tunnel-id 2
PEC(config)#mpls static-lsp egress lspbc in-label 301 lsr-id 132.0.0.2
tunnel-id 2
PE B
PE C
Step 7 Configure the working node and protection node of PW 1:1 protection group and MC-PW
protection group.
PE A
PE B
PE C
Step 8 Associate the MC-PW protection pair of PE B and PE C to the ICCP Tunnel respectively.
PE B
PE C
Checking results
Use the show iccp channel command to show ICCP configurations of PE B.
Use the show mpls line-protection config command to show protection switching
configurations of PE A, PE B, and PE C.
PE A
Id:1
Name:--
Working Entity Information:
Vc-Id:1 destination:20.0.0.20
State/LCK/M: Active/N/N
Link State:failure
Protection Entity Information:
Vc-Id:2 destination:30.0.0.30
State/F/M: Standby/N/N
Link State:failure
Wtr(m):5
Holdoff(100ms):0
PE B
PE C
Networking requirements
As shown in Figure 15-8, CE 1 services are transmitted through PE 1 and PE 2 respectively.
PE 1 and PE 2 are connected to the PE 4 which locates at the core layer through the static PW
carried by the static Tunnel. The services of the peer CE 2 are transmitted through PE 3 which
is also connected to the core-layer PE 5 through the static PW. The PE devices at the core
layer are enabled with the dynamic PW which is carried by the LDP LSP dynamically. The
core-layer devices include PE 4, PE 5, PE 6, and PE 7. The devices at the access side are all
configured with two static PWs (master/slave) and enabled with PW redundancy protection.
To implement service transmission and protection at the core layer, you can enable static-to-
dynamic PW conversion on PE 4 and PE 5 and enable dynamic PW conversion on PE 6 and
PE 7.
Configuration strategy
Configure MPLS basic functions on the PE devices, configure MPLS LDP, and establish
Tunnels between PE devices.
Enable OSPF on PE 4, PE 5, PE 6, and PE 7 and ensure that routes are reachable
between PE devices.
Configure static routes among PE 1, PE 2, and PE 4 and configure static routes between
PE 3 and PE 5.
Configure the static-to-dynamic PW conversion on PE 4 and configure static-to-dynamic
PW conversion on PE 5.
Configure static PWs among PE 1, PE 2, and PE 4 and configure static PWs on PE 3 and
PE 5.
Configure PW redundancy.
Data preparation
Figure 15-9 shows the data preparation.
Configuration steps
Step 1 Enable MPLS and LDP globally.
Configure PE 1.
Configure PE 6.
PE1(config)#interface loopback 2
PE1(config-loopback2)#ip address 1.1.1.1 255.255.255.0
PE1(config-loopback2)#exit
Configure PE 2.
PE2(config)#interface loopback 2
PE2(config-loopback2)#ip address 2.2.2.2 255.255.255.0
PE2(config-loopback2)#exit
Configure PE 4.
PE4(config)#interface loopback 2
PE4(config-loopback2)#ip address 4.4.4.4 255.255.255.0
PE4(config-loopback2)#exit
PE4(config)#router id 4.4.4.4
Configure PE 6.
PE6(config)#interface loopback 2
PE6(config-loopback2)#ip address 6.6.6.6 255.255.255.0
PE6(config-loopback2)#exit
PE6(config)#router id 6.6.6.6
PE6(config)#router ospf 1 router-id 6.6.6.6
PE6(config-router-ospf)#network 6.6.6.6 0.0.0.255 area 0
PE6(config-router-ospf)#network 60.0.0.2 0.0.0.255 area 0
PE6(config-router-ospf)#network 30.0.0.1 0.0.0.255 area 0
PE6(config-router-ospf)#exit
Configure PE 7.
PE7(config)#interface loopback 2
PE7(config-loopback2)#ip address 7.7.7.7 255.255.255.0
PE7(config-loopback2)#exit
PE7(config)#router id 7.7.7.7
PE7(config)#router ospf 1 router-id 7.7.7.7
PE7(config-router-ospf)#network 7.7.7.7 0.0.0.255 area 0
PE7(config-router-ospf)#network 70.0.0.2 0.0.0.255 area 0
PE7(config-router-ospf)#network 50.0.0.1 0.0.0.255 area 0
PE7(config-router-ospf)#exit
Configure PE 5.
PE5(config)#interface loopback 2
PE5(config-loopback2)#ip address 5.5.5.5 255.255.255.0
PE5(config-loopback2)#exit
PE5(config)#router id 5.5.5.5
PE5(config)#router ospf 1 router-id 5.5.5.5
PE5(config-router-ospf)#network 5.5.5.5 0.0.0.255 area 0
PE5(config-router-ospf)#network 30.0.0.2 0.0.0.255 area 0
PE5(config-router-ospf)#network 50.0.0.2 0.0.0.255 area 0
PE5(config-router-ospf)#exit
Configure PE 3.
PE3(config)#interface loopback 2
Configure PE 2.
Configure PE 3.
Configure PE 4.
Configure PE 5.
Configure PE 5.
Configure PE 6.
Configure PE 7.
Configure PE 2.
Configure PE 3.
PE3(config-tunnel1/1/3)#mpls te commit
PE3(config-tunnel1/1/3)#exit
PE3(config)#mpls bidirectional static-lsp ingress lspin3 lsr-id 5.5.5.5
tunnel-id 3
PE3(config-ingress-lsp)#forward 5.5.5.5 255.255.255.255 nexthop 80.0.0.1
out-label 3005
PE3(config-ingress-lsp)#backward in-label 5003
PE3(config-ingress-lsp)#exit
Configure PE 5.
Configure PE 5.
Configure PE 6.
Configure PE 7.
Checking configurations
After configurations are complete, use the following commands to check whether LDP LSP is
correctly created and whether the status is Up and check whether the status of PW, VC, and
AC are Up.
show mpls ldp session
show mpls ldp targeted neighbour
show mpls lsp ldp
show mpls l2vc
show mpls switch-l2vc
16 Appendix
This chapter lists terms, acronyms, and abbreviations involved in this document, including the
following sections:
Terms
Acronyms and abbreviations
16.1 Terms
A
A series of ordered rules composed of permit | deny sentences. These
Access
rules are based on source MAC address, destination MAC address,
Control List
source IP address, destination IP address, interface ID, etc. The device
(ACL)
decides to receive or refuse the packets based on these rules.
C
An electronic module, composed of the chip and other electronic
Card components installed on a flat and hard Printed Circuit Board (PCB). The
PCB has conductive circuits for connecting these components.
A standard defined by IEEE. It defines protocols and practices for OAM
Connectivity
(Operations, Administration, and Maintenance) for paths through 802.1
Fault
bridges and local area networks (LANs). Used to diagnose fault for EVC
Management
(Ethernet Virtual Connection). Cost-effective by fault management
(CFM)
function and improve Ethernet maintenance.
E
Encapsulation A technology used by the layered protocol. When the lower protocol
receives packets from the upper layer, it will map packets to the data of
the lower protocol. The outer layer of the data is encapsulated with the
lower layer overhead to form a lower protocol packet structure. For
example, an IP packet from the IP protocol is mapped to the data of
802.1Q protocol. The outer layer is encapsulated by the 802.1Q frame
header to form a VLAN frame structure.
Raisecom Proprietary and Confidential
408
Copyright © Raisecom Technology Co., Ltd.
Raisecom
iTN8800 (P100R002) Configuration Guide 16 Appendix
A
Complying with IEEE 802.3ah protocol, EFM is a link-level Ethernet
Ethernet in OAM technology. It provides the link connectivity detection, link fault
the First Mile monitoring, and remote fault notification, etc. for a link between two
(EFM) directly-connected devices. EFM is mainly used for the Ethernet link on
edges of the network accessed by users.
L
Link A computer networking term which describes using multiple network
Aggregation cables/ports in parallel to increase the link speed beyond the limits of any
one single cable or port, and to increase the redundancy for higher
availability.
P
In data communication field, packet is the data unit for switching and
transmitting information. In transmission, it will be continuously
encapsulated and decapsulated. The header is used to define the
Packet
destination address and source address. The trailer contains information
indicating the end of the packet. The payload data in between is the
actual packet.
In packet switching network, data is partitioned into multiple data
segments. The data segment is encapsulated by control information, such
as, destination address, to form the switching packet. The switching
Packet
packet is transmitted to the destination in the way of storage-forwarding
switching
on the network. Packet switching is developed based on storage-
forwarding method and has merits of both circuit switching and packet
switching.
Q
QinQ QinQ is (also called Stacked VLAN or Double VLAN) extended from
802.1Q, defined by IEEE 802.1ad recommendation. Basic QinQ is a
simple layer-2 VPN tunnel technology, encapsulating outer VLAN Tag
for client private packets at carrier access end; the packets take double
VLAN Tag passing through trunk network (public network). In public
network, packets only transmit according to outer VLAN Tag, the private
VLAN Tag are transmitted as data in packets.
V
Virtual Local VLAN is a protocol proposed to solve broadcast and security issues for
Area Ethernet. It divides devices in a LAN into different segments logically
Network rather than physically, thus implementing multiple virtual work groups
(VLAN) which are based on Layer 2 isolation and do not affect each other.
A
VLAN mapping is mainly used to replace the private VLAN Tag of the
Ethernet service packet with the ISP's VLAN Tag, making the packet
transmitted according to ISP's VLAN forwarding rules. When the packet
VLAN
is sent to the peer private network from the ISP network, the VLAN Tag
mapping
is restored to the original private VLAN Tag according to the same
VLAN forwarding rules. Thus, the packet is sent to the destination
correctly.
C
CE Customer Edge
CFM Connectivity Fault Management
CoS Class of Service
D
DHD Dual Home Device
DRR Deficit Round Robin
DSCP Differentiated Services Code Point
E
EFM Ethernet in the First Mile
F
FTP File Transfer Protocol
G
GPS Global Positioning System
GSM Global System for Mobile Communications
H
HA High Availability
I
ICCP Inter-Chassis Communication Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
International Telecommunications Union - Telecommunication
ITU-T
Standardization Sector
L
LACP Link Aggregation Control Protocol
LBM LoopBack Message
LBR LoopBack Reply
LLDP Link Layer Discovery Protocol
LLDPDU Link Layer Discovery Protocol Data Unit
LTM LinkTrace Message
LTR LinkTrace Reply
M
MA Maintenance Association
MAC Medium Access Control
MD Maintenance Domain
MEG Maintenance Entity Group
MEP Maintenance associations End Point
MIB Management Information Base
MIP Maintenance association Intermediate Point
MTU Maximum Transmission Unit
A
NTP Network Time Protocol
O
OAM Operation, Administration and Maintenance
P
PDU Protocol Data Unit
PE Provider Edge
PSN Packet Switched Network
PTN Packet Transport Network
PW Pseudo Wire
PWE3 Pseudo Wire Emulation Edge-to-Edge
Q
QoS Quality of Service
R
RMEP Remote Maintenance association End Point
RMON Remote Network Monitoring
S
SAToP Structure-Agnostic TDM over Packet
SFP Small Form-factor Pluggables
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SNTP Simple Network Time Protocol
SP Strict-Priority
SSH Secure Shell
T
TCI Tag Control Information
TCP Transmission Control Protocol
A
TFTP Trivial File Transfer Protocol
TLV Type Length Value
ToS Type of Service
TPID Tag Protocol Identifier
V
VPN Virtual Private Network
VLAN Virtual Local Area Network
W
WRR Weight Round Robin