ZXCTN 9000 MML Configuration Guide (IPv4 Routing) V2.08.32 en

ZXCTN 9002/9004/9008
Packet Transport Network Product
MML Configuration Guide (IPv4 Routing)

Version: 2.08.32
ZTE CORPORATION
NO. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright 2011 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited.
Additionally, the contents of this document are protected by
contractual confidentiality obligations.

All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided as is, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No.
Revision Data
Revision Reason
R1.0
20110730
ZXCTN 9002/9004/9008(V2.08.32) first version issued
Serial Number: SJ-20100901100356-015

Publishing Date: 2011-07-30(R1.0)
About This Manual

Purpose
This manual describes the principle, configuration commands, maintenance commands,
configuration examples and fault handling about IPv4 Route Configuration of ZXCTN 9000.
What Is in This Manual

This manual contains the following contents:
Chapter
Chapter 1 Safety Instruction
Summary
Introduces safety instruction and symbol description for device
installation, operation and maintenance.
Chapter 2 Static Route
Describes the Static Route Basic principle, configuration
Configuration
commands, maintenance commands, configuration examples

and fault handling.
Chapter 3 ARP Configuration
Describes the ARP principle, configuration commands,

maintenance commands, configuration examples and fault
handling.
Chapter 4 RIP Configuration
Describes the RIP principle, configuration commands,

handling.
Chapter 5 OSPF Configuration
Describes the OSPF principle, configuration commands,

handling.
Chapter 6 IS-IS Configuration
Describes the IS-IS principle, configuration commands,

handling.
Chapter 7 BGP Configuration
Describes the BGP principle, configuration commands,

handling.
Intended Audience
This manual is intended for the following engineers:
l
l
l
Network planning engineer

Commissioning engineer
On-duty personnel
Conventions
ZTE documents employ the following typographical conventions.
I
Typeface
Meaning
Italics
Variables in commands. It may also refers to other related manuals and documents.
Bold
Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters and commands.
CAPS
Keys on the keyboard and buttons on screens and company name.
Constant
Text that you type, program codes, filenames, directory names, function names.
width
[]
Optional parameters.
{}
Mandatory parameters.
Separates individual parameter in series of parameters.
Danger: Indicates an imminently hazardous situation, which if not avoided, will result in
death or serious injury.
Warning: Indicates a hazard that, if not avoided, could result in serious injuries,
equipment damages or interruptions of major services.
Caution: Indicates a potential hazard that, if not avoided, could result in moderate
injuries, equipment damages or partial service interruption.
Note: Provides additional information about a certain topic.
Checkpoint: Indicates that a particular step needs to be checked before proceeding

further.
Tip: Indicates a suggestion or hint to make things easier or more productive for the
reader.
Auxiliary Function
Command help function of ZXCTN9000 devices has the following features:
1. By entering a question mark (?) following DOS prompt in any command mode, a list of
available commands in this command mode are displayed. With the context-sensitive
help function, the keywords and parameter list of any commands can be displayed.
l By entering a question mark "?" following DOS prompt in any command mode,
a list of all commands in this mode and brief description of these commands are
displayed.
l Input the question mark following a character or a character string, a list of
commands or keywords beginning with this character or character string is
displayed. Note that there is no space between the character (string) and the
question mark.
II
Press Tab key following the character string. If the command or keyword
beginning with this character string is unique, complement the command or
keyword and attach a space to the end. Note that there is no space between the
character string and the Tab key.
l Input a question mark (?) following the command, keyword or parameter. The
next keyword or parameter to be entered is listed, and also a brief description is
given. A space shall be entered before the question mark.
2. If incorrect command, keyword or parameter is entered, the error isolation is offered
with ^ in the user interface after you press Enter key. Character ^ locates below the
first character of the entered incorrect command, keyword or parameter.
3. The system allows the command or keyword to be abbreviated to a character or
character string that uniquely identifies this command or keyword. For example, show
command can be abbreviated to sh or sho.
4. User interface supports the function of recording input commands. Maximum ten
history commands can be recorded. This function is very useful in re-invocation of
a long or complicated command or ingress.
To re-invoke a command from the record buffer, conduct one of the following
operations.
Command
Function
Press Ctrl-P or the up arrow
It re-invokes the latest commands in the record buffer. Repress
key
these keys to invoke old commands forwards.
Press Ctrl-N or down arrow
Roll commands downwards. When the last command line is
key
reached, one more operation will roll the commands from the
beginning of the buffer cyclically.
Use show history command in any mode, and the latest several commands in this
mode will be listed.
III
IV
Chapter 1
Safety Instructions
Table of Contents
Safety Instructions......................................................................................................1-1
Conventions ...............................................................................................................1-1
1.1 Safety Instructions

Only qualified personnel are allowed to install/operate/maintain the equipment.
During equipment installation/operation/maintenance, please abide by local safety
regulations and related operation instructions. Otherwise, personal injury or equipment
damage might be incurred. The safety precautions introduced in this document are only
supplementary to local safety regulation.
The execution of the debug commands may seriously affects the equipment performance.
Use these commands with caution. To be particular, the debug all command can enable
all debug processes. Do not use this command on the equipment providing services. It is
recommended that users not use the debug commands when the network runs properly.
ZTE is exempt from all responsibility for injury or damage caused by violation of general
safety precautions or by violation of safety standards in design/manufacture/use of the
equipment.
1.2 Conventions
Pay attention to the following symbols in the installation, operation, and maintenance
descriptions.
Warning!
Indicates a hazard that, if not avoided, could result in serious injuries, equipment damages
or interruptions of major services.
Caution!
Indicates a potential hazard that, if not avoided, could result in moderate injuries,
equipment damages or partial service interruption.
1-1
SJ-20100901100356-015|2011-07-30(R1.0)
ZTE Proprietary and Confidential
ZXCTN 9002/9004/9008 MML Configuration Guide (IPv4 Routing)
Please strictly follow the above instructions.
1-2
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 2
Static Route Configuration

Table of Contents
Configuring Static Route.............................................................................................2-1
Maintaining Static Route.............................................................................................2-2
Static Route Configuration Instances..........................................................................2-3
Static Route Troubleshooting .....................................................................................2-7
2.1 Configuring Static Route

Use the ip route command to configure the static route. This command involves the
following parameters.
Command
Function
ZXCTN9000#ip route [ mng | vrf < vrf-name> ] <
Configures a static route.
ip-address> < mask> { < interface> | { [ interface] <

nexthop> } } [ global] [ < 1-255> ] [ tag < 150-255>
] [ slave] [ wtrtime< 0-12> ] [ { [ detect-group <
1-10> | track-session < name> ] } ]
ZXCTN9000#no ip route [ mng | vrf < vrf-name> ] <
Deletes a static route.
ip-address> < mask> [ < 1-255> ] [ tag < 150-255>

] [ { [ detect-group < 1-10> | track-session <
name> ] } ]
The parameters are described in the table below.

Parameter
Description
mng
Configures a static route for the management

interface.
vrf < vrf-name>
Configures a static route for the specified VRF.

The VRF name ranges from 1 to 32 characters.
ip-address
Indicates the destination IP address.
mask
Indicates the mask.
< interface>
Indicates the egress.
< nexthop>
Indicates the next hop.
2-1
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
global
Indicates that the next hop is the next-hop IP

address on the public network, not the directly
connected next hop. This command is valid only
for static L3VPN routes.
< 1-255>
Indicates the priority of the route.
tag< 150-255>
Indicates the tag value of the route. This

parameter is used to differentiate static routes
with the same destination IP address and mask.
Indicates that the route can serve as the FRR
slave
slave route.
wtrtime< 0-12>
Indicates the FRR wait-to-restore time. The value

of this parameter ranges from 0 to 12 minutes.
The default value is 0.
detect-group< 1-10>
Binds the static route to a ping detection group.
track-session< name>
Binds the static route to a track session.
2.2 Maintaining Static Route

Use this command to maintain the static route on the ZXCTN 9000.
Command
Function
ZXCTN9000#show ip route [ vrf < vrf-name> ] static
Shows the global routing table of the

router. < vrf-name> indicates the VRF
name.
If the show ip route command is executed in the OAM interface, the basic information about
all routes is displayed in the routing table.
show_rtm_route is the debugging function. If this function is executed in shell mode, the
details about a route is displayed for fault analysis.
The execution result of the show ip route command is shown below.
P1#show ip route static
Total number of routes:
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri Metric
40.40.40.40
255.255.255.255 199.40.48.2
vlan2
static
49.49.49.49
255.255.255.255 20.1.1.2
tunnel1
static
The command output is described in the table below.
2-2
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 2 Static Route Configuration
Output Item
Description
Dest
Mask
Indicates the mask.
Gw
Indicates the gateway.
Interface
Indicates the egress of the route.
Owner
Indicates the type of the route.
Pri
Indicates the priority of the route.
Metric
Indicates the metric of the route.
2.3 Static Route Configuration Instances

2.3.1 Configuring Direct Static Route
As shown in Figure 2-1, to send packets to remote network 140.1.1.0/24, P1 needs to
send the packets to P2 at 10.6.1.18. Since P1 and P2 are directly connected, in this case,
a static route to the destination network segment 140.1.1.0 with the next-hop IP address
as 10.6.1.18 needs to be configured on P1 and a static route to the destination network
segment 140.1.1.0 with the next-hop IP address as 10.9.1.39 needs to be configured on
P2.
Figure 2-1 Configuring Static Route
The configuration of P1:

P1(config)#ip route 140.1.1.0 255.255.255.0 10.6.1.18
or
P1(config)#ip route 140.1.1.0 255.255.255.0 vlan1 10.6.1.18

P2(config)#ip route 140.1.1.0 255.255.255.0 10.9.1.39
or
P2(config)#ip route 140.1.1.0 255.255.255.0 vlan2 10.9.1.39
2-3
SJ-20100901100356-015|2011-07-30(R1.0)
If the egress is specified on the ZXCTN9000, the next-hop IP address must be set.
Otherwise, traffic cannot be forwarded.
If both the egress and next-hop IP address are specified, they must be on the same
network segment. Otherwise, a configuration error may occur. The direct next hop is
usually specified.
The execution result of the show command is shown below.
View the configuration on P1:
IPv4 Routing Table:

Dest
140.1.1.0
Mask
255.255.255.0
Gw
10.6.1.18
Interface
Owner
vlan1
static
Pri Metric
1
View the configuration on P2:

IPv4 Routing Table:

Dest
140.1.1.0
Mask
255.255.255.0
Gw
10.9.1.39
Interface
Owner
vlan2
static
Pri Metric
1
2.3.2 Configuring Non Direct Static Route (Static L3VPN Route)

As shown in Figure 2-2, CE1 (through PE1) and CE2 (through PE2) are added to the same
VRF. To send packets to remote network 192.168.1.0/24, CE1 needs to send the packets
to PE2 with the loopback address 2.2.2.2. Since PE1 and PE2 are directly connected, in
the case, a static L3VPN route to the network segment 192.168.1.0 with the next-hop IP
address as 2.2.2.2 needs to be configured on PE1 and the next hop should be configured
as the non direct next hop on the public network.
Figure 2-2 Configuring Static L3VPN Route

P1(config)#ip route vrf zte 192.168.1.0 255.255.255.0 2.2.2.2 global
2-4
SJ-20100901100356-015|2011-07-30(R1.0)
The key word global indicates that the next hop is the next hop on the public network, not
direct next hop. Meanwhile, a static L3VPN route must be configured by adding the global
key word to the next hop, not by specifying the egress.
This command only adds a VPN route to the routing table. To forward traffic, you need
to run the mpls label mode per-vrf command in the vrf configuration mode on PE2 and
specify the incoming tag. Run the static-outlabel command in the vrf configuration mode
on PE1 and specify the inner outgoing tag for the next-hop IP address 2.2.2.2 on the public
network. The outgoing tag must match the incoming tag configured on PE2. (For the
configurations of the mpls label mode per-vrf and static-outlabel commands, refer to the
related commands in vrf mode.)
The execution result of the show command is shown below.
PE1(config)#show ip route vrf zte static
IPv4 Routing Table:

Dest
192.168.1.0
Mask
255.255.255.0
Gw
49.49.49.49
Interface
Owner
tunnel1
static
Pri Metric
1
2.3.3 Configuring Default Route

The default route is a special static route. When all the routes in the routing table fail to
be selected, the default route is used to forward packets, greatly reducing the load on the
PTN device.
If a PTN cannot find the route for a packet, the packet is discarded, which is the last
thing people would expect. To establish a complete connection, the PTN device must
have a route to a certain network. The default route can be used to maintain a complete
connection for the PTN device without recording a single route. The default route uses a
single route to symbolize all other routes.
An example of configuring the default route is shown below. As shown in Figure 2-3, since
no route to the Internet is available on P1, P1 can use the default route to forward packets
whose route cannot be founded to P2.
Figure 2-3 Configuring Default Route
The method for configuring a default route is the same as that for configuring a static route.
The only difference is that both the destination IP address and subnet mask of the default
route are 0.0.0.0.
2-5
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config)#ip route 0.0.0.0 0.0.0.0 10.6.1.18
You can use the show command to view the routing table of P1.
IPv4 Routing Table:

Dest
0.0.0.0
Mask
0.0.0.0
Gw
Interface
Owner
Pri Metric
10.6.1.18
vlan1
static
In this case, if the next hop is configured as null, the route is a blackhole route.
P1(config)#ip route 0.0.0.0 0.0.0.0 null1
IPv4 Routing Table:

Dest
0.0.0.0
Mask
Gw
Interface
Owner
0.0.0.0
10.6.1.18
null1
static
Pri Metric
1
The default route is not necessarily a static route. It can be a route of other protocols, such
as BGP and RIP. In routing protocol configuration, the default route varies with the routing
protocol.
2.3.4 Configuring Static Slave Route

As shown in the parameters of the command for configuring a static route, you can
configure a static slave route by adding the slave parameter. The function takes effect
after the wtrtime parameter is specified. This function aims to solve the problem that the
traffic is not immediately switched back to the master link during FRR recovery.
Prerequisite: The function takes effect only if the static slave route is valid and active (view
related information through the show ip route command ).
Trigger condition: The static master route is valid and forms FRR (view related information
through the show ip backup route) with the static slave route.
Configuration command (taking the static route on a private network for example):
ZXCTN9000(config)#ip route vrf zte 5.5.5.5 255.255.255.255 3.3.3.3 global 3 tag 150
slave wtrtime 5
2-6
SJ-20100901100356-015|2011-07-30(R1.0)
2.4 Static Route Troubleshooting

2.4.1 Network Topology
As shown in Figure 2-4, P1 needs to access the network segment 10.9.1.0/24 where an
interface of P3 resides.
Figure 2-4 Network Topology for Handling a Static Route Fault
2.4.2 Fault Analysis

A common fault is that the configured static route does not take effect.
P1(config)#ip route 10.9.1.0 255.255.255.0 10.6.1.18
The execution result of the show command on P1 shows that the route is not generated
and P1 cannot ping through 10.9.1.39.
If the static route to the destination network segment is configured on P1, this fault may be
caused by a physical link failure.
2.4.3 Handling Flow

The flow to handle a static route fault is shown in Figure 2-5.
2-7
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 2-5 Flow to Handle a Static Route Fault
2.4.4 Handling Procedure

The procedure to handle a static route fault is described below.
1. Run the show ip route command to check whether the static route is generated. If
the route is not generated, check whether its configurations are correct, including the
destination network segment, subnet mask, and next-hop IP address.
2. If the configurations are correct, check the IP address and the status of the physical
link.
3. Run the show ip interface brief command or the show ip interface command with the
interface name to check whether the status of the physical interface is up.
2-8
SJ-20100901100356-015|2011-07-30(R1.0)
4. If the status of the interface is down, check whether the cable is correctly connected.
5. Run the ping command to check whether the destination network segment can be
pinged through.
If the fault still persists, contact the technical support engineer for help.
2-9
SJ-20100901100356-015|2011-07-30(R1.0)
This page intentionally left blank.
2-10
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 3
ARP Configuration
Table of Contents
Configuring ARP ........................................................................................................3-1
Maintaining ARP ........................................................................................................3-4
ARP Configuration Instances......................................................................................3-5
ARP Troubleshooting ...............................................................................................3-10
3.1 Configuring ARP

3.1.1 Configuring Permanent ARP Entry
Use these commands to configure static permanent ARP entries on the ZXCTN9000.
Step
Command
Function
ZXCTN 9000(config)#interface < vlan id>
Enters the interface configuration

mode from the configuration mode.
ZXCTN 9000(config-if-vlanX)#set arp { static |
Configures static permanent ARP
permanent } < ip-address> < hardware-address> [ <
entries.
external-vlanId> ] [ < internal-vlanId> ]
The parameters in step 2 are described in the table below.

Parameter
Description
permanent
Indicates permanent binding. To be specific, the

ARP entry is valid currently and still valid after
the device restarts.
Indicates static binding. To be specific, the ARP
static
entry is valid currently but invalid after the device

restarts.
< ip-address>
Indicates the IP address, in dotted decimal

notation.
< hardware-address>
Indicates the MAC address, in xxxx.xxxx.xxxx

format.
< external-vlanId>
Indicates the outer VLAN ID of the entry.
< internal-vlanId>
Indicates the inner VLAN ID of the entry.
3-1
SJ-20100901100356-015|2011-07-30(R1.0)
3.1.2 Configuring Common ARP Attribute

Step
1
Command
Function
ZXCTN 9000(config)#arp protect { interface| whole |
Enables the ARP protection function.
mac } { limit-num < num> }
By default, ARP protection is

disabled.
Converts dynamic ARP entries to TS
ZXCTN 9000(config)#arp to-static
entries.
3
ZXCTN 9000(config)#interface < gei_1/1>

ZXCTN 9000(config-gei_1/1)arp protect interface
Enables the ARP protection function.
limit-num < num>
By default, ARP protection is

disabled.
Converts dynamic ARP entries to TS
ZXCTN 9000(config-if-vlanX)arp to-static
entries.
6
ZXCTN 9000(config-if-vlanX)arp timeout <
Sets the aging time of ARP entries
seconds>
in the ARP cache.
ZXCTN 9000(config-if-vlanX)no arp learn
Disables ARP learning.
ZXCTN 9000#clear arp-cache[ { [ ( interface <
Clears ARP entries.
interface-name> )[ < ip-address> | permanent | static |

dynamic | dynamic-force | dhcp| < mac-address> ] ] |
{ permanent | static | < ip-address> | dynamic-force |
dhcp} } ]

Parameter
Description
interface
Indicates the ARP protection based on interfaces.
whole
Indicates the ARP protection based on the

number of global ARP entries.
mac
Indicates the ARP protection based on the

number of MAC entries.
limit-num
Sets the upper limit for the number of ARP

entries.
< num>
Ranges from 1 to 65535.

Parameter
Description
interface
Indicates the ARP protection based on interfaces.
3-2
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< num>
Sets the upper limit for the number of ARP

entries.
The parameter in step 5 is described in the table below.

Parameter
Description
< seconds>
Indicates the aging time of ARP entries in the

ARP cache. The unit is second. The value of this
parameter ranges from 1 to 2147483. The default
value is 600.

Parameter
Description
interface
Deletes ARP entries based on interface.
< interface-name>
Indicates the interface name.
dynamic
Deletes dynamic ARP entries.
staic
Deletes static and to-static ARP entries.
permanent
Deletes static permanent ARP entries.
< ip-address>
Indicates the IP address, in dotted decimal

notation.
dynamic-force
Deletes ARP entries of dynamic binding, available

on the ZXCTN9000.
dhcp
Deletes DHCP ARP entries.
< mac-address>
Indicates the MAC address, in xxxx.xxxx.xxxx

format.
3.1.3 Configuring ARP Proxy

Step
Command
Function

ZXCTN 9000(config-if-vlanX)#ip proxy-arp
Enables the ARP proxy function. By

default, the ARP proxy function is
disabled.
3-3
SJ-20100901100356-015|2011-07-30(R1.0)
3.1.4 Configuring ARP Source Filtering

Step
Command
Function

ZXCTN 9000(config-if-vlanX)#arp source-filtered
Enables ARP source filtering. By

default, this function is enabled. You
can use the no arp source-filtered
command to disable the ARP source
filtering on the interface.
3.2 Maintaining ARP

Use these commands to maintain ARP on the ZXCTN9000.
Command
Function
ZXCTN 9000#show arp[ { vrf < vrf-name> } | < ip-addr> |
Shows various ARP entries.
dynamic | static | arp-to-static | interface ] < interface-name> [ <

ip-addr> | < mac-addr> ] [ detail] ] ] ]
ZXCTN 9000#debug arp { packets | [ trace { send | receive} ] |
Shows the debugging information
all } { interface < interface-name> | source < ip-address> | <
about ARP packet sending
mac-address> | destination < ip-address> | < mac-address> }
and receiving and whether the

ZXCTN9000 is sending or receiving
ARP packets.
The execution result of the show arp command is shown below.

ZXCTN 9000#show arp
Arp protect whole is disabled
The count is 3
IPAddr
Age HardwareAddr Interface ExterVlanID InterVlanID SubInterface
-------------------------------------------------------------------------192.168.88.200 - 00e0.d021.0203 gei_1/1
N/A
N/A
N/A
1.1.1.1
P 0011.0011.0011 gei_1/1
N/A
N/A
N/A
2.2.2.2
30 0022.0022.0022 gei_1/1
N/A
N/A
N/A

Output Item
Description
IP Address
Indicates the IP address.
Age
Indicates the aging time. P indicates a permanent

ARP entry, and a number indicates the remaining
time of a dynamic ARP entry.
3-4
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
Hardware Address
Indicates the MAC address.
Interface
Indicates the interface name.
Exter VlanID
Indicates the outer VLAN ID.
Inter VlanID
Indicates the inner VLAN ID.
Sub Interface
Indicates the subinterface.
The execution result of the debug arp command is shown below.

ZXCTN 9000#debug arp
19:12:27 Unit:1
IP ARP:rcvd rep src 192.168.88.1 0016.3E28.5657,
dst 192.168.88.200 00E0.D021.0203
19:12:27
Unit:1
Arp received reply packet of src ip 192.168.88.1,

dst ip 192.168.88.200, src mac 0016.3e28.5657,
dst mac 00e0.d021.0203 deals successfully

Output Item
Description
IP ARP:rcvd rep src 192.168.88.1
Monitors ARP. The source IP address and
0016.3E28.5657, dst 192.168.88.200
MAC address of the received response packet
00E0.D021.0203
is 192.168.88.1 and 0016.3E28.5657, and its

destination IP address and MAC address are
192.168.88.200 and 00E0.D021.0203.
Arp received reply packet of src ip 192.168.88.1,
Monitors packet sending and receiving. The
dst ip 192.168.88.200, src mac 0016.3e28.5657,
source IP address and MAC address of the
dst mac 00e0.d021.0203 deals successfully
received response packet is 192.168.88.1 and

0016.3e28.5657, and its destination IP address
and MAC address are 192.168.88.200 and
00e0.d021.0203.
3.3 ARP Configuration Instances

3.3.1 Example 1: Configuring Permanent ARP Entry
Configuration Description
Configure permanent ARP entries on an interface.
3-5
SJ-20100901100356-015|2011-07-30(R1.0)
Configuration Procedure
In the interface configuration mode, note that the IP address of the interface to be
configured with permanent ARP entries must be set.
ZXCTN 9000(config)#interface vlan 1
ZXCTN 9000(config-if-vlan1)#set arp permanent 120.1.1.1 0020.1122.3344
The configuration of permanent ARP entries on a supervlan interface is similar to that on a

physical interface. The only difference lies in that the configuration on a supervlan interface
requires the VLAN-ID parameter.
ZXCTN 9000(config-supervlan1)#set arp permanent 120.1.1.5 0020.1122.3366 1
Configuration Verification
Use the show command to view the configuration result.
ZXCTN 9000(config)#show arp static
The count is 1
IP Address
Age Hardware Address
Interface
Exter VlanID
Inter VlanID
Sub Interface
-----------------------------------------------------------------------------------------120.1.1.1
0020.1122.3344
vlan1
N/A
N/A
N/A
Inter VlanID
Sub Interface
ZXCTN 9000(config)#show arp 120.1.1.3

The count is 1
IP Address
Age Hardware Address
Interface
Exter VlanID
-----------------------------------------------------------------------------------------120.1.1.3
0020.1122.3355
vlan1
N/A
N/A
N/A
ZXCTN 9000(config)#show arp interface supervlan1

The count is 1
IP Address
Age
Hardware Address
Interface
Exter VlanID
Inter VlanID
Sub Interface
-----------------------------------------------------------------------------------------120.1.1.5
0020.1122.3366
supervlan1
N/A
N/A
3.3.2 Example 2: Configuring Common ARP Attribute

The common ARP functions are shown below:
ZXCTN 9000(config-if-vlan1)#no arp learn
/*Disables the ARP learning function

on an interface.*/
ZXCTN 9000(config-if-vlan1)#ip proxy-arp
/*Enables the ARP proxy function.*/
ZXCTN 9000(config-if-vlan1)#no arp source-filtered
/*Disables the source filtering
ZXCTN 9000(config-if-vlan1)#arp timeout 10
/*Sets the aging time to 10s.*/
function.*/
ZXCTN 9000(config-if-vlan1)#ex
ZXCTN 9000(config)#interface gei_1/3
3-6
SJ-20100901100356-015|2011-07-30(R1.0)

ZXCTN 9000(config-gei_1/3)#arp protect interface limit-num 10 /*Sets the upper limit
for the number of ARP
entries to 10.*/
ZXCTN 9000(config)#show running-config interface gei_1/3
/*Views the configuration

result.*/
interface gei_1/3
ip proxy-arp
no arp source-filtered
no arp learn
arp protect interface limit-num 10
!
end
3.3.3 Example 3: Configuring ARP Proxy Application

As shown in Figure 3-1, host A identifies that host D is on the same network segment
according to the subnet mask. When host A needs to communicate with host D, host A
sends an ARP request to host D. The ARP request is shown below.
Senders MAC Addr
Senders IP
Target MAC Addr
Target IP
00-00-0c-94-36-aa
172.16.10.100
00-00-00-00-00-00
172.16.20.200
Figure 3-1 shows the configuration example.
3-7
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 3-1 Configuring ARP Proxy Application
The ARP request cannot reach host D, because the ZXCTN9000 does not forward
cross-VLAN broadcast packets in normal cases. Therefore, the communication fails
when ARP proxy is disabled.
When the ARP proxy function is enabled on the ZXCTN9000, the ZXCTN9000 processes
all valid IP addresses except the IP addresses in the VLAN of the local port and sends the
ARP packet with the egress MAC address as the response. The response is shown below.
Senders MAC Addr
Senders IP
Target MAC Addr
Target IP
00-00-0c-94-36-ab
172.16.20.200
00-00-0c-94-36-aa
172.16.10.100
As a result, the following item appears in the ARP table of host A.

ZXCTN 9000(config)#show arp
The count is 2
IP Address
Age
Hardware Address Interface ExterVlanID InterVlanID SubInterface
-------------------------------------------------------------------------------------172.16.20.200 00:00:03 0000.0c94.36ab
gei_1/1
N/A
N/A
gei_1/1
Enable the ARP proxy function on the ZXCTN9000.
ZXCTN 9000(config-if-vlan1)#exit
3-8
SJ-20100901100356-015|2011-07-30(R1.0)

interface vlan1
ip proxy-arp
!
end
interface vlan2
ip proxy-arp
!
end
3.3.4 Example 4: Configuring ARP Source Filtering Application

By default, the ARP source filtering function is enabled. When the function is enabled,
the ZXCTN9000 searches the routing table for the source IP address of a received ARP
packet and checks whether a route with the port as the egress is available. If a route is
found, the route is learned. If no route is found, the ARP packet is discarded.
Run the following commands.
ZXCTN 9000(config-if-vlan1)#no arp source-filtered
/*Disables the source filtering

function.*/
ZXCTN 9000(config)#show running-config interface vlan1
interface vlan1
!
end
ZXCTN 9000(config-if-vlan1)#arp source-filtered
/*Enables the source filtering

function.*/
ZXCTN 9000(config-if-vlan1)#show running-config interface vlan1

interface vlan1
!
end
3-9
SJ-20100901100356-015|2011-07-30(R1.0)
3.4 ARP Troubleshooting

Take the topology shown in Figure 3-2 as an example to describe how to handle a basic
ARP fault.
Figure 3-2 Network Topology for Handling Basic ARP Fault

A common fault is ARP learning failure. Possible causes include:
l
l
l
l
l
l
The status of the local or peer interface is Down.

The no arp learn command is executed on the local or peer interface.
ARP protection is enabled on the local or peer interface, and the number of ARP
entries reaches the upper limit.
A permanent ARP entry with an incorrect MAC address of the peer IP address is
configured on the local interface.
The local and peer IP addresses are on different network segments, and ARP source
filtering is enabled.
The process is faulty due to other causes.
3.4.3 Handling Flow

The flow to handle an ARP fault is shown in Figure 3-3.
3-10
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 3-3 Flow to Handle ARP Fault

The procedure to handle an ARP fault is described below.
1. View the status of interfaces.
ZXCTN 9000(config)#show ip interface brief
Interface
IP-Address
Mask
AdminStatus PhyStatus Protocol
vlan1
192.168.2.1
255.255.255.0
down
down
down
vlan2
12.1.1.1
255.255.255.0
up
up
up
vlan3
13.1.1.1
255.255.255.0
up
up
up
vlan4
14.1.1.1
255.255.255.0
up
up
up
3-11
SJ-20100901100356-015|2011-07-30(R1.0)

vlan5
15.1.1.1
255.255.255.0
up
up
up
2. View ARP configurations and check whether the ARP learning anomaly is caused by
the ARP protection function.
ZXCTN 9000(config-arp-if)#show running-config interface vlan3
/*Views the
configuration
result.*/
interface vlan3
ip proxy-arp
no arp learn
arp protect interface limit-num 10
!
end
3. Check whether any permanent ARP entry is configured with an incorrect MAC address.
ZXCTN 9000(config)#show arp
Arp protect whole is enabled
The count is 21
IP Address
Age Hardware Address Interface ExterVlanID InterVlanID SubInterface
-----------------------------------------------------------------------------------192.168.112.100
0020.1244.5566
vlan10
N/A
N/A
N/A
12.1.1.1
0020.1244.5566
vlan2
N/A
N/A
N/A
13.1.1.1
0020.1244.5566
vlan3
N/A
N/A
N/A
14.1.1.1
0020.1244.5566
vlan4
N/A
N/A
N/A
15.1.1.1
0020.1244.5566
vlan5
N/A
N/A
N/A
120.1.1.1
0020.1122.3344
vlan1
N/A
N/A
N/A
120.1.1.2
TS
0020.2222.3344
vlan1
N/A
N/A
N/A
120.1.1.3
0020.1122.3355
vlan2
N/A
N/A
N/A
120.1.1.4
TS
0020.1122.3355
vlan2
N/A
N/A
N/A
20.1.1.1
0020.1244.5566
vlan1
N/A
N/A
N/A
120.1.1.5
0020.1122.3366
vlan1
N/A
N/A
120.1.1.6
TS
0020.1122.3366
vlan1
N/A
N/A
21.1.1.1
0020.1244.5566
vlan1
N/A
N/A
N/A
120.1.1.7
0020.1122.3377
vlan1
N/A
N/A
192.168.2.1
0020.1244.5566
vlan1
N/A
N/A
N/A
In the Age column, P indicates a permanent ARP entry, and TS indicates a static ARP
entry.
4. Run the debug command to check ARP packet sending, receiving, and response.
ZXCTN 9000#debug packets destination 192.168.2.1
ZXCTN 9000#debug arp packets interface vlan1
ZXCTN 9000#debug arp trace receive destination 192.168.2.1
ZXCTN 9000#debug arp trace receive source 192.168.2.1
3-12
SJ-20100901100356-015|2011-07-30(R1.0)

ZXCTN 9000#
ZXCTN 9000#terminal monitor
5. Check port configurations to check whether the traffic is sent to the destination.
3-13
SJ-20100901100356-015|2011-07-30(R1.0)
3-14
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 4
RIP Configuration
Table of Contents
Configuring RIP..........................................................................................................4-1
RIP Maintenance and Diagnosis.................................................................................4-7
RIP Configuration Example ......................................................................................4-12
RIP Troubleshooting.................................................................................................4-14
4.1 Configuring RIP

4.1.1 Configuring Basic RIP Functions
Use these commands to configure basic RIP functions on the ZXCTN 9000.
1. Enabling RIP
Step
Command
Function
ZXCTN9000(config)#router rip
Enables the RIP process and enters

the RIP configuration mode.
ZXCTN9000(config-rip)#network < ip-address> < wildcard-mask>
Enables RIP in the specified network.
2. Adjusting the RIP timer

Step
Command
Function
Enables the RIP process and enters

the RIP configuration mode.
ZXCTN9000(config-rip)#timers basic < update> < invalid> <
Adjusts the RIP timer.
holddown> < flush>

3
ZXCTN9000(config-rip)#output-delay < packets> < delay>
Changes the interval at which a

number of RIP update packets are
sent.

Parameter
Description
< update>
Indicates the interval between update packets. The unit is second.

The value of this parameter ranges from 1 to 65535. The default
value is 30.
4-1
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< invalid>
Indicates the duration before a route is declared invalid. The unit is

second. The value of this parameter ranges from 1 to 65535. The
default value is 180. It is recommended to set this parameter to larger
than three times the value of update.
If a route is not refreshed within invalid after the route is received, the
route is declared invalid and the ZXCTN9000 enters the holddown
state. If holddown is set to 0, the flush timer directly starts.
< holddown>
Indicates the duration for suppressing better route information. The

unit is second. The value of this parameter ranges from 0 to 65535.
The default value is 180. It is recommended to set this parameter to
larger than three times the value ofupdate .
When the ZXCTN9000 receives an update packet and learns that the
route is unreachable or the invalid timer times out, the route is invalid
and the ZXCTN9000 enters the holddown state. The route is marked
unavailable and declared unreachable, but it is still used for packet
forwarding. After the holddown period, routes advertised by other
sources can be received and the route is available again.
< flush>
Indicates the duration from a route is declared invalid to it is cleared.

The unit is second. The value of this parameter ranges from 1 to
65535. The default value is 240.
The value of this parameter cannot be smaller than that of holddown.
If the value of this parameter is smaller than that of holddown, new
route information may be received before the holddown timer times
out.

Parameter
Description
< packets>
Indicates the number of packets. The value of this parameter ranges

from 1 to 4294967295. The default value is 5.
< delay>
Indicates the interval at which packets of the specified number are

sent. The unit is millisecond. The value of this parameter ranges from
0 to 100. The default value is 100.
Example
A configuration example of setting the time parameters of RIP is shown below.
ZXCTN9000(config-rip)#timers basic 5 15 15 30
ZXCTN9000(config-rip)#output-delay 500 10
The configuration result is as follows:

l
The interval between RIP update packets is 5s.

4-2
SJ-20100901100356-015|2011-07-30(R1.0)
l
l
l
l
The duration before a route is declared invalid is 15s.

The duration of the holddown state of the ZXCTN9000 is 15s.
The ZXCTN9000 clears a route 30s after the route is declared invalid.
500 packets are sent every 10 ms.
4.1.2 Configuring Enhanced RIP Functions

Use these commands to configure enhanced RIP functions on the ZXCTN 9000.
1. Configuring RIP neighbors
Step
Command
Function
Enters the RIP configuration mode.
ZXCTN9000(config-rip)#neighbor < ip-address>
Defines the neighbors that exchange

routing information with the ZXCTN9000.
This command is required on
non-broadcast links.
A maximum of 255 neighbors can be
detected or configured at the same time.
This command allows point-to-point exchange of RIP routing information. Once a

neighbor (an interface) is specified, interfaces on the same network with the interface
do not exchange RIP routing information through broadcast (or multicast).
2. Configuring RIP authentication
RIPv2 supports plain-text authentication and MD5 authentication. Passwords are
required on neighboring interfaces. Neighbors must use the same authentication
mode and password on the network. RIPv1 does not support authentication.
Use these commands to configure plain-text authentication for RIP packets.
Step
Command
Function
ZXCTN9000(config)#interface < vlan id>
Enters the interface configuration mode.
ZXCTN9000(config-if-vlanX)#ip rip authentication mode text
Configures the interface to use plain-text

authentication for RIP packets.
ZXCTN9000(config-if-vlanX)#ip rip authentication key <
Configures the key for plain-text
key>
authentication. The value of this

parameter ranges from 1 to 16
characters.
Use these commands to configure MD5 authentication for RIP packets.

Step
Command
Function
4-3
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-if-vlanX)#ip rip authentication mode
Configures the interface to use MD5
md5
authentication for RIP packets.
ZXCTN9000(config-if-vlanX)#ip rip authentication key-chain
Configures key-chain for MD5
< key-id> < key-string>
authentication.

Parameter
Description
< key-id>
Indicates the ID of the key in the key-chain. The value of this

parameter ranges from 1 to 255.
< key-string>
Indicates the value of the key. The value of this parameter ranges
from 1 to 16 characters.
3. Configuring split horizon and poison reverse

Step
Command
Function
ZXCTN9000(config-if-vlanX)#ip split-horizon
Enables split horizon. By default, split

horizon is enabled. You can use the no
command to disable the function.
ZXCTN9000(config-if-vlanX)#ip poison-reverse
Enables poison reverse. By default,

poison reverse is enabled. You can use
the no command to disable the function.
It is not recommended to disable split horizon, unless for the purpose of correctly
advertising routes. To make split horizon on a serial interface (connected to a PSN)
invalid, you need to disable split horizon on all related ZXCTN9000s and access
servers.
4. Configuring route redistribution
Use these commands to redistribute routes of one protocol to RIP.
Step
Command
Function
ZXCTN9000(config-rip)#redistribute < protocol> [ process-id]
Redistributes routes of other protocols
[ metric < metric-value> ] [ route-map < name> ]
to RIP.
4-4
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
[ process-id]
Indicates the process ID. This parameter is required for redistributing OSPF
or IS-IS routes. The value range of this parameter is as follows:
l
ospf: 1-65535
isis: 1-65535

< protocol>
Indicates the routing protocol whose routes are to be redistributed. The

value of this parameter can be ospf-ext, ospf-int, static, bgp-ext, bgp-int,
connected, isis-1, isis-2, or isis-1-2.
metric < metric-value>
Indicates the metric of the route to be introduced. If this parameter is not

specified, default-metric is adopted. The value of this parameter ranges
from 0 to 16.
route-map < map-tag>
Indicates the name of the route mapping for redistribution. The value of this
parameter ranges from 1 to 31 characters.
4.1.3 Configuring the RIP Version

The ZXCTN9000 supports both RIPv1 and RIPv2. By default, RIPv2 is used. Use these
commands to configure the RIP version for sending or receiving on the ZXCTN 9000.
Step
Command
Function
ZXCTN9000(config-rip)#version { 1| 2}
Configures RIPv1 or RIPv2. The default

value is RIPv2.
As shown in the following table, if the RIP version for sending or receiving is configured on
an interface, the default RIP version configured by the version command is invalid.
Step
Command
Function
ZXCTN9000(config-if-vlanX)#ip rip receive version { 1 | 2}
Configures the RIP version for receiving

on the interface as RIPv1 or RIPv2. If the
version command is not executed, the
default value (both RIPv1 and RIPv2) is
used.
ZXCTN9000(config-if-vlanX)#ip rip send version { 1 | 2 {
Configures the RIP version for sending on
broadcast | multicast} }
the interface as RIPv1 or RIPv2.
4-5
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
Indicates that the interface sends only RIPv1 packets.
Indicates that the interface sends only RIPv2 packets. In this case, you can select the
broadcast or multicast mode.
Indicates that the interface sends compatible packets in broadcast mode and only routes
broadcast
of natural networks are sent.

Indicates that the interface sends RIPv2 packets in multicast mode and subnet routes
multicast
can be sent as required by the auto-summary command.
4.1.4 Configuring RIP Routing Load Balancing

Routing load balancing can improve:
l
Link reliability: The transport layer poses high requirements on stability and reliability.
The reliability covers the link itself and whether packet forwarding is affected in the
case of link faults.
Bandwidth: Routing load balancing enables the ZXCTN9000 to balance traffic by
multiple paths, fully utilizing bandwidth resources. The configuration of routing
protocols or static routes realizes multiple routes available for one destination
address in the forwarding table.
Load balancing supports per-packet and per-destination forwarding. The following table
shows the advantages and disadvantages of the two methods:
Per-destination
per-packet
Advan-
Even if multiple routes are available for one
Path usage is high. Since this method
tage
destination, only one route is used. Packets
uses polling to determine paths for packets,
to different destinations are routed along
traffic is balanced among paths.
different paths.
Disad-
In the case of few destinations, traffic may
Traffic to one destination may be routed
van-
be routed through a small number of paths,
through different paths, resulting in the
tage
making load unbalanced. This method
sequencing of receiving ends. Therefore,
achieves effective load balancing only in the
this method is not applicable to traffic
case of many destinations.
requiring specific sequence, such as VoIP.
Use these commands to configure RIP routing load balancing on the ZXCTN 9000.
Step
Command
Function
Enters the RIP routing configuration mode.
ZXCTN9000(config-rip)#maximum-paths < number>
Configures the maximum of routes for

load balancing supported by the protocol.
The value of this parameter ranges from 1
to 8. The default value is 1.
4-6
SJ-20100901100356-015|2011-07-30(R1.0)
4.2 RIP Maintenance and Diagnosis

4.2.1 RIP show Command
Use these show commands to maintain RIP on the ZXCTN 9000.
Command
Function
ZXCTN9000(config)#show ip rip [ vrf < vrf-name> ]
Shows basic RIP running information.
ZXCTN9000(config)#show ip rip interface [ vrf < vrf-name> ] < vlan id>
Shows the current configuration and

status of RIP-enabled interfaces.
ZXCTN9000(config)#show ip rip database [ vrf < vrf-name> ] [ network <
Shows routes generated by RIP.
ip-address> [ mask < net-mask> ] ]

ZXCTN9000(config)#show ip rip networks [ vrf < vrf-name> ]
Shows the information about all

RIP-enabled interfaces configured by
users through commands.
ZXCTN9000(config)#show ip rip neighbors[ vrf < vrf-name> ]
Shows the information about RIP

neighbors.

Parameter
Description
vrf < vrf-name>
Indicates the VRF name. The value of this parameter ranges from
1 to 32 characters.
network < ip-address>
Indicates the network ID, in dotted decimal notation.
mask < net-mask>
Indicates the network mask, in dotted decimal notation.
< interface-name>
Indicates the name of the RIP-enabled interface.
The execution result of the show ip rip command is shown below.

ZXCTN9000#show ip rip
router rip
auto-summary
default-metric 1
distance 120
validate-update-source
version 2
flash-update-threshold 5
maximum-paths 1
output-delay 5 100
timers basic 30 180 180 240
network
10.0.0.0
0.255.255.255

4-7
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
auto-summary
Configures the ZXCTN9000 to send only the routes (RIPv2) of natural

and super networks summarized. You can use the no command to
send all RIP routes. Even if the auto-summary command is configured,
the following policy still takes effect: when the ZXCTN9000 has an RIP
subnet route to the natural network where an RIP-enabled interface
resides, the RIP update packets sent from the interface does not
contain the route to the natural network where the interface resides,
but the packets contain the RIP routes to the other subnets on the
same natural network.
default-metric
Sets the default metric of routes generated by other protocols and to

be redistributed to RIP. You can use the no command to restore the
default value, that is, 1. If this command is used together with the
redistribute command, the current routing protocol uses the same
metric for all routes to be redistributed. This command solves the
redistribution of routes of different metrics. If the metric is not specified,
the default metric offers a reasonable solution for redistribution.
distance
Defines the distance for RIP routing management. You can use the
no command to restore the default value, that is, 120. The value of
this parameter determines the selection of the best route in the global
routing table.
validate-update-source
Enables the function of checking whether the source IP addresses of

RIP update packets received are valid. You can use the no command
to make the function invalid.
flash-update-threshold
Defines the RIP flash timer. You can use the no command to restore
the default value, that is, 5. The flash timer can be changed as
required.
maximum-paths
Configures the number of routes supported by load balancing. You

can use the no command to restore the default value, that is, 1. The
number of valid routes that can be received by RIP can be changed
based on load balancing requirements.
The execution result of the show ip rip database command is shown below.
ZXCTN9000(config)#show ip rip database
Routes of rip:
h : is possibly down,in holddown time
f : out holddown time before flush
Dest
Metric RtPrf
InstanceID
Time
From
*> 137.1.0.0/16
254
00:00:12
0.0.0.0
*> 137.1.1.0/24
00:00:00
0.0.0.0
4-8
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
Metric
Indicates the metric of the route. If the value of this parameter is set to
16, the route is declared invalid.
RtPrf
Indicates the priority of the route. The value of this parameter shows
the reliability of the route. The priority of a route after aggregation is
254. If the value is 255, the route is invalid.
InstanceID
Indicates the instance of the route ID. This parameter is valid only to
OSPF and IS-IS routes.
Time
Indicates the duration of the route and the status of its timer.
From
Indicates where the route is learned. From 0.0.0.0 indicates that the
route is generated by the local ZXCTN9000.
The execution result of the show ip rip interface command is shown below.
ZXCTN9000(config-rip)#show ip rip interface vlan 1
ip address:137.1.1.2/24 rip is enabled
receive version 1 2
send version 2
split horizon is effective
poison reverse is effective
send subnet only is ineffective
notify default unset
originate default unset
neighbor restrict is ineffective
interface is nomoral
authentication type:none

Output Item
Description
send subnet only
Configures the interface to send only the routing information of the

same subnet, but not other subnets. This command is used for
an inferior ZXCTN9000 to report routing information to its superior
ZXCTN9000, because in this case only the information about the local
subnet is required. This can reduce redundant route advertisement.
notify default
Configures the routes sent by the interface to contain the default

route. If key word Parameteronly is included in this command, only
the default route is sent by the interface.
4-9
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
originate default
Generates a default route on the interface and forcibly advertises it.

If key word Parameteronly is included in this command, only the
default route is sent by the interface. After this command is executed,
a default route is generated on the interface and forcibly advertised,
but the route is not added to the routing table of the local ZXCTN9000.
The route is added to the routing table of the neighboring ZXCTN9000.
neighbor restrict
Indicates the interface neighbor restrict mode. When the ZXCTN9000

enters the interface neighbor restrict mode and no neighbor is
configured on the interface, the ZXCTN9000 can detect a neighbor,
but still sends multicast (not unicast) packets to the neighbor. In
this case, the ZXCTN9000 can receive packets from the detected
neighbor. After a neighbor is configured on the interface, the detected
neighbor on the interface is deleted. The ZXCTN9000 cannot detect
neighbors and sends unicast (not multicast) packets to the configured
neighbor. In this case, the ZXCTN9000 can receive packets only from
the configured neighbor, but discards packets from other sources.
Therefore, to make the function take effect, you must configure the
interface neighbor restrict mode on both ZXCTN9000s and enable the
neighboring relationship between them.
The execution result of the show ip rip neighbors command is shown below.
ZXCTN9000#show ip rip neighbors
neighbor address
interface
10.1.1.15
vlan 1

Output Item
Description
neighbor address
Indicates the IP address of the RIP neighbor.
interface
Indicates that the interface of the neighbor is learned.
4.2.2 RIP debug Command

Use these debug commands to debug RIP and monitor related information.
Command
Function
ZXCTN9000#debug ip rip
Monitors RIP packet sending and

receiving.
ZXCTN9000#debug ip rip all
Enables all the RIP debugging switches.
ZXCTN9000#debug ip rip events
Monitors RIP-related events.
4-10
SJ-20100901100356-015|2011-07-30(R1.0)
Command
Function
ZXCTN9000#debug ip rip database
Monitors the change of the RIP routing

table.
Monitors events triggered by RIP.
ZXCTN9000#debug ip rip trigger
The execution result of the debug ip rip command is shown below.

ZXCTN9000#debug monitor
ZXCTN9000#debug ip rip
RIP protocol debugging is on
ZXCTN9000#
11:01:28: RIP: building update entries
130.1.0.0/16 via 0.0.0.0, metric 1, tag 0
130.1.1.0/24 via 0.0.0.0, metric 1, tag 0
177.0.0.0/9 via 0.0.0.0, metric 1, tag 0
193.1.168.0/24 via 0.0.0.0, metric 1, tag 0
197.1.0.0/16 via 0.0.0.0, metric 1, tag 0
199.2.0.0/16 via 0.0.0.0, metric 1, tag 0
202.119.8.0/24 via 0.0.0.0, metric 1, tag 0
11:01:28: RIP: sending v2 periodic update to 224.0.0.9
via pos3_3/1 (193.1.1.111)
130.1.0.0/16 via 0.0.0.0, metric 1, tag 0
130.1.1.0/24 via 0.0.0.0, metric 1, tag 0
177.0.0.0/9 via 0.0.0.0, metric 1, tag 0
193.1.1.0/24 via 0.0.0.0, metric 1, tag 0
via gei_1/1 (193.1.168.111)
via gei_1/1 (193.1.168.111)
via gei_1/1 (193.1.168.111)
via gei_1/1 (193.1.168.111)

Output Item
Description
224.0.0.9
Advertises RIP routes in multicast mode.
via vlan 1
Advertises routes through an interface.
4-11
SJ-20100901100356-015|2011-07-30(R1.0)
4.3 RIP Configuration Example

Configuration Configuration
RIPfeatures easy implementation principle and configuration method. It is mainly applied
in the network of simple topology. Figure 4-1 shows the typical RIP networking. The
following describes the basic RIP configuration based on the figure. RIP should run on P1
and P2.
Figure 4-1 Topology of the RIP Configuration Example
Configuration Method
1.
2.
3.
4.
Configure the IP addresses of interfaces.

Configure RIP.
Enable RIP configurations on interfaces.
Verify the configuration to check that RIP neighboring relationship is established and
P1 and P2 can learn the route advertised by each other.
P1(config)#interface vlan 1
P1(config-if-vlan1)#ip address 192.168.1.1 255.255.255.0
P1(config-if-vlan1)#exit
P1(config)#router rip
P1(config-rip)#network 192.168.1.1 0.0.0.255
P1(config-rip)#exit

P2(config)#interface vlan2
P2(config)#router rip
4-12
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-rip)#end
When the above configurations are completed, view the result on P1 and P2. If the
following information is displayed, RIP neighboring relationship is established. In addition,
P1 and P2 can learn the interface route from each other and ping through each other.
Run the show running-config rip command on P1 to check whether the RIP configuration
is correct.
P1(config-rip)#show running-config rip
router rip
network 192.168.1.0 0.0.0.255
network 10.1.0.0 0.0.255.255
interface vlan 1
$
interface vlan 2
$
!
P1(config)#show ip rip database

Routes of rip:
Dest
Metric
RtPrf
Time
From
*> 10.0.0.0/8
120
00:00:12
192.168.1.2
254
00:00:29
0.0.0.0
*> 10.1.0.0/16
00:00:00
0.0.0.0
*> 192.168.1.0/24
00:00:00
0.0.0.0
10.0.0.0/8
P1(config)#show ip rip neighbors

neighbor address
192.168.1.2
interface
vlan 1
Run the show running-config rip command on P2 to check whether the RIP configuration
is correct.
P2(config)#show running-config rip
router rip
network 192.168.1.0 0.0.0.255
network 10.2.0.0 0.0.255.255
interface vlan 1
$
interface vlan 2
4-13
SJ-20100901100356-015|2011-07-30(R1.0)

$
!
P2(config)#show ip rip database

Routes of rip:
Dest
Metric
*> 10.0.0.0/8
RtPrf
254
Time
00:00:03
From
0.0.0.0
*> 10.2.0.0/16
00:00:00
0.0.0.0
*> 192.168.1.0/24
00:00:00
0.0.0.0
P2(config)#show ip rip neighbors

neighbor address
interface
192.168.1.1
vlan 1
4.4 RIP Troubleshooting

Take the topology shown in Figure 4-2 as an example to describe how to handle an RIP
fault, such as the fault that the neighboring relationship cannot be established in the default
configuration, or a route cannot be correctly learned.
Figure 4-2 Network Topology for Handling an RIP Fault

P1 and P2 cannot discover the neighbor or learn the route. Check the hardware, including
the main control board, line card, interface board, and network cable (checking whether
P1 and P2 can ping through each other).
If the hardware works properly, check the software. Check the consistency of the global
RIP configuration, including the information of version, network, time basic, disable
interface, and redistribute. Check the RIP configuration on the interface, including the type
of packets sent and received on the RIP interface, authentication type, and passive/active
modes. For special default routes and subnet advertisement, check the configuration of
notify and only-send-subnet. The following describes the detailed handling flow.
4-14
SJ-20100901100356-015|2011-07-30(R1.0)
4.4.3 Handling Flow

The flow to handle an RIP fault is shown in Figure 4-3.
Figure 4-3 Flow to Handle an RIP Fault
4-15
SJ-20100901100356-015|2011-07-30(R1.0)

The procedure to handle an RIP fault is described below.
1. Check whether the management state and protocol state of the two ends of the
directly-connected interface are up. Check whether the cable is correctly connected
and whether the interface board works properly.
2. Check whether the interface IP address is correctly configured and reachable and
whether the peer ARP can be learned.
3. Use the no version command to restore the default version configuration (the v1 and
v2 versions are currently supported). Use the show ip rip database command to view
the network interface address and network segment. Make sure that the RIP timer
configurations of all routers on the network are consistent (the default configuration
is generally adopted). Enable all RIP interfaces (the default status is enabled). Use
the show ip rip database command to make sure that the routes learned from other
protocols are redistributed to RIP through the redistribute or parameterroute-map
mode.
4. View the RIP configuration of the directly-connected interface (through the show runni
ng-config rip command) to check whether the packet types, authentication types, and
passive/active modes of packets sent and received by the interface are consistent.
Run the no ip rip command on the interface to restore the default configuration, and
check whether the interface requiring authentication is configured with the correct
authentication type and authentication string.
4-16
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 5
OSPF Configuration
Table of Contents
Configuring OSPF ......................................................................................................5-1
OSPF Configuration Instances .................................................................................5-44
OSPF Troubleshooting .............................................................................................5-54
5.1 Configuring OSPF

5.1.1 Configuring Basic OSPF Functions
Use these commands to enable the OSPF process on the ZXCTN9000, so that the
ZXCTN9000 can learn routes through OSPF.
Step
Command
Function
ZXCTN9000(config)#router ospf < process-id> [ vrf < vrf-name> ]
Enables the OSPF process to run

the OSPF protocol and enter the
OSPF configuration mode.
After OSPF is enabled, one of the
current interfaces is selected as the
router ID for OSPF.
When the interfaces of the
ZXCTN9000 has no IP address, the
router ID cannot be selected. In this
case, configure an interface address
for the OSPF to dynamically obtain
or manually configure the router ID
and clear the OSPF process.
ZXCTN9000(config-router)#network < ip-address> < wildcard-mask>
Indicates the interface running OSPF
area < area-id>
and the area ID of the interface. If

the area does not exist, a new area
is created.
ZXCTN9000(config-router)#router-id < ip-address>
Configures the router ID of the

ZXCTN9000.
The loopback interface address is
recommended as the router ID for
the ZXCTN9000.
5-1
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-router)#end
Returns to the privilege mode.
ZXCTN9000#clear ip ospf process < process-id>
Restarts the OSPF process.
Example
As shown in Figure 5-1, enable OSPF on P1, P2, and P3.
The router IDs of devices are described in the table below.
Device
Router ID
P1
1.1.1.1
P2
1.1.1.2
P3
1.1.1.3
Figure 5-1 Configuration Example

P1(config)#interface loopback1
P1(config-loopback1)#ip adderss 1.1.1.1 255.255.255.255
P1(config-loopback1)#exit
P1(config)#interface gei_1/1
P1(config-gei_1/1)#switchport access vlan 1
P1(config-gei_1/1)#exit
P1(config)#router ospf 1
P1(config-router)#network 30.0.0.0 0.0.0.3 area 0
P1(config-router)#exit
View the OSPF information.

P1(config)#show ip ospf
OSPF 1 Router ID 1.1.1.1 enable
Enabled for 00:00:21,Debug on
Number of areas 1, Stub 0, Transit 0
5-2
SJ-20100901100356-015|2011-07-30(R1.0)

Number of interfaces 1
Area 0.0.0.0 enable

Enabled for 00:00:05
Area has no authentication
Times spf has been run 1
Number of interfaces 1. Up 1
The basic OSPF configuration on P1 is completed, and the OSPF process is successfully
enabled. The router ID is the address of the vlan1 interface.
Configure P2. Use the loopback interface to establish the OSPF connection. First,
configure a loopback address and then enables the OSPF process, as shown in the
following:
View the OSPF information. OSPF automatically selects the address of loopback1 as the
router ID.
Number of areas 0, Normal 0, Stub 0, NSSA 0

5-3
SJ-20100901100356-015|2011-07-30(R1.0)

View the routing table on P3.

P3#show ip route
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri
Metric
loopback1
address
ospf
110
1.1.1.3
255.255.255.255
1.1.1.3
30.0.0.1
255.255.255.255
30.0.1.2
vlan1
30.0.0.2
255.255.255.255
30.0.1.2
vlan1
ospf
110
12
30.0.1.0
255.255.255.252
30.0.1.1
vlan2
direct
30.0.1.1
255.255.255.255
30.0.1.1
vlan2
address
30.0.1.2
255.255.255.255
30.0.1.2
vlan2
110
ospf
If P3 can ping through P1, it indicates that the route and OSPF work properly.
5.1.2 Configuring OSPF Interface Attribute

Use these commands to modify the attributes of the OSPF interface, so that the OSPF
neighboring relationship can be established. The interface attributes need to be modified
for the interconnection of devices from different vendors.
Step
Command
Function
Enables the OSPF protocol.

mode.
5-4
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-if-vlanX)#ip ospf hello-interval < seconds>
Indicates the Hello packet sending

interval. The unit is second. The
value of this parameter ranges from
ZXCTN9000(config-if-vlanX)#ip ospf dead-interval < seconds>
Indicates the dead interval. The

unit is second. The value of this
ZXCTN9000(config-if-vlanX)#ip ospf retransmit-interval <
Indicates the LSA retransmission
seconds>
interval. The unit is second. The

ZXCTN9000(config-if-vlanX)#ip ospf transmit-delay < seconds>
Indicates the transmission delay.

The unit is second. The value of this
ZXCTN9000(config-if-vlanX)#ip ospf cost < cost>
Configures the interface cost. The

1 to 65535. The default value is
100M/interface bandwidth. The route
LSA whose metric value is 65535 is
not counted in route calculation.
ZXCTN9000(config-if-vlanX)#ip ospf priority < priority>
Configures the interface priority. The

value of this parameter ranges form
Example
As shown in Figure 5-2, modify the default parameter of the OSPF interfaces on P1 and
P2.
Figure 5-2 Configuring OSPF Interface Attribute
Enable the OSPF protocol on P1 and P2 and advertise the network segment.
5-5
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-router)#router-id 1.1.1.1

P2(config-if)#ip adderss 1.1.1.2 255.255.255.255
P2(config-if)#exit
P2(config-if)#ip address 30.0.0.2 255.255.255.252
P2(config-if)#exit
P2(config-ospfv2)#router-id 1.1.1.3
P2(config-ospfv2)#network 30.0.0.0 0.0.0.3 area 0
P2(config-ospfv2)#exit
Modify the default OSPF attributes of the interface.

P1(config-if-vlan1)#ip ospf hello-interval 20
/*Sets the Hello packet sending interval to 20 seconds.*/
P1(config-if-vlan1)#ip ospf dead-interval 80
/*Sets the dead interval to 80 seconds.*/
P1(config-if-vlan1)#ip ospf retransmit-interval 10
/*Sets the LSA retransmission interval to 10 seconds.*/
P1(config-if-vlan1)#ip ospf retransmit-delay 2
/*Sets the transmission delay to 2 seconds.*/
P1(config-if-vlan1)#ip ospf cost 10
/*Sets the interface cost to 10.*/
P1(config-if-vlan1)#ip ospf priority 10
/*Sets the priority to 10.*/
5-6
SJ-20100901100356-015|2011-07-30(R1.0)
5.1.3 Configuring OSPF Authentication

To enhance the security of the routing processes on the network, OSPF authentication
can be configured on routers. When a password is configured for the interface, the OSPF
neighbor must uses the same password on the network.
Step
Command
Function
ZXCTN 9000(config)#router ospf < process-id> [ vrf <
Enters the OSPF route configuration
vrf-name> ]
mode.
ZXCTN 9000(config-router)#area < area-id>
Enables the OSPF authentication
authentication [ message-digest]
function.
mode.
ZXCTN 9000(config-if-vlan1)#ip ospf
Configures the authentication mode
authentication [ null| message-digest]
for the interface.
Sets the authentication key for
authentication-key < password>
the interface configured with key

authentication.
Sets the key ID and authentication
message-digest-key < keyid> md5 < password> [ delay
key for the interface configured with
< time> | encrypt [ delay < time> ] ]
digest authentication.

Parameter
Description
< keyid>
Indicates the key ID. The value of this parameter is

an integer ranging from 1 to 255.
md5< password>
Indicates the authentication key. The value of this

parameter ranges from 1 to 24 characters (space
excluded).
delay < time>
Indicates the delay. The unit is unit. The value of

this parameter ranges from 0 to 100000.
encypt
Encrypts the configured authentication key.
Example
As shown in Figure 5-3, configure the OSPF authentication function on P1 and P2.
Device
Router ID
P1
1.1.1.1
P2
1.1.1.2
P3
1.1.1.3
5-7
SJ-20100901100356-015|2011-07-30(R1.0)
In area 0, establish the OSPF neighboring relationship between P1 and P2. In area 1,
establish the OSPF neighboring relationship between P2 and P3.
P1(config-gei_1/1)#swithport access vlan1

5-8
SJ-20100901100356-015|2011-07-30(R1.0)


Enable the plain text authentication in area 0 and configure zte as the packet to be
authenticated.
P1(config-router)#area 0 authentication
P1(config-if-vlan1)#ip ospf authentication
P1(config-if-vlan1)#ip ospf authentication-key zte

P2(config-router)#area 0 authentication
5-9
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-if-vlan1)#ip ospf authentication
P2(config-if-vlan1)#ip ospf authentication-key zte
Run the show ip ospf command. The simple authentication takes effect in area 0.
Number of areas 1, Stub 0, Transit 0
Area 0.0.0.0 enable

Area has simple password authentication
Number of ASBR local to this area 0
Number of ABR local to this area 1
Enable the MD5 authentication in area 1. The key ID is 1 and the authentication key is zte.
P2(config-router)#area 1 authentication message-digest
P2(config-if-vlan2)#ip ospf authentication message-digest
P2(config-if-vlan2)#ip ospf message-digest-key 1 md5 zte

P3(config-router)#area 1 authentication message-digest
P3(config-if-vlan2)#ip ospf authentication message-digest
P3(config-if-vlan2)#ip ospf message-digest-key 1 md5 zte
View the OSPF interface information on P3. The authentication mode is MD5.
P3(config)#show ip ospf interface vlan2
OSPF Router with ID (1.1.1.3) (Process ID 1)
Vlan2 is up
Internet Address 30.0.1.2 255.255.255.252 enable
5-10
SJ-20100901100356-015|2011-07-30(R1.0)

Up for 00:09:38
In the area 0.0.0.1 BDR
Cost 1, Priority 1, Network Type broadcast
Transmit Delay(sec) 1, Authentication Type message-digest
5.1.4 Configuring OSPF Stub Area

The OSPF protocol is already enabled between ZXCTN9000s and the area to be
configured is a non-backbone.
Uses these commands to reduce the size of the routing table and the memory requirement
of the ZXCTN9000 in the area.
Step
Command
Function

mode.
ZXCTN9000(config-router)#area < area-id> stub [ default-cost <
Configures the area as the stub area.
cost> ]
3
ZXCTN9000(config-router)#area < area-id> stub no-summary [
Disables the ABR from importing
default-cost < cost> ]
type 3 routing information in the stub

area, so that only one type 3 default
route is available.

Parameter
Description
no-summary
Disables the ABR from sending the summary routing information to

the stub area.
default-cost < cost>
Indicates the cost of the default route advertised to the stub area. The
value of this parameter ranges from 0 to 65535.
Example
As shown in Figure 5-4, configure area 1 as the stub area.
Device
Router ID
P1
1.1.1.1
P2
1.1.1.2
P3
1.1.1.3
5-11
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-gei_1/1) #switchport access vlan 1
P1(config-router)#redistribute connected

5-12
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-gei_1/2)#swithport access vlan 2
P2(config-router)#area 1 stub

P3(config-gei_1/1)# swithport access vlan2
P3(config-router)#area 1 stub
Connect P1, P2, and P3 according to the network topology.

To configure area 1 as the stub area, implement the following configuration on P2:
P2(config-router)#area 1 stub no-summary
Implement the following configuration on P3:

P3(config-router)#area 1 stub no-summary
5-13
SJ-20100901100356-015|2011-07-30(R1.0)
5.1.5 Configuring NSSA Area

The OSPF protocol is already enabled between ZXCTN9000s and the area to be
configured is a non-backbone or stub area.
An ASBR stub area is expected. In this area, the ZXCTN9000 can receive AS external
routes from the ASBR, but the external routes from other areas are blocked.
Certain devices on the network do no support the NSSA configuration and cannot identify
type 7 LSAs. Therefore, the ABR converts the type 7 LSAs generated to type 5 LSAs and
then advertises them. In addition, the advertiser of the LSAs are changed to the ABR. This
process is the route translation in OSPF. In this way, the devices outside the NSSA area
are not required to support the NSSA configuration.
Step
Command
Function

mode.
ZXCTN9000(config-router)#area < area-id> nssa [ no-redistribution]
Configure this area as an NSSA
[ default-information-originate [ metric < metric-value> ] [ metric-type
area, and determine whether to
< type> ] ] [ no-summary] [ trans-type7-suppress-fa] [ translator-role {
disable the ABR from sending the
always | candidate} ] [ translator-stab-intv < stab-intv> ]
summary routing information to the

NSSA area, whether to import type 7
LSAs to the NSSA area, and whether
to generate type 7 default LSAs.
By default, the routing information
is summarized, type 7 LSAs are
imported, type 7 default LSAs are
generated for the ASR but not for
non-ABR devices.

Parameter
Description
no-redistribution
Stops redistributing NSSA LSAs to the NSSA area.
default-information-originate
Generates type 7 LSAs.
metric< metric-value>
Indicates the metric value of the type 7 default LSA. The value of this
metric-type < type>
Indicates the type of type 7 LSAs. The value of this parameter can be
ext-1 or ext-2.
no-summary
Stops redistributing summary LSAs to the NSSA area.
trans-type7-suppress-fa
Suppresses forwarding addresses when type 7 LSAs are converted

to type 5 LSAs.
translator-role
Indicates the translation role when type 7 LSAs are converted to type
5 LSAs.
5-14
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
always|candidate
Indicates the translation role. The value of this parameter can be

always or candidate.
translator-stab-intv < stab-intv>
Indicates the translation role holding time after the translation role
is lost.
Example
As shown in Figure 5-5, configure area 1 as the NSSA area.
Device
Router-ID
P1
1.1.1.1
P2
1.1.1.2
P3
1.1.1.3

5-15
SJ-20100901100356-015|2011-07-30(R1.0)


P2(config-router)#area 1 nssa default-information-originate

5-16
SJ-20100901100356-015|2011-07-30(R1.0)

P3(config-router)#area 1 nssa

To configure this command on R2 (ABR ZXCTN9000) to stop type 3 LSAs entering the
NSSA area, implement the following configuration:
P2(config-router)#area 1 nssa default-information-originate no-summary
P2(config)#exit
5.1.6 Configuring Cross-Area Route Aggregation

The area is created and the command can be used only on the ABR.
Route aggregation saves resources in the backbone area by advertising a group of network
address as an aggregation address.
Configuring cross-area route aggregation
Step
Command
Function

mode.
ZXCTN9000(config-ospfv2)#area < area-id> range < ip-address>
Configures the range of aggregation
< net-mask> { summary-link | nssa-external-link} [ advertise |
addresses in the area.
not-advertise] [ tag < tag-value> ]

Parameter
Description
summary-link|nssa-external-link
Summary link: type 3 aggregation; NSSA external link: type 7

aggregation.
advertise
Advertises the status of type 3 aggregation or type 7 aggregation links.
not-advertise
Disables the advertisement of the status of type 3 aggregation links.

The routing information of this network segment is not received in
other areas.
5-17
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
tag< tag-value>
Configures the tag of the aggregation LSA. This parameter is valid

to type 7 aggregation. The value of this parameter ranges from 0
to 4294967295.
Example
As shown in Figure 5-6, configure OSPF on P1, P2, and P3, set P2 to the ABR, and
configure route aggregation on P2.
Device
Router-ID
P1
1.1.1.1
P2
1.1.1.2
P3
1.1.1.3
Implement common configurations on P1, P2, and P3.

5-18
SJ-20100901100356-015|2011-07-30(R1.0)



5-19
SJ-20100901100356-015|2011-07-30(R1.0)


After the configuration is completed, view the routing table on P3. Unaggregated routes
are available in the routing table.
P3#show ip route
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
loopback1
address
1.1.1.3
255.255.255.255
1.1.1.3
2.2.2.0
255.255.255.252
30.0.1.1
vlan3
2.2.2.4
255.255.255.252
30.0.1.1
30.0.0.0
255.255.255.255
30.0.0.2
255.255.255.255
30.0.1.0
Pri Metr
0
ospf
110
vlan2
ospf
110
30.0.1.1
vlan1
ospf
110
30.0.1.1
vlan1
ospf
110
255.255.255.252
30.0.1.2
vlan1
direct
30.0.1.1
255.255.255.255
30.0.1.1
vlan1
ospf
110
30.0.1.2
255.255.255.255
30.0.1.2
vlan1
address
Configure cross-area route aggregation on P2.

P2(config-router)#area 1 range 2.2.2.0 255.255.255.248 summary-link
Aggregation route to network segment 2.2.2.0/29 can be viewed on P3.

P3#show ip route
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
1.1.1.3
255.255.255.255
1.1.1.3
loopback1
address
2.2.2.0
255.255.255.248
30.0.1.1
vlan1
30.0.0.1
255.255.255.255
30.0.1.1
vlan1
30.0.0.2
255.255.255.255
30.0.1.1
30.0.1.0
255.255.255.252
30.0.1.1
255.255.255.255
30.0.1.2
255.255.255.255
Pri Metr
0
ospf
110
ospf
110
vlan1
ospf
110
30.0.1.2
vlan2
direct
30.0.1.1
vlan2
ospf
110
30.0.1.2
vlan2
address
5-20
SJ-20100901100356-015|2011-07-30(R1.0)
Note that the area 1 range 2.2.2.0 255.255.255.248 command is advertise by default. If it is
set to not-advertise, the aggregation route to network segment 2.2.2.0 is unavailable on
P3, and P3 cannot ping through this network segment.
P2(config-router)#area 1 range 2.2.2.0 255.255.255.248 summary-link not-advertise
P3#show ip route
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
1.1.1.3
255.255.255.255
1.1.1.3
loopback1
address
30.0.0.1
255.255.255.255
30.0.1.1
vlan2
30.0.0.2
255.255.255.255
30.0.1.1
30.0.1.0
255.255.255.252
30.0.1.2
30.0.1.1
255.255.255.255
30.0.1.2
255.255.255.255
Pri Metr
0
ospf
110
vlan2
ospf
110
vlan2
direct
30.0.1.1
vlan2
ospf
110
30.0.1.2
vlan2
address
If the above information is displayed, it indicates that P3 does not learn the routing
information of network segment 2.2.2.0. Although the aggregation route to network
segment 2.2.2.0 is still available in the database, but not advertised to other areas.
5.1.7 Configuring Route Aggregation upon Route Redistribution

Route aggregation can be used only on the routing devices deployed at the AS edges.
After the routes of other routing protocols are redistributed to OSPF, each route can be
independently advertised as an external LSA. These external routes can be aggregated
as one route for advertisement, which greatly reduces the size of the OSPF database.
Configuring ASBR route aggregation
Step
Command
Function

mode.
ZXCTN9000(config-router)#summary-address < ip-address> <
Creates the aggregation address
net-mask>
for OSPF to aggregate the routes

redistributed to OSPF.
Example
As shown in Figure 5-7, to configure OSPF on P1, P2, and P3, advertise the external
routes on P1 and configure ASBR route aggregation on P1.
Device
Router-ID
P1
1.1.1.1
5-21
SJ-20100901100356-015|2011-07-30(R1.0)
Device
Router-ID
P2
1.1.1.2
P3
1.1.1.3

5-22
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-router)#summary-address 2.2.2.0 255.255.255.248


5-23
SJ-20100901100356-015|2011-07-30(R1.0)

View the routing table on P2. The information of network segment 2.2.2.0/29 after
aggregation is available in the routing table.
P2#show ip route
Total number of routes: 9
IPv4 Routing Table:
Interface
Owner
Pri Me
1.1.1.1
Dest
255.255.255.255 30.0.0.2
Mask
Gw
vlan1
ospf
110 20
1.1.1.2
255.255.255.255 1.1.1.2
loopback1
address
2.2.2.0
255.255.255.248 30.0.0.2
vlan1
ospf
30.0.0.0
255.255.255.252 30.0.0.1
vlan1
direct
30.0.0.1
255.255.255.255 30.0.0.1
vlan1
address
30.0.0.2
255.255.255.255 30.0.0.2
vlan1
ospf
110
30.0.1.0
255.255.255.252 30.0.1.1
vlan2
direct
30.0.1.1
255.255.255.255 30.0.1.1
vlan2
address
30.0.1.2
255.255.255.255 30.0.1.2
vlan2
ospf
110
110 20
5.1.8 Configuring Route Redistribution for Other Routing Protocols

Use these commands to advertise the routing information for other routing protocols
to OSPF, so that therefore different dynamic routing protocols can share the routing
information through route redistribution.
Use these commands to redistribute routes for other routing protocols
Step
Command
Function
Enables the OSPF process to run

the OSPF protocol.
ZXCTN9000(config-router)#redistribute < protocol> [ as <
Imports the compliant routes of other
as-number> ] [ peer < peer-address> ] [ tag < tag-value> ] [ metric <
routing protocols into the OSPF AS.
metric-value> ] [ metric-type < type> ] [ route-map < map-tag> ]
By default, the routes of other routing

protocols are not imported into the
OSPF AS. The metric value for
redistributing BGP routes is 1 and 20
for other routes.

Parameter
Description
< protocol>
Indicates the protocol. The value of this parameter can be connected,

static, RIP, bgp-ext, bgp-int, IS-IS-1, IS-IS-1-2, IS-IS-2, ospf-int, or
ospf-ext.
as < as-number>
Indicates the peer AS number. The value of this parameter ranges

from 1 to 65535.
5-24
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
peer < peer-address>
Indicates the peer IP address.
tag < tag-value>
Indicates the LSA tag after redistribution. The value of this parameter
ranges from 0 to 4294967295.
Indicates the LSA metric after redistribution. The system default

metric is adopted by default. The value of this parameter ranges from
0 to 16777214.
metric-type < type>
Indicates the LSA metric type after redistribution. The value of this
parameter is ext-1 or ext-2. The default value is ext-2.
route-map < map-tag>
Indicates the name of the route mapping for redistribution. The value
of this parameter ranges from 1 to 64 characters.
Example
As shown in Figure 5-8, redistribute RIP routes in area 0.
Device
Router-ID
P1
1.1.1.1
P2
1.1.1.2
1. Establish the OSPF neighboring relationship between P1 and P2.

5-25
SJ-20100901100356-015|2011-07-30(R1.0)


2. Enable RIP between P1 and external devices.

The routes between P1 and external devices cannot be viewed in the OSPF area.
3. Redistribute RIP routes on P1.
P1(config-router)#redistribute rip
The information of network segment 30.0.2.0/30 can be viewed on P2.

P2#show ip route
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri
Metric
1.1.1.2
255.255.255.255
1.1.1.2
loopback1
address
30.0.0.0
255.255.255.252
30.0.0.2
vlan1
direct
30.0.0.1
255.255.255.255
30.0.0.1
vlan1
ospf
110
30.0.0.2
255.255.255.255
30.0.0.2
vlan1
address
30.0.2.0
255.255.255.252
30.0.0.1
vlan1
ospf
110
20
If redistribute direct routes on P1:

P1(config-ospfv2)#redistribute connected
The information of network segment 30.0.1.0 can be viewed on P2.

P2#show ip route
5-26
SJ-20100901100356-015|2011-07-30(R1.0)

IPv4 Routing Table:
Dest
1.1.1.1
Mask
255.255.255.255
Gw
Interface
Owner
Pri
Metric
30.0.0.1
vlan1
ospf
110
20
1.1.1.2
255.255.255.255
1.1.1.2
loopback1
address
30.0.0.0
255.255.255.252
30.0.0.2
vlan1
direct
30.0.0.1
255.255.255.255
30.0.0.1
vlan1
ospf
110
30.0.0.2
255.255.255.255
30.0.0.2
vlan1
address 0
30.0.1.0
255.255.255.252
30.0.0.1
vlan1
ospf
110
20
30.0.2.0
255.255.255.252
30.0.0.1
vlan1
ospf
110
20
5.1.9 Configuring OSPF Default Route

When the ZXCTN9000 obtains a default route through other protocol or static route, the
default route should be advertised. If there is no default route, the reachable route is
advertised in common way. After this command is configured, the ZXCTN9000 serves as
an ASBR.
Step
Command
Function
Enters the OSPF routing mode.
ZXCTN9000(config-router)#notify default route [ always] [ metric <
When the ZXCTN9000 obtains
metric-value> ] [ metric-type < type> ] [ route-map < map-tag> ]
default route 0/0 through other

protocol or static route, the default
route should be advertised. If there
is no default route, the reachable
route is advertised in common way.
After this command is configured,
the ZXCTN9000 serves as an ASBR.

Parameter
Description
always
If this parameter is adopted, the default route is advertised no matter

whether the ZXCTN9000 has default route. If this parameter is not
adopted, the default route is advertised if it is available in the routing
table of the ZXCTN9000; otherwise, the default route is not advertised.
metric< metric-value>
Indicates the metric value of the default. The value of this parameter
ranges from 0 to 16777214. The default value is 1.
metric-type< type>
Indicates the type of the default route. The value of this parameter can
be ext-1 or ext-2. The default value is ext-2.
route-map< map-tag>
Indicates the name of the mapping used in route generation. The

value of this parameter ranges from 1 to 64 characters.
5-27
SJ-20100901100356-015|2011-07-30(R1.0)
5.1.10 Configuring OSPF Virtual Link

All areas on the OSPF network should be directly connected to the backbone area. To
achieve this purpose, the virtual link is adopted to enable a remote area to connect to the
backbone area through another area.
Step
Command
Function

mode.
ZXCTN9000(config-router)#area < area-id> virtual-link <
Defines the OSPF virtual link. The
router-id> [ hello-interval < seconds> ] [ retransmit-interval <
no command can be used to delete
seconds> ] [ transmit-delay < seconds> ] [ dead-interval < seconds> ]
the virtual link.
[ authentication-key < key> ] [ message-digest-key < keyid> md5
The virtual link cannot be created in
< cryptkey> [ delay < time> ] ] [ authentication [ null| message-digest] ]
area 0, stub area, or NSSA area.
Note that the virtual link cannot be created in area 0, stub area, or NSSA area.
Parameter
Description
< area-id>
Indicates the area ID that the virtual link passes by. The area cannot
be the stub area, NSSA area, or area 0.
< router-id>
Indicates the peer ZXCTN9000 ID of the virtual link, in dotted decimal

notation.
hello-interval < seconds>
Indicates the Hello packet sending interval on the virtual link. The unit
is second. The value of this parameter ranges from 1 to 8192. The
default value is 10.
retransmit-interval < seconds>
Indicates the retransmission interval on the virtual link. The unit is

second. The value of this parameter ranges from 1 to 8192. The
default value is 5.
transmit-delay < seconds>
Indicates the transmission delay on the virtual link. The unit is second.
The value of this parameter ranges from 1 to 8192. The default value
is 1.
dead-interval < seconds>
Indicates the dead interval on the virtual link. The unit is second. The
value of this parameter ranges from 1 to 8192. The default value is 40.
Example
As shown in Figure 5-9, create the virtual link between P2 and P3.
Device
Router-ID
P1
1.1.1.1
P2
1.1.1.2
P3
1.1.1.3
5-28
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-loopback1)#ip address 1.1.1.1 255.255.255.255

5-29
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-router)#area 1 virtual-link 1.1.1.3

P3(config-router)#area 1 virtual-link 1.1.1.2
5.1.11 Configuring Sham Link

On the actual network, if there are both public network routes and OSPF private network
routes, the OSPF private network routes are preferentially adopted, for their priority are
higher than that of BGP routes. The bandwidth of private network routes are smaller than
that of public network routes, and therefore cannot bear heavy traffic. In this case, a proper
mechanism is required to distribute traffic on the private network to the public network and
realize the smooth traffic switchover between the private network and private network.
As shown in Figure 5-10, when P1 and P2 are in the same area and P1 wants to access
P2, P1 can learn two types of LSAs. One is type 3 LSA advertised by the PE device and the
other is type 1 LSA directly flooded from area 0. Then P1 can calculate the routes based
on the LSA. According to the OSPF route selection policy, the route calculated based on
the type 1 LSA is optimal, and therefore the final path is the OSPF private network route.
Then the sham link is required to implement traffic distribution.
5-30
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 5-10 Configuring Sham Link
Enabling the sham link, establishing the neighboring relationship, and exchanging the
database between PE devices enables the private network router in the area to learn two
routes, namely, one sham link (MPLS VPN backbone) route and one private network route.
The route selection can be realized by changing the metric attribute.
Configuring the following in the VRF instance corresponding to the OSPF on the PE device
Step
Command
Function
ZXCTN9000(config)#router ospf < area-id>

mode.
ZXCTN9000(config-ospfv2)#area < area-id> sham-link <
Establishes the connection between
ip-address1> < ip-address2>
the two PEs to transmit OSPF

packets through the MPLS VPN.

Parameter
Description
< area-id>
Indicates the area ID. The value can be a decimal number (0 to

4294967295) or an IP address in dotted decimal notation.
< ip-address1>
Indicates the IP address of the local loopback interface establishing

the sham link, in dotted decimal notation.
< ip-address2>
Indicates the IP address of the peer loopback interface establishing

the sham link, in dotted decimal notation.
5-31
SJ-20100901100356-015|2011-07-30(R1.0)
5.1.12 Configuring max-metric

Use these commands to disable the ZXCTN9000 from learning any OSPF route.
Step
Command
Function

mode.
ZXCTN9000(config-router)#max-metric router-lsa
Configure the ZXCTN9000 to make

it unable to learn any OSPF route.
Parameter transit-link of the local
router LSA is set to 65535.
Other ZXCTN9000s learn only the
routes initiated by this configured
ZXCTN9000. The configured
ZXCTN9000 is still reachable in
the network topology but cannot be
traversed.
ZXCTN9000(config-router)#max-metric router-lsa on-startup
Wait for one minute after the BGP
wait-for-bgp
neighbor takes effect. Then the

ZXCTN9000 can be traversed.
If the BGP neighbor fails, the
ZXCTN9000 can be traversed after
10 minutes.
ZXCTN9000(config-router)#max-metric router-lsa on-startup <
Indicates the on-startup time. The

unit is second. The value of this
seconds>

That is, the ZXCTN9000 can be
traversed after the restart.
5.1.13 Configuring OSPF Routing Load Balancing

l
Use these commands to configure OSPF routing load balancing on the ZXCTN 9000.
5-32
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config)#router ospf < process-id> [ vrf <
Enter the OSPF route configuration mode.
vrf-name> ]
2
ZXCTN9000(config-router)#maximum-paths < number>
Configures the maximum of routes for

load balancing supported by the protocol.
The value of this parameter ranges from 1
A maximum of eight equivalent routes are saved in the routing table for load balancing.
This command supports up to eight routes with the same metric value. By default, one is
supported.
A maximum of eight equivalent routes are saved in the routing table for load balancing.
This command supports up to eight routes with the same metric value. By default, one is
supported.
Example
As shown in Figure 5-11, enable OSPF between P1 and P2, configure routing load
balancing between P1 and P2, and set the maximum number of supported routes for
OSPF routing load balancing to 2.
Device
Router-ID
P1
1.1.1.1
P2
1.1.1.2

5-33
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config)#maximum-paths 2
/*Sets the maximum number of supported routes for

OSPF routing load balancing to 2.*/

P2(config-if-vlan1)#ip adderss 1.1.1.2 255.255.255.255
5-34
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-router)#maximum-paths 2 /*Sets the maximum number of supported routes for
Connect P1 and P2 according to the network topology.

View the routing table of P1. Two OSPF routes to the same destination 2.2.2.4/30 can be
viewed.
P1#show ip route
11
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri
Metric
1.1.1.1
255.255.255.255 1.1.1.1
loopback1
address
2.2.2.0
255.255.255.252 2.2.2.1
vlan3
direct
2.2.2.1
255.255.255.255 2.2.2.1
vlan3
address
2.2.2.4
255.255.255.252 30.0.1.2
vlan2
ospf
110
30.0.0.2
vlan1
ospf
110
30.0.0.0 255.255.255.252 30.0.0.1
vlan1
direct
30.0.0.1 255.255.255.255 30.0.0.1
vlan1
address
30.0.0.2 255.255.255.255 30.0.0.2
vlan1
ospf
110
30.0.1.0 255.255.255.252 30.0.1.1
vlan2
direct
30.0.1.1 255.255.255.255 30.0.1.1
vlan2
address
30.0.1.2 255.255.255.255 30.0.1.2
vlan2
ospf
110
Similarly, such routes can also be viewed on P2.
5.1.14 Configuring OSPF FRR

Use these commands to configure OSPF FRR on the ZXCTN 9000.
Step
Command
Function
ZXCTN9000(config)#router ospf < process-id> [ vrf <
Enter the OSPF route configuration mode.
vrf-name> ]
2
ZXCTN9000(config-router)#fast-reroute alternate-protect-t
Configures the route backup mode,
ype { default| down-stream-path}
namely, default mode or down steam path.
ZXCTN9000(config-router)#interface < vlan id>
5-35
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-if-vlanX)#ip ospf cost < value>
Configures the cost of the current value.

After the FRR automatic route backup is
enabled, the route with high cost serves
as the backup route.
ZXCTN9000(config-if-vlanX)#fast-reroute [
Indicates the FRR backup interface of the
backup-interface < interface-name> ]
current interface. When the automatic

FRR route calculation requirement in step
2 is not satisfied, the static FRR takes
effect. The static FRR cannot filter loops.
5.1.15 OSPF show Command

Use these show commands to maintain OSPF on the ZXCTN 9000.
Command
Function
ZXCTN9000#show ip ospf [ < process-id> ]
Shows the general information of the

OSPF protocol and that of each OSPF
area.
ZXCTN9000#show ip ospf interface [ < interface-name> ] [ process <
Shows the OSPF interface information.
process-id> ]
ZXCTN9000#show ip ospf database [ database-summary | adv-router <
Shows the OSPF database information.
router-id> | self-originate] [ area < area-id> ] [ process < process-id> ]

ZXCTN9000#show ip ospf database router [ < link-state-id> ] [ adv-router <
Shows the router LSA information in the
OSPF database.
ZXCTN9000#show ip ospf database network [ < link-state-id> ] [ adv-router
Shows the network LSA information in
< router-id> | self-originate] [ area < area-id> ] [ process < process-id> ]
the OSPF database.
ZXCTN9000#show ip ospf database summary [ < link-state-id> ] [ adv-router
Shows the summary LSA information in
the OSPF database.
ZXCTN9000#show ip ospf database asbr-summary [ < link-state-id> ] [
Shows the ASBR-summary LSA
adv-router < router-id> | self-originate] [ area < area-id> ] [ process <
information in the OSPF database.
process-id> ]
ZXCTN9000#show ip ospf database external [ < link-state-id> ] [ adv-router
Shows the external LSA information in
the OSPF database.
ZXCTN9000#show ip ospf database nssa [ < link-state-id> ] [ adv-router <
Shows the NSSA LSA information in
the OSPF database.
ZXCTN9000#show ip ospf database { opaque-area | opaque-link} [ <
Shows the Opaque-area LSA and
link-state-id> ] [ adv-router < router-id> | self-originate] [ area < area-id>
Opaque-link information in the OSPF
] [ process < process-id> ]
database.
5-36
SJ-20100901100356-015|2011-07-30(R1.0)
The execution result of the show ip ospf command is shown below:

ZXCTN9000(config)#show ip ospf 1
Domain ID type 0x5,value 0.0.0.1
Number of areas 2, Normal 2, Stub 0, NSSA 0
Number of interfaces 2
Number of neighbors 2
Number of adjacent neighbors 2
Number of virtual links 0
Total number of entries in LSDB 13
Number of ASEs in LSDB 1, Checksum Sum 0x0000dc0d
Number of grace LSAs 0
Number of new LSAs received 23
Number of self originated LSAs 22
Hold time between consecutive SPF 1 secs
Non-stop Forwarding disabled, last NSF restart 00:21:13 ago (took 0 secs)
Area 0.0.0.0 enable (Demand circuit available)

Total number of intra/inter entries in LSDB 7. Checksum Sum 0x00046565
Area-filter out not set
Area-filter in not set
Area ranges count 0
Area 0.0.0.1 enable (Demand circuit available)

Total number of intra/inter entries in LSDB 5. Checksum Sum 0x00025888
Area-filter out not set
Area-filter in not set
Area ranges count 0
5-37
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
Indicates that the OSPF instance is valid.
Domain ID type 0x5,value 0.0.0.1
Indicates that the domain ID type is 0x5 and the value is 0.0.0.1.
Number of areas 2, Normal 2, Stub 0,
Indicates that the number of areas is 2, that of common areas 2, that
NSSA 0
of stub areas 0, and that of NSSA areas 0.
Area 0.0.0.0 enable (Demand circuit
Indicates the details in each area.
available) and other parameters on the

right
The execution result of the show ip ospf interface command is shown below:
ZXCTN9000(config)#show ip ospf interface
gei_1/1 is up
Up for 00:17:51
In the area 0.0.0.0 DR
Transmit Delay(sec) 1, Authentication Type null
Timer intervals(sec) : Hello 10, Dead 40, Retransmit 5
Designated Router (ID) 100.100.100.14, Interface address 100.100.100.14
Backup Designated router (ID) 100.1.1.2, Interface address 100.100.100.12
Number of Neighbors 1, Number of Adjacent neighbors 1
100.1.1.2
BDR
gei_1/2 is up
Up for 00:16:25
Transmit Delay(sec) 1, Authentication Type null
Timer intervals(sec) : Hello 10, Dead 40, Retransmit 5
Designated Router (ID) 100.100.100.14, Interface address 1.1.1.1
Backup Designated router (ID) 100.1.1.2, Interface address 1.1.1.10
Number of Neighbors 1, Number of Adjacent neighbors 1
100.1.1.2
BDR

Output Item
Description
Internet Address 100.100.100.14
Indicates the IP address of the interface.
255.255.255.0 enable
Indicates that the area is 0.0.0.0 and the type is DR.
5-38
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
Timer intervals(sec) : Hello 10, Dead 40,
Indicates that the interval for sending Hello packets is 10 seconds,
Retransmit 5
the failure interval 40 seconds, and the LSA retransmission interval

5 seconds.
The execution result of the show ip ospf database command is shown below:
ZXCTN9000#show ip ospf database
Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# Checksum Link count
110.1.1.1 110.1.1.1 3 0x80000002 0x3dbe 1
Summary Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# Checksum
112.1.1.0 110.1.1.1 6 0x80000001 0xd99f
168.1.0.0 110.1.1.1 6 0x80000001 0xff43
Summary ASB Link States (Area 0.0.0.0)
168.1.1.3 110.1.1.1 6 0x80000001 0xc875
Link ID ADV Router Age Seq# Checksum Link count
110.1.1.1 110.1.1.1 3 0x80000025 0xf8f8 1
168.1.1.3 168.1.1.3 61 0x80000005 0x70e 2
Net Link States (Area 0.0.0.1)
168.1.1.1 110.1.1.1 1183 0x80000002 0x9787
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
113.1.0.0 168.1.1.3 48 0x80000001 0xa0dd 0
111.1.0.0 110.1.1.1 272 0x80000001 0x4ae3 3489660928

Output Item
Description
Link ID
Indicates the ID of the LSA.
ADV Router
Advertises routes to the ZXCTN9000.
Age
Indicates the aging time.
Seq#
Indicates the sequence number of the LSA.
Checksum
Indicates the checksum.
Link count
Indicates the number of links.
The execution result of the show ip ospf database router command is shown below:
ZXCTN9000#show ip ospf database router
5-39
SJ-20100901100356-015|2011-07-30(R1.0)

Routing Bit Set on this LSA
LS age: 1700
Options: (No TOS-capability, No DC)
LS Type: Router Links
Link State ID: 110.1.1.1
Advertising Router: 110.1.1.1
LS Seq Number: 0x8000001f
Checksum: 0xf9e7
Length: 36
Number of Links: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 110.1.0.0
(Link Data) Network Mask: 255.255.0.0
Number of TOS metrics: 0
TOS 0 Metrics: 1

Output Item
Description
LS age
Indicates the aging time of the LSA.
LS Type
Indicates the type of the LSA.
Link State ID
Advertising Router
LS Seq Number
Checksum
Length
Indicates the length.
The execution result of the show ip ospf database network command is shown below:
ZXCTN9000#show ip ospf database network
Net Link States (Area 0.0.0.1)
Routing Bit Set on this LSA
LS age: 789
LS Type: Network Links
Link State ID: 168.1.1.1 (Address of Designated Router)
LS Seq Number: 0x80000002
Checksum: 0x9787
Length: 32
Network Mask: /16
Attached Router: 110.1.1.1
5-40
SJ-20100901100356-015|2011-07-30(R1.0)

Attached Router: 168.1.1.3

Output Item
Description
LS age
LS Type
Link State ID
Advertising Router
LS Seq Number
Checksum
Length
The execution result of the show ip ospf database summary command is shown below:
ZXCTN9000#show ip ospf database summary
Summary Net Link States (Area 0.0.0.0)
LS age: 129
LS Type: Summary Links(Network)
Link State ID: 112.1.1.0 (Summary Network Number)
Checksum: 0xd99f
Length: 28
Network Mask: /24
TOS: 0 Metric: 2

Output Item
Description
LS age
LS Type
Link State ID
Advertising Router
LS Seq Number
Checksum
Length
The execution result of the show ip ospf database external command is shown below:
ZXCTN9000#show ip ospf database external
5-41
SJ-20100901100356-015|2011-07-30(R1.0)

Type-5 AS External Link States
LS age: 18
LS Type: AS External Link
Link State ID: 111.1.0.0 (External Network Number)
Checksum: 0x4ae3
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 110.1.1.111
External Route Tag: 3489660928

Output Item
Description
LS age
LS Type
Link State ID
Advertising Router
LS Seq Number
The execution result of the show ip ospf database asbr-summary command is shown below:
ZXCTN9000#show ip ospf database asbr-summary
Summary ASB Link States (Area 0.0.0.0)
LS age: 68
LS Type: Summary Links(AS Boundary Router)
Link State ID: 168.1.1.3 (AS Boundary Router address)
Checksum: 0xc875
Length: 28
Network Mask: /0
TOS: 0 Metric: 1

Output Item
Description
LS age

5-42
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
LS Type
Link State ID
Advertising Router
LS Seq Number
Checksum
5.1.16 OSPF debug Command

Use these debug commands to debug OSPF and monitor related information.
Command
Function
ZXCTN9000#debug ip ospf adj < process-id>
Enables the OSPF adjacent debugging

switch.
ZXCTN9000#debug ip ospf all < process-id>
Enables all the OSPF debugging

switches.
Enables the OSPF CSPF debugging
ZXCTN9000#debug ip ospf cspf< process-id>
switch.
Enables the OSPF database timer
ZXCTN9000#debug ip ospf database-timer< process-id>
debugging switch.
ZXCTN9000#debug ip ospf events < process-id>
Enables the OSPF event debugging

switch.
ZXCTN9000#debug ip ospf fast-reroute[ external | inter | intra | nbrspf] <
Enables the OSPF fast route debugging
process-id>
switch.
ZXCTN9000#debug ip ospf flood < process-id>
Enables the OSPF flood debugging

switch.
ZXCTN9000#debug ip ospf lsa-generation < process-id>
Enables the OSPF LSA generation

debugging switch.
ZXCTN9000#debug ip ospf nsf < process-id>
Enables the OSPF non-stop forwarding

debugging switch.
ZXCTN9000#debug ip ospf packet < process-id>
Enables the OSPF packet debugging

switch.
ZXCTN9000#debug ip ospf retransmission < process-id>
Enables the OSPF retransmission

debugging switch.
ZXCTN9000#debug ip ospf spf [ external | inter | intra] < process-id>
Enables the OSPF route calculation

debugging switch.
The execution result of the debug ip ospf all command is shown below:
5-43
SJ-20100901100356-015|2011-07-30(R1.0)

ZXCTN9000#debug ip ospf all 1
ZXCTN9000#debug monitor
ZXCTN9000#
01:03:25: OSPF: send v:2 t:1 l:48 rid:100.100.100.20 aid:0.0.0.1 chk:a367
aut:0 auk:
int:gei_1/2 src:1.1.1.8 dest:AllSPFRouters
01:03:25: OSPF: Rcv v:2 t:1 l:48 rid:100.100.100.14 aid:0.0.0.0 chk:c3da
aut:0 auk:
int:gei_1/1 src:100.100.100.14 dest:224.0.0.5
01:03:25: OSPF: Rcv hello from
100.100.100.14 area 0.0.0.0 on intf
100.100.100.20
01:03:25: OSPF: End of hello processing
01:03:26: OSPF: 100.100.100.20 db aging timer activated
01:03:27: OSPF: 100.100.100.20 As external export timer activated
01:03:28: OSPF: send v:2 t:1 l:48 rid:100.100.100.20 aid:0.0.0.0
chk:c3da aut:0 auk:
int:gei_1/1 src:100.100.100.20 dest:AllSPFRouters
01:03:29: OSPF: Rcv v:2 t:1 l:48 rid:100.100.100.14 aid:0.0.0.1 chk:a367
aut:0 auk:
int:gei_1/2 src:1.1.1.1 dest:224.0.0.5

Output Item
Description
OSPF: send v:2 t:1 l:48 rid:100.100.100.20
Sends an OSPFv2 Hello packet. The TTL is 1, packet length 48
aid:0.0.0.1 chk:a367 aut:0 auk:
bytes, router ID 100.100.100.20, area ID 0.0.0.1,checksum (chk)

a367, authentication type (aut) 0, and authentication key (auk) null.
OSPF: Rcv hello from 100.100.100.14 area
Receives a Hello packet on interface 100.100.100.20. The IP address
0.0.0.0 on intf 100.100.100.20
of the packet is 100.100.100.14 and the area ID is 0.0.0.0.
OSPF: 100.100.100.20 db aging timer
Activates the aging timer at 100.100.100.20.
activated
5.2 OSPF Configuration Instances

5.2.1 Example 1: Configuring OSPF
As shown in Figure 5-12, connect P1 and P2 through two respective links to advertise their
own route to the loopback address.
5-44
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 5-12 Topology of OSPF Configuration Example 1
1. Configure directly-connected interface addresses and loopback interface addresses
for P1 and P2.
2. Add the interfaces to OSPF area 0.
3. Configure routing load balancing. P1 and P2 can learn each other's routes to the
loopback interfaces.


5-45
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-router)#maximum-paths 2

following information is displayed, OSPF neighboring relationship is established. In
addition, P1 and P2 can ping through each other through the loopback interfaces.
P1#show ip ospf neighbor
Neighbor ID
Pri
State
DeadTime
Address
Interface
1.1.1.2
FULL/--
00:00:39
30.0.0.2
vlan1
1.1.1.2
FULL/--
00:00:40
30.0.1.2
vlan2
ZXCTN 9000(config-router)#show ip route 1.1.1.22

IPv4 Routing Table:

Dest
1.1.1.22
Mask
255.255.255.255
Gw
Interface
Owner
Pri
Metric
30.0.1.2
vlan2
ospf
110
30.0.0.2
vlan1
ospf
110
Run the ping command to check the connectivity.

P1#ping 1.1.1.22
5-46
SJ-20100901100356-015|2011-07-30(R1.0)

sending 5,100-byte ICMP echoes to 1.1.1.22,timeout is 2 seconds.
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max= 1/1/2 ms.
5.2.2 Example 2: Configuring OSPF

As shown in Figure 5-13, P1 does not learn the external route in the backbone area.
Instead, P1 should advertise its external route to other nodes. In this case, the NSSA
area should be established between P1 and P2, and P2 and P3 should be connected
through the backbone area.
Figure 5-13 Topology of OSPF Configuration Example 2
1.
2.
3.
4.
Connect P1 and P2 through NSSA area 1 and P2 and P3 through area 0.

Re-distribute direct routes on P3 and P1.
Configure the NSSA default route advertisement on P2.
P1 cannot learn the routes on P3, but the default route to P2 is available. P3 can learn
the direct route re-distributed from P1.
P1(config)#interface
gei_2/1
5-47
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-router)#area 1 nssa

P2(config-router)#area 1 nssa default-information-originate

P3(config-gei-2/5)#switchport access vlan 2
P3(config-gei-2/5)#exit
5-48
SJ-20100901100356-015|2011-07-30(R1.0)

Run the show ip route 1.1.1.3 command on P1 to view whether the route to P3 is available.
ZXCTN 9000(config)#show ip route 1.1.1.3
IPv4 Routing Table:

Dest
0.0.0.0
Mask
0.0.0.0
Gw
Interface
11.22.1.2
vlan1
Owner
Pri
ospf
110
Metric
3
Run the show ip route 0.0.0.0 command on P1 to view whether the default route to P2 is
available.
ZXCTN 9000(config)#show ip route 0.0.0.0
IPv4 Routing Table:

Dest
Mask
0.0.0.0
0.0.0.0
Gw
Interface
11.22.1.2
vlan1
Owner
Pri Metric
ospf
110
Run the show ip route 1.1.1.1 command on P3 to view whether the route to P1 is available.
P3(config)#show ip route 1.1.1.1
IPv4 Routing Table:

Dest
1.1.1.1
Mask
Gw
Interface
255.255.255.255 33.22.1.2
vlan1
Owner
Pri Metric
ospf
110
20
On P3, check the connectivity to P1.

P3#ping 1.1.1.1
sending 5,100-byte ICMP echoes to 1.1.1.11,timeout is 2 seconds.
!!!!!
5.2.3 OSPF Multi-instance Configuration Example

The OSPF multi-instance allows a user to configure multiple protocol entities. The entities
can be of either the same or different VPNs or public networks. The protocol entities
are independent from each other. They maintain their own neighboring relationship and
OSPF database, and independently calculate routes. However, the multiple instances of
the same VPN or public share a VPN or public routing table. The main purpose is to
implement network division and isolation.
5-49
SJ-20100901100356-015|2011-07-30(R1.0)
The following example describes how CE1 isolates the flood information from PE1 and
PE2. Figure 5-14 shows the networking of the configuration example.
Figure 5-14 Topology of OSPF Multi-instance Configuration Example
1. Establish the OSPF relationship between PE1 and CE1.
2. Establish the OSPF relationship between PE2 and CE1.
3. Disable PE2 from learning the link state information on VPN1.
The configuration of PE1:
PE1(config)#ip vrf vpn1
PE1(config-vrf)#rd 1:1
PE1(config-vrf)#exit
PE1(config)#interface loopback1
PE1(config-loopback1)#ip vrf forwarding vpn1
PE1(config-loopback1#ip address 1.1.1.11 255.255.255.255
PE1(config-loopback1)#exit
PE1(config)#interface vlan1
PE1(config-if-vlan1)#ip vrf forwarding vpn1
PE1(config-if-vlan1)#ip address 30.0.0.1 255.255.255.252
PE1(config-if-vlan1)#exit
PE1(config)#interface gei_1/1
PE1(config-gei_1/1)#switchport access vlan 1
PE1(config-gei_1/1)#exit
PE1(config)#router ospf 1 vrf vpn1
PE1(config-router)#network 1.1.1.11 0.0.0.0 area 0
PE1(config-router)#exit
The configuration of CE1:

CE1(config)#interface loopback1
CE1(config-loopback1)#ip address 2.2.2.11 255.255.255.255
5-50
SJ-20100901100356-015|2011-07-30(R1.0)

CE1(config-loopback1)#exit
CE1(config)#interface loopback2
CE1(config-loopback2)#ip address 2.2.2.22 255.255.255.255
CE1(config-loopback2)#exit
CE1(config)#interface vlan1
CE1(config-if-vlan1)#ip address 30.0.0.2 255.255.255.252
CE1(config-if-vlan1)#exit
CE1(config)#interface gei_1/2
CE1(config-gei_1/2)#switchport access vlan 1
CE1(config-gei_1/2)#exit
CE1(config)#interface vlan2
CE1(config-if-vlan2)#ip address 30.0.1.2 255.255.255.252
CE1(config-if-vlan2)#exit
CE1(config)#interface gei_1/3
CE1(config-gei_1/3)#switchport access vlan 2
CE1(config-gei_1/3)#exit
CE1(config)#router ospf 1
CE1(config-router)#network 2.2.2.11 0.0.0.0 area 0
CE1(config-router)#network 30.0.0.0.0 0.0.0.3 area 0
CE1(config-router)#exit
CE1(config)#router ospf 2
CE1(config-router)#exit
The configuration of PE2:

PE2(config)#ip vrf vpn2
PE2(config-vrf)#rd 2:2
PE2(config-vrf)#exit
PE2(config)#interface loopback1
PE2(config-loopback1)#ip vrf forwarding vpn2
PE2(config-loopback1)#ip address 1.1.1.22 255.255.255.255
PE2(config-loopback1)#exit
PE2(config)#interface vlan2
PE2(config-if-vlan2)#ip vrf forwarding vpn2
PE2(config-if-vlan2)#ip address 30.0.1.1 255.255.255.252
PE2(config-if-vlan2)#exit
PE2(config)#interface gei_1/4
PE2(config-gei_1/4)#switchport access vlan 1
PE2(config-gei_1/4)#exit
PE2(config)#router ospf 1 vrf vpn2
PE2(config-router)#exit
Connect PE1, CE1, and PE2 according to the network topology.

5-51
SJ-20100901100356-015|2011-07-30(R1.0)
After the environment is established, CE1 can learn the loopback1 route advertised by
PE1, as well as that advertised by PE2. But PE2 and PE1 cannot learn the route from
each other. It indicates that the OSPF multi-instance makes a difference.
CE1#show ip route ospf
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri Metric
1.1.1.11
255.255.255.255
30.0.0.1
vlan1
ospf
110
2.2.2.11
255.255.255.255
30.0.1.1
vlan2
ospf
110
30.0.0.1
255.255.255.255
30.0.0.1
vlan1
ospf
110
30.0.1.1
255.255.255.255
30.0.1.1
vlan2
ospf
110
PE2#show ip route vrf vpn2 ospf

IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri
Metric
2.2.2.22
255.255.255.255
30.0.1.2
vlan1
ospf
110
30.0.1.2
255.255.255.255
30.0.1.2
vlan1
ospf
110
PE1#show ip route vrf vpn1 ospf

IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri
Metric
1.1.1.22
255.255.255.255
30.0.0.2
vlan1
ospf
110
30.0.0.2
255.255.255.255
30.0.0.2
vlan1
ospf
110
5.2.4 OSPF Routing Load Balancing Configuration Example

Routing load balancing distributes the traffic beyond the bandwidth of an interface to
multiple links.
Taking OSPF as an example, when there are multiple links on the same neighboring
node in an area and the same price is adopted, OSPF routing load balancing can be
implemented.
Figure 5-15 OSPFv2 Routing Load Balancing Configuration Example
5-52
SJ-20100901100356-015|2011-07-30(R1.0)
1. Configure the interface and per-packet load balancing (per-destination by default).
2. Enable and configure the OSPF protocol.
3. Configure routing load balancing on P1.


5-53
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-router)#maximum-paths 2

Run the show commands to verify the configuration result.
P1#show ip route ospf
IPv4 Routing Table:

Dest
Mask
Gw
Interface
Owner
Pri
Metric
30.0.0.2
255.255.255.255
30.0.0.2
vlan1
ospf
110
30.0.1.2
255.255.255.255
30.0.1.2
vlan2
ospf
110
5.3 OSPF Troubleshooting

5.3.1 Handling Basic OSPF Fault
5.3.1.1 Network Topology
Take the topology shown in Figure 5-16 as an example to describe how to handle a basic
OSPF fault.
Figure 5-16 Network Topology for Handling Basic OSPF Fault
5.3.1.2 Fault Analysis

Fault symptom: The neighboring relationship between P2 and P1 cannot be established.
l
l
l
Check whether the interface sends and receives IP packets properly.

Check whether the interface is added to the OSPF group.
Check whether the authentication type is correct.
5-54
SJ-20100901100356-015|2011-07-30(R1.0)
l
l
l
l
l
l
Check whether the hello interval and dead interval are consistent.
Check whether the area of the interface and that of the neighboring interface are consistent and whether their area types match.
To check the MTU in exstart state, the MTUs for master/slave negotiation based on DD
packets must be consistent. In addition, check whether the unicast route is reachable.
Check whether the process and area are disabled through the show ip ospf command.
Check whether the interface is disabled and whether it is set to the passive mode.
Check whether the router ID is compliant. If the network is a broadcast network, check
whether the subnet masks are consistent.
5.3.1.3 Handling Flow

The flow to handle a basic OSPF fault is shown in Figure 5-17.
5-55
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 5-17 Flow to Handle Basic OSPF Fault
5-56
SJ-20100901100356-015|2011-07-30(R1.0)
5.3.1.4 Handling Procedure

The procedure to handle a basic OSPF fault is described below.
1. Check whether packets are properly sent and received by pinging the IP address of
the peer interface.
2. Use the show ip ospf interface command to check whether the interface is added to the
OSPF group, whether the authentication type is correct, and whether the hello interval
and dead interval are consistent. Use the show running-config ospf command to check
whether the interface is set to the passive mode.
3. Use the show ip ospf command to check whether the process and area is disabled,
whether the area type is correct, and whether the router ID is compliant.
4. Use the show interface command to check whether the MTU of the interface is
compliant.
5. Use the show running-config-interface command to check whether the masks of
interfaces are consistent.
5.3.2 Handling OSPF Multi-instance Fault

Take the topology shown in Figure 5-18 as an example to describe how to handle an OSPF
multi-instance fault.
Figure 5-18 Network Topology for Handling OSPF Multi-instance Fault

Fault symptom: The direct route advertised on P1 cannot be learned on P3.
Check whether the neighboring relationship between P1 and P2 and that between P2 and
P3 are established. Check whether the interfaces respectively connecting to P1 and P3
are added to the same instance on P2. Check whether the direct route advertised on P1
are in the same instance with the interface for establishing the neighboring relationship.
Check whether the network types of the interfaces are consistent. Check whether the
backbone area is separated from the area connecting P1 and P2 and the are connecting
P2 and P3, and whether several non-backbone areas are connected in serial mode. Check
whether retransmission occurs and whether the interface price is set to 65535. In addition,
check whether the max-metric router lsa command is configured on P2 or P3.

The flow to handle an OSPF multi-instance fault is shown in Figure 5-19.
5-57
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 5-19 Flow to Handle OSPF Multi-instance Fault

The procedure to handle an OSPF multi-instance fault is described below.
5-58
SJ-20100901100356-015|2011-07-30(R1.0)
1. If the neighboring relationship cannot be established, refer to related fault handling

method.
2. Add the interfaces on a network to the same instance.
3. Make sure that the network types of the interfaces must be consistent.
4. Ensure that IP address contradiction does not occur. Otherwise, incorrect route
calculation may be resulted.
5. Ensure that the interface price is not set to 65535. Otherwise, route calculation fails.
5.3.3 Handling OSPF Routing Load Balancing Fault

Take the topology as shown in Figure 5-20 as an example to describe how to handle an
OSPF routing load balancing fault.
Figure 5-20 Network Topology for Handling OSPF Routing Load Balancing Fault
5.3.3.2 Fault Analysis (OSPF Routing Load Balancing Fault)

If service traffic is not evenly distributed to links, it indicates that routing load balancing
is not enabled. In this case, check whether the routing load balancing configuration is
available and whether there are multiple forwarding items in the routing table.
If there are multiple forwarding items in the routing table and the ip load-sharing per-packet
command is not configured on the interface, per-destination load balancing is adopted.
Make sure that the service traffic meets the routing load balancing requirements.
Routing load balancing includes two modes, that is, per-packet load balancing and
per-destination load balancing. Service traffic can be evenly shared in per-packet
load balancing mode only when there are multiple next hops. Once a flow uses
per-destination load balancing, this mode is selected as the default load balancing mode.
In per-destination load balancing mode, if an individual flow (the quintuple is consistent)
is sent, the flow passes by only one express. If multiple flows (the quintuples differ) are
sent, different expresses are adopted.
If there is only one forwarding item in the routing table, check whether the link price is
consistent. If the fault still persists, contact the technical support engineer for help.

The flow to handle an OSPF routing load balancing fault is shown in Figure 5-21.
5-59
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 5-21 Handle OSPF Routing Load Balancing Fault

The procedure to handle an OSPF routing load balancing fault is described below.
1. Check whether the OSPF routing load balancing item is available in the routing table.
ZXCTN 9000#show ip forwarding
route ospf
IPv4 Routing Table:
Dest
Gw
Interface
Owner
Pri
Metric
1.1.1.200/32
101.2.1.200
gei_1/1
OSPF
110
1.1.1.200/32
102.2.1.200
gei_1/2
OSPF
110
2. Check whether routing load balancing is enabled, that is, whether the maximum-paths
parameter is configured.
ZXCTN 9000#show running-config ospf
router ospf 1
5-60
SJ-20100901100356-015|2011-07-30(R1.0)

maximum-paths 2
network 101.2.1.0 0.0.0.255 area 0.0.0.0
network 102.2.1.0 0.0.0.255 area 0.0.0.0
!
3. Check whether the prices of the links are consistent.

4. Check whether per-destination or per-packet load balancing is adopted. (Each
interface should be checked. Once a flow uses per-destination load balancing, this
mode is selected as the default load balancing mode.)
ZXCTN 9000#show running-config-interface gei_1/1
!
interface gei_1/1
index 2
ip address 101.2.1.100 255.255.255.0
ip load-sharing per-packet
!
5. If the per-destination load balancing is adopted, check whether the quintuple is regular
and whether the internal algorithm supports the flows to be forwarded to the same
next hop. If the quintuple is irregular or the algorithm is improper, contact the technical
support engineer for help.
5.3.4 Handling OSPF FRR Fault

Take the topology shown in Figure 5-22 as an example to describe how to handle an OSPF
FRR fault.
Figure 5-22 Network Topology for Handling OSPF FRR Fault

If the active/standby mode is configured and two or more routes to the same destination
are available, check whether the FRR configuration is compliant and whether related
requirements for forming the FRR relationship are met. For the down-stream FRR
relationship, which is the default mode, the algorithm should satisfy Distance_opt(Ni,
D)<Distance (S, D). To be specific, the distance from the next hop of the standby link to
the destination should be shorter than that from the source node of the active link to the
destination. For the LFAs detection mode, the algorithm should satisfy Distance_opt(Ni,
D)<Distance_opt(Ni, S)+Distance(S, D). To be specific, the distance from the next hop of
5-61
SJ-20100901100356-015|2011-07-30(R1.0)
the standby link to the destination should be shorter than the sum of the distance from the
next hop of the standby link to the source node and the distance from the source node
of the active link to the destination.
If the cost value of the link meets related requirement, check whether the fast-reroute disa
ble or fast-reroute block command is configured on the interface of the standby link.

The flow to handle an OSPF FRR fault is shown in Figure 5-23.
Figure 5-23 Flow to Handle OSPF FRR Fault

The procedure to handle an OSPF FRR fault is described below.
1. Use the show running-config [bgp | ospf|isis] command to check whether the FRR
configuration is enabled.
The following commands can be used to check whether the active/standby links are
configured:
show ip ospf border-lsfas[process <process-id>]
5-62
SJ-20100901100356-015|2011-07-30(R1.0)
When the active/standby egresses are available, the active/standby mode is formed.
To use this command, the peer end must be an ABR or ASBR.
2. If the active/standby mode is not configured, check whether the algorithm meets
related requirements. If not, modify the cost of the interface to satisfy the requirements
of the FRR algorithm.
3. Check whether the standby link is disabled.
5-63
SJ-20100901100356-015|2011-07-30(R1.0)
5-64
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 6
IS-IS Configuration
Table of Contents
Configuring IS-IS ........................................................................................................6-1
IS-IS Configuration Instances ...................................................................................6-17
IS-IS Troubleshooting...............................................................................................6-29
6.1 Configuring IS-IS

6.1.1 Configuring Basic IS-IS Information
Use these commands to configure basic IS-IS information on the ZXCTN 9000.
Step
Command
Function
ZXCTN9000(config)#router isis [ vrf < vrf-name> ]
Enables IS-IS and enters the IS-IS

configuration mode.
ZXCTN9000(config-isis)#area < area-address>
Sets the IS-IS area in IS-IS routing

mode and adds the ZXCTN9000 to
the area.
The area address is a 1- to 13-byte
hexadecimal string.
ZXCTN9000(config-isis)#system-id < system-id> [ range <
range-number> ]
Sets the system ID of IS-IS. The

value of the system ID is a 6-byte
hexadecimal string. The value of
range ranges from 0 to 32.
Configures IS-IS on the VLAN
ZXCTN9000(config-if-vlan1)#ip router isis
interface.
6.1.2 Configuring Global IS-IS Parameter

If all devices involved are ZXCTN9000s, the default parameters can be adopted for
IS-IS configuration. If the ZXCTN9000 interworks with other vendors' devices, related
parameters and timers need adjustment, achieving high-efficiency running of IS-IS on the
network.
Use these commands to configure global IS-IS parameters on the ZXCTN 9000.
6-1
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function

configuration mode.
ZXCTN9000(config-isis)#is-type { level-1 | level-1-2 | level-2-only}
Sets the level of the local

ZXCTN9000. The value of this
parameter can be level-1, level-1-2,
or level-2-only.
By default, the ZXCTN9000 running
IS-IS is identified as level-1-2.
ZXCTN9000(config-isis)#metric-style < narrow | wide >
Sets metric-style.
By default, the narrow mode is
adopted.
ZXCTN9000(config-isis)#lsp-refresh-time < refresh-time >
Sets the interval for refreshing the

local LSP. The unit is second. The
1 to 65535.
On stable networks, the local LSP is
regularly refreshed. By default, the
interval is 900s.
ZXCTN9000(config-isis)#max-lsp-lifetime < time >
Sets the maximum lifetime of the

local LSP, that is, the lifetime of the
local LSP packets in all reachable
node databases. The unit is second.
The value of this parameter ranges
from 1 to 65535.
ZXCTN9000(config-isis)#distance < value >
Sets the priority of IS-IS for

comparison with other protocols.
from 1 to 255. The default value is
115.
ZXCTN9000(config-isis)#passive-interface { default | <
Configures a passive interface.
interface-name> }
When an interface is set to a passive

one, its address information is
included in the local LSP, but the
interface does not send packets.
If the default parameter is included,
all local interfaces are set to passive.
Otherwise, a specified interface is
set to passive.
6-2
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-isis)#set-overload-bit [ on-start-up { < 5-86400>
Configures the OL flag bit of IS-IS.
| auto | wait-for-bgp} ] [ suppress { all | external | interlevel} ]
The flag is used to inform other

ZXCTN9000s running IS-IS that
topology and routing information
cannot be transmitted through
the local ZXCTN9000 due to its
insufficient processing capability.
ZXCTN9000(config-isis)#default-information originate [ always] [
Configures the default route.
metric < metric-value> ] [ metric-type < type> ] [ level-1 | level-1-2 |
When route redistribution is
level-2]
configured, this command is required

on the ZXCTN9000 to redistribute
the default route to IS-IS.
10
ZXCTN9000(config-isis)#summary-address < ip-address> <
Configures route aggregation.
net-mask> [ metric < metric-value> ] [ level-1 | level-1-2 | level-2]
IS-IS can aggregate certain routes in

the routing table into one route and
advertise it, not these specific routes.
11
ZXCTN9000(config-isis)#hello padding { multi-point |
Configures the Hello packets to
point-to-point }
form the maximum packet length

and sends them in broadcast or
point-to-point mode.
12
ZXCTN9000(config-if-vlanX)#isis psnp-interval < interval> [ level-1
Sets the interval between two
| level-2]
PSNPs. The default value is 3.

Parameter
Description
on-start-up { 5-86400 | auto | wait-for-bgp }
Parameters after on-start-up:

l
5-86400: indicates that the OL flag bit setting is cancelled a

period (5 to 86400s) after the device restarts.
auto: indicates that the OL flag bit setting is cancelled after

database synchronization is completed.
wait-for-bgp: indicates that the OL flag bit setting is cancelled

after BGP synchronization is completed.
suppress { all | external | interlevel}
Parameters after suppress:

l
all: suppresses route redistribution and route leaking between

level-1 and level-2.
external: Suppresses the local learning of redistributed routes.
interlevel: Suppresses the route leaking between level-1 and

level-2.

6-3
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
always
Indicates that the system generates a default route for advertisement

regardless of whether the routes to be redistributed include a default
route. If this parameter is not configured, the default route is advertised
only when the routes to be redistributed include a default route.
Indicates the metric value. The value of this parameter ranges from 0
to 4261412864.
metric-type < type>
Indicates the metric type. The value is external or internal. The default
value is internal.
level-1
Generates the default route in level-1.
level-1-2
Generates the default route both in level-1 and level-2.
level-2
Generates the default route in level-2. This is the default value.
tag
Configures the tag of the network segment.
route-map
Redistributes the default routes of other protocols and advertises the

default routes only if the route-map condition is met.

Parameter
Description
< ip-address>
Indicates the address range for distribution, in dotted decimal notation.
< net-mask>
Indicates the subnet mask of the aggregated route, in dotted decimal

notation.
to 4261412864.
level-1
Indicates that if the non local interface addresses in the local level-1
LSP contains the subnet route of this aggregated network segment,
the routes are aggregated to level-1 according to the address.
level-1-2
Indicates that if the non local interface address information in the

local level-1 LSP contains the subnet route of this aggregated
network segment, the routes are aggregated to level-1 according to
the address, and if the non local interface address information in
the local level-2 LSP contains the subnet route of this aggregated
network segment, the routes are aggregated to level-2 according to
the address.
level-2
Indicates that if the address information in the local level-2 LSP

contains the subnet route of this aggregated network segment, the
routes are aggregated to level-2 according to the address.
tag
Adds tag to the routes of the aggregated network segment.
6-4
SJ-20100901100356-015|2011-07-30(R1.0)
6.1.3 Configuring IS-IS Interface Parameter

Use these commands to configure IS-IS interface parameters on the ZXCTN 9000.
Step
Command
Function
ZXCTN9000(config-isis)#interface < vlan id>
Enters the Layer-3 interface.
ZXCTN9000(config-if-vlanX)#isis circuit-type { level-1|
Sets the interface type. The default value
level-1-2| level-2-only}
is level-1-2. The value of this parameter

should match that of the corresponding
global IS-IS parameter. The parameters of
two directly connected neighbors should
also be consistent.
ZXCTN9000(config-if-vlanX)#isis hello-interval < interval>
Sets the Hello packet sending interval.
[ level-1 | level-2]

parameter ranges from 1 to 65535. The
default value is 10.
After the broadcast link DIS is elected, the
interval of the DIS is 3s and cannot be
changed.
If the optional parameters are not included,
the interval is valid to both level-1 and
level-2.
ZXCTN9000(config-if-vlanX)#isis hello-multiplier <
Sets the multiple of the interface saving
multiplier> [ level-1 | level-2]
time compared with the Hello packet

sending interval. The value of this
default value is 3.
the multiple is valid to the intervals of both
ZXCTN9000(config-if-vlanX)#isis lsp-interval < interval>
Sets the interval between LSP packets.

default value is 2.
level-2.
ZXCTN9000(config-if-vlanX)#isis retransmit-interval <
Sets the retransmission interval between
interval> [ level-1 | level-2]
LSP packets. The unit is second. The

value of this parameter ranges from 1 to
65535. The default value is 5.
This parameter is applicable to only
point-to-point links. If the optional
parameters are not included, the
6-5
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
retransmission interval is valid to both
ZXCTN9000(config-if-vlanX)#isis priority < priority> [
Sets the DIS election priority of the
level-1 | level-2]
interface. The value of this parameter

ranges from 0 to 127. The default value is
64. The one with a larger value is elected
as the DIS.
This parameter is applicable to only
broadcast links. If the optional parameters
are not included, the priority is valid to
both level-1 and level-2.
ZXCTN9000(config-if-vlanX)#isis metric < metric-value> [
Sets the metric of the IS-IS interface. The
level-1 | level-2]
default value is 10. In wide mode, the

value of this parameter ranges from 0 to
16777214. In narrow mode, the value of
this parameter ranges from 0 to 63.
the metric value is valid to both level-1
and level-2.
ZXCTN9000(config-if-vlanX)#isis csnp-interval < interval>
Sets the CSNP transmission interval. The
unit is second. The value of this parameter

ranges from 1 to 65535. The default value
is 10s for broadcast links and 3600s for
point-to-point links.
level-2.
ZXCTN9000(config-if-vlanX)#isis psnp-interval < interval>
Sets the PSNP transmission interval. The
unit is second. The value of this parameter

is 3.
level-2.
6.1.4 Configuring IS-IS Authentication

The ZXCTN 9000 supports the following types of IS-IS authentication.
l
l
l
Inter-neighbor authentication
Intra-area authentication
Inter-area authentication
6-6
SJ-20100901100356-015|2011-07-30(R1.0)
Inter-SNP authentication
Currently, the ZXCTN 9000 supports plain-text and MD5 authentication.

commands to configure IS-IS authentication on the ZXCTN 9000.
Use these
Step
Command
Function
ZXCTN9000(config-isis)#authentication-type < type> [
Configures the plain-text or MD5
level-1 | level-2]
authentication.
the authentication type is valid to both
ZXCTN9000(config-isis)#authentication { < password> | [
Configures the IS-IS authentication in
encrypt< password> ] } [ level-1 | level-2]
routing mode. The password ranges from

1 to 180 characters.
In routing mode, both SNP and LSP
packets are authenticated by default.
To authenticate only LSP packets, you
can run the disable-snp-authentication
command.
the authentication is valid to the SNP
packets of both level-1 and level-2.
Enters the VLAN interface configuration

mode.
ZXCTN9000(config-if-vlanX)#authentication-type < type>
Configures the plain-text or MD5
authentication in the interface mode.

the authentication type is valid to both
ZXCTN9000(config-if-vlanX)#isis authentication { <
Configures the authentication for Hello
password> | [ encrypt< password> ] } [ level-1 | level-2]
packets. The password ranges from 1 to

180 characters.
the authentication is valid to the Hello
packets of both level-1 and level-2.

configuration mode.
6-7
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-isis)#enable-snp-authentication
After the authentication for LSP packets

is configured, the same authentication
password is configured for SNP packets.
By default, the same authentication is
adopted for SNP packets.
ZXCTN9000(config-isis)#disable-snp-authentication
Cancels the authentication for SNP

packets.
6.1.5 Configuring IS-IS hostname

Use these commands to configure IS-IS hostname on the ZXCTN 9000.
Step
Command
Function
Enters the IS-IS configuration mode.
ZXCTN9000(config-isis)#hostname dynamic
Enables the ISIS to dynamically

obtain hostname. By default, the
function is enabled. Therefore,
ZXCTN9000(config-isis)#no hostname dynamic
the configuration is displayed in

Disables
the ISIS
to dynamically
configuration
information.
obtain hostname.
6.1.6 Configuring IS-IS Mesh Group

Use these commands to configure IS-IS mesh group on the ZXCTN 9000.
Step
Command
Function

mode.
ZXCTN9000(config-if-vlanX)#isis mesh-group blocked
Configures the mesh group as

blocked, indicating that the LSP
information is blocked on this
interface.
ZXCTN9000(config-if-vlanX)#isis mesh-group < mesh-group-numb
Adds the interface to a specific
er>
mesh group. The value of the mesh

group number ranges from 1 to
4294967295.
6-8
SJ-20100901100356-015|2011-07-30(R1.0)
6.1.7 Configuring IS-IS Redistribution

Use these commands to configure IS-IS redistribution on the ZXCTN 9000.
Step
Command
Function

configuration mode.
ZXCTN9000(config-isis)#redistribute < protocol> [ level-1 ]
Configures redistribution in IS-IS
[ level-1-2 ] [ level-2 ] [ metric-type < metric-type> ] [ metric <
routing mode.
metric-value> ] [ route-map < map-tag> ]

Parameter
Description
< protocol>
Indicates the routing protocol. The value of this parameter can be

connect, static, rip, isis <process-id>, ospf <process-id>, or bgp. This
parameter is mandatory. To redistribute IS-IS/OSPF routes, you need
to specify the process ID.
level-1
Adds the redistributed routes to level-1.
level-1-2
Adds the redistributed routes to both level-1 and level-2.
level-2
Adds the redistributed routes to level-2.
< metric-type>
Sets the metric type (external or internal) of the redistributed routes.
< metric-value>
to 4261412864.
route-map < map-name>
References a route-map.
6.1.8 Configuring IS-IS Load Balancing

l
6-9
SJ-20100901100356-015|2011-07-30(R1.0)
Per-destination
per-packet
Advan-
Path usage is high. Since this method uses polling
tage
destination, only one route is used. Packets to
to determine paths for packets, traffic is balanced
different destinations are routed along different
among paths.
paths.
Disad-
Traffic to one destination may be routed through
vantage
different paths, resulting in the sequencing of
making load unbalanced. This method achieves
receiving ends. Therefore, this method is not
effective load balancing only in the case of many
applicable to traffic requiring specific sequence,
destinations.
such as VoIP.
The ZXCTN9000 supports IS-IS load balancing, through which traffic can be balanced
among multiple links to the destination with the same cost. Load balancing includes two
modes, per-packet and per-destination. By default, per-destination is adopted.
Use these commands to configure IS-IS routing load balancing on the ZXCTN 9000.
Step
Command
Function
Enters the IS-IS configuration mode.
ZXCTN9000(config-isis)#maximum-paths < number>
Configures the maximum of routes

for load balancing supported by the
protocol. The value of this parameter
is 1.
6.1.9 Configuring IS-IS TE

The ZXCTN 9000 supports IS-IS TE on IPv4 public networks.
Use these commands to configure IS-IS TE on the ZXCTN 9000.
Step
Command
Function

configuration mode.
ZXCTN9000(config-isis)#metric-style wide
Sets the width in IS-IS routing mode.
ZXCTN9000(config-isis)#mpls traffic-eng level-1
Enables TE in IS-IS level-1.
ZXCTN9000(config-isis)#mpls traffic-eng level-2
Enables TE in IS-IS level-2.
ZXCTN9000(config-isis)#mpls traffic-eng router-id <
Selects an interface on the local

IS-IS-enabled device for the configuration
interface-name>
of Router-ID.
6-10
SJ-20100901100356-015|2011-07-30(R1.0)
6.1.10 Configuring IS-IS FRR

The IS-IS FRR function is used to calculate the backup topology. When the active link
is unavailable, traffic can be immediately forwarded by the standby link, preventing data
losses.
Use these commands to configure IS-IS FRR on the ZXCTN 9000.
Step
Command
Function
ZXCTN9000(config)#router isis vrf < vrf-name> ]

configuration mode.
ZXCTN9000(config-isis)#fast-reroute enable
Enables FRR in IS-IS routing mode.
ZXCTN9000(config-isis)#fast-reroute alternate-type
Configures the IS-IS FRR algorithm
down-stream-path
as down-stream-path. The default

algorithm is LFA.
Enters the VLAN interface

configuration mode.
ZXCTN9000(config-if-vlanX)#isis fast-reroute block
Configures the interface not to

participate in IS-IS FRR calculation,
not used in forming the standby link.
6.1.11 IS-IS show Command

Use these commands to maintain IS-IS on the ZXCTN 9000.
Command
Function
ZXCTN9000(config)#show isis adjacency [ up-time] [ level-1 | level-2] [
Shows the adjacency relationship and
vrf < vrf-name> ]
the current neighboring status.
ZXCTN9000(config)#show isis circuits [ detail] [ vrf < vrf-name> ]
Shows the current IS-IS interface

information.
ZXCTN9000(config)#show isis database [ verbose] [ level-1| level-2] [ detail]
Shows the IS-IS database information.
[ vrf < vrf-name> ] [ < LSP-ID> ]

ZXCTN9000(config)#show isis topology [ level-1| level-2] [ vrf < vrf-name> ]
Shows the current IS-IS topology.
ZXCTN9000(config)#show isis ipv6
Shows current tunnels used by SPF

calculation of IS-IS.
ZXCTN9000(config)#show isis fast-reroute-topology [ level-1| level-2] [
Shows the current IS-IS backup
vrf < vrf-name> ]
topology.
ZXCTN9000(config)#show isis hostname [ vrf < vrf-name> ]
Shows the names of the ZXCTN9000

known by the local ZXCTN9000.
ZXCTN9000(config)#show isis mesh-groups [ blocked| group] [ vrf <
Shows the information about mesh
vrf-name>
groups.
6-11
SJ-20100901100356-015|2011-07-30(R1.0)
Command
Function
ZXCTN9000(config)#show isis nsf [ vrf < vrf-name> ]
Shows NSF information.

Output Item
Description
level-1
Indicates that the ZXCTN9000 is in level-1.
level-2
Indicates that the ZXCTN9000 is in level-2.
up_time
Indicates the up time of the neighbor.
detail
Indicates the detailed information.
The execution result of the show isis adjacency command is shown below:
ZXCTN9000(config-isis)#show isis adjacency
Interface
System id
State
vlan20
P2
UP/UP
L1L2
Lev Holds
6/6
00D0.D0C0.1901
SNPA(802.2)
64/64
Pri
vlan10
P2
UP
L1
00D0.D0C0.1901
64
MT

Output Item
Description
Interface
Indicates the name of the local interface that establishes the

neighboring relationship with the peer interface.
System id
Indicates the system ID of the neighbor, in xxxx.xxxx.xxxx format.
State
Indicates the status of the neighboring relationship, that is, UP or INIT.
Lev
Indicates the level of the neighboring relationship, that is, L1, L2, or
L1L2.
Holds
Indicates the holding time of the neighboring relationship.
SNPA(802.2)
Indicates the subnet access point.
Pri
Indicates the election priority of the ZXCTN9000.
MT
Indicates the multi-topology tag.
The execution result of the show isis circuits command is shown below:
ZXCTN9000(config-router)#show isis circuits
IS-IS interface database:
Interface State
Lev
CirId
Level1-DR
vlan20
Up
L1L2
P2.03
vlan10
Up
L1
P2.02
Level2-DR
Pri(L1/L2)
P2.03
64/64
Disabled
64/64

6-12
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
Interface
Indicates the name of the IS-IS port.
State
Indicates the status of IS-IS on a port. If IS-IS is enabled, the value of

this parameter is up. If IS-IS is disabled, the value of this parameter
is down.
Lev
Indicates the level of the port.
CirId
Indicates the ID of the port.
Level1-DR
Indicates the ZXCTN9000 with level-1 port.
Level2-DR
Indicates the ZXCTN9000 with level-2 port.
Pri(L1/L2)
Indicates the L1/L2 priority of the port.
The execution result of the show isis database command is shown below:
ZXCTN9000(config-router)#show isis database detail
IS-IS Level-1 Link State Database:
LSPID
LSP Seq Num
P1.00-00*
LSP Checksum
0x5
0xfdf9
LSP Holdtime
ATT/P/OL
640
0/0/0
NLPID
0xcc
Area Address
01
Ip address
10.1.1.1
Hostname
P1
Metric: 10
IS neighbor P2.03
Metric: 10
IS neighbor P2.02
Metric: 10
IP-Internal 20.1.1.0 255.255.255.0
Metric: 10
IP-Internal 10.1.1.0 255.255.255.0
LSPID
LSP Seq Num
P2.00-00
LSP Checksum
0xb
0xdeaa
LSP Holdtime
ATT/P/OL
667
0/0/0
NLPID
0xcc
Area Address
01
Ip address
10.1.1.2
Hostname
P2
Metric: 10
IS neighbor P2.03
Metric: 10
IS neighbor P2.02
Metric: 10
IP-Internal 20.1.1.0 255.255.255.0
Metric: 10
IP-Internal 10.1.1.0 255.255.255.0
LSPID
LSP Seq Num
P2.02-00
LSP Checksum
0x2
0xad1f
Hostname
P2
Metric: 0
IS neighbor P1.00
Metric: 0
IS neighbor P2.00
LSP Holdtime
ATT/P/OL
557
0/0/0
6-13
SJ-20100901100356-015|2011-07-30(R1.0)

LSPID
LSP Seq Num
P2.03-00
LSP Checksum
0x2
LSP Holdtime
ATT/P/OL
665
0/0/0
LSP Holdtime
ATT/P/OL
972
0/0/0
0xa625
Hostname
P2
Metric: 0
IS neighbor P1.00
Metric: 0
IS neighbor P2.00
IS-IS Level-2 Link State Database:

LSPID
LSP Seq Num
P1.00-00*
LSP Checksum
0x6
0x2b31
NLPID
0xcc
Area Address
01
Ip address
10.1.1.1
Hostname
P1
Metric: 10
IS neighbor P2.03
Metric: 10
IP-Internal 20.1.1.0 255.255.255.0
Metric: 10
IP-Internal 10.1.1.0 255.255.255.0
LSPID
LSP Seq Num
P2.00-00
LSP Checksum
0xd
LSP Holdtime
ATT/P/OL
1021
0/0/0
0xae2
NLPID
0xcc
Area Address
01
Ip address
10.1.1.2
Hostname
P2
Metric: 10
IS neighbor P2.03
Metric: 10
IP-Internal 20.1.1.0 255.255.255.0
Metric: 10
IP-Internal 10.1.1.0 255.255.255.0
LSPID
LSP Seq Num
P2.00-01
LSPID
LSP Checksum
0x1
0x5e0
LSP Seq Num
P2.02-00
LSPID
LSP Checksum
0x2
0(629)
LSP Holdtime
0xad1f
LSP Seq Num
P2.03-00
LSP Holdtime
LSP Checksum
0x2
0(997)
P2
Metric: 0
IS neighbor P1.00
Metric: 0
IS neighbor P2.00
0/0/0
ATT/P/OL
0/0/0
LSP Holdtime
ATT/P/OL
664
0/0/0
0xa625
Hostname
ATT/P/OL

Output Item
Description
LSPID
Indicates the ID of the LSP.
LSP Seq Num
Indicates the sequence number of the LSP.

6-14
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
LSP Checksum
Indicates the checksum of the LSP.
LSP Holdtime
Indicates the lifetime of the LSP.
ATT/P/OL
Indicates the ATT (connected to external areas)/P (area division)/OL

(overload) flag bit.
The execution result of the show isis topology command is shown below:
ZXCTN9000(config-isis)#show isis topology
IS-IS paths to Level-1 routers
System id
Metric
P1
10
P2
--
Next-Hop
Interface
P1
SNPA
vlan10
00D0.D0C0.0C81

System id
Metric
P1
10
P2
--
Next-Hop
Interface
P1
SNPA
vlan10
00D0.D0C0.0C81

Output Item
Description
System id
Indicates the system ID of the destination device.
Metric
Indicates the metric of the destination IS. If the value is --, it indicates
the local device. If the value is **, no IS-IS route is available.
Next-Hop
Indicates the nex-hop of the IS-IS route to the destination.
Interface
Indicates the forwarding port of the route.
SNPA
Indicates the SNPA address of the next hop. A P-P port is tagged
*ppp*.
The execution result of the show isis fast-reroute-topology command is shown below:
P1(config)#show isis fast-reroute-topology
IS-IS ipfrr paths to Level-1 routers
System id
Interface
Ipfrr interface
P2
vlan20
vlan10
Ipfrr type
Link/ECMP
Metric
10
P2
vlan10
vlan20
Link/ECMP
10
P3
vlan31
vlan10
Link
20

System id
Interface
Ipfrr interface
Ipfrr type
Metric
P2
vlan20
vlan31
Link
20
P3
vlan31
vlan20
Link
20
P2(config)#sho isis fast-reroute-topology
6-15
SJ-20100901100356-015|2011-07-30(R1.0)

System id
Interface
Ipfrr interface
P1
vlan20
vlan10
Link/ECMP
10
P1
vlan10
vlan20
Link/ECMP
10
P3
vlan32
Ipfrr type
Metric
vlan10
Link
20

System id
Interface
Ipfrr interface
Ipfrr type
Metric
P1
vlan20
vlan32
Link
20
P3
vlan32
vlan20
Link
20
Output Item
Description
system Id
Indicates the system ID of the destination device.
interface
Indicates the primary egress of the IS-IS route to the destination.
ipfrr interface
Indicates the secondary egress of the IS-IS route to the destination.
ipfrr type
Indicates the IS-IS FRR calculation method, that is, LFA or

down-stream-path.
metric
Indicates the metric of the IS-IS route to the destination.
6.1.12 IS-IS debug Command

Use these debug commands to debug IS-IS and monitor related information.
Command
Function
ZXCTN9000#debug isis all
Enables all IS-IS debuggings.

Monitors the sent and received IS-IS
ZXCTN9000#debug isis adj-packets
Hello packets.
Monitors the sent and received IS-IS
ZXCTN9000#debug isis snp-packets
SNP packets.
Monitors IS-IS route calculation event
ZXCTN9000#debug isis spf-events
debugging information.
Monitors IS-IS LSP packet processing
ZXCTN9000#debug isis update-packets
event debugging information.

ZXCTN9000#debug isis nsf-event
Monitors IS-IS GR information.
ZXCTN9000#debug isis mpls traffic-eng events
Monitors IS-IS CSPF route calculation

event debugging information.
Monitors IS-IS FRR information.
ZXCTN9000#ddebug isis fast-reroute
The execution result of the debug isis all command is shown below:
ZXCTN 9000#debug isis all
All IS-IS debugging has been turned on
6-16
SJ-20100901100356-015|2011-07-30(R1.0)

ZXCTN 9000#
Jan 1 00:08:30: ISIS-Adj: Sending LAN_IIH(1) on vlan10 length 48
Jan 1 00:08:33: ISIS-Adj: Recv LAN_IIH(1) from 1111.1111.1111(vlan10)
Jan 1 00:08:33: cir type L1L2, lan id 2222.2222.2222-02, length 48
Jan 1 00:08:33: ISIS-Adj: Recv LAN_IIH(2) from 1111.1111.1111(vlan10)
Jan 1 00:08:33: cir type L1L2, lan id 2222.2222.2222-02, length 48
Jan 1 00:08:39: ISIS-Snp: Sending L1 CSNP on vlan10
Jan 1 00:08:39: ISIS-Snp: Sending L2 CSNP on vlan10

Output Item
Description
ISIS-Adj: Recv LAN_IIH(2) from
IS-IS neighbor information: receives a LAN_IIH(2) packet through the
1111.1111.1111(vlan10)
vlan10 interface on the router at 1111.1111.1111.
ISIS-Adj: Sending LAN_IIH(1) on vlan10
IS-IS neighbor information: sends a LAN_IIH(1) packet whose length
length 48
is 48 through the vlan10 interface.
cir type L1L2, lan id 2222.2222.2222-02,
Interface information.
length 48
ISIS-Snp: Sending L1 CSNP on vlan10
SNP information: sends an L1 CSNP packet through the vlan10

interface.
6.2 IS-IS Configuration Instances

6.2.1 Configuring Single-Area IS-IS
Before IS-IS configuration, analyze the entire network. Determine the topology based on
the network size, and check whether the network needs to be divided into multiple areas
and whether multiple routing protocols run on the network. If the network is not large, only
single-area IS-IS is required.
Figure 6-1 shows the typical single-area IS-IS networking. The following describes the
basic IS-IS configuration based on the figure.
6-17
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 6-1 Configuring Single-Area IS-IS
1.
2.
3.
4.
Configure VLAN interface.

Configure IS-IS.
Enable IS-IS on the VLAN interface.
Verify the configuration result, and check whether the neighboring relationship is
established between two devices and the topology is figured out.
P1(config)#router isis
P1(config-router)#area 01
P1(config-router)#system-id 1111.1111.1111
P1(config)#vlan 10
P1(config-vlan10)#interface vlan10
P1(config-if-vlan10)#ip router isis
P1(config)#vlan 20
P1(config-vlan20)#interface vlan20

P2(config-if-vlan10)#sho isis circuits
6-18
SJ-20100901100356-015|2011-07-30(R1.0)

following information is displayed, neighboring relationship is established, and the
topology is figured out.
Run the show running-config isis command on P1 to check whether the IS-IS configuration
is correct.
P1(config)#show running-config module isis
Building configuration...
!
router isis
area 01
system-id 1111.1111.1111
!
!
end
Run the show isis adjacency command on P1 to check whether the status of the neighbor
is Up. If the neighboring relationship is established, the status of the neighbor is Up.
P1(config)#show isis adjacency
Interface
vlan10
System id
P2
State
Lev
Holds
UP/UP
L1L2
8/8
SNPA(802.2)
Pri
MT
00D0.D0C0.1901 64/64
Run the show isis topologyy command on P1 to check whether the topology is correctly
figured out. If the topology is figured out, the execution result of the command contains
the following metric information. If metric is , it indicates the local device. If metric is **, it
indicates unreachable.
P1(config)#show isis topology
System id
Metric
P1
--
P2
10
Next-Hop
P2
Interface
vlan10
SNPA
00D0.D0C0.1901

System id
Metric
P1
--
P2
10
Next-Hop
P2
Interface
vlan10
SNPA
00D0.D0C0.1901
Run the show isis circuits command on P1 to view the interface information and DIS
election. If the status of the interface is up, the interface is working properly. If the status
of the interface is down, an anomaly occurs. In this case, you need to check the link
status and IP configuration.
P1(config)#show isis circuits
6-19
SJ-20100901100356-015|2011-07-30(R1.0)

Interface
State
vlan20
Up
vlan10
Up
Lev
CirId
Level1-DR
Level2-DR
Pri(L1/L2)
L1L2
No found
No found
64/64
L1L2
P2.02
P2.02
64/64
Similarly, verify the configuration result on P2.

!
router isis
area 01
system-id 2222.2222.2222
fast-reroute enable
!
!
end
P2(config)#show isis circuits

Interface
CirId
Level1-DR
Level2-DR
vlan20
State
Up
Lev
L1L2
No found
No found
vlan10
Up
L1L2
Dis is me
Dis is me

Interface
vlan10
System id
State
Lev
Holds
SNPA(802.2)
Pri
P1
UP/UP
L1L2
27/27
00D0.D0C0.0C81
64/64
MT

System id
Metric
P1
10
P2
Next-Hop
Interface
P1
vlan10
SNPA
00D0.D0C0.0C81
--

System id
Metric
P1
10
P2
Next-Hop
Interface
P1
vlan10
SNPA
00D0.D0C0.0C81
--
6.2.2 Configuring Multi-Area IS-IS

On large networks, multi-area IS-IS can be required. Adjacent routers can be divided into
one area based on the geographical position and function. Area division helps reduce
requirements on memory. Routers in an area needs to maintain only a small LSDB.
6-20
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 6-2 shows the configuration example of multi-area IS-IS. P1 belongs to area 1, P2
belongs to area 0, and P3 and P4 belong to area 2. P1 aggregates the routes of area 1.
P4 redistributes the default route to IS-IS.
Figure 6-2 Configuring Multi-Area IS-IS
1.
2.
3.
4.
5.
6.
Configure the IP addresses of interfaces.

Configure IS-IS.
Enable IS-IS on the interface.
Enable route aggregation on P1.
Configure static default route on P4 and redistribute the default route.
Verify the configuration result, and check whether the neighboring relationship is
established between two devices and the topology is figured out. Check whether both
devices can ping through each other.
P1(config-router)#is-type level-1-2
P1(config-router)#ex
P1(config-if-vlan4)#isis circuit-type level-2
P1(config-if-vlan4)#ex
6-21
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-if-vlan7)#ex
P1(config-router)#summary-address 192.168.100.0 255.255.252.0 metric 10

P2(config-router)#is-type level-2
P2(config-if-vlan6)#

P3(config-router)#is-type level-1-2
6-22
SJ-20100901100356-015|2011-07-30(R1.0)


P4(config-router)#is-type level-1
P4(config-router)#ex
P4(config)#
P4(config)#ip route 0.0.0.0 0.0.0.0 192.168.14.10
P4(config-router)#default-information originate
P4(config-router)#redistribute static metric 10
P4(config-router)#end
P4#
following information is displayed, neighboring relationship is established, and the
topology is figured out. In addition, P1 and P2 can ping through each other.
You can see the above configuration in P1 configuration information. You can use the show
ip protocol routing command to the static default routes redistributed by P4.
!
router isis
area 01
system-id 1111.1111.1111
is-type level-1-2
summary-address 192.168.100.0 255.255.252.0
!
!
end

Interface
System id
State
Lev
Holds
SNPA(802.2)
Pri
MT
6-23
SJ-20100901100356-015|2011-07-30(R1.0)

vlan4
P2
UP
L2
00D0.D0C0.1901
64

System id
Metric
P1
Next-Hop
Interface
SNPA
Interface
SNPA
--

System id
Metric
Next-Hop
P1
--
P2
10
P2
vlan4
00D0.D0C0.1901
P3
20
P2
vlan4
00D0.D0C0.1901
P1(config)#show ip protocol routing

Protocol routes:
Status codes: *-valid, >-best, i-internal, s-stale
Dest
*>
0.0.0.0/0
NextHop
RoutePrf
RouteMetric Protocol
0.0.0.0
254
special
*>
192.168.13.0/24
192.168.15.2
115
30
isis-l2
*>
192.168.14.0/24
192.168.15.2
115
20
isis-l2
*>
192.168.15.0/24
192.168.15.1
192.168.15.0/24
192.168.15.2
115
*>
192.168.15.1/32
192.168.15.1
connected
*>
192.168.100.0/24
192.168.100.1
connected
*>
192.168.100.1/32
192.168.100.1
connected
*>
192.168.101.0/24
192.168.101.1
connected
*>
192.168.101.1/32
192.168.101.1
connected
*>
192.168.102.0/24
192.168.102.1
connected
*>
192.168.102.1/32
192.168.102.1
connected
*>
255.255.255.255/32 0.0.0.0
254
special
0
20
connected
isis-l2
Similarly, view the configuration on P2:

!
router isis
area 00
system-id 2222.2222.2222
is-type level-2-only
!
!
end
6-24
SJ-20100901100356-015|2011-07-30(R1.0)

System id
Metric
Next-Hop
Interface
SNPA
Interface
SNPA
P1
vlan4
00D0.D0C0.0C81
P3
vlan6
00D0.D0C0.2581

System id
Metric
P1
10
P2
--
P3
10
Next-Hop

Interface
System id
State
Lev
Holds
SNPA(802.2)
Pri
vlan6
P3
UP
L2
00D0.D0C0.2581
64
vlan4
P1
UP
L2
30
00D0.D0C0.0C81
64
MT

Protocol routes:
*>
Dest
NextHop
0.0.0.0/0
0.0.0.0
RoutePrf
254
RouteMetric Protocol
8
special
*>
192.168.13.0/24
192.168.14.3
115
20
isis-l2
*>
192.168.14.0/24
192.168.14.2
connected
192.168.14.0/24
192.168.14.3
115
20
*>
192.168.14.2/32
192.168.14.2
connected
isis-l2
*>
192.168.15.0/24
192.168.15.2
connected
192.168.15.0/24
192.168.15.1
115
20
*>
192.168.15.2/32
192.168.15.2
connected
*>
192.168.100.0/22
192.168.15.1
115
10
isis-l2
*>
255.255.255.255/32
254
special
0.0.0.0
isis-l2

!
router isis
area 02
system-id 3333.3333.3333
is-type level-1-2
!
!
End

System id
Metric
Next-Hop
Interface
SNPA
6-25
SJ-20100901100356-015|2011-07-30(R1.0)

P3
--
P4
10
P4
vlan4
00D0.D0C0.3201

System id
Metric
Next-Hop
Interface
P1
20
P2
vlan6
00D0.D0C0.1901
SNPA
P2
10
P2
vlan6
00D0.D0C0.1901
P3
--

Interface
System id
State
Lev
Holds
SNPA(802.2)
Pri
vlan4
P4
UP
L1
00D0.D0C0.3201
64
vlan6
P2
UP
L2
26
00D0.D0C0.1901
64
MT

Protocol routes:
Dest
NextHop
RoutePrf
RouteMetric
Protocol
*>
0.0.0.0/0
0.0.0.0
254
special
*>
192.168.13.0/24
192.168.13.3
connected
192.168.13.0/24
192.168.13.4
115
*>
192.168.13.3/32
192.168.13.3
*>
192.168.14.0/24
192.168.14.3
192.168.14.0/24
192.168.14.2
115
*>
192.168.14.3/32
192.168.14.3
*>
192.168.15.0/24
192.168.14.2
115
20
isis-l2
*>
192.168.100.0/22
192.168.14.2
115
20
isis-l2
*>
255.255.255.255/32 0.0.0.0
254
20
isis-l1
connected
connected
20
0
isis-l2
connected
special

!
router isis
area 02
system-id 4444.4444.4444
is-type level-1
default-information originate
redistribute static metric 10
!
!
End
6-26
SJ-20100901100356-015|2011-07-30(R1.0)

System id
Metric
P3
10
P4
--
Next-Hop
Interface
P3
vlan4
SNPA
00D0.D0C0.2581

System id
Metric
Next-Hop
Interface
SNPA

Interface
System id
vlan4
State
P3
UP
Lev
Holds
L1
25
SNPA(802.2)
Pri
00D0.D0C0.2581
MT
64

Protocol routes:
Dest
NextHop
RoutePrf
RouteMetric
Protocol
*> 0.0.0.0/0
192.168.14.10
0.0.0.0/0
192.168.13.3
115
10
static
0.0.0.0/0
0.0.0.0
254
special
*> 192.168.13.0/24
192.168.13.4
connected
isis-l1
192.168.13.0/24
192.168.13.3
115
*> 192.168.13.4/32
192.168.13.4
connected
*> 192.168.14.0/24
192.168.14.1
connected
*> 192.168.14.1/32
192.168.14.1
connected
254
special
*> 255.255.255.255/32
0.0.0.0
20
isis-l1
6.2.3 Configuring IS-IS FRR

Fast Reroute (FRR) provides backup for failed links and nodes, minimizes the impact on
traffic, and restores traffic in a short time.
Typical FRR networking:
1. Figure 6-3 shows the typical networking of node protection.
Figure 6-3 Typical Networking of Node Protection
6-27
SJ-20100901100356-015|2011-07-30(R1.0)
2. Figure 6-4 shows the typical networking of link protection. IS-IS neighboring topology
is established between two links, providing primary and secondary links.
Figure 6-4 Typical Networking of Link Protection
1. Configure routing protocols.
2. For a destination, configure two or more next hops on FRR nodes and different costs
for routes.
3. Enable FRR on the router running the routing protocol.
The detailed configurations are:
1. This document takes the FRR configuration for node protection of BGP as an example.
For detailed configuration, refer to the example for configuring BGP FRR.
2. Link protection
Take Figure 6-4 as an example to configure IS-IS FRR.
P1(config-router)#fast-reroute enable
P1(config-if-vlan20)#isis metric 20

6-28
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-router)#fast-reroute enable
Run the show ip forwarding backup route command to view the configuration results and
check whether FRR is enabled.
IS-IS FRR status on P1:
P1(config)#show isis fast-reroute-topology
System id
P2
Interface
Ipfrr interface
Ipfrr type
Metric
vlan20
Link
20
Ipfrr interface
Ipfrr type
Metric
vlan20
Link
20
vlan10

System id
P2
Interface
vlan10

System id
Metric
P1
--
P2
10
Next-Hop
Interface
P2
vlan10
SNPA
00D0.D0C0.1901

System id
Metric
P1
--
P2
10
Next-Hop
Interface
P2
vlan10
SNPA
00D0.D0C0.1901
6.3 IS-IS Troubleshooting

6.3.1 Handling Basic IS-IS Fault
Take the topology shown in Figure 6-5 as an example to describe how to handle an IS-IS
fault, such as the fault that the neighboring relationship cannot be established in the default
configuration, or the topology is not figured out.
6-29
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 6-5 Network Topology for Handling IS-IS Fault

Fault symptom: IS-IS route is not available between P1 and P2.
Fault analysis:
1. Check whether the management status of the physical interfaces are up. If the status
is down, check whether the interface is shut down. If the management, physical, and
protocol status of the interface is up, check whether both ends can ping through each
other. If they cannot ping through each other, replace the cable.
2. Configure IS-IS and enable IS-IS on the interface. Run the show isis circuits command
to view the IS-IS interfaces and their status. If the interface is included in the execution
result of the command, view the status of the interface. If the status is down, check
the link status.
3. Configure IS-IS on both devices and enables IS-IS on the corresponding interfaces.
Run the show isis adjacency command to view the neighbor status. If the status is
up, the neighboring relationship is successfully established. If the status is init, the
packet from the peer end is received. During the initial phase of link establishment, the
status is init for 10 seconds. If the status is always init, check whether authentication
is correctly configured on both ends.
4. Check whether the topology is correctly figured out. Run the show isis topology
command to view the topology calculation. If the topology is not figured out, check
whether the values of metric-type and the authentication in routing mode on both
ends are consistent.

If both devices are configured with IS-IS, but the status of the neighbor is not up, follow
the flow shown in Figure 6-6 to check whether the configurations are correct and further
locate and troubleshoot the fault.
6-30
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 6-6 Flow to Handle an IS-IS Fault

The procedure to handle a basic IS-IS fault is described below.
1. Check whether both ends can ping through each other.
2. Run the show running-config module isis command to check whether IS-IS is enabled.
6-31
SJ-20100901100356-015|2011-07-30(R1.0)
3. Check whether the system ID of each device is unique. If the system IDs of two devices
are the same, they cannot establish the neighboring relationship.
4. Check whether the areas are correctly configured. If both areas are level-1, the areas
of the two devices must be identical. Otherwise, they cannot establish the neighboring
relationship.
5. Check whether the IS-types of the two devices are correctly configured. The IS-type
should overlap with the circuit-type on the interface. Otherwise, the two devices cannot
establish the neighboring relationship.
6. Check whether the IP router isis command is executed on directly connected interfaces.
7. Check whether circuit-type is correctly configured on the interface.
8. Check whether the authentication information is consistent on both ends.
9. Check whether metric-type on both ends is consistent in routing mode.
10. Check whether the authentication on both ends is consistent in routing mode.
6.3.2 Handling IS-IS FRR Fault

Take the topology shown in Figure 6-7 as an example to describe how to handle an IS-IS
FRR fault.
Figure 6-7 Network Topology for Handling IS-IS FRR Fault

If the IS-IS active/standby mode is configured and two or more routes to the same
destination are available, check whether the FRR configuration is compliant and whether
related requirements for forming the FRR relationship are met. For the down-stream FRR
relationship, which is the default mode, the algorithm should satisfy Distance_opt(Ni,
D)<Distance (S, D). To be specific, the distance from the next hop of the standby link to
the destination should be shorter than that from the source node of the active link to the
destination. For the LFAs detection mode, the algorithm should satisfy Distance_opt(Ni,
D)<Distance_opt(Ni, S)+Distance(S, D). To be specific, the distance from the next hop of
the standby link to the destination should be shorter than the sum of the distance from the
next hop of the standby link to the source node and the distance from the source node
of the active link to the destination.
6-32
SJ-20100901100356-015|2011-07-30(R1.0)
If the cost value of the link meets related requirement, check whether the fast-reroute disa
ble or fast-reroute block command is configured on the interface of the standby link.

The flow to handle an IS-IS FRR fault is shown in Figure 6-8.
Figure 6-8 Flow to Handle an IS-IS FRR Fault

The procedure to handle an IS-IS FRR fault is described below.
1. Use the show running-config module[bgp | ospf|isis] command to check whether
the FRR configuration is enabled.
The following command can be used to check whether the active/standby links are
configured:
show isis fast-reroute-topology [level-1 | level-2] If the link or node tag is included
without ecmp, the active/standby relationship is formed.
6-33
SJ-20100901100356-015|2011-07-30(R1.0)
6-34
SJ-20100901100356-015|2011-07-30(R1.0)
Chapter 7
BGP Configuration
Table of Contents
Configuring BGP ........................................................................................................7-1
BGP Maintenance and Diagnosis ............................................................................7-50
BGP Configuration Instances ...................................................................................7-57
BGP Troubleshooting ...............................................................................................7-71
7.1 Configuring BGP

7.1.1 Establishing BGP Neighbor
After establishing BGP sessions with each other, routers become BGP peers or BGP
neighbors. BGP peers can be Internal BGP (IBGP) peers or External BGP (EBGP) peers.
If the BGP session is within routers in the same autonomous system (AS), then it is called
iBGP (Internal BGP). If the session is to another AS, then it is called eBGP (extenal BGP).
As shown in Figure 7-1, P1 and P2 are EBGP neighbors and P2 and P3 are IBGP
neighbors.
Figure 7-1 IBGP and EBGP Neighbors
7-1
SJ-20100901100356-015|2011-07-30(R1.0)
7.1.1.1 Establishing EBGP Neighbor

The physical connection between the nodes should be proper and the nodes should belong
to different ASs.
In normal cases, EBGP neighbors are directly connected. BGP connections can be
established through the IP addresses of connected ports or the specified loopback
addresses of the routers.
To establish EBGP connections between indirectly connected routers, you need to specify
the multi-hop connection when configuring the routers. Otherwise, since the TTL value of
BGP data packets in EBGP communications are set to 1 on routers by default, the open
packet cannot be sent to the CPU of the peer router even after the bottom layer TCP
connection is established. As a result, the connection cannot enter the Established state.
Step
Command
Function
ZXCTN 9000(config)#router bgp < as-number>
Starts the BGP process and specifies

the number of the AS where the
router resides.
The value of parameter as-number
specifies the the number of the AS
where the router resides. The value
of this parameter ranges from 1 to
65535. 1 to 64511 are public AS
numbers and 64512 to 65535 are
private AS numbers. The current
version support the four-byte AS
number. The value ranges from 1 to
4294967295.
ZXCTN 9000(config-router)#neighbor [ <
Configures a BGP neighbor or a peer
ipv4-address> | < peer-group-name> ] remote-as <
group and the AS number of the
number>
group.
(Optional) Use this command to
ipv4-address> | < peer-group-name> ] ebgp-multihop
establish EBGP neighbors when
[ ttl < value> ]
routers are indirectly connected.

This command establishes EBGP
neighbors over indirectly connected
networks.
7-2
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ipv4-address> | < peer-group-name> ] update-source
establish EBGP connections through
< vlan id>
loopback addresses. This command

specifies the local loopback address
as the source IP address for
establishing TCP connections.

Parameter
< ipv4-address>
Description
Indicates the IPv4 address of the neighbor, in dotted decimal
notation.
< peer-group-name>
Indicates the name of the peer group.
< number>
Indicates the number of the AS where the neighbor resides. The

value of this parameter ranges from 1 to 65535.

Parameter
< ipv4-address>
Description
notation.
< peer-group-name>
< number>
Indicates the number of the AS where the neighbor resides. For

two-byte AS numbers, the value of this parameter ranges from 1
to 65535. For four-byte AS numbers, the value of this parameter
< value>
Indicates the TTL value. The value of this parameter ranges

from 1 to 255.

Parameter
< ipv4-address>
Description
notation.
< peer-group-name>
< vlan id>
Indicates the interface name used as the source address for

establishing TCP connections in the BGP session.
Example
1. Establish EBGP neighbors through directly connected addresses.
7-3
SJ-20100901100356-015|2011-07-30(R1.0)
As shown in Figure 7-2, P1 is in AS65000 and P2 is in AS65001. Establish EBGP

neighbors through the directly connected ports on P1 and P2.
Figure 7-2 Network Topology for Configuring EBGP Neighbors Through Directly
Connected Ports

P1#config terminal
vlan 1

P1(config)#router bgp 65000
P1(config-router)#neighbor 129.213.1.2 remote-as 65001

P2#config terminal
vlan 1

Configuration verification:
Run the show ip bgp neighbor command on P1 to view the BGP neighboring
relationship:
P1#show ip bgp neighbor
BGP neighbor is 129.213.1.2, remote AS 65001, external link
BGP version 4, remote router ID 129.213.1.2
7-4
SJ-20100901100356-015|2011-07-30(R1.0)

BGP state = Established, up for 00:04:21
hold time is 90 seconds, keepalive interval is 30 seconds
Connections established 1
Local host: 129.213.1.1, Local port: 179
Foreign host: 129.213.1.2, Foreign port: 1024
The above output shows that the IP address of the BGP neighbor is 129.213.1.2. The
neighbor is in AS65001 and the EBGP connection is established. The router ID of the
neighbor is 129.213.1.2, the state is Established, and the session is established for 4
minutes and 21 seconds.
relationship. The output description is similar as the above command.
2. Establish EBGP neighbors through loopback addresses.

As shown in Figure 7-3, EBGP neighbors are established through the loopback
addresses on P1 and P2.
Figure 7-3 Network Topology for Configuring the EBGP Neighbors Through
Loopback Addresses
7-5
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config)#interface Loopback1
P1(config-router)#neighbor 1.1.1.2 ebgp-multihop ttl 5
P1(config-router)#neighbor 1.1.1.2 update-source Loopback1
P1(config)#ip route 1.1.1.2 255.255.255.255 192.168.1.2

P2#config terminal
P2(config)#interface Loopback1
P2(config-router)#neighbor 1.1.1.1 update-source Loopback1
P2(config)#ip route 1.1.1.1 255.255.255.255 192.168.1.1
If the number of hops is not specified behind the ebgp-multihop parameter, the TTL
value is set to the maximum value, which is 8, by default.
Configuration verification: Run the show ip bgp neighbor command on P1 to view the
BGP neighboring relationship:
The above output shows that an EBGP connection is established between P1 in the
local and ZXCTN, whose IP address is 1.1.1.2, in AS65001.
7-6
SJ-20100901100356-015|2011-07-30(R1.0)
relationship:
The above output shows that an EBGP connection is established between P2 in the
local and ZXCTN, whose IP address is 1.1.1.1, in AS65000.
7.1.1.2 Establishing IBGP Neighbors

The physical connection between the nodes should be proper and the nodes should belong
to the same AS.
IBGP neighbors exchange BGP update packets within an AS to maintain the internal
connectivity of the AS.
It is defined that an IBGP router cannot send the route from the other IBGP router to
other IBGP routers. This is the generally called the split-horizon rule. When receiving
an update packet through EBGP, a router processes the packet and sends it to the rest
EBGP neighbors and all IBGP neighbors. When receiving an update packet through IBGP,
the router processes the packet and sends it to only EBGP neighbors. Therefore, BGP
routers should achieve a full meshed connection through IBGP sessions within an AS to
maintain the BGP connectivity. If a physically full meshed connection is not available, the
connectivity may be affected.
Step
Command
Function

router resides.
Configures a BGP neighbor or a
ipv4-address> | < peer-group-name> ] remote-as <
peer group and the AS number of
number>
the group.
ipv4-address> | < peer-group-name> ] update-source <
establish EBGP connections through

loopback addresses. This command
interface-name>
specifies the local loopback address

as the source IP address for
establishing TCP connections.
7-7
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
Forcibly uses the own interface
ipv4-address> | peer-group-name> ] next-hop-self
address of the router as the next hop

address for advertising routes.
ZXCTN 9000(config-router)#no synchronization
Disables the synchronization

function so that the BGP neighbor
can advertise routes without waiting
for IGP synchronization.

Parameter
Description
< ipv4-address>

notation.
< peer-group-name>
< number>
Indicates the number of the AS where the neighbor resides. For

two-byte AS numbers, the value of this parameter ranges from 1
to 65535. For four-byte AS numbers, the value of this parameter

Parameter
Description
< ipv4-address>

notation.
< peer-group-name>
< vlan id>
Indicates the interface name used as the source address for

establishing TCP connections in the BGP session.

Parameter
Description
< ipv4-address>

notation.
< peer-group-name>
In step 4, NEXT_HOP is a mandatory attribute that describes the IP address of the

next-hop router on the path to the destination address. There are there application
scenarios:
l
If the source and destination routers are in different ASs, the next-hop address is the
IP address of the interface on the router advertising the route.
7-8
SJ-20100901100356-015|2011-07-30(R1.0)
If the source and destination routers are in the same AS, and the destination of NLRI
in the update packet is also in the AS, the next-hop address is the IP address of the
neighbor.
If the source and destination routers are BGP peers in an AS, and NLRI in the update
packet is bound for another AS, the next-hop address is the IP address of the external
peer of the learned route.
When an AS provides the transition service for another AS, the synchronization function in
step 5 guarantees that a BGP neighbor can send a route to external neighbors only after
all routers within the AS receive the route through IGP route spreading. When receiving a
route update packet from an IBGP neighbor, the router checks the synchronization before
forwarding the packet to EBGP neighbors. The packet is forwarded to EBGP neighbors
only when the IGP on the router recognizes the update packet, that is, the IGP routing
table contains the entry of the route. Otherwise, the router does not forward the packet.
The synchronization function is to ensure the connectivity inside an AS, avoiding
blackholes caused by routing loops. However, the synchronization function is generally
disabled in practice. The full meshed connection is used in the AS to guarantee
connectivity, thus avoiding large numbers of BGP routes injected to the IGP, accelerating
the processing rate of the router, and eliminating packet losses. To disable the
synchronization function without affecting service, one of the following requirements
should be met:
1. The AS must a stub AS, that is, the AS has only one interface to connect to the external
network.
2. Although the AS provides the transition service, that is, an AS can connect to another
AS over the local one, BGP runs on all routers in the local AS.
The second requirement is common in practice because BGP is configured on all routers
of an AS and IGP only needs to transmit routing information for the local AS.
By default, the synchronization function is enabled on the ZXCTN9000. You can run the
no synchronization command to disable the function.
Example
As shown in Figure 7-4, create IBGP neighbors through loopback addresses. P2 and
P3 are in the same AS. Establishing IBGP neighboring relationship between P2 and P3
through loopback addresses.
7-9
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-4 Network Topology for Configuring IBGP Neighbors

P2#config terminal
vlan 1

P2(config-router)#neighbor 1.1.1.3 update-source loopback1
P2(config-router)#neighbor 1.1.1.3 next-hop-self
P2(config-router)#no synchronization

P3#config terminal
7-10
SJ-20100901100356-015|2011-07-30(R1.0)

Run the show ip bgp neighbor command on P2 to view the BGP neighboring relationship:
BGP neighbor is 1.1.1.3, remote AS 65001, internal link
last error code is 6
The above output shows that neighboring relationship is established between P2 and IP
address 1.1.1.3 (which is P3).
Run the show ip bgp neighbor command on P3 to view the BGP neighboring relationship:
BGP neighbor is 1.1.1.2, remote AS 65001, internal link
last error code is 5
The above output shows that neighboring relationship is established between P3 and IP
address 1.1.1.2 (which is P2).
7-11
SJ-20100901100356-015|2011-07-30(R1.0)
7.1.1.3 Configuring the Authentication Password for BGP Neighbors

To achieve valid MD5 authentication on TCP connections between BGP neighbors,
you can configure the authentication password. To get better confidentiality over BGP
connections, you can encrypted the password.
Step
Command
Function

router resides.
ZXCTN 9000(config-router)#neighbor < ip-address>
Configures the authentication for
password [ < string 1> | encrypt < string 2> ]
BGP neighbors, including the display

mode of the password.

Parameter
Description
< ip-address>
Indicates the IPv4 address of the neighbor, in dotted decimal notation.
< string 1>
Indicates the case sensitive password. The value of this parameter

ranges from 3 to 80 characters.
< string 2>
Indicates the case sensitive password. The value of this parameter

ranges from 3 to 80 characters.
Example
An example of configuring the authentication and password display mode of BGP
neighbors is shown below.
ZXCTN 9000(config)#router bgp 100
ZXCTN 9000(config-router)#neighbor 192.168.0.2 remote-as 100
ZXCTN 9000(config-router)#neighbor 192.168.0.2 password 789
ZXCTN 9000(config-router)#neighbor 192.168.0.2 password encrypt 123
ZXCTN 9000(config-router)#show running-config module bgp
router bgp 100
neighbor 192.168.0.2 password encrypt u5pd4oP1YGP1E+My5y4ec1dbC7
eZf4gsX0qhVYXcb6KV1CMnm8VFlX9dcceOjgUYrxPGh3Gy7Rl8VxSlqtHcujwZ5qzj
LbVOkiKWz41nHPk=
!
7.1.1.4 Restarting the BGP Process

When the state of BGP neighbors are abnormal, you can restart the BGP process.
The operation should be implemented in global configuration mode to restart a BGP
neighbor.
7-12
SJ-20100901100356-015|2011-07-30(R1.0)
Command
Function
ZXCTN 9000(config)#reset ip bgp [ vrf <
Restarts a BGP instance, a peer, or a peer group.
vrf-name> ] [ < ipv4-address> | < peer-group-name>

]

Parameter
Description
< vrf-name>
Indicates the name of the VRF. The value of this

parameter ranges from 1 to 32 characters.
< ipv4-address>
Indicates the IPv4 address of the neighbor.
< peer-group-name>
Indicates the name of the peer group. The value

of this parameters ranges from 1 to 64 characters.
7.1.2 Configuring BGP Route Advertisement

7.1.2.1 Principles of BGP Route Advertisement
The route to be advertised should be contained in the IGP routing table. The table is
injected to the BGP routing table as the source of BGP route update, directly affecting the
stability of routes on the Internet. The routing information can be injected in either dynamic
or static mode.
The dynamic mode is classified into complete dynamic injection and selective dynamic
injection.
In complete dynamic injection, all IGP routes are redistributed into the BGP routing table.
This mode features simple configuration but poor controllability and low efficiency.
In selective dynamic injection, certain information of the IGP routing table is injected into
the BGP routing table through commands such as the network command. In this mode,
the address and mask are verified, which greatly improves the controllability and efficiency,
and avoids the injection of incorrect route information.
But route instability is generated regardless of the injection mode. This is because that
the dynamic injection entirely depends on IGP information. When IGP routes change,
BGP routes are updated. Such instability generates large amount of update information
and hence cost abundant bandwidths. Route dampening and route aggregation can be
adopted to overcome the defect.
Static injection effectively removes route instability. In static injection, static routes are
injected into the BGP routing table. The static routes are man-made routes. Such routes
are not affected by IGP changes and hence are fairly stable. The stability of static routes
eliminates the repeated update caused by route changes. But, if the boarder of subnets is
fuzzy, the static injection also causes problems such as data flow block.
7-13
SJ-20100901100356-015|2011-07-30(R1.0)
In conclusion, the BGP route advertisement modes are:

1. Using the network command
2. Using the redistribute command to redistribute the routes learned by other routing
protocols into BGP
3. Advertisement of BGP route aggregation
7.1.2.2 Configuring Route Advertisement by Using the network Command

The route advertised through the network command should exist in the IGP routing table.
A common method for advertising BGP routes is using the network command to select
the network segment to be advertised by specifying the destination network segment and
mask. Routes accurately meeting the requirement are injected into the BGP routing table,
and then advertised based on related policies.
For example, after you run the network 18.0.0.0 255.0.0.0 command, routes corresponding
to the 18.0.0.0/8 network segment are injected into the BGP routing table. If IGP routing
table does not contain a route corresponding to the network segment or its subnets,
no routes are injected into the BGP routing table. Therefore, to collaborate with the
advertisement of BGP routes, certain static routes directing to the loopback address are
configured on the router.
Note that not every route injected into the BGP routing table can be advertised. The
advertisement is determined by the BGP route filtering or routing policy.
In BGP applications, you can run the network to advertise the networks learned by a router.
The learned networks are the networks directly connected to the router, or those that can
be learned through static or dynamic routes. The usage of the network command in BGP
is different from that in IGP.
Step
Command
Function

router resides.
ZXCTN 9000(config-router)#network< ip-address>
Injects the routes to be advertised to
< net-mask> [ route-map< map-tag> ]
the BGP routing table. The routes

can be connected routes, dynamic
routes, or static routes.
Example
As shown in Figure 7-5, advertise routes by using the network command. OSPF of IGP
runs on P2. On P2, inject network segment 18.0.0.0/8 discovered by OSPF into the BGP
routing table of P1.
7-14
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-5 Advertising Route by Using the network Command

P2#config terminal
P2(config-router)#network 18.0.0.0 255.255.255.0

P1#config terminal
View the configuration. Run the show ip bgp command to view the BGP routing table on
P1.
P1#show ip bgp
7-15
SJ-20100901100356-015|2011-07-30(R1.0)

Status codes: *-valid, >-best, i-internal,s-stale
Origin codes: i-IGP, e-EGP, ?-incomplete
Dest
*>18.0.0.0/8
NextHop
Metric
LocPrf
RtPrf
192.168.2.1
20
65001
Path
In the output of the show ip bgp command, the asterisk (*) indicates a valid route, the angle
bracket (>) indicates the optimal route, i indicates an IBGP route, and the route not marked
by i is an EBGP route or a locally generated route. The IP address of the NextHop column
is the next-hop address of the BGP route. The all-zero route is locally generated. The
value of the LocPrf column is local priority of the route learned by BGP. The value is 100
by default. The value of the Path column indicates the source of the route, including IGP,
EGP, and Incomplete.
The above information shows that the route to network segment 18.0.0.0/8 already exists
in the BGP routing table on P1. The next-hop address is 192.168.2.1, which is the IP
address of the interface on P2.
7.1.2.3 Configuring Route Redistribution by Using the redistribute Command

IGP should be configured on the ZXCTN9000.
In scenarios where route entries are of a large number and route aggregation is difficult
to implement, BGP routes have to be injected in complete injection mode. IGP routes
of a certain or multiple types are redistributed into the BGP routing table for simple and
convenient configuration.
You can use the redistribute command to redistribute IGP routes such as RIP, OSPF, and
IS-IS routes into the BGP routing table. When using this command, make sure that routes
learned from BGP are not redistributed into BGP again. You can use the filtering command
to avoid routing loops when necessary.
Run the following commands on the ZXCTN 9000 to distribute routes:
Step
Command
Function
ZXCTN9000(config)#router bgp < as-number>

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#redistribute < protocol> [ metric <
Redistribute the routes learned by
metric-value> ] [ route-map < map-tag> ]
other routing protocols into the BGP

routing table.

Parameter
Description
< protocol>
Indicates the name of other protocols, including connected, static, rip,

ospf-int, ospf-ext, isis-1, isis-2, and isis12.
7-16
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< metric-value>
Indicates the metric value used in route redistribution. If no value is

specified, the default value is adopted. The value of this parameter
< map-tag>
Indicates the name of the mapping used in route redistribution. The

value of this parameter ranges from 1 to 32 characters.
Redistributing Route by Using the redistribute Command

As shown in Figure 7-6, OSPF runs on P2. Import OSPF routes of P2 into the BGP routing
table.
Figure 7-6 Network Topology for Redistributing Route into the BGP Routing Table

P2#config terminal
P2(config)#exit
P2(config-router)#redistribute ospf-int
P2(config)#exit
7-17
SJ-20100901100356-015|2011-07-30(R1.0)
View the configuration. Run the show ip bgp route command to view the BGP routing table
on P1.
P1#show ip bgp route
Dest
*>
18.0.0.0/8
NextHop
Metric
LocPrf
RtPrf
20
65001
192.168.2.1
Path
To import external OSPF routes to P2 and set the value of metric to 5, run the following
command:
P2#config terminal
P2(config)#exit
P2(config-router)#redistribute ospf-ext metric 5
P2(config)#exit
7.1.2.4 Configuring Route Aggregation

The masks aggregated on the ZXCTN9000 must be identical, otherwise, blackholes may
occur.
BGP can aggregate multiple learned routes into one routing information and advertise it,
greatly reducing route entries in the routing table.
Step
Command
Function

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#aggregate-address < ip-address> <
Creates a route aggregation policy
net-mask> [ count < count> ] [ as-set] [ summary-only] [ strict]
in the BGP routing table.

Parameter
Description
< ip-address>
Indicates the aggregation network to be generated, in dotted decimal

notation.
< net-mask>
Indicates the mask to be generated, in dotted decimal notation.
7-18
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< count>
Indicates the required number of subnets in route aggregation. The

value of this parameter ranges from 0 to 255. The default value is 1.
as-set
Generates AS path information.
summary-only
If this parameter is specified, only the aggregated route is advertised

to BGP neighbors, excluding the aggregated subnet routes.
According to RFC1771, only the routes with identical MED and
strict
NEXT_HOP attributes can be aggregated. Otherwise, the requirement

on route aggregation can be adjusted to exclude the MED and
NEXT_HOP attributes.
Configuring Route Aggregation

As shown in Figure 7-7, the ZXCTN9000 (P1) advertises its own network segment and
internal route network segments 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, and
192.168.3.0/24 to P2 (also a ZXCTN9000) in AS300. OSPF runs on P1 and P3.

7-19
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-router)#aggregate-address 192.168.0.0 255.255.252.0 count 0 summary-only
area 0

After the above configuration is completes, P1 learns route 192.168.0.0/24,

192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 through IBGP. But only the
aggregated route 192.168.0.0/22 is advertised to P2 through EBGP. If parameter
summary-only in the route aggregation command is not specified, detailed routes are
advertised with the aggregated route.
View the configuration. Run the show ip bgp route command on P2 to view the routing
table that has received the aggregated route.
Status codes: *valid, >best, i-internal
Dest
*>192.168.0.0/22
NextHop
Metric
LocPrf
RtPrf
2.2.2.2
20
Path
100 i
P2#show ip bgp route detail 192.168.0.0 255.255.252.0

BGP routing table entry for 192.168.0.0/22
01:02:19 received from 2.2.2.2
origin i,nexthop 2.2.2.2,atomic,aggr 100 2.2.2.2,
as path [100]
After route aggregation is completed, the BGP routing table on P2 in AS300 contains only
one route, which greatly reduces the scale of the routing table. In addition, the aggregated
route carries atomic aggregation and aggregation attribute, and indicates the aggregation
point.
If the summary-only parameter is not specified, P2 advertises both aggregated and detailed
routes. The following shows the command output.
Dest
NextHop
Metric
LocPrf
RtPrf
Path
*>192.168.0.0/22
2.2.2.2
20
100 i
*>192.168.0.0/24
2.2.2.2
20
100 i
*>192.168.1.0/24
2.2.2.2
20
100 i
*>192.168.2.0/24
2.2.2.2
20
100 i
*>192.168.3.0/24
2.2.2.2
20
100 i
7-20
SJ-20100901100356-015|2011-07-30(R1.0)
The above output shows that the aggregated route 192.168.0.0/22, and detailed route
192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 are displayed.
Parameter < count> indicates the required number of subnets in route aggregation. The
value of this parameter ranges from 0 to 255. The default value is 1, indicating that one
subnet exists in the IGP routing table on the router advertising the route. If the parameter
is specifies as 0, route 192.168.0.0/22 is advertised when any subnet of 192.168.0.0
255.255.252.0 exists in the IGP routing table. If the parameter is specifies as other
values, you need to run the following command to specify the subnet.
aggregate-address < ip-address> < net-mask> subnet < subnet-address> < subnet-mask>
After the command is executed, route aggregation and advertisement are implemented
when the specified subnet exists in the IGP routing table and the number of subnets
reaches the value of count.
Aggregating Routes with Parameters count and subnet

If the IGP routing table on P1 contains the latter three of routes 192.168.0.0/24,
192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24, P1 sends the aggregated route
192.168.0.0/22 to P2.
vlan 1

P1(config-router)#aggregate-address 192.168.0.0 255.255.252.0 count 3
summary-only
P1(config-router)#aggregate-address 192.168.0.0 255.255.252.0 subnet
192.168.1.0 255.255.255.0
192.168.2.0 255.255.255.0
192.168.3.0 255.255.255.0
After the commands are executed, P2 advertises the aggregated route 192.168.0.0/22
to P1 when routes 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 are properly
advertised, regardless the status of route 192.168.0.0/24.
But if any of routes
7-21
SJ-20100901100356-015|2011-07-30(R1.0)
192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 is abnormal, P2 does not advertise

the aggregated route to P1.
7.1.3 Configuring BGP Load Balancing

l
Per-destination
per-packet
Advan-
Path usage is high. Since this method uses polling
tage
destination, only one route is used. Packets to
to determine paths for packets, traffic is balanced
different destinations are routed along different
among paths.
paths.
Disad-
Traffic to one destination may be routed through
vantage
different paths, resulting in the sequencing of
making load unbalanced. This method achieves
receiving ends. Therefore, this method is not
effective load balancing only in the case of many
applicable to traffic requiring specific sequence,
destinations.
such as VoIP.
Use these commands to configure BGP routing load balancing on the ZXCTN 9000.
Step
Command
Function
Enters the BGP configuration mode.
ZXCTN 9000(config-bgp)#maximum-paths ibgp< number>

is 1 (for IBGP load balancing).
ZXCTN 9000(config-bgp)#maximum-paths < number>

is 1 (for EBGP load balancing).
7-22
SJ-20100901100356-015|2011-07-30(R1.0)
7.1.4 Configuring BGP FRR

Use these commands to configure BGP FRR on the ZXCTN 9000.
Step
Command
Function
ZXCTN9000(config-bgp)#bgp frr
Enables BGP FRR.
7.1.5 Configuring BGP Attribute and Route Filtering

7.1.5.1 Filtering Routes by Route Map
The network is correctly connected and BGP runs properly.
The setting of route filtering and attribute are the basic for BGP decision. By route filtering,
you can control the input or output route attributes.
The route map controls routing information and reassigns routes among routing protocols
according to specified conditions. Generally, the route map makes decisions base on route
attributes.
Step
Step
1
Command
Function
ZXCTN9000(config)#route-map < map-tag> [ permit | deny] [ <
Creates the route map.
sequence-number> ]
2

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#neighbor [ < ipv4-address> | <
Defines a route map.
peer-group-name> ] route-map < map-tag> { in | out}

Parameter
Description
< map-tag>
Indicates the name of the route mapping, consisting of 1 to 64

characters.
permit
If the route mapping matches the condition, the mapping is allowed to

be reassigned or tagged.
deny
If the route mapping matches the condition, the mapping is not allowed
to be reassigned or tagged.
< sequence-number>
Indicates the sequence number. The value of this parameter ranges

from 0 to 65535.
7-23
SJ-20100901100356-015|2011-07-30(R1.0)

Parameter
Description
< ipv4-address>
< peer-group-name>
< map-tag>

characters.
in | out
Indicates whether to output or input the route.
Filtering Routes by Route Map

As shown in Figure 7-8, establish an EBGP connection between the ZXCTN9000s, that
is, P1 and P2. Configure a route map on P1 to advertise network 172.3.0.0/16 to AS200,
and set the MED value to 5.
Figure 7-8 Network Topology for Filtering Routes by Route Map

P1(config-bgp)#neighbor 182.17.20.1 remote-as 200
P1(config-bgp)#network 172.3.0.0 255.255.0.0
P1(config-bgp)#neighbor 182.17.20.1 route-map MAP1 out
P1(config-bgp)#neighbor 182.17.20.1 send-med
P1(config-bgp)#exit
P1(config)#route-map MAP1 permit 10
7-24
SJ-20100901100356-015|2011-07-30(R1.0)

P1(config-route-map)#match ip address 1
P1(config-route-map)#set metric 5
P1(config-route-map)#exit
P1(config)#ipv4-access-list 1
P1(config-ipv4-acl)#rule 10 permit 172.3.0.0 0.0.255.255
P1(config-ipv4-acl)#exit
The above output shows that the route filtering is configured. In route filtering by route
map, the match and set are also generally used. The match command defines the matching
condition and the set command defines the action after the matching condition is hit.
After the neighbor 182.17.20.1 send-med command is executed, the MED value is sent to
neighbor 182.17.20.1 with the advertised route.
View the configuration. Run the show ip bgp route on P2 to view its BGP routing table.
Dest
NextHop
Metric
*>172.3.0.0/16
182.17.20.2
LocPrf
RtPrf
Path
20
100 i

07:18:49 received from 182.17.20.2 (172.3.0.1)
origin i,nexthop 182.17.20.2,metric 5,
as path [100]
The above output shows that P2 learns only the route to network segment 172.3.0.0/16,
and the metric value is 5.
7.1.5.2 Filtering Routes by NLRI

To forbid the ZXCTN9000 to obtain or advertise the route selection information, you can
filter out the route update from or to a specified neighbor. The filter contains a list of route
update from or to a specified neighbor.
Step
Command
Function
sequence-number> ]
2
Binds the specified route map to
peer-group-name> ] route-map < map-tag> { in | out}
match BGP routes or change the

route attribute.

7-25
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< map-tag>

characters.
permit
deny
< sequence-number>

from 0 to 65535.

Parameter
Description
< ipv4-address>
< peer-group-name>
< map-tag>

characters.
in | out
Indicates whether to output or input the route.
Filtering Routes by NLRI

As shown in Figure 7-9, P2 and P2 are IBGP peers, P1 and P3 are EBGP peers, and P2
and P4 are EBGP peers. To forbid AS100 to work as a transition AS and P1 to advertise
network 192.18.10.0/24 from AS300 to AS200, the filtering function should be configured
on P1.
Figure 7-9 Network Topology for Filtering Routes by NLRI
7-26
SJ-20100901100356-015|2011-07-30(R1.0)
The configuration of P1 (port and IGP configurations):

P1(config-bgp)#no synchronization
P1(config-bgp)#neighbor 182.17.1.2 next-hop-self
P1(config-bgp)#neighbor 182.17.20.1 route-map MAP1 out
P1(config-bgp)#exit
P1(config)#route-map MAP1 permit 10
P1(config)#acl standard number 1
P1(config-std-acl)#rule 1 deny 192.18.10.0 0.0.0.255
P1(config-std-acl)#rule 2 permit any
With the application of the Access Control List (ACL) and the route-map command, P1
is forbidden to send the route with prefix 192.18.10.0/24 to AS200. That is, the route
with prefix 192.18.10.0/24 is filtered out on P1. In this way, P3 cannot learn the route to
192.18.10.0/24.
Run the show ip bgp route command to view the BGP routing table P3.
Dest
NextHop
Metric
LocPrf
RtPrf
Path
*>192.168.11.0/24
182.17.20.2
20
300
100 i
*>192.168.12.0/24
182.17.20.2
20
300
100 i
*>192.168.13.0/24
182.17.20.2
20
300
100 i
The above route shows that P3 in AS200 does not learn the route to 192.18.10.0/24.
7.1.5.3 Restricting the Number of Routes Accepted by A Neighbor

Through BGP, the number of routes accepted by a neighbor can be restricted. Use these
commands on the ZXCTN 9000.
Step
Command
Function

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#neighbor < ip-address> maximum-prefix
Configures the maximum number
< value> [ < threshold-value> | drop-routes | restart < time> |
of routes that can be accepted by a
warning-only]
neighbor.

7-27
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< ip-address>
Indicates the IP address of the neighbor, in dotted decimal notation.
< value>
Indicates the maximum number of roues that can be accepted by a

neighbor. The value of this parameter ranges from 1 to 4294967295.
< threshold-value>
Indicates the threshold (%) for generating an alarm. When the

proportion of received routes to the maximum value reaches the
threshold, an alarm is generated.
Indicates that routes are discarded when the number of received
drop-routes
routes exceeds the maximum value.

< time>
Indicates that the link is disconnected after the number of received

routes exceeds the maximum value. The link is re-established after
the specified duration. The value this parameter ranges from 1 to
30000, in minutes.
Displays only alarms when the number of received routes exceeds
warning-only
the maximum value.
Example
In the example shown in Figure 7-10, P1 allows P2 to advertise a maximum of 10 routes
to P1, excess routes are discarded. P2 allows P1 to advertise a maximum of 20 routes
to P2. If the route number exceeds 20, the link is disconnected and re-established after 1
minutes.
Figure 7-10 Restricting the Number of Routes Accepted by A Neighbor

P1(config-bgp)#neighbor 10.1.1.1 maximum-prefix 10 drop-routes

P2(config-bgp)#neighbor 10.1.1.2 maximum-prefix 20 restart 1
7-28
SJ-20100901100356-015|2011-07-30(R1.0)
If the restart time is not specified and P1 advertises more than 20 routes to P2, to display
only alarms on P2, use warning-only.
P2(config-bgp)#neighbor 10.1.1.2 maximum-prefix 20 warning-only
7.1.5.4 Filtering Routes by AS_PATH

AS_PATH is a well-known mandatory attribute, which contains a path segment consisting
of a series of AS numbers for a route to reach a destination. The AS generating the route
adds its AS number when sending the route to EBGP peers. Afterwards, each AS receiving
the route adds its number in front of other AS numbers when sending the route to peers.
BGP uses AS_PASH as a key factor of route update to a achieve acyclic topology over
connected networks. Each route contains the numbers of ASs it passes through. If a
route is advertised to an AS whose number already exists in the route, the AS does not
receive the route. In addition, AS_PATH is used for determining the optimal route. When
multiple routes are available to a destination and they possess identical attributes except
for AS_PATH, BGP selects the route of the shortest patch as the optimal route. Therefore,
in certain scenarios, you can change BGP route selection by adding AS_PATH on the
ZXCTN9000.
When all routes of one or multiple ASs need to be filtered, AS_PATH is generally used.
AS_PATH-based route filtering avoids the complexity of prefix-based route filtering.
Step
Command
Function
ZXCTN9000(config)#ip as-path access-list < access-list-number> {
Defines the ACL corresponding to
permit | deny} < as-regular-expression>
AS_PATH
Enters the route mapping
sequence-number> ]
configuration mode.
ZXCTN9000(config-route-map)#set as-path prepend <
Modifies the AS path of a BGP route.
as-path-number> [ < as-path-number> ]

from 1 to 65535, or 1 to 4294967295.

Parameter
Description
< map-tag>

characters.
permit

7-29
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
deny
< sequence-number>

from 0 to 65535.

Parameter
Description
< access-list-number>
Indicates the access list number in the regular expression.
permit
Allows reassignment or tagging.
deny
Disallows reassignment or tagging.
< as-regular-expression>
Indicates the AS uses the regular expression in the access list.
Filtering Routes by AS_PATH

Figure 7-11 shows the network topology of multiple ASs.
Select path
AS500->AS300->AS200->AS100 as the optimal path for the access from the Internet
to AS100 in 10.1.0.0/24.
Figure 7-11 Network Topology for Selecting Routes by AS_PATH
The configuration on the ZXCTN9000 at the egress of AS100:

ZXCTN9000_AS100(config)#router bgp 100
ZXCTN9000_AS100(config-bgp)#network 10.0.1.0 255.255.255.0
7-30
SJ-20100901100356-015|2011-07-30(R1.0)

ZXCTN9000_AS100(config-bgp)#neighbor 192.168.1.2 remote-as 400
ZXCTN9000_AS100(config-bgp)#neighbor 192.168.1.2 activate
ZXCTN9000_AS100(config-bgp)#neighbor 192.168.1.2 route_map PATH out
ZXCTN9000_AS100(config-bgp)#exit
ZXCTN9000_AS100(config)#acl standard number 1
ZXCTN9000_AS100(config-std-acl)#permit 10.1.0.0 0.0.0.255
ZXCTN9000_AS100(config-std-acl)#exit
ZXCTN9000_AS100(config)#route_map PATH permit 0
ZXCTN9000_AS100(config_route_map)#match ip address 1
ZXCTN9000_AS100(config_route_map)#set as-path prepend 100 100 100 100
ZXCTN9000-AS100(config-route-map)#exit
The selection of routes for the access from AS500 to AS100 is affected by the routing
policy that adds AS_PATH to the advertised route.
on the ZXCTN9000 in AS500.
ZXCTN9000_AS500#show ip bgp route
Dest
NextHop
Metric LocPrf
*>10.0.1.0/24
192.168.1.17
20
*>10.0.2.0/24
192.168.1.17
20
*>10.0.3.0/24
192.168.1.17
20
*>10.0.4.0/24
192.168.1.17
*>10.1.0.0/24
192.168.1.17
20
RtPrf
Path
300 200
100 i
300 200 100 400 i
300
200 i
300 200
100 i
300 i
400 100 100

>10.1.0.0/24
192.168.1.13
20
100 100 100 i
ZXCTN9000_AS500#show ip bgp route detail 10.1.0.0 255.255.255.0

01:19:50 received from 192.168.1.11 (10.0.2.1)
origin i,nexthop 192.168.1.13,
as path [400 100 100 100 100 100]
The above output shows that after AS_PATH is added, AS500 learns that the number of
ASs to the destination is 6 from AS400 and 3 from AS300. Therefore, the path with fewest
ASs is selected when other attributes are identical. In this example, the path from AS300
to AS100 meets the requirement and hence is selected.
7-31
SJ-20100901100356-015|2011-07-30(R1.0)
7.1.5.5 Filtering Routes by LOCAL_PREF

LOCAL_PREF is a well-known discretionary attribute. The ZXCTN9000 identifies and uses
the attribute. The default value of this attribute is 100.
The ZXCTN9000 should add this attribute when broadcasting routes to other routes in
the AS. The value of LOCAL_PREF affects route priority. The route with the largest
LOCAL_PREF value is selected as the optimal route. LOCAL_PRE affect outbound traffic
and is used only inside the local AS. That is, LOCAL_PREF is exchanged only between
IBGP neighbors and is available to EBGP neighbors.
Step
Command
Function
1
sequence-number> ]
2
sequence-number> ]
configuration mode.
ZXCTN9000(config-route-map)#set local-preference < value>
Configures priority value of

LOCAL_PREF. The value of
this parameter ranges from 0 to
4294967295. The default value is
100.

Parameter
Description
< map-tag>

characters.
permit
deny
< sequence-number>

from 0 to 65535.
Selecting Routes by LOCAL_PREF

As shown in Figure 7-12, the ZXCTN9000s, that is , P1, P2, and P3 are IBGP neighbors.
Use LOCAL_PREF to make all outbound services select P1 to reach to AS300.
7-32
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-12 Network Topology for Selecting Routes by LOCAL_PREF

P1(config-bgp)#neighbor 172.16.1.2 activate
P1(config-bgp)#neighbor 172.16.1.2 route-map Local_Pref in
P1(config-bgp)#exit
P1(config-std-acl)#permit any
P1(config)#route-map Local_Pref permit 10
P1(config-route-map)#set local-preference 200

7-33
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-bgp)#neighbor 192.168.1.10
P2(config-bgp)#neighbor 172.16.0.2 route-map Local_Pref in
P2(config)#route-map Local_Pref permit 10
on P3.
Dest
NextHop
Metric
LocPrf
RtPrf
Path
*>i 10.0.0.0/24
192.168.1.6
200
200
300 i
*i 10.0.0.0/24
192.168.1.2
100
200
300 i

01:24:10 received from 192.168.1.2 (172.16.0.1)
origin i,nexthop 192.168.1.2, localpref 100,
as path [300]
01:21:46 received from 192.168.1.6 (172.16.1.1)
origin i,nexthop 192.168.1.6, localpref 200,
as path [300]
The egress of outbound services is specified by the modification of LOCAL_PREF on P2.

In this example, traffic to 10.0.0.0/24 in AS300 is preferentially forwarded by P1 because
routes passing P1 has the largest LOCAL_PREF value.
7.1.5.6 Filtering Routes by MED

MED is an optional non-transitive attribute of BGP. LOCAL_PREF affects the outbound
traffic of an AS whereas MED affects the inbound traffic. If a AS as multiple ingress
points, the ingress point with the smallest MED value is selected for the traffic from EBGP
neighbors. The default MED value for reassigned BGP routes is 0.
7-34
SJ-20100901100356-015|2011-07-30(R1.0)
Command
Function
Enters the route mapping configuration
sequence-number> ]
mode.
ZXCTN9000(config-route-map)#set metric [ + | -] < metric-value>
Configures the metric value for the

route selection protocol.

Parameter
Description
< map-tag>

characters.
permit
deny
< sequence-number>

from 0 to 65535.
Increases the metric value.
Reduces the metric value.
< metric-value>
to 4294967295.
Selecting Routes by MED

As shown in Figure 7-13, AS100 and AS400 are connected by two links. Configure P1 in
AS100 to make traffic from AS400 be transmitted along link 1 to AS100.
7-35
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-13 Network Topology for Selecting Routes by MED

P1(config-bgp)#neighbor 192.168.1.2 route-map Med1 out
P1(config-bgp)#neighbor 192.168.2.2 route-map Med2 out
P1(config-bgp)#exit
P1(config-std-acl)#exit
P1(config)#route-map Med1 permit 10
P1(config)#route-map Med2 permit 10
7-36
SJ-20100901100356-015|2011-07-30(R1.0)

The configuration of P2 (the ZXCTN9000 in AS400):

P2(config-bgp)#exit
on P2.
P2(config-bgp)#show ip bgp route
Dest
NextHop
Metric
LocPrf
RtPrf
Path
*>10.0.1.0/24
192.168.2.1
50
20
100 i
* 10.0.1.0/24
192.168.1.1
100
20
100 i
*>10.0.2.0/24
0.0.0.0
P2(config)#show ip bgp route detail 10.0.1.0 255.255.255.0

01:44:13 received from 192.168.2.1 (10.0.1.1)
as path [100]
01:47:25 received from 192.168.1.1 (10.0.1.1)
as path [100]
The above output shows that after the MED value is changed, P2 preferentially selects link
1 with the smaller MED value (50) as the link to AS100.
7.1.5.7 Configuring BGP Community

The community attribute is an optional and transitive attribute. A community is a group
of destinations that share one or multiple common attributes. The community attribute
has four bytes: the first two bytes are the AS number and the latter second bytes are
the management identifier. When routes are aggregated, the resulting aggregate has a
community attribute that contains all community attributes from all the initial routes.
A few predefined and well-known community attributes are as follows:
l
l
no-export: Do not advertise this route to EBGP neighbors.

no-advertise: Do not advertise this route to any neighbor (internal or external).
7-37
SJ-20100901100356-015|2011-07-30(R1.0)
l
l
l
no-export-subconfed: Do not advertise this route to to EBGP neighbors, including

neighbors in other members' ASs inside a BGP confederation.
local-AS: Do not advertise this route to neighbors outside the local AS.
Internet: Advertise this route to all neighbors.
Beside these well-known attributes, you can use private attributes to define special
functions.
Step
Command
Function
sequence-number> ]
2
ZXCTN9000(config)#ip prefix-list < prefix-list-name> [ seq <
Configures an IP address prefix list
seq-number> ] { permit | deny} < network-num> < len> [ ge < value>
to filter route advertisements.
| le < value> ]
3
sequence-number> ]
configuration mode.
ZXCTN9000(config-route-map)#set as-path prepend <
Modifies the AS path.
as-path-number> [ < as-path-number> ]

ZXCTN9000(config-route-map)#set local-preference < value>
Configures priority value of

LOCAL_PREF.
ZXCTN9000(config-route-map)#set metric [ + | -] < metric-value>
Configures the metric value for the

route selection protocol.
ZXCTN9000(config-route-map)#set community { none | [ additive] {
Configures the communities
no-advertise | no-export | no-export-subconfed | < aa:nn> | < nn> } [ {
attribute.
no-advertise | no-export | no-export-subconfed | < aa:nn> | < nn> } ] }

ZXCTN9000(config-route-map)#set dampening < half-life> < reuse>
Configures route dampening
< suppress> < max-suppress-time>

Parameter
Description
< map-tag>

characters.
permit
deny
< sequence-number>

from 0 to 65535.
7-38
SJ-20100901100356-015|2011-07-30(R1.0)
Parameter
Description
< prefix-list-name>
Indicates the name of the prefix list, consisting of 1 to 32 characters.
seq < seq-number>
Indicates the index value of the prefix list. The smaller value is
preferentially used. The value of this parameter ranges from 1 to
4294967294.
If an IP address to the filtered exists in the prefix range of the entry, the
permit
IP address passes the filtering and no further matching is performed.

If an IP address to the filtered does not exist in the prefix range of the
entry, further matching is performed.
If an IP address to the filtered exists in the prefix range of the entry,
deny
the IP address fails the filtering and no further matching is performed.

If an IP address to the filtered does not exist in the prefix range of the
entry, further matching is performed.
< network-num>
Indicates the range of the prefix range.
< len>
Indicates the mask length of the IP address. The value ranges from
ge < value>
0 to 32.
Indicates the value that the length of the prefix matching the prefix
range should be larger than. The value ranges from 0 to 32.
le < value>
Indicates the value that the length of the prefix matching the prefix
range should be smaller than. The value ranges from 0 to 32.
Tagging Routes with the Community Attribute

In the network as shown in Figure 7-14, set different attributes for routes from ASs on the
ZXCTN9000s in AS300 and AS400. Routes from AS300 are tagged as 300:1 and routes
from AS400 are tagged as 400:1.
7-39
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-14 Network Topology for Controlling Large Numbers of Routes by Community
The configuration of the ZXCTN9000 in AS300 (port and IGP configurations):

ZXCTN9000_AS300(config-bgp)#neighbor 192.168.1.18 route-map community out
ZXCTN9000_AS300(config-bgp)#neighbor 192.168.1.18 send-community
ZXCTN9000_AS300(config)#ip prefix-list AS200 seq 5 permit 10.0.3.0 24
ZXCTN9000_AS300(config)#route-map Community permit 10
ZXCTN9000_AS300(config-route-map)#match ip address prefix-list AS200
ZXCTN9000_AS300(config-route-map)#set community 300:1
ZXCTN9000_AS300(config-route-map)#exit
7-40
SJ-20100901100356-015|2011-07-30(R1.0)

ZXCTN9000_AS400(config-bgp)#neighbor 192.168.1.14 route-map community out
ZXCTN9000_AS400(config-bgp)#neighbor 192.168.1.14 send-community
ZXCTN9000_AS400(config)#ipv4-access-list 1
ZXCTN9000_AS400(config-ipv4-acl)#rule 1 permit any
ZXCTN9000_AS400(config-ipv4-acl)#exit
ZXCTN9000_AS400(config)#route-map Community permit 10
ZXCTN9000_AS400(config-route-map)#match ip address 1
ZXCTN9000_AS400(config-route-map)#set community 400:1
ZXCTN9000_AS600(config)#show ip bgp route
Dest
NextHop
Metric LocPrf
RtPrf
Path
*>10.0.1.0/24
192.168.1.13
20
400
100 i
*>10.0.2.0/24
192.168.1.13
20
400
*>10.0.3.0/24
192.168.1.17
20
300
200 i
* 10.0.3.0/24
192.168.1.13
20
400
100 200 i
*>10.0.4.0/24
192.168.1.13
20
400
100 200 300 i
ZXCTN9000_AS600(config)#show ip bgp route detail 10.0.3.0 255.255.255.0

00:28:52 received from 192.168.1.17 (10.0.4.1)
community 300:1
as path [300 200]
00:28:54 received from 192.168.1.13 (10.0.2.1)
community 400:1
as path [400 100 200]
The above output shows that routes are tagged based on their sources. Routes from
AS300 are tagged as 300:1 and routes from AS400 are tagged as 400:1.
7-41
SJ-20100901100356-015|2011-07-30(R1.0)
Filtering Large Numbers of Routes by Community

Select routes by configure LOCAL_PREF on the ZXCTN9000 in AS600 based on the
community attribute.
ZXCTN9000_AS600(config-bgp)#neighbor 192.168.1.13 route-map Local_Pref in
ZXCTN9000_AS600(config)#route-map Local_Pref permit 10
ZXCTN9000_AS600(config-route-map)#match community-list 1
ZXCTN9000_AS600(config-route-map)#set local-preference 200
ZXCTN9000_AS600(config)#ip community-list 1 permit 400:1
ZXCTN9000_AS600(config)#show ip bgp route
Dest
NextHop
Metric
LocPrf
RtPrf
Path
*>10.0.1.0/24
192.168.1.13
200
20
*>10.0.2.0/24
192.168.1.13
200
20
400 i
*>10.0.3.0/24
192.168.1.13
200
20
400 100 200 i
* 10.0.3.0/24
192.168.1.17
20
300 200 i
*>10.0.4.0/24
192.168.1.13
20
400 100 200 300 i
200
400 100 i
The above output shows that the route with the largest LOCAL_PREF value is
preferentially selected. In this example, the route from AS400 to 10.0.3.0/24 is selected.
7.1.6 BGP Configuration in Large-Scale Networks

7.1.6.1 Configuring BGP Route Reflector
Not all IBGP routers are in full connection in an AS. Each ZXCTN9000 has more than 100
BGP sessions.
For an AS with a large network scale, an IBGP router can work as the route reflector (RR)
and other IBGP routes as clients. The clients connect to the RR and the RRs connect
to each other. In this way, all clients reflect routes through the RR and the number of
neighbors is reduced to n-1. Clients are the IBGP neighbors establishing full connections
with the RR. The clients and RR constitutes a group. Other IBGP neighbors of the RR are
not clients.
7-42
SJ-20100901100356-015|2011-07-30(R1.0)
After receiving a route, the RR reflects the route by peer type:

l
l
l
If an update packet is from an EBGP neighbor, the RR reflects the packet to all IBGP
neighbors, including client and non-client neighbors.
If an update packet is from a non-client neighbor, the RR reflects the packet to only
clients.
If an update packet is from the Route Reflector Cluster (RRC), the RR reflects the
route to all IBGP neighbors, including client and non-client neighbors. But the RR
does not reflect the packet to its sender.
When an AS has multiple RRs, certain RRs can be classifies as a cluster. An AS can have
multiple clusters, each of which should contain at least one RR.
Note that the RR is recommended when each ZXCTN9000 has more than 100 BGP
sessions.
Step
Command
Function

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#bgp cluster-id { < value> | < ip-address> }
Configures the cluster ID. By default,

the router-ID is adopted as the
cluster ID.
Configures the neighbor or neighbor
peer-group-name> ] router-refletor-client
group as the RR client.

Parameter
Description
< value>
Indicates the cluster ID. The value of this parameter ranges from 1
to 4294967295.
< ip-address>
Indicates the cluster ID, in dotted decimal notation.

Parameter
Description
< ipv4-address>
Indicates the IP address of the neighbor, in dotted decimal notation.
< peer-group-name>
Configuring the Route Reflector

In the network as shown in Figure 7-15, P1, P2, and P3 are IBGP neighbors but are not
with full connections. Configure the RR so that P3 can receive the route from one IBGP
neighbor and forwards the route to another neighbor. The configuration of RR avoids full
connections in AS600.
7-43
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-15 Network Topology for Configuring the Route Reflector

P1(config-bgp)#exit

P2(config-bgp)#exit

P3(config-bgp)#bgp cluster-id 3.3.3.3
7-44
SJ-20100901100356-015|2011-07-30(R1.0)

P3(config-bgp)#neighbor 192.168.1.2 route-reflector-client
P3(config-bgp)#neighbor 192.168.1.6 route-reflector-client
P3(config-bgp)#exit
Run the show ip bgp route command to view the BGP routing table on P1.
P1(config)#show ip bgp route
Dest
*>
NextHop
10.0.0.0/24
*>i 10.0.1.0/24
Metric
LocPrf
10.0.0.1
192.168.1.2
100
RtPrf
Path
20
300 i
200
400 i

05:04:45 received from 192.168.1.5 (192.168.1.1)
origin i,nexthop 192.168.1.2,localpref 100, originator_id 172.16.0.1
cluster_list 3.3.3.3
as path [400]
Dest
*>i 10.0.0.0/24
*>
10.0.1.0/24
NextHop
Metric
192.168.1.6
LocPrf
100
10.0.1.1
RtPrf
Path
200
300 i
20
400 i

05:05:19 received from 192.168.1.1 (192.168.1.1)
origin i,nexthop 192.168.1.6,localpref 100, originator_id 10.0.0.1
cluster_list 3.3.3.3
as path [300]
The above output shows that P1 and P2 have learned the route to each other.
7.1.6.2 Configuring BGP Confederation

In a large-scale network, the network is correctly connected and IGP runs properly.
Providing the same function as a router reflector, a confederation reduces connections
among IBGP neighbors. The confederation classifies an AS into multiple sub-ASs, each
7-45
SJ-20100901100356-015|2011-07-30(R1.0)
possessing several IBGP neighbors. The sub-ASs are EBGP neighbors. Sub-ASs are not
available to routers outside the AS.
Step
Command
Function

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#bgp confederation identifier < value>
Configures the confederation ID.

from 1 to 65535.
ZXCTN9000(config-bgp)#bgp confederation peers < value> [ <
Configures the AS ID of the
value> ]
confederation peer. The value of this

Configuring a Confederation to Avoid IBGP Full Connection

As shown in Figure 7-16, configure a confederation in AS600 to avoid IBGP full connection.
Figure 7-16 Network topology for Configuring the BGP Confederation

P2(config-bgp)#bgp confederation identifier 600
P2(config-bgp)#bgp confederation peers 65001 65002
7-46
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config-bgp)#exit

P4(config-bgp)#bgp confederation identifier 600
P4(config-bgp)#bgp confederation peers 65003
P4(config-bgp)#exit
Dest
NextHop
*>i 10.0.0.0/24
172.16.1.2
*>
172.16.2.2
10.1.0.0/24
Metric
LocPrf
100
RtPrf
Path
200
65002 i
20
500 i
The above output shows that routes to P4 exits on P2.

Dest
NextHop
*>10.0.0.0/24
0.0.0.0
*>10.1.0.0/24
172.16.2.2
Metric
LocPrf
RtPrf
0
100
Path
i
200
65003 500 i

06:27:14 received from 172.16.1.1 (172.16.1.1)
origin i,nexthop 172.16.2.2,localpref 100,
as path (65003) [500]
The above output shows that routes to AS500 exits on P4.

In a confederation, an AS is classified into multiple sub-ASs, which are EBGP neighbors.
Each sub-AS works as an independent AS and runs IBGP.
The entire AS runs only one IGP. Every sub-AS contains IGP routing information of all
other sub-ASs.
7-47
SJ-20100901100356-015|2011-07-30(R1.0)
7.1.6.3 Configuring BGP Route Dampening

BGP provides route dampening to minimize the propagation of flapping routes across
an network. When routes are changed, update and withdraw packets are continuously
transmitted on the network, occupying abandon bandwidths and router resources. This
sere affects network performance and should be avoided.
The principle of route dampening: A penalty of 1000 is assigned upon each route flap.
When the penalty exceeds a configurable suppress limit, the router stops advertising the
route. Thus, the route is dampened. Once the route has been assigned a penalty, the
penalty is decreased by half after the half-life period. As the penalty for a flapping route
decreases and falls below the reuse limit, the route is unsuppressed.
The following terms are used when describing route dampening:
l
l
l
l
half-life-time: ranges from 1 to 45 minutes. The default value is 15.

reuse-value: ranges from 1 to 20000. The default value is 750.
suppress-value: ranges from 1 to 20000. The default value is 2000.
max-suppress-time: ranges from 1 to 255 minutes. The default value is four times the
half-life-time.
Step
Command
Function

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#bgp dampening [ < half-life> < reuse> <
Enables BGP route dampening and
suppress> < max-suppress-time> | route-map < map-tag> ]
modifies factors.

Parameter
Description
< half-life>
Changes the half life time. The value of this parameter ranges from 1
to 45 minutes. The default value is 15.
< reuse>
Changes the reuse value. The value of this parameter ranges from 1
< suppress>
Changes the suppress limit. The value of this parameter ranges from
< max-suppress-time>
Changes the maximum suppress limit. This value is the maximum

amount of time a route can be suppressed. The value of this
parameter ranges from 1 to 255 minutes. The default value is 60.
< map-tag>
Configures the route mapping identifier, consisting of 1 to 31

characters. Only the route flapping value specified in the route
mapping can be applied to route flaps.
7-48
SJ-20100901100356-015|2011-07-30(R1.0)
Enabling BGP Route Dampening on the ZXCTN9000

Enable BGP route dampening on the ZXCTN9000. Set half life time to 30 minutes, reuse
value to 500, suppress value to 2000, and max suppress time to 120 minutes.
ZXCTN9000(config)#router bgp 100
ZXCTN9000(config-bgp)#bgp dampening 30 500 2000 120
ZXCTN9000(config-bgp)#network 203.250.15.0 255.255.255.0
ZXCTN9000(config-bgp)#neighbor 192.208.10.5 remote-as 300
ZXCTN9000(config-bgp)#exit
Run the show ip bgp protocol command on the ZXCTN9000 to view the configurations of
route dampening.
ZXCTN9000#show ip bgp protocol
BGP router ID is 1.1.1.2, Local as is 1
Hold time is 90 seconds, KeepAlive time is 30 seconds
Default local preference is 100
Default export metric is 0
IGP synchronization is disabled
Default information advertise is disabled
Always compare med is disabled
Fast fallover is enabled
Client-to-client reflection is enabled
Ipv4 unicast is activated
Router target is filtered
Route dampening enabled, halflife-time is 30,
reuse is 500, suppress is 2000, max-suppress-time is 120
Distance : external 20 internal 200
The above output shows that route dampening is enabled. The half life time is 30 minutes,
reuse value is 500, suppress value is 2000, and max suppress time is 120 minutes.
7.1.6.4 Configuring BGP Peer Group

BGP peer group mainly manages BGP peers by groups. After BGP peers are added into
a BGP peer group, the peers can be configured and operated in a unified way to reduce
workload and simplify configuration procedure. In addition, peers can be managed by
groups, improving reliability and convenience of maintenance.
Step
Command
Function

ZXCTN9000 resides.
ZXCTN9000(config-bgp)#neighbor < word> peer-group
Creates a BGP peer group. The

name of the peer group consists of 1
to 64 characters.
7-49
SJ-20100901100356-015|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-bgp)#neighbor < word> remote-as < number>
Configures the AS number of a

neighbor peer group.
ZXCTN9000(config-bgp)#neighbor < ip-address> peer-group <
Adds the neighbor to the BGP peer
word>
group.

Parameter
Description
< word>
Indicates the name of the peer group, consisting of 1 to 64 characters.

Parameter
Description
< word>
< number>
Indicates the number of the AS where the neighbor resides. The value
of this parameter ranges from 1 to 65535, or 1 to 4294967295.

Parameter
Description
< ip-address>
< word>
Example
Create a BGP peer group. The name of the peer group is zte. In AS100, add neighbors
192.168.0.2 and 192.168.0.3 to the BGP peer group.
ZXCTN9000(config)#router bgp 100
ZXCTN9000(config-bgp)#neighbor zte peer-group
ZXCTN9000(config-bgp)#neighbor zte remote-as 100
ZXCTN9000(config-bgp)#neighbor 192.168.0.2 peer-group zte
ZXCTN9000(config-bgp)#neighbor 192.168.0.3 peer-group zte
7.2 BGP Maintenance and Diagnosis

7.2.1 BGP show Command
When a BGP route fails, you can use the debug commands to locate and rectify the fault.
The show command is most commonly used. Using this command, you can view the
current BGP neighboring status and BGP routes learned by the ZXCTN9000.
Use these commands to maintain BGP on the ZXCTN 9000.
7-50
SJ-20100901100356-015|2011-07-30(R1.0)
Command
Function
Shows the configuration of the local

BGP module.
ZXCTN9000#.show ip bgp neighbor
Shows the adjacency relationship and

the current neighboring status.
ZXCTN9000#show ip bgp route [ network < ip-address> [ mask < net-mask>
Shows the entries in the BGP routing
]]
table.
ZXCTN9000#show ip bgp summary
Shows all BGP neighboring status.
The execution result of the show ip bgp protocol command is shown below:
BGP router ID is 1.1.1.2, Local as is 1
Hold time is 90 seconds, KeepAlive time is 30 seconds
IGP synchronization is disabled
Default information advertise is disabled
Always compare med is disabled
Fast fallover is enabled
Client-to-client reflection is enabled
Ipv4 unicast is activated
Router target is filtered
Route dampening is disabled

Output Item
Description
Hold time is 90 seconds, KeepAlive time is
The hold time is 90 seconds and the keep-alive time is 30 seconds.
30 seconds
The default local priority is 100.
The default export metric value is 0.
The external distance is 20 and the internal distance is 200.
The execution result of the show ip bgp neighbor command is shown below:
ZXCTN9000#show ip bgp neighbor
Neighbor capabilities:
Route refresh: advertised and received
7-51
SJ-20100901100356-015|2011-07-30(R1.0)

Address family IPv4 Unicast: advertised and received
All received 10 messages
0 updates, 0 errs
1 opens, 0 errs
9 keepalives
0 vpnv4 refreshs, 0 ipv4 refreshs, 0 ipv4 multicast refreshs, 0 ipv6 refreshs,
0 errs
0 notifications, 0 other errs

After last established received 8 messages
0 updates, 0 errs
0 opens, 0 errs
8 keepalives
0 errs

All sent 10 messages
0 updates, 1 opens, 9 keepalives
0 notifications
After last established sent 8 messages
0 notifications
For address family: IPv4 Unicast

All received nlri 0, unnlri 0, 0 accepted prefixes
All sent nlri 0, unnlri 0, 0 advertised prefixes
maximum limit 4294967295
Minimum time between advertisement runs is 30 seconds
Minimum time between origin runs is 15 seconds

Output Item
Description
BGP neighbor is 129.213.1.2, remote AS
The IP address is the peer IP address for the TCP connection between
65001, external link
BGP peers. The peer end is in AS65001 and it is an EBGP connection.
BGP version 4, remote router ID
BGP-4 is used. The IF of the remote ZXCTN9000 is 129.213.1.2.
129.213.1.2
The status of the neighbor is Established, and the session is

established for 4 minutes and 21 seconds.
hold time is 90 seconds, keepalive interval
The hold time is 90 seconds and the keep-alive time is 30 seconds.
is 30 seconds
7-52
SJ-20100901100356-015|2011-07-30(R1.0)
Output Item
Description
Neighbor capabilities:
The following are the descriptions of the peer end.
Route refresh: advertised and received
The peer end supports route refresh.
Address family IPv4 Unicast: advertised
The peer end supports unicast NLRI.
and received
All received 10 messages
A total of 10 packets are received, including 1 open packet and 9
0 updates, 0 errs
keep-alive packets. The packets of VPNV4 route update and IPV4
1 opens, 0 errs
route update are not received. The notification and error packets are
9 keepalives
not received.
0 vpnv4 refreshs, 0 ipv4 refreshs, 0 ipv4

multicast refreshs, 0 ipv6 refreshs, 0 errs
After last established received 8 messages
From the last time point that the neighboring connection is in
0 updates, 0 errs
established status till present, a total of 8 packets are received. All
0 opens, 0 errs
of them are keep-alive packets.
8 keepalives
multicast refreshs, 0 ipv6 refreshs, 0 errs
All sent 10 messages
A total of 10 packets are transmitted, including 0 update packets, 1
open packet, and 9 keep-alive packets.

multicast refreshs, 0 ipv6 refreshs, 0
notifications
After last established sent 8 messages 0
From the last time point that the neighboring connection is in
updates, 0 opens, 8 keepalives 0 vpnv4
established status till present, a total of 8 packets are transmitted,
refreshs, 0 ipv4 refreshs, 0 ipv4 multicast
including 0 update packets, 0 open packet, and 8 keep-alive packets.
refreshs, 0 ipv6 refreshs, 0 notifications

For address family: IPv4 Unicast
The The following are the descriptions of IPv4 unicast routes.
All received nlri 0, unnlri 0, 0 accepted
No NLRI packets, withdraw packets, or unicast prefixes are received.
prefixes
All sent nlri 0, unnlri 0, 0 advertised prefixes
No NLRI or withdraw packets are advertised. 1 unicast prefix is

advertised.
Minimum time between advertisement runs
The minimum update interval is 30 seconds.
is 30 seconds
1 BGP connection with the peer end has been established.

Indicates the local IP socket, including the local IP address and TCP
port number.
Foreign host: 129.213.1.2, Foreign port:
Indicates the IP socket of the peer end, including the peer IP address
1024
and TCP port number.

7-53
SJ-20100901100356-015|2011-07-30(R1.0)
The execution result of the show ip bgp route command is shown below:
ZXCTN9000#show ip bgp route
Dest
NextHop
Metric
*> 10.0.1.0/24
192.168.2.1
50
20
100 i
192.168.1.1
100
20
100 i
10.0.1.0/24
*> 10.0.2.0/24
LocPrf
RtPrf
0.0.0.0
Path
ZXCTN9000(config)#show ip bgp route detail 10.0.1.0 255.255.255.0

01:44:13 received from 192.168.2.1 (10.0.1.1)
as path [100]
01:47:25 received from 192.168.1.1 (10.0.1.1)
as path [100]
In the output of the show ip bgp route command, the asterisk (*) indicates a valid route, the
angle bracket (>) indicates the optimal route, i indicates an IBGP route, and the route not
marked by i is an EBGP route or a locally generated route.
The above example shows that the local ZXCTN9000 has to legal routes to 10.0.1.0/24.
The next-hop addresses of the routes are 192.168.2.1 and 192.168.1.1. The route whose
next-hop address is 192.168.2.1 is the optimal route because its metric value is 50, which
is smaller than that of the other route.
Output Item
Description
Dest
Next-hop
Indicates the next-hop address of the route. An all-0 next-hop address

is generated by the local ZXCTN9000.
Metric
Indicates the metric value.
LocPrf
Indicates the local priority of the route learned by BGP.
RtPrf
Indicates the priority of a route.
Path
Indicates the source of a route, including IGP, EGP, and incomplete.
The execution result of the show ip bgp summary command is shown below:
ZXCTN9000#show ip bgp summary
Neighbor Ver
As
1.1.1.1
MsgRcvd MsgSend Up/Down(s) State/PfxRcd

14
1.1.1.3
13
00:06:06
00:02:33
7-54
SJ-20100901100356-015|2011-07-30(R1.0)

Output Item
Description
Neighbor
Indicates the BGP neighbor.
Ver
Indicates the version number of the BGP.
As
Indicates the number of the AS where the neighbor resides.
MsgRcvd
Indicates the number of packets received by BGP.
MsgSend
Indicates the number of packets transmitted by BGP.
Up/Down(s)
Indicates the establishment time of a connection.
State/PfxRcd
If the neighboring connection is successfully established, a number

is displayed to indicate the number of received routes. If not, a letter
is displayed to indicate the state.
7.2.2 BGP debug Command

Besides the show command, you can use the debug to monitor the process of BGP
neighbor establishment and route update.
Use these commands to maintain BGP on the ZXCTN 9000.
Command
Function
ZXCTN9000#debug ip bgp in
Traces and shows notification packets

received by BGP, and shows error code
and error ID.
Traces and shows notification packets
ZXCTN9000#debug ip bgp out
transmitted by BGP, and shows error

code and error ID.
ZXCTN9000#debug ip bgp dampening
Shows BGP dampening status.
ZXCTN9000#debug ip bgp keepalieves
Shows the processing of BGP

keep-alive packets.
Shows the processing of BGP update
ZXCTN9000#debug ip bgp updates
packets. The processing of update

packets a specified peer can be traced
and displayed.
Traces and shows the state machine
ZXCTN9000#debug ip bgp events
status of BGP connections.

Traces and shows information of all
ZXCTN9000#debug ip bgp all
BGP debug commands.

Shows the configuration of the debug
ZXCTN9000#show debug bgp
command.
7-55
SJ-20100901100356-015|2011-07-30(R1.0)
The following example uses the debug ip bgp events command to trace the state machine
status of BGP connections.
ZXCTN9000#terminal monitor
ZXCTN9000#debug ip bgp events
BGP events debugging is on
0/20/CPU0 2010-6-5 10:10:07: ROUTE_bgp: 192.168.1.2 reset due to Erroneous BGP
Open received
0/20/CPU0 2010-6-5 10:10:07: ROUTE_bgp: 192.168.1.2 went from Connect to
Idle
0/20/CPU0 2010-6-5 10:10:08: ROUTE_bgp: 192.168.1.2 went from Idle to
Connect
0/20/CPU0 2010-6-5 10:10:13: ROUTE_bgp: 192.168.1.2 went from Connect to
OpenSent
0/20/CPU0 2010-6-5 10:10:13: ROUTE_bgp: 192.168.1.2 went from OpenSent to
OpenConfirm
0/20/CPU0 2010-6-5 10:10:13: ROUTE_bgp: 192.168.1.2 went from OpenConfirm to
Established
The above output shows that the status of the BGP state machine changes in the following
order:
ConnectIdleConnectOpenSentOpenConfirmEstablished
7.2.3 BGP Alarm Information

For important faults, the system displays alarms. Common BGP alarms are described in
the below table:
Alarm Code
Description
INFORM_BGP_ACTIVE_GET_TCB
Obtaining TCB fails when BGP active get is enabled.
INFORM_BGP_IF_CHANGE
The neighbor is disconnected because the BGP interface is down.
INFORM_BGP_HOLD_EXPIRED
The neighbor hold timer expires.
A complete alarm contains the alarm type, alarm code, and alarm description. The alarm
code indicates the attribute and type of an alarm. The back-end system identifies an alarm
based on its alarm code. An alarm can carry a description, such as the caused of the alarm.
For detailed descriptions of BGP alarms, refer to corresponding manual.
7-56
SJ-20100901100356-015|2011-07-30(R1.0)
7.3 BGP Configuration Instances

7.3.1 Example 1: Configuring BGP FRR
Fast Reroute (FRR) provides backup for failed links and nodes, minimizes the impact on
traffic, and restores traffic in a short time.
Typical FRR networking:
1. Figure 7-17 shows the typical networking of node protection.
Figure 7-17 Typical Networking of Node Protection
2. Figure 7-18 shows the typical networking of link protection. IS-IS neighboring topology
is established between two links, providing primary and secondary links.
Figure 7-18 Typical Networking of Link Protection
1. Configure routing protocols.
2. For a destination, configure two or more next hops on FRR nodes and different costs
for routes.
3. Enable FRR on the router running the routing protocol.
The detailed configurations are:
1. FRR for node protection
For the networking as shown in Figure 7-17, all ZXCTN9000s establish EBGP
neighboring relationship through actual interfaces. Enable FRR on P1. Configure the
7-57
SJ-20100901100356-015|2011-07-30(R1.0)
local preference to select P1P2P3 as the optimal path for routes advertised by
P3.
P1(config-router)#neighbor 172.16.1.2
remote-as 2
remote-as 3
P1(config-router)#bgp frr
P1(config)#route-map lt
route-map lt in


2. Link protection
For the networking as shown in Figure 7-18, perform the configuration according to
Configuration Example of IS-IS FRR.
Run the show ip backup route command to view the configuration results and check
whether FRR is enabled.
FRR status on P1:
P1#show ip backup route
IPv4 Backup Routing Table:
Dest
Gw
1.1.1.150/32
172.16.20.2
Interface
gei_2/2
Owner
Pri
BGP
20
Metric
0
7-58
SJ-20100901100356-015|2011-07-30(R1.0)
7.3.2 Example 2: Comprehensive BGP Configuration

As shown in Figure 7-19, P1 and P2 are in AS1, P4 is in AS2, and P3 and P5 are in AS3.
The loopback addresses of the ZXCTN9000is are described in the table below.
ZXCTN9000
Loopback Address
P1
1.1.1.2/32
P2
1.1.1.3/32
P3
1.1.1.4/32
P4
1.1.1.1/32
P5
1.1.1.5/32
Figure 7-19 Network Topology for Comprehensive BGP Configuration
1. P1 and P2 are IBGP neighbors. P1 and P4 are EBGP neighbors. P2 and P3 are
EBGP neighbors.
2. P3 is connected to P5 through static routes and OSPF.
3. P3 imports OSPF routes to BGP and set the metric value of the imported routes to
122.
4. P4 has static routes to 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24,
192.168.3.0/24, 192.168.100.0/24, and 10.1.1.0/24.
5. P4 advertises its static routes to BGP and changes the metric value to 22. P3 filters
out the route to 192.168.100.0/24.
6. Implement route aggregation on P3 and advertise detailed routes.
7. Make sure that the PC in AS2 can connect to P5 in 20.1.1.0/24.
7-59
SJ-20100901100356-015|2011-07-30(R1.0)
8. All ZXCTN9000s uses loopback1 interfaces as the source address for connection. The
mask length of the interconnected address is 30 bits.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Configure static routes.

Configure IGP (OSPF).
Enable BGP.
Configure neighbors.
Modify source addresses.
Configure route aggregation.
Configure multi-hop.
Disable synchronization.
Configure the route map to filter specified routes.
Change the metric value of the route to be advertised.
P1(config-router)#neighbor 1.1.1.1 activate
P1(config)#ip route 1.1.1.1 255.255.255.255 11.1.1.1
P1(config)#ip route 1.1.1.3 255.255.255.255 13.1.1.2

7-60
SJ-20100901100356-015|2011-07-30(R1.0)

P2(config)#ip route 1.1.1.4 255.255.255.255 12.1.1.1
P2(config)#ip route 1.1.1.2 255.255.255.255 13.1.1.1

P3(config-router)#redistribute ospf-int metric 122
P3(config-router)#neighbor 1.1.1.3 send-med
P3(config)#ip route 1.1.1.3 255.255.255.255 12.1.1.2
7-61
SJ-20100901100356-015|2011-07-30(R1.0)

P3(config-router)#network 14.1.1.0 0.0.0.3 area 0.0.0.0

P4(config-if-vlan1)#negotiation auto
P4(config-router)#redistribute static
as-set
P4(config-router)#neighbor 1.1.1.2 route-map test-static out
P4(config-router)#neighbor 1.1.1.2 send-med
P4(config)#ip route 1.1.1.2 255.255.255.255 11.1.1.2
P4(config)#ip route 192.168.100.0 255.255.255.0 10.1.1.2
P4(config)#ip route 192.168.1.0 255.255.255.0 10.1.1.2
P4(config)#ip route 192.168.0.0 255.255.255.0 10.1.1.2
P4(config)#ip route 192.168.3.0 255.255.255.0 10.1.1.2
P4(config)#ip route 192.168.2.0 255.255.255.0 10.1.1.2
P4(config)#ipv4-access-list 1
P4(config-ipv4-acl)#exit
P4(config)#route-map test-static permit 10
7-62
SJ-20100901100356-015|2011-07-30(R1.0)

P5(config)#ip route 0.0.0.0 0.0.0.0 14.1.1.1
View the BGP routing table and route forwarding table on P1.
P1# show ip bgp
Dest
NextHop
*>
1.1.1.2/32
1.1.1.2
*>
10.1.1.0/24
1.1.1.1
*>
11.1.1.0/30
11.1.1.2
Metric
LocPrf
33
RtPrf
Path
20
2 i
200
100
200
*>i
12.1.1.0/30
1.1.1.3
*>
13.1.1.0/30
13.1.1.1
*i
13.1.1.0/30
1.1.1.3
*>i
14.1.1.0/30
1.1.1.3
100
200
3 ?
100
*>i
20.1.1.0/24
100
1.1.1.3
122
200
3 ?
*>
192.168.0.0/22
1.1.1.1
33
20
2 i
*>
192.168.0.0/24
1.1.1.1
33
20
2 ?
*>
192.168.1.0/24
1.1.1.1
33
20
2 ?
*>
192.168.2.0/24
1.1.1.1
33
20
2 ?
*>
192.168.3.0/24
1.1.1.1
33
20
2 ?
P1#show ip route
IPv4 Routing Table:
Dest
Mask
Gw
Interface
Owner
pri
metric
1.1.1.1
255.255.255.255
11.1.1.1
gei_1/1
static
1.1.1.2
255.255.255.255
1.1.1.2
loopback1
address
1.1.1.3
255.255.255.255
13.1.1.2
gei_2/1
static
7-63
SJ-20100901100356-015|2011-07-30(R1.0)

10.1.1.0
255.255.255.0
11.1.1.1
gei_1/1
bgp
20
33
11.1.1.0
255.255.255.252
11.1.1.2
gei_1/1
direct
11.1.1.2
255.255.255.255
11.1.1.2
gei_1/1
address
12.1.1.0
255.255.255.252
13.1.1.2
gei_2/1
bgp
200
13.1.1.0
255.255.255.252
13.1.1.1
gei_2/1
direct
13.1.1.1
255.255.255.255
13.1.1.1
gei_2/1
address
14.1.1.0
255.255.255.252
13.1.1.2
gei_2/1
bgp
200
20.1.1.0
255.255.255.0
13.1.1.2
gei_2/1
bgp
200
122
192.168.0.0
255.255.252.0
11.1.1.1
gei_1/1
bgp
20
33
192.168.0.0
255.255.255.0
11.1.1.1
gei_1/1
bgp
20
33
192.168.1.0
255.255.255.0
11.1.1.1
gei_1/1
bgp
20
33
192.168.2.0
255.255.255.0
11.1.1.1
gei_1/1
bgp
20
33
192.168.3.0
255.255.255.0
11.1.1.1
gei_1/1
bgp
20
33
P2#show ip bgp
Dest
NextHop
1.1.1.3/32
1.1.1.3
*>i
10.1.1.0/24
1.1.1.2
*>i
11.1.1.0/30
1.1.1.2
*>
12.1.1.0/30
12.1.1.2
12.1.1.0/30
1.1.1.4
*>
13.1.1.0/30
13.1.1.2
*i
13.1.1.0/30
1.1.1.2
200
*>
14.1.1.0/30
1.1.1.4
20
3 ?
*>
20.1.1.0/24
1.1.1.4
122
20
3 ?
*>i 192.168.0.0/22
1.1.1.2
33
100
200
2 i
*>i 192.168.0.0/24
1.1.1.2
33
100
200
2 ?
*>i 192.168.1.0/24
1.1.1.2
33
100
200
2 ?
*>i 192.168.2.0/24
1.1.1.2
33
100
200
2 ?
*>i 192.168.3.0/24
1.1.1.2
33
100
200
2 ?
*>
Metric
33
LocPrf
RtPrf
Path
100
200
2 i
100
200
20
3 ?
100
P2#show ip route
IPv4 Routing Table:
Dest
Mask
Gw
Interface
Owner
1.1.1.2
255.255.255.255
13.1.1.1
gei_1/1
static
1.1.1.3
255.255.255.255
1.1.1.3
loopback1 address
1.1.1.4
255.255.255.255
12.1.1.1
gei_2/1
static
pri
metric
10.1.1.0
255.255.255.0
13.1.1.1
gei_1/1
bgp
200
33
11.1.1.0
255.255.255.252
13.1.1.1
gei_1/1
bgp
200
12.1.1.0
255.255.255.252
12.1.1.2
gei_2/1
direct
12.1.1.2
255.255.255.255
12.1.1.2
gei_2/1
address
7-64
SJ-20100901100356-015|2011-07-30(R1.0)

13.1.1.0
255.255.255.252
13.1.1.2
gei_1/1
direct
13.1.1.2
255.255.255.255
13.1.1.2
gei_1/1
address
14.1.1.0
255.255.255.252
12.1.1.1
gei_2/1
bgp
20
20.1.1.0
255.255.255.0
12.1.1.1
gei_2/1
bgp
20
192.168.0.0
255.255.252.0
13.1.1.1
gei_1/1
bgp
200
33
122
192.168.0.0
255.255.255.0
13.1.1.1
gei_1/1
bgp
200
33
192.168.1.0
255.255.255.0
13.1.1.1
gei_1/1
bgp
200
33
192.168.2.0
255.255.255.0
13.1.1.1
gei_1/1
bgp
200
33
192.168.3.0
255.255.255.0
13.1.1.1
gei_1/1
bgp
200
33
View the BGP routing table, OSPF routing table, and route forwarding table on P3.
P3#show ip bgp
Dest
*>
NextHop
Metric
LocPrf
RtPrf
Path
1.1.1.4/32
1.1.1.4
*> 10.1.1.0/24
1.1.1.3
20
1 2 i
*> 11.1.1.0/30
1.1.1.3
20
1 ?
*> 12.1.1.0/30
12.1.1.1
12.1.1.0/30
1.1.1.3
20
1 ?
*> 13.1.1.0/30
1.1.1.3
20
1 ?
*> 14.1.1.0/30
14.1.1.1
*> 20.1.1.0/24
14.1.1.2
0
122
110
*>192.168.0.0/22
1.1.1.3
20
1 2 ?
*>192.168.0.0/24
1.1.1.3
20
1 2 ?
*>192.168.1.0/24
1.1.1.3
20
1 2 ?
*>192.168.2.0/24
1.1.1.3
20
1 2 ?
*>192.168.3.0/24
1.1.1.3
20
1 2 ?
P3#show ip route
IPv4 Routing Table:
Dest
Mask
Gw
Interface
1.1.1.3
255.255.255.255
12.1.1.2
gei_1/1
1.1.1.4
255.255.255.255
1.1.1.4
Owner
static
loopback1 address
pri
metric
10.1.1.0
255.255.255.0
12.1.1.2
gei_1/1
bgp
20
11.1.1.0
255.255.255.252
12.1.1.2
gei_1/1
bgp
20
12.1.1.0
255.255.255.252
12.1.1.1
gei_1/1
direct
12.1.1.1
255.255.255.255
12.1.1.1
gei_1/1
address
13.1.1.0
255.255.255.252
12.1.1.2
gei_1/1
bgp
20
14.1.1.0
255.255.255.252
14.1.1.1
gei_2/1
direct
14.1.1.1
255.255.255.255
14.1.1.1
gei_2/1
address
20.1.1.0
255.255.255.0
14.1.1.2
gei_2/1
ospf
110
192.168.0.0
255.255.252.0
12.1.1.2
gei_1/1
bgp
20
192.168.0.0
255.255.255.0
12.1.1.2
gei_1/1
bgp
20
192.168.1.0
255.255.255.0
12.1.1.2
gei_1/1
bgp
20
7-65
SJ-20100901100356-015|2011-07-30(R1.0)

192.168.2.0
255.255.255.0
12.1.1.2
gei_1/1
bgp
20
192.168.3.0
255.255.255.0
12.1.1.2
gei_1/1
bgp
20
P3#show ip routeospf
IPv4 Routing Table:
Dest
20.1.1.0
Mask
Gw
255.255.255.0
Interface
14.1.1.2
vlan2
Owner
pri
ospf
110
metric
2
P4#show ip bgp
Dest
NextHop
*>
1.1.1.1/32
*>
Metric
LocPrf
1.1.1.1
RtPrf
Path
1.1.1.2/32
11.1.1.2
*> 10.1.1.0/24
10.1.1.1
*> 11.1.1.0/30
11.1.1.1
11.1.1.0/30
1.1.1.2
20
*> 12.1.1.0/30
1.1.1.2
20
*> 13.1.1.0/30
1.1.1.2
20
*> 14.1.1.0/30
1.1.1.2
20
1 3 ?
1 3 ?
?
i
?
*> 20.1.1.0/24
1.1.1.2
20
*>192.168.0.0/22
0.0.0.0
254
*>192.168.0.0/24
10.1.1.2
*>192.168.1.0/24
10.1.1.2
*>192.168.2.0/24
10.1.1.2
*>192.168.3.0/24
10.1.1.2
*>192.168.100.0/24 10.1.1.2
P4#show ip route
IPv4 Routing Table:
Dest
Mask
Gw
Interface
Owner
pri metric
1.1.1.1
255.255.255.255
1.1.1.1
loopback1
address
1.1.1.2
255.255.255.255
11.1.1.2
gei_1/1
static
10.1.1.0
255.255.255.0
10.1.1.1
gei_2/1
direct
10.1.1.1
255.255.255.255
10.1.1.1
gei_2/1
address
11.1.1.0
255.255.255.252
11.1.1.1
gei_1/1
direct
11.1.1.1
255.255.255.255
11.1.1.1
gei_1/1
address
12.1.1.0
255.255.255.252
11.1.1.2
gei_1/1
bgp
20
13.1.1.0
255.255.255.252
11.1.1.2
gei_1/1
bgp
20
14.1.1.0
255.255.255.252
11.1.1.2
gei_1/1
bgp
20
20.1.1.0
255.255.255.0
11.1.1.2
gei_1/1
bgp
20
192.168.0.0
255.255.255.0
10.1.1.2
gei_2/1
static
192.168.1.0
255.255.255.0
10.1.1.2
gei_2/1
static
7-66
SJ-20100901100356-015|2011-07-30(R1.0)

192.168.2.0
255.255.255.0
10.1.1.2
gei_2/1
static
192.168.3.0
255.255.255.0
10.1.1.2
gei_2/1
static
192.168.100.0 255.255.255.0
10.1.1.2
gei_2/1
static
Test network connectivity on P4 and P5.

P4#ping 20.1.1.1
sending 5,100-byte ICMP echos to 20.1.1.1,timeout is 2 seconds.
!!!!!
P4#trace 20.1.1.1
tracing the route to 20.1.1.1
1
11.1.1.2
20 ms
<20ms
<20ms
13.1.1.2
<20ms
<20ms
<20ms
12.1.1.1
<20ms
<20ms
<20ms
14.1.1.2
<20ms
<20ms
<20ms
[finished]
P5#ping 10.1.1.2
sending 5,100-byte ICMP echos to 10.1.1.2,timeout is 2 seconds.
!!!!!
P5#trace 10.1.1.2
tracing the route to 10.1.1.2
1
14.1.1.1
<20ms
<20ms
<20ms
12.1.1.2
<20ms
<20ms
<20ms
13.1.1.1
<20ms
<20ms
<20ms
11.1.1.1
<20ms
<20ms
<20ms
[finished]
Perform the test on the PC whose IP address is 10.1.1.2 255.255.255.0.

C:\Documents and Settings\Administrator>ping 20.1.1.1
Pinging 20.1.1.1 with 32 bytes of data:
Reply from 20.1.1.1: bytes=32 time=1ms TTL=251
Ping statistics for 20.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
C:\Documents and Settings\Administrator>tracert 20.1.1.1
7-67
SJ-20100901100356-015|2011-07-30(R1.0)

Tracing route to 20.1.1.1 over a maximum of 30 hops
1
<1 ms
6 ms
<1 ms
10.1.1.1
1 ms
1 ms
1 ms
11.1.1.2
1 ms
1 ms
1 ms
13.1.1.2
1 ms
1 ms
1 ms
12.1.1.1
1 ms
1 ms
1 ms
20.1.1.1
Trace complete.
The test results of step 5 and step 6 show that network communications are proper between
AS2 and AS3.
7.3.3 Example 3: Comprehensive BGP Configuration

This configuration example involves the BGP applications such as route aggregation and
static routes.
As shown in Figure 7-20, P4 and P1 are EBGP neighbors, P1 and P2 are IBGP neighbor,
and P2 and P5 are connected through multi-hop EBGP. Suppose that P4 has four static
routes listed in Figure 7-20.
In the configuration of P4, aggregate and advertise only 192.16.0.0/16, and configures the
route map to forbid the advertisement of 170.16.10.0/24 through BGP. Connect P2 and P5
through multi-hop EBGP. Before configuring BGP, make sure that the addresses used by
ZXCTN9000s can ping through each other.
Figure 7-20 BGP Configuration Example
7-68
SJ-20100901100356-015|2011-07-30(R1.0)

remote-as 1
next-hop-self
remote-as 2

P2(config)#ip route 183.16.0.0 255.255.0.0 173.16.2.1

P4(config-router)#redistribute static
as-set summary-only
P4(config-router)#neighbor 172.16.20.2 route-map torouteP1 out
P4(config)#acl std num 1
P4(config-std-acl)#rule 1 deny
170.16.10.0 0.0.0.255

P4(config-std-acl)#exit
P4(config)#route-map torouteP1 permit 10

P5(config)#ip route 173.16.0.0 255.255.0.0 183.16.20.1
Run the show ip bgp summary command on P4 to view the neighboring relationship.
P4(config)#show ip bgp summary
Neighbor
172.16.20.2
Ver
4
As
1
MsgRcvd
46
MsgSend
Up/Down(s)
140
00:22:35
State/PfxRcd
0
Run the show ip bgp route command on P4 to view the BGP routing table.
7-69
SJ-20100901100356-015|2011-07-30(R1.0)

Dest
NextHop
Metric
LocPrf
RtPrf
Path
*> 192.16.0.0/16
0.0.0.0
254
*> 192.16.20.0/24
10.9.1.39
*> 192.16.21.0/24
10.9.1.39
*> 192.16.22.0/24
10.9.1.39
*> 170.16.10.0/24
10.9.1.39
MsgRcvd
MsgSend
172.16.20.1
Neighbor
Ver
4
As
2
46
140
Up/Down(s)
00:22:35
State/PfxRcd
1
172.16.1.2
46
140
00:22:35
BGP routing table on P1:

Dest
*>
NextHop
192.16.0.0/16
Metric
LocPrf
RtPrf
172.16.20.1
Path
20
i 2
Neighbor
Ver
183.16.20.2
As
3
MsgRcvd
46
MsgSend
140
Up/Down(s)
00:22:35
State/PfxRcd
0
172.16.1.1
46
140
00:22:35

Dest
*>i
NextHop
192.16.0.0/16
Metric
LocPrf
172.16.1.1
RtPrf
Path
200
i 2
Run the show ip bgp summay command on P5 to view the neighboring relationship.
Neighbor
Ver
173.16.20.2
As
MsgRcvd
46
MsgSend
140
Up/Down(s)
State/PfxRcd
00:22:35

Dest
*>
192.16.0.0/16
NextHop
Metric
173.16.20.2
LocPrf
RtPrf
20
Path
i 1 2
7-70
SJ-20100901100356-015|2011-07-30(R1.0)
7.4 BGP Troubleshooting

7.4.1 BGP Basic Troubleshooting
Take the topology as shown in Figure 7-21 to describe how to establish EBGP neighboring
relationship between loopback1 of P1 and loopback1 of P2. Routes are connected through
actual interfaces.
Figure 7-21 Network Topology for Handling BGP Fault

Fault symptom: Neighboring relationship is not available between loopback interfaces of
P1 and P2.
Check whether the loopback interfaces can ping through each other. If not, check whether
physical links are in up state. Check physical interfaces can ping through each other. If
not, check whether physical interfaces are in up state. If physical interfaces are in up state
but cannot ping through each other, change the cable or contact the technical support
engineer for help. If physical links are in up state, routes between the loopback interfaces
may be not available. In this case, configure the routes. If physical interfaces can ping
through each other, the configurations of AS number, multi-hop, and TCP initiator may be
incorrect. Use the show ip bgp neighbor command to check the error code and search for
the BGP error code table to locate the fault. If the fault still persists, contact the technical
support engineer for help.
Item
Remarks
Remote-as
Followed by the AS number of the neighbor.
Update source
This item is required when the neighboring relationship is established

between loopback interfaces.
ebgp-multihop
This item is required for multi-hop EBGP neighbors.

The flow to handle a BGP fault is shown in Figure 7-22.
7-71
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-22 Flow to Handle a BGP Fault
Table 7-1 shows the BGP error code table.
7-72
SJ-20100901100356-015|2011-07-30(R1.0)
Table 7-1 BGP Error Code Table

Error
Meaning
Error ID
Description
The connection is not
Code
synchronized.
1
Packet header error
The packet length is

incorrect.
The packet format is

incorrect.
The version number is not

supported.
The peer AS is incorrect.
The BGP identifier is

incorrect.
The open packet is

incorrect.
The optional field is

incorrect.
The authentication fails.
The holdtime is not

acceptable.
The attribute list is

malformed.
The well-known attribute is

nonidentifiable.
The well-known attribute is

lost.
The attribute flag is

incorrect.
5
3
The update packet is
The attribute length is

incorrect.
incorrect.
6
The oringin attribute is

illegal.
The AS route loop occurs.
The next hop attribute is

illegal.
The optional attribute is

incorrect.
10
The network segment is

illegal.
7-73
SJ-20100901100356-015|2011-07-30(R1.0)
Error
Meaning
Error ID
Description
11
The AS_PATH attribute is
Code
incorrect.
4
The hold timer expires.
The finite state machine is
The maximum number of
incorrect.
6
Termination
prefixes received by the

neighbor is exceeded.
2
The neighbor is in invalid

state.
The neighbor is invalid

due to configuration
modification.
The BGP instance or

neighbor is reset.
The connection is denied.
The configuration is
changed due to neighbor
modification.
The connections collide.
The neighbor is shut down

due to memory exhaustion.

The procedure to handle a BGP fault is described below.
1. Check whether the physical interface is in up state.
2. Check whether routes are available between loopback interfaces. Check whether
loopback interfaces can ping through each other.
3. Check whether AS numbers are correctly configured on both ends.
4. For multi-hop EBGP neighbors, check whether ebgp-multihop is configured.
5. For loopback address-based links, check whether update source is configured.
6. Use the show ip bgp neighbor command to check the error code and search for the
BGP error code table to locate the fault.
7-74
SJ-20100901100356-015|2011-07-30(R1.0)
7.4.2 BGP FRR Troubleshooting

Take the topology shown in Figure 7-23 as an example to describe how to handle an BGP
FRR fault.
Figure 7-23 Network Topology for Handling BGP FRR Fault

The application conditions for BGP FRR are relatively easy to meet. If two next hops are
available for one destination and the route does not exist in the backup routing table, check
whether load balancing is enabled and the conditions for load balancing are met. If both
FRR and load balancing are configured and the conditions for load balancing are met, load
balancing takes effect.

The flow to handle a BGP FRR fault is shown in Figure 7-24.
7-75
SJ-20100901100356-015|2011-07-30(R1.0)
Figure 7-24 Flow to Handle a BGP FRR Fault

The procedure to handle a BGP FRR fault is described below.
1. Use the show running-config [bgp | ospf|isis] command to check whether the FRR
configuration is enabled.
7-76
SJ-20100901100356-015|2011-07-30(R1.0)
Figures
Figure 2-1 Configuring Static Route .......................................................................... 2-3
Figure 2-2 Configuring Static L3VPN Route .............................................................. 2-4
Figure 2-3 Configuring Default Route........................................................................ 2-5
Figure 2-4 Network Topology for Handling a Static Route Fault................................. 2-7
Figure 2-5 Flow to Handle a Static Route Fault ......................................................... 2-8
Figure 3-1 Configuring ARP Proxy Application .......................................................... 3-8
Figure 3-2 Network Topology for Handling Basic ARP Fault .................................... 3-10
Figure 3-3 Flow to Handle ARP Fault...................................................................... 3-11
Figure 4-1 Topology of the RIP Configuration Example ........................................... 4-12
Figure 4-2 Network Topology for Handling an RIP Fault .......................................... 4-14
Figure 4-3 Flow to Handle an RIP Fault .................................................................. 4-15
Figure 5-1 Configuration Example............................................................................. 5-2
Figure 5-2 Configuring OSPF Interface Attribute ....................................................... 5-5
Figure 5-3 Configuration Example............................................................................. 5-8
Figure 5-4 Configuration Example........................................................................... 5-12
Figure 5-10 Configuring Sham Link......................................................................... 5-31
Figure 5-11 Configuration Example ......................................................................... 5-33
Figure 5-12 Topology of OSPF Configuration Example 1 ........................................ 5-45
Figure 5-13 Topology of OSPF Configuration Example 2 ........................................ 5-47
Figure 5-14 Topology of OSPF Multi-instance Configuration Example..................... 5-50
Figure 5-15 OSPFv2 Routing Load Balancing Configuration Example .................... 5-52
Figure 5-16 Network Topology for Handling Basic OSPF Fault................................ 5-54
Figure 5-17 Flow to Handle Basic OSPF Fault ........................................................ 5-56
Figure 5-18 Network Topology for Handling OSPF Multi-instance Fault................... 5-57
Figure 5-19 Flow to Handle OSPF Multi-instance Fault ........................................... 5-58
Figure 5-20 Network Topology for Handling OSPF Routing Load Balancing
Fault ..................................................................................................... 5-59
Figure 5-21 Handle OSPF Routing Load Balancing Fault........................................ 5-60

Figure 5-22 Network Topology for Handling OSPF FRR Fault ................................. 5-61
Figure 5-23 Flow to Handle OSPF FRR Fault ......................................................... 5-62
Figure 6-1 Configuring Single-Area IS-IS ................................................................ 6-18
Figure 6-2 Configuring Multi-Area IS-IS .................................................................. 6-21
Figure 6-3 Typical Networking of Node Protection................................................... 6-27
Figure 6-4 Typical Networking of Link Protection..................................................... 6-28
Figure 6-5 Network Topology for Handling IS-IS Fault ............................................. 6-30
Figure 6-6 Flow to Handle an IS-IS Fault ................................................................ 6-31
Figure 6-7 Network Topology for Handling IS-IS FRR Fault..................................... 6-32
Figure 6-8 Flow to Handle an IS-IS FRR Fault ........................................................ 6-33
Figure 7-1 IBGP and EBGP Neighbors ..................................................................... 7-1
Figure 7-2 Network Topology for Configuring EBGP Neighbors Through Directly
Connected Ports ..................................................................................... 7-4
Figure 7-3 Network Topology for Configuring the EBGP Neighbors Through
Loopback Addresses .............................................................................. 7-5
Figure 7-4 Network Topology for Configuring IBGP Neighbors ................................ 7-10
Figure 7-5 Advertising Route by Using the network Command................................ 7-15
Figure 7-6 Network Topology for Redistributing Route into the BGP Routing
Table..................................................................................................... 7-17
Figure 7-8 Network Topology for Filtering Routes by Route Map ............................. 7-24
Figure 7-9 Network Topology for Filtering Routes by NLRI ...................................... 7-26
Figure 7-10 Restricting the Number of Routes Accepted by A Neighbor.................. 7-28
Figure 7-11 Network Topology for Selecting Routes by AS_PATH ........................... 7-30
Figure 7-12 Network Topology for Selecting Routes by LOCAL_PREF ................... 7-33
Figure 7-13 Network Topology for Selecting Routes by MED .................................. 7-36
Figure 7-14 Network Topology for Controlling Large Numbers of Routes by
Community ........................................................................................... 7-40
Figure 7-15 Network Topology for Configuring the Route Reflector ......................... 7-44
Figure 7-16 Network topology for Configuring the BGP Confederation .................... 7-46
Figure 7-17 Typical Networking of Node Protection................................................. 7-57
Figure 7-18 Typical Networking of Link Protection................................................... 7-57
Figure 7-19 Network Topology for Comprehensive BGP Configuration.................... 7-59
Figure 7-20 BGP Configuration Example ................................................................ 7-68
Figure 7-21 Network Topology for Handling BGP Fault ........................................... 7-71
II
Figures
Figure 7-22 Flow to Handle a BGP Fault................................................................. 7-72

Figure 7-23 Network Topology for Handling BGP FRR Fault ................................... 7-75
Figure 7-24 Flow to Handle a BGP FRR Fault......................................................... 7-76
III
Figures
Glossary
ABR
- Area Border Router
ARP
- Address Resolution Protocol
ASBR
- Autonomous System Boundary Router
BGP
- Border Gateway Protocol
IS-IS
- Intermediate System-to-Intermediate System
LSA
- Link State Advertisement
LSDB
- Link-state Database
OSPF
- Open Shortest Path First
RIP
- Routing Information Protocol

ZXCTN 9000 MML Configuration Guide (IPv4 Routing) V2.08.32 en

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ZXCTN 9000 MML Configuration Guide (IPv4 Routing) V2.08.32 en

Hochgeladen von

Copyright:

Verfügbare Formate

ZXCTN 9002/9004/9008

Packet Transport Network Product

MML Configuration Guide (IPv4 Routing)

Additionally, the contents of this document are protected by

contractual confidentiality obligations.

ZXCTN 9002/9004/9008(V2.08.32) first version issued

Serial Number: SJ-20100901100356-015

About This Manual

What Is in This Manual

Chapter 2 Static Route

Describes the Static Route Basic principle, configuration

commands, maintenance commands, configuration examples

Chapter 3 ARP Configuration

Describes the ARP principle, configuration commands,

Chapter 4 RIP Configuration

Describes the RIP principle, configuration commands,

Chapter 5 OSPF Configuration

Describes the OSPF principle, configuration commands,

Chapter 6 IS-IS Configuration

Describes the IS-IS principle, configuration commands,

Chapter 7 BGP Configuration

Describes the BGP principle, configuration commands,

Network planning engineer

Keys on the keyboard and buttons on screens and company name.

Separates individual parameter in series of parameters.

Checkpoint: Indicates that a particular step needs to be checked before proceeding

Press Ctrl-P or the up arrow

It re-invokes the latest commands in the record buffer. Repress

these keys to invoke old commands forwards.

Press Ctrl-N or down arrow

Roll commands downwards. When the last command line is

1.1 Safety Instructions

ZTE Proprietary and Confidential

ZXCTN 9002/9004/9008 MML Configuration Guide (IPv4 Routing)

Please strictly follow the above instructions.

ZTE Proprietary and Confidential

Static Route Configuration

2.1 Configuring Static Route

ZXCTN9000#ip route [ mng | vrf < vrf-name> ] <

Configures a static route.

ip-address> < mask> { < interface> | { [ interface] <

Deletes a static route.

ip-address> < mask> [ < 1-255> ] [ tag < 150-255>

The parameters are described in the table below.

Configures a static route for the management

vrf < vrf-name>

Configures a static route for the specified VRF.

Indicates the destination IP address.

Indicates the mask.

Indicates the egress.

Indicates the next hop.

ZTE Proprietary and Confidential

ZXCTN 9002/9004/9008 MML Configuration Guide (IPv4 Routing)

Indicates that the next hop is the next-hop IP

Indicates the priority of the route.

Indicates the tag value of the route. This

Indicates the FRR wait-to-restore time. The value

Binds the static route to a ping detection group.

Binds the static route to a track session.

2.2 Maintaining Static Route

ZXCTN9000#show ip route [ vrf < vrf-name> ] static

Shows the global routing table of the

IPv4 Routing Table: